Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5630

The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Pages: 56
Proposed Standard
Updates:  32613608
Part 1 of 3 – Pages 1 to 13
None   None   Next

Top   ToC   RFC5630 - Page 1
Network Working Group                                           F. Audet
Request for Comments: 5630                                    Skype Labs
Updates: 3261, 3608                                         October 2009
Category: Standards Track


The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

Abstract

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright and License Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Top   ToC   RFC5630 - Page 2

Table of Contents

1. Introduction ....................................................3 2. Terminology .....................................................3 3. Background ......................................................3 3.1. Models for Using TLS in SIP ................................3 3.1.1. Server-Provided Certificate .........................3 3.1.2. Mutual Authentication ...............................4 3.1.3. Using TLS with SIP Instead of SIPS ..................4 3.1.4. Usage of the transport=tls URI Parameter and the TLS Via Parameter ...............................5 3.2. Detection of Hop-by-Hop Security ...........................6 3.3. The Problems with the Meaning of SIPS in RFC 3261 ..........7 4. Overview of Operations ..........................................9 4.1. Routing ...................................................11 5. Normative Requirements .........................................13 5.1. General User Agent Behavior ...............................13 5.1.1. UAC Behavior .......................................13 5.1.1.1. Registration ..............................14 5.1.1.2. SIPS in a Dialog ..........................15 5.1.1.3. Derived Dialogs and Transactions ..........15 5.1.1.4. GRUU ......................................16 5.1.2. UAS Behavior .......................................17 5.2. Registrar Behavior ........................................18 5.2.1. GRUU ...............................................18 5.3. Proxy Behavior ............................................18 5.4. Redirect Server Behavior ..................................20 6. Call Flows .....................................................21 6.1. Bob Registers His Contacts ................................22 6.2. Alice Calls Bob's SIPS AOR ................................27 6.3. Alice Calls Bob's SIP AOR Using TCP .......................36 6.4. Alice Calls Bob's SIP AOR Using TLS .......................50 7. Further Considerations .........................................51 8. Security Considerations ........................................52 9. IANA Considerations ............................................52 10. Acknowledgments ...............................................52 11. References ....................................................53 11.1. Normative References .....................................53 11.2. Informative References ...................................53 Appendix A. Bug Fixes for RFC 3261 ..............................55
Top   ToC   RFC5630 - Page 3

1. Introduction

The meaning and usage of the SIPS URI scheme and of Transport Layer Security (TLS) [RFC5246] are underspecified in SIP [RFC3261] and have been a source of confusion for implementers. This document provides clarifications and guidelines concerning the use of the SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP (including both [RFC3261] and [RFC3608].

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Background

3.1. Models for Using TLS in SIP

This section describes briefly the usage of TLS in SIP.

3.1.1. Server-Provided Certificate

In this model, only the TLS server provides a certificate during the TLS handshake. This is applicable only between a user agent (UA) and a proxy, where the UA is the TLS client and the proxy is the TLS server, and hence the UA uses TLS to authenticate the proxy but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, this can be achieved by SIP HTTP digest authentication. This directionality implies that the TLS connection always needs to be set up by the UA (e.g., during the registration phase). Since SIP allows for requests in both directions (e.g., an incoming call), the UA is expected to keep the TLS connection alive, and that connection is expected to be reused for both incoming and outgoing requests. This solution of having the UA always initiate and keep alive the connection also solves the Network Address Translation (NAT) and firewall problem as it ensures that responses and further requests will always be deliverable on the existing connection. [RFC5626] provides the mechanism for initiating and maintaining outbound connections in a standard interoperable way.
Top   ToC   RFC5630 - Page 4

3.1.2. Mutual Authentication

In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA is in possession of a certificate. When sending a SIP request when there is not already a suitable TLS connection in place, a user agent client (UAC) takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a user agent server (UAS) takes on the role of TLS server. Because in SIP a UA or a proxy acts both as UAC and UAS depending on if it is sending or receiving requests, the symmetrical nature of mutual TLS is very convenient. This allows for TLS connections to be set up or torn down at will and does not rely on keeping the TLS connection alive for further requests. However, there are some significant limitations. The first obvious limitation is not with mutual authentication per se, but with the model where the underlying TCP connection can be established by either side, interchangeably, which is not possible in many environments. For examples, NATs and firewalls will often allow TCP connections to be established in one direction only. This includes most residential SIP deployments, for example. Mutual authentication can be used in those environments, but only if the connection is always started by the same side, for example, by using [RFC5626] as described in Section 3.1.1. Having to rely on [RFC5626] in this case negates many of the advantages of mutual authentication. The second significant limitation is that mutual authentication requires both sides to exchange a certificate. This has proven to be impractical in many environments, in particular for SIP UAs, because of the difficulties of setting up a certificate infrastructure for a wide population of users. For these reasons, mutual authentication is mostly used in server-to- server communications (e.g., between SIP proxies, or between proxies and gateways or media servers), and in environments where using certificates on both sides is possible (e.g., high-security devices used within an enterprise).

3.1.3. Using TLS with SIP Instead of SIPS

Because a SIPS URI implies that requests sent to the resource identified by it be sent over each SIP hop over TLS, SIPS URIs are not suitable for "best-effort TLS": they are only suitable for "TLS- only" requests. This is recognized in Section 26.2.2 of [RFC3261].
Top   ToC   RFC5630 - Page 5
      Users that distribute a SIPS URI as an address-of-record may elect
      to operate devices that refuse requests over insecure transports.

   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

   Using SIP over TLS is very simple.  A UA opens a TLS connection and
   uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   When TLS is used, the Via header field indicates TLS.

   [RFC3261], Section 26.3.2.1, states:

      When a UA comes online and registers with its local administrative
      domain, it SHOULD establish a TLS connection with its registrar
      (...).  Once the registration has been accepted by the registrar,
      the UA SHOULD leave this TLS connection open provided that the
      registrar also acts as the proxy server to which requests are sent
      for users in this administrative domain.  The existing TLS
      connection will be reused to deliver incoming requests to the UA
      that had just completed registration.

   [RFC5626] describes how to establish and maintain a TLS connection in
   environments where it can only be initiated by the UA.

   Similarly, proxies can forward requests using TLS if they can open a
   TLS connection, even if the route set used SIP URIs instead of SIPS
   URIs.  The proxies can insert Record-Route header fields using SIP
   URIs even if it uses TLS transport.  [RFC3261], Section 26.3.2.2,
   explains how interdomain requests can use TLS.

   Some user agents, redirect servers, and proxies might have local
   policies that enforce TLS on all connections, independently of
   whether or not SIPS is used.

3.1.4. Usage of the transport=tls URI Parameter and the TLS Via Parameter

[RFC3261], Section 26.2.2 deprecated the "transport=tls" URI transport parameter in SIPS or SIP URIs: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543.
Top   ToC   RFC5630 - Page 6
   The "tls" parameter has not been eliminated from the ABNF in
   [RFC3261], Section 25, since the parameter needs to remain in the
   ABNF for backward compatibility in order for parsers to be able to
   process the parameter correctly.  The transport=tls parameter has
   never been defined in an RFC, but only in some of the Internet drafts
   between [RFC2543] and [RFC3261].

   This specification does not make use of the transport=tls parameter.

   The reinstatement of the transport=tls parameter, or an alternative
   mechanism for indicating the use of the TLS on a single hop in a URI,
   is outside the scope of this specification.

   For Via header fields, the following transport protocols are defined
   in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-
   SCTP".

3.2. Detection of Hop-by-Hop Security

The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path to secure the request end- to-end? Effectively, the UAS cannot know for sure. However, [RFC3261], Section 26.4.4, recommends how a UAS can make some checks to validate the security. Additionally, the History-Info header field [RFC4244] could be inspected for detecting retargeting from SIP and SIPS. Retargeting from SIP to SIPS by a proxy is an issue because it can leave the receiver of the request with the impression that the request was delivered securely on each hop, while in fact, it was not. To emphasize, all the checking can be circumvented by any proxies or back-to-back user agents (B2BUAs) on the path that do not follow the rules and recommendations of this specification and of [RFC3261]. Proxies can have their own policies regarding routing of requests to SIP or SIPS URIs. For example, some proxies in some environments can be configured to only route SIPS URIs. Some proxies can be configured to detect non-compliances and reject unsecure requests. For example, proxies could inspect Request-URIs, Path, Record-Route, To, From, Contact header fields, and Via header fields to enforce SIPS. [RFC3261], Section 26.4.4, explains that S/MIME can also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in [RFC3261], Section 26.4.4, this is meant to imply that [RFC3893] would be used to "tunnel" important header fields (such as To and
Top   ToC   RFC5630 - Page 7
   From) in an encrypted and signed S/MIME body, replicating the
   information in the SIP message, and allowing the UAS to validate the
   content of those important header fields.  While this approach is
   certainly legal, a preferable approach is to use the SIP Identity
   mechanism defined in [RFC4474].  SIP Identity creates a signed
   identity digest, which includes, among other things, the Address of
   Record (AOR) of the sender (from the From header field) and the AOR
   of the original target (from the To header field).

3.3. The Problems with the Meaning of SIPS in RFC 3261

[RFC3261], Section 19.1, describes a SIPS URI as follows: A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Section 26.2.2 re-iterates it, with regards to Request-URIs: When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address- of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. Let's take the classic SIP trapezoid to explain the meaning of a sips:b@B URI. Instead of using real domain names like example.com and example.net, logical names like "A" and "B" are used, for clarity.
Top   ToC   RFC5630 - Page 8
        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | Proxy |-----TLS---- | Proxy |               .
        .              |   A   | .         . |  B    |               .
        .              |       | .         . |       |               .
        .            / +-------+ .         . +-------+ \             .
        .           /            .         .            \            .
        .          /             .         .             \           .
        .        TLS             .         .        Policy-based     .
        .        /               .         .               \         .
        .       /                .         .                \        .
        .      /                 .         .                 \       .
        .   +-------+            .         .              +-------+  .
        .   |       |            .         .              |       |  .
        .   | UAC a |            .         .              | UAS b |  .
        .   |       |            .         .              |       |  .
        .   +-------+            .         .              +-------+  .
        .             Domain A   .         .   Domain B              .
        ..........................         ...........................

                   SIP trapezoid with last-hop exception

   According to [RFC3261], if a@A is sending a request to sips:b@B, the
   following applies:

   o  TLS is required between UA a@A and Proxy A

   o  TLS is required between Proxy A and Proxy B

   o  TLS is required between Proxy B and UA b@B, depending on local
      policy.

   One can then wonder why TLS is mandatory between UA a@A and Proxy A
   but not between Proxy B and UA b@B.  The main reason is that
   [RFC3261] was written before [RFC5626].  At that time, it was
   recognized that in many practical deployments, Proxy B might not be
   able to establish a TLS connection with UA b because only Proxy B
   would have a certificate to provide and UA b would not.  Since UA b
   would be the TLS server, it would then not be able to accept the
   incoming TLS connection.  The consequence is that an [RFC3261]-
   compliant UAS b, while it might not need to support TLS for incoming
   requests, will nevertheless have to support TLS for outgoing requests
   as it takes the UAC role.  Contrary to what many believed
   erroneously, the last-hop exception was not created to allow for
   using a SIPS URI to address a UAS that does not support TLS: the
   last-hop exception was an attempt to allow for incoming requests to
Top   ToC   RFC5630 - Page 9
   not be transported over TLS when a SIPS URI is used, and it does not
   apply to outgoing requests.  The rationale for this was somewhat
   flawed, and since then, [RFC5626] has provided a more satisfactory
   solution to this problem.  [RFC5626] also solves the problem that if
   UA b is behind a NAT or firewall, Proxy B would not even be able to
   establish a TCP session in the first place.

   Furthermore, consider the problem of using SIPS inside a dialog.  If
   a@A sends a request to b@B using a SIPS Request-URI, then, according
   to [RFC3261], Section 8.1.1.8, "the Contact header field MUST contain
   a SIPS URI as well".  This means that b@B, upon sending a new Request
   within the dialog (e.g., a BYE or re-INVITE), will have to use a SIPS
   URI.  If there is no Record-Route entry, or if the last Record-Route
   entry consists of a SIPS URI, this implies that b@B is expected to
   understand SIPS in the first place, and is required to also support
   TLS.  If the last Record-Route entry however is a sip URI, then b
   would be able to send requests without using TLS (but b would still
   have to be able to handle SIPS schemes when parsing the message).  In
   either case, the Request-URI in the request from b@B to B would be a
   SIPS URI.

4. Overview of Operations

Because of all the problems described in Section 3.3, this specification deprecates the last-hop exception when forwarding a request to the last hop (see Section 5.3). This will ensure that TLS is used on all hops all the way up to the remote target.
Top   ToC   RFC5630 - Page 10
        ..........................         ...........................
        .                        .         .                         .
        .              +-------+ .         . +-------+               .
        .              |       | .         . |       |               .
        .              | Proxy |-----TLS---- | Proxy |               .
        .              |   A   | .         . |  B    |               .
        .              |       | .         . |       |               .
        .            / +-------+ .         . +-------+ \             .
        .           /            .         .            \            .
        .          /             .         .             \           .
        .        TLS             .         .             TLS         .
        .        /               .         .               \         .
        .       /                .         .                \        .
        .      /                 .         .                 \       .
        .   +-------+            .         .              +-------+  .
        .   |       |            .         .              |       |  .
        .   | UAC a |            .         .              | UAS b |  .
        .   |       |            .         .              |       |  .
        .   +-------+            .         .              +-------+  .
        .             Domain A   .         .   Domain B              .
        ..........................         ...........................

                 SIP trapezoid without last-hop exception

   The SIPS scheme implies transitive trust.  Obviously, there is
   nothing that prevents proxies from cheating (see [RFC3261], Section
   26.4.4).  While SIPS is useful to request that a resource be
   contacted securely, it is not useful as an indication that a resource
   was in fact contacted securely.  Therefore, it is not appropriate to
   infer that because an incoming request had a Request-URI (or even a
   To header field) containing a SIPS URI, that it necessarily
   guarantees that the request was in fact transmitted securely on each
   hop.  Some have been tempted to believe that the SIPS scheme was
   equivalent to an HTTPS scheme in the sense that one could provide a
   visual indication to a user (e.g., a padlock icon) to the effect that
   the session is secured.  This is obviously not the case, and
   therefore the meaning of a SIPS URI is not to be oversold.  There is
   currently no mechanism to provide an indication of end-to-end
   security for SIP.  Other mechanisms can provide a more concrete
   indication of some level of security.  For example, SIP Identity
   [RFC4474] provides an authenticated identity mechanism and a domain-
   to-domain integrity protection mechanism.

   Some have asked why is SIPS useful in a global open environment such
   as the Internet, if (when used in a Request-URI) it is not an
   absolute guarantee that the request will in fact be delivered over
   TLS on each hop?  Why is SIPS any different from just using TLS
   transport with SIP?  The difference is that using a SIPS URI in a
Top   ToC   RFC5630 - Page 11
   Request-URI means that if you are instructing the network to use TLS
   over each hop and if it is not possible to reject the request, you
   would rather have the request fail than have the request delivered
   without TLS.  Just using TLS with a SIP Request-URI instead of a SIPS
   Request-URI implies a "best-effort" service: the request can but need
   not be delivered over TLS on each hop.

   Another common question is why not have a Proxy-Require and Require
   option tag forcing the use of TLS instead?  The answer is that it
   would only be functionally equivalent to using SIPS in a Request-URI.
   SIPS URIs however can be used in many other header fields: in Contact
   for registration, Contact in dialog-creating requests, Route, Record-
   Route, Path, From, To, Refer-To, Referred-By, etc.  SIPS URIs can
   also be used in human-usable format (e.g., business cards, user
   interface).  SIPS URIs can even be used in other protocols or
   document formats that allow for including SIPS URIs (e.g., HTML).

   This document specifies that SIPS means that the SIP resource
   designated by the target SIPS URI is to be contacted securely, using
   TLS on each hop between the UAC and the remote UAS (as opposed to
   only to the proxy responsible for the target domain of the Request-
   URI).  It is outside of the scope of this document to specify what
   happens when a SIPS URI identifies a UAS resource that "maps" outside
   the SIP network, for example, to other networks such as the Public
   Switched Telephone Network (PSTN).

4.1. Routing

SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) refer to the same resource. This requirement is implicit in [RFC3261], Section 19.1, which states that "any resource described by a SIP URI can be 'upgraded' to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely". This does not mean that the SIPS URI will necessarily be reachable, in particular, if the proxy cannot establish a secure connection to a client or another proxy. This does not suggest either that proxies would arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request (see Section 5.3). Rather, it means that when a resource is addressable with SIP, it will also be addressable with SIPS. For example, consider the case of a UA that has registered with a SIPS Contact header field. If a UAC later addresses a request using a SIP Request-URI, the proxy will forward the request addressed to a SIP Request-URI to the UAS, as illustrated by message F13 in Sections 6.3 and in 6.4. The proxy forwards the request to the UA using a SIP Request-URI and not the SIPS Request-URI used in registration. The proxy does this by replacing the SIPS scheme that was used in the
Top   ToC   RFC5630 - Page 12
   registered Contact header field binding with a SIP scheme while
   leaving the rest of the URI as is, and then by using this new URI as
   the Request-URI.  If the proxy did not do this, and instead used a
   SIPS Request-URI, then the response (e.g., a 200 to an INVITE) would
   have to include a SIPS Contact header field.  That SIPS Contact
   header field would then force the other UA to use a SIPS Contact
   header field in any mid-dialog request, including the ACK (which
   would not be possible if that UA did not support SIPS).

   This specification mandates that when a proxy is forwarding a
   request, a resource described by a SIPS Request-URI cannot be
   "downgraded" to a SIP URI by changing the scheme, or by sending the
   associated request over a nonsecure link.  If a request needs to be
   rejected because otherwise it would be a "downgrade", the request
   would be rejected with a 480 (Temporarily Unavailable) response
   (potentially with a Warning header with warn-code 380 "SIPS Not
   Allowed").  Similarly, this specification mandates that when a proxy
   is forwarding a request, a resource described by a SIP Request-URI
   cannot be "upgraded" to a SIPS URI by changing the scheme (otherwise
   it would be an "upgrade" only for that hop onwards rather than on all
   hops, and would therefore mislead the UAS).  If a request needs to be
   rejected because otherwise it would be a misleading "upgrade", the
   request would be rejected with a 480 (Temporarily Unavailable)
   response (potentially with a Warning header field with warn-code 381
   "SIPS Required").  See Section 5.3 for more details.

   For example, the sip:bob@example.com and sips:bob@example.com AORs
   refer to the same user "Bob" in the domain "example.com": the first
   URI is the SIP version, and the second one is the SIPS version.  From
   the point of view of routing, requests to either sip:bob@example.com
   or sips:bob@example.com are treated the same way.  When Bob
   registers, it therefore does not really matter if he is using a SIP
   or a SIPS AOR, since they both refer to the same user.  At first
   glance, Section 19.1.4 of [RFC3261] seems to contradict this idea by
   stating that a SIP and a SIPS URI are never equivalent.
   Specifically, it says that they are never equivalent for the purpose
   of comparing bindings in Contact header field URIs in REGISTER
   requests.  The key point is that this statement applies to the
   Contact header field bindings in a registration: it is the
   association of the Contact header field with the AOR that will
   determine whether or not the user is reachable with a SIPS URI.

   Consider this example: if Bob (AOR bob@example.com) registers with a
   SIPS Contact header field (e.g., sips:bob@bobphone.example.com), the
   registrar and the location service then know that Bob is reachable at
   sips:bob@bobphone.example.com and at sip:bob@bobphone.example.com.
Top   ToC   RFC5630 - Page 13
   If a request is sent to AOR sips:bob@example.com, Bob's proxy will
   route it to Bob at Request-URI sips:bob@bobphone.example.com.  If a
   request is sent to AOR sip:bob@example.com, Bob's proxy will route it
   to Bob at Request-URI sip:bob@bobphone.example.com.

   If Bob wants to ensure that every request delivered to him always be
   transported over TLS, Bob can use [RFC5626] when registering.

   However, if Bob had registered with a SIP Contact header field
   instead of a SIPS Contact header field (e.g.,
   sip:bob@bobphone.example.com), then a request to AOR
   sips:bob@example.com would not be routed to Bob, since there is no
   SIPS Contact header field for Bob, and "downgrades" from SIPS to SIP
   are not allowed.

   See Section 6 for illustrative call flows.



(page 13 continued on part 2)

Next Section