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

2. All Rights Reserved © Alcatel-Lucent 2007, ##### 2 | Presentation Title | January 2007 What is in the IMS standards 1. IETF RFC 3261 (SIP): mandates the qop, i.e., use of the cnonce; 2. IETF RFC 3310 (HTTP Digest AKA): recommends to use the digest mechanism (in addition to the AKA) for message integrity; 3. 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, and SIP digest (cnonce); 5. 3GPP ISIM TS 31.103: supports HTTP Digest Security context; 6. 3GPP IMS stage 3 TS 24.229: describes UE procedure when receiving digest calculated with cnonce; 7. 3GPP TS 34.229: IMS Registration Message contains qop and cnonce; 8. 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; 9. 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 7. Information 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 IMS TS 24.229 describes the procedure for UE 5.1.1.2 Initial Registration On receiving the 200 (OK) response to the REGISTER request, the UE shall: store the expiration time of the registration for the public user identities found in the To header value; b) store as the default public user identity the first URI on the list of URIs present in the P- Associated-URI header; NOTE 4:The UE can utilize additional URIs contained in the P-Associated-URI header, e.g. for application purposes. c) treat the identity under registration as a barred public user identity, if it is not included in the P-Associated-URI header; d) store the list of Service-Route headers contained in the Service-Route header, in order to build a proper preloaded Route header value for new dialogs and standalone transactions; e) set the security association lifetime to the longest of either the previously existing security association lifetime (if available), or the lifetime of the just completed registration plus 30 seconds; and NOTE 5: If the UE receives Authentication-Info, it will proceed as described in RFC 3310 

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

10. All Rights Reserved © Alcatel-Lucent 2007, ##### 10 | 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

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

12. All Rights Reserved © Alcatel-Lucent 2007, ##### 12 | Presentation Title | January 2007 Conclusion: turn qop on for replay protection  Existing IMS standards recommend to use qop mechanism to provide additional protection  Almost all the IMS standards support both, HTTP Digest and HTTP Digest AKA already. Therefore the mechanism to use cnonce is already supported by most IMS compliance equipment.  Turn on qop tag is only a provisional change for operator. There is no impact on the S-CSCF behavior baselined in “2G IMS Security based on R-UIM card”  Since the 2G IMS security relies on cnonce for replay protection, it is recommended that qop being turned on when the replay protection is desired.