IMS/RCS Technology

5 Security
157
ChapterChapterChapterChapter 5555
SecuritySecuritySecuritySecurity
TopicTopicTopicTopic PagePagePagePage
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

IMS/RCS Technology
158
This page is intentionally left blank

5 Security
159
IMS aIMS aIMS aIMS authenticationuthenticationuthenticationuthentication
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.
UTRAN /
IMS
UMTS AKA
IMS AKA
E-UTRANIMSI
IMPI
Figure 5-1 3GPP AKA & IMS AKA
UMTS AKA & IMS AKAUMTS AKA & IMS AKAUMTS AKA & IMS AKAUMTS 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.

IMS/RCS Technology
160
ProcedureProcedureProcedureProcedure
[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.
(RES)
401 UNAUTHORIZED
MAR/MAA
200 OK
SAR/SAA
REGISTER
UAR/UAA
REGISTER (RES)
REGISTER
REGISTER
401 UNAUTHORIZED.
HSSP-CSCF I-CSCF S-CSCF
401 UNAUTH.
REGISTERREGISTER
UAR/UAA
200 OK200 OK
(RAND, AUTN, XRES, CK, IK)
(RAND, AUTN, CK, IK)
(RAND, AUTN) (RAND, AUTN, CK, IK)
(RES)
RES=XRES
MAC=XMAC
Figure 5-2 IMS AKA (successful)
User authentication failureUser authentication failureUser authentication failureUser 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.

5 Security
161
(RES)
401 UNAUTHORIZED
4xx AUTHENTICATION FAILURE
SAR/SAA
REGISTER
UAR/UAA
REGISTER (RES)
REGISTER
REGISTER
401 UNAUTHORIZED
401 UNAUTH.
REGISTER
REGISTER
UAR/UAA
4xx AUTH. FAILURE4xx AUTH. FAIL.
(RES)
RES≠XRES
MAR/MAA
Figure 5-3 IMS AKA (user authentication failure)
Network authentication failureNetwork authentication failureNetwork authentication failureNetwork 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 failureSynchronisation failureSynchronisation failureSynchronisation 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.

IMS/RCS Technology
162
(Auth. Failure)
401 UNAUTHORIZED
4xx AUTHENTICATION FAILURE
SAR/SAA
REGISTER
UAR/UAA
REGISTER (Auth. Failure)
REGISTER
REGISTER
401 UNAUTHORIZED
401 UNAUTH.
REGISTER
REGISTER
UAR/UAA
4xx AUTH. FAILURE4xx AUTH. FAIL.
(Auth. Failure)
MAC≠XMAC
MAR/MAA
Figure 5-4 IMS AKA (network authentication failure)
(Synch. Failure, AUTS)
401 UNAUTHORIZED
(AUTS, RAND)
REGISTER
UAR/UAA
REGISTER (Syn. Failure, AUTS)
REGISTER
REGISTER
401 UNAUTHORIZED
401 UNAUTH.
REGISTER
REGISTER
UAR/UAA
(Synch. Fail.,
AUTS)
SQN out of range
MAR/MAA
Figure 5-5 IMS AKA (synchronisation failure)

5 Security
163
ISIMISIMISIMISIM
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 USIMSharing security functions and data with the USIMSharing security functions and data with the USIMSharing 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).

IMS/RCS Technology
164
SIPSIPSIPSIP confidentialityconfidentialityconfidentialityconfidentiality and integrityand integrityand integrityand 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 setSecurity association setSecurity association setSecurity association set----upupupup
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

5 Security
165
negotiate the SA parameters required for IPsec ESP with authentication and
confidentiality.
P-CSCF S-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)
Security Assoc. 1
CK, IK CK, IK
Security Assoc. 2
algorithms selected by P-CSCF
algorithms selected by UE
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.

IMS/RCS Technology
166
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.
183 SESSION IN PROGRESS
200 OK
REGISTER
183 SESSION IN PROGRESS
100 TRYING
100 TRYING
INVITE
REGISTER
P-CSCF
INVITE
client
server
server
client unprotected
protected by SA 1
protected by SA 2
Figure 5-7 SA 1 and SA 2 usage
SIP DigestSIP DigestSIP DigestSIP 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.

5 Security
167
401 UNAUTHORIZED
MAR/MAA
200 OK
SAR/SAA
REGISTER
UAR/UAA
REGISTER
REGISTER
REGISTER
401 UNAUTHORIZED
401 UNAUTH.
REGISTERREGISTER
UAR/UAA
200 OK200 OK
(IMPI, realm, algorithm, qop, HA1)
(IMPI, realm, nonce, algotithm, qop)
(realm, nonce, response, cnonce, nonce-count, algorithm, digest-uri)
response = expected response
(response’)
response’ = expected response’
Figure 5-8 SIP Digest
username = IMPI
realm = HN domain name
digestURI = SIP URI of the domain name of the HN
qop = auth
method = REGISTER
algorithm = MD5
HA1=MD5(A1)=MD5(username:realm:password)
HA2=MD5(A2)=MD5(method:digestURI)
response=MD5(HA1:nonce:moce-count:cnonce:qop:HA2)
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

IMS/RCS Technology
168
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.

5 Security
169
SIP Digest with TLSSIP Digest with TLSSIP Digest with TLSSIP 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.
200 OK
401 UNAUTH.
(IMPI, realm, nonce, algotithm, qop, TLS support)
REGISTER
(TLS support)
401 UNAUTHORIZED
MAR/MAA
200 OK
SAR/SAA
REGISTER
UAR/UAA
REGISTER
REGISTER
401 UNAUTHORIZED
REGISTERREGISTER
UAR/UAA
200 OK
(IMPI, realm, algorithm, qop, HA1)
(realm, nonce, response, cnonce, nonce-count, algorithm, digest-uri)
response = expected response
(response’)
response’ = expected response’
TLS handshake
TLS session ID ↔ UE’s
IP, port #, IMPI, IMPUs
integrityandconfidentialityprot.
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.

IMS/RCS Technology
170
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.
GPRSGPRSGPRSGPRS----IMSIMSIMSIMS----BundledBundledBundledBundled
Authentication (GAuthentication (GAuthentication (GAuthentication (GIBA)IBA)IBA)IBA)
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 MechanismGIBA Security MechanismGIBA Security MechanismGIBA 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

5 Security
171
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 FlowsMessage FlowsMessage FlowsMessage Flows
Successful registrationSuccessful registrationSuccessful registrationSuccessful registration
Fig. 5-11 below describes the message flow for successful registration to the
IMS that is specified by the early IMS security solution.

IMS/RCS Technology
172
MAA (IP)
SIP REGISTER via: „sent-by” IP, received: IP, from: IMPU
SIP REGISTER via: „sent-by” IP, from: IMPU
Activate PDP Ctx. Acc. (IP)
Activate PDP Ctx. Req.
Accounting Request (IP, IMSI, MSISDN)
SIP REGISTER via: „sent-by” IP, from: IMPUIP
GGSN checks for IP address spoofing
IP
P-CSCF checks src IP against „via” field
UAR/UAA
MAR (IMPU)
HSS maps IMPU to IMSI or MSISDN to retrieve associated IP address
S-CSCF checks „received” IP or „sent-by” IP against IP address from HSS
P-CSCF I-CSCF S-CSCFGGSNRADIUS client HSS
RADIUS server
SIP REGISTER via: „sent-by” IP, received: IP, from: IMPU
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.”

5 Security
173
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 GIBARestrictions imposed by GIBARestrictions imposed by GIBARestrictions 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.

IMS/RCS Technology
174
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.
GGGGeneric Authenticationeneric Authenticationeneric Authenticationeneric Authentication
Architecture (GAA)Architecture (GAA)Architecture (GAA)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.
XDMS / PS / RLS
GAA authentication
XCAP traffic
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

5 Security
175
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
Generic
Bootstrapping
Architecture
SSC
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

IMS/RCS Technology
176
how a mobile operator can issue digital certificates to its subscribers (hence
providing a basic PKI).
GBAGBAGBAGBA
[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.
BSF NAFSLF
HSS
Zh
Dz Zn
Ub 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.

5 Security
177
ProceduresProceduresProceduresProcedures
[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 discoveryService discoveryService discoveryService 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.
IMSI: 234 15 0999999999
MCC MNC MSIN
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 bootstrappingInitiation of bootstrappingInitiation of bootstrappingInitiation 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.
Bootstrapping initiation required
Request
NAF
Figure 5-16 Initiation of bootstrapping (GBA)

IMS/RCS Technology
178
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 proceduresBootstrapping proceduresBootstrapping proceduresBootstrapping 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.
MAA (user profile, AV =
RAND||AUTN||XRES||CK||IK)
MAR (IMPI)
Request (IMPI)
BSF HSS
401 Unauthorized
(Digest: RAND, AUTN)
Client runs AKA algorithm,
verifies AUTN, derivies RES
and other session keys
Request (Digest: RES)
BSF checks if RES=XRES
Ks=CK||IK
200 OK
(B-TID, key lifetime)
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.

5 Security
179
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 AssociationProcedures using bootstrapped Security AssociationProcedures using bootstrapped Security AssociationProcedures 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.

IMS/RCS Technology
180
BIR (B-TID, NAF-Id)
NAF
BIA (Ks_NAF, profile,
bootstrap time, key lifetime)
Application answer
Key derivation Ks → Ks_NAF
B-TID, Ks
BSF
B-TID, Ks, profile
Application request (B-TID)
Key derivation Ks → Ks_NAF
Server stores Ks_NAF, profile,
bootstrap time, key lifetime
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.
SSCSSCSSCSSC
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.

5 Security
181
BSF
PKI portal
(NAF)
SLF
HSS
Zh
Dz Zn
Ub
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).

IMS/RCS Technology
182
This page is intentionally left blank

IMS/RCS Technology

More Related Content

What's hot (11)

Viewers also liked (16)

Similar to IMS/RCS Technology (20)

Recently uploaded (20)

IMS/RCS Technology