Subject: [Sip-security] Re: Digest AKA in IETF

From: Greg Rose <[email-masked]>
Date: Fri, 19 Apr 2002 08:44:47 +1000

[Resend -- I goofed the sip-security address.]

At 02:36 PM 4/18/2002 +0300, Aki Niemi wrote:
>The draft is in WG Last Call starting from beginning of this week, and 
>will remain so for two weeks. This is the time to collect comments from 
>the WG review of the document. Once the WGLC ends, the document will enter 
>IETF LC for two weeks, now soliciting feedback from the entire IETF 
>community. After that the draft is ready for the IESG, and to pursuit 
>Standards Track RFC status. The objective is to do all this by mid May (in 
>bundle #2).
>
>Please comment the draft, and also preferably send the comments also on 
>the SIP WG list at:

Hello Aki,

I directed this message to sip.security, rather than all of sip... I 
apologise if this is the wrong thing to do.

The draft appears to allow "algorithm=AKAv1-MD5-sess", which would 
implicitly allow reuse of the (possibly only 32-bit) RES in the context of 
the password. As we have already discussed on this list, that would be both 
insecure and contrary to the intent of AKA. Unless there is an explicit 
reason for inclusion of this option (other than allowing reuse of RES...) I 
would limit AKA to be used only with MD5 and not MD5-sess.

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

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

---

From: Jari Arkko <[email-masked]>
Date: Fri, 19 Apr 2002 08:50:01 +0300

Greg Rose wrote:

 > implicitly allow reuse of the (possibly only 32-bit) RES in
 > the context of the password. As we have already discussed on this list,
 > that would be both

Yes, and thanks for pointing this out. There is no reason to
support MD5-sess and MD5 should be sufficient.

Jari