Subject: [Sipping] RE: SIP authentication problem when using RES in Digest-AKA

From: "James Undery" <[email-masked]>
Date: Fri, 15 Mar 2002 10:08:14 -0000

Forgive me for being a bit slow, but I can't see how this attack works.
Firstly I'll check RES uses a shared secret and some entropy to create a
session password to provide forward security?

Comments inline.

> -----Original Message-----
> From: John W Noerenberg II [mailto:[email-masked]]
> Sent: 15 March 2002 00:38
> To: [email-masked]; [email-masked]
> Cc: Greg Rose; [email-masked]; [email-masked];
> [email-masked]; James Undery; Sanjoy Sen
> Subject: SIP authentication problem when using RES in Digest-AKA
> 
> 
> Greg Rose has identified a security problem when HTTP-Digest is 
> combined with the mechanism proposed in 
> draft-niemi-sipping-digest-aka-00 and draft-undery-sip-auth-00.  He's 
> outlined this for the 3GPP TSG SA WG3, one of the TSG security area 
> working groups.
> 
> Essentially the problem is a consequence of using a RES that is 
> shorter than the key from which it is derived, typically as small as 
> 32 bits.  RES's length results from the goal of maintaining backward 
> compatibility with existing USIMs.  RES is a choke point that can be 
> used to break the authentication.  Instead of using RES, IK has much 
> greater entropy, and makes the attack prohibitively difficult.  A 
> description of the attack against RES is given below.
> 
> The authentication process can be summarized as follows:
> 
> 1. UE attempts to register.
> 2. The attempt is rejected because the UE is unauthenticated.  The 
> rejection message includes AKA-related information and an HTTP-Digest 
> nonce.
> 3. UE/USIM checks the AKA information and computes RES.
> 4. RES is now used as the password shared by the UE and the CSCF.
> 5. UE computes HTTP-Digest response based on RES, and 
> attempts to register.
> 6. Registration succeeds.
> 
> Subsequently
> 
> 7. UE sends another SIP message (e.g. Invite) and the HTTP-Digest 
> method calculates authentication information based on RES. 
> (Actually, A1 is used, but it is derived from RES).
> 
> Choke Point Attack
> 
> An attacker monitoring the traffic would break the scheme as follows:
> 
> The attacker has all the messages from steps 2 and 5 above.  All of 
> the information used in the calculation of the response in step 5, 
> except for the value of RES is present in these messages.  Assuming 
> RES is 32 bits, the attacker tries the 2**32 possible values, 
> comparing them to the captured response generated for step 5.  With 
> very high probability, he will succeed with exactly one candidate 
> value for RES, in the time needed to calculate 2**31 MD5 hashes. 
> This takes ~5 minutes on a typical laptop.

The RES 'secret' is surely going to be recalculated each time the
session entropy (i.e. nonce) changes. Thus I'd modify step 4 and add
pre7

4. RES is now used as the password shared by the UE and the CSCF for the
register.

pre7. UE/USIM checks the AKA information and computes RES. RES is now
used as the password shared by the UE and the CSCF until the nonce is
changed.

The attacker now can obtain the old RES 'secret' and it has bought him
zip unless given enough of these he can break the method the RES
'secret' is calculated.

> Once the value of RES is known, the attacker can now forge SIP 
> messages or alter them in transit, recalculating the Digest after 
> altering the message.
> 
> By replacing the use of RES with a higher entropy quantity, this 
> attack can be prevented.  As noted above, Greg recommends using IK as 
> a replacement for RES.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Greg Rose <[email-masked]>
Date: Fri, 15 Mar 2002 13:00:44 +1100

At 07:18 PM 3/14/2002 -0600, Sanjoy Sen wrote:

>Another option to think about is whether there is any need to carry AKA 
>credentials (as is) in the HTTP *-Authenticate and *-Authorization 
>headers. This means that we define AKA as an authentication scheme at par 
>with Digest (instead of using it as a password generation tool, say, for 
>Digest MD5). In HTTP Authentication syntax,
>
>challenge = "AKA" AKA-challenge
>AKA-challenge = 1#(rand | autn | auth-param)
>
>credential = "AKA" AKA-response
>AKA-response = 1#(res | [auts])
>
>where, rand, res, autn, auts (all AKA parameters) are all base64 encoded. 
>One advantage of this approach is that you need not run Digest algorithms 
>(draft-niemi-sipping-digest-aka-00 forces you to run both a Digest 
>algorithm and the AKA authentication algorithm).
>
>We discussed about this option but never reached any agreement on whether 
>to go for this. It was not clear whether transferring res will lead to any 
>potential security attacks.

I think that somehow doing it directly got tied up with use of EAP to 
encapsulate everything, and the EAP approach was then dropped. But direct 
use of AKA instead of doing both AKA and then Digest is (IMO) far 
preferable. Then A1 for draft-undery-... could be IK (or derived from it) 
without any problem I'm aware of. I'm not sure what happened to this 
possibility.

The security analysis of 3GPP AKA is available, and it is clear that there 
is no security exposure in revealing RAND, RES and AUTN publicly (except 
enabling brute-force offline attack, which was already true for HTTP-Digest).

Greg.

> > From: John W Noerenberg II 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Thursday, March 14, 2002 6:38 PM
> > [email-masked]; James Undery; Sen, Sanjoy [NGC:B692:EXCH]
> > best,
> > --
> > john noerenberg
> > [email-masked]
> > --------------------------------------------------------------
> > ------------
> >    The truth knocks on the door and you say, "Go away, I'm looking
> >    for the truth,"  and so it goes away.  Puzzling.
> >    -- Zen and the Art of Motorcycle Maintenance, Robert M.
> > Pirsig, 1974
> >
> > --------------------------------------------------------------
> > ------------
> >

Greg Rose                                       INTERNET: [email-masked]
Qualcomm Australia          VOICE:  +61-2-9817 4188   FAX: +61-2-9817 5199
Level 3, 230 Victoria Road,                http://people.qualcomm.com/ggr/
Gladesville NSW 2111    232B EC8F 44C6 C853 D68F  E107 E6BF CD2F 1081 A37C

---

From: "Sanjoy Sen"<[email-masked]>
Date: Fri, 15 Mar 2002 10:24:30 -0600

> From: Niemi Aki (NET/Espoo) [mailto:[email-masked]]
> Sent: Friday, March 15, 2002 3:28 AM

<snip>

> 
> However, by doing this you will lose the one thing that 
> Digest provides, 
> which is authentication of the SIP message, or at least parts of it 
> during the authentication procedure.
> 
> So all in all, from the AKA perspective, both options should 
> be equally 
> secure, but with Digest AKA, the SIP message is better protected. How 
> desirable exactly this added protection is, and indeed is the 
> added cost 
> of calculating the Digest MD5 worth the received benefits, is open to 
> discussion.

You can always integrity-protect the message body using a separate
Authorization header, if so desired. Actually, for integrity protection
between UE and the P-CSCF, you would use a separate header anyways. Keeping
AKA and MD5 separate gives you the option of *not* using MD5, if so desired.

Sanjoy