3GPP2 S.S0086-B
Version: 2.0
Date: February 2008
IMS Security Framework
COPYRIGHT
3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner's name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner's documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.
S.S0086-B v2.0
EDITOR
Zhibi Wang Alcatel-Lucent
(630)713-8381 [email protected]
REVISION HISTORY
1.0 Initial Publication December 2005
2.0 Addressed TIA legal comments February 2008
(This page intentionally left blank)
S.S0086-B v2.0
1 2 3 CONTENTS 4 5 6 1 SCOPE ...... 1 7 8 2 REFERENCES...... 1 9 2.1 NORMATIVE REFERENCES ...... 1 10 NFORMATIVE EFERENCES 11 2.2 I R ...... 2 12 3 DEFINITIONS, SYMBOLS AND ABBREVIATIONS...... 2 13 14 3.1 DEFINITIONS...... 2 15 3.2 ABBREVIATIONS...... 3 16 4 OVERVIEW OF THE SECURITY ARCHITECTURE ...... 3 17 18 19 5 SECURITY FEATURES...... 6 20 5.1 SECURE ACCESS TO IMS...... 6 21 5.1.1 Authentication of the subscriber and the network...... 6 22 5.1.2 Re-Authentication of the subscriber ...... 7 23 5.1.3 Confidentiality protection...... 7 24 5.1.4 Integrity protection...... 7 25 ETWORK TOPOLOGY HIDING 26 5.2 N ...... 8 27 5.3 SIP PRIVACY HANDLING IN IMS NETWORKS ...... 8 28 5.4 SIP PRIVACY HANDLING WHEN INTERWORKING WITH NON-IMS NETWORKS...... 8 29 6 SECURITY MECHANISMS ...... 9 30 31 6.1 AUTHENTICATION AND KEY AGREEMENT ...... 9 32 6.1.1 Authentication of an IM-subscriber...... 9 33 6.1.2 Authentication failures ...... 12 34 6.1.2.1 User authentication failure ...... 12 35 6.1.2.2 Network authentication failure...... 13 36 6.1.2.3 Incomplete authentication ...... 14 37 6.1.3 Synchronization failure ...... 14 38 6.1.4 Network Initiated authentications ...... 15 39 6.1.5 Integrity protection indicator ...... 16 40 6.2 CONFIDENTIALITY MECHANISMS ...... 16 41 42 6.3 INTEGRITY MECHANISMS...... 16 43 6.4 HIDING MECHANISMS ...... 17 44 6.5 CSCF INTEROPERATING WITH PROXY LOCATED IN A NON-IMS NETWORK ...... 17 45 7 SECURITY ASSOCIATION SET-UP PROCEDURE...... 18 46 47 7.1 SECURITY ASSOCIATION PARAMETERS ...... 18 48 7.2 SET-UP OF SECURITY ASSOCIATIONS (SUCCESSFUL CASE)...... 22 49 7.3 ERROR CASES IN THE SET-UP OF SECURITY ASSOCIATIONS ...... 24 50 7.3.1 Error cases related to IMS AKA...... 24 51 7.3.1.1 User authentication failure ...... 24 52 7.3.1.2 Network authentication failure...... 25 53 7.3.1.3 Synchronisation failure...... 25 54 7.3.1.4 Incomplete authentication ...... 25 55 7.3.2 Error cases related to the Security-setup ...... 25 56 7.3.2.1 Proposal unacceptable to P-CSCF...... 25 57 58 7.3.2.2 Proposal unacceptable to UE...... 25 7.3.2.3 Failed consistency check of Security-setup lines at the P-CSCF ...... 25
i
S.S0086-B v2.0
1 2 7.4 AUTHENTICATED RE-REGISTRATION ...... 26 3 7.4.1 Void ...... 26 4 7.4.1a Management of security associations in the UE ...... 26 5 7.4.2 Void ...... 27 6 7.4.2a Management of security associations in the P-CSCF...... 27 7 7.5 RULES FOR SECURITY ASSOCIATION HANDLING WHEN THE UE CHANGES IP ADDRESS...... 28 8 9 8 SECURE MEMORY WITHIN UE ...... 29 10 8.1 REQUIREMENTS ON THE SECURE MEMORY OF AN IMS CAPABLE UE ...... 29 11 12 9 NETWORK DOMAIN SECURITY...... 30 13 14 9.1 INTER-DOMAIN SECURITY...... 30 15 9.2 INTRA-DOMAIN SECURITY ...... 30 16 9.3 PROFILES OF NETWORK DOMAIN SECURITY METHODS...... 30 17 9.3.1 Support of IPSec ESP...... 30 18 9.3.1.1 Support of ESP authentication and encryption ...... 31 19 9.3.2 Support of TLS ...... 31 20 ANNEX A (NORMATIVE): THE USE OF SECURITY MECHANISM AGREEMENT FOR SIP 21 SESSIONS (REF. [12]) FOR SECURITY MODE SET-UP...... 32 22 23 24 ANNEX B (NORMATIVE): KEY EXPANSION FUNCTIONS FOR IPSEC ESP ...... 34 25 26 ANNEX C (INFORMATIVE): RECOMMENDATIONS TO PROTECT THE IMS FROM UES 27 BYPASSING THE P-CSCF ...... 35 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
ii S.S0086-B v2.0
1 2 3 FOREWORD 4 5 This Technical Specification has been produced by the 3rd Generation Partnership Project 2 (3GPP2) based 6 on “3rd Generation Partnership Project (3GPP); Technical Specification Group Services and System 7 Aspects; 3G Security; Access security for IP-based services (Release 5)”, TS 33.203 v5.4.0. 8 9 This document contains portions of material copied from 3GPP document number(s) TS 33.203. The 10 copyright on the 3GPP document is owned by the Organizational Partners of 3GPP (ARIB - Association of 11 Radio Industries and Businesses, Japan; CCSA – China Communications Standards Association; ETSI – 12 European Telecommunications Standards Institute; Committee T1, USA; TTA - Telecommunications 13 Technology Association, Korea; and TTC – Telecommunication Technology Committee, Japan), which 14 have granted license for reproduction and for use by 3GPP2 and its Organizational Partners. 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
iii
S.S0086-B v2.0
1 2 3 4 1 Scope 5 6 This document addresses the access and network security for IP-based services. 7 8 The scope for this document is to specify the security features and mechanisms for secure access to the IM 9 subsystem (IMS) for the 3G mobile telecommunication system. 10 11 The IMS supports IP Multimedia applications such as video, audio and multimedia conferences using SIP, 12 Session Initiation Protocol, as the signaling protocol for creating and terminating Multimedia sessions, 13 cf. [2]. This document only deals with how the SIP signaling is protected between the subscriber and the 14 IMS, how the subscriber is authenticated and how the subscriber authenticates the IMS. 15 16 17 18 2 References 19 20 The following documents contain provisions which, through reference in this text, constitute provisions of 21 the present document. 22 23 • References are either specific (identified by date of publication, edition number, version number, 24 etc.) or non-specific. 25 26 • For a specific reference, subsequent revisions do not apply. 27 28 • For a non-specific reference, the latest version applies. 29 30 2.1 Normative References 31 32 [1] 3GPP TS 33.102, "3rd Generation Partnership Project; Technical Specification Group Services and 33 System Aspects; 3G Security; Security Architecture". 34 35 [2] IETF RFC 3261, "SIP: Session Initiation Protocol". 36 37 [3] 3GPP2 X.S0013-004, "All-IP Core Network Multimedia Domain: IP Multimedia Call Control 38 Protocol Based on SIP and SDP Stage 3". 39 40 [4] IETF RFC 2406 (1998), "IP Encapsulating Security Payload (ESP)". 41 42 [5] IETF RFC 2401 (1998), "Security Architecture for the Internet Protocol". 43 44 [6] IETF RFC 2403 (1998), "The Use of HMAC-MD5-96 within ESP and AH". 45 46 [7] IETF RFC 2404 (1998), "The Use of HMAC-SHA-1-96 within ESP and AH". 47 48 [8] IETF RFC 3310 (2002), "HTTP Digest Authentication Using AKA". 49 50 [9] IETF RFC 2402 (1998), "IP Authentication Header". 51 52 [10] IETF RFC 2405 (1998), "The ESP DES-CBC Cipher Algorithm With Explicit IV". 53 [11] IETF RFC 2406 (1998), "IP Encapsulating Security Payload (ESP)". 54 55 [12] IETF RFC 3329 (2002), "Security Mechanism Agreement for the Session Initiation Protocol (SIP)". 56 57 [13] 3GPP2 X.S0011, " cdma2000 Wireless IP Network Standard". 58 [14] IETF RFC 2409 (1998), "Internet Key Exchange (IKE)".
1 S.S0086-B v2.0
1 2 [15] IETF RFC 2451 (1998), "The ESP CBC-Mode Cipher Algorithms". 3 4 [16] IETF RFC 3602 (2003), "The AES-CBC Cipher Algorithm and Its Use with IPsec". 5 [17] IETF RFC 2407 (1998), "The Internet IP Security Domain of Interpretation for ISAKMP". 6 7 [18] IETF RFC 2408 (1998), "Internet Security Association and Key Management Protocol (ISAKMP)". 8 9 [19] IETF RFC 2246 (1999), "The TLS Protocol Version 1.0". 10 11 [20] IETF RFC 3268 (2002), "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer 12 Security (TLS)". 13 14 [21] 3GPP2 C.S0023, "Removable User Identity Module for Spread Spectrum Systems". 15 16 [22] 3GPP2 C.S0069, "ISIM Application on UICC for Spread Spectrum Systems". 17 18 [23] IETF RFC 2617 (1999), "HTTP Authentication: Basic and Digest Access Authentication". 19 20 21 22
23 24 2.2 Informative References 25 26 [24] 3GPP2 X.S0013-002, "All-IP Core Network Multimedia Domain: IP Multimedia Subsystem – Stage 27 2". 28 29 [25] 3GPP2 S.R0037, "IP Network Architecture Model for cdma2000 Spread Spectrum Systems". 30 31 [26] IETF RFC 3041 (2001), "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". 32 33 [27] IETF RFC 3263 (2002), "Session Initiation Protocol (SIP): Locating SIP Servers". 34 35 [28] IETF RFC 3323 (2002), "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 36 [29] IETF RFC 3325 (2002), "Private Extensions to the Session Initiation Protocol (SIP) for Asserted 37 Identity within Trusted Networks". 38 39 40 41 42 43 44 45 3 Definitions, symbols and abbreviations 46 47 48 49 3.1 Definitions 50 51 For the purposes of the present document, the following terms and definitions apply. 52 53 Authenticated (re-) registration: A registration i.e. a SIP register is sent towards the Home Network 54 which will trigger an authentication of the IMS subscriber i.e. a challenge is generated and sent to the UE. 55 56 Confidentiality: The property that information is not made available or disclosed to unauthorized 57 individuals, entities or processes. 58
Data integrity: The property that data has not been altered in an unauthorized manner.
2 S.S0086-B v2.0
1 2 Data origin authentication: The corroboration that the source of data received is as claimed. 3 Entity authentication: The provision of assurance of the claimed identity of an entity. 4 5 Key freshness: A key is fresh if it can be guaranteed to be new, as opposed to an old key being reused 6 through actions of either an adversary or authorized party. 7 8 Security Domain: Networks that are managed by a single administrative authority. Within a security 9 domain the same level of security and usage of security services will be typical. 10 11 12 13 14 15 16 17 3.2 Abbreviations 18 For the purposes of the present document, the following abbreviations apply: 19 20 AAA Authentication Authorization Accounting 21 AKA Authentication and key agreement 22 CSCF Call Session Control Function 23 HSS Collective Home Subscriber Server equivalent to AAA plus Databases 24 25 IM IP Multimedia 26 IMPI IM Private Identity 27 IMPU IM Public Identity 28 IMS IP Multimedia Core Network Subsystem 29 LMSD Legacy MS Domain 30 MAC Message Authentication Code 31 MMD Multi-Media Domain 32 MS Mobile Station 1 33 PDS Packet Data Subsystem (cdma2000® PDSN-based) 34 PDSN Packet Data Serving Node 35 R-UIM Removable User Identity Module 36 SA Security Association 37 SEG Security Gateway 38 39 SDP Session Description Protocol 40 SIP Session Initiation Protocol 41 SIP AS SIP Application Server 42 UA User Agent 43 UE User Equipment (equivalent to MS) 44 . 45 46 47 48 49 4 Overview of the security architecture 50 51 In the MMD, service is not provided until a security association is established between the mobile 52 equipment and the network. IMS is essentially an overlay to the PDS and has a low dependency on the 53 PDS. PDS can be deployed without the multimedia session capability. Consequently a separate security 54 55 56 ® 57 1 cdma2000 is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners ® 58 (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000 is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.
3 S.S0086-B v2.0
1 2 association is required between the multimedia client and the IMS before access is granted to multimedia 3 services. The IMS Security Framework is shown in Figure 1. 4 5 IMS authentication keys and functions at the user side may be stored in some secure memory location on 6 an UE. It shall be possible for the IMS authentication keys and functions to be logically independent to the 7 keys and functions used for PDS authentication. However, this does not preclude common authentication 8 keys and functions from being used for IMS and PDS authentication according to the guidelines given in 9 section 8. 10 11 The IMS Security Framework also addresses the security of interfaces between the IMS and external 12 network domains, for example Multimedia IP-Networks as shown in Figure 1. This is important since the 13 service capability subsystem of the MMD includes application servers that reside on untrusted third-party 14 networks, and which can access network functionality. 15 16 17 18 19 20 21 IMS 22 UE 23 Home Network 24 Secure 25 1 HSS Mem 6 26 27 3 3 28 29 30 5 Multimedia I -CSCF S-CSCF IP- Networks 31 7 32 4/5 4/5 33 34 35 Home/Serving Nt k 36 UA 2 P- CSCF 37 38 39 40
Transport 41 42 ® cdma2000 Packet Data Subsystem 43 Radio AN 44 Access 45 46 47 48 Figure 1: The IMS security architecture 49 50 There are seven different security associations and different needs for security protection for IMS 51 (including SIP AS nodes) and they are numbered 1 through 7 in Figure 1. 52 53 1. Provides mutual authentication between the UE and the S-CSCF. The HSS collective (comprising of 54 the AAA and the associated Databases, also referenced in this document as the “HSS”) delegates the 55 56 performance of subscriber authentication to the S-CSCF. However the HSS is responsible for 57 generating keys and challenges. The long-term key in the secure memory of the UE and the HSS is 58 associated with the user private identity (IMPI). The UE will have one (network internal) user private identity (IMPI) and at least one external user public identity (IMPU).
4 S.S0086-B v2.0
1 2 2. Provides a secure link and a security association between the UE and a P-CSCF for protection of the 3 Gm reference point. Data origin authentication is provided i.e. the corroboration that the source of 4 data received is as claimed. For the definition of the Gm reference point cf. [25]. 5 6 3. Provides security within the network domain internally for the Cx-interface. This security 7 association is covered in section 9. For the definition of the Cx-interface cf. [25]. 8 9 4. Provides security between different networks for SIP capable nodes. This security association is 10 covered in section 9. This security association is only applicable when the P-CSCF resides in the 11 Visited Network (VN). If the P-CSCF resides in the Home Network (HN) then bullet point number 12 five below applies. 13 14 5. Provides security within the network internally within the IMS subsystem between SIP capable 15 nodes. This security association is covered in section 9. Note that this security association also 16 applies when the P-CSCF resides in the HN. 17 18 6. Provides security between a SIP-capable node residing in an external IP network, and the HSS. This 19 security association is covered in section 9. The SIP-capable node is a SIP Application Server and 20 may also reside within the HN. However, SA6 is only applicable when the SIP AS resides in an 21 external IP network. If the SIP AS resides in the Home Network, then bullet point three above 22 applies. 23 24 7. Provides security between SIP-capable nodes located in different networks. It differs from security 25 association 4 in that the SIP-capable node here is the SIP Application Server. Using SIP, this type 26 of application server may communicate with network entities to offer service control and content, 27 access functionality provided in the operator’s network, and manage bearers. This security 28 association is covered in section 9. It is only applicable when the SIP AS resides in an external IP 29 network. If the SIP AS resides in the Home Network, then bullet point five above applies. 30 31 32 33 There may exist other interfaces and reference points in IMS, which have not been addressed above. Those 34 interfaces and reference points reside within the IMS, either within the same security domain or between 35 different security domains. This document assumes that the IP MMD core network supports secure 36 communications via standard IETF protocols [5]. Section 9 is intended to address security issues for all 37 such interfaces. 38 39 Mutual authentication is required between the UE and the HN. 40 41 The mechanisms specified in this document are independent of the mechanisms defined for the Legacy MS 42 Domain (LMSD) and Packet Data Subsystem (PDS). 43 44 An independent IMS security mechanism provides additional protection against security breaches. For 45 example, if the PDS security is breached the IMS would continue to be protected by its own security 46 mechanism. As indicated in Figure 1 the P-CSCF may be located either in the Visited or the Home 47 Network. 48 49 The confidentiality and integrity protection for SIP-signaling is provided in a hop-by-hop fashion. The first 50 hop i.e. between the UE and the P-CSCF is specified in the section 5 to 8 of this document. The other hops, 51 inter-domain and intra-domain are specified in section 9. 52 53 54 55 56 57 58
5 S.S0086-B v2.0
1 2 3 5 Security features 4 5 6 5.1 Secure access to IMS 7 8 9 5.1.1 Authentication of the subscriber and the network 10 11 The user’s subscription is authenticated by the S-CSCF (home service provider). The security association 12 between the UE and the first access point into the operator’s network (P-CSCF) is negotiated based on the 13 protocol defined in RFC 3329 [12]. The options that may be negotiated using [12] are: tls, digest [23], 14 ipsec-ike, ipsec-man, and ipsec-3gpp. When the negotiated protocol is not ipsec-3gpp, sections 5 through 8 15 do not apply. In this case a method other than AKA may be used to authenticate the UE, e.g. an appropriate 16 method from the SIP RFC [2]. 17 18 Authentication between the subscriber and the network shall be performed as specified in section 6.1. 19 20 An IM-subscriber will have its subscriber profile located in the HSS in the Home Network. The subscriber 21 profile will contain information on the subscriber that may not be revealed to an external partner, cf. [24]. 22 At registration an S-CSCF is assigned to the subscriber by the I-CSCF. The subscriber profile will be 23 downloaded to the S-CSCF over the Cx-reference point from the HSS (Cx-Pull). When a subscriber 24 requests access to the IP Multimedia Core Network Subsystem this S-CSCF will check, by matching the 25 request with the subscriber profile, if the subscriber is allowed to continue with the request or not i.e. Home 26 Control (Authorization of IM-services). 27 28 All SIP-signaling will take place over the MMD i.e. IP Multimedia Core Network Subsystem is essentially 29 an overlay to the PDS. Hence the Visited Network will have control of all the subscribers in the PDS i.e. 30 Visited Control (Authorization of bearer resources) since the Visited Network provides the subscriber with 31 32 a transport service and its associated QoS. 33 For IM-services a new security association is required between the mobile and the IMS before access is 34 granted to IM-services. 35 36 The mechanism for mutual authentication in cdma2000 is called AKA. It is a challenge response protocol 37 and in cdma2000 the authentication center in the Home System derives the challenge. An Authentication 38 Vector containing the challenge is sent from the Home Stratum to the Serving Network. The Authentication 39 40 Vector contains the expected response XRES and also a message authentication code MAC. The Serving 41 Network compares the response from the UE with the XRES and if they match the UE has been 42 authenticated. The UE calculates an expected MAC, XMAC, and compares this with the received MAC 43 and if they match the UE has authenticated the network. 44 45 The AKA-protocol is a secure protocol developed for UMTS and the same concept/principles may be 46 reused for the IP Multimedia Core Network Subsystem, where it is called IMS AKA. One specific 47 characteristic of the IMS AKA procedure is that the UE is authenticated for IMS services only by the Home 48 Network, and not by the Serving Network. 49 50 NOTE 1: Although the method of calculating the parameters in cdma2000 AKA and IMS AKA 51 are identical, the parameters are transported in slightly different ways. In cdma2000, the 52 UE’s response RES is sent in the clear, while in IMS RES is not sent in the clear but 53 combined with other parameters to form an authentication response and authentication 54 response is sent to the network (as described in [8]). 55 56 The Home Network authenticates the subscriber at anytime via the registration or re-registration 57 procedures. 58
6 S.S0086-B v2.0
1 2 5.1.2 Re-Authentication of the subscriber 3 4 Initial registration shall always be authenticated. It is the policy of the operator that decides when to trigger 5 a re-authentication by the S-CSCF. Hence a re-registration might not need to be authenticated2. 6 7 A SIP REGISTER message, which has not been integrity protected at the first hop, shall be considered as 8 initial registration. 9 10 The S-CSCF shall also be able to initiate an authenticated re-registration of a user at any time, independent 11 of previous registrations. 12 13 14 5.1.3 Confidentiality protection 15 16 Possibility for IMS specific confidentiality protection shall be provided to SIP signaling messages between 17 the UE and the P-CSCF. Mobile Operators shall take care that the deployed confidentiality protection 18 solution and roaming agreements fulfils the confidentiality requirements presented in the local privacy 19 legislation. The following mechanism is provided at SIP layer: 20 21 The UE shall always offer encryption algorithms for P-CSCF to be used for the session, as specified in 22 section 7. 23 24 The P-CSCF shall decide whether the IMS specific encryption mechanism is used. If used, the UE and the 25 P-CSCF shall agree on security associations, which include the encryption key that shall be used for the 26 confidentiality protection. The mechanism is based on IMS AKA and specified in section 6.1. 27 28 Confidentiality between CSCFs, and between CSCFs and the HSS shall rely on mechanisms specified in 29 section 9 and [13]. 30 31 32 5.1.4 Integrity protection 33 Integrity protection shall be applied between the UE and the P-CSCF for protecting the SIP signaling, as 34 35 specified in section 6.3 whenever an SA exists. The following mechanisms are provided. 36 1. The UE and the P-CSCF shall negotiate the integrity algorithm/mechanism to be used for a 37 particular session, as specified in section 7 (based on [12]). 38 39 2. The UE and the P-CSCF shall agree on security associations, which include the integrity keys that 40 shall be used for the integrity protection. The integrity key shall be the IK, delivered by the S-CSCF 41 to the P-CSCF during the user’s IMS authentication process (component of the AKA Authentication 42 43 Vector), as specified in section 6.1. 44 3. The UE and the P-CSCF shall both verify that the data received originates from a node, which has 45 46 the agreed integrity key. This verification is also used to detect if the data has been tampered with. 47 4. Replay attacks and reflection attacks should be mitigated. 48 49 Integrity protection between CSCFs, and between CSCFs and the HSS shall rely on mechanisms specified 50 by Network Domain Security in section 9. 51 52 NOTE 1: TLS is mandatorily supported by SIP proxies according to RFC 3261 [2]. Operators 53 may use it to provide confidentiality and integrity inside their networks instead of or on 54 top of IPSec. TLS may also be used between IMS networks on top of IPSec. It should 55 be pointed out that the cdma2000 documents do not provide support for TLS certificate 56 57 58 2 Here, “authentication” refers to the AKA procedure. Integrity protection is always used for Registration messages when a security association exists.
7 S.S0086-B v2.0
1 2 management nor do they ensure backward compatibility with CSCFs from earlier 3 revisions nor interoperability with other networks which do not use TLS, in case TLS is 4 used by Rev-A CSCFs. These management and compatibility issues need then to be 5 solved by manual configuration of the involved operators. 6 7 8 5.2 Network topology hiding 9 10 The operational details of an operator's network are sensitive business information that operators are 11 reluctant to share with their competitors. While there may be situations (partnerships or other business 12 relations) where the sharing of such information is appropriate, the possibility should exist for an operator 13 to determine whether or not the topology of its network needs to be hidden. 14 15 It shall be possible to hide the network topology from other operators, which includes the hiding of the 16 number of S-CSCFs, the capabilities of the S-CSCFs and the capability of the network. 17 18 To achieve network hiding, the I-CSCF shall have the capability to encrypt the address of an S-CSCF in 19 SIP Via, Record-Route, Route and Path headers and then decrypt the address when handling the response 20 to a request. The P-CSCF may receive routing information that is encrypted but the P-CSCF will not have 21 the key to decrypt this information. 22 23 The mechanism shall support the scenario that different I-CSCFs in the Home Network may encrypt and 24 decrypt the address of the S-CSCFs. 25 26 27 5.3 SIP Privacy handling in IMS Networks 28 29 Privacy may in many instances be equivalent with confidentiality i.e., to hide the information (using 30 31 encryption and encryption keys) from all entities except those who are authorized to understand the 32 information. The SIP Privacy Extensions for IMS Networks do not provide such confidentiality. The 33 purpose of the mechanism is rather to give an IMS subscriber the possibility to withhold certain identity 34 information of the subscriber as specified in RFC 3323 [28] and RFC 3325 [29]. 35 36 NOTE 1: It is useful that the privacy mechanism for IMS networks does not create states in the 37 CSCFs other than the normal SIP states. 38 39 40 5.4 SIP Privacy handling when interworking with non-IMS 41 42 Networks 43 44 When a Rev-A IMS is interworking with a non-IMS network, the CSCF in the IMS network shall decide 45 the trust relation with the other end. The other end is trusted when the security mechanism for the 46 interworking (cf. section 6.5) is applied as well as the availability of an inter-working agreement. If the 47 interworking non-IMS network is not trusted, the privacy information shall be removed from the traffic 48 towards this non-IMS network (i.e. the P-Asserted-Identity). When receiving SIP signaling, the CSCF shall 49 also verify if any privacy information is already contained. If the interworking non-IMS network is not 50 trusted, the information shall be removed by the CSCF, and retained otherwise. 51 52 Because absence of the security mechanism for the interworking (cf. section 6.5) indicates an untrusted 53 non-IMS network, separate CSCFs are usually needed to interface with IMS and non-IMS networks. The 54 CSCF interfacing with IMS networks implicitly trusts all IMS networks reachable according to section 9.1. 55 The S-CSCF trust setting shall be a configurable option that an operator can set according to his network 56 and interface configuration. 57 58
8 S.S0086-B v2.0
1 2 3 6 Security Mechanisms 4 5 The security mechanism agreement is based on [12]. [12] defines a negotiation mechanism between the 6 UE and its first-hop SIP entry, the P-CSCF. It also provides protection against Man-in-the-Middle attack 7 by allowing the peers to detect if the initial, unprotected offer has been tampered with. cdma2000 IMS 8 shall support ipsec-3gpp as described below (conforming to recommendation [12] appendix A). 9 10 11 6.1 Authentication and key agreement 12 13 The scheme used for authentication and key agreement in the IMS is called IMS AKA. The IMS AKA 14 achieves mutual authentication between the UE and the Home Network (HN), cf. Figure 1. The identity 15 used for authenticating a subscriber is the private identity, IMPI, which has the form of a NAI, cf. [24]. The 16 HSS and the UE share a long-term key associated only with the IMPI, not with an IM public identity 17 (IMPU). 18 19 The HN shall use the IMS AKA scheme for authenticating an IM subscriber. The security parameters e.g. 20 keys generated by the IMS AKA scheme are transported by SIP. 21 22 The generation of the authentication vector AV that includes RAND, XRES, CK, IK and AUTN shall be 23 done in the same way as specified in [1]. The UE and the HSS keep track of their respective IMS specific 24 SQN counters. The requirements on the handling of the counters and mechanisms for sequence number 25 management are specified in [1]. The AMF field can be used in the same way as in [1]. 26 27 Furthermore two pairs of (unilateral) security associations (SAs) are established between the UE and the P- 28 CSCF. The subscriber may have several IMPUs associated with one IMPI. These may belong to the same 29 or different service profiles. Only two pairs of SAs shall be active between the UE and the P-CSCF. These 30 two pairs of SAs shall be updated when a new successful authentication of the subscriber has occurred, cf. 31 32 section 7.4. 33 It is the policy of the HN that decides if an authentication shall take place for the registration of different 34 IMPUs e.g. belonging to same or different service profiles. Regarding the definition of service profiles cf. 35 36 [24]. The registration process may be done without key distribution and exchange process. However, for 37 certain implementations, it may also be acceptable to combine the registration and key distribution such 38 that keying material would be made available during the combined registration and authentication process. 39 40 41 6.1.1 Authentication of an IM-subscriber 42 Before a user can get access to the IM services at least one IMPU needs to be registered and the IMPI 43 authenticated in the IMS at application level. In order to get registered the UE sends a SIP REGISTER 44 45 message towards the SIP registrar server i.e. the S-CSCF, cf. Figure 1, which will perform the 46 authentication of the user. The message flows are the same regardless of whether the user has an IMPU 47 already registered or not. 48 49 50 51 52 53 54 55 56 57 58
9 S.S0086-B v2.0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 Figure 2: The IMS Authentication and Key Agreement for an unregistered IM subscriber and 28 successful mutual authentication with no synchronization error 29 30 The detailed requirements and complete registration flows are defined in [3]. 31 32 SMn stands for SIP Message n and CMm stands for Cx message m which has a relation to the 33 authentication process: 34 35 SM1: 36 REGISTER(IMPI, IMPU) 37 38 39 In SM2 and SM3 the P-CSCF and the I-CSCF respectively forwards the SIP REGISTER towards the S- 40 CSCF. 41 42 After receiving SM3, if the IMPU is not currently registered at the S-CSCF, the S-CSCF needs to set the 43 registration flag at the HSS to initial registration pending. This is done in order to handle mobile terminated 44 calls while the initial registration is in progress and not successfully completed. The registration flag is 45 stored in the HSS together with the S-CSCF name and user identity, and is used to indicate whether a 46 particular IMPU of the user is unregistered or registered at a particular S-CSCF or if the initial registration 47 at a particular S-CSCF is pending. The registration flag is set by the S-CSCF sending a Cx-Put to the HSS. 48 If the IMPU is currently registered, the S-CSCF shall leave the registration flag set to registered. At this 49 stage the HSS has performed a check that the IMPI and the IMPU belong to the same user. 50 51 Upon receiving the SIP REGISTER the S-CSCF shall use an Authentication Vector (AV) for 52 authenticating and agreeing on a key with the user. If the S-CSCF has no valid AV then the S-CSCF shall 53 send a request for AV(s) to the HSS in CM1 together with the number m of AVs wanted where m is at least 54 one. 55 56 57 58
10 S.S0086-B v2.0
1 CM1: 2 Cx-AV-Req(IMPI, m) 3 4 5 6 Upon receipt of a request from the S-CSCF, the HSS sends an ordered array of n authentication vectors to 7 the S-CSCF using CM2. The authentication vectors are ordered based on sequence number. Each 8 authentication vector consists of the following components: a random number RAND, an expected 9 response XRES, a cipher key CK, an integrity key IK and an authentication token AUTN. Each 10 authentication vector is good for one authentication and key agreement between the S-CSCF and the IMS 11 user. 12 13 CM2: 14 Cx-AV-Req-Resp(IMPI, RAND1||AUTN1||XRES1||CK1||IK1,….,RANDn||AUTNn||XRESn||CKn||IKn) 15 16 17 18 When the S-CSCF needs to send an authentication challenge to the same user, it selects the next 19 authentication vector from the ordered array, i.e. authentication vectors in a particular S-CSCF are used on 20 a first-in / first-out basis. 21 22 The S-CSCF sends a SIP 4xx Auth_Challenge i.e. an authentication challenge towards the UE including 23 the challenge RAND and the authentication token AUTN in SM4. It also includes the integrity key IK and 24 the cipher key CK for the P-CSCF. RFC 3310 [8] specifies how to populate the parameters of an 25 authentication challenge. The S-CSCF also stores the RAND sent to the UE for use in case of a 26 synchronization failure. 27 28 The verification of the SQN by the UE will cause the UE to reject an attempt by the S-CSCF to re-use an 29 AV. Therefore no AV shall be sent more than once. 30 31 NOTE 1: This does not preclude the use of the normal SIP transaction layer re-transmission 32 procedures. 33 34 35 36 SM4: 37 4xx Auth_Challenge(IMPI, RAND, AUTN, IK, CK) 38 39 40 41 When the P-CSCF receives SM5 it shall store the key(s) and remove that information and forward the rest 42 of the message to the UE i.e. 43 44 SM6: 45 4xx Auth_Challenge(IMPI, RAND, AUTN) 46 47 48 As part of the challenge (SM6) the UE receives AUTN, which includes a MAC and the SQN. The UE 49 calculates the XMAC and checks that XMAC=MAC, and then checks if the SQN is in the correct range as 50 in [1]. If both these checks are successful the UE uses RES and some other parameters to calculate an 51 authentication response. The response is put into the Authorization header and sent back to the registrar in 52 SM7. RFC 3310 [8] specifies how to populate the parameters of the response. It should be noted that the 53 UE at this stage also computes the session keys CK and IK. 54 55 SM7: 56 REGISTER(IMPI, Authentication response) 57 58
11 S.S0086-B v2.0
1 2 The P-CSCF forwards the authentication response in SM8 to the I-CSCF, which queries the HSS to find 3 the address of the S-CSCF. In SM9 the I-CSCF forwards the authentication response to the S-CSCF. 4 5 Upon receiving SM9 containing the response, the S-CSCF retrieves the active XRES for that user and uses 6 this to check the authentication response sent by the UE as described in RFC 3310 [8]. If the check is 7 successful then the user has been authenticated and the IMPU is registered in the S-CSCF. If the IMPU was 8 not currently registered, the S-CSCF shall send a Cx-Put to update the registration-flag to registered. If the 9 IMPU was currently registered the registration-flag is not altered. 10 11 It shall be possible to implicitly register IMPU(s), cf. section 4.3.3.4 in [24]. All the IMPU(s) being 12 implicitly registered shall be delivered by the HSS to the S-CSCF and subsequently to the P-CSCF. The S- 13 CSCF shall regard all implicitly registered IMPU(s) as registered IMPU(s). 14 15 When an IMPU has been registered this registration will be valid for some period of time. Both the UE and 16 the S-CSCF will keep track of a timer for this purpose but the expiration time in the UE is smaller than the 17 one in the S-CSCF in order to make it possible for the UE to be registered and reachable without 18 interruptions. A successful registration of a previously registered IMPU (including implicitly registered 19 IMPUs) means the expiry time of the registration is refreshed. 20 21 If the user has been successfully authenticated, the S-CSCF sends a SM10 SIP 2xx Auth_OK message to 22 the I-CSCF indicating that the registration was successful. In SM11 and SM12 the I-CSCF and the P-CSCF 23 respectively forward the SIP 2xx Auth_OK towards the UE. 24 25 26 27 It should be noted that the UE initiated re-registration opens up a potential denial-of-service attack. That is, 28 an attacker could try to register an already registered IMPU and respond with an incorrect authentication 29 response in order to make the HN de-register the IMPU. For this reason a subscriber should not be de- 30 registered if it fails an authentication. It shall be defined by the policy of the operator when successfully 31 registered IMPU(s) are to be de-registered. 32 33 The lengths of the Authentication Vector parameters are specified in section 6.3.7 in [1]. 34 35 36 6.1.2 Authentication failures 37 38 6.1.2.1 User authentication failure 39 40 In this case the authentication of the user should fail at the S-CSCF because of an incorrect response 41 (received in SM9). However, if the response is incorrect, then the IK used to protect SM7 will normally be 42 incorrect as well, which will normally cause the integrity check at the P-CSCF to fail. In this case SM7 is 43 discarded by the IPsec layer at the P-CSCF, therefore SM9 does not reach the S-CSCF. If the integrity 44 45 check passes but the response is incorrect, the message flows are identical up to and including SM9 as a 46 successful authentication. Once the S-CSCF detects the user authentication failure it should proceed in the 47 same way as having received SM9 in a network authentication failure (see section 6.1.2.2). 48 49 50 51 52 53 54 55 56 57 58
12 S.S0086-B v2.0
1 2 6.1.2.2 Network authentication failure 3 4 In this section the case when the authentication of the network is not successful is specified. When the 5 check of the MAC in the UE fails the network cannot be authenticated and hence registration fails. The 6 flow is identical as for the successful registration in 6.1.1 up to SM6, as shown in Figure 3. 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 Figure 3: The IMS Authentication and Key Agreement with network authentication error. 34 35 36 The UE shall send a Register message towards the HN including an indication of the cause of failure in 37 SM7. The P-CSCF and the I-CSCF forward this message to the S-CSCF. 38 SM7: 39 REGISTER(Failure = AuthenticationFailure, IMPI) 40 41 42 Upon receiving SM9, which includes the cause of authentication failure, the S-CSCF shall set the 43 registration-flag in the HSS to unregistered, if the IMPU is not currently registered. To set the flag the S- 44 CSCF sends in CM3 a Cx-Put to the HSS. If the IMPU is currently registered, the S-CSCF does not update 45 46 the registration flag. 47 CM3: 48 Cx- Put(IMPI, Clear S-CSCF name) 49 50 51 52 The HSS responds to CM3 with a Cx-Put-Resp in CM4. 53 54 In SM10 the S-CSCF sends a 4xx Auth_Failure towards the UE indicating that authentication has failed, no 55 security parameters shall be included in this message. 56 57 58
13 S.S0086-B v2.0
1 2 SM10: 3 SIP/2.0 4xx Auth_Failure 4 5 6 7 6.1.2.3 Incomplete authentication 8 9 When the S-CSCF receives a new REGISTER request and challenges this request, it considers any 10 previous authentication to have failed. It shall delete any information relating to the previous 11 authentication, although the S-CSCF may send a response if the previous challenge is answered. A 12 challenge to the new request proceeds as described in section 6.1.1. 13 14 If the S-CSCF does not receive a response to an authentication challenge within an acceptable time, it 15 considers the authentication to have failed. If the IMPU was not already registered, the S-CSCF shall send 16 a Cx-Put to the HSS to set the registration-flag for that IMPU to unregistered (see message CM3 in 17 section 6.1.2.2). If the IMPU was already registered, the S-CSCF does not change the registration-flag. 18 19 20 6.1.3 Synchronization failure 21 22 In this section the case of an authenticated registration with synchronization failure is described. After re- 23 synchronization, authentication may be successfully completed, but it may also happen that in subsequent 24 attempts other failure conditions (i.e. user authentication failure, network authentication failure) occur. In 25 the message flow in Figure 4, only the case of synchronization failure with subsequent successful 26 authentication is shown. The other cases can be derived by combination with the flows for the other failure 27 conditions. 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 Figure 4: The IMS Authentication and Key Agreement with synchronization failure. 56 57 The flow equals the flow in 6.1.1 up to SM6. When the UE receives SM6 it detects that the SQN is out of 58 range and sends a synchronization failure back to the S-CSCF in SM7. RFC 3310 [8] describes the fields to populate corresponding parameters of synchronization failure.
14 S.S0086-B v2.0
1 SM7: 2 REGISTER(Failure = Synchronization Failure, AUTS, IMPI) 3 4 5 Upon receiving the Synchronization Failure and the AUTS the S-CSCF sends an AV-Req to the HSS in 6 CM3 including the RAND stored by the S-CSCF and the required number of AVs, m. 7 8 CM3: 9 AV-Req(IMPI, RAND,AUTS, m) 10 11 12 13 The HSS checks the AUTS as in section 6.3.5 in [1]. After potentially updating the SQN, the HSS sends 14 new AVs to the S-CSCF in CM4. 15 16 17 CM4: 18 AV-Req-Resp(IMPI, n,RAND1||AUTN1||XRES1||CK1||IK1,….,RANDn||AUTNn||XRESn||CKn||IKn) 19 20 21 When the S-CSCF receives the new batch of authentication vectors from the HSS it deletes the old ones for 22 that user in the S-CSCF. 23 24 The rest of the messages i.e. SM10-SM18 including the Cx messages are exactly the same as SM4-SM12 25 and the corresponding Cx messages in 6.1.1. 26 27 28 6.1.4 Network Initiated authentications 29 30 In order to authenticate an already registered user, the S-CSCF shall send a request to the UE to initiate a 31 re-registration procedure. When received at the S-CSCF, the re-registration shall trigger a new IMS AKA 32 procedure that will allow the S-CSCF to re-authenticate the user, as shown in Figure 5. 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 Figure 5: The IMS Authentication and Key Agreement with network initiated 55 authentications. 56 57 The UE shall initiate the re-registration on the reception of the Authentication Required indication. In the 58 event that the UE does not initiate the re-registration procedure after the request from the S-CSCF, the S- CSCF may decide to de-register the subscriber or re-issue an Authentication-Required.
15 S.S0086-B v2.0
1 2 6.1.5 Integrity protection indicator 3 4 In order to decide whether a REGISTER request from the UE needs to be authenticated, the S-CSCF needs 5 to know about the integrity protection applied to the message. The P-CSCF attaches an indication to the 6 REGISTER request to inform the S-CSCF that the message was integrity protected if: 7 8 - the P-CSCF receives a REGISTER containing an authentication response and the message is 9 protected with an SA created during this authentication procedure; or 10 11 - the P-CSCF receives a REGISTER not containing an authentication response and the message is 12 protected with an SA created by latest successful authentication (from the P-CSCF perspective). 13 14 For all other REGISTER requests the P-CSCF attaches an indication that the REGISTER request was not 15 integrity protected or ensures that there is no indication about integrity protection in the message. 16 17 18 6.2 Confidentiality mechanisms 19 20 If the local policy in P-CSCF requires the use of IMS specific confidentiality protection mechanism 21 between UE and P-CSCF, IPsec ESP as specified in [4] shall provide confidentiality protection of SIP 22 signaling between the UE and the P-CSCF, protecting all SIP signaling messages at the IP level. IPSec ESP 23 general concepts on Security Policy management, Security Associations and IP traffic processing as 24 described in reference [5] shall also be considered. ESP confidentiality shall be applied in transport mode 25 between UE and P-CSCF. 26 27 The method to set up ESP security associations (SAs) during the SIP registration procedure is specified in 28 section 7. As a result of an authenticated registration procedure, two pairs of unidirectional SAs between 29 the UE and the P-CSCF all shared by TCP and UDP, shall be established in the P-CSCF and later in the 30 31 UE. One SA pair is for traffic between a client port at the UE and a server port at the P-CSCF and the other 32 SA is for traffic between a client port at the P-CSCF and a server port at the UE. For a detailed description 33 of the establishment of these security associations see section 7. 34 35 The encryption key CK is the same for the two pairs of simultaneously established SAs. The encryption ESP 36 key CKESP is obtained from the key CKIM established as a result of the AKA procedure, specified in 37 section 6.1, using a suitable key expansion function. 38 39 The encryption key expansion on the user side is done in the UE. The encryption key expansion on the 40 network side is done in the P-CSCF. The key expansion function is described in Annex B. 41 42
43 44 45 6.3 Integrity mechanisms 46 47 IPsec ESP as specified in reference [4] shall provide integrity protection of SIP signaling between the UE 48 and the P-CSCF, protecting all SIP signaling messages at the IP level. IPSec ESP general concepts on 49 Security Policy management, Security Associations and IP traffic processing as described in reference [5] 50 shall also be considered. ESP integrity shall be applied in transport mode between UE and P-CSCF. 51 52 The method to set up ESP security associations (SAs) during the SIP registration procedure is specified in 53 section 7. As a result of an authenticated registration procedure, two pairs of unidirectional SAs between 54 the UE and the P-CSCF, all shared by TCP and UDP, shall be simultaneously established in the P-CSCF 55 and later on in the UE. One SA pair is for traffic between a client port at the UE and a server port at the 56 P-CSCF and the other SA pair is for traffic between a client port at the P-CSCF and a server port at the UE. 57 For a detailed description of the establishment of these security associations see section 7. 58
16 S.S0086-B v2.0
1 2 The integrity key IKESP is the same for the two simultaneously established SAs. The integrity key IKESP is 3 obtained from the key IKIM established as a result of the AKA procedure, specified in section 6.1, using a 4 suitable key expansion function. This key expansion function depends on the ESP integrity algorithm and 5 is specified in Annex B of this document. 6 7 The integrity key expansion on the user side is done in the UE. The integrity key expansion on the network 8 side is done in the P-CSCF. 9 10 The anti-replay service as described in [11] shall be enabled in the UE and the P-CSCF on all established 11 SAs. Note that IPsec integrity protection is incompatible with use of Network Address Translation between 12 IPv4 entities. No Network Address Translation is allowed between the UE and P-CSCF. 13 14 15 6.4 Hiding mechanisms 16 17 The Hiding Mechanism is optional for implementation. All I-CSCFs in the HN shall share the same 18 encryption and decryption key Kv. If the mechanism is used and the operator policy states that the topology 19 shall be hidden the I-CSCF shall encrypt the hiding information elements when the I-CSCF forwards SIP 20 Request or Response messages outside the hiding network’s domain. The hiding information elements are 21 entries in SIP headers, such as Via, Record-Route, Route and Path, which contain addresses of SIP proxies 22 in hiding network. When I-CSCF receives a SIP Request or Response message from outside the hiding 23 network’s domain, the I-CSCF shall decrypt those information elements that were encrypted by I-CSCF in 24 this hiding network domain. 25 26 The purpose of encryption in network hiding is to protect the identities of the SIP proxies and the topology 27 of the hiding network. Therefore, an encryption algorithm in confidentiality mode shall be used. The 28 network hiding mechanism will not address the issues of authentication and integrity protection of SIP 29 headers. The AES in CBC mode with 128-bit block and 128-bit key shall be used as the encryption 30 31 algorithm for network hiding. In the CBC mode under a given key, if a fixed IV is used to encrypt two 32 same plaintexts, then the ciphertext blocks will also be equal. This is undesirable for network hiding. 33 Therefore, random IV shall be used for each encryption. The same IV is required to decrypt the 34 information. The IV shall be included in the same SIP header that includes the encrypted information. 35 36 37 6.5 CSCF interoperating with proxy located in a non-IMS 38 39 network 40 41 SIP signaling protected by TLS specified in RFC 3261 [2] may be used for protecting the SIP 42 interoperation between an IMS CSCF with a proxy/CSCF located in a foreign network. The CSCF may 43 request the TLS connection with a foreign proxy by publishing sips: URI in DNS server, that can be 44 resolved via NAPTR/SRV mechanism specified in RFC 3263 [27]. When sending/receiving the certificate 45 during the TLS handshaking phase, the CSCF shall verify the name on the certificate against the list of the 46 interworking partners. 47 48 The TLS session could be initiated from either network. A TLS connection is capable of carrying multiple 49 SIP dialogs. 50 51 Applying this method is to prevent attacks on SIP level, but it does not prohibit other security methods to 52 be applied so as to strengthen the security for IP based networks. This part is specified in section 9.1. 53 54 NOTE 1: The NOTE 1 in section 5.1.4 on the use of TLS also applies here. 55 56 57 58
17 S.S0086-B v2.0
1 2 3 7 Security association set-up procedure 4 5 The security association set-up procedure is necessary in order to decide what security services to apply 6 and when the security services start. In the IMS authentication of users is performed during registration as 7 specified in section 6.1. Subsequent signaling communications in this session will be integrity protected 8 based on the keys derived during the authentication and key agreement process. 9 10 11 7.1 Security association parameters 12 13 For protecting IMS signaling between the UE and the P-CSCF it is necessary to agree on shared keys that 14 are provided by a set of parameters specific to a protection method. The security mode setup (cf. 15 section 7.2) is used to negotiate the SA parameters required for IPsec ESP with authentication, and 16 confidentiality, in accordance with the provisions in sections 5.1.3 and 6.2. 17 18 19 20 The SA parameters that shall be negotiated between UE and P-CSCF in the security mode set-up procedure 21 are: 22 23 - Encryption algorithm 24 25 The encryption algorithm is either DES-EDE3-CBC as specified in RFC 2451 [15] or AES-CBC as 26 specified in RFC 3602 [16] with 128 bit key. 27 28 Both encryption algorithms shall be supported by both the UE and the P-CSCF. 29 30 - Integrity algorithm 31 32 NOTE 1: What is called "authentication algorithm" in [4] is called "integrity algorithm" in this 33 document to avoid confusion with the authentication algorithms used in the AKA protocol. 34 35 The integrity algorithm is either HMAC-MD5-96 [6] or HMAC-SHA-1-96 [7]. 36 37 NOTE 2: This, in particular, excludes the use of the NULL integrity algorithm. 38 Both integrity algorithms shall be supported by both the UE and the P-CSCF as mandated by [4]. In 39 40 the unlikely event that one of the integrity algorithms is compromised during the lifetime of this 41 document, this algorithm shall no longer be supported. 42 NOTE 3: If only one of the two integrity algorithms is compromised then it suffices for the IMS to 43 44 remain secure that the algorithm is no longer supported by any P-CSCF. The security mode 45 set-up procedure (cf. section 7.2) will then ensure that the other integrity algorithm is 46 selected. 47 48 - SPI (Security Parameter Index) 49 The SPI is allocated locally for inbound SAs. The triple (SPI, destination IP address, security 50 protocol) uniquely identifies an SA at the IP layer. The UE shall select the SPIs uniquely, and 51 52 different from any SPIs that might be used in any existing SAs (i.e. inbound and outbound SAs). 53 The SPIs selected by the P-CSCF shall be different than the SPIs sent by the UE, cf. section 7.2. In 54 an authenticated registration, the UE and the P-CSCF each select two SPIs, not yet associated with 55 existing inbound SAs, for the new inbound security associations at the UE and the P-CSCF 56 respectively. 57 58
18 S.S0086-B v2.0
1 2 NOTE 4: This allocation of SPIs ensures that protected messages in the uplink always differ from 3 protected messages in the downlink in, at least, the SPI field. This thwarts reflection attacks. 4 When several applications use IPsec on the same physical interface the SIP application 5 should be allocated a separate range of SPIs. 6 7 The following SA parameters are not negotiated: 8 9 - Life type: the life type is always seconds; 10 - SA duration: the SA duration has a fixed length of 232-1; 11 12 NOTE 5: The SA duration is a network layer concept. From a practical point of view, the value chosen 13 for "SA duration" does not impose any limit on the lifetime of an SA at the network layer. 14 The SA lifetime is controlled by the SIP application as specified in section 7.4. 15 16 - Mode: transport mode; 17 18 - Key length: the length of the integrity key IKESP depends on the integrity algorithm. It is 128 bits for 19 HMAC-MD5-96 and 160 bits for HMAC-SHA-1-96. 20 21 - Key length: the length of the encryption key depends on the encryption algorithm. The entropy of 22 the key shall at least be 128 bits. 23 24 Selectors: 25 26 The security associations (SA) have to be bound to specific parameters (selectors) of the SIP flows between 27 UE and P-CSCF, i.e. source and destination IP addresses, transport protocol, and source and destination 28 ports. 29 30 - IP addresses are bound to two pairs of SAs, as in section 6.3, as follows: 31 32 - inbound SA at the P-CSCF: 33 The source and destination IP addresses associated with the SA are identical to those in the 34 header of the IP packet in which the initial SIP REGISTER message was received by the 35 P-CSCF. 36 37 - outbound SA at the P-CSCF: 38 the source IP address bound to the outbound SA equals the destination IP address bound to the 39 inbound SA; 40 the destination IP address bound to the outbound SA equals the source IP address bound to the 41 inbound SA. 42 43 NOTE 6: This implies that the source and destination IP addresses in the header of the IP packet in 44 which the protected SIP REGISTER message was received by the P-CSCF need to be the 45 same as those in the header of the IP packet in which the initial SIP REGISTER message was 46 received by the P-CSCF. 47 48 - The transport protocol is either TCP or UDP. 49 50 - Ports: 51 52 1. The P-CSCF associates two ports, called port_ps and port_pc, with each pair of security 53 associations established in an authenticated registration. The port port_ps and port_pc are 54 different from the standard SIP ports 5060 and 5061. No unprotected messages shall be sent 55 from or received on the ports port_ps and port_pc. From a security point of view, unprotected 56 messages may be received on any port which is communicated to the UE during the security 57 mode set-up procedure, cf. section 7.2. These ports are used with both UDP and TCP. The use of 58 these ports may differ for TCP and UDP as follows:
19 S.S0086-B v2.0
1 2 UDP case: the P-CSCF receives requests and responses protected with ESP from any UE on the 3 port port_ps (the "protected server port"). The P-CSCF sends requests and responses protected 4 with ESP to a UE on the port port_pc (the "protected client port"). 5 6 TCP case: the P-CSCF, if it does not have a TCP connection towards the UE yet, shall set up a 7 TCP connection from its port_pc to the port port_us of the UE before sending a request to it. 8 9 NOTE 7: Both the UE and the P-CSCF may set up a TCP connection from their client port to the other 10 end’s server port on demand. An already existing TCP connection may be reused by both the 11 P-CSCF or the UE; but it is not mandatory. 12 13 NOTE 8: The protected server port port_ps stays fixed for a UE until all IMPUs from this UE are de- 14 registered. It may be fixed for a particular P-CSCF over all UEs, but there is no need to fix 15 the same protected server port for different P-CSCFs. 16 17 NOTE 9: The distinction between the UDP and the TCP case reflects the different behavior of SIP over 18 UDP and TCP, as specified in RFC 3261, section 18. 19 20 2. The UE associates two ports, called port_us and port_uc, with each pair of security associations 21 established in an authenticated registration. The ports port_us and port_uc are different from the 22 standard SIP ports 5060 and 5061. No unprotected messages shall be sent from or received on 23 the ports port_us and port_uc. From a security point of view, unprotected messages may be 24 received on any port which is different from the ports port_us and port_uc. The number of the 25 ports port_us and port_uc are communicated to the P-CSCF during the security mode set-up 26 procedure, cf. section 7.2. These ports are used with both UDP and TCP. The use of these ports 27 may differ for TCP and UDP, as follows: 28 29 UDP case: the UE receives requests and responses protected with ESP on the port port_us (the 30 "protected server port"). The UE sends requests and responses protected with ESP on the port 31 port_uc (the "protected client port"). 32 33 TCP case: the UE, if it does not have a TCP connection towards the P-CSCF yet, shall set up a 34 TCP connection to the port port_ps of the P-CSCF before sending a request to it. 35 36 NOTE 10: Both the UE and the P-CSCF may set up a TCP connection from their client port to the other 37 end’s server port on demand. An already existing TCP connection may be reused by both the 38 P-CSCF or the UE; but it is not mandatory. 39 40 NOTE 11: The protected server port port_us stays fixed for a UE until all IMPUs from this UE are de- 41 registered. 42 43 NOTE 12: The distinction between the UDP and the TCP case reflects the different behavior of SIP 44 over UDP and TCP, as specified in RFC 3261, section 18. 45 46 3. The P-CSCF is allowed to receive only REGISTER messages and error messages on unprotected 47 ports. All other messages not arriving on the protected port shall be either discarded or rejected 48 by the P-CSCF. 49 50 4. The UE is allowed to receive only the following messages on an unprotected port: 51 52 - responses to unprotected REGISTER messages; 53 54 - error messages. 55 56 All other messages not arriving on a protected port shall be rejected or silently discarded by the 57 UE. 58
The following rules apply:
20 S.S0086-B v2.0
1 2 1. For each unidirectional SA which has been established and has not expired, the SIP application at 3 the P-CSCF stores at least the following data: (UE_IP_address, UE_protected_port, P- 4 CSCF_protected_port, SPI, IMPI, IMPU1, ... , IMPUn, lifetime) in an "SA_table". The pair 5 (UE_protected port, P-CSCF_protected_port) equals either (port_uc, port_ps) or (port_us, port_pc). 6 7 NOTE 13: The SPI is only required when initiating and deleting SAs in the P-CSCF. The SPI is not 8 exchanged between IPsec and the SIP layer for incoming or outgoing SIP messages. 9 10 2. The SIP application at the P-CSCF shall check upon receipt of a protected REGISTER message that 11 the source IP address in the packet header coincides with the UE’s IP address given inserted in the 12 contact Via header of the protected REGISTER message. If the contact Via header does not 13 explicitly contain the UE’s IP address, but rather a symbolic name then the P-CSCF shall first 14 resolve the symbolic name by suitable means to obtain an IP address. 15 16 3. The SIP application at the P-CSCF shall check upon receipt of an initial REGISTER message that 17 the pair (UE_IP_address, UE_protected_client_port), where the UE_IP_address is the source IP 18 address in the packet header and the protected client port is sent as part of the security mode set-up 19 procedure (cf. section 7.2), has not yet been associated with entries in the "SA_table". Furthermore, 20 the P-CSCF shall check that, for any one IMPI, no more than six SAs per direction are stored at any 21 one time. If these checks are unsuccessful the registration is aborted and a suitable error message is 22 sent to the UE. 23 24 NOTE 14: According to section 7.4 on SA handling, at most six SAs per direction may exist at a 25 P-CSCF for one user at any one time. 26 27 4. For each incoming protected message the SIP application at the P-CSCF shall verify that the correct 28 inbound SA according to section 7.4 on SA handling has been used. The SA is identified by the 29 triple (UE_IP_address, UE_protected_port, P-CSCF_protected_port) in the "SA_table". The SIP 30 application at the P-CSCF shall further check that the IMPU associated with the SA in the 31 "SA_table" and the IMPU in the received SIP message coincide. If this is not the case the message 32 shall be discarded. 33 34 5. For each unidirectional SA which has been established and has not expired, the SIP application at 35 the UE stores at least the following data: (UE_protected_port, P-CSCF_protected_port, SPI, 36 lifetime) in an "SA_table". The pair (UE_protected_port, P-CSCF_protected_port) equals either 37 (port_uc, port_ps) or (port_us, port_pc). 38 39 NOTE 15: The SPI is only required to initiate and delete SAs in the UE. The SPI is not exchanged 40 between IPsec and the SIP layer for incoming or outgoing SIP messages. 41 42 6. When establishing a new pair of SAs (cf. section 6.3) the SIP application at the UE shall ensure that 43 the selected number for the protected ports do not correspond to an entry in the "SA_table". 44 45 NOTE 16: Regarding the selection of the number of the protected port at the UE it is generally 46 recommended that the UE randomly selects the number of the protected port from a 47 sufficiently large set of numbers not yet allocated at the UE. This is to thwart a limited form 48 of a Denial of Service attack. 49 50 7. For each incoming protected message the SIP application at the UE shall verify that the correct 51 inbound SA according to section 7.4 on SA handling has been used. The SA is identified by the pair 52 (UE_protected_port, P-CSCF_protected_port) in the "SA table". 53 54 NOTE 17: If the integrity check of a received packet fails then IPsec will automatically discard the 55 packet. 56 57 58
21 S.S0086-B v2.0
1 2 7.2 Set-up of security associations (successful case) 3 4 Authentication and key agreement procedures are described in section 6.1. 5 6 The set-up of security associations is based on [12]. Annex A of this document shows how to use [12] for 7 the set-up of security associations. 8 9 In this section the normal case is specified i.e. when no failures occurs. Note that for simplicity some of the 10 nodes and messages have been omitted. Hence there are gaps in the numbering of messages, as the I-CSCF 11 is omitted. 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 Figure 6: Successful set-up of security associations. 40 41 The UE sends a Register message towards the S-CSCF to register the location of the UE and to set-up the 42 security mode, cf. section 6.1. In order to start the security mode set-up procedure, the UE shall include a 43 Security-setup line in this message. 44 45 The Security-setup line in SM1 contains the Security Parameter Index value and the protected ports 46 selected by the UE. It also contains a list of identifiers for the integrity and encryption algorithms, which 47 the UE supports. 48 49 50 SM1: 51 REGISTER(Security-setup = SPI_U, Port_U, UE integrity and encryption algorithms list) 52 53 SPI_U is the symbolic name of a pair of SPI values (cf. section 7.1) (spi_uc, spi_us) that the UE selects. 54 spi_uc is the SPI of the inbound SA at the UE’s protected client port, and spi_us is the SPI of the inbound 55 SA at the UE’s protected server port. The syntax of the spi_uc and spi_us is defined in Annex A. 56 57 Port_U is the symbolic name of a pair of port numbers (port_uc, port_us) as defined in section 7.1. The 58 syntax of port_uc and port_us is defined in Annex A.
22 S.S0086-B v2.0
1 2 Upon receipt of SM1, the P-CSCF temporarily stores the parameters received in the Security-setup line 3 together with the UE’s IP address from the source IP address of the IP packet header, the IMPI and IMPU. 4 Upon receipt of SM4, the P-CSCF adds the keys IKIM and CKIM received from the S-CSCF to the 5 temporarily stored parameters. 6 7 A P-CSCF which supports confidentiality protection shall propose SA alternatives for previous revision 8 UE’s since the UE may or may not support confidentiality protection. The P-CSCF then selects the SPIs for 9 the inbound SAs. The same SPI number shall be used for all revisions. The P-CSCF shall define the SPIs 10 such that they are unique and different from any SPIs as received in the Security-setup line from the UE. 11 12 NOTE 1: This rule (unique SPIs) is needed since the UE and the P-CSCF use the same key for inbound 13 and outbound traffic. 14 15 In order to determine the integrity and encryption algorithm the P-CSCF proceeds as follows: the P-CSCF 16 has a list of integrity and encryption algorithms it supports, ordered by priority. Later revision algorithms 17 must have higher priority than earlier revision algorithms. The P-CSCF selects the first integrity algorithm 18 on its own list which is also supported by the UE. 19 20 The P-CSCF then establishes two new pairs of SAs in the local security association database. 21 22 The Security-setup line in SM6 contains the SPIs and the ports assigned by the P-CSCF. It also contains a 23 list of identifiers for the integrity and encryption algorithms, which the P-CSCF supports. 24 25 NOTE 2: P-CSCF may be configured to trust on the encryption provided by the underlying access 26 network. In this case, the P-CSCF acts according to earlier revision documents, and does not 27 include encryption algorithms to the Security-setup line in SM6. 28 29 30 31 SM6: 32 4xx Auth_Challenge(Security-setup = SPI_P, Port_P, P-CSCF integrity and encryption algorithms list) 33 34 SPI_P is the symbolic name of the pair of SPI values (cf. section 7.1) (spi_pc, spi_ps) that the P-CSCF 35 36 selects. spi_pc is the SPI of the inbound SA at the P-CSCF’s protected client port, and spi_ps is the SPI of 37 the inbound SA at the P-CSCF’s protected server port. The syntax of the spi_pc and spi_ps is defined in 38 Annex A. 39 40 Port_P is the symbolic name of the port numbers (port_pc, port_ps) as defined in section 7.1 The syntax of 41 Port_P is defined in Annex A. 42 Upon receipt of SM6, the UE determines the integrity and encryption algorithm as follows: the UE selects 43 44 the first integrity and encryption algorithm combination on the list received from the P-CSCF in SM 6 45 which is also supported by the UE. 46 NOTE 3: UE from earlier revisions will not support any encryption algorithms, and will choose the 47 48 first earlier revision integrity algorithm on the list received from the P-CSCF in SM6. 49 The UE then proceeds to establish two new pairs of SAs in the local SAD. 50 51 The UE shall integrity and confidentiality protect SM7 and all following SIP messages. Furthermore the 52 integrity and encryption algorithms list, SPI_P, and Port_P received in SM6, and SPI_U, Port_U sent in 53 SM1 shall be included: 54 55 56 SM7: 57 REGISTER(Security-setup = SPI_U, Port_U, SPI_P, Port_P, P-CSCF integrity and encryption algorithms list) 58
23 S.S0086-B v2.0
1 2 After receiving SM7 from the UE, the P-CSCF shall check whether the integrity algorithms list, SPI_P, and 3 Port_P received in SM7 is identical with the corresponding parameters sent in SM6. It further checks 4 whether SPI_U and Port_U received in SM7 are identical with those received in SM1. If these checks are 5 not successful the registration procedure is aborted. The P-CSCF shall include in SM8 information to the S- 6 CSCF that the received message from the UE was integrity protected as indicated in section 6.1.5. The P- 7 CSCF shall add this information to all subsequent REGISTER messages received from the UE that have 8 successfully passed the integrity and confidentiality check in the P-CSCF. 9 10 SM8: 11 REGISTER(Integrity-Protection = Successful, Confidentiality-Protection = Successful, IMPI) 12 13 The P-CSCF finally sends SM12 to the UE. SM12 does not contain information specific to security mode 14 setup (i.e. a Security-setup line), but with sending SM12 not indicating an error the P-CSCF confirms that 15 security mode setup has been successful. After receiving SM12 not indicating an error, the UE can assume 16 the successful completion of the security-mode setup. 17 18 An example of how to make use of the two pairs of unidirectional SAs is illustrated in the figure below 19 with a set of example message exchanges protected by the respective IPsec SAs where the INVITE and 20 following messages are assumed to be carried over TCP. 21 22 23 UE P-CSCF 24 Register (SM1) 25 26 401 Unauthorised (SM6) 27 RAND||AUTN Unprotected 28 Protected by SA pair 1 29 Protected by SA pair 2 30 Register (SM7) 31 RES port_uc port_ps 32 OK (SM12) 33 34 35 Invite 36 37 180 Ringing port_us port_pc 38 200 OK 39 40 41 42 Figure 7 43 44 45 7.3 Error cases in the set-up of security associations 46 47 48 7.3.1 Error cases related to IMS AKA 49 50 Errors related to IMS AKA failures are specified in section 6.1. However, this section additionally 51 describes how these shall be treated, related to security setup. 52 53 7.3.1.1 User authentication failure 54 55 56 In this case, SM7 fails integrity check by IPsec at the P-CSCF if the IKIM derived from RAND at UE is wrong. The SIP application at the P-CSCF never receives SM7. It shall delete the temporarily stored SA 57 parameters associated with this registration after a time-out. 58
24 S.S0086-B v2.0
1 2 In case IKIM was derived correctly, but the response was wrong the authentication of the user fails at the 3 S-CSCF due to an incorrect response. The S-CSCF shall send a 4xx Auth_Failure message to the UE, via 4 the P-CSCF, which may pass through an already established SA. Afterwards, both, the UE and the P-CSCF 5 shall delete the new SAs. 6 7 7.3.1.2 Network authentication failure 8 9 If the UE is not able to successfully authenticate the network, the UE shall send a REGISTER message 10 which may pass through an already established SA, indicating a network authentication failure, to the P- 11 CSCF. The P-CSCF deletes the new SAs after receiving this message. 12 13 14 7.3.1.3 Synchronisation failure 15 16 In this situation, the UE observes that the AUTN sent by the network in SM6 contains an out-of-range 17 sequence number. The UE shall send a REGISTER message to the P-CSCF, which may pass through an 18 already established SA, indicating the synchronization failure. The P-CSCF deletes the new SAs after 19 receiving this message. 20 21 22 7.3.1.4 Incomplete authentication 23 24 If the UE responds to an authentication challenge from a S-CSCF, but does not receive a reply before the 25 request times out, the UE shall start a registration procedure if it still requires any IM services. The first 26 message in this registration should be protected with an SA created by a previous successful authentication 27 if one exists. 28 29 When the P-CSCF receives a challenge from the S-CSCF and creates the corresponding SAs during a 30 registration procedure, it shall delete any information relating to any previous registration procedure 31 (including the SAs created during the previous registration procedure). 32 33 If the P-CSCF deletes a registration SA due to its lifetime being exceeded, the P-CSCF should delete any 34 information relating to the registration procedure that created the SA. 35 36 37 7.3.2 Error cases related to the Security-setup 38 39 7.3.2.1 Proposal unacceptable to P-CSCF 40 41 In this case the P-CSCF cannot accept the proposal set sent by the UE in the Security-setup command of 42 SM1. The P-CSCF shall respond to SM1 indicating a failure, by sending an error response to the UE. 43 44 45 7.3.2.2 Proposal unacceptable to UE 46 47 If the P-CSCF sends in the Security-setup line of SM6 a proposal that is not acceptable for the UE, the UE 48 shall abandon the registration procedure. 49 50 7.3.2.3 Failed consistency check of Security-setup lines at the P-CSCF 51 52 The P-CSCF shall check whether authentication and encryption algorithms list received in SM7 is identical 53 with the authentication and encryption algorithms list sent in SM6. If this is not the case the registration 54 procedure is aborted. (Cf. section 7.2). 55 56 57 58
25 S.S0086-B v2.0
1 2 7.4 Authenticated re-registration 3 4 Every registration that includes a user authentication attempt produces new security associations. If the 5 authentication is successful, then these new security associations shall replace the previous ones. This 6 section describes how the UE and P-CSCF handle this replacement and which SAs to apply to which 7 message. 8 9 When security associations are changed in an authenticated re-registration then the protected server ports at 10 the UE (port_us) and the P-CSCF (port_ps) shall remain unchanged, while the protected client ports at the 11 UE (port_uc) and the P-CSCF (port_pc) shall change. For the definition of these ports see section 7.1. 12 13 If the UE has an already active security association, then it shall use this to protect the REGISTER 14 message. If the S-CSCF is notified by the P-CSCF that the REGISTER message from the UE was integrity- 15 protected it may decide not to authenticate the user by means of the AKA protocol. However, the UE may 16 send unprotected REGISTER messages at any time. In this case, the S-CSCF shall authenticate the user by 17 18 means of the AKA protocol. In particular, if the UE considers the SAs no longer active at the P-CSCF, e.g., 19 after receiving no response to several protected messages, then the UE shall send an unprotected 20 REGISTER message. 21 22 Security associations may be unidirectional or bi-directional. This section assumes that security 23 associations are unidirectional, as this is the general case. For IP layer SAs, the lifetime mentioned in the 24 following sections is the lifetime held at the application layer. Furthermore deleting an SA means deleting 25 the SA from both the application and IPsec layer. The message numbers, e.g. SM1, used in the following 26 sections relate to the message flow given in section 6.1.1. 27 28 29 7.4.1 Void 30 31 7.4.1a Management of security associations in the UE 32 33 The UE shall be involved in only one registration procedure at a time, i.e. the UE shall remove any data 34 relating to any previous incomplete registrations or authentications, including any SAs created by an 35 incomplete authentication. 36 37 The UE may start a registration procedure with two existing pairs of SAs. These will be referred to as the 38 old SAs. The authentication produces two pairs of new SAs. These new SAs shall not be used to protect 39 non-authentication traffic until noted during the authentication flow. In the same way, certain messages in 40 41 the authentication shall be protected with a particular SA. If the UE receives a message protected with the 42 incorrect SA, it shall discard the message. 43 A successful authentication proceeds in the following steps: 44 45 - The UE sends the SM1 message to register with the IMS. If SM1 was protected, it shall be protected 46 with the old outbound SA. 47 48 - The UE receives an authentication challenge in a message (SM6) from the P-CSCF. This message 49 shall be protected with the old inbound SA if SM1 was protected and unprotected otherwise. 50 51 - If this message SM6 can be successfully processed by the UE, the UE creates the new SAs, which 52 are derived according to section 7.1. The lifetime of the new SAs shall be set to allow enough time 53 to complete the registration procedure. The UE then sends its response (SM7) to the P-CSCF, which 54 shall be protected with the new outbound SA. Meanwhile, if SM1 was protected, the UE shall use 55 56 the old SAs for messages other than those in the authentication, until a successful message of new 57 authentication is received (SM12). 58
26 S.S0086-B v2.0
1 2 - The UE receives an authentication successful message (SM12) from the P-CSCF. It shall be 3 protected with the new inbound SA. 4 5 - After the successful processing of this message by the UE, the registration is complete. The UE sets 6 the lifetime of the new SAs such that it either equals the latest lifetime of the old SAs or it will 7 expire shortly after the registration timer in the message, depending which gives the SAs the longer 8 life. For further SIP messages sent from UE, the new outbound SAs are used, with the following 9 exception: when a SIP message is part of a pending SIP transaction it may still be sent over the old 10 SA. A SIP transaction is called pending if it was started using an old SA. When a further SIP 11 message protected with a new inbound SA is successfully received from the P-CSCF, then the old 12 SAs shall be deleted as soon as either all pending SIP transactions have been completed, or have 13 timed out. The old SAs shall be always deleted when the lifetime is expired. This completes the SA 14 handling procedure for the UE. 15 16 A failure in the authentication can occur for several reasons. If the SM1 was not protected, then no 17 protection shall be applied to the failure messages, except the user authentication failure message which 18 shall be protected with the new SA. If SM1 was protected, the old SAs shall be used to protect the failure 19 message, the UE shall delete the new SAs. 20 21 The UE shall monitor the expiry time of registration without an authentication and if necessary increase the 22 lifetime of the SAs created by the last successful authentication such that it will expire shortly after the 23 registration timer in the message. 24 25 NOTE 1: In particular this means that the lifetime of a SA is never decreased. 26 27 The UE shall delete any SA whose lifetime is exceeded. The UE shall delete all SAs it holds once all the 28 IMPUs are deregistered. 29 30 31 7.4.2 Void 32 33 34 7.4.2a Management of security associations in the P-CSCF 35 36 When the S-CSCF initiates an authentication by sending a challenge to the UE, the P-CSCF may already 37 contain existing SAs from previously completed authentications. It may also contain two existing pairs of 38 SAs from an incomplete authentication. These will be referred to as the old and registration SAs 39 respectively. The authentication produces two pairs of new SAs. These new SAs shall not be used to 40 protect non-authentication traffic until noted during the authentication flow. Similarly certain messages in 41 the authentication shall be protected with a particular SA. If the P-CSCF receives a message protected with 42 the incorrect SA, it shall discard the message. 43 44 The P-CSCF associates the IMPI given in the registration procedure and all the successfully registered 45 IMPUs related to that IMPI to an SA. 46 47 A successful authentication proceeds in the following steps: 48 49 - The P-CSCF receives the SM1 message. If SM1 is protected, it shall be protected with the old 50 inbound SA. 51 52 - The P-CSCF forwards the message containing the challenge (SM6) to the UE. This shall be 53 protected with the old outbound SA, if SM1 was protected and unprotected otherwise. 54 55 - The P-CSCF then creates the new SAs, which are derived according to section 7.1. The expiry time 56 of the new SAs shall be set to allow enough time to complete the registration procedure. The 57 registration SAs shall be deleted if they exist. 58
27 S.S0086-B v2.0
1 2 - The P-CSCF receives the message carrying the response (SM7) from the UE. It shall be protected 3 using the new inbound SA. If SM1 was protected, the old SAs can now be used to protect messages 4 other than those in the authentication. 5 6 - The P-CSCF forwards the successful registration message (SM12) to the UE. It shall be protected 7 using the new outbound SA. This completes the registration procedure for the P-CSCF. The P- 8 CSCF sets the expiry time of the new SAs such that they either equals the latest lifetime of the old 9 SAs or it will expire shortly after the registration timer in the message, depending which gives the 10 SAs the longer life. 11 12 - After SM12 is sent, the P-CSCF handles the UE related SAs according to the following rules: 13 14 - If there are old SAs, but SM1 belonging to the same registration procedure was received 15 unprotected, the P-CSCF considers error cases happened, and assumes UE does not have those 16 old SAs for use. In this case, the P-CSCF shall remove the old SAs. 17 18 - If SM1 belonging to the same registration procedure was protected with an old valid SA, the 19 P-CSCF keeps this inbound SA and the corresponding three SAs created during the same 20 registration with the UE active, and continues to use them. Any other old SAs are deleted. When 21 the old SAs have only a short time left before expiring or a further SIP message protected with a 22 new inbound SA is successfully received from the UE, the P-CSCF starts to use the new SAs for 23 outbound messages with the following exception: when a SIP message is part of a pending SIP 24 transaction it may still be sent over the old SA. A SIP transaction is called pending if it was 25 started using an old SA. The old SAs are then deleted as soon as all pending SIP transactions 26 have been completed, or have timed out. The old SAs are always deleted when the old SAs 27 lifetime are expired. When the old SAs expire without a further SIP message protected by the 28 new SAs, the new SAs are taken into use for outbound messages. This completes the SA 29 handling procedure for the P-CSCF. 30 31 A failure in the authentication can occur for several reasons. If the SM1 was not protected, then no 32 protection shall be applied to the failure messages, except the user authentication failure message which 33 shall be protected with the new SAs. If SM1 was protected, the old SAs shall be used to protect the failure 34 35 messages. In both cases, after processing the failure message, the P-CSCF shall delete the new SAs. 36 The P-CSCF shall monitor the expiry time of registration without an authentication and if necessary 37 increase the lifetime of SAs created by the last successful authentication such that it will expire shortly after 38 39 the registration timer in the message. 40 NOTE 1: In particular this means that the lifetime of a SA is never decreased. 41 42 The P-CSCF shall delete any SA whose lifetime is exceeded. The P-CSCF shall delete all SAs it holds that 43 are associated with a particular IMPI once all the associated IMPUs are de-registered. 44 45 46 47 48 49 7.5 Rules for security association handling when the UE 50 changes IP address 51 52 When a UE changes its IP address, e.g. by using the method described in RFC 3041 [26], then the UE shall 53 delete the existing SA's and initiate an unprotected registration procedure using the new IP address as the 54 source IP address in the packets carrying the REGISTER messages. 55 56 57 58
28 S.S0086-B v2.0
1 2 3 8 Secure Memory within UE 4 5 For the purposes of this document the secure memory include the collection of IMS security data and 6 functions on a UE. 7 8 9 10 11 8.1 Requirements on the Secure Memory of an IMS 12 13 Capable UE 14 15 This section identifies requirements on the secure memory to support IMS access security. It does not 16 identify any data or functions that may be required on the secure memory for non-security purposes. 17 The secure memory shall include: 18 19 - The IMPI; 20 21 - At least one IMPU; 22 23 - Home Network Domain Name; 24 25 - Support for sequence number checking in the context of the IMS Domain; 26 27 - The same enhanced AKA algorithms as specified in cdma2000 apply for the secure memory; 28 29 - An authentication Key. 30 31 The secure memory shall deliver the CK to the UE although it is not required that SIP signaling is 32 confidentiality protected. 33 34 At UE power off the existing SAs (session keys and related information) shall be deleted. 35 36 The IMS security data and functions described in the present section may be provided by an UIM, R-UIM 37 [21] or an ISIM [22]. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
29 S.S0086-B v2.0
1 2 3 4 9 Network Domain Security 5 6 This section describes security mechanisms for all communication except interfaces 1 and 2 of Figure 1, 7 rd including the Home Network, Serving Network, and any 3 party network nodes (such as SIP Application 8 Servers). This section is applicable independent of negotiation of the SIP security mechanism. 9 10 11 9.1 Inter-domain Security 12 13 Referring to Figure 1, interfaces 4 and 7 provides transport security between different networks for SIP 14 capable nodes. Interface 6 in Figure 1 provides security for communications between a SIP Application 15 Server, residing in an external network, and the HSS. There may be other interfaces to nodes outside the 16 Home Network, which are also intended to be covered by this section. The involved nodes shall be capable 17 of IPsec [5]. Privacy protection shall be applied with cryptographic strength greater than DES. Integrity 18 19 protection shall be applied. IPsec may be used in either transport mode or tunnel mode; when used in 20 tunnel mode, one or both of the network security domains may use Security Gateways. Security 21 associations between nodes in different networks shall be negotiated using IPsec/IKE [14]. 22 23 It is necessary that nodes outside the home network should be secure and trustworthy, perhaps using 24 mechanisms such as firewalls, packet filters, and so on. However such details are outside the scope of this 25 document. 26 27 28 9.2 Intra-domain Security 29 30 The interface labeled 5 in Figure 1 is between SIP-capable nodes in the same network security domain. 31 The interface labeled 3 in Figure 1 is between the I-CSCF/S-CSCF and the HSS. There may be other 32 interfaces to nodes inside the Home Network, which are also intended to be covered by this section. As 33 these interfaces exist entirely within one network security domain, the administrative authority may choose 34 any mechanism to secure this interface, including physical security where appropriate. Cryptographic 35 methods of security, if applied, shall include both privacy and integrity protection, and be at least as strong 36 as IPsec [5] using triple-DES and HMAC-MD5. 37 38 39 40 41 9.3 Profiles of Network Domain Security Methods 42 43 The profiles specified in this section apply to both sections 9.1 and 9.2. 44 45 46 9.3.1 Support of IPSec ESP 47 48 For the interfaces security protection between IMS network elements, this section specifies the protection 49 using IPsec as specified in RFC 2401 [5] with 3DES and AES (key length shall be 128 bits) for encryption 50 and HMAC-SHA-1 for integrity protection. The key management and distribution architecture is based on 51 the IPsec IKE (RFC 2401 [5], RFC 2407 [17], RFC 2408 [18] and RFC 2409 [14]) protocols. 52 53 The security services provided by network domain security: 54 55 - data integrity; 56 57 - data origin authentication; 58
- anti-replay protection;
30 S.S0086-B v2.0
1 2 - confidentiality (optional); 3 - limited protection against traffic flow analysis when confidentiality is applied. 4 5 The IPsec security protocol shall always be ESP. Integrity protection/message authentication together with 6 anti-replay protection shall always be used. IPSec ESP should be used with both encryption and integrity 7 protection for all SIP signaling traversing inter-security domain boundaries. 8 9 IPsec offers a set of security services, which is determined by the negotiated IPsec security associations. 10 That is, the IPsec SA defines which security protocol to be used, the mode, and the endpoints of the SA. 11 12 13 9.3.1.1 Support of ESP authentication and encryption 14 15 For IMS signaling traffic, ESP shall always be used to provide data integrity, data origin authentication, 16 and anti-replay protection services, thus the ESP_NULL authentication algorithm shall not be allowed for 17 use. It shall support ESP_HMAC_SHA-1 algorithm. 18 19 The ESP_DES algorithm shall not be used due to its weakness and instead it shall be mandatory to support 20 the ESP_3DES algorithm as default. Support for the AES-CBC cipher algorithm (RFC 3602 [16]) is 21 mandatory. The AES-CBC key length shall be 128 bits. 22 23 24 25 26 9.3.2 Support of TLS 27 28 This section specifies the use of TLS, for transport protection between IMS network elements. Where TLS 29 is used for transport protection, implementations shall support TLS 1.0, as specified in RFC 2246 [19]. 30 Implementations may support (and attempt to negotiate the use of) succeeding versions of TLS. 31 Implementations shall support mutual, certificate-based authentication, and may support (and attempt to 32 negotiate the use of) other authentication methods such as pre-shared secret keys (PSK). The security 33 services provided by network domain security: 34 35 - data integrity; 36 37 - data origin authentication; 38 39 - anti-replay protection; 40 41 TLS provides transport-layer security over connection-oriented protocols (for the purposes of this 42 document, TCP); "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within 43 a “Via” header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security 44 is required between hosts with no pre-existing trust association. 45 46 Implementations should support the AES cipher suites as specified in RFC 3268 [20], and shall at 47 minimum support TLS_RSA_WITH_AES_128_CBC_SHA. Implementations shall firstly prefer AES 48 cipher suites, and secondly prefer ephemeral Diffie-Hellman cipher suites during TLS negotiation. Mutual 49 authentication shall be required for all TLS connections; in other words anonymous cipher suites shall not 50 be accepted during negotiation. 51 52 53 54 55 56 57 58
31 S.S0086-B v2.0
1 2 3 4 5 6 Annex A (Normative): 7 8 The use of Security Mechanism Agreement for SIP 9 10 Sessions (ref. [12]) for security mode set-up 11 12 The BNF syntax of [12] is defined for negotiating security associations for manually keyed IPsec in the 13 following way: 14 security-client = "Security-Client" HCOLON sec-mechanism *(COMMA sec- 15 16 mechanism) 17 security-server = "Security-Server" HCOLON sec-mechanism *(COMMA sec- 18 19 mechanism) 20 security-verify = "Security-Verify" HCOLON sec-mechanism *(COMMA sec- 21 mechanism) 22 23 sec-mechanism = mechanism-name *(SEMI mech-parameters) 24 25 mechanism-name = "ipsec-3gpp" 26 27 mech-parameters = ( preference / algorithm / protocol / mode / encrypt-algorithm / spi-c / 28 spi-s / port-c / port-s / transport ) 29 30 preference = "q" EQUAL qvalue 31 32 qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] ) 33 34 algorithm = "alg" EQUAL ( "hmac-md5-96" / "hmac-sha-1-96 " ) 35 36 protocol = "prot" EQUAL ( "ah" / "esp" ) 37 38 mode = "mod" EQUAL ( "trans" / "tun" ) 39 encrypt-algorithm = "ealg" EQUAL ("aes-cbc" / "des-ede3-cbc" / "null" ) 40 41 spi-c = "spi" EQUAL spivalue 42 43 spi-s = "spi" EQUAL spivalue 44 45 spivalue = 10DIGIT; 0 to 4294967295 46 47 port-c = "port-c" EQUAL port 48 49 port-s = "port-s" EQUAL port 50 51 port = 1*DIGIT 52 53 54 55 The parameters described by the BNF above have the following semantics: 56 Mechanism-name: For manually keyed IPsec, this field includes the value "ipsec-3gpp". "ipsec- 57 58 3gpp" mechanism extends the general negotiation procedure of [12] in the following way:
32 S.S0086-B v2.0
1 2 1. The server shall store the Security-Client header received in the request before sending the 3 response with the Security-Server header. 4 5 2. The client shall include the Security-Client header in the first protected request. In other 6 words, the first protected request shall include both Security-Verify and Security-Client 7 header fields. 8 9 3. The server shall check that the content of Security-Client headers received in previous steps 10 (1 and 2) are the same. 11 Preference: As defined in [12]. 12 13 Algorithm: Defines the authentication algorithm. May have a value "hmac-md5-96" for algorithm 14 defined in [6], "hmac-sha-1-96" for algorithm defined in [7]. The algorithm parameter is mandatory. 15 16 17 18 Protocol: Defines the IPsec protocol. May have a value "ah" for [9] and "esp" for [4]. If no Protocol 19 parameter is present, the value will be "esp". 20 21 NOTE 1: According to section 6 only "esp" is allowed for use in IMS. 22 23 Mode: Defines the mode in which the IPsec protocol is used. May have a value "trans" for transport 24 mode, and value "tun" for tunneling mode. If no Mode parameter is present, the value will be 25 "trans". 26 27 NOTE 2: According to section 6.3 ESP integrity shall be applied in transport mode i.e. only "trans" is 28 allowed for use in IMS. 29 30 Encrypt-algorithm: If present, defines the encryption algorithm. May have a value "des-ede3-cbc" 31 for algorithm defined in [10] or "aes-cbc" for the algorithm defined in IETF RFC 3602 [16] or "null" 32 if encryption is not used. If no Encrypt-algorithm parameter is present, the algorithm will be "null". 33 34 Spi-c: Defines the SPI number of the inbound SA at the protected client port. 35 36 Spi-s: Defines the SPI number of the inbound SA at the protected server port. 37 38 Port-c: Defines the protected client port. 39 40 Port-s: Defines the protected server port. 41 42 43 It is assumed that the underlying IPsec implementation supports selectors that allow all transport 44 45 protocols supported by SIP to be protected with a single SA. 46 47 48 49 50 51 52 53 54 55 56 57 58
33 S.S0086-B v2.0
1 2 3 4 Annex B (Normative): 5 6 Key expansion functions for IPsec ESP 7 8 Integrity Keys: 9 10 If the selected authentication algorithm is HMAC-MD5-96 then IKESP = IKIM. 11 12 If the selected authentication algorithm is HMAC-SHA-1-96 then IK is obtained from IK by ESP IM 13 appending 32 zero bits to the end of IKIM to create a 160-bit string. 14 Encryption Keys: 15 16 17 Divide CKIM into two blocks of 64 bits each : 18 19 CKIM = CKIM1 || CKIM2 20 21 Where CKIM1 are the 64 most significant bits and CKIM2 are the 64 least significant bits. 22 The key for DES-EDE3-CBC is then defined to be 23 24 CKESP = CKIM1 || CKIM2 || CKIM1, 25 26 after adjusting parity bits to comply with [10]. 27 28 If selected encryption algorithm is AES-CBC as specified in RFC 3602 [16] with 128 bit key then CKESP = 29 CKIM. 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58
34 S.S0086-B v2.0
1 2 3 4 Annex C (Informative): 5 6 Recommendations to protect the IMS from UEs 7 8 bypassing the P-CSCF 9 10 After the UE does a successful SIP REGISTER with the P-CSCF, malicious UE could try to send SIP 11 messages directly to the S-CSCF. This could imply that the UE would be able to bypass the integrity 12 protection provided by IPSec ESP between the UE and the P-CSCF. 13 14 NOTE 1: [3] defines a trust domain that consists of the P-CSCF, the I-CSCF, the S-CSCF, the rd 15 BGCF, the MGCF, the MRFC and all the AS’s that are not provided by 3 party service 16 providers. There are nodes in the edge of the trust domain that are allowed to provide 17 with an asserted identity header. The nodes in the trust domain will trust SIP messages 18 with asserted identity header. The asserted identity information is useful as long as the 19 interfaces in an operator’s network can be trusted. 20 21 If a UE manages to bypass the P-CSCF it presents at least the following problems: 22 23 1) The P-CSCF is not able to generate any charging information. 24 25 2) Malicious UE could masquerade as some other user (e.g. it could potentially send INVITE or BYE 26 messages). 27 28 The following recommendations for preventing attacks based on such misbehavior are given: 29 • Access to S-CSCF entities should be restricted to the core network entities that are required 30 31 for IMS operation only. It shall be ensured that no UE is able to directly send IP packets to 32 IMS-entities other than the required ones, i.e. Assigned P-CSCF, or HTTP servers. 33 34 • Impersonation of IMS core network entities at IP level (IP spoofing), especially 35 impersonation of P-CSCFs by UEs should be prevented. 36 37 • It is desirable to have a general protection mechanism against UEs spoofing (source) IP 38 addresses in any access network providing access to IMS services. 39 40 If the traffic is between two non-IMS CSCFs, it is recommended to use TLS mechanisms as specified in 41 RFC 3261 [2]. This will mitigate the problems caused by mis-behave of the UE. If neither intra-CSCF 42 traffic nor CSCF-SEG traffic can be trusted and if this traffic is not protected by mechanisms specified in 43 section 9 and [13], then physical protection measures or IP traffic filtering should be applied. This is 44 anyhow not in the scope of cdma2000 documents. 45 46 47 48 49 50 51 52 53 54 55 56 57 58
35