GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4083

Network Working Group M. Garcia-Martin Request for Comments: 4083 Nokia Category: Informational May 2005

          Input 3rd-Generation Partnership Project (3GPP)
  Release 5 Requirements on the Session Initiation Protocol (SIP)

Status of This Memo

 This memo provides information for the Internet community.  It does
 not specify an Internet standard of any kind.  Distribution of this
 memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 The 3rd-Generation Partnership Project (3GPP) has selected Session
 Initiation Protocol (SIP) as the session establishment protocol for
 the 3GPP IP Multimedia Core Network Subsystem (IMS).  IMS is part of
 Release 5 of the 3GPP specifications.  Although SIP is a protocol
 that fulfills most of the requirements for establishing a session in
 an IP network, SIP has never been evaluated against the specific 3GPP
 requirements for operation in a cellular network.  In this document,
 we express the requirements identified by 3GPP to support SIP for
 Release 5 of the 3GPP IMS in cellular networks.

Garcia-Martin Informational [Page 1] RFC 4083 3GPP R5 Requirements on SIP May 2005

Table of Contents

 1. Introduction ....................................................4
 2. Conventions .....................................................4
 3. Overview of the 3GPP IMS ........................................5
 4. 3GPP Requirements on SIP ........................................7
    4.1. General Requirements .......................................7
         4.1.1. Efficient Use of the Radio Interface ................7
         4.1.2. Minimum Session Setup Time ..........................7
         4.1.3. Minimum Support Required in the Terminal ............8
         4.1.4. Roaming and Non-roaming .............................8
         4.1.5. Terminal Mobility Management ........................8
         4.1.6. IP Version 6 ........................................8
    4.2. SIP Outbound Proxy .........................................8
         4.2.1. SIP Outbound Proxy ..................................8
         4.2.2. Discovery of the SIP Outbound Proxy .................8
    4.3. Registration ...............................................9
         4.3.1. Registration Required ...............................9
         4.3.2. Efficient Registration .............................10
         4.3.3. Registration for Roaming and Non-roaming Cases .....10
         4.3.4. Visited Domain Name ................................10
         4.3.5. De-registration ....................................10
    4.4. SIP Compression ...........................................11
         4.4.1. Compression Algorithm Independence .................12
         4.4.2. Extensibility of the SIP Compression ...............12
         4.4.3. Minimal Impact of SIP Compression on the Network ...12
         4.4.4. Optionality of SIP Compression .....................12
    4.5. QoS Requirements Related to SIP ...........................13
         4.5.1. Independence between QoS Signaling and SIP .........13
         4.5.2. Coordination between SIP and QoS/Resource
                Allocation .........................................13
    4.6. Prevention of Theft of Service ............................14
    4.7. Radio Resource Authorization ..............................14
    4.8. Prevention of Malicious Usage .............................14
    4.9. Prevention of Denial of Service ...........................14
    4.10. Identification of Users ..................................15
          4.10.1. Private User Identity ............................15
          4.10.2. Public User Identities ...........................15
          4.10.3. Delivery of the Dialed Public User ID ............17
    4.11. Identifiers Used for Routing .............................17
    4.12. Hiding Requirements ......................................17
          4.12.1. Hiding of the Network Structure ..................17
          4.12.2. Hiding of IP Addresses ...........................17
          4.12.3. SIP Hiding Proxy .................................18
    4.13. Cell-ID ..................................................18
          4.13.1. Cell-ID in Signaling from the UA to the
                  Visited and Home .................................18
          4.13.2. Format of the Cell-ID ............................18

Garcia-Martin Informational [Page 2] RFC 4083 3GPP R5 Requirements on SIP May 2005

    4.14. Release of Sessions ......................................18
          4.14.1. Ungraceful Session Release .......................19
          4.14.2. Graceful Session Release .........................19
    4.15. Routing of SIP Messages ..................................20
          4.15.1. SIP Outbound Proxy ...............................20
          4.15.2. SIP Serving Proxy in the Home Network ............20
          4.15.3. INVITE Might Follow a Different Path than
                  REGISTER .........................................20
          4.15.4. SIP Inbound Proxy ................................20
          4.15.5. Distribution of the Source Routing Set of
                  Proxies ..........................................21
    4.16. Emergency Sessions .......................................21
    4.17. Identities Used for Session Establishment ................21
          4.17.1. Remote Party Identification Presentatio ..........21
          4.17.2. Remote Party Identification Privacy ..............21
          4.17.3. Remote Party Identification Blocking .............21
          4.17.4. Anonymity ........................................22
          4.17.5. Anonymous Session Establishment ..................22
    4.18. Charging .................................................22
          4.18.1. Support of Both Prepaid and Postpaid Models ......22
          4.18.2. Charging Correlation Levels ......................23
          4.18.3. Charging Correlation Principles ..................23
          4.18.4. Collection of Session Detailed Information .......24
    4.19. General Support of Additional Capabilities ...............24
          4.19.1. Additional Capabilities ..........................24
          4.19.2. DTMF Signaling ...................................24
          4.19.3. Early Media ......................................25
    4.20. Exchange of Session Description ..........................25
    4.21. Prohibition of Certain SDP Parameters ....................26
          4.21.1. Prohibition of Codecs ............................26
          4.21.2. Prohibition of Media Types .......................26
    4.22. Network-initiated Re-authentication ......................26
    4.23. Security Model ...........................................27
    4.24. Access Domain Security ...................................28
          4.24.1. General Requirements .............................28
          4.24.2. Authentication ...................................29
          4.24.3. Message Protection ...............................29
          4.24.4. Negotiation of Mechanisms ........................31
          4.24.5. Verification of Messages .........................31
    4.25. Network Domain Security ..................................32
 5. Security Considerations ........................................32
 6. Contributors ...................................................32
 7. References .....................................................32
    7.1. Normative References ......................................32
    7.2. Informative References ....................................33

Garcia-Martin Informational [Page 3] RFC 4083 3GPP R5 Requirements on SIP May 2005

1. Introduction

 3GPP has selected SIP [2] as the protocol to establish and tear down
 multimedia sessions in the IP Multimedia Subsystem (IMS).  3GPP
 Technical Specification 23.228 [28] describes the IMS.  3GPP
 Technical Specification 24.228 [29] contains a comprehensive set of
 session flows.  3GPP Technical Specification 24.229 [30] describes
 the usage of SIP by the various IMS nodes.
 This document is an effort to define the requirements applicable to
 the usage of the SIP protocol suite in cellular networks,
 particularly in the 3GPP IMS for Release 5 of the 3GPP
 specifications.  Further releases of the 3GPP specifications may
 contain additional SIP requirements.  This document focuses on the
 requirements identified for the 3GPP Release 5 IMS.
 The rest of this document is structured as follows:
 o  Section 3 offers an overview of the 3GPP IMS.  Readers who are not
    familiar with it should carefully read this section.
 o  Section 4 contains the 3GPP requirements to SIP.  Requirements are
    grouped by category.  Some requirements include statements on
    possible solutions that would be able to fulfill them.  Note that,
    as a particular requirement might be fulfilled by different
    solutions, not all the solutions might have an impact on SIP.
 This document is advisory in nature.  Its primary purpose is to help
 the IETF understand the IMS environment.  Given this better
 understanding, we expect that the IETF can more effectively evolve
 the SIP protocol.  The IETF will not respond to the requirements
 given in this document on a point-for-point basis.  Some requirements
 have been and/or will be met by extensions to the SIP protocol.
 Others may be addressed by effectively using existing capabilities in
 SIP or other protocols, and we expect that individual members of the
 SIP community will work with 3GPP to achieve a better understanding
 of these mechanisms.  Some of the requirements in this document may
 not be addressed at all by the IETF, although we believe that the act
 of documenting and discussing them is in itself helpful in achieving
 a better all-around understanding of the task at hand.

2. Conventions

 This document does not specify any protocol of any kind.  Therefore,
 the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
 "OPTIONAL" in this document, as described in RFC 2119 [1], does not
 apply.

Garcia-Martin Informational [Page 4] RFC 4083 3GPP R5 Requirements on SIP May 2005

3. Overview of the 3GPP IMS

 This section gives the reader an overview of the 3GPP IM CN Subsystem
 (IMS).  It is not intended to be comprehensive, but it provides
 enough information to understand the basis of the 3GPP IMS.  Readers
 are encouraged to find a more detailed description in the 3GPP
 Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29].
 For a particular cellular device, the 3GPP IMS network is further
 decomposed in a home network and a visited network.
 An IMS subscriber belongs to his or her home network.  Services are
 triggered and may be executed in the home network.  One or more SIP
 servers are deployed in the SIP home network to support the IP
 Multimedia Subsystem.  Among those SIP servers, there is a SIP
 serving proxy, which is also acting as a SIP registrar.
 Authentication/Authorization servers may be part of the home network
 as well.  Users are authenticated in the home network.
 A SIP outbound proxy is provided to support the User Agent (UA).  The
 SIP outbound proxy is typically located in the visited network,
 although it may be located in the home network as well.  The SIP
 outbound proxy maintains security associations between itself and the
 terminals, and interworks with the resource management in the packet
 network.
 The SIP outbound proxy is assigned after the mobile device has
 connected to the access network.  Once this proxy is assigned, it
 does not change while the mobile remains connected to the access
 network.  Thus the mobile can move freely within the access network
 without SIP outbound proxy reassignment.
 The home network may also support one or more SIP edge proxies.
 These nodes may act as the first entry points for SIP signaling to
 the home network and may determine (with the help of location
 servers) which SIP registrar server to assign to a particular user.
 Typically the address of the home network SIP edge proxy is
 configured in DNS in the form of a DNS Naming Authority Pointer
 (NAPTR) and Service (SRV) records for SIP.
 Additionally, home and visited networks may deploy, if required, a
 SIP-hiding proxy.  The main purpose of the SIP-hiding proxy is to
 hide the network configuration.
 The 3GPP IM CN Subsystem is designed to be access independent.
 Access is granted from 3GPP cellular terminals or from other
 terminals that use other accesses out of the scope of 3GPP.

Garcia-Martin Informational [Page 5] RFC 4083 3GPP R5 Requirements on SIP May 2005

 3GPP cellular IP Multimedia terminals use the existing General Packet
 Radio Service (GPRS) [27] as a transport network for IP datagrams.
 The terminals first connect to the GPRS network to get an IPv6
 prefix.  In order to do this, the terminals must perform a GPRS
 Attach procedure followed by a GPRS PDP Context Activation procedure.
 These GPRS procedures are required to be completed before any IP
 Multimedia session can be established.
 As a result of the above-mentioned GPRS procedures, the terminal has
 built an IPv6 address.  The IPv6 address belongs to the same network
 address space as does the SIP outbound proxy.  The address does not
 change, as the mobile terminal moves while still attached to the same
 network address space.
 If the terminal moves from a GPRS access to another GPRS access, the
 above-mentioned GPRS procedures needs to start from the beginning to
 allocate an IPv6 address to the terminal.
 Figure 1 shows an overview of the 3GPP architecture for IM CN
 Subsystem.
           +-------------+  +----------------+   +----------------+
           |             |  |                |   |      +------+  |
           |             |  |                |   |      | SIP  |  |
           |             |  |                |   |      |server|  |
     |     |             |  |                |   |      +------+  |
   +-|+    |             |  |                |   |       /        |
   |  |    |             |  |    +------+    |   | +------+       |
   |  |    |             |  |    | SIP  |    |   | | SIP  |       |
   |  | ---|-------------|--|----|server|----|---|-|server|       |
   +--+    |             |  |    +------+    |   | +------+       |
           |             |  |                |   |                |
   SIP     | GPRS access |  | Visited Network|   |  Home Network  |
   dev.    +-------------+  +----------------+   +----------------+
              Figure 1: Overview of the 3GPP IMS architecture
 Another possible future configuration is depicted in Figure 2.  In
 that case, a general-purpose computer (e.g., a laptop computer) is
 connected to a GPRS terminal.  The computer hosts the Multimedia
 application (comprising SIP, SDP, RTP, etc.).  The GPRS terminal
 handles the radio access and the GPRS connectivity.  Note that, for
 the sake of clarity, in this example the home network has not been
 depicted in the figure.

Garcia-Martin Informational [Page 6] RFC 4083 3GPP R5 Requirements on SIP May 2005

                                +-------------+  +----------------+
       +-------+          |     |             |  |                |
       |       |        +-|+    |             |  |                |
       |       |        |  |    |             |  |    +------+    |
       +-------+        |  |    |             |  |    | SIP  |    |
      /       / --------|  | ---|-------------|-------|server|------
     /-------/          +--+    |             |  |    +------+    |
                                |             |  |                |
       SIP              GPRS    | GPRS access |  | Visited Network|
      client          terminal  +-------------+  +----------------+
            Figure 2: A computer connected to a GPRS terminal
 Services are typically executed in an application server.  The
 interface between the SIP server and the application server is based
 on SIP.  However, certain operators may want to reuse the existing
 technology, and therefore, they may need to interoperate SIP with
 protocols such as CAMEL/Intelligent-Network or Open Services
 Architecture (OSA).

4. 3GPP Requirements on SIP

4.1. General Requirements

 This section does not specify any particular requirement for SIP.
 However, it includes a list of general requirements that must be
 considered when developing solutions to particular requirements.

4.1.1. Efficient Use of the Radio Interface

 The radio interface is a scarce resource.  As such, the exchange of
 signaling messages between the mobile terminal and the network should
 be minimized.  All the mechanisms developed should make an efficient
 use of the radio interface.
 See also the related requirements in Section 4.4.

4.1.2. Minimum Session Setup Time

 All the procedures and mechanisms should have a minimum impact on the
 session setup time as perceived by the user.  When there is a choice
 between performing tasks at session establishment and prior to
 session establishment, then tasks should be performed prior to
 session establishment.
 See also the related requirements in Section 4.4.

Garcia-Martin Informational [Page 7] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.1.3. Minimum Support Required in the Terminal

 As terminals could be rather small devices, memory requirements,
 power consumption, processing power, etc., should be kept to a
 minimum.  Mandating support for additional protocols in the terminal
 must meet this requirement.

4.1.4. Roaming and Non-roaming

 All the requirements must be met for both roaming and non-roaming
 scenarios.  There should not be a significant change in the signaling
 procedures between roaming and non-roaming scenarios.

4.1.5. Terminal Mobility Management

 As terminal mobility is managed by the access network, there is no
 need to support terminal mobility management in SIP.

4.1.6. IP Version 6

 3GPP IMS is solely designed to use IP version 6.  As a consequence,
 all protocols must support IPv6 addresses.

4.2. SIP Outbound Proxy

4.2.1. SIP Outbound Proxy

 A SIP outbound proxy is provided to support both roaming and
 non-roaming scenarios.  The SIP outbound proxy may be located either
 in the home network or in the visited network.

4.2.2. Discovery of the SIP Outbound Proxy

 There must be a general mechanism whereby the mobile device (UA)
 learns the SIP outbound proxy address.
 The DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill
 the requirement.
 In addition to the above-expressed requirement, the 3GPP access
 network may provide the SIP outbound proxy address during access
 network bearer establishment.  This is considered a less general
 mechanism, though.

Garcia-Martin Informational [Page 8] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.3. Registration

 The home network must maintain one or more SIP registrars.  The SIP
 registrar authenticates the user and registers the IP address where
 the user can be located.
 Once the terminal is switched on, the mobile device UA reads its
 configuration data.  This data may be stored in a SIM card or in any
 other memory device.  The configuration data contains an
 identification of the home network.  The device finds the SIP
 registrar address from the home network domain name.  The terminal
 sends the registration through the SIP outbound proxy.
 In order to support the search of the registrar, the home network
 contains one or more SIP servers that may be configured in DNS with
 the NAPTR/SRV record of SIP.  These are the home network edge
 proxies.  Their mission is to serve as the first points of contact in
 the home network, and to decide (with the help of location servers)
 which SIP registrar server to assign to a particular user.
 The procedures specified in RFC 3263 [10] applied to a REGISTER
 message seem to be sufficient to meet this requirement.

4.3.1. Registration Required

 A user must register to the IMS before he/she can receive any
 invitation to any sessions.  In addition, it is desirable for the
 user to register before initiating any sessions.  The following
 factors contribute to the rationale behind this:
 1.  The SIP serving proxy in the home network needs to know when and
     from which terminal the user is available, in order to route
     received SIP requests for sessions and services.
 2.  The user can be pre-authenticated early so that authentication
     does not contribute to post-dial delay.  The procedure should not
     have a penalty on the session setup time (see also the
     requirement stated in Section 4.1.2).
 3.  The user is assigned a particular serving proxy.  The serving
     proxy downloads the service profile for that user to trigger
     services.
 Therefore, 3GPP has mandated the mobile device UA to register before
 the mobile device UA initiates any session.

Garcia-Martin Informational [Page 9] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.3.2. Efficient Registration

 Due to the scarce radio interface resource, a single registration
 must be sufficient to ensure that the mobile UA is reachable from
 both the home and the visited networks.
 A single REGISTER message, addressed to the registrar, may traverse
 the SIP outbound proxy.  This can install, if needed, soft
 registration states in the SIP outbound proxy.

4.3.3. Registration for Roaming and Non-roaming Cases

 Independent of whether the UA is roaming, it is desirable for the
 registration procedure to be the same.

4.3.4. Visited Domain Name

 The home network must be able to validate the existence of a roaming
 agreement between the home and the visited network.  The home network
 needs to validate that the user is allowed to roam to such a visited
 network.  Therefore, there must be a mechanism whereby the visited
 network identity is known at registration time at the home network.
 It is acceptable to represent the visited network identity either as
 a visited network domain name or as a string.

4.3.5. De-registration

4.3.5.1. De-registration of Users

 There must be a procedure for a user to de-register from the network.
 This procedure may be used, for example, when the user deactivates
 the terminal.
 We believe that a REGISTER with an expiration timer of 0 will meet
 the requirement.

4.3.5.2. Network-initiated De-registration or Re-registration

 In a number of situations a network needs to de-register or trigger a
 re-registration of a previously registered UA.  Examples of usage are
 described in sections 4.3.6.3, 4.3.6.4, and 4.3.6.5.
 This implies a need for a notification mechanism whereby the UA can
 be notified of the de-registration, or of a request for
 re-registration.

Garcia-Martin Informational [Page 10] RFC 4083 3GPP R5 Requirements on SIP May 2005

 We believe that this requirement is met by the SIP-specific event
 notification [12] and a registration event package [14].

4.3.5.3. Network-initiated De-registration, Network Maintenance

 There might be cases in which the SIP serving proxy has to shutdown;
 e.g., due to maintenance operation.  Although this situation is not
 likely to happen in everyday situations, it is desirable to have a
 mechanism to inform the UA that his current registration is being
 cancelled.  The UA may initiate another registration process that
 will lead to the selection of a new SIP serving proxy.

4.3.5.4. Network-initiated De-registration, Network/Traffic Determined

 The system must support a mechanism to avoid inconsistent information
 storage and to remove any redundant registration information.  This
 case will occur when a subscriber roams to a different network
 without a prior de-registration.  This case occurs in normal mobility
 procedures when the user roams from one access network to another, or
 when new service conditions are imposed on roamers.

4.3.5.5. Network-initiated De-registration, Administrative

 For different reasons (e.g., subscription termination, stolen
 terminal, etc.) a home network administrative function may determine
 a need to clear a user's SIP registration.  It is desirable to have a
 mechanism whereby the SIP serving proxy can inform the UA that its
 registration is being cancelled.
 There must be a procedure for the SIP serving proxy to de-register
 users.  The de-registration information must be available at all the
 proxies that keep registration state and the UA.
 We believe that a procedure based on SIP-specific event notification
 [12] and a registration event package [14] will meet this
 requirement.

4.4. SIP Compression

 The radio interface is a scarce resource, and typically the available
 bandwidth over the radio interface is limited.  These two factors
 seem to limit the transport of possibly large SIP messages over the
 air interface.  Particularly, the session setup time might be
 extended due to the time needed to transport SIP messages over a
 limited bandwidth channel.

Garcia-Martin Informational [Page 11] RFC 4083 3GPP R5 Requirements on SIP May 2005

 On the other hand, the number and size of certain SIP header values,
 such as Via or Record-Route, seems not to be limited.  A mobile
 device UA may present limitations in the available memory to store
 this kind of information.
 Therefore, there must be a mechanism to efficiently transport SIP
 signaling packets over the radio interface, by compressing the SIP
 messages between the mobile device UA and the SIP outbound proxy, and
 between the SIP outbound proxy and the mobile device UA.  Note that
 compression of IP and transport layer protocol headers that carry
 these SIP messages is also a requirement, although we believe that
 this does not have an impact on SIP.

4.4.1. Compression Algorithm Independence

 The chosen solution(s) must be able to allow the operation under
 several different compression algorithms.

4.4.2. Extensibility of the SIP Compression

 The chosen solution(s) must be extensible to facilitate the
 incorporation of new and improved compression algorithms in a
 backward-compatible way, as they become available.

4.4.3. Minimal Impact of SIP Compression on the Network

 Application-specific compression must minimize impacts on existing
 3GPP access networks (such as base stations transceivers).  On the
 other hand, the compression mechanism should be independent of the
 access; e.g., the compression must be defined between the mobile
 device UA and the outbound SIP proxy.

4.4.4. Optionality of SIP Compression

 It must be possible to leave the usage of compression for SIP
 signaling optional.  To facilitate mobile terminal roaming between
 networks that are using compression, the mobile terminal should
 always support SIP signaling compression.  If compression is not
 supported, communication may continue without compression, depending
 on the local policy of the visited network.

4.4.4.1. Compression Reliability

 The compression mechanism should be reliable and able to recover
 automatically from errors generated during the decompression.

Garcia-Martin Informational [Page 12] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.5. QoS Requirements Related to SIP

4.5.1. Independence between QoS Signaling and SIP

 The selection of QoS signaling and resource allocation schemes must
 be independent of the selected session control protocols.  This
 allows for independent evolution of QoS control and SIP.

4.5.2. Coordination between SIP and QoS/Resource Allocation

4.5.2.1. Allocation before Alerting

 In establishing a SIP session, it must be possible for an application
 to request that the resources needed for bearer establishment are
 successfully allocated before the destination user is alerted.  Note,
 however, that it must be also possible for an SIP application in a
 terminal to alert the user before the radio resources are established
 (e.g., if the user wants to participate in the media negotiation).
 We believe that this requirement is met by Integration of Resource
 Management and SIP [15].

4.5.2.2. Destination User Participates in the Bearer Negotiation

 In establishing a SIP session, it must be possible for a terminating
 application to allow the destination user to participate in
 determining which bearers will be established.  However, it must be
 possible to establish the SIP session without user intervention.
 We believe that this requirement is met by the standard SDP
 negotiation described in SIP [2], the SDP offer/answer model [11] and
 the extensions described in Integration of Resource Management and
 SIP

4.5.2.3. Successful Bearer Establishment

 Successful bearer establishment must include the completion of any
 required end-to-end QoS signaling, negotiation, and resource
 allocation.
 We believe that this requirement is met by the procedures described
 in the Integration of Resource Management and SIP [15].

Garcia-Martin Informational [Page 13] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.6. Prevention of Theft of Service

 Typically, users are allocated QoS resources.  There is an admission
 control mechanism that prevents users exceeding the limits negotiated
 with the network.  The network must prevent unauthorized users to
 make use of non-authorized resources.  For instance, the network must
 provide a mechanism to prevent a user from using the resources
 allocated to a second user, and for which this second user may be
 paying.
 We believe that this requirement may be met by the procedures
 described in the Private SIP extensions for Media Authorization [16].

4.7. Radio Resource Authorization

 As radio resources are very valuable, the network must be able to
 manage them in a controlled manner.  The network must be able to
 identify who is using these resources and to authorize their usage.
 For example, a mobile device terminal could execute an unlimited and
 uncontrolled resource reservation procedure if the network does not
 supervise the usage of radio resources.
 We believe that this requirement is met by the procedures described
 in the Private SIP extensions for Media Authorization [16].

4.8. Prevention of Malicious Usage

 The 3GPP IMS must prevent mobile devices from making malicious use of
 the network.  For instance, a malicious UA could not obey the
 procedures related to the Record-Route header field: when sending
 subsequent requests the UA could bypass proxies which inserted a
 Record-Route header during the initial transaction.

4.9. Prevention of Denial of Service

 The risk that a proxy will receive a denial of service attack should
 be minimized.  For instance, a malicious mobile device could learn a
 SIP proxy IP address and port number (e.g., in a Record-Route header
 value) and establish an attack upon that proxy.

Garcia-Martin Informational [Page 14] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.10. Identification of Users

4.10.1. Private User Identity

 In order to use the 3GPP IMS, a user is assigned a private user
 identity.  The home network operator assigns the private user
 identity, which is used to identify the user uniquely from a network
 perspective.  The private user identity is used, for example, for
 authentication, authorization, administration, and, possibly,
 accounting purposes.  Note that the private user identity is not used
 for routing of SIP messages.
 The private user identity is a unique global identity defined by the
 Home Network Operator.  The identity takes the form of a Network
 Access Identifier (NAI) as defined in RFC 2486 [6].
 The end user does not have access to the private user identity.
 Typically the identity is stored in a Subscriber Identity Module
 card.
 The private user identity is permanently allocated to a user (it is
 not a dynamic identity), and is valid for the duration of the user's
 business subscription with the home network.

4.10.1.1. Private User ID in Registrations

 The mobile UA must deliver the private user identity to the SIP
 outbound proxy and the registrar at registration time.
 The private user identity is used as the basis for authentication
 during registration of the mobile user.  The term authentication is
 used in this document with the same meaning as it is defined in RFC
 2828 [7].
 We believe that this requirement is met by populating the username
 field of the Authorization: header value of the REGISTER request with
 the private user identity.

4.10.2. Public User Identities

 In order to use the 3GPP IMS, a user is assigned one or more public
 user identities.  The user will make use of the public user identity/
 identities when requesting communication to other users.  For
 example, the public user identity might be included on a business
 card.

Garcia-Martin Informational [Page 15] RFC 4083 3GPP R5 Requirements on SIP May 2005

 Different public user identities may be grouped into a user profile.
 A user may have different profiles, each one containing different
 public user identities.  A public user identity can be part of a
 single user profile.
 The user may need to register one or more public user identities
 prior to receiving communications addressed to that public user
 identity.
 We believe that this requirement is met by populating the From: and
 To:  header values of a REGISTER message with the public user
 identity.

4.10.2.1. Format of the Public User Identities

 The public user identity must take the form of a SIP URI (as defined
 in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number.
 We believe that this requirement is met by using SIP URLs and
 telephone numbers represented in SIP URLs as described in SIP [3].
 In addition, tel: URLs as specified in RFC 3966 [35] can be used to
 fulfill the requirement.

4.10.2.2. Registration of Public User IDs

 It must be possible to register globally (i.e., through one single UA
 request) a user that has more than one public identity that belongs
 to the same user profile, via a mechanism within the IMS.  In this
 case, the user will be registered with all the public identities
 associated to a user profile.
 We believe this requirement may be accomplished by external
 procedures.  For example, the user's profile may contain a list of
 alias identities that the registrar considers active if the primary
 identity is registered.  The user may get informed of the
 automatically registered public user IDs by subscribing to its own
 registration state.

4.10.2.3. Authentication of the public user ID

 Public user identities are not authenticated by the 3GPP IMS.
 However, the network authorizes that the public user identity is
 associated with the registered private user identity.
 There is a list of public user identities associated with each
 private user ID within the IMS.  IMS will reject attempts to use
 other public identities with this private user ID.

Garcia-Martin Informational [Page 16] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.10.3. Delivery of the Dialed Public User ID

 Typically a UA will be registered under a set of different public
 user IDs.  As such, sessions destined to the user can be placed with
 any of the registered public user IDs.  The serving proxy and
 application server(s) in the termination network may apply certain
 filtering rules or services based on the public user ID contained in
 the Request-URI.  The UA may also apply certain filtering rules or
 services based on the called public user ID.
 Therefore, it must be possible for all sessions to deliver the dialed
 public user ID to the terminating entities, such as the serving
 proxy, application servers, and terminating UA.

4.11. Identifiers Used for Routing

 Routing of SIP signaling within IMS must use SIP URLs as defined in
 SIP [2].  E.164 [34] format public user identities must not be used
 for routing within IMS, and session requests based on E.164 format
 public user identities will require conversion into SIP URI format
 for internal IMS usage.
 We believe that this requirement is achieved by translating E.164
 numbers into SIP URIs.  A database, such as ENUM [9], might do the
 job.

4.12. Hiding Requirements

 Although the requirements included in this section are not optional,
 the hiding feature is optional to use through configuration.  This
 means that a network operator can, at his desire, switch the hiding
 functionality on or off.

4.12.1. Hiding of the Network Structure

 A network operator need not be required to reveal the internal
 network structure to another network (in Via, Route, or other
 headers) that may contain indication of the number of SIP proxies,
 domain name of the SIP proxies, capabilities of the SIP proxies, or
 capacity of the network.

4.12.2. Hiding of IP Addresses

 A network need not be required to expose the explicit IP addresses of
 the nodes within the network (excluding firewalls and border
 gateways).

Garcia-Martin Informational [Page 17] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.12.3. SIP Hiding Proxy

 In order to support the hiding requirements, a SIP hiding proxy may
 be included in the SIP signaling path.  This additional proxy may be
 used to shield the internal structure of a network from other
 networks.

4.13. Cell-ID

 The identity of the cell through which the 3GPP UA is accessing the
 IMS (Cell-ID) may be used by the home network to provide localized
 services or information on the location of the terminal during an
 emergency call (when emergency calls are handled in IMS; see also the
 requirement stated in Section 4.16).

4.13.1. Cell-ID in Signaling from the UA to the Visited and Home

       Networks
 Assuming that the Cell-ID is obtained by the UA by other mechanisms
 outside the scope of SIP, the Cell-ID must be transported at least in
 the following procedures:
 o  Registration
 o  Session Establishment (Mobile Originated)
 o  Session Establishment (Mobile Terminated)
 o  Session Release
 The Cell-ID is private information and only of interest in the UA
 home network.  Therefore, the Cell-ID should be removed prior to
 sending the SIP signaling beyond the originating home network.

4.13.2. Format of the Cell-ID

 The cell-ID must be sent in any of the formats described in the 3GPP
 Technical Specification 23.003 [26].

4.14. Release of Sessions

 In addition to the normal mechanisms for releasing a SIP session
 (e.g., BYE), two cases are considered in this section: the ungraceful
 session release (e.g., the terminal moves to an out-of-coverage zone)
 and the graceful session release ordered by the network (e.g.,
 prepaid caller runs out of credit).
 We believe that this requirement is met by a SIP entity acting as a
 so-called transparent back-to-back UA.

Garcia-Martin Informational [Page 18] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.14.1. Ungraceful Session Release

 If an ungraceful session termination occurs (e.g., a flat battery or
 a mobile leaves coverage), when a call stateful SIP proxy server
 (such as the SIP serving proxy at home) is involved in a session,
 memory leaks and, eventually, server failure can occur due to hanging
 state machines.  To ensure stable server operation and carrier grade
 service, a mechanism to handle the ungraceful session termination
 issue must be provided.  We assume that there is a mechanism by which
 the SIP outbound proxy is notified, by a mechanism external to SIP,
 of the ungraceful session termination.  This allows transforming the
 ungraceful session release into a graceful session release ordered by
 the network (see the next section).  For example, upon reception of
 the notification of loss of mobile radio coverage, the SIP outbound
 proxy could send a BYE request on behalf of the terminal, although
 this BYE cannot be authenticated.

4.14.2. Graceful Session Release

 There must be a mechanism whereby an entity in the network may order
 the release of resources to other entities.  This may be used, for
 example, in prepaid calls when the user runs out of credit.
 This release must not involve any request to the UA to send out a
 release request (BYE), as the UA might not follow this request.  The
 receiving entity needs the guarantee that resources are released when
 requested by the ordering entity.
 The following objectives must be met:
 o  Accurately report the termination to the charging subsystem.
 o  Release the associated network resources: bearer resources and
    signaling resources.
 o  Notify other parties to the session, if any, of the session
    termination.
 When feasible, this mechanism should be at the SIP protocol level in
 order to guarantee access independence for the system.

Garcia-Martin Informational [Page 19] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.15. Routing of SIP Messages

4.15.1. SIP Outbound Proxy

 The 3GPP architecture includes a SIP outbound proxy that is typically
 located in the visited network (although it may be located in the
 home network).  This outbound proxy provides local services such as
 compression of SIP messages or security functions.  In addition, the
 outbound proxy may interact with the media reservation mechanism to
 provide authentication and authorization support for media
 reservation.
 All mobile terminal originated session setup attempts must transit
 the outbound proxy so that the services provided by the outbound
 proxy can be delivered to the mobile terminal.

4.15.2. SIP Serving Proxy in the Home Network

 The serving proxy in the home network allows triggering of user-
 customized services that are typically executed in an application
 server.
 All mobile terminal originated session setup attempts must transit
 the serving proxy in the home network so that the proxy can properly
 trigger the SIP services allocated to the user (e.g., speed dial
 substitution).  This implies a requirement for some sort of source-
 routing mechanism to ensure these proxies are transited correctly.

4.15.3. INVITE Might Follow a Different Path than REGISTER

 The path taken by an INVITE request need not be restricted to the
 specific path taken by a mobile terminal originated REGISTER request;
 e.g., the INVITE may traverse just the SIP outbound proxy and the SIP
 serving proxy, without passing through any other proxies.  However,
 the path taken by the INVITE may follow the same path taken by the
 REGISTER.

4.15.4. SIP Inbound Proxy

 The visited network may apply certain services and policies to
 incoming sessions (such as establishment of security services or
 interaction with the media reservation mechanism).  Therefore, the
 visited network may contain a SIP inbound proxy for terminating
 sessions.  In general, the SIP inbound proxy and the SIP outbound
 proxy are the same SIP proxy.

Garcia-Martin Informational [Page 20] RFC 4083 3GPP R5 Requirements on SIP May 2005

4.15.5. Distribution of the Source Routing Set of Proxies

 Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is
 used to effect traversal of the required SIP proxies during session
 setup.
 There must be some means of dynamically informing the node that adds
 the source-routing set of proxies that the INVITE has to traverse
 (e.g., the outbound proxy or serving proxy) of what that set of
 proxies should be.
 The hiding requirements expressed in Section 4.12 also apply to the
 said set of proxies.

4.16. Emergency Sessions

 3GPP networks already contain alternative procedures for delivering
 emergency sessions.  Release 5 of the 3GPP specifications does not
 add any requirement for SIP emergency sessions.

4.17. Identities Used for Session Establishment

4.17.1. Remote Party Identification Presentation

 It must be possible to present to the caller the identity of the
 party to which he/she may dial back to return a call.
 We believe that this requirement is met by the procedures described
 in RFC 3325 [17].

4.17.2. Remote Party Identification Privacy

 In addition to the previous requirement, the called party must be
 able to request that his/her identity not be revealed to the caller.
 We believe that this requirement is met by the procedures described
 in RFC 3323 [18].

4.17.3. Remote Party Identification Blocking

 Regulatory agencies, as well as subscribers, may require the ability
 of callers to block the display of their caller identification.  The
 destination subscriber's SIP serving proxy may be perform this
 function.  In this way, the destination subscriber is still able to
 do a session-return, session-trace, transfer, or any other
 supplementary service.

Garcia-Martin Informational [Page 21] RFC 4083 3GPP R5 Requirements on SIP May 2005

 Therefore, it must be possible that the caller request to block the
 display of his/her identity on the callee's display.
 We believe that this requirement is met by the procedures described
 in RFC 3323 [18].

4.17.4. Anonymity

 Procedures are required for anonymous session establishment.
 However, sessions are not intended to be anonymous to the originating
 or terminating network operators.
 We believe that this requirement is met by the procedures described
 in RFC 3323 [18] and RFC 3325 [17].

4.17.5. Anonymous Session Establishment

 If the caller requests that the session be anonymous, the User Agent
 Client (UAC) must not reveal any identity information to the User
 Agent Server (UAS).
 If the caller requests that the session be anonymous, the terminating
 network must not reveal any identity or signaling routing information
 to the destination endpoint.  The terminating network should
 distinguish at least two cases: first, whether the caller intended
 the session to be anonymous, and second, whether the caller's
 identity was deleted by a transit network.
 We believe that this requirement is met by the procedures described
 in RFC 3323 [18] and RFC 3325 [17].

4.18. Charging

 The 3GPP charging implications are described in the 3GPP Technical
 Specification 32.225 [31].

4.18.1. Support of Both Prepaid and Postpaid Models

 Operators may choose to offer prepaid and/or postpaid services.  The
 prepaid model is accomplished with the support of the online charging
 model.  The postpaid model is accomplished with the support of the
 offline charging model.
 Online charging is the process whereby charging information can
 affect, in real-time, the service rendered to the user, such as a
 request for a graceful release of an existing session.  Online
 charging interacts with the SIP signaling.

Garcia-Martin Informational [Page 22] RFC 4083 3GPP R5 Requirements on SIP May 2005

 Offline charging is the process whereby charging information does not
 affect, in real-time, the service rendered to the user.

4.18.2. Charging Correlation Levels

 The following levels of correlation for IMS charging are considered:
 o  Correlation within a session.  A session may comprise a number of
    media components.  It must be possible to correlate the charging
    data of the different media components belonging to a session.
 o  Correlation at media-component level.  For a session comprising
    several media types (such as audio and video), charging data is
    generated for each media type and needs to be correlated between
    network elements.  For this, a media identifier will be unique and
    will clearly identify which media type of a session this charging
    information belongs to.  This component identifier is not
    exchanged between network elements and is based on the ordering of
    media flows in the SDP.  This ordering is the same as that used in
    the binding information passed to the GPRS network.

4.18.3. Charging Correlation Principles

 To support the correlation of charging information, the following
 principles apply to both offline and online charging:
 o  The correlation of charging information for an IMS session is
    based on the use of IMS Charging Identifiers (ICID).
 o  The first IMS network entity within the SIP signaling path is
    responsible for assigning an ICID.  This ICID will then be passed
    along the whole session path in an end-to-end manner.  However,
    this will not preclude further elements (other SIP proxies) along
    the session path from generating additional identifiers to be
    passed along.
 o  The ICID is passed to all IMS network entities in the session
    signaling path.  This is performed using SIP signaling.
 o  The addresses of the charging functions are passed by the serving
    SIP proxy to all IMS network entities in the session signaling
    path.  This is to provide a common destination for all the
    charging records generated by each IMS network entity with the
    same ICID.
 o  For the charging correlation between the GPRS network and the IMS,
    one or more GPRS Charging IDs, which identify the PDP contexts of
    the session, are passed from the GPRS network to the IMS.

Garcia-Martin Informational [Page 23] RFC 4083 3GPP R5 Requirements on SIP May 2005

 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.

Garcia-Martin Informational [Page 24] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 25] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 26] RFC 4083 3GPP R5 Requirements on SIP May 2005

 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

Garcia-Martin Informational [Page 27] RFC 4083 3GPP R5 Requirements on SIP May 2005

 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.

Garcia-Martin Informational [Page 28] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 29] RFC 4083 3GPP R5 Requirements on SIP May 2005

 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.

Garcia-Martin Informational [Page 30] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 31] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 32] RFC 4083 3GPP R5 Requirements on SIP May 2005

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.

Garcia-Martin Informational [Page 33] RFC 4083 3GPP R5 Requirements on SIP May 2005

 [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/>.

Garcia-Martin Informational [Page 34] RFC 4083 3GPP R5 Requirements on SIP May 2005

 [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

Garcia-Martin Informational [Page 35] RFC 4083 3GPP R5 Requirements on SIP May 2005

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
 attempt made to obtain a general license or permission for the use of
 such proprietary rights by implementers or users of this
 specification can be obtained from the IETF on-line IPR repository at
 http://www.ietf.org/ipr.
 The IETF invites any interested party to bring to its attention any
 copyrights, patents or patent applications, or other proprietary
 rights that may cover technology that may be required to implement
 this standard.  Please address the information to the IETF at ietf-
 ipr@ietf.org.

Acknowledgement

 Funding for the RFC Editor function is currently provided by the
 Internet Society.

Garcia-Martin Informational [Page 36]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4083.txt · Last modified: 2005/05/18 21:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki