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

From: Greg Rose <[email-masked]>
Date: Mon, 18 Mar 2002 12:10:14 +1100

[As requested, I've taken "sipping" out of the Cc: line.]

At 10:08 AM 3/15/2002 +0000, James Undery wrote:
>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

This is definitely not in line with the intent of AKA, or the existing 
architecture.

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

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

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Mar 2002 17:42:03 +0200

> This is definitely not in line with the intent of AKA, or the existing 

What I understood James proposing is that *if* AKA is used for the
authentication of an INVITE to the home after being used for authenticating
a REGISTER, then AKA should be re-run.

In the above, do you mean the 3GPP architecture in 'the existing architecture'?
 From what I understand the 3GPP architecture only intends to authenticate REGISTERs
with AKA. Therefore, if draft-niemi allows anything to happen after the
first authentication, it is beyond the 3GPP architecture. If plugging a
security hole requires that we never allow AKA authentication to be reused
and always need a new full AKA run, I would say that's fine. Greg, does
preventing reuse of the same RES help to block the security problem?
Also, I have proposed simply requiring 128 bit RES values to be used,
that solves the problem but is there any reason why we couldn't require
it?

Then we have another matter of how the INVITEs are authenticated in 3GPP.
That is based on the session keys generated as a side effect of AKA.
Let's keep the AKA re-run to the home -discussion separate from this.

Jari

---

From: Greg Rose <[email-masked]>
Date: Tue, 19 Mar 2002 07:41:00 +1100

Thanks for your questions.

>a REGISTER, then AKA should be re-run.

Yes, in theory that would be fine, but I did not get this from my reading 
of draft-undery. It appears to me that it uses the same A1 that was 
calculated during the processing of the register message, in the subsequent 
step.

>first authentication, it is beyond the 3GPP architecture.

Yes, true.

>  If plugging a

It helps but it doesn't completely solve the problem. Whatever the process 
by which RES (old *or new*) is used to calculate the authentication values, 
can be used by a man-in-the-middle:
1. Mal gets the SIP message, and blocks its onward delivery.
2. He quickly sets his lab of computers to the task of finding 32-bit RES.
3. Before the reply timer expires, he can create any message he wants, and 
authenticate it using that value of RES, even though it is only used once.

Note that even a 64-bit RES probably defeats this.

Note also that air-interface ciphering also stops it working, if Mal is on 
the air interface... but he might not be.

>that solves the problem but is there any reason why we couldn't require

I had understood that there were compatibility issues with this, but that 
is a question for operators to answer... I don't know. Anyway, I'd be 
perfectly happy if that was done; all my objections would go away.

Thanks,
Greg.

---

From: Jari Arkko <[email-masked]>
Date: Mon, 18 Mar 2002 23:02:52 +0200

Hi Greg and thanks for your response. Some
further discussion below.

> Yes, in theory that would be fine, but I did not get this from my 
> reading of draft-undery. It appears to me that it uses the same A1 that 
> was calculated during the processing of the register message, in the 
> subsequent step.

This may be true, but draft-undery doesn't deal with AKA. Draft-niemi
does. If you meant draft-niemi, then we should fix it (it shouldn't
do that).

> It helps but it doesn't completely solve the problem. Whatever the 
> process by which RES (old *or new*) is used to calculate the 
> authentication values, can be used by a man-in-the-middle:
> 3. Before the reply timer expires, he can create any message he wants, 
> and authenticate it using that value of RES, even though it is only used 
> once.
> 

Fair enough, I suspected that this might be the case.
But a further question. Assuming a MD5(RES) is crackable
and the MitM can send his own request, why isn't pure RES
crackable in the same way? That is, if we send just the
RES, the MitM can just pick the value and without any lab
computers he can place the RES in a different request, and
the server side can't detect anything. So, while I understand
the attack, what does removing MD5 encapsulation give us?

> I had understood that there were compatibility issues with this, but 
> that is a question for operators to answer... I don't know. Anyway, I'd 
> be perfectly happy if that was done; all my objections would go away.

Ok, let's try to figure this question out then.

Jari

---

From: Greg Rose <[email-masked]>
Date: Tue, 19 Mar 2002 14:27:33 +1100

>does. If you meant draft-niemi, then we should fix it (it shouldn't

As I've said all along, there's no problem with draft-undery by itself. And 
since I've now identified a problem with even a single message integrity 
calculation using 32-bit RES, yes, we can focus on draft-niemi.

>the attack, what does removing MD5 encapsulation give us?

This is a very deep philosophical question :-). It has to do with the 
difference between authentication and message integrity. Just sending RES 
implies that the real terminal (ISIM) existed and was in contact at this 
point in time. By itself, it says nothing about the message that contained 
it. But if RES is also used to calculate some sort of message integrity 
check, it seems to be promising something that it isn't delivering, namely 
message integrity via HTTP-digest.

>[Just use 128-bit RES then?]

I agree, let's just find out if this is truly an option.

regards, and apologies if I sound argumentative,
Greg.

---

From: John W Noerenberg II <[email-masked]>
Date: Fri, 29 Mar 2002 09:29:16 -0800

>I agree, let's just find out if this is truly an option.

Has anyone determined whether or not a 128-bit RES is backward compatible?
-- 

john noerenberg
[email-masked]
   ----------------------------------------------------------------------
   While the belief we  have found the Answer can separate us
   and make us forget our humanity, it is the seeking that continues
   to bring us together, that makes and keeps us human.
   -- Daniel J. Boorstin, "The Seekers", 1998
   ----------------------------------------------------------------------

---

From: Greg Rose <[email-masked]>
Date: Sun, 31 Mar 2002 12:39:19 +1000

>Has anyone determined whether or not a 128-bit RES is backward compatible?

Definitely not backward compatible, although that might not yet be a 
big deal. In the meantime, however, the vote in SA3 has been to go 
with IPsec for integrity protection, so the problem is now moot; 
32-bit RES is sufficient in that context.

thanks,
Greg.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 31 Mar 2002 08:02:29 +0300

Greg Rose wrote:

> Definitely not backward compatible, although that might not yet be a big 
> deal. In the meantime, however, the vote in SA3 has been to go with 
> IPsec for integrity protection, so the problem is now moot; 32-bit RES 
> is sufficient in that context.

As far as I understand, whether IPsec or James' enhanced digest was adopted
as the solution for first hop integrity protection does not affect the RES
discussion at all. Both use the generated session key, IK, and not RES.

The only discussion has been on whether Digest AKA -- the home authentication
scheme for 3G networks -- uses RES in the clear or whether it ties the RES to the
rest of the message using MD5. The former approach is kind of like basic using
one time passwords, the latter is regular digest usage. The former is always
vulnerable to someone replacing the message contents but keeping RES; the
latter is not vulnerable to this except when RES is short.

The input from the IETF meeting was that the Digest approach is favored.

Jari