5 Security
Chapter 5 Security Topic
Page
IMS authentication ......................................................................................... 159 SIP confidentiality and integrity .................................................................... 164 SIP Digest ...................................................................................................... 166 SIP Digest with TLS ...................................................................................... 169 GPRS-IMS-Bundled Authentication (GIBA) ................................................ 170 Generic Authentication Architecture (GAA) ................................................. 174
157
IMS/RCS Technology
This page is intentionally left blank
158
5 Security
IMS authentication authentication In a 3GPP network environment, even when an IMS subscriber has passed the PS domain authentication, the IMS subscriber's identity (IMPI) must be confirmed by the IMS authentication again before accessing IMS services. Both the PS domain and the IMS authentications are necessary for the IMS subscriber. This is referred to as a two-pass authentication. However, the PS domain authentication is carried out by the Authentication and Key Agreement (AKA) of the 3GPP, called 3GPP AKA; the IMS authentication is carried out by IMS AKA.
IMSI
IMPI
UMTS AKA
UTRAN / E-UTRAN
IMS
IMS AKA
Figure 5-1 3GPP AKA & IMS AKA
UMTS AKA & IMS AKA [33.203] The mechanism for mutual authentication in UMTS is called UMTS Authentication and Key Agreement (UMTS AKA). It is a challenge response protocol and the HLR/AuC in the HPLMN derives the challenge. An Authentication Vector (AV) containing the challenge is sent from the HLR/AuC to the VPLMN MSC/VLR or SGSN. The AV contains the expected response XRES and also a message authentication code MAC. The MSC/VLR or SGSN compares the response from the UE with the XRES and if they match the UE has been authenticated. The UE calculates an expected MAC, XMAC, and compares this with the received MAC and if they match the UE has authenticated the serving network. The AKA-protocol is a secure protocol developed for UMTS and the same concept and principles are reused for the IMS, where it is called IMS AKA. The UE can be authenticated at anytime via the registration or re-registration procedures. 159
IMS/RCS Technology
Procedure [33.203] The initial SIP messaging (SIP REGISTER and associated response) is carried in the clear text (i.e. not encrypted). The response to the first SIP REGISTER message contains a challenge for the user and key information for the P-CSCF. The P-CSCF removes the key information before forwarding the response to the user. The user calculates a response to the challenge and uses this calculated information to encrypt all future SIP control messages. The user sends a new register request encrypted, including the challenge response. The P-CSCF uses the key information to decrypt the message and forward it in the clear toward the S-CSCF. The S-CSCF examines the response to authenticate the user. In the downstream direction, the P-CSCF uses the keys to encrypt the SIP messages before forwarding them to the user. P-CSCF REGISTER
I-CSCF REGISTER
S-CSCF
HSS
UAR/UAA REGISTER
(RAND, AUTN) 401 UNAUTH.
(RAND, AUTN, CK, IK) 401 UNAUTHORIZED.
MAR/MAA (RAND, AUTN, XRES, CK, IK) 401 UNAUTHORIZED (RAND, AUTN, CK, IK)
MAC=XMAC REGISTER
REGISTER
(RES)
(RES)
UAR/UAA REGISTER (RES) RES=XRES SAR/SAA
200 OK
200 OK
200 OK
Figure 5-2 IMS AKA (successful)
User authentication failure In case the authentication of the user fails at the S-CSCF due an incorrect RES1, the S-CSCF clears the S-CSCF name in the HSS and sends a SIP 4xx AUTHENTICATION FAILURE towards the UE indicating that authentication has failed. 1 However, if the RES is incorrect, then the IK used to protect the second REGISTER message will normally be incorrect as well, which will normally cause the integrity check at the P-CSCF to fail before the RES can be verified at S-CSCF. In this case the second REGISTER message is discarded by the IPsec layer at the P-CSCF.
160
5 Security
P-CSCF REGISTER
REGISTER
S-CSCF
HSS
I-CSCF UAR/UAA
REGISTER
(RAND, AUTN)
(RAND, AUTN, CK, IK)
401 UNAUTH.
401 UNAUTHORIZED
REGISTER (RES)
MAR/MAA (RAND, AUTN, XRES, CK, IK) 401 UNAUTHORIZED (RAND, AUTN, CK, IK)
REGISTER (RES)
UAR/UAA REGISTER (RES) RES≠XRES SAR/SAA
4xx AUTH. FAIL.
4xx AUTH. FAILURE
4xx AUTHENTICATION FAILURE
Figure 5-3 IMS AKA (user authentication failure)
Network authentication failure 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 (see Fig. 5-4). The UE send the second SIP REGISTER message including an indication of the cause of failure (Failure = AuthenticationFailure).
Synchronisation failure When the UE receives SIP 401 AUTHENTICATION REQUIRED it detects that the SQN is out of range and sends a Synchronisation Failure back to the S-CSCF including AUTS (see Fig. 5-5). Upon receiving the Synchronisation Failure and the AUTS the S-CSCF sends a MAR with AV request to the HSS in including the RAND stored by the S-CSCF, AUTS received from UE and the required number of AV. The HSS checks the AUTS and after updating the SQN, the HSS sends new AVs to the S-CSCF. When the S-CSCF receives the new batch of AVs from the HSS it deletes the old ones and the procedure continues with the new AV.
161
IMS/RCS Technology
P-CSCF REGISTER
REGISTER
S-CSCF
HSS
I-CSCF UAR/UAA
REGISTER
(RAND, AUTN)
(RAND, AUTN, CK, IK)
401 UNAUTH.
401 UNAUTHORIZED
MAR/MAA (RAND, AUTN, XRES, CK, IK) 401 UNAUTHORIZED (RAND, AUTN, CK, IK)
MAC≠XMAC REGISTER
REGISTER
(Auth. Failure)
UAR/UAA
(Auth. Failure)
REGISTER (Auth. Failure) SAR/SAA
4xx AUTH. FAIL.
4xx AUTH. FAILURE
4xx AUTHENTICATION FAILURE
Figure 5-4 IMS AKA (network authentication failure)
P-CSCF REGISTER
HSS
I-CSCF REGISTER
S-CSCF
UAR/UAA REGISTER
(RAND, AUTN)
(RAND, AUTN, CK, IK)
401 UNAUTH.
401 UNAUTHORIZED
MAR/MAA (RAND, AUTN, XRES, CK, IK) 401 UNAUTHORIZED (RAND, AUTN, CK, IK)
SQN out of range REGISTER
REGISTER
(Synch. Fail., AUTS)
UAR/UAA (Synch. Failure, AUTS) REGISTER (Syn. Failure, AUTS) (AUTS, RAND) (RAND, AUTN, XRES, CK, IK)
Figure 5-5 IMS AKA (synchronisation failure)
162
5 Security
ISIM For the purposes of IMS AKA the following implementation options are permitted for ISIM: •
Use of a distinct ISIM application on a UICC which does not share security functions with the USIM;
•
Use of a distinct ISIM application on a UICC which does share security functions with the USIM;
•
Use of a USIM application on a UICC.
If there is an ISIM application and a USIM application on a UICC, then the ISIM application shall always be used for IMS authentication.
Sharing security functions and data with the USIM When an ISIM application is used for IMS access, only the following options for sharing security functions and data are permitted: •
No security functions or data are shared;
•
Only the sequence number checking mechanism is shared;
•
Only the algorithm is shared;
•
Only the algorithm and sequence number checking mechanism are shared;
The authentication key, authentication functions and the sequence number checking mechanism are shared. When a USIM is used for IMS access the authentication key, authentication functions and the sequence number checking mechanism are shared. If the authentication keys and functions are shared, the cipher/integrity key sets generated during authentication are used with different cipher/integrity algorithms in CS/PS domain and IMS. Note that the same cipher/integrity key set is never used for both CS/PS domain and IMS because the authentication and key agreement protocol is run independently between CS/PS domain and IMS. Therefore there is no danger that the compromise of the cipher/integrity algorithm in one domain would lead to vulnerabilities in the other domain. If the mechanism and data for checking sequence numbers are shared then it is required for the authentication failure rate due to synchronization failures to be kept sufficiently low. In particular, the mechanism shall be required to support interleaving authentication in three domains (CS, PS and IMS).
163
IMS/RCS Technology
SIP confidentiality and integrity If the local policy in P-CSCF requires the use of IMS specific confidentiality and integrity protection mechanism, IPsec Encapsulating Security Payload (ESP) is used between the UE and the P-CSCF, protecting all SIP signalling messages at the IP level. ESP confidentiality and integrity are applied in transport mode between UE and P-CSCF. Support of SIP signalling encryption and integrity protection is mandatory for both the UE and the P-CSCF. 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, are 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. The encryption key CKESP is the same for the two pairs of simultaneously established SAs. The encryption key CKESP is obtained from the key CKIM established as a result of the AKA procedure, using a key expansion function. 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. The encryption algorithm is either DES-EDE3-CBC or AES-CBC with 128 bit key. Both encryption algorithms shall be supported by both, the UE and the P-CSCF. The integrity key IKESP is the same for the two pairs of simultaneously established SAs. The integrity key IKESP is obtained from the key IKIM established as a result of the AKA procedure, using a key expansion function. 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 integrity algorithm is either HMAC-MD5-96 (key length 128 bits) or HMAC-SHA-1-96 (key length 160 bits). Both integrity algorithms shall be supported by both, the UE and the P-CSCF.
Security association setset-up For protecting IMS signalling between the UE and the P-CSCF it is necessary to agree on shared keys that are provided by IMS AKA, and a set of parameters specific to a protection method. The security mode setup is used to 164
5 Security
negotiate the SA parameters required for IPsec ESP with authentication and confidentiality. S-CSCF
P-CSCF REGISTER
REGISTER
(port numbers, UE integrity and encryption algorithms list) 401 AUTHORIZATION REQUIRED (RAND, AUTN, port numbers, P-CSCF integrity and encryption algorithms list) CK, IK
401 AUTHORIZATION REQUIRED (RAND, AUTN, CK, IK)
CK, IK algorithms selected by P-CSCF
Security Assoc. 1 algorithms selected by UE
Security Assoc. 2
Figure 5-6 Security association set-up The UE sends a REGISTER message towards the S-CSCF to register the location of the UE and to set-up the security mode. In order to start the security mode set-up procedure, the UE includes a Security-setup-line in this message. The Security-setup-line contains the Security Parameter Index values and the protected ports selected by the UE. It also contains a list of identifiers for the integrity and encryption algorithms, which the UE supports. In order to determine the integrity and encryption algorithm the P-CSCF proceeds as follows: the P-CSCF has a list of integrity and encryption algorithms it supports, ordered by priority. The P-CSCF selects the first algorithm combination on its own list which is also supported by the UE. If the UE did not include any confidentiality algorithm in REGISTER message then the P-CSCF shall either select the NULL encryption algorithm or abort the procedure, according to its policy on confidentiality. The Security-setup-line in the SIP 401 AUTHORISATION REQUIRED contains the SPIs and the ports assigned by the P-CSCF. It also contains a list of identifiers for the integrity and encryption algorithms, which the P-CSCF supports. The UE determines the integrity and encryption algorithms as follows: the UE selects the first integrity and encryption algorithm combination on the list received from the P-CSCF which is also supported by the UE. If the P-CSCF did not include any confidentiality algorithm in then the UE shall select the NULL encryption algorithm. 165
IMS/RCS Technology
From that moment two Security Associations (SAs) exists between the UE and the P-CSCF. The SA 1 is used for the procedures in which the UE acts as a client and P-CSCF acts as a server (e.g. registration or MO call set-up). The integrity and encryption algorithms for the SA 1 are selected by P-CSCF and indicated inside IPsec header. The SA 2 is used for the procedures in which the P-CSCF acts as a client and the UE acts as a server (e.g. MT call set-up). The integrity and encryption algorithms for SA 2 are selected by UE and indicated inside IPsec header. P-CSCF REGISTER 401 AUTHORIZATION REQUIRED
200 OK
INVITE
unprotected
server
client
REGISTER
protected by SA 1 protected by SA 2
100 TRYING 183 SESSION IN PROGRESS
100 TRYING 183 SESSION IN PROGRESS
client
server
INVITE
Figure 5-7 SA 1 and SA 2 usage
SIP Digest [33.203] SIP Digest [RFC 3261] is an authentication method that applies only to non-3GPP access networks. SIP Digest achieves mutual authentication between the UE and the HN, and is based on HTTP Digest [RFC 2617]. The identity used for authenticating a subscriber is the private identity, IMPI, which has the form of a NAI. The HSS and the UE share a preset secret (e.g., a password) associated with the IMPI.
166
5 Security
P-CSCF REGISTER
I-CSCF REGISTER
S-CSCF
HSS
UAR/UAA REGISTER MAR/MAA (IMPI, realm, algorithm, qop, HA1)
401 UNAUTH.
401 UNAUTHORIZED
401 UNAUTHORIZED
(IMPI, realm, nonce, algotithm, qop) REGISTER
REGISTER
UAR/UAA REGISTER
(realm, nonce, response, cnonce, nonce-count, algorithm, digest-uri) response = expected response SAR/SAA 200 OK
200 OK
200 OK (response’)
response’ = expected response’
Figure 5-8 SIP Digest
HA1=MD5(A1)=MD5(username:realm:password) HA2=MD5(A2)=MD5(method:digestURI) response=MD5(HA1:nonce:moce-count:cnonce:qop:HA2) username = IMPI realm = HN domain name digestURI = SIP URI of the domain name of the HN qop = auth method = REGISTER algorithm = MD5
Figure 5-9 SIP Digest (variables) Upon receiving the first SIP REGISTER the S-CSCF shall use a SIP Digest Authentication Vector (SD-AV) for authenticating the user. If the S-CSCF has no valid SD-AV for the specific IMPI, then the S-CSCF sends a request for SD-AV to the HSS. Upon receipt of a request from the S-CSCF, the HSS sends one SD-AV to the S-CSCF. The SD-AV consists of the quality of protection (qop) value, the
167
IMS/RCS Technology
authentication algorithm, realm, and a hash, called HA1, of the IMPI, realm, and password. The qop value shall be set to "auth" since SIP Digest, as used in IMS, can only provide authentication, not message integrity. The S-CSCF generates a random nonce, stores HA1 and the nonce against the IMPI, and then sends the SIP 401 UNAUTHORIZED including nonce and other authentication challenge parameters (realm, qop, algorithm) towards the UE. Upon receiving the challenge, the UE generates a cnonce (client nonce). It then uses the cnonce as well as parameters provided in the SIP 401 UNAUTHORIZED such as nonce and qop to calculate an authentication response. This response and other parameters are put into the Authorization header in the second SIP REGISTER message and sent back towards the network. Upon receiving the second SIP REGISTER message containing the response, the S-CSCF calculates the expected response using the previously stored HA1 and stored nonce together with other parameters contained in the message (e.g., cnonce, nonce-count, qop) and uses this to check against the response sent by the UE. If the check is successful then the user has been authenticated and the IMPU is registered in the S-CSCF. If the user has been successfully authenticated, the S-CSCF sends a SIP 200 OK message indicating that the registration was successful. The SIP 200 OK message contains the “response-digest”, which allows the UE to authenticate the HN. The “response-digest” value is calculated as for the “request-digest”, except that the cnonce value is the one provided by the UE. Upon receiving SIP 200 OK, the UE calculates the expected response from the HN. To authenticate the HN, the UE compares its expected response to the response provided by the HN. If the comparison fails the UE shall abort the communication.
168
5 Security
SIP Digest with TLS SIP Digest [RFC 3261] with Transport Layer Security (TLS) [RFC 5246] is an authentication, integrity and confidentiality protection method that applies only to non-3GPP access networks. In this method SIP Digest authentication and TLS security session set-up are integrated with the SIP registration procedure. P-CSCF REGISTER
I-CSCF REGISTER
(TLS support)
S-CSCF
HSS
UAR/UAA REGISTER MAR/MAA (IMPI, realm, algorithm, qop, HA1)
401 UNAUTHORIZED
401 UNAUTH.
401 UNAUTHORIZED
(IMPI, realm, nonce, algotithm, qop, TLS support)
integrity and confidentiality prot.
TLS handshake REGISTER
REGISTER
UAR/UAA REGISTER
(realm, nonce, response, cnonce, nonce-count, algorithm, digest-uri) response = expected response
TLS session ID ↔ UE’s IP, port #, IMPI, IMPUs
SAR/SAA 200 OK
200 OK 200 OK
(response’)
response’ = expected response’
Figure 5-10 SIP Digest with TLS Up to and including message received by the UE, the procedures for the SIP Digest cases with and without TLS are identical, except for the additional parameters in messages and indicting the support of TLS in UE and P-CSCF. After receiving message , when TLS was selected by the P-CSCF, the UE performs a TLS handshake with the P-CSCF. After successful establishment of a TLS connection, the UE sends the second SIP REGISTER message over this TLS connection. After successful SIP Digest authentication performed at S-CSCF, the SIP 200 OK message is sent towards UE.
169
IMS/RCS Technology
When P-CSCF receives the SIP 200 OK message, indicating successful authentication, it associates the UE's IP address and port of the TLS connection with the TLS Session ID, the IMPI and all the successfully registered IMPUs related to that IMPI. From this point on, the P-CSCF does not accept any SIP signalling messages outside the TLS connection other than SIP REGISTER and messages relating to emergency services. After the UE has received SIP 200 OK message it does not accept any SIP signalling messages outside the TLS connection other than responses to REGISTER messages and messages relating to emergency services.
GPRSGPRS-IMSIMS-Bundled Authentication (GIBA) (GIBA) Although full support of 3GPP IMS security features is preferred from a security perspective, it is acknowledged that “early� IMS implementations will exist which do not support these features. Non-compliance with security features specified in 3GPP IMS is expected to be a problem mainly at the UE side, because of the potential lack of support of the USIM/ISIM interface (especially in 2G-only devices) and because of the potential inability to support IPsec on some UE platforms. Therefore, there is a need to ensure that simple, yet adequately secure, mechanisms are in place to protect against the most significant security threats that will exist in early IMS implementations. GPRS-IMS-Bundled Authentication (formerly called "early IMS security") is a security mechanisms developed for early IMS systems, that provides a lower level of protection compared with that offered by the fully compliant IMS security solution. Therefore GIBA is considered and migration to the fully compliant IMS security solution should take place as soon as suitable products become available at an acceptable cost.
GIBA Security Mechanism The GIBA security solution works by creating a secure binding in the HSS between the public/private user identity (SIP-level identity) and the IP address currently allocated to the user at the GPRS level (bearer/network level identity). Therefore, IMS level signalling, and especially the IMS identities
170
5 Security
claimed by a user, can be connected securely to the PS domain bearer level security context. The GGSN terminates each user's PDP context and has assurance that the IMSI used within this PDP context is authenticated. The GGSN shall provide the user's IP address (or the prefix in the case of IPv6), IMSI and MSISDN to a RADIUS server in the HSS over the Gi interface when a PDP context is activated towards the IMS system. The HSS has a binding between the IMSI and/or MSISDN and the IMPI and IMPU(s), and is therefore able to store the currently assigned IP address (or the prefix in the case of IPv6) from the GGSN against the user's IMPI and/or IMPU(s). The GGSN informs the HSS when the PDP context is deactivated/modified so that the stored IP address (or the prefix in the case of IPv6) can be updated in the HSS. When the S-CSCF receives a SIP registration request or any subsequent requests for a given IMPU, it checks that the IP address (or the prefix in the case of IPv6) in the SIP header (verified by the network) matches the IP address (or the prefix in the case of IPv6) that was stored against that subscriber's IMPU in the HSS. The mechanism assumes that the GGSN does not allow a UE to successfully transmit an IP packet with a source IP address (or the prefix in the case of IPv6) that is different to the one assigned during PDP context activation. In other words, the GGSN must prevent "source IP spoofing". The mechanism also assumes that the P-CSCF checks that the source IP address in the SIP header is the same as the source IP address in the IP header received from the UE (the assumption here, as well as for the full security solution, is that no NAT is present between the GGSN and the P-CSCF).
Message Flows Successful registration Fig. 5-11 below describes the message flow for successful registration to the IMS that is specified by the early IMS security solution.
171
IMS/RCS Technology
RADIUS client
GGSN
P-CSCF
S-CSCF
RADIUS server
Activate PDP Ctx. Req.
Accounting Request (IP, IMSI, MSISDN)
Activate PDP Ctx. Acc. (IP) IP
HSS
I-CSCF
SIP REGISTER via: „sent-by” IP, from: IMPU GGSN checks for IP address spoofing IP
SIP REGISTER via: „sent-by” IP, from: IMPU
P-CSCF checks src IP against „via” field SIP REGISTER via: „sent-by” IP, received: IP, from: IMPU UAR/UAA SIP REGISTER via: „sent-by” IP, received: IP, from: IMPU MAR (IMPU) HSS maps IMPU to IMSI or MSISDN to retrieve associated IP address MAA (IP) S-CSCF checks „received” IP or „sent-by” IP against IP address from HSS
Figure 5-11 GPRS-IMS-Bundled Authentication (GIBA) The UE starts by setting up a PDP context. The GGSN provides the user's IP address (or the prefix in the case of IPv6), IMSI and MSISDN to a RADIUS server in the HSS. When a PDP context has been set up successfully, the UE sends a SIP REGISTER. The SIP REGISTER message contains the IP address and the IMPU of the UE. The GGSN checks that the source IP address provided in the IP header of the IP packet carrying SIP REGISTER message matches the IP address allocated to the UE when the PDP context was set up. When the IP address has been verified, the GGSN forwards the IP packet carrying SIP REGISTER message to the P-CSCF.2 The P-CSCF checks the source IP address against the IP address in the Via header of the REGISTER message. If the source IP address differs from the IP address in the Via header, the P-CSCF adds the source IP address to a received parameter in the Via header. The P-CSCF then forwards the REGISTER to the I-CSCF in the home network.
2 The original text from 3GPP 33.203 „The GGSN checks that the IP address provided in the REGISTER message matches the IP address allocated to the UE when the PDP context was set up. When the IP address has been verified, the GGSN forwards the REGISTER message to the P-CSCF.”
172
5 Security
The I-CSCF contacts the HSS to authorize the UE. The HSS responds that the UE is authorized, and the I-CSCF forwards the SIP REGISTER message to the S-CSCF chosen to serve the UE. The S-CSCF contacts the HSS and indicates that GIBA is used to authenticate the UE. The HSS returns the stored IP address to the S-CSCF. The S-CSCF then checks the IP address returned by the HSS against the IP address obtained in the SIP REGISTER message (if present, the received by parameter shall be used). If the check is successful the registration procedure is continued as normally.
Restrictions imposed by GIBA The mechanism assumes that only one contact IP address is associated with one IMPI. Furthermore, the mechanism supports the case that there may be several IMPUs associated with one IMPI. In GIBA the IMS user authentication is performed by linking the IMS registration (based on an IMPI) to a PDP context (based on an authenticated IMSI). The mechanism here assumes that there is a one-to-one relationship between the IMSI for bearer access and the IMPI for IMS access. The GIBA mechanism further adds the requirement on the UE that it allows only one APN for accessing IMS for a PLMN and that all active PDP contexts, for a single UE, associated with that IMS APN use the same IP address at any given time. The GIBA mechanism relies on the Via header remaining unchanged between the UE and the S-CSCF for requests and responses sent in the direction from the UE to the S-CSCF. GIBA requires the GGSN to be in the home network. GIBA works with UEs that contain a SIM or a USIM, whereas full IMS security requires a USIM or ISIM. GIBA does not authenticate at the IMS level. Instead, it relies on bearer level security at the GPRS or UMTS PS level. Because there is no key agreement, IPsec security associations are not set up between UE and P-CSCF, as they are in the full IMS security solution. The solution works by binding the IMS level transactions to the GPRS or UMTS PS domain security association established at a GPRS or UMTS PS domain level. In doing so, it creates a dependency between SIP and the PS bearer, which does not exist with the full IMS security solution. This means that the interim solution does not provide as high a degree of access network independency as the full solution. In particular, the solution does not currently support scenarios where IMS services are offered over WLAN.
173
IMS/RCS Technology
GIBA derives the public user identity used in the SIP REGISTER request from the IMSI. Consequently, the same derived public user identity cannot be simultaneously registered from multiple terminals, using only GIBA registration procedures. However, simultaneous registration of a public user identity from one terminal using GIBA, and from other terminals using fully compliant IMS security is not precluded. Unlike in fully compliant IMS security, the private user identity is not included in the SIP REGISTER requests when GIBA is used for registration, re-registration and mobile-initiated de-registration procedures. Subsequently, all SIP REGISTER requests from the UE shall use the IMSI-derived IMPU as the public user identity even when the implicitly registered IMPUs are available at the UE. Otherwise, the I-CSCF would be unable to derive the private user identity that is needed to query the HSS.
Generic Authentication Architecture (GAA) [33.911] A number of applications share a need for mutual authentication between a client (i.e. the UE ) and an Application Server (AS) before further communication can take place. Examples include (but are not limited to) communication between a client and a Presence Server (possibly via an authentication proxy), communication with a PKI portal where a client requests a digital certificate, communication with a Mobile Broadcast / Multicast Service (MBMS) content server, etc.
GAA authentication XCAP traffic XDMS / PS / RLS
Figure 5-12 Generic Authentication Architecture (usage example) Since a lot of applications share this common need for a peer authentication mechanism, it has been considered useful to specify a Generic Authentication
174
5 Security
Architecture (GAA). This GAA describes a generic architecture for peer authentication that can a priori serve for any (present and future) application. There are generally speaking two types of authentication mechanisms. One is based on a secret shared between the communicating entities, the other one is based on (public, private) key pairs and digital certificates. Also in GAA these are the two options that are a priori available for mobile applications.
GAA Generic Authentication Architecture
Shared secret
Certificates
GBA
SSC
Generic Bootstrapping Architecture
Support for Subscriber Certificates
Figure 5-13 GAA mechanisms to issue authentication credentials There are several authentication protocols that rely on a pre-shared secret between the two communicating entities. Popular examples include HTTP Digest, Pre-Shared Key TLS, IKE with pre-shared secret and a priori any mechanism based on username and password. The main problem with these mechanisms is how to agree on this pre-shared secret. The 3GPP solution to this problem is Generic Bootstrapping Architecture (GBA), that describes how in a mobile context an AKA based mechanism can be used to provide both communicating entities with a pre-shared secret. An alternative to using shared secrets for authentication is to rely on asymmetric cryptography. This assumes that the entity that needs to be authenticated (one or both partners in the communication) possesses a (public, private) key pair and a corresponding digital certificate. The latter validates the key pair and binds the key pair to its legitimate owner. Well-known protocols whose authentication is based on (public, private) key pairs include PGP and HTTP over TLS (the later is commonly called by its protocol identifier, "HTTPS"). The main disadvantage of this type of authentication is that a PKI is needed and that asymmetric key cryptographic operations often require substantially more computational effort than symmetric key operations. The 3GPP solution to this problem is Support for Subscriber Certificates (SSC), that describes
175
IMS/RCS Technology
how a mobile operator can issue digital certificates to its subscribers (hence providing a basic PKI).
GBA [33.220] The Generic Bootstrapping Architecture (GBA) provides a general mechanism based on 3GPP AKA to install a shared secret between a UE and a server.
HSS Zh
SLF
Dz
BSF
Zn
Ub
NAF Ua
Figure 5-14 GBA architecture AKA is a very powerful mechanism that mobile networks make use of. GBA takes benefit of this mechanism and re-uses AKA to bootstrap application security. GBA introduces a new network element (NE) called the Bootstrapping Server Function (BSF). This BSF has an interface with the HSS. The UE runs AKA with the HSS via the BSF. From the resulting (CK, IK), a session key is derived in BSF and UE. An application server, called Network Application Function (NAF) can fetch this session key from the BSF together with subscriber profile information. In this way the application server (NAF) and the UE share a secret key that can subsequently be used for application security, in particular to authenticate UE and NAF at the start of the application session (possibly also for integrity and/or confidentiality protection). If only SIM cards or SIMs on UICC is available, and 2G_GBA is allowed, the BSF and UE mutually authenticates using the 2G AKA and TLS protocol. The BSF was introduced to keep the number of different types of NEs as well as the total number of NEs that retrieve AVs from the HSS to a minimum. One generic mechanism for different applications avoids a large diversity of mechanisms and allows to address security issues once and in a consistent way.
176
5 Security
Procedures [33.220] This section describes the format of the bootstrapping procedure that is further utilized by various applications. It contains the AKA authentication procedure with BSF, and the key material generation procedure.
Service discovery [23.003] The UE shall discover the BSF address from the identity information related to the UICC application that is used during the bootstrapping procedure i.e. IMSI for USIM, or IMPI for ISIM, as in Fig. 5-15. MCC
MNC
MSIN
IMSI: 234 15 0999999999 bsf.mnc015.mcc234.pub.3gppnetwork.org IMPI: user@operator.com bsf.operator.com Figure 5-15 BSF address (GBA) In the case where the USIM is used in bootstrapping, the BSF address shall be derived as follows:
Initiation of bootstrapping Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use the GBA. When a UE wants to interact with a NAF, but it does not know if the NAF requires the use of shared keys obtained by means of the GBA, the UE shall contact the NAF for further instructions.
NAF
Request Bootstrapping initiation required Figure 5-16 Initiation of bootstrapping (GBA)
177
IMS/RCS Technology
UE starts communication over reference point Ua with the NAF without any GBA-related parameters. If the NAF requires the use of shared keys obtained by means of the GBA, but the request from UE does not include GBA-related parameters, the NAF replies with a bootstrapping initiation message. The form of this indication may depend on the particular reference point Ua.
Bootstrapping procedures When a UE wants to interact with a NAF, and it knows that the bootstrapping procedure is needed, it shall first perform a bootstrapping authentication. Otherwise, the UE shall perform a bootstrapping authentication only when it has received bootstrapping initiation required message or a bootstrapping negotiation indication from the NAF, or when the lifetime of the key in UE has expired. BSF
HSS
Request (IMPI) MAR (IMPI) 401 Unauthorized (Digest: RAND, AUTN)
MAA (user profile, AV = RAND||AUTN||XRES||CK||IK)
Client runs AKA algorithm, verifies AUTN, derivies RES and other session keys Request (Digest: RES) BSF checks if RES=XRES 200 OK (B-TID, key lifetime)
Ks=CK||IK
Ks=CK||IK
Figure 5-17 Bootstrapping procedure (GBA) The UE sends an HTTP request towards the BSF. The UE includes IMPI in the "username" parameter. The BSF retrieves the complete set of GBA user security settings and one Authentication Vector (AV, AV = RAND||AUTN||XRES||CK||IK) from the HSS.
178
5 Security
In a multiple HSS environment, the BSF may have to obtain the address of the HSS where the subscription of the user is stored by querying the SLF, prior to step . Then BSF forwards the RAND and AUTN to the UE in the HTTP 401 message (without the CK, IK and XRES). This is to demand the UE to authenticate itself. The UE checks AUTN to verify that the challenge is from an authorised network; the UE also calculates CK, IK and RES. This will result in session keys IK and CK in both BSF and UE. The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF. The BSF authenticates the UE by verifying the Digest AKA response. The BSF generates key material Ks by concatenating CK and IK. The B-TID value shall be also generated in format of NAI by taking the base64 encoded RAND value from step , and the BSF server name, i.e. base64encode(RAND)@bsf.mnc<MNC>.mcc<MCC>.pub.3gppnetwork.org. The BSF shall send a HTTP 200 OK message, including a B-TID, to the UE to indicate the success of the authentication. In addition, in the HTTP 200 OK message, the BSF shall supply the lifetime of the key Ks. The key material Ks is generated in UE by concatenating CK and IK. Both the UE and the BSF shall use the Ks to derive the key material Ks_NAF. Ks_NAF shall be used for securing the reference point Ua. Ks_NAF = KDF (Ks, "gba-me" constant, RAND, IMPI, NAF_Id), where KDF is the key derivation function, and the key derivation parameters consist of the user's IMPI, the NAF_Id and RAND. The NAF_Id is constructed as follows: NAF_Id = FQDN of the NAF || Ua security protocol identifier. KDF shall be implemented in the ME. The UE and the BSF shall store the key Ks with the associated B-TID for further use, until the lifetime of Ks has expired, or until the key Ks is updated.
Procedures using bootstrapped Security Association [33.220], [29.109] Before communication between the UE and the NAF can start, the UE and the NAF first have to agree whether to use shared keys obtained by means of the GBA. If the UE does not know whether to use GBA with this NAF, it uses the Initiation of Bootstrapping procedure. Once the UE and the NAF have established that they want to use GBA then every time the UE wants to interact with an NAF the following steps are executed as depicted in Fig. 5-18.
179
IMS/RCS Technology
NAF
BSF
B-TID, Ks
B-TID, Ks, profile
Key derivation Ks â&#x2020;&#x2019; Ks_NAF Application request (B-TID)
Key derivation Ks â&#x2020;&#x2019; Ks_NAF BIR (B-TID, NAF-Id) BIA (Ks_NAF, profile, bootstrap time, key lifetime)
Server stores Ks_NAF, profile, bootstrap time, key lifetime Application answer
Figure 5-18 Bootstrapping usage procedure (GBA) The UE supplies the B-TID to the NAF, to allow the NAF to retrieve the corresponding keys from the BSF; In Diameter message Bootstrapping-Info-Request (BIR), the NAF requests key material from BSF corresponding to the B-TID supplied by the UE. In Diameter message Bootstrapping-Info-Answer (BIA), the BSF supplies to NAF the requested key Ks_NAF, as well as the bootstrapping time and the lifetime of that key. NAF continues with the protocol used over the reference point Ua with the UE. Once the run of the protocol used over reference point Ua is completed the purpose of bootstrapping is fulfilled as it enabled UE and NAF to use reference point Ua in a secure way.
SSC If a client wants to make use of asymmetric encryption technology, he needs a digital certificate that is created by a Certification Authority (CA). Such a certificate binds a public key to the identity of its legitimate owner and certifies the validity of the public key. If a mobile subscriber wants to have and make use of a (public, private) key pair, the key pair and a certificate should either be preloaded or the subscriber must have the means to either generate or obtain a key pair and dynamically obtain a corresponding digital certificate. The Support for Subscriber Certificates (SSC) specifies a mechanism to dynamically issue a digital certificate to a mobile subscriber. 180
5 Security
HSS Zh
SLF
Dz
BSF Ub
Zn
PKI portal (NAF) Ua
Figure 5-19 SSC architecture (certificate issuing) [33.221] To dynamically obtain a digital certificate a UE must send an appropriate certificate request to a PKI portal of his home operator, and the PKI portal must authenticate the certificate request. The certificate enrolment process i.e. the issuing of a certificate to a subscriber and the corresponding communication session between a UE and a PKI portal is in fact an example of a mobile application. As with many mobile applications it requires authentication of the communicating entities, in this case the UE and the PKI portal (the latter plays the role of the application server). As for any other application there are two options for this authentication: pre-shared secret based or based on asymmetric cryptography and certificates. The latter is only an option when a new certificate is requested from the PKI portal while another still valid certificate is already loaded in the UE. The former method requires a shared secret between the PKI portal and the UE. If the shared secret is not pre-configured, GBA can be used to obtain such a shared secret. The result of the process of issuing a certificate to a mobile subscriber is that the UE is loaded with a certificate corresponding to its (public, private) key pair. Once the certificate is in place it can be used (together with the corresponding key pair) to authenticate the UE. The key pair and the corresponding digital certificate can also be used for integrity protection (or less likely confidentiality).
181
IMS/RCS Technology
This page is intentionally left blank
182