Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 33.203  Word version:  17.1.0

Top   Top   Up   Prev   Next
1…   4   5…   6…   7…   8…   G…   M…   N…   O…   P…   T…   X…

 

6  Security mechanismsp. 19

6.1  Authentication and key agreementp. 19

6.1.0  General |R12|p. 19

The scheme for authentication and key agreement in the IMS is called IMS AKA. The IMS AKA achieves mutual authentication between the ISIM and the HN, cf. Figure 1. The identity used for authenticating a subscriber is the private identity, IMPI, which has the form of a NAI, cf. TS 23.228. The HSS and the ISIM share a long-term key associated with the IMPI.
The HN shall choose the IMS AKA scheme for authenticating an IM subscriber accessing through UMTS. The security parameters e.g. keys generated by the IMS AKA scheme are transported by SIP.
The generation of the authentication vector AV that includes RAND, XRES, CK, IK and AUTN shall be done in the same way as specified in TS 33.102. The ISIM and the HSS keep track of counters SQNISIM and SQNHSS respectively. The requirements on the handling of the counters and mechanisms for sequence number management are specified in TS 33.102. The AMF field can be used in the same way as in TS 33.102.
Furthermore two pairs of (unilateral) security associations (SAs) are established between the UE and the P-CSCF for each registered contact. The subscriber may have several IMPUs associated with one IMPI. These may belong to the same or different service profiles. Only two pairs of SAs shall be active between the UE and the P-CSCF for each registered contact. These two pairs of SAs shall be updated when a new successful authentication of the registered contact of for the subscriber has occurred, cf. clause 7.4.
It is the policy of the HN that decides if an authentication shall take place for the registration of different IMPUs e.g. belonging to same or different service profiles. Regarding the definition of service profiles cf. TS 23.228.
Up

6.1.1  Authentication of an IM-subscriberp. 20

Before a user can get access to the IM services at least one IMPU needs to be registered and the IMPI authenticated in the IMS at application level. In order to get registered the UE sends a SIP REGISTER message towards the SIP registrar server i.e. the S-CSCF, cf. Figure 1, which will perform the authentication of the user. The message flows are the same regardless of whether the user has an IMPU already registered or not.
Copy of original 3GPP image for 3GPP TS 33.203, Fig. 4: The IMS Authentication and Key Agreement for an unregistered IM subscriber and successful mutual authentication with no synchronization error
Up
The detailed requirements and complete registration flows are defined in TS 24.229 and TS 24.228.
SMn stands for SIP Message n and CMm stands for Cx message m which has a relation to the authentication process:
SM1:
REGISTER(IMPI, IMPU)
In SM2 and SM3 the P-CSCF and the I-CSCF respectively forwards the SIP REGISTER towards the S-CSCF.
After receiving SM3, if the IMPU is not currently registered at the S-CSCF, the S-CSCF needs to set the registration flag at the HSS to initial registration pending. This is done in order to handle UE terminated calls while the initial registration is in progress and not successfully completed. The registration flag is stored in the HSS together with the S-CSCF name and user identity, and is used to indicate whether a particular IMPU of the user is unregistered or registered at a particular S-CSCF or if the initial registration at a particular S-CSCF is pending. The registration flag is set by the S-CSCF sending a Cx-Put to the HSS. If the IMPU is currently registered, the S-CSCF shall leave the registration flag set to registered. At this stage the HSS has performed a check that the IMPI and the IMPU belong to the same user.
Upon receiving the SIP REGISTER the S-CSCF shall use an Authentication Vector (AV) for authenticating and agreeing a key with the user. If the S-CSCF has no valid AV then the S-CSCF shall send a request for AV(s) to the HSS in CM1 together with the number m of AVs wanted where m is at least one.
CM1:
Cx-AV-Req(IMPI, m)
Upon receipt of a request from the S-CSCF, the HSS sends an ordered array of n authentication vectors to the S-CSCF using CM2. The authentication vectors are ordered based on sequence number. Each authentication vector consists of the following components: a random number RAND, an expected response XRES, a cipher key CK, an integrity key IK and an authentication token AUTN. Each authentication vector is good for one authentication and key agreement between the S-CSCF and the IMS user.
CM2:
Cx-AV-Req-Resp(IMPI, RAND1||AUTN1||XRES1||CK1||IK1,….,RANDn||AUTNn||XRESn||CKn||IKn)
When the S-CSCF needs to send an authentication challenge to the user, it selects the next authentication vector from the ordered array, i.e. authentication vectors in a particular S-CSCF are used on a first-in / first-out basis.
The S-CSCF sends a SIP 4xx Auth_Challenge i.e. an authentication challenge towards the UE including the challenge RAND, the authentication token AUTN in SM4. It also includes the integrity key IK and the cipher key CK for the P-CSCF. RFC 3310 and RFC 4169 specifies how to populate the parameters of an authentication challenge. The S-CSCF shall offer both "AKAv2-SHA-256" RFC 4169 and "AKAv1-MD5" RFC 3310 starting with "AKAv2-SHA-256" as most preferred. The S-CSCF also stores the RAND sent to the UE for use in case of a synchronization failure. To maintain backwards compatibility with pre Rel-17 releases, "AKAv1-MD5" is supported but not recommended to use.
The verification of the SQN by the USIM and ISIM will cause the UE to reject an attempt by the S-CSCF to re-use a AV. Therefore no AV shall be sent more than once.
SM4:
4xx Auth_Challenge(IMPI, RAND, AUTN, IK, CK)
When the P-CSCF receives SM5 it shall store the key(s) and remove that information and forward the rest of the message to the UE i.e.
SM6:
4xx Auth_Challenge(IMPI, RAND, AUTN)
Upon receiving the challenge, SM6, the UE takes the AUTN, which includes a MAC and the SQN. The UE calculates the XMAC and checks that XMAC=MAC and that the SQN is in the correct range as in TS 33.102. If both these checks are successful the UE selects the first algorithm it supports and uses RES and some other parameters to calculate an authentication response. The UE needs to support "AKAv2-SHA-256".This response is put into the Authorization header and sent back to the registrar in SM7. RFC 4169 and RFC 3310 specify how to populate the parameters of the response for "AKAv2-SHA-256" and "AKAv1-MD5" respectively. It should be noted that the UE at this stage also computes the session keys CK and IK. To maintain backwards compatibility, "AKAv1-MD5" is supported but not recommended to use.
SM7:
REGISTER(IMPI, Authentication response)
The P-CSCF forwards the authentication response in SM8 to the I-CSCF, which queries the HSS to find the address of the S-CSCF. In SM9 the I-CSCF forwards the authentication response to the S-CSCF.
Upon receiving SM9 containing the response, the S-CSCF retrieves the active XRES for that user and uses this to check the authentication response sent by the UE as described in RFC 3310 and RFC 4169. If the check is successful then the user has been authenticated and the IMPU is registered in the S-CSCF. If the IMPU was not currently registered, the S-CSCF shall send a Cx-Put to update the registration-flag to registered. If the IMPU was currently registered the registration-flag is not altered.
It shall be possible to implicitly register IMPU(s). (see clause 4.3.3.4 in TS 23.228). All the IMPU(s) being implicitly registered shall be delivered by the HSS to the S-CSCF and subsequently to the P-CSCF. The S-CSCF shall regard all implicitly registered IMPU(s) as registered IMPU(s).
When an IMPU has been registered this registration will be valid for some period of time. Both the UE and the S-CSCF will keep track on a timer for this purpose but the expiration time in the UE is smaller than the one in the S-CSCF in order to make it possible for the UE to be registered and reachable without interruptions. A successful registration of a previously registered IMPU (including implicitly registered IMPUs) means the expiry time of the registration is refreshed.
If the user has been successfully authenticated, the S-CSCF sends a SM10 SIP 2xx Auth_OK message to the I-CSCF indicating that the registration was successful. In SM11 and SM12 the I-CSCF and the P-CSCF respectively forward the SIP 2xx Auth_OK towards the UE.
It should be noted that the UE initiated re-registration opens up a potential denial-of-service attack. That is, an attacker could try to register an already registered IMPU and respond with an incorrect authentication response in order to make the HN de-register the IMPU. For this reason a subscriber, when registered, shall not be de-registered if it fails an authentication.
The lengths of the IMS AKA parameters are specified in clause 6.3.7 of TS 33.102.
Up

6.1.2  Authentication failuresp. 22

6.1.2.1  User authentication failurep. 22

In this case the authentication of the user should fail at the S-CSCF due an incorrect response (received in SM9). However, if the response is incorrect, then the IK used to protect SM7 will normally be incorrect as well, which will normally cause the integrity check at the P-CSCF to fail before the response can be verified at S-CSCF. In this case SM7 is discarded by the IPsec layer at the P-CSCF.
If the integrity check passes but the response is incorrect, the message flows are identical up to and including SM9 as a successful authentication. Once the S-CSCF detects the user authentication failure it should proceed in the same way as having received SM9 in a network authentication failure (see clause 6.1.2.2).
Up

6.1.2.2  Network authentication failurep. 23

In this clause the case when the authentication of the network is not successful is specified. When the check of the MAC in the UE fails the network can not be authenticated and hence registration fails. The flow is identical as for the successful registration in clause 6.1.1 up to SM6.
Copy of original 3GPP image for 3GPP TS 33.203, Fig. 5:
Figure 5
(⇒ copy of original 3GPP image)
Up
The UE shall send a Register message towards the HN including an indication of the cause of failure in SM7. The P-CSCF and the I-CSCF forward this message to the S-CSCF.
SM7:
REGISTER(Failure = AuthenticationFailure, IMPI)
Upon receiving SM9, which includes the cause of authentication failure, the S-CSCF shall clear the S-CSCF name in the HSS, if the IMPU is currently Not registered. To clear the S-CSCF name the S-CSCF sends in CM3 a Cx-Put to the HSS. The S-CSCF does not update the registration flag.
CM3:
Cx-AV-Put(IMPI, Clear S-CSCF name)
The HSS responds to CM3 with a Cx-Put-Resp in CM4.
In SM10 the S-CSCF sends a 4xx Auth_Failure towards the UE indicating that authentication has failed, no security parameters shall be included in this message.
SM10:
SIP/2.0 4xx Auth_Failure
Up

6.1.2.3  Incomplete authenticationp. 24

When the S-CSCF receives a new REGISTER request and challenges this request, it considers any previous authentication to have failed. It shall delete any information relating to the previous authentication, although the S-CSCF may send a response if the previous challenge is answered. A challenge to the new request proceeds as described in clause 6.1.1.
If the S-CSCF does not receive a response to an authentication challenge within an acceptable time, it considers the authentication to have failed. The update to the HSS is performed in the same way as if receiving an SM9 indicating authentication failure (see message CM3 in clause 6.1.2.2).
Up

6.1.3  Synchronization failurep. 24

In this clause the case of an authenticated registration with synchronization failure is described. After re-synchronization, authentication may be successfully completed, but it may also happen that in subsequent attempts other failure conditions (i.e. user authentication failure, network authentication failure) occur. In below only the case of synchronization failure with subsequent successful authentication is shown. The other cases can be derived by combination with the flows for the other failure conditions.
Copy of original 3GPP image for 3GPP TS 33.203, Fig. 6:
Figure 6
(⇒ copy of original 3GPP image)
Up
The flow equals the flow in clause 6.1.1 up to SM6. When the UE receives SM6 it detects that the SQN is out of range and sends a synchronization failure back to the S-CSCF in SM7. RFC 3310 describes the fields to populate corresponding parameters of synchronization failure.
SM7:
REGISTER(Failure = Synchronization Failure, AUTS, IMPI)
Upon receiving the Synchronization Failure and the AUTS the S-CSCF sends an Av-Req to the HSS in CM3 including the RAND stored by the S-CSCF and the required number of Avs, m.
CM3:
Cx-AV-Req(IMPI, RAND,AUTS, m)
The HSS checks the AUTS as in clause 6.3.5 of TS 33.102. After potentially updating the SQN, the HSS sends new AVs to the S-CSCF in CM4.
CM4:
Cx-AV-Req-Resp(IMPI, n,RAND1||AUTN1||XRES1||CK1||IK1,….,RANDn||AUTNn||XRESn||CKn||IKn)
When the S-CSCF receives the new batch of authentication vectors from the HSS it deletes the old ones for that user in the S-CSCF.
The rest of the messages i.e. SM10-SM18 including the Cx messages are exactly the same as SM4-SM12 and the corresponding Cx messages in clause 6.1.1.
Up

6.1.4  Network Initiated authenticationsp. 25

In order to authenticate an already registered user, the S-CSCF shall send a request to the UE to initiate a re-registration procedure. When received at the S-CSCF, the re-registration shall trigger a new IMS AKA procedure that will allow the S-CSCF to re-authenticate the user.
Copy of original 3GPP image for 3GPP TS 33.203, Fig. 7:
Figure 7
(⇒ copy of original 3GPP image)
Up
The UE shall initiate the re-registration on the reception of the Authentication Required indication. In the 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.

6.1.5  Integrity protection indicatorp. 25

In order to decide whether a REGISTER request from the UE needs to be authenticated, the S-CSCF needs to know about the integrity protection applied to the message. The P-CSCF attaches an indication to the REGISTER request to inform the S-CSCF that the message was integrity protected if:
  • the P-CSCF receives a REGISTER containing an authentication response and the message is protected with an SA created during this authentication procedure; or
  • the P-CSCF receives a REGISTER not containing an authentication response and the message is protected with an SA created by latest successful authentication (from the P-CSCF perspective).
For all other REGISTER requests the P-CSCF attaches an indication that the REGISTER request was not integrity protected.
Up

6.2  Confidentiality mechanismsp. 26

If the local policy in P-CSCF requires the use of IMS specific confidentiality protection mechanism between UE and P-CSCF, IPsec ESP as specified in RFC 4303 shall provide confidentiality protection of SIP signalling between the UE and the P-CSCF, protecting all SIP signalling messages at the IP level. IPsec ESP general concepts on Security Policy management, Security Associations and IP traffic processing as described in reference RFC 4301 shall also be considered. ESP confidentiality shall be applied in transport mode between UE and P-CSCF. Dummy packets (Next Header = 59) shall not be sent.
The method to set up ESP security associations (SAs) during the SIP registration procedure is specified in clause 7. As a result of an authenticated registration procedure, two pairs of unidirectional SAs between the UE and the P-CSCF all shared by TCP and UDP, shall be established in the P-CSCF and later in the 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 SA is for traffic between a client port at the P-CSCF and a server port at the UE. For a detailed description of the establishment of these security associations see clause 7.
The encryption key CKESP is the same for the two pairs of simultaneously established SAs. The encryption key CKESP is obtained from the keying material established as a result of the AKA procedure, specified in clause 6.1, using a suitable key expansion function. This key expansion function depends on the ESP encryption algorithm and is specified in Annex I of this specification.
The encryption key expansion on the user side is done in the UE. The encryption key expansion on the network side is done in the P-CSCF.
Up

6.3  Integrity mechanismsp. 26

IPsec ESP as specified in reference RFC 4303 shall provide integrity protection of SIP signalling between the UE and the P-CSCF, protecting all SIP signalling messages at the IP level. IPsec ESP general concepts on Security Policy management, Security Associations and IP traffic processing as described in reference RFC 4301 shall also be considered. ESP integrity shall be applied between UE and P-CSCF either in transport mode if no NAT is present or - if NAT traversal shall be supported - in UDP encapsulated tunnel mode. ESP integrity can be provided by an integrity algorithm or an authenticated encryption algorithm, see RFC 4106.
The method to set up ESP security associations (SAs) during the SIP registration procedure is specified in clause 7. As a result of an authenticated registration procedure, two pairs of unidirectional SAs between the UE and the P-CSCF, all shared by TCP and UDP, shall be established in the P-CSCF and later in the 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 SA is for traffic between a client port at the P-CSCF and a server port at the UE. For a detailed description of the establishment of these security associations see clause 7.
The integrity key IKESP is the same for the two pairs of simultaneously established SAs. The integrity key IKESP is obtained from the keying material established as a result of the AKA procedure, specified in clause 6.1, using a suitable key expansion function. This key expansion function depends on the ESP integrity algorithm and is specified in Annex I of this specification.
The integrity key expansion on the user side is done in the UE. The integrity key expansion on the network side is done in the P-CSCF.
The anti-replay service shall be enabled in the UE and the P-CSCF on all established SAs.
Up

6.4  Hiding mechanismsp. 26

The Hiding Mechanism is optional for implementation. All I-CSCFs/IBCFs in the HN shall share the same encryption and decryption key Kv. If the mechanism is used and the operator policy states that the topology shall be hidden the I-CSCF/IBCF shall encrypt the hiding information elements when the I-CSCF/IBCF forwards SIP Request or Response messages outside the hiding network's domain. The hiding information elements are entries in SIP headers, such as Via, Record-Route, Route and Path, which contain addresses of SIP proxies in hiding network. When I-CSCF/IBCF receives a SIP Request or Response message from outside the hiding network's domain, the I-CSCF/IBCF shall decrypt those information elements that were encrypted by I-CSCF/IBCF in this hiding network domain.
The purpose of encryption in network hiding is to protect the identities of the SIP proxies and the topology of the hiding network. Therefore, an encryption algorithm in confidentiality mode shall be used. The network hiding mechanism will not address the issues of authentication and integrity protection of SIP headers. The AES in CBC mode with 128-bit block and 128-bit key shall be used as the encryption algorithm for network hiding. In the CBC mode under a given key, if a fixed IV is used to encrypt two same plaintexts, then the ciphertext blocks will also be equal. This is undesirable for network hiding. Therefore, random IV shall be used for each encryption. The same IV is required to decrypt the information. The IV shall be included in the same SIP header that includes the encrypted information.
Up

6.5  CSCF interoperating with proxy located in a non-IMS network |R6|p. 27

SIP signalling protected by TLS specified in RFC 3261 may be used for protecting the SIP interoperation between an IMS-CSCF with a proxy/CSCF located in a foreign network. The CSCF may request the TLS connection with a foreign Proxy by publishing sips: URI in DNS server, that can be resolved via NAPTR/SRV mechanism specified in RFC 3263. When sending/receiving the certificate during the TLS handshaking phase, the CSCF shall verify the name on the certificate against the list of the interworking partners.
The TLS session could be initiated from either network. A TLS connection is capable of carrying multiple SIP dialogs.
Applying this method is to prevent attacks on SIP level, but it does not prohibit other security methods to be applied so as to strengthen the security for IP based networks. This part is specified in Annex A of TS 33.210.
Up

Up   Top   ToC