1. All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Zhibi Wang January, 2007

2. All Rights Reserved © Alcatel-Lucent 2007, ##### 2 | Presentation Title | January 2007 What are in IMS standards 1. IETF RFC 3261 (SIP) mandates the qop, i.e., use of the cnonce. 2. IETF RFC 3310 (HTTP Digest AKA still recommends the use of digest mechanism on top of AKA 3. In 3GPP2 IMS Security Framework S.S0086B, Digest is one of the mechanisms that can be used for access security 4. 3GPP Cx interface 3GPP TS 29.228 specifies the information element for qop, ad SIP digest (cnonce) 5. 3GPP ISIM TS 31.103 supports HTTP Digest Security context 6. 3GPP TS 34.229 IMS Registration Message contains qop and co nonce 7. CableLab’s PacketCable V2.0 standards added SIP-Digest-Authenticate mechanism to all the corresponding standards from 3GPP, e.g. PKT-SP-33.203- I02-061013 8. MultiService Forum Implementation Agreement for a MSFR3 SIP Server (MSF- IA-SIP.012-FINAL Aug 2006) mandates support at least either AKA or HTTP Digest, and SHOULD support both.

3. All Rights Reserved © Alcatel-Lucent 2007, ##### 3 | Presentation Title | January 2007 SIP RFC 3261  In the SIP RFC 3261, section 22.4: "The Digest Authentication Scheme", item 8 states: "RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including "MD5-Sess") require that the qop directive be sent. Use of the "qop" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the "qop" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a "qop" parameter in WWW-Authenticate and Proxy- Authenticate header field values. If a client receives a "qop" parameter in a challenge header field, it MUST send the "qop" parameter in any resulting authorization header field."

4. All Rights Reserved © Alcatel-Lucent 2007, ##### 4 | Presentation Title | January 2007 RFC 3310 HTTP Digest AKA “Even though AKA provides inherent mutual authentication with the AKA AUTN token, mutual authentication mechanisms provided by Digest may still be useful in order to provide message integrity.” 1) Initial request REGISTER sip:home.mobile.biz SIP/2.0 2) Response containing a challenge SIP/2.0 401 Unauthorized WWW-Authenticate: Digest realm="RoamingUsers@mobile.biz", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", qop="auth,auth-int", opaque="5ccc069c403ebaf9f0171e9517f40e41", algorithm=AKAv1-MD5 3) Request containing credentials REGISTER sip:home.mobile.biz SIP/2.0 Authorization: Digest username="jon.dough@mobile.biz", realm="RoamingUsers@mobile.biz", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", uri="sip:home.mobile.biz", qop=auth-int, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"

5. All Rights Reserved © Alcatel-Lucent 2007, ##### 5 | Presentation Title | January 2007 3GPP2 IMS Security Framework S.S0086 5.1.1 Authentication of the subscriber and the network The user’s subscription is authenticated by the S-CSCF (home service provider). The security association between the UE and the first access point into the operator’s network (P-CSCF) is negotiated based on the protocol defined in RFC 3329 [12]. The options that may be negotiated using [12] are: tls, digest [23], ipsec-ike, ipsec-man, and ipsec-3gpp. When the negotiated protocol is not ipsec-3gpp, sections 5 through 8 do not apply. In this case a method other than AKA may be used to authenticate the UE, e.g. an appropriate method from the SIP RFC [2].

6. All Rights Reserved © Alcatel-Lucent 2007, ##### 6 | Presentation Title | January 2007 3GPP Cx interface 3GPP TS 29.228 7Information element contents 7.9.7 Authentication Context This information element contains authentication-related information relevant for performing the authentication but that is not part of the SIP authentication headers. Some mechanisms (e.g. PGP, digest with quality of protection set to authint defined in IETF RFC 2617 [16], digest with predictive nonces or sip access digest) request that part or the whole SIP request (e.g. the SIP method) is passed to the entity performing the authentication. In such cases the SIPAuthentication-Context AVP shall be carrying such information.

7. All Rights Reserved © Alcatel-Lucent 2007, ##### 7 | Presentation Title | January 2007 3GPP ISIM TS 31.103 supports HTTP Digest Security context 7.1.2.2 HTTP Digest security context along with IMS AKA and GBA

8. All Rights Reserved © Alcatel-Lucent 2007, ##### 8 | Presentation Title | January 2007 3GPP TS 34.229 IMS Registration Message IMS Registration Message contains QOP and CNONCE fields

9. All Rights Reserved © Alcatel-Lucent 2007, ##### 9 | Presentation Title | January 2007 CableLab’s PacketCable V2.0 CableLab’s PacketCable V2.0 standards added SIP-Digest- Authenticate mechanism to all the corresponding standards from 3GPP, e.g. PKT- SP-33.203-I02-061013

10. All Rights Reserved © Alcatel-Lucent 2007, ##### 10 | Presentation Title | January 2007 MultiService Forum Implementation Agreement for a MSFR3 SIP Server (MSF-IA-SIP.012-FINAL Aug 2006)

11. All Rights Reserved © Alcatel-Lucent 2007, ##### 11 | Presentation Title | January 2007 Conclusion In conclusion, almost all the IMS standards support HTTP Digest already, therefore the mechanism to use cnonce is already supported by most IMS compliance equipment. HW's argument that ALU proposal needs additional development for SCSCF is not sound.