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.
Editor's Note: The above statement conflicts with the use of GIBA as an allowed mechanism for UMTS access.
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
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.
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:
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 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.
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.
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  specifies how to populate the parameters of an authentication challenge. The S CSCF also stores the RAND sent to the UE for use in case of a synchronization failure.
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.
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.
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 uses RES and some other parameters to calculate an authentication response. This response is put into the Authorization header and sent back to the registrar in SM7.RFC 3310  specifies how to populate the parameters of the response. It should be noted that the UE at this stage also computes the session keys CK and IK.
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 . 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 18.104.22.168 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