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

From: Greg Rose <[email-masked]>
Date: Fri, 15 Mar 2002 12:52:06 +1100

At 06:48 PM 3/14/2002 -0600, Sanjoy Sen wrote:

>draft-undery-sip-auth-00.txt doesn't make any recommendation as to how the 
>password should be computed. However, I remember that when we took the 
>proposal of using Digest for the first time to 3GPP, we had recommended 
>using IK as the password.

That's right. draft-undery-sip-auth-00.txt assumes that the password is 
strong, and by itself has no problems. draft-niemi-sipping-digest-aka-00 
assumes that RES is used as the password only once for the authentication, 
and by itself has no problems. Put the two together, and there's a problem...

BTW, my suggestion to use IK would solve this juxtaposition problem (since 
a 128 bit "choke point" is not seen to be a problem), but is not seen to be 
acceptable to 3GPP SA3, because that would mean that IK was to be used for 
two distinct things potentially at the same time, although I don't agree 
with this  argument (it seems to me that the 3GPP mechanism and 
draft-undery-... can't both be used at the same time). However the 
Ciphering Key CK is also available, 128 bits, and is not expected to be 
used for anything. Anyway, possible solutions can be examined further.

Thanks to John Noerenberg for helping me distribute this information.

regards,
Greg.

>Sanjoy
>
> > -----Original Message-----
> > From: John W Noerenberg II 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > Sent: Thursday, March 14, 2002 6:38 PM
> > To: [email-masked]; [email-masked]
> > Cc: Greg Rose; [email-masked]; [email-masked];
> > [email-masked]; James Undery; Sen, Sanjoy [NGC:B692:EXCH]
> > 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.
> >
> > 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.
> >
> > 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

_______________________________________________
Sip-security mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sip-security

---

From: "Niemi Aki (NET/Espoo)" <[email-masked]>
Date: Fri, 15 Mar 2002 11:38:25 +0200

Hi Greg, John,

Thanks for the comments!

> and by itself has no problems. Put the two together, and there's a problem...

I'm a little confused on where the problem actually is. In draft-niemi, 
we at some point were thinking about adding an HTTP Digest feature 
called stale nonces to Digest AKA. This would've made it possible to 
reuse the RES when calculating a Digest response with a "fresh" nonce 
value.

However, we decided not to include that as it turns out that in RFC 
2617, the UA can also always ignore the stale flag, and ask the 
username/password from the user. Thus, the nonce in Digest AKA must 
always contain the AKA parameters RAND, AUTN, and a new RES is therefore 
always calculated when the UA receives a Digest AKA challenge.

What comes to integrity protection, the draft-undery should definitely 
always be used with the IK. RES should be seen as a one-time password 
for authentication only. In fact, I would argue, that reusing the RES in 
Digest AKA is not possible, even.

But I guess that isn't stated very well in draft-niemi and should really 
be there. We'll add some clarifying text.

Cheers,
Aki

---

From: Jari Arkko <[email-masked]>
Date: Fri, 15 Mar 2002 11:41:26 +0200

> and by itself has no problems. Put the two together, and there's a problem...

We are in agreement that IK should be used as the password
for draft-undery. However, I feel that in this discussion we
have been mixing draft-undery and draft-niemi in a manner
that it doesn't clearly show that this is still being
done. Let me try to clarify this situation in light
of the 3GPP architecture:

1. Draft-undery is being used for UE - P-CSCF int. protection.
   Algorithm = MD5, password = IK (communicated to the P-CSCF
   using method X from the S-CSCF).

2. Draft-niemi is being used for UE - S-CSCF authentication.
   Algorithm = AKA and no traditional password, just the
   shared long term secret. The authentication is based on
   RES. As a side effect an IK is produced (and communicated
   to the P-CSCF using means beyond draft-niemi).

So, in this particular case Draft-Undery *does* use the
IK as the password. The only remaining issue is how
Draft-Niemi calculates Digest results, and whether
that reveals anything interesting to attackers. 

Draft-niemi is an application of Digest and as such has some
integrity protection features, and particular way to
calculate Response. This particular way is essentially
MD5(... RES ...). So at this point we are not using IK
twice anywhere. But perhaps there's an attack that would
reveal RES, if it was too short. (I personally think we
should simply require it to be long, but I'll ignore that
for the moment.)

Let's study this by considering two cases:

(a) AKA is run at the beginning and if any further
    communications with the home network take place,
    the RES is cached and used as a password. This
    allows the attack described by Greg. But as
    Aki explained, it seems that we have forbidden
    this in Draft-niemi.

(b) AKA has to be run every time, and a RES can't be
    reused. Is there a problem left then?

Jari

---

From: "Niemi Aki (NET/Espoo)" <[email-masked]>
Date: Fri, 15 Mar 2002 15:18:07 +0200

Hi,

On 03/15/2002 11:41 AM, ext Jari Arkko wrote:

[snip]

>     Aki explained, it seems that we have forbidden

I would further divide this into two subcases:

(a1)
The actual Digest credentials are cached, and the UA attempts to use 
them in further communications with the same server. If the server is 
not happy with then, it can rechallenge.

(a2)
The RES is cached, and used again as part of the stale nonce scheme when 
calculating Digest credentials.

 From these two, I'd say only the second case seems to be forbidden in 
draft-niemi.

Regards,
Aki

> 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
>