<<

. 122
( 132 .)



>>

Security within the IMS is provided as an overlay on top of the PS domain. There are
¬ve needs for security, as shown in Figure 9.26 (from TS 33.203):

1. Mutual authentication between the ISIM and the HSS. The HSS delegates the
authentication function to the S-CSCF but is responsible for generating authentication
challenges based on the subscriber™s private key.
2. Mutual authentication and integrity checking for messages between the UA and the
P-CSCF.
3. Mutual authentication and integrity checking for messages between the I-CSCF,
S-CSCF and the HSS
4. Mutual authentication and integrity checking for messages between the P-CSCF and
the S-CSCF/I-ISCF where the P-CSCF is sited within a visited network
600 RELEASE 5 AND BEYOND (ALL-IP)


HSS

ISIM 1


I-CSCF 3
P-CSCF
3
4/5
2
UA

5
4/5



S-CSCF
Visited/Home Serving/
UE network Home network


Figure 9.26 IMS security architecture

5. Mutual authentication and integrity checking for messages between the P-CSCF and
the S-CSCF/I-ISCF where the P-CSCF is sited within the home network

Security for IMS service can be split into three areas, as follows.

• IMS access security (1 and 2 in Figure 9.26): controls UE access to the network, and
is used to protect against service theft and denial of service attacks. Also protects
messages between the UE and P-CSCF. This is described in Sections 9.7.2 and 9.7.3.
• IP network domain security (3,4, and 5 in Figure 9.26): securing signalling between
IMS network elements. Security for these links is provided by the use of IPSec and
IKE over the Za and Zb interfaces and is described in Section Section 9.4.
• Application security: providing end-to-end security for a user application, e.g. encryp-
tion of a multimedia call. This is negotiated end-to-end. Application security is not
de¬ned by 3GPP and developers are free to choose their own techniques. There are
already a number of working and fully implemented security protocols for use by IP
applications, namely IPSec for VPN service, TLS for secure web access, S/MIME for
email authentication and encryption, and RTP encryption for multimedia calls



9.7.2 P-CSCF assignment
Before the user can register they must establish the address of the P-CSCF. There are
two ways this can be done, using DHCP and DNS (see Section 9.5.7) or directly using
the PDP context establishment procedure. Alternatively, the address of the P-CSCF can
be contained within the protocol con¬guration options additional parameters list of the
PDP context accept. This will be quicker than DHCP/DNS but requires a little more
9.7 UMTS IMS CALL SIGNALLING 601



DHCP DNS
UE GGSN
server server

PDP Context activation

DHCP query
DHCP query
DHCP response
DHCP response

DNS query
DNS query
DNS response
DNS response



Figure 9.27 P-CSCF assignment using DHCP


complexity at the GGSN. For example, it may have to assign a P-CSCF address based
on load sharing. The message ¬‚ow for DHCP and DNS is shown in Figure 9.27.



9.7.3 IMS registration

Before the user can make use of the IMS, they must register with their home S-CSCF.
This provides them with two services, an outgoing S-CSCF for mobile originated calls
and a registration entry within the S-CSCF of their current contact address for mobile
terminated calls. As the registration procedure is carried out, the user is also authenticated.
The authentication procedure takes place between the subscriber™s ISIM and the HSS. The
technique uses the same algorithm as standard UMTS authentication (see Section 6.21);
however, the subscriber™s identity values and secret key are different. The following
de¬nitions are relevant to the discussion:

• IM public identity (IMPU): essentially the user™s SIP public address which is used to
route calls to the subscriber.
• IM private identity (IMPI): an identity used internally within the network for registra-
tion, admission and accounting purposes. It is not used for routing SIP calls.
• IM services identity module (ISIM): an UICC application which performs security func-
tions (e.g. authentication) for the IMS.
• Private key: encryption key shared between the HSS and ISIM, used to authentication
both parties.

The IMPU, IMPI and private key are stored securely within the ISIM and cannot be
modi¬ed. For a UE which does not have an ISIM application, the IMPU and IMPI can be
derived from the IMSI as described in Section 9.5.1. The IMS registration/authentication
procedure is shown in Figure 9.28.
602 RELEASE 5 AND BEYOND (ALL-IP)


UE

P-CSCF
ISIM UA I-CSCF S-CSCF HSS


Register
Register
Cx - user authentication request
From: IMPU
IMPU, IP address, IMPU, IMPI, P-CSCF, visited-network-ID
To: IMPU
IMPI, domain, Cx - user authentication answer
Contact: IP address
reg status
visited-network-ID
Username: IMPI
Register
Cx-MAR
Domain: home IMPU, IP address,
IMPI, domain Cx-MAA
401 unauthorised
401 unauthorised RAND+AUTN+IKE+CK
401 unauthorised RAND+AUTN+IKE+CK
Challenge RAND+AUTN
RAND
Response
Register
R1
Register
From: IMPU Cx - query
Response: R1
IMPU, IMPI, P-CSCF
To: IMPU
Cx - query-response
Contact: IP address
reg status
Username: IMPI Register
Cx - Put registration
Response: R1
Domain: home
IMPU, IMPI, S-CSCF
200 OK
Response: R1
200 OK
200 OK



Figure 9.28 IMS registration/authentication


The UE initially builds a REGISTER request. The URI for this request points to the
registrar at the user™s home domain e.g. sip:registrar.oribitage.com. The request also
contains the user™s public and private identity (IMPU, IMPI), their assigned IP address
in the visited network and home domain. The P-CSCF appends an identity for the visited
network and then uses the URI to forward the request to the UA™s home I-CSCF.
The I-CSCF is responsible for forwarding all registration requests to the S-CSCF.
Before doing this it checks if the user is allowed access to the IMS by sending a Cx user
authorization request (UAR) to the HSS. This message contains the user™s public and
private identity, as well as the visited network ID. The HSS responds with information
about the subscriber™s registration in the Cx-UAA response (see Table 9.7). For users
who are already registered the response contains the name of the S-CSCF assigned; this
is then used to forward the REGISTER request. For users who are not registered the
I-CSCF must assigning an S-CSCF. If S-CSCF capabilities are present in the Cx-query
response these are then used by the I-CSCF to determine which S-CSCF within its pool
can be assigned. The format and use of the S-CSCF capabilities is not speci¬ed by 3GPP
and their use is operator/vendor dependent. It is possible at this stage for the HSS to
disallow the registration in two ways. Either the user is unknown or the registration is
rejected (e.g. in the case of a visited network having no IMS roaming agreement with the
home network).
If the I-CSCF determines the registration is permitted it must then assign an S-CSCF
to the user (in the case of an unregistered user) and then forward the REGISTER request.
The S-CSCF is responsible for terminating the SIP registration requests (i.e. it is a
SIP registrar) as well as performing the authentication checks for the subscribers. Before
authentication can proceed the S-CSCF must obtain authentication vectors for the user
9.7 UMTS IMS CALL SIGNALLING 603


Table 9.7 Information elements in a Cx-UAA message
Name Description
Registration status (mandatory) Registration status of user; possible values are
unknown, allowed, reject and registered already
S-CSCF name (only present if Name of S-CSCF for users who are already
status = registered already) registered
S-CSCF capabilities (Optional) Capability requirements for S-CSCF


from the HSS. It does this by sending a Cx-MAR request to the HSS. This request contains
the user™s public and private identity. The HSS responds with the authentication data, i.e.
AUTN, RAND, XRES, IK and CK.
The AUTN value authenticates the HSS to the UE. The RAND value is used as a
challenge and the XRES is the expected response. CK and IK are the cipher key and
integrity key, respectively. For more information about these parameters please refer
to Section 6.21. The S-CSCF then sends a SIP 401 unauthorized response back, which
contains the random challenge value (RAND) plus the authentication token AUTN as well
as IK and CK values. The 401 response is routed back to the UA via the I-CSCF and
P-CSCF. Note that the P-CSCF removes the IK and CK before forwarding the response.
These values are used as shared secrets between the P-CSCF and the UE to provide
integrity checking (and optionally privacy protection) for all future SIP signalling. The
IK and CK values are generated by the UE using its private key and the RAND value.
The UA within the UE then uses the random challenge and requests the ISIM to produce
the appropriate authentication response. It also sends the ISIM the AUTN token so that
the appropriate checks on network authentication can be performed. Note that the private
key is contained within the ISIM. This protects against illicit copying. The ISIM then
sends the UA the response R1 to the challenge. The UA then produces a new registration
request, this time containing the authentication data R1. The authenticated registration is
then sent back to the S-CSCF. The S-CSCF checks that the value R1 = XRES and if so
the user is authenticated and the 200 OK con¬rming the registration sent in reply. The
S-CSCF also updates the registration status of the user at the HSS by sending the Cx-put
message. This contains a noti¬cation of the registration event at the server. Possible values
are registered, unregistered, unregistered due to timeout, and authentication failure.
Note that the authentication procedure is done twice in this case, once when establishing
the GPRS context and secondly when connecting to the IMS. This separation of the
authentication domains allows for more ¬‚exibility. For example, a user could send an
authenticated registration request to the I-CSCF even if they are connected not via GPRS
but using a ¬xed-line service. This is because the security is handled within SIP and is
not dependent on the access technology (¬xed line or wireless).



9.7.4 IMS mobile originated call
The mobile originated call is always routed via the S-CSCF. This is to ensure network
accounting integrity (see Section 9.2.1). The mobile originated requests are routed from
604 RELEASE 5 AND BEYOND (ALL-IP)


the UE to the P-CSCF then either directly to the S-CSCF or to the I-CSCF, which then
forwards them to the S-CSCF. The use of the I-CSCF in call signalling is useful since it
allows an operator to hide the internal structure of their network for security reasons. Note
for all call ¬‚ows shown in this section only message transfers within the IMS are shown.
Figure 9.29 shows the call ¬‚ow for a mobile originated call routed without the aid of
the I-CSCF. The initial INVITE message from the UE contains SDP containing a list
of CODECs that the UE wants to support for the call as well as the QoS request. The
P-CSCF then forwards the request to the S-CSCF. No QoS authorization is attempted at


P-CSCF S-CSCF
UE UE
visited home net
INVITE
100 TRYING
INVITE
100 TRYING

Evaluation
filter criteria
INVITE

<<

. 122
( 132 .)



>>