AKA Digest authentication scheme for VoLTE (IMS)

When a VoLTE client needs to connect to IMS network, it has to authenticate the network while network also needs to make sure that only the correct user is registered to its network. AKA Digest is one of the scheme to authenticate VoLTE client to the IMS server

AKA

AKA stands for "Authentication and key agreement". This scheme comes from the legacy 3gpp networks and has been widely used in LTE, 3G, CDMA and WiMAX technologies. In this mechanism, a secret key is already known to both user device (USIM, iSIM) and authentication servers (HSS, HLR). 

The server will challenge the end user using AKA algorithms and shared key and sends RAND, AUTN values towards UE. UE will authenticate network and prepares result (RES for network to authenticate UE) with the help of shared key in UICC and parameters sent by Server.

HTTP Digest

Http Digest is the popular authentication scheme used for authenticating users to access web servers and other applications which requires security and data integrity. This scheme is much secure than the basic authentication as it applies hash function to the password before sending it [RFC2617]. 

HTTP Digest is username / password based authentication procedure. The authentication server provides one time created " nonce " value to the client. The client uses the nonce value and creates a secure response that contains  the password, username and other parameters to the server. The password which is known both to server and client, is always fixed

Now For IMS

Now since IMS is a part of 3GPP and on the contrary SIP signaling defines http digest for authentication [RFC3261]. Therefore in order to use 3GPP AKA with IMS, the parameters from AKA are mapped onto http digest [RFC3310]. In simple words the parameters / headers used to transport http digest information, will transport AKA information in identical format

With 3GPP AKA digest, the "nonce" now contains RAND, AUTN. The password now contains the one time RESPONSE generated by client with help of UICC (USIM, ISIM). Thus the method is even more secure. 

Authentication in IMS networks

• VoLTE Client sends SIP register request to IMS Server. The user is not authenticated at this  point. The SIP register request contains IMS related identities (private identity, public identity, URI, etc)

• The IMS server (S-CSCF) obtains authentication vector and SQN from HSS that contains a random challenge RAND, authentication token AUTN, expected authentication result XRES, a session key for integrity check IK, and a session key for encryption CK

• The server creates an authentication request, which contains the random challenge RAND, and the network authenticator token AUTN

• The authentication request is delivered to the client with "401 UNAUTHORIZED" message

• The client verifies the AUTN with the ISIM. If the verification is successful, the network has been authenticated. The client then produces an authentication response RES, using the shared secret K and the random challenge RAND

3GPP AKA Operation in IMS

• The authentication response RES is delivered to the server using new regiser sip message

• The server compares the authentication response RES with the expected response. If the two match, the user has been successfully authenticated

• Session keys IK and CK can be used for protecting further communications between the client and the server

• Server sends "200 OK" message to inform the VoLTE client about successful registration