Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)

The use of the SIPS URI scheme and of TLS is somewhat underspecified in SIP 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 . This document provides clarifications and guidelines concerning the use of the SIPS URI scheme and TLS. Section 7 also summarizes key points regarding SIPS and TLS, scattered through RFC 3261.

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

RFC 3261 allows for "upgrading" any SIP URI to a SIPS URI if it is desired to communicate securily. 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. 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". Should we make the previous statement about infering a SIPS AOR from a SIP AOR a MUST or a SHOULD for the registrar? The problem with making it a SHOULD is that 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, even if it is a "good" registrar that follows the SHOULD. However, 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. Similarly, 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. 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?

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. The UAC registers, including Contact values in the REGISTER for each transport it supports, using a q-value to prioritize the transports. The Registrar responds 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. Sometimes, it makes more sense for the Registrar to only accept one Contact: for example, the registrar may decide to only use the most secure transport when supported. Another reason for only using one transport is when SIP is used with outbound connections (i.e., client initiated) . In the examples in this section, it is assumed that TLS is the only mechanism used for securing SIP. RFC 3261 provides a lot of "escape clauses" which are meant to be used when the last hop is secured with other means than TLS (e.g., IPsec in some network environments). Those escape clauses have been confusing implementors who are using TLS as the main means of security SIP.

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.

From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp Expires: 7200 Content-Length: 0]]> The registrar responds with a 200 OK as follows:

;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp Expires: 7200 Content-Length: 0]]> The registrar MUST respond to the REGISTER using the same TLS connection.

In many practical network deployment, a best-effort policy is desireable, i.e., one wants 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:

From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp;q=0.7, ;transport=tcp;q=0.5, ;transport=udp;q=0.1 Expires: 7200 Content-Length: 0]]> See open issue in section 3. In this example, the registrar responds with a 200 OK as follows, and only adds the sips Contact, in order to force the use of TLS on that link.

;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp Expires: 7200 Content-Length: 0]]>

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:

From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp;q=0.5, ;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, picking TCP as the only valid transport for the contact:

;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp Expires: 7200 Content-Length: 0]]> If TLS is not used for registration, the REGISTER message will be as follows:

From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp;q=0.5, ;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:

;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: ;transport=tcp Expires: 7200 Content-Length: 0]]>

There MUST be only one Contact in any request resulting in the establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). If the Request-URI or top Route header field contains a SIPS URI, the Contact header filed MUST be a SIPS URI as well. 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. RFC 3261 is not very clear what a UAS is to do if it doesn't support SIPS and TLS, in which case the previous paragraph obviously can not apply. Shoud we state that the UAS MUST reject the request with response code 416? In that case, should we say that the UAC MUST NOT re-attempt the request with a SIP URI by automatically replacing the SIPS scheme with a SIP scheme? When a target refresh occurs within a dialog (e.g., re-INVITE, UPDATE), the UAC SHOULD include a Contact header with a SIPS URI if the original request creating the dialog was sent over TLS, and the Request-URI contained a SIPS URI. 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?

RFC 3261 makes it clear that the use of the "transport=tls" URI transport parameter in SIPS or SIP URIs has been deprecated. However, it has not been eliminated from the ABNF in section 25 of RFC 3261. For Via headers however, the following transport "UDP", "TCP", "TLS", "SCTP", and "TLS-SCTP" (see RFC 4168 ) are supported.

REFER introduces its own set of issues with sips: 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? How should the UAC sending a REFER react if it receives a 416 in response to the REFER? 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).

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. How should the UAC react if the returned GRUU is SIP but the To was SIPS? How should the UAC react if the returned GRUU is SIPS but the To was SIP? TBD: Need to look at Replaces, Joing 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? This is a placeholder for more investigation.

TBD: this is a placeholder for -related issues.

The use of the SIPS URI scheme in SIP is scattered throughout the following sections of RFC 3261 . 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: 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 . 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 RFC 3263 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 .

There are no security considerations introduced by this document.

There are no IANA considerations.

There are no IAB considerations.

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