Authentication and Authorization

In IMS, a user must register before being allowed to access services. At the initial registration, the mobile terminal and the S-CSCF perform mutual authentication by running the IMS AKA protocol [15]. The IMS AKA uses the long term key that is associated with the Private User Identity and that is shared between the ISIM and the HSS.

Figure 6.6 shows the IMS authentication procedure. The message sequence is the same as in the IMS registration shown in Figure 4.1, but here the relevant message and the authentication data are explicitly depicted.

Figure 6.6 shows the IMS authentication procedure. The message sequence is the same as in the IMS registration shown in Figure 4.1, but here the relevant message and the authentication data are explicitly depicted.

Ims Registration

Figure 6.6: IMS authentication.

In the initial REGISTER request (1) the mobile terminal indicates the Public User Identity (IMPU) it wants to register and the Private User Identity (IMPI). Normally the underlying access domain provides confidentiality protection for the link between the mobile terminal and a secured network node. This confidentiality protection helps to protect the privacy of the IMPI when transmitted over the radio interface. Upon receiving the registration request, the S-CSCF fetches AVs from the HSS, messages (6) and (7), in case it does not already have an AV available for that user. The IMS AKA AVs have the same format and content as those used in UMTS AKA (see Section 6.2.1). The S-CSCF sends RAND and AUTN as an authentication challenge in the response (8). CK and IK are also sent in the response but the P-CSCF removes them before forwarding the message to the terminal (10).

Upon receiving the authentication challenge, the IMS terminal instructs the ISIM (or USIM) to verify the AUTN (see Section 6.2.1). If the verification succeeds the network is considered authenticated and the ISIM outputs RES to the terminal. The terminal uses RES and some other parameters to calculate an authentication response as described in RFC 3310 HTTP Digest AKA [137]. The authentication response is sent to the network in a new

REGISTER request (11). Note that this is different from the UMTS AKA in which the RES is sent back to the network. The reason to use HTTP Digest AKA is that the AKA parameters need to be carried in SIP/HTTP messages, and the HTTP Digest framework fits that need nicely as it provides e.g. a challenge mechanism which can be used to carry AKA challenges.

In case the terminal fails to authenticate the network, an error message is instead sent to the network to indicate the failure.

Upon receipt of the new REGISTER request containing the authentication response, the S-CSCF retrieves the active XRES for that user, calculates the corresponding HTTP Digest AKA authentication response, and compares the result with the one received. If the values match the user is successfully authenticated and the Public User Identity is registered in the S-CSCF.

Re-authentication of the same user may or may not be required at re-registration, depending on the security policy of the operator.

0 0

Post a comment