o The GPRS Charging IDs are passed by the outbound SIP proxy to the
serving SIP proxy and the Application Servers using SIP signaling.
They are not transferred from one home IMS (e.g., caller’s home)
to another (e.g., callee’s home).
o Inter Operator Identifiers (IOI) are shared between the caller’s
home IMS and the callee’s home IMS to provide identifiers of the
home originating and home terminating networks.
4.18.4. Collection of Session Detailed Information
The SIP serving proxy or another SIP server in the home network must
be able to log details of all sessions, such as the duration, source,
and destination of a session, to provide to the charging subsystem.
4.19. General Support of Additional Capabilities
4.19.1. Additional Capabilities
3GPP is interested in applying and using additional services, such as
those described in SIP Call Control - Transfer [20], SIP Basic Call
Flow Examples [21], SIP Public Switched Telephone Network (PSTN) Call
Flows [22], and SIP service examples [23]. Although 3GPP is not
going to standardize additional services, 3GPP may make sure that the
capabilities that enable those services are granted in the network.
Therefore, we believe that the SIP REFER method [24] and the Replaces
header [25] constitute a complement to be used as an enabler in order
to meet the above requirement.
4.19.2. DTMF Signaling
Support for voice calls must provide a level of service similar to
that of the existing circuit-based voice service. This includes the
ability to use DTMF signaling, for example, for control of
interactive voice response systems such as ticket sales lines and
timetable information.
The transport of DTMF tones from the mobile terminal to target
systems that may be in the PSTN, or to SIP-based solutions (i.e., no
PSTN connection), must be supported.
The transport of DTMF signals may be required for the whole call,
just for the first part, or from some later point in the call. The
start time and duration of such signaling is therefore unpredictable.
We believe that the mechanisms specified in RFC 2833 [8] meet the
requirement without impacting SIP.
4.19.3. Early Media
As mobile terminals will frequently interoperate with the PSTN,
support for early media is required.
4.20. Exchange of Session Description
Typically a session description protocol such as SDP is used in SIP
to describe the media streams and codecs needed to establish the
session. SIP uses an offer/answer model of the session description,
as described in RFC 3264 [11], in which one of the parties offers his
session description and the other answers that offer.
In the 3GPP IMS, the mobile terminals might have restrictions with
the memory, DSP capacity, etc. As such, a mechanism is required by
which the Session Description negotiation may conclude with one out
of many codecs per media stream. Both UAC and UAS must know, prior
to any media being sent or received, which codec is used for each
media stream.
In the 3GPP IMS, efficient use of the network and radio resources is
an important requirement. As such, the network should know in
advance which codec is used for a particular media stream. The
network access control may use this information to grant access to
the network and to control the resource utilization.
Additionally, it is required that the party who pays for the resource
utilization have the opportunity to decide which codecs to use, once
both end parties are aware of the capabilities supported at the
remote UA.
Therefore, a mechanism is required by which both UAC and UAS have the
ability to negotiate and trim down the number of codecs used per
media stream, so that at the end of the negotiation there can be a
reduced set of agreed codecs per media stream.
We believe that the mechanism specified in RFC 3264 [11] meets the
requirement.
4.21. Prohibition of Certain SDP Parameters
4.21.1. Prohibition of Codecs
The SIP outbound proxy may contain local policy rules with respect
the codecs allowed in the network. For instance, certain networks
may disallow high-bandwidth-consuming audio codecs. There has to be
a mechanism whereby the SIP outbound proxy can reject a session
establishment attempt when a codec is prohibited in the network due
to local policy.
4.21.2. Prohibition of Media Types
Certain users’ subscriptions may include restrictions on certain
media types. For instance, a user may not be allowed to establish a
video session. The SIP serving proxy in the home network downloads
the user profile, which contains the rules for these kinds of
restrictions.
As the establishment of sessions traverse the SIP serving proxy in
the home network, the proxy can prohibit an attempt to establish a
session that includes a non-allowed media type for the user.
Therefore, there has to be a mechanism whereby the SIP serving proxy
can reject a session establishment attempt when the session includes
a forbidden media type.
4.22. Network-initiated Re-authentication
Network operators need to authenticate users to ensure that they are
charged appropriately for the services they use. The
re-authentication done when the user initiates a message will not
suffice for this purpose, as described below.
If the duration of the authentication period is set to a relatively
low value to ensure that the user cannot incur a high amount of
charges between two authentications, it may create a lot of
unnecessary authentications of users that have remained largely
inactive, and therefore it may use unnecessary air interface
resources.
If the duration of the authentication period is set to a relatively
high value to avoid these unnecessary authentications, the risk is
then that some users may incur high charges between authentications.
A user’s authentication is automatically invalidated when a certain
threshold for charges (or number, or duration of sessions) is reached
without giving the user a chance to re-authenticate, even if a valid
registration exists. This would not provide an adequate level of
service.
Consequently, it must be possible for the network to initiate a
re-authentication process at any time. The triggers must be set
within the network and may include charging thresholds, number of
events, session duration, etc.
4.23. Security Model
Sections 4.23, 4.24, and 4.25 have been based on the 3GPP Technical
Specifications 33.203 [32], 23.228 [28], and 33.210 [33].
The scope for security of the 3GPP IMS is the SIP signaling between
the various SIP entities. Protecting the end-to-end media streams
may be a future extension, but it is not considered in the Release 5
version of the IMS specifications.
Each operator providing IMS services acts as its own domain of trust
and shares a long-term security association with its subscribers
(e.g., pre-shared keys). Operators may enter into roaming agreements
with other operators, in which case a certain level of trust exists
between their respective domains.
SIP UAs must authenticate to their home network before the use of IMS
resources is authorized. In Release 5 of the 3GPP IMS
specifications, authentication is performed during registration and
re-registrations.
Portions of the SIP signaling must be protected hop by hop. Looking
at Figure 1 in Section 3, we can distinguish two distinct zones where
the required security is unique:
o Access Domain: Between the SIP user device and the visited
network.
o Network Domain: Between the visited and home networks, or inside
the home network.
Characteristics needed in the Access Domain are quite different from
those of the Network Domain because of the terminal’s requirements
for mobility, computation restriction, battery limit, bandwidth
conservation, and radio interface. SIP entities in the access domain
should be able to maintain security contexts with a large group of
users in parallel. Furthermore, Access Domain provides user-specific
security associations, whereas Network Domain provides security
associations between network nodes. Therefore, the weight of
protocols and algorithms and their compliance with compression
mechanisms are very important to Access Domain Security. It is
therefore required that the security solutions allow different
mechanisms in these two domains.
4.24. Access Domain Security
4.24.1. General Requirements
4.24.1.1. Scalability and Efficiency
3GPP IMS is characterized by a large subscriber base of up to a
billion users, all of which must be treated in a secure manner.
The security solutions must allow global roaming among a large number
of administrative domains.
4.24.1.2. Bandwidth and Round-trips
The wireless interface in 3GPP terminals is an expensive resource
both in terms of power consumption and maximum use of scarce
spectrum. Furthermore, cellular networks typically have long
round-trip time delays, which must be taken in account in the design
of the security solutions.
Any security mechanism that involves 3GPP terminals should not
unnecessarily increase the bandwidth needs.
All security mechanisms that involve 3GPP terminals should minimize
the number of necessary extra round-trips. In particular, during
normal call signaling there should not be any additional security-
related messages.
4.24.1.3. Computation
It must be possible for mobile device terminals to provide security
without requiring public key cryptography and/or certificates. 3GPP
IMS may, however, include optional security schemes that employ these
techniques.
Current HTTP authentication methods use only symmetric cryptography,
as required here. Lower-layer mechanisms (IKE, TLS) require
implementation of public-key cryptography e.g., Diffie-Hellman. If
these lower-layer mechanisms were used, the mobile terminal would
authenticate and negotiate session keys with the visited network
using only symmetric methods.
4.24.1.4. Independence of the Transport Protocol
The selected security mechanism should work with any transport
protocol allowed by SIP (e.g., TCP, UDP).
4.24.2. Authentication
Authentication, as used in this context, means entity authentication
that enables two entities to verify the identity of the respective
peer.
4.24.2.1. Authentication Method
A strong, mutual authentication must be provided.
The authentication method must be able to work when there are zero or
more SIP proxies in the SIP path between the authenticator and the
authenticated user.
It must be possible to support extensible authentication methods.
Therefore, authentication using an extensible authentication
framework is strongly recommended.
Authentication methods based on the secure storage of long-term keys
used for authentication and the secure execution of authentication
algorithms must be supported.
The SIP client’s credentials must not be transferred as plain text.
3GPP intends to reuse UMTS AKA [13]. UMTS AKA applies a symmetric
cryptographic scheme, provides mutual authentication, and is
typically implemented on a so-called SIM card that provides secure
storage on the user’s side.
Additional requirements related to message protection that apply to
the authentication method are stated in Section 4.24.3.
4.24.3. Message Protection
4.24.3.1. Message Protection Mechanisms
SIP entities (typically a SIP client and a SIP proxy) must be able to
communicate using integrity. By integrity, we mean the ability for
the receiver of a message to verify that the message has not been
modified in transit. SIP entities should be able to communicate
confidentially. In 3GPP IMS, these protection modes must be based on
initial authentication. Integrity protection and confidentiality
must be possible using symmetric cryptographic keys.
It must also be possible to handle error conditions in a satisfactory
manner as to allow recovery (see also sections 4.3.6.3 and 4.14).
It must be possible to provide this protection between two adjacent
SIP entities. In future network scenarios, it may also be necessary
to provide this protection through proxies, though the 3GPP Release 5
IMS does not require this.
The security mechanism must be able to protect a complete SIP
message.
If header compression/removal or SIP compression is applied to SIP
messages, it must be compatible with message protection.
4.24.3.2. Delegation
3GPP IMS implements distributed security functions responsible for
authentication and message protection.
It must be possible to perform an initial authentication based on
long-term authentication credentials, followed by subsequent
protected signaling that uses short-term authentication credentials,
such as session keys created during initial authentication. The
authentication mechanism used is able to provide such session keys.
It must be possible to apply subsequent message protection as soon as
possible, even during the initial authentication period.
Initial authentication is performed between the SIP UA and the
authenticating SIP serving proxy in the home network. However, the
authentication mechanism must not require access to the long-term
authentication credentials in these nodes. In the home network, the
authenticating SIP serving proxy must support interaction with a
dedicated authentication server in order to accomplish the
authentication task. At the client side, a secured
(tamper-resistant) device storing the long-term credentials of the
user must perform the authentication.
Additionally, the SIP serving proxy that performed the initial
authentication must be able to delegate subsequent SIP signaling
protection (e.g., session keys for integrity or encryption) securely
to an authorized SIP proxy further downstream. The tamper-resistant
device at the client side must be able to delegate the session keys
securely to the SIP UA.
4.24.4. Negotiation of Mechanisms
A method must be provided to negotiate the security mechanisms to be
used in the access domain securely.
This method must at least support the negotiation of different
security mechanisms providing integrity protection and encryption,
algorithms used within these mechanisms, and additional parameters
that they require in order to be exchanged.
The negotiation mechanism must protect against attackers who do not
have access to authentication credentials. In particular, the
negotiation mechanism must be able to detect a possible
man-in-the-middle attacker who could influence the negotiation result
so that services with weaker security or with none are negotiated.
A negotiation mechanism is generally required in all secure protocols
to decide which security services to use and when they should be
started. This security mechanism serves algorithm and protocol
development as well as interoperability. Often, the negotiation is
handled within a security service. For example, the HTTP
authentication scheme includes a selection mechanism for choosing
among appropriate algorithms. Note that when referring to
negotiation we mean just the negotiation, not all functions in
protocols such as IKE. For instance, we expect that the session key
generation is to be a part of the initial authentication.
SIP entities must be able to use the same security mode parameters to
protect several SIP sessions without re-negotiation. For example,
security mode parameters may be assumed to be valid within the
lifetime of a registration. Note that it is necessary to amortize
the cost of security association setup and parameter negotiation over
several INVITEs.
4.24.5. Verification of Messages
4.24.5.1. Verification at the SIP Outbound Proxy
The SIP outbound proxy must be able to guarantee the message origin
and to verify that the message has not been changed (e.g., it is
integrity protected).
4.24.5.2. Verification at the SIP Serving Proxy
The serving SIP proxy needs to receive an indication if the outbound
proxy was able to verify the message origin and, in the case of a
REGISTER request, whether or not it was integrity protected.
4.25. Network Domain Security
Message authentication, key agreement, integrity and replay
protection, and confidentiality must be provided for communications
between SIP network entities such as proxy servers.
Network domain security mechanisms must be scalable up to a large
number of network elements.
3GPP intends to make having the protection discussed above mandatory
at least between two operators, and optional within an operator’s own
network. Security gateways exist between operator’s networks.
We believe that the above requirements are fulfilled by applying
security mechanisms as specified in the current IP Security standards
in RFC 2401 [5].
5. Security Considerations
This document does not define a protocol, but still presents some
security requirements to protocols. The main security requirements
are stated in sections 4.23, 4.24, and 4.25. Additional
security-related issues are discussed under sections 4.6, 4.7, 4.8,
4.9, 4.10, and 4.12.
6. Contributors
The following people contributed to this document:
Duncan Mills (Vodafone), Gabor Bajko (Nokia), Georg Mayer (Siemens),
Francois-Xerome Derome (Alcatel), Hugh Shieh (AWS), Andrew Allen
(dynamicsoft), Sunil Chotai (mmO2), Keith Drage (Lucent), Jayshree
Bharatia (Nortel), Kevan Hobbis (Huthison 3G UK), Dean Willis
(dynamicsoft), Krisztian Kiss (Nokia), Vesa Torvinen (Ericsson), Jari
Arkko (Ericsson), and Sonia Garapaty (Nortel).
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
7.2. Informative References
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[5] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[6] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[7] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September
2000.
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[13] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication and
Key Agreement (AKA)", RFC 3310, September 2002.
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Registrations", RFC 3680, March 2004.
[15] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[16] Marshall, W., "Private Session Initiation Protocol (SIP)
Extensions for Media Authorization", RFC 3313, January 2003.
[17] Jennings, C., Peterson, J., and M. Watson, "Private Extensions
to the Session Initiation Protocol (SIP) for Asserted Identity
within Trusted Networks", RFC 3325, November 2002.
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[19] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol (SIP)
Servers", RFC 3319, July 2003.
[20] Sparks, R., "Session Initiation Protocol Call Control -
Transfer", Work in Progress, February 2005.
[21] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Basic Call Flow
Examples", BCP 75, RFC 3665, December 2003.
[22] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
Summers, "Session Initiation Protocol (SIP) Public Switched
Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666,
December 2003.
[23] Johnston, A. and R. Sparks, "Session Initiation Protocol
Service Examples", Work in Progress, February 2005.
[24] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[25] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) ’Replaces’ Header", RFC 3891, September 2004.
[26] 3GPP, "TS 23.003 Numbering, addressing and identification
(Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[27] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service
Description; Stage 2", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.060/>.
[28] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
[29] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call
control based on SIP and SDP", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[30] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) -
Release 5", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[31] 3GPP, "TS 32.225: Telecommunication Management; Charging
Management; Charging Data Description for IP Multimedia
Subsystem; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[32] 3GPP, "TS 32.203: 3G Security; Access security for IP based
services; (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.203/>.
[33] 3GPP, "TS 32.210: 3G Security; Network Domain Security; IP
network layer security (Release 5)", September 2002,
<ftp://ftp.3gpp.org/Specs/archive/33_series/33.210/>.
[34] ITU-T, "Recommendation E.164 (05/97): The international public
telecommunication numbering plan", May 1997,
<http://www.itu.int/rec/recommendation.asp?
type=folders&lang=e&parent=T-REC-E.164>.
[35] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
Author’s Address
Miguel A. Garcia-Martin
Nokia
P.O. Box 407
NOKIA GROUP, FIN 00045
Finland
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an