All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Alec...

All Rights Reserved © Alcatel-Lucent 2006, #####

2G IMS CAVE Based Security

Replay Protection

Alec Brusilovsky, Zhibi Wang

Alcatel-Lucent, July 24, 2007

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.


SIP RFC 3261In 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."


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="[email protected]", 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="[email protected]", realm="[email protected]", nonce="CjPk9mRqNuT25eRkajM09uTl9nM09uTl9nMz5OX25PZz==", uri="sip:home.mobile.biz", qop=auth-int, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41"


3GPP2 IMS Security Framework S.S00865.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].


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.


3GPP ISIM TS 31.103 supports HTTP Digest Security context

7.1.2.2 HTTP Digest security context along with IMS AKA and GBA

EFIST (ISIM Service Table)

This EF indicates which optional services are available. If a service is not indicated as available in the ISIM, the ME shall not select this service. The presence of this file is mandatory if optional services are provided in the ISIM.

Identifier: '6F07' Structure: transparent Optional SFI: '07'

File size: X bytes, X >= 1 Update activity: low

Access Conditions: READ PIN UPDATE ADM DEACTIVATE ADM ACTIVATE ADM

Bytes Description M/O Length 1 Services n°1 to n°8 M 1 byte 2 Services n°9 to n°16 O 1 byte 3 Services n°17 to n°24 O 1 byte 4 Services n°25 to n°32 O 1 byte

etc. X Services n°(8X-7) to n°(8X) O 1 byte

-Services Contents: Service n°1: P-CSCF address Service n°2 Generic Bootstrapping Architecture (GBA) Service n°3 HTTP Digest


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


3GPP TS 34.229 IMS Registration Message

IMS Registration Message contains QOP and CNONCE fields

Authorization A2 username A2 px_PrivateUserIdentity (when using ISIM) or

private user identity derived from px_IMSI (when using USIM) realm A2 same value as received in the realm directive in the WWW

Authenticate header sent by SS nonce A2 same value as in WWW-Authenticate header sent by SS opaque A2 px_Opaque digest-uri A2 SIP URI formed from px_HomeDomainName qop-value A2 auth cnonce-value A2 value assigned by UE affecting the response calculation nonce-count A2 counter to indicate how many times UE has sent the same value of

nonce within successive REGISTERs, initial value shall be 1 response A2 response calculated by UE algorithm A2 AKAv1-MD5

RFC 2617 [16] RFC 3310 [17]


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


MultiService Forum

Implementation Agreement for a MSFR3 SIP Server (MSF-IA-SIP.012-FINAL Aug 2006)


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.

All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Alec...

Documents

Transcript of All Rights Reserved © Alcatel-Lucent 2006, ##### 2G IMS CAVE Based Security Replay Protection Alec...