RFC 5630
The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
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.
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
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.
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].
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.
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
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.
.......................... ........................... . . . . . +-------+ . . +-------+ . . | | . . | | . . | 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
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.
.......................... ........................... . . . . . +-------+ . . +-------+ . . | | . . | | . . | 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
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
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.
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)
