Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)
draft-audet-sip-sips-guidelines-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>.

The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>.

This Internet-Draft will expire in December 2006.

Copyright Notice

Copyright © The Internet Society (2006). All Rights Reserved.

Abstract

This document provides clarifications and guidelines concerning the use of SIPS URI Scheme in the Session Initiation Protocol (SIP).

Table of Contents

• 1.   Introduction
• 2.   Terminology
• 3.   Meaning of SIPS
• 4.   Upgrading and dowgrading between SIP and SIPS
• 5.   Registration
  • 5.1   AOR is to be reachable only with secure transport
  • 5.2   AOR is to be reachable preferably with secure transport
  • 5.3   AOR is to be reachable only without secure transport
• 6.   SIPS in a dialog
• 7.   Usage of tls and TLS parameters
• 8.   REFER and sips
• 9.   Routing
• 10.   GRUU
• 11.   Others
• 12.   SIPS and Client Initiated Connections
• 13.   Background
• 14.   Security Considerations
• 15.   IANA Considerations
• 16.   IAB Considerations
• 17.   Acknowledgments
• 18.   References
  • 18.1   Normative References
  • 18.2   Informational References
• Author's Address
• Intellectual Property and Copyright Statements

• Figure 1: SIP trapezoid

1. Introduction

The use of the SIPS URI scheme and of TLS is somewhat underspecified in SIP [RFC3261] and has been the source of confusion for implementors. The usage of SIPS in various fields such as "Request-URI", "To", "From", "Contact" in different methods (e.g., REGISTER and INVITE), and how it relates to the chosen transport has been particularly confusing. This draft complements another draft that discusses the use of TLS in SIP [I-D.gurbani-sip-tls-use].

This document provides clarifications and guidelines concerning the use of the SIPS URI scheme.

Section 13 also summarizes key points regarding SIPS, scattered through RFC 3261.

NOTE:

This document makes the fundamental assumption that RFC 3261's SIPS usage is essentially correct, albeit underspecified and confusing. Therefore, this document does NOT propose major departures from RFC 3261. Some have advocated drastic changes such as deprecating SIPS altogether. While someting as drastic as deprecating SIPS altogether would have a huge impact on RFC 3261 itself, it does have significant benefits. It has been demonstrated that SIPS is not a useful indicator that end-to-end security was achieved. Furthermore, as demonstrated by this paper, there are quite a few areas where the usage of SIPS is problematic, and where RFC 3261 contradicts itself, which implies that it will be necessary to do some changes to RFC 3261 anyways.

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. Meaning of SIPS

RFC 3261/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.

   ..........................         ...........................
   .                        .         .                         .
   .              +-------+ .         . +-------+               .
   .              |       | .         . |       |               .
   .              | Proxy |-----TLS---- | Proxy |               .
   .              |   A   | .         . |  B    |               .
   .              |       | .         . |       |               .
   .            / +-------+ .         . +-------+ \             .
   .           /            .         .            \            .
   .          /             .         .             \           .
   .        TLS             .         .        Policy-based     .
   .        /               .         .               \         .
   .       /                .         .                \        .
   .      /                 .         .                 \       .
   .   +-------+            .         .              +-------+  .
   .   |       |            .         .              |       |  .
   .   | UA a  |            .         .              | UA b  |  .
   .   |       |            .         .              |       |  .
   .   +-------+            .         .              +-------+  .
   .             Domain A   .         .   Domain B              .
   ..........................         ...........................
  

Figure 1: SIP trapezoid

In this case, if a@A is trying to send a request to sips:b@B, the following will apply:

TLS MUST be used between UA a@A and Proxy A

TLS MUST be used between Proxy A and Proxy B

TLS MAY be used between Proxy B and UA b@B, depending on local policy.

Because B is responsible for it's own security policy inside it's own domain, it could use some other security mechanism. For example, it could be using IPsec, or some lower-layer security mechanism.

OPEN ISSUE:

Should we RECOMMEND that TLS be used between Proxy B and UA b@B?

One may then wonder why TLS is mandatory between UA a@A and Proxy A. The reason is that the resource to be contacted (i.e., b@B) is in Domain B. Since Domain B has no control over the security policy of Domain A, or even what those policies are, it is necessary to normalize the meaning of SIPS accross domains. In other words, B can trust itself for it's own security policy, but it can not trust A's security policy and therefore, using TLS is a way to use a common baseline. Striclty speaking, this has the consequence that UA b, while it may not need to support TLS for incoming requests, it will have to support TLS for outgoing requests (because Domain A can not possibly know what the internal security policies of Domain B may be).

Furthemore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, according to RFC 3261/8.1.1.8, then the contact MUST contain a SIPS URI as well. This means that b@B, upon sending a new Request (e.g., a BYE), will have to use a SIP URI. Which implies that b@B must understand SIPS in the first place, and must also support TLS (unless of course Record-Route is used).

OPEN ISSUE:

This is something that is quite broken in RFC 3261. It is not clear that it can be easily fixed. A first idea is to deprecate the whole idea of allowing SIPS when TLS is not used inside the terminating domain. A second idea would be to deprecate the rule that SIPS must be used in the contact if it is used in the Request-URI (possibly, one could use transport=tls instead, which the far end may consider as a guideline for hop-by-hop instead of an end-to-end requirment), but that is also a very slippery slope. A third idea is obviously to deprecate SIPS altogether.

Obviously, there is nothing that prevents a proxy to cheat and pretend that TLS was used when in fact is was not (see RFC 3261/26.4.4). While SIPS is useful to request that a resource be contacted security, it is not useful as an indication that a resource was in fact contacted security. Therefore, it is not appropriate to infer that because an incoming request had a Request-URI (or To header) containing a SIPS URI, that it necessarily garantees that the request was in fact transmitted security hop-by-hop. Some have been tempted to believe that the SIPS sheme 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 one must therefore be careful not to oversell the meaning of a SIPS URI. There is currently no mechanism to provide an indication of end-to-end security for SIP. Other mechanism may provide a more concrete indication of some level of security. For example, SIP Identity [I-D.ietf-sip-identity] describes an integrity protection mechanism.

4. Upgrading and dowgrading between SIP and SIPS

RFC 3261/19.1 allows for "upgrading" any SIP URI AOR to a SIPS URI AOR if it is desired to communicate securely. It is quite possible that a request will be rejected with response code 416 (either because TLS is not supported, or because the policy is to never support secure transport). When 416 is received, the request could be re-attempted with a SIP URI, but the user should be informed. It should be understood that the concept of ugrading a SIP URI to a SIPS URI in RFC 3261 is meant to apply to AOR, not to other URIs (.e.g., Contacts).

Upgrading a SIP to a SIPS URI AOR is very useful when registering. It allows for a UAC to register both SIP and SIPS contacts in a single registration (with multiple contacts) against a single SIP AOR (registrations only allows for single AOR, but multiple contacts). The registrar, upon seeing both a SIP and SIPS contact (potentially prioritized with a proper q-value), and a single SIP AOR MUST infer that the user is reachabe with a SIPS AOR consisting of the same AOR as the SIP URI, but with the scheme changed from "sip" to "sips".

Note:

The rationale for infering the SIPS URI is that otherwise, some registrars might then expect 2 registrations, one for the SIP AOR, another one for the SIPS AOR. This is quite wasteful. Furthermore, it would be an issue for SIP device manufacturers: if they want their device to be reachable with both a SIP and a SIPS URI, and the type of registrar is not known, the device will have to perform 2 registration. This is quite troublesome because it is very inexpensive for the device to do so, but very expensive for the registrar.

When registering a Contact, a UAC MUST explicitely register both the SIP and SIPS contacts if it expects to be contacted using either SIP or SIPS. A registrar SHOULD NOT "upgrade" SIP contacts to SIPS contacts because it may create situations where a contact is not reachable anymore by other users.

RFC 3261 however does not allow for "downgrading" from SIPS to SIP. That being said, it is possible that redirect server or UAS send a 3XX response to a request to a SIPS URI with a Contact containing a SIP URI. Section 8.1.3.4/RFC 3261 recommends that if the UAC decide to recurse to the SIP URI, it SHOULD inform the user.

OPEN ISSUE:

When a proxy is handling the 3XX, it can obviously not indicate anything to the user that it is recursing from SIPS to SIP. It is not clear what the proxy should do: should it forward the 3XX to the user? Should it just ignore the 3XX?

5. Registration

When an AOR is assigned, it must be determined what policy will be used for reachability.

• AOR is to be reachable only with secure transport
• AOR is to be reachable preferably with secure transport
• AOR is to be reachable only without secure transport

This section provides examples on how the various SIP and SIPS URIs used in different headers should be used for providing these policies. This section makes use of the capability to use multiple contacts in a REGISTER to bind various addresses (with their respective allowable transport, such as UDP, TCP or TLS/TCP) in each of these contacts. It uses the q-value to indicate which address/transport are preferable.

OPEN ISSUE:

Some have argued that instead of explicitely registering all usable address/transport, only one would suffice, and the registrar/proxy would "infer" the secure ones (perhaps from the transport that was used to send the request). Explicitely describing each available transport prevents repeated transport failures when the proxy picks an unsuported type. The usefulness of an explicit indication is more obvious when thinking not just in terms of "secure" versus "not secure", but in terms of all available transports. Currently, this includes UDP, TCP, SCTP, TLS/TCP, TLS/SCTP (maybe DTLS is next...). Furthermore, explicitely describing the protocol allows the proxy to tell the client which protocol it should use by only accepting one in the 200 sent in response to the REGISTER.

If the REGISTER request is sent over secure transport to the registrar, the Request-URI MUST be a sips URI. This means that the Register transaction itself is secure.

The To header indicates the AOR. If the To header is a SIPS URI, it means that the UA is only reachable using a SIPS AOR. If the To header is a SIP URI, it means that the UA is possibly reachable with both a SIP and possibly a SIPS URI.

The meaning of the Contact header in REGISTER is somewhat different than in other methods. The Contacts in the REGISTER associates the Contacts with the AOR (in the To header).

When the UAC registers, it MUST includes all the Contact values in the REGISTER corresponding to each transport it supports, using a q-value to prioritize the transports. The Registrar MUST NOT infer any Contact URI (e.g., infer a SIPS Contact from a SIP Contact). However, as per Section 4, the Registrar MUST infer a SIPS AOR from a SIP AOR in the To header, if there is a SIPS Contact listed. If there is no SIPS Contact listed, the Registrar MUST NOT infer a SIPS AOR from a SIP AOR in the To header unless the last hop is secured using some other means than TLS (e.g., IPsec). The Registrar MUST respond to the REGISTER with a 200 OK listing all the successfully registered contacts. Note that the Registrar may decide to accept one or many of the listed contacts.

5.1 AOR is to be reachable only with secure transport

If an AOR is to be reachable only with secure transport, the AOR MUST be a SIPS AOR, and so MUST the contacts and the Request-URI. The Via header MUST indicate TLS. TLS transport MUST be used to perform the registration.

  REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
  Max-Forwards: 70
  To: Bob <sips:bob@example.com>
  From: Bob <sips:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sips:bob@bobspc.example.com;transport=tcp>
  Expires: 7200
  Content-Length: 0

The registrar responds with a 200 OK as follows:

  SIP 2.0 200 OK
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
       received=192.0.2.4
  To: Bob <sips:bob@example.com>;tag=2493K59K9
  From: Bob <sips:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sips:bob@bobspc.example.com;transport=tcp>;expires=7200
  Date: Mon, 12 Jun 2006 16:43:12 GMT
  Content-Length: 0

The registrar MUST respond to the REGISTER using the same TLS connection.

5.2 AOR is to be reachable preferably with secure transport

In many practical network deployment, one may want to use a secure transport when possible, but still allow for a non-secure transport when it is not possible.

In that situation, the UAC MUST use a SIP URI as an AOR, and not a SIPS URI. The UAC MUST provide both a SIP URI contact and a SIPS URI contact, appropriately prioritized with a q-value.

The transport used for performing the registration itself MUST be TLS. The REGISTER message will be as follows:

  REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
  Max-Forwards: 70
  To: Bob <sip:bob@example.com>
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sips:bob@bobspc.example.com;transport=tcp>;q=0.7,
           <sip:bob@bobspc.example.com;transport=tcp>;q=0.5,
           <sip:bob@bobspc.example.com;transport=udp>;q=0.1
  Expires: 7200
  Content-Length: 0

In this example, the registrar responds with a 200 OK as follows, and list all the registered contacts.

  SIP 2.0 200 OK
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
       received=192.0.2.4
  To: Bob <sip:bob@example.com>;tag=2493K59K9
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sips:bob@bobspc.example.com;transport=tcp>;expires=7200,
           <sip:bob@bobspc.example.com;transport=tcp>;expires=7200,
           <sip:bob@bobspc.example.com;transport=udp>;expires=7200
  Date: Mon, 12 Jun 2006 16:43:12 GMT
  Content-Length: 0

5.3 AOR is to be reachable only without secure transport

In some cases, disabling secure transport completely may be desireable (although it is strongly discourage). This may apply when the equipment does not support TLS, or when there are other security mechanisms in place (like IPsec).

In that situation, the AOR MUST be a SIP URI. The contacts MUST also be SIP URI. However, the transport used for performing the registration itself may be either TLS or not.

If TLS is used for registration, the REGISTER message will be as follows:

  REGISTER sips:registrar.example.com;transport=tcp SIP/2.0
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
  Max-Forwards: 70
  To: Bob <sip:bob@example.com>
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sip:bob@bobspc.example.com;transport=tcp>;q=0.5,
           <sip:bob@bobspc.example.com;transport=udp>;q=0.1
  Expires: 7200
  Content-Length: 0

The registrar MUST respond to the REGISTER using the same TLS connection. The registrar responds with a 200 OK as follows, listing all the registered contacts:

  SIP 2.0 200 OK
  Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds;
       received=192.0.2.4
  To: Bob <sip:bob@example.com>;tag=2493K59K9
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sip:bob@bobspc.example.com;transport=tcp>;expires=7200,
           <sip:bob@bobspc.example.com;transport=udp>;expires=7200
  Date: Mon, 12 Jun 2006 16:43:12 GMT
  Content-Length: 0

If TLS is not used for registration, the REGISTER message will be as follows:

  REGISTER sip:registrar.example.com;transport=tcp SIP/2.0
  Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds
  Max-Forwards: 70
  To: Bob <sip:bob@example.com>
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sip:bob@bobspc.example.com;transport=tcp>;q=0.5,
           <sip:bob@bobspc.example.com;transport=udp>;q=0.2
  Expires: 7200
  Content-Length: 0

In his example, the registrar responds with a 200 OK and picks TCP as the only valid transport for the contact:

  SIP 2.0 200 OK
  Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds;
       received=192.0.2.4
  To: Bob <sip:bob@example.com>;tag=2493K59K9
  From: Bob <sip:bob@example.com>;tag=456248
  Call-ID: 843817637684230@998sdasdh09
  CSeq: 1826 REGISTER
  Contact: <sip:bob@bobspc.example.com;transport=tcp>;expires=7200,
           <sip:bob@bobspc.example.com;transport=udp>;expires=7200
  Date: Mon, 12 Jun 2006 16:43:12 GMT
  Content-Length: 0

6. SIPS in a dialog

There MUST be only one Contact in any request resulting in the establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). As mandated by RFC 3261/8.1.1.8, t, if the Request-URI or top Route header field contains a SIPS URI, the Contact header filed MUST be a SIPS URI as well. This poses a very significant problem in that if the remote end end does not support SIPS, it will not be able to send a mid-dialog request to the client. This may be the case when the far-end domain does not use TLS internally see Section 3.

In the response, the Contact field MUST also be a SIPS URI if the Request-URI contained a SIPS URI or if the topmost Record-Route header contained a SIPS URI or if the Contact header contained one and there was no Record-Route header.

If a UAS does not support SIPS, it MUST reject a request over TLS with response code 416. Upon receiveing a 416 a UAC SHOULD not re-attempt the request with a SIP URI by automatically replacing the SIPS scheme with a SIP scheme. If the UAC does re-attempt the call with a SIP URI, it SHOULD inform to the user that the security level is downgraded.

If the Request-URI is a SIP URI, then the UAC needs to be careful about what to use in the Contact. If the Contact is a SIPS URI, it means that it will only accept mid-dialog requests that are over secure transport. Since the Request-URI is in this case a SIP URI, it is quite possible that the UA sending a request to that URI may not be able to send requests to SIPS URIs. It is therefore RECOMMENDED that in this case, the Contact be a SIP URI, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy).

When a target refresh occurs within a dialog (e.g., re-INVITE, UPDATE), unless there is a need to change it, the UAC SHOULD include a Contact header with a SIPS URI if the original request used a SIPS Request-URI.

The presence of a SIPS Request-URI does not necessarily indicate that the request was sent end-to-end securely. As described in 26.4.4/RFC 3261, a proxy may legitimaly retarget a request from SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the Request-URI alone that SIPS was used for the entire request path. An example of a case where a proxy legitimally retargets from SIP to SIPS is when a UAC registers with a SIP AOR and a SIPS Contact only. A UAC might want to do this because it wants to be reachable with both a SIP and SIPS URI, but it wants to maintain only one connection to it's outbound proxy because of NAT traversal (see Section 12).

So how does a UAS know if the SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS can not know for sure. However, 26.4.4/RFC 3261 recommends how a UAS may make some checks to validate the security. Here is a summary of how the algorithm may look like:

If the URI in the To header is a SIPS URI and the Request-URI is a SIPS, then the dialog is "tentatively" secure. See below.

If the URI in the To header is SIPS and the Request-URI is SIP and there is some other security mechanism (e.g., IPsec) securing the last hop, then the dialog may be "tentatively" secure. See below.

Otherwise the dialog is insecure.

If the dialog was "tentatively" secure, it is RECOMMENDED that the security be checked by checking both the Via headers and the Record-route, as described in 26.4.4/RFC 3261.

Again, it should be restated that all the checking may be circumvented by any proxy on the path that does not follow the rules and recommendations of this document and of RFC 3261.

26.4.4/RFC 3261 also explains that S/MIME may 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 26.4.4/RFC 3261, this is meant to imply that [RFC3893] would be used to "tunnel" important headers (such as To and From) in an encrypted S/MIME body, replicating the information in the SIP message, and allowing the UAS to validate the content of those important headers. While this approach is certainly legal, another approach is to use the SIP Identity mechanism defined in [I-D.ietf-sip-identity]. SIP Identity creates a signed identity digest which includes, amongst other things, the AOR of the sender (from the From header) and the AOR of the original destination (from the To header). It is RECOMMENDED that a UAC use the mechanism in [I-D.ietf-sip-identity] instead of the one defined in RFC 3893.

OPEN ISSUE:

Handling of annomalies are not very well defined in RFC 3261. For example, what if the request contains a SIPS contact but the response contains a SIP contact? What if a UAS receives a SIP Contact replacing a SIPS contact in a target refresh? Should the UAC tear down the dialog if it can not cope with the unexpected response?

7. Usage of tls and TLS parameters

RFC 3261/26.2.2 makes it clear that the use of the "transport=tls" URI transport parameter in SIPS or SIP URIs has been deprecated.:

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.

Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.

However, the "tls" parameter has not been eliminated from the ABNF in RFC 3261/25, and RFC 3261/26.2.1 has a vague reference to it. This has been a source of confusion. Those omissions are errors in RFC 3261.

The "transport=tls" parameter MUST NOT be used.

OPEN ISSUE:

It has been suggested that the "transport=tls" parameter be allowed for cases where it specifically means a "hop-by-hop" TLS link. This could be useful in Request-URIs, Contacts, Record, Record-Route and so forth to indicate the desired transport layer for the hop. It would be particularly useful in cases where one wishes to use TLS if possible, but where one would not want to refuse a request if it wasn't sent end-to-end using TLS (i.e., using sips), because on hop doesn't support TSL. Another example is when mid-dialog requests are sent end-to-end and the originator does not support TLS, but is reachable with TLS (as described in Section 3). Un-deprecating transport=tls" would have very significant impact on RFC 3261. There is absolutely no mention in RFC 3261 of what the parameter would mean in different contextes. For example, in certain cases, one could argue that it would mean "oppurtunistic" use of TLS, i.e., allowing reverting to UDP or TCP transport if TLS is not supported. It seems that since the use of transport=tls is prohibited in RFC 3261, or undefined at best, the parameter would indeed be ignored by entities that don't understand it (which would imply UDP transport). In RFC 3261, only SIPS is ever described. It would also be necessary to add the transport and security to the transport field, e.g., tls+sctp, etc.

OPEN ISSUE:

Otherwise, what should be done if a "transport=tls" parameter is received? Should we mandated that if a URI containing a "transport=tls" parameter (e.g., sip:a@A;transport=tls) that it be interpreted as "sips:a@A;transport=tcp"?

For Via headers however, the following transport "UDP", "TCP", "TLS", "SCTP", and "TLS-SCTP" (see [RFC4168]) are supported.

8. REFER and sips

REFER [RFC3515] and also [RFC3892] introduces its own set of issues with sips:

OPEN ISSUE:

What if a UA with not support for TLS receives a SIPS URI in a Refer-to header in a REFER request? Does it reject the REFER, or accept REFER and send back a 416 in a NOTIFY?

OPEN ISSUE

How should the UAC sending a REFER react if it receives a 416 in response to the REFER?

OPEN ISSUE

What if a UA with TLS support receives a SIP URI in a Refer-to header? Is it allowed to "upgrade" to a SIPS URI? It is probably a bad idea in most scenarios, unless it already knows that the other ends supports TLS (and has a SIPS URI).

9. Routing

Section 16.6 and 16.7 of RFC 3261 explain that if Route or Request-URI contains a SIPS URI, then the corresponding inserted Record-Route MUST be a SIPS URI. It also explains that if the request is received over TLS without using a SIPS URI, then the Recored-Route MUST NOT be a SIPS URI.

OPEN ISSUE

There is absolutely not mention of using "transport=tls" in Record-Route. Furthermore, RFC 3261 makes it clear that the transport parameter SHOULD not be included unless the proxy has knowledge that the next downstream element that will be in the path supports that transport. It is not very clear what would be the difference in meaning between SIPS and transport=tls in this case.

TBD: Path header [RFC3327] and Service-Route [RFC3608] also need to be looked at.

10. GRUU

GRUU [I-D.ietf-sip-gruu] specifies that when a GRUU is obtained through registration, if the To header field in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the To header filed in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned.

OPEN ISSUE

How should the UAC react if the returned GRUU is SIP but the To was SIPS?

OPEN ISSUE

How should the UAC react if the returned GRUU is SIPS but the To was SIP?

11. Others

TBD: Need to look at Replaces [RFC3891], Join [RFC3911] and Target-Dialog. For example, what if this header field is received in a request to a SIPS URI but the dialog to which it relates has a SIP local target, or vice-versa?

TBD: Third-party call control [RFC3725] may also have its own set of issues to investigate.

12. SIPS and Client Initiated Connections

Using SIPS with Client Initiated Connections in SIP [I-D.ietf-sip-outbound] provides its own share of considerations.

A typical example of usage of Client Initiated Connections in SIP is when the UAC wishes to establish a single TLS connection with its outbound proxy (for example, to minimize the requirments for keeping connections alive for NAT traversal), but where the UA wants to be reachable with both SIP and SIPS AORs.

A registration for this scenario would be as follows:

 REGISTER sips:proxy.example.com;transport=tcp SIP/2.0
 Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
 Max-Forwards: 70
 To: Bob <sip:bob@example.com>
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Supported: path
 Route: <sip:proxy.example.com;lr>
 Contact: <sips:bob@bobspc.example.com;transport=tcp>;reg-id=1
          ;+sip.instance="<urn:uuid:00000000-0000-0000-000A95A0E128>"
 Expires: 7200
 Content-Length: 0

The proxy would respond with a 200 OK as follows:

 SIP 2.0 200 OK
 Via: SIP/2.0/TLS bobspc.example.com:5060;branch=z9hG4bKnashds
      ;received=192.0.2.4
 To: Bob <sip:bob@example.com>;tag=2493K59K9
 From: Bob <sip:bob@example.com>;tag=456248
 Call-ID: 843817637684230@998sdasdh09
 CSeq: 1826 REGISTER
 Supported: outbound
 Contact: <sips:bob@bobspc.example.com;transport=tcp>;reg-id=1
          ;+sip.instance="<urn:uuid:00000000-0000-0000-000A95A0E128>"
          ;expires=7200
 Date: Mon, 12 Jun 2006 16:43:12 GMT
 Content-Length: 0

A further incoming request to Bob could be addressed to Bob's SIP AOR (i.e., sip:bob@example.com). The proxy would retarget the request to the SIP AOR to the SIPS Contact described in this example, as described in section 26.4.4/RFC 3261, in order to deliver the request to Bob using the already established TLS connection between Bob's UA and its outbound proxy.

13. Background

The use of the SIPS URI scheme in SIP is scattered throughout the following sections of [RFC3261].

8.1.1.8 describes the use of the Contact header field. Of particular importance are the following statements:

The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog.

If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well.

8.1.3.4 describes processing of 3XX responses. Of particular importance is the following statement:

If the original request had a SIPS URI in the Request-URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI.

8.1.3.5 and 8.2.2.1 implies that if a SIPS is not supported by UAS, it can reject it with a 416, and the UAC SHOULD retry the request with a SIP URI. However, although not discussed in RFC 3261, the user should be informed.

10.2.1 describes address binding of SIPS AOR during registration:

If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS.

12.1.1 describes the UAS behavior when creating a dialog with a SIPS Request-URI or a top Record-Route header:

If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI.

12.1.2 describes the UAC behavior when creating a dialog with a SIPS Request-URI or a top Recored-Route header. Of particular importance are the following statements:

If the request has a Request-URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI.

If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE.

12.2.1.1 expands on what this secure flag means when doing any target refresh requests within that dialog:

A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the "secure" flag is true, that URI MUST be a SIPS URI.

16.6 bullet 4 describes Record Route processing for SIPS URIs by proxies:

If the Request-URI contains a SIPS URI, or the topmost Route header field value [...] contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value [...], MUST insert a Record-Route header field that is not a SIPS URI.

16.7 describes proxy response forwarding with Record-Route:

If the proxy received the request over TLS, and sent it outover a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it outover TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI.

19.1 describes the SIP and SIPS URI in general. Of particular importance is the following statement:

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

19.1.4 describes rules for URI comparisons. Of particular importance is the following statement:

A SIP and SIPS URI are never equivalent.

20.42 describes indicating TLS transport in Via headers:

A Via header field value contains the transport protocol used to send the message, [...] Transport protocols defined here are "UDP", "TCP", "TLS", and "SCTP". "TLS" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS.

26.2.1 describes Transport Layer Security [RFC2246]. Of particular importance is the following statement:

"tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI.

26.2.2 is very important and describes the SIPS URI scheme. Of particular importance is the following statements:

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.

[...]

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.

Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports.

26.4.4 describes the limitations in what to infer from using SIPS URIs. Of particular importance are the the following important statement:

Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. [...]

The reader should also be familiar with [RFC3263] which describes the use of DNS with SIPS schemes.

Finally, because in practical implementations TLS will often be implemented using client-initiated connections, the reader should be familar with [I-D.ietf-sip-outbound].

14. Security Considerations

There are no security considerations introduced by this document.

15. IANA Considerations

There are no IANA considerations.

16. IAB Considerations

There are no IAB considerations.

17. Acknowledgments

The author would like to thank John Elwell, Paul Kyzivat, Rifaat Shekh-Yusef, Meenakshi Kaushik, and Samir Srivastava for their valuable comments.

18. References

18.1 Normative References

18.2 Informational References

Author's Address

Intellectual Property Statement

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.

Disclaimer of Validity

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.

Copyright Statement

Copyright © The Internet Society (2006). 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.

Acknowledgement

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