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

From: John W Noerenberg II <[email-masked]>
Date: Thu, 14 Mar 2002 16:37:48 -0800

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

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

---

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

John, Greg,

Thanks for an interesting describing this interesting attack! I believe
while making draft-niemi the authors have been assuming that we do not
use the GSM compatibility mode (which I believe is the reason why the RES
could be only 32 bits). That is, when full AKA is used this isn't a problem.

So, we could either

(1) Require the full use of AKA
(2) Switch to using IK and not RES as input in the Digest process

Greg, is the IK free of similar limitations when GSM compatibility
is used?

Jari

---

From: Greg Rose <[email-masked]>
Date: Fri, 15 Mar 2002 18:38:30 +1100

>could be only 32 bits). That is, when full AKA is used this isn't a problem.

Regrettably, this is not correct. RES could be as little as 32 bits *even 
in full AKA*.

>(2) Switch to using IK and not RES as input in the Digest process

IK is the obvious (to me) candidate.

>Greg, is the IK free of similar limitations when GSM compatibility

If I understand your question correctly -- yes. IK is always 128 bits 
coming out of the USIM, even if it is subsequently "dumbed down" for GSM 
compatibility (which should never happen in anything capable of packet data 
and IMS). When a *GSM SIM* is used, you will only get out a 64-bit K_c, but 
even that is a lot better than a 32-bit RES.

regards,
Greg.

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: Jari Arkko <[email-masked]>
Date: Fri, 15 Mar 2002 10:52:17 +0200

> Regrettably, this is not correct. RES could be as little as 32 bits *even

Yes, but don't we have the choice of *requiring* that
in order to use AKA in Digest, you have to provide
128 bits? Is there a particular reason why less than
128 bits would have to be produced. In particular, as
the draft is currently written, we do not transport the
RES over the air, so its length is not an efficiency issue.

[By the way Vesa: it does not help extending a short user
password, because in the end there's not enough original
bits.]
 
Jari

---

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

Hi All,

> (2) Switch to using IK and not RES as input in the Digest process

As far as I understand the authentication/integrity protection schemes 
of 3GPP IMS, the authentication is between the UE and the S-CSCF, and 
the integrity protection is between the UE and the P-CSCF. Therefore I 
can't see a problem in using RES as input for Digest AKA in the 
authentication, and IK as input for the Digest in integrity protection.

The RES would then constitute a one-time password type key, whereas IK 
is a more long term key for integrity protection.

I don't see a need to group the two mechanisms together.

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