SIP F. Audet Internet-Draft Nortel Networks Intended status: Standards Track April 13, 2007 Expires: October 15, 2007 The use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) draft-ietf-sip-sips-03 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 on October 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document provides clarifications and guidelines concerning the use of SIPS URI scheme in the Session Initiation Protocol (SIP). It also makes normative changes to SIP. This document also provides a discussion of possible future steps in specification. Audet Expires October 15, 2007 [Page 1] Internet-Draft SIPS April 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Meaning of SIPS . . . . . . . . . . . . . . . . . . . . . 3 3.1.1. Scope of SIPS . . . . . . . . . . . . . . . . . . . . 6 3.1.2. Using TLS with SIP instead of SIPS . . . . . . . . . . 6 3.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Detection of hop-by-hop security . . . . . . . . . . . 9 3.2.2. Double Record Routing . . . . . . . . . . . . . . . . 9 3.3. Usage of tls transport parameter and TLS Via parameter . . 11 4. Normative Requirements . . . . . . . . . . . . . . . . . . . . 11 4.1. General User Agent Behavior . . . . . . . . . . . . . . . 11 4.1.1. Service routes . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Registration . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. SIPS in a dialog . . . . . . . . . . . . . . . . . . . 15 4.1.4. Derived dialogs and transactions . . . . . . . . . . . 16 4.1.5. Usage of tls transport parameter . . . . . . . . . . . 16 4.1.6. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Redirect Server Behavior . . . . . . . . . . . . . . . . . 19 5. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.1. Bob Registers His Contacts . . . . . . . . . . . . . . . . 21 5.2. Alice Calls Bob's SIPS AOR . . . . . . . . . . . . . . . . 26 5.3. Alice Calls Bob's SIP AOR using TCP . . . . . . . . . . . 31 5.4. Alice Calls Bob's SIP AOR using TLS . . . . . . . . . . . 41 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Security Considerations . . . . . . . . . . . . . . . . . . . 49 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 8.1. SIP Option Tag . . . . . . . . . . . . . . . . . . . . . . 49 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 49 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 11.1. Normative References . . . . . . . . . . . . . . . . . . . 50 11.2. Informational References . . . . . . . . . . . . . . . . . 50 Appendix A. Future steps in specification . . . . . . . . . . . . 51 A.1. Indication of validity of SIPS . . . . . . . . . . . . . . 51 A.2. True end-to-end encryption of SIP . . . . . . . . . . . . 51 Appendix B. Bug Fixes for RFC 3261 . . . . . . . . . . . . . . . 51 Appendix C. Open issues . . . . . . . . . . . . . . . . . . . . . 53 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 53 Intellectual Property and Copyright Statements . . . . . . . . . . 54 Audet Expires October 15, 2007 [Page 2] Internet-Draft SIPS April 2007 1. Introduction The meaning and usage of the SIPS URI scheme and of TLS [RFC4346] is underspecified in SIP [RFC3261] and has been the 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. This document also provides a discussion of possible future steps in specification. 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. Overview 3.1. Meaning of SIPS [RFC3261]/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. Audet Expires October 15, 2007 [Page 3] Internet-Draft SIPS April 2007 .......................... ........................... . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |-----TLS---- | Proxy | . . | A | . . | B | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . TLS . . Policy-based . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | UA a | . . | UA b | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . .......................... ........................... SIP trapezoid According to [RFC3261], if a@A is sending a request to sips:b@B, the following applies: o TLS must be used between UA a@A and Proxy A o TLS must be used between Proxy A and Proxy B o TLS may be used between Proxy B and UA b@B, depending on local policy. One may 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 [I-D.ietf-sip-outbound]. At that time, it was recognized that in many practical deployments, Proxy B may 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 may 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, [I-D.ietf-sip-outbound] has provided a more Audet Expires October 15, 2007 [Page 4] Internet-Draft SIPS April 2007 satisfactory solution to this problem. [I-D.ietf-sip-outbound] also solve 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]/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 consist of a SIPS URI, this implies that b@B must understand SIPS in the first place, and must 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. Because of all the problems caused by the last hop exception, this specification deprecates the last hop exception when forwarding a request to the last hop (see Section 4.2). This will ensure that TLS is used on all hops all the way up to the remote target. The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents proxies from cheating (see [RFC3261]/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 To header) 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 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 mechanisms may 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 than 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: Audet Expires October 15, 2007 [Page 5] Internet-Draft SIPS April 2007 i.e., that 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 may or may not be delivered over TLS on each hop. Another common question is why not have a Proxy-Require and Require option tag that forces 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, Refer-By, etc. This specification clarifies the significance of using SIPS URIs in these cases. SIPS URIs can also be used in human-usable format (e.g., business cards, user interface, etc.). SIPS URIs can even be used in other protocols that allow for including SIPS URIs (e.g., HTML). 3.1.1. Scope of SIPS 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 of the SIP network, for example, to other networks such as the PSTN. 3.1.2. 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 [RFC3261]/26.2.2 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 to send the request over TLS. In fact, implementations SHOULD try to establish a TLS connection when using a SIP URI. Using SIP over TLS is very simple. A UA opens a TLS connection and uses SIP URIs instead of SIPS URIs for all the headers in a SIP message (From, To, Request-URI, Contact header field, Route, etc.). However, when TLS is used, the Via header indicates TLS. Similarly, proxies may forward requests using TLS if they can open a TLS connection, even if the route set used SIP URIs instead of SIPS Audet Expires October 15, 2007 [Page 6] Internet-Draft SIPS April 2007 URIs. The proxies may insert Record-Route using SIP URIs even if it uses TLS transport. Some user agents, redirect server and proxies may have local policies that enforce TLS on all connections, independently of if SIPS is used or not. 3.2. 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]/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 can not establish a secure connection to a client or another proxy. This does not suggest either that proxies should arbitrarily "upgrade" SIP URIs to SIPS URIs when forwarding a request (See Section 4.2). 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 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 endpoint, as illustrated by message F13 in Section 5.3 and in Section 5.4. The proxy forwards the request to the UA using a SIP Request-URI and not the SIPS Request-URI used in registration (and it does this by substituting the sip scheme to the sips scheme in the registered contact header field binding). 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 wouldn't be possible if that UA did not support SIPS). This specification mandates that a resource described by a SIPS Request-URI can not be "downgraded" to a SIP URI when a proxy is forwarding a request by changing the scheme, or by sending the associated request over a non secure link. See Section 4.2. For example, the sip:bob@example.com and sips:bob@example.com AORs must refer to the same user "Bob" in 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 and sips:bob@example.com are treated the same way. Location services are therefore free to map from SIP to SIPS URIs as appropriate (see Audet Expires October 15, 2007 [Page 7] Internet-Draft SIPS April 2007 [RFC3261]/26.4.4). 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 [RFC3261]/19.1.4 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 if the user is reachable or not with a SIPS URI. Consider this example. If Bob registers with a SIPS contact header field (e.g., sips:bob@bobphone.example.com), the registrar and the location service then knows that Bob (bob@example.com) 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. The proxy should attempt to transport the request over TLS if a TLS connection can be established even if a SIP URI is used. Indeed, some proxies may even have local policies of always using TLS. Furthermore, if Bob wants to ensure that every request delivered to it be always transported over TLS, Bob can use [I-D.ietf-sip-outbound] when registering. However, if Bob had registered instead 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 5 for illustrative call flows. Since upgrading from SIP to SIPS is allowed in other circumstances (e.g., a user "guessing" a SIPS AOR from a SIP AOR on a business card), it is quite possible that a request will be rejected with response code 416 (Unsupported URI scheme), because the UAS only supports the SIP scheme. When 416 (Unsupported URI scheme) is received, the request may be re-attempted with a SIP URI, but the user should be informed. While guessing a SIPS AOR from a known SIP AOR and using it to initiate a request is a valid thing to do, doing the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it) is not a valid thing to do as it would be a security downgrade. Although "downgrading" from SIPS to SIP is disallowed, it is possible that a redirect server or UAS sends a 3XX response to a request to a Audet Expires October 15, 2007 [Page 8] Internet-Draft SIPS April 2007 SIPS URI with a contact header field containing a SIP URI. [RFC3261]/8.1.3.4 states 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 being redirected from SIPS to SIP: therefore, proxies would not be able recurse on the contact header field, and instead would either forward the 3XX to the UAC or reject the request. 3.2.1. 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 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, [RFC3261]/26.4.4 recommends how a UAS may make some checks to validate the security. Additionally, the History-Info header [RFC4244] could be inspected for detecting retargeting between SIP and SIPS. It should be restated that all the checking may be circumvented by any proxies or B2BUAs on the path that does 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 environment may be configured to only route SIPS. Some proxies may be configured to detect non-compliances and reject un-secure requests. For example, proxies could inspect Request-URIs, Path, Record-Route, To, From, contact header field and Via headers to enforce SIPS. [RFC3261]/26.4.4 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 [RFC3261]/26.4.4, this is meant to imply that [RFC3893] would be used to "tunnel" important headers (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 headers. 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, amongst other things, the AOR of the sender (from the From header) and the AOR of the original destination (from the To header). 3.2.2. Double Record Routing While proxies conforming to this specification do not forward or retarget from SIP to SIPS and vice-versa, it is possible that proxies that conform to [RFC3261] but not to this specification may do so. Audet Expires October 15, 2007 [Page 9] Internet-Draft SIPS April 2007 The use case for a proxy to forward a request from SIPS to SIP was the "last hop exception" downgrade described in Section 1. This section explains how such a proxy would be able to use "double record route" in order to forward or retarget a request from SIP to SIPS or from SIPS to SIP. This section is included for completeness, to describe how to achieve backward compatibility. When a proxy inserts a Record-Route entry, it must take care in using the proper scheme so that further in-dialog requests are sent to the proper URI. [RFC3261] sections 16.6 and 16.7 describe how this can be done by having the proxy modifying the Record-Route in the response. However, as described in [RFC3608], this is problematic. It is preferable to use the procedures of [RFC3608], and instead of following the procedure in [RFC3261], proxies that are inserting Record-Route or Path header field URIs would record not one but two route URIs when processing the request in the case where the scheme is changed. The first value recorded indicates the scheme of the receiving interface, and the second indicates the scheme of the sending interface. When processing the response, no modification of the recorded route is required. This optimization provides for fully invertible routes that can be effectively used in construction of service routes. If the Request-URI or the topmost Route header on the receiving interface is SIPS and the Request-URI on the sending interface is SIP, then the first value recorded uses a SIPS URI and the second value indicates a SIP URI. It is illustrated as follows: UA a Proxy UA b -------REQUEST sips:-------->-------REQUEST sip:---------> Record-Route: , <------Response sips:-------<-------Response sip:--------- Record-Route: Record-Route: , Record routing from SIPS to SIP If the Request-URI on the receiving interface is SIP and the Request- URI on the sending interface is SIPS, then the first value recorded uses a SIP URI and the second value indicates a SIPS URI. It is illustrated as follows: Audet Expires October 15, 2007 [Page 10] Internet-Draft SIPS April 2007 UA a Proxy UA b -------REQUEST sip:--------->-------REQUEST sips:--------> Record-Route: , <------Response sip:--------<-------Response sips:-------- Record-Route: Record-Route: , Record routing from SIP to SIPS Note that the same rules apply to the Path Header [RFC3327]. 3.3. Usage of tls transport parameter and TLS Via parameter [RFC3261]/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. However, the "tls" parameter has not been eliminated from the ABNF in [RFC3261]/25, and [RFC3261]/26.2.1 has a vague reference to it. This has been a source of confusion. The reference in section 26.2.1 is an error in [RFC3261] (see Appendix B). However, the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. For Via headers, the following transport protocol are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS-SCTP". 4. Normative Requirements This section describes all the normative requirements defined by this specification. The justification for the [RFC2119] language is provided by the previous sections of this specification. 4.1. General User Agent Behavior When presented with a SIPS URI, a UAC or UAS MUST NOT map it to a SIP URI. For example, if a directory entry includes a SIPS AOR, the UAC Audet Expires October 15, 2007 [Page 11] Internet-Draft SIPS April 2007 must not send requests to that AOR using a SIP Request-URI. Similarly, if a user reads a business card with a SIPS URI, he should not infer a SIP URI (unfortunately, we can not prevent people from being foolish). If a 3XX response includes a SIPS contact header field, the UAC MUST NOT replace it with a SIP Request-URI (e.g., by replacing the SIPS scheme with a SIP scheme) when sending a request as a result of the redirection. A UAC that conforms to this specification MUST include a sips option- tag in Supported or Require header field when sending a request. The Supported header is useful for a "backward compatible mode" where the UAS may not support this specification, but still support SIPS as per [RFC3261] (note however that since the usage of SIPS was greatly underspecified in [RFC3261], there is no guarantee that it will actually work). The Require header field is useful for a mode where the expectation is that this specification be supported throughout the network (for example, to enforce the deprecation of the last hop exception). If the Request-URI is a SIP URI, a sips option-tag in a Require header field MUST NOT be used, and a Supported header field MUST be used instead. If a UAS receives a request with the sips option-tag in a Supported or Require header field and it accepts the registration, it MUST include the sips option-tag in Supported or Require header in a 200 (OK) response. If the UAS does not support the sips option-tag, it will reject a request with a sips option-tag in a Require header field, and it will no include the sips option-tag in a 200 (OK) sent in response to a request with a sips option-tag in a Supported header. If a UAC sent a request with a sips option-tag in a Supported header, and the 200 (OK) did not include a sips option-tag in a Require or Supported header, it will know that the procedures of this specification are not supported by the UAS. The UAC MUST include the sips option-tag in a Proxy-Require header in a request if it wants to ensure that this specification is supported by all proxies along the path (this is not suitable for a "backward compatible mode"). As mandated by [RFC3261]/8.1.1.8, in a request, "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". Furthermore, as mandated by [RFC3261]/12.1.1, "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 filed in the response MUST be a SIPS URI". If a UAS does not support SIPS, "it SHOULD reject the request with a 416 (Unsupported URI scheme) response" as described in [RFC3261]/ 8.2.2.1. Upon receiving a 416, a UAC MUST NOT re-attempt the request by automatically replacing the SIPS scheme with a SIP scheme as Audet Expires October 15, 2007 [Page 12] Internet-Draft SIPS April 2007 described in [RFC3261]/8.1.3.5 as it would be a security vulnerability. If the UAC does re-attempt the call with a SIP URI, it SHOULD get a confirmation from the user to authorize re-initiating the session with a SIP Requst-URI instead of a SIPS Request-URI. If a UAS does not wish to be contacted with a SIP URI, it MAY reject a request to a SIP Request-URI with response code 404 (Not Found), or it MAY redirect the request to a SIPS URI with a 3XX response. A 3XX response has the advantage that it provides some indication to the UAC on why the request was rejected, i.e., that the session SHOULD be tried again to the SIPS Contact header field. Using a 404 (Not Found) provides no useful indication on why the request is rejected. Upon receiving a 3XX response with a SIPS Contact header field, the UAC SHOULD automatically re-initiate the request using a SIPS Request-URI (i.e., it does not need to get a confirmation from the user to autorize re-initiating the session with a SIPS Request-URI instead of a SIP Request-URI). 4.1.1. Service routes If a UA registers with a SIPS contact header field, the registrar returning a service route MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client. If a UA registers with a SIPS contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA. It is the responsibility of the UAC to use a Route header consisting of all SIPS URIs when using a SIPS Request-URI and contact header field. Specifically, If the service route included SIP URI, the UAC MUST upgrade the SIP URIs to SIPS URIs simply by changing the scheme from "sip" to "sips" before sending the request. Note that this allows for configuring or discovering one Service Route with all SIP URIs and allowing sending requests to both SIP and SIPS URIs. 4.1.2. Registration This section describes the registration procedures of SIPS versus SIP contact header field that follows from the discussion in Section 3.2. The UAC registers either a SIPS or a SIP AOR. From a routing perspective, it does not matter which one is used for registration as they identify the same resource. The registrar MUST consider AORs that are identical except for one having the SIP scheme and the other having the SIPS scheme to be equivalent. If a UA wishes to be reachable with a SIPS URI, it MUST register with Audet Expires October 15, 2007 [Page 13] Internet-Draft SIPS April 2007 a SIPS contact header field. Requests addressed to that UA's AOR using either a SIP or SIPS Request-URI will be routed to that UA. Note that this includes UA that support both SIP and SIPS. If a UA does not wish to be reached with a SIPS URI, it MUST register with a SIP contact header field. The UA MUST NOT include a sips option-tag in that case. Because registering with a SIPS contact header field implies a binding to both a SIPS Contact and a corresponding SIP Contact, a UA MUST NOT include both the SIPS and the SIP version of the same contact header field in a REGISTER: it MUST only use the SIPS version in this case. Similarly, a UA SHOULD NOT register both a SIP contact header field and a SIPS contact header field in separate registrations as the SIP contact header field would be superfluous. Note however that a UA could register first with a SIP contact header field (meaning it does not support SIPS), and later register with a SIPS contact header field (meaning it now supports SIPS). If a UA wants to ensure that no requests are delivered without using TLS on that last hop, the UA MUST use [I-D.ietf-sip-outbound]. If all the contact header fields in a REGISTER are SIPS, a SIPS AOR MUST be used by the UAC in the REGISTER. If at least one of the contact header fields is SIP or is neither SIP nor SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by the UAC. However, the registrar MUST treat the SIP and SIPS schemes of the AOR the same way (i.e., it MUST not care if it is SIP or SIPS). These are purely mechanical rules with no influence on routing. Furthermore, it is a matter of local policy for a UA to accept incoming requests addressed to a URI scheme that does not correspond to what it used for registration. For example, a UA with a policy of "always SIPS" would address the Registrar using a SIPS Request-URI over TLS, would register with a SIPS contact header field, and would reject requests addressed to a SIP Request-URI with 403 (Forbidden). A UA with a policy of "best-effort SIPS" would address the Registrar using a SIPS Request-URI over TLS, would register with a SIPS contact header field, and would accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No SIPS" would address the Registrar using a SIP Request-URI, could use TLS or not, would register with a SIP AOR and a SIP contact header field, and would accept requests addressed to a SIP Request-URI. A registrar MUST only accept a binding to a SIPS contact header field if all the appropriate URIs are of the SIPS scheme, otherwise there could be an inadvertent binding of a secure resource (SIPS) to an unsecured one (SIP). This includes the Request-URI, the Contacts and Audet Expires October 15, 2007 [Page 14] Internet-Draft SIPS April 2007 all the Path headers, but does not include the From and To headers. If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 403 (Forbidden). The usage of the "transport" URI parameter in contact header fields in registration is of dubious usefulness. The assumption is that a UAC would choose one transport for the registration itself, and a different transport for receiving requests. Using the transport URI parameters also results in some complex problems. For example, should all the transports be listed as separate contact header fields (e.g, udp, TCP, sctp, tls over TCP, tls over sctp)? If so, there is no way to signal tls over sctp defined yet. Furthermore, how should they be prioritized using a q-value? If so, it is possible that certain proxies will interpret this as a forking scenario and they might decide to send one incoming request per transport. Another issue is what happens if a UAC fetches bindings by sending an empty REGISTER message. Would the proxy respond with one or all the possible transport? All this would generate unwarranted complexity. It is therefore RECOMMENDED that UACs do not use any transport URI parameters in contact header fields in REGISTER. For backward compatibility, a registrar should accept a REGISTER message with a transport URI parameter in the contact header field. It is recommended that a registrar ignores that parameter, i.e., that it will not influence routing. 4.1.3. SIPS in a dialog If the Request-URI in a request that initiates a dialog is a SIP URI, then the UAC needs to be careful about what to use in the contact header field (in case Record-Route is not used for this hop). If the contact header field was a SIPS URI, it would mean that it would only accept mid-dialog requests that are sent over secure transport on each hop. 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. If the top Route header field does not contain a SIPS URI, the contact header field MUST 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 as would be the case with [I-D.ietf-sip-outbound]). When a target refresh occurs within a dialog (e.g., re-INVITE, UPDATE), unless there is a need to change it, the UAC and UAS MUST include a contact header field with a SIPS URI if the original request used a SIPS Request-URI. Audet Expires October 15, 2007 [Page 15] Internet-Draft SIPS April 2007 4.1.4. Derived dialogs and transactions Sessions, dialogs and transactions may be "derived" from existing ones. A good example of a derived dialog is one that was established as a result of using the REFER method [RFC3515]. As a general principle, derived dialogs and transactions MUST NOT result in an effective downgrading of SIPS to SIP, without the explicit authorization of the entities involved. For example, when a REFER request is used to perform a call transfer, it results in an existing dialog being terminated and another one being created based on the Refer-to URI. If that initial dialog was established using SIPS, then the new one MUST NOT be established using SIP, unless there is an explicit authorization given by the recipient of REFER. This could be a warning provided to the user. Having such a warning could be useful for example for a secure directory service application, resulting in being routed to a UA that does not support SIPS. If the proper treatment is to reject the REFER, for example because warnings are impractical or impossible with very simple phones, it could be rejected with error response 404 (Not Found). Note that a REFER may also be used for referring to resources that do not result in dialogs being created. In fact, a REFER may be used to point to resources that are of a different type than the original one (i.e., not SIP or SIPS). Please see [RFC3515]/5.2 for security considerations related to this. Other examples of derived dialogs and transactions include the use of Third-Party Call Control [RFC3725], the Replaces header [RFC3891], the Join header [RFC3911]. Again, the general principle is that these mechanism SHOULD NOT result in an effective downgrading of SIPS to SIP, without the proper authorization. 4.1.5. Usage of tls transport parameter The "transport=tls" parameter MUST NOT be used by UAs. However, for backward compatibility, if a "transport=tls" parameter is received by a UA, it should be interpreted as per the following guidelines: o [RFC3261]/16.7 states that in a Record-Route, "The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports this transport". Generally, it is recommended that the transport parameter never be used in a Record-Route, Route or Path header. Since the transport=tls URI parameter has been deprecated, it MUST Audet Expires October 15, 2007 [Page 16] Internet-Draft SIPS April 2007 NOT be used in Route, Record-Route or Path headers, and MUST be ignored. o In a contact header field in a dialog, it could be interpreted as a request to send incoming mid-dialog requests using TLS. Note that this would only have a significance if [I-D.ietf-sip-outbound] and Record-Route are not used, and if that URI is nevertheless reachable with TLS which is extremely unlikely. If it was the case that it was reachable with TLS, say because there is an active TLS connection, then that connection could be re-used anyways, regardless of the presence of the transport parameter. It is RECOMMENDED that the "transport=tls" parameter in a Contact header field in a dialog be ignored by the UAS. o In a contact header field in a REGISTER, it tells the registrar that the UAC is reachable through TLS. If the registrar and proxy are co-located, and are the proxy of that UAC, it tells what is already known because the request was sent over TLS (i.e., that it is reachable using TLS), and is therefore redundant. If the registrar is not co-located with the proxy, then it is useless because transport=tls is hop-by-hop and therefore not applicable in this case. The transport=tls parameter MUST therefore be ignored by the registrar in a Contact header field in a REGISTER. o In a Request-URI, the transport parameter is problematic. On the last hop, it is useless because the transport is evident. A UAS MUST ignore the "transport=tls" parameter in a Request-URI. o In a contact header field in a 3XX response, it would essentially mean a request to attempt to re-send the request, using TLS transport. Since the transport=tls parameter only has local significance, it will only be successful if the 3XX is recursed by the last hop. It MAY be ignored by the recursing entity, or the recursing entity MAY re-attempt the request using TLS transport. 4.1.6. GRUU When a GRUU [I-D.ietf-sip-gruu] is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. When a GRUU is obtained through registration, if the Contact header in the REGISTER request contains a SIP URI, the SIP version of the GRUU is returned. If the Contact header filed in the REGISTER request contains a SIPS URI, the SIPS version of the GRUU is returned. If the wrong scheme is received in the GRUU (which would be an error in the registrar), the UAC SHOULD treat it as if the proper scheme was used (i.e., it SHOULD replace the scheme with the proper scheme before using the GRUU). Audet Expires October 15, 2007 [Page 17] Internet-Draft SIPS April 2007 4.2. Proxy Behavior Proxies that conform to this specification MUST NOT use the last hop exception when forwarding or retargeting a request to the last hop. Specifically, when a proxy receives a request with a SIPS Request- URI, the proxy MUST forward or retarget the request to a SIPS Request-URI. If the target UAS had registered previously using a SIP Contact header field instead of a SIPS Contact header field, the proxy MUST NOT forward the request to the URI indicated in the SIPS Contact header field. If the proxy needs to reject the request for that reason, it MUST reject it with a 404 (Not Found). Proxies SHOULD transport requests using a SIP URI over TLS when it is possible to set-up a TLS connection, or re-use an existing one. [I-D.ietf-sip-outbound] for example, allows for re-using an existing TLS connection. Some proxies MAY have policies that prohibits sending any request over anything but TLS. When a proxy receives a request with a SIP Request-URI, the proxy MUST NOT forward the request to a SIPS Request-URI. If the target UAS had registered previously using a SIPS Contact header field, and the proxy decides to forward the request, it MUST substitute the SIP scheme to the SIPS scheme of the URI found in the registered Contact header field binding and use it in the Request-URI of the forwarded request, and those proxies MUST use TLS to forward the request to the UAS. Some proxies MAY have a policy of not forwarding at all requests using a non-SIPS Request-URI if the UAS had registed using a SIPS Contact header fields. If the proxy elects to reject the request because it has such a policy or because it is not capable of establishing a TLS connection, it MAY reject it with a 404 (Not found) or it MAY redirect it to a SIP Request-URI with a 3XX response. A 3XX response has the advantage that it provides some indication to the UAC on why the request was rejected, i.e., that the session SHOULD be tried again to the SIPS Contact header field. Using a 404 (Not Found) provides no useful indication on why the request is rejected. Proxies can use the sips option-tag in Supported, Require and Proxy- Require header fields to detect UAs that do not conform to this specification. This is particularly useful for backward compatibility with legacy implementations that included support for SIPS before the publication of this specification. It should be noted that because the usage of the SIPS URI scheme was underspecified in [RFC3261], proxies may have to do fairly complex implementation-specific non-compliant procedures to handle legacy implementations. It is RECOMMENDED to use an outbound proxy as per the procedures Audet Expires October 15, 2007 [Page 18] Internet-Draft SIPS April 2007 defined in [I-D.ietf-sip-outbound] for supporting UACs that can not provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used). When a proxy sends a request using a SIPS Request-URI and receives a 3XX response with a SIP Contact header field, it MUST NOT recurse on the Contact header field. The Proxy SHOULD forward the 3XX to the UAC instead of recursing, in order to allow for the UAC to take the appropriate action. The proxy MAY instead reject the request with a 404 (Not found) if it is not its policy to allow redirection to be done by the UA and consequently, the user will not receive any indication of why the request was rejected. When a proxy sends a request using a SIP Request-URI and receives a 3XX response with a SIPS Contact header field, it MUST NOT recurse on the Contact header field. The Proxy SHOULD forward the 3XX to the UAC instead of recursing, in order to allow for the UAC to take the appropriate action. The proxy MAY instead map the request with a 416 (Unsupported URI Scheme) if it is not its policy to allow redirection to be done by the UA. The "transport=tls" parameter must not be used by proxies. However, for backward compatibility, if a "transport=tls" parameter is received by a proxy, it should be interpreted as per the following guidelines: o In a Request-URI, the transport parameter is problematic. Before being resolved to the last hop (with loose routing), it is not clear what it would mean to the proxy. A proxy MUST ignore the "transport=tls" parameter in a Request-URI. 4.3. Redirect Server Behavior Using a Redirect Server instead of a Proxy, with TLS has some limitations that has to be taken into account. Since there no pre- established connection (such as with [I-D.ietf-sip-outbound]) between the Proxy and the UAS, it is only appropriate for scenarios where inbound connections are allowed. For example, it could be used in a server to server environment (redirect server or proxy server) where mutual TLS is used, and where there is no NAT traversal issues. A redirect server would not be usable if server-side authentication is used or if there is a NAT between the server and the UAS. When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field to "upgrade" to SIPS if it Audet Expires October 15, 2007 [Page 19] Internet-Draft SIPS April 2007 is in an environment where TLS is usable (as described in the previous paragraph). If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it redirects the request. When a redirect server receives a request with a SIPS Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field to "upgrade" to SIPS if it is in an environment where TLS is usable (as described in the previous paragraph). If the target UAS had registered previously using a SIP Contact header field, the redirect server MUST return a SIP Contact header field in a 3XX response if it chooses to redirect; otherwise it may reject the request with a 416 (Unsupported URI Scheme). 5. Call Flows The following diagram illustrates the topology used for the examples in this section: |-----------| | Registrar | |-----------| | | |-----------| |-----------| | Outbound |__________| Outbound | | Proxy B | | Proxy A | |-----------| |-----------| / | | / | | / | | ______ | | | | _____ _____ |______| O / \ O O / \ O /_______/ /___\ /___\ bob@bobppc bob@bobphone Alice Topology In the following examples, Bob has two clients, one is a SIP PC Audet Expires October 15, 2007 [Page 20] Internet-Draft SIPS April 2007 client running on his computer, and the other one is a SIP Phone. The PC client does not support SIPS and consequently only registers with a SIP contact header field. The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS contact header field. Both of Bob's devices are going through Outbound Proxy B, and consequently, they include a Route header indicating Proxy B. Proxy B removes the Route header corresponding to itself, and adds itself in a Path header. The registration process call flow is illustrated in Section 5.1. After registration, there are 2 contact bindings associated with Bob's AOR of bob@example.com: sips:bob@bobphone.example.com and sip:bob@bobpc.example.com. Alice then calls Bob through her own Outbound Proxy A, including a Route header for Proxy A. Proxy A locates Bob's domain example.com. In this example, that domain is co-located with Bob's outbound proxy, but it could easily have been a separate proxy. Outbound Proxy A removes the Route header corresponding to itself, and inserts itself in the Record-Route and forwards the request to Outbound Proxy B. The following subsections illustrates registration and three examples. In the first example (Section 5.2), Alice calls Bob using Bob's SIPS URI. In the second example (Section 5.3), Alice calls Bob's SIP AOR using TCP transport. In the third example (Section 5.4), Alice calls Bob's SIP AOR using TLS transport. 5.1. Bob Registers His Contacts This call flow illustrates the registration process by which Bob's device registers. His PC client (Bob@bobpc) registers with a SIP scheme and his SIP Phone (Bob@phone) registers with a SIPS scheme. Audet Expires October 15, 2007 [Page 21] Internet-Draft SIPS April 2007 Outbound Bob@bobpc Proxy B Registrar | | | | REGISTER F1 | | |------------------>| REGISTER F2 | | |-------------->| | | 200 F3 | | 200 F4 |<--------------| |------------------>| | | | | | Bob@bobphone | | | | | | | |REGISTER F5 | | | |----------->| REGISTER F6 | | | |-------------->| | | | 200 F7 | | | 200 F8 |<--------------| | |----------->| | | | | | Bob Registers His Contacts Message details F1 REGISTER Bob's PC Client -> Proxy B REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds Max-Forwards: 70 To: Bob From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: path Route: Contact: ;+sip.instance="" ;reg-id=1 Expires: 7200 Content-Length: 0 Audet Expires October 15, 2007 [Page 22] Internet-Draft SIPS April 2007 F2 REGISTER Proxy B -> Registrar REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds Max-Forwards: 69 To: Bob From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: path Path: Contact: ;+sip.instance="" ;reg-id=1 Expires: 7200 Content-Length: 0 F3 200 (REGISTER) Registrar -> Proxy B SIP/2.0 200 OK Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds To: Bob ;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: outbound Path: Contact: ;+sip.instance="" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 Audet Expires October 15, 2007 [Page 23] Internet-Draft SIPS April 2007 F4 200 (REGISTER) Proxy B -> Bob's PC Client SIP/2.0 200 OK Via: SIP/2.0/TCP bobspc.example.com:5060;branch=z9hG4bKnashds To: Bob ;tag=2493K59K9 From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: outbound Path: Contact: ;+sip.instance="" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 F5 REGISTER Bob's Phone -> Proxy B REGISTER sips:registrar.example.com SIP/2.0 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 Max-Forwards: 70 To: Bob From: Bob ;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: sips, path Route: Contact: ;+sip.instance="" ;reg-id=1 Expires: 7200 Content-Length: 0 Audet Expires October 15, 2007 [Page 24] Internet-Draft SIPS April 2007 F6 REGISTER Proxy B -> Registrar REGISTER sips:registrar.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK876354 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 Max-Forwards: 69 To: Bob From: Bob ;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: sips, path Path: Contact: ;+sip.instance="" ;reg-id=1 Expires: 7200 Content-Length: 0 F7 200 (REGISTER) Registrar -> Proxy B SIP/2.0 200 OK Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK876354 Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 To: Bob ;tag=5150 From: Bob ;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: sips, outbound Path: Contact: ;+sip.instance="" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:50 GMT Content-Length: 0 Audet Expires October 15, 2007 [Page 25] Internet-Draft SIPS April 2007 F8 200 (REGISTER) Proxy B -> Bob's Phone SIP/2.0 200 OK Via: SIP/2.0/TLS bobphone.example.com:5061;branch=z9hG4bK9555 To: Bob ;tag=5150 From: Bob ;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: sips, outbound Path: Contact: ;+sip.instance="" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:50 GMT Content-Length: 0 5.2. Alice Calls Bob's SIPS AOR Bob's registration has already occurred as per Section 5.1. In this first example, Alice calls Bob's SIPS AOR (sips:bob@example.com). Proxy B consults the binding in the registration database, and finds the 2 contact header field bindings. Alice had addressed Bob with a SIPS Request-URI (sips:bob@example.com), so Proxy B determines that the calls needs to be routed only to a SIPS contact header field, and therefore the request is only sent to sips:bob@bobphone.example.com. Proxy B inserts itself in the Record-Route. Bob answers at sips:bob@bobphone.example.com. Audet Expires October 15, 2007 [Page 26] Internet-Draft SIPS April 2007 Outbound Outbound Bob@bobpc Proxy B Proxy A Alice | | | | | Bob@bobphone | | INVITE F9 | | | | INVITE F11 |<-------------| | | INVITE F13 |<-------------| 100 F10 | | |<-------------| 100 F12 |------------->| | | 100 F14 |------------->| | | |------------->| | | | | 200 F15 | | | | |------------->| 200 F16 | | | | |------------->| 200 F17 | | | | |------------->| | | | | ACK F18 | | | | ACK F19 |<-------------| | | ACK F20 |<-------------| | | |<-------------| | | | | | | | Alice Calls Bob's SIPS AOR Message details F9 INVITE Alice -> Proxy A INVITE sips:bob@example.com SIP/2.0 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} Audet Expires October 15, 2007 [Page 27] Internet-Draft SIPS April 2007 F10 100 (INVITE) Proxy A -> Alice SIP/2.0 100 Trying Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 F11 INVITE Proxy A -> Proxy B INVITE sips:bob@example.com SIP/2.0 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 69 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F12 100 (INVITE) Proxy B -> Proxy A SIP/2.0 100 Trying Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 28] Internet-Draft SIPS April 2007 F13 INVITE Proxy B -> Bob's Phone INVITE sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 68 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 Supported: sips CSeq: 1 INVITE Record-Route: , Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F14 100 (INVITE) Bob's Phone -> Proxy B SIP/2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 29] Internet-Draft SIPS April 2007 F15 200 (INVITE) Bob's Phone -> Proxy B SIP/2.0 200 OK Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , Contact: Content-Length: 0 F16 200 (INVITE) Proxy B -> Proxy A SIP/2.0 200 OK Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 F17 200 (INVITE) Proxy A -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , Contact: Content-Length: 0 Audet Expires October 15, 2007 [Page 30] Internet-Draft SIPS April 2007 F18 ACK Alice -> Proxy A ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf Max-Forwards: 70 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: , Content-Length: 0 F19 ACK Proxy A -> Proxy B ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf Max-Forwards: 69 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: Content-Length: 0 F20 ACK Proxy B -> Bob's Phone ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bK8msdu2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKplo7hy Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKksdjf Max-Forwards: 68 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Length: 0 5.3. Alice Calls Bob's SIP AOR using TCP Bob's registration has already occurred as per Section 5.1. In the second example, Alice calls Bob's SIP AOR instead (sip:bob@example.com), and she uses TCP as a transport. Proxy B consults the binding in the registration database, and finds the 2 Audet Expires October 15, 2007 [Page 31] Internet-Draft SIPS April 2007 contact header field bindings. Alice had addressed Bob with a SIP Request-URI (sip:bob@example.com), so Proxy B determines that the calls needs to be routed both to the SIP contact header field and the SIPS contact header field, and therefore the request is forked sent to sip:bob@boppc.example.com and sip:bob@bobphone.example.com. Note that the proxy substituted the SIP scheme to the SIPS scheme for bob@bobphone.example.com. Outbound Proxy B inserts itself in the Record-Route. Bob's phone's policy is to accept calls to SIP and SIPS (i.e., "best effort") so both his PC Client and his SIP Phone ring simultaneously. Bob answers on his SIP phone, and the forked call leg to the PC client is canceled. Audet Expires October 15, 2007 [Page 32] Internet-Draft SIPS April 2007 Outbound Outbound Bob@bobpc Proxy B Proxy A Alice | | | | | | | INVITE F9 | | | INVITE F11 |<------------| | INVITE F13' |<-------------| 100 F10 | |<------------------| 100 F12 |------------>| | 100 F14' |------------->| | |------------------>| | | | 180 F15' | | | |------------------>| 180 F16' | | | |------------->| 180 F17' | | Bob@bobphone | |------------>| | | | | | | | INVITE F13 | | | | |<-----------| | | | | 100 F14 | | | | |----------->| | | | | 200 F15 | | | | |----------->| 200 F16 | | | | |------------->| 200 F17 | | | | |------------>| | | | | ACK F18 | | | | ACK F19 |<------------| | | ACK F20 |<-------------| | | |<-----------| | | | | | | | CANCEL F20' | | | |<------------------| | | | 200 F21' | | | |------------------>| | | | 487 F22' | | | |------------------>| | | | | | | Alice Calls Bob's SIP AOR Message details Audet Expires October 15, 2007 [Page 33] Internet-Draft SIPS April 2007 F9 INVITE Alice -> Proxy A INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F10 100 (INVITE) Proxy A -> Alice SIP/2.0 100 Trying Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 F11 INVITE Proxy A -> Proxy B INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 69 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} Audet Expires October 15, 2007 [Page 34] Internet-Draft SIPS April 2007 F12 100 (INVITE) Proxy B -> Proxy A SIP/2.0 100 Trying Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 F13' INVITE Proxy B -> Bob's PC Client INVITE sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 68 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F14' 100 (INVITE) Bob's PC Client -> Proxy B SIP/2.0 100 Trying Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 35] Internet-Draft SIPS April 2007 F15' 180 (INVITE) Bob's PC Client -> Proxy B SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 F16' 180 (INVITE) Proxy B -> Proxy A SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 F17' 180 (INVITE) Proxy A -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 Audet Expires October 15, 2007 [Page 36] Internet-Draft SIPS April 2007 F13 INVITE Proxy B -> Bob's Phone INVITE sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 68 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F14 100 (INVITE) Bob's Phone -> Proxy B SIP/2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 37] Internet-Draft SIPS April 2007 F15 200 (INVITE) Bob's Phone -> Proxy B SIP/2.0 200 OK Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 F16 200 (INVITE) Proxy B -> Proxy A SIP/2.0 200 OK Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 Audet Expires October 15, 2007 [Page 38] Internet-Draft SIPS April 2007 F17 200 (INVITE) Proxy A -> Alice SIP/2.0 200 OK Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 F18 ACK Alice -> Proxy A ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 70 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: , , Content-Length: 0 F19 ACK Proxy A -> Proxy B ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 69 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: , Content-Length: 0 Audet Expires October 15, 2007 [Page 39] Internet-Draft SIPS April 2007 F20 ACK Proxy B -> Bob's Phone ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 68 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Length: 0 F20' CANCEL Proxy B -> Bob's PC Client CANCEL sip:bob@bobpc.example.com SIP/2.0 Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Max-Forwards: 70 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Length: 0 F21' 200 (CANCEL) Proxy B -> Bob's PC Client SIP/2.0 200 OK Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Length: 0 Audet Expires October 15, 2007 [Page 40] Internet-Draft SIPS April 2007 F22' 487 (INVITE) Proxy B -> Bob's PC Client SIP/2.0 487 Request Terminated Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 5.4. Alice Calls Bob's SIP AOR using TLS Bob's registration has already occurred as per Section 5.1. The third example is identical to the second one, except that Alice uses TLS as the transport for her connection to her outbound proxy. Such an arrangement would be common if Alice's UA supported TLS and wanted to use a single connection to the outbound proxy (as would be the case when using [I-D.ietf-sip-outbound]). In the example below, Outbound proxy A is also using TLS as a transport to communicate with Outbound proxy B, but it is not necessarily the case. It should be noted that when using a SIP URI in the Request-URI, but TLS as a transport for sending the request, the Via field indicates TLS. The Route header (if present) typically would use a SIP URI (but it could also be a SIPS URI). The contact header fields, To and From however would also normally indicate a SIP URI. The call flow would be exactly as per the second example (Section 5.3). Messages F20'-F22' are identical to the ones in Section 5.3. The other messages are as follows. Audet Expires October 15, 2007 [Page 41] Internet-Draft SIPS April 2007 F9 INVITE Alice -> Proxy A INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F10 100 (INVITE) Proxy A -> Alice SIP/2.0 100 Trying Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 F11 INVITE Proxy A -> Proxy B INVITE sip:bob@example.com SIP/2.0 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 69 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} Audet Expires October 15, 2007 [Page 42] Internet-Draft SIPS April 2007 F12 100 (INVITE) Proxy B -> Proxy A SIP/2.0 100 Trying Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 F13' INVITE Proxy B -> Bob's PC Client INVITE sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 68 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F14' 100 (INVITE) Bob's PC Client -> Proxy B SIP/2.0 100 Trying Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 43] Internet-Draft SIPS April 2007 F15' 180 (INVITE) Bob's PC Client -> Proxy B SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxyb.example.com:5060;branch=z9hG4bKbalouba.2 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 F16' 180 (INVITE) Proxy B -> Proxy A SIP/2.0 180 Ringing Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 F17' 180 (INVITE) Proxy A -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=963258 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: , Contact: Content-Length: 0 Audet Expires October 15, 2007 [Page 44] Internet-Draft SIPS April 2007 F13 INVITE Proxy B -> Bob's Phone INVITE sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 68 To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} F14 100 (INVITE) Bob's Phone -> Proxy B SIP/2.0 100 Trying Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires October 15, 2007 [Page 45] Internet-Draft SIPS April 2007 F15 200 (INVITE) Bob's Phone -> Proxy B SIP/2.0 200 OK Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 F16 200 (INVITE) Proxy B -> Proxy A SIP/2.0 200 OK Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 Audet Expires October 15, 2007 [Page 46] Internet-Draft SIPS April 2007 F17 200 (INVITE) Proxy A -> Alice SIP/2.0 200 OK Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Supported: sips Record-Route: , , Contact: Content-Length: 0 F18 ACK Alice -> Proxy A ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 70 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: , , Content-Length: 0 F19 ACK Proxy A -> Proxy B ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 69 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: , Content-Length: 0 Audet Expires October 15, 2007 [Page 47] Internet-Draft SIPS April 2007 F20 ACK Proxy B -> Bob's Phone ACK sip:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TLS proxyb.example.com:5061;branch=z9hG4bKbalouba.1 Via: SIP/2.0/TLS proxya.example.net:5061;branch=z9hG4bKpouet Via: SIP/2.0/TLS alice-1.example.net:5061;branch=z9hG4bKprout Max-Forwards: 68 To: Bob ;tag=5551212 From: Alice ;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Length: 0 6. Conclusion SIP [RFC3261] itself introduces some complications with using SIPS, for example when using strict routing instead of loose routing. When a SIPS URI is used in a contact header field in a dialog initiating request and Record-Route is not used, that SIPS URI may not be usable by the other end. If the other end does not support SIPS and/or TLS, it will not be able to use it. The "last-hop exception" is an example of when this may occur. In this case, using Record-Route so that the requests are sent through proxies may help in making it work. Another example of issues with strict routing is that even in a case where the contact header field is a SIPS URI, no Record-Route is used, and the far end supports SIPS and TLS, it may still not be possible for the far end to establish a TLS connection with the SIP originating end if the certificate can not be validated by the far end. This could typically be the case if the originating end was using server-side authentication as described below, or if the originating end is not using a certificate that can be validated. TLS itself has a significant impact on how SIPS may be used. "Server-side authentication" (where the server side provides its certificate but the client side does not) is typically used between a SIP end-user device acting as the TLS client side (e.g., a phone or a personal computer), and it's SIP server (proxy or registrar) acting as the TLS server side. "Mutual TLS" (where both the client and the server side provide their respective certificate) is typically used between SIP servers (proxies, registrars), or statically configured devices such as PSTN gateways or media servers. In the mutual TLS model, for two entities to be able to establish a TLS connection, it is required that both sides be able to validate each other's certificates, either by static configuration or by being able to recurse to a valid root certificate. With server-side authentication, only the client side is capable of validating the server side's certificate, as the client side does not provide a Audet Expires October 15, 2007 [Page 48] Internet-Draft SIPS April 2007 certificate. The consequences of all this are that whenever a SIPS URI is used to establish a TLS connection, it must be possible for the entity establishing the connection (the client) to validate the certificate from the server side. For server-side authentication, [I-D.ietf-sip-outbound] is the recommended approach. For mutual TLS, it means that one should be very careful that the architecture of the network is such that connections are made between entities that have access to each other's credential. Record-Route [RFC3261] and Path [RFC3327] are very useful in ensuring that previously established TLS connections can be re-used. Other mechanism may also be used in certain circumstances: for example, using root-certificates that are widely recognized may allow for more easily created TLS connections. The "last hop exception" introduces significant potential vulnerabilities in SIP and therefore has been deprecated by this specification. 7. Security Considerations Most of this document can be considered to be security considerations since it applies to the usage of the SIPS URI. 8. IANA Considerations 8.1. SIP Option Tag This specification registers one new SIP option tag, as per the guidelines in section 27.1 of [RFC3261]. Name: sips Description: This option-tag is used to identify UACs, UASs and Registrars that support the procedures of this specification. 9. IAB Considerations There are no IAB considerations. 10. Acknowledgments The author would like to thank Jon Peterson, Cullen Jennings, Jonathan Rosenberg, John Elwell, Paul Kyzivat, Eric Rescorla, Robert Sparks, Rifaat Shekh-Yusef, Peter Reissner, Tina Tsou, Keith Drage, Brian Stucker, Patrick Ma, Lavis Zhou, Joel Halpern and Dean Willis for their careful review and input. Audet Expires October 15, 2007 [Page 49] Internet-Draft SIPS April 2007 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. 11.2. Informational References [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004. [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, October 2004. [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005. [RFC4244] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, Audet Expires October 15, 2007 [Page 50] Internet-Draft SIPS April 2007 November 2005. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [I-D.ietf-sip-outbound] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-ietf-sip-outbound-08 (work in progress), March 2007. [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-13 (work in progress), April 2007. Appendix A. Future steps in specification This section is a placeholder for a discussion of possible future steps in specification, and the pros and cons of making such changes. Protocol and normative changes to any specifications (such as RFC 3261) resulting from this discussion would be specified in further documents. A.1. Indication of validity of SIPS Since the presence of a SIPS URI in a Request-URI in an incoming request currently does not guarantee that SIPS and TLS was indeed used on every hop along the path, it has been suggested that it would be useful to define a mechanism for a verifiable assertion that TLS and SIPS were used on every hop. A.2. True end-to-end encryption of SIP Another suggestion has been to define a mechanism to encrypt SIP end- to-end. This would require either an peer-to-peer SIP model, or alternatively a mechanism that allows the encrypted SIP signalling to be tunnelled through proxies. Appendix B. Bug Fixes for RFC 3261 The fifth paragraph of section 10.2.1 should be replaced by: Audet Expires October 15, 2007 [Page 51] Internet-Draft SIPS April 2007 If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field value in the request MUST also be SIPS URIs. In section 16.7 on p. 112 describing Record-Route, the second paragraph should be deleted. The last paragraph of section 19.1 needs to be reworded as follows: A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used on each hop between the UAC and the resource identified by the target SIPS URI. Any resources described by a SIP URI (...) In section 26.2.1 delete the following phrase in the 6th paragraph: ; "tls" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI" The second paragraph of section 26.2.2 needs to be reworded as follows: (...) 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 resource identified by the Request-URI, must be secured with TLS. 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. The first paragraph of section 26.4.4 needs to be replaced by the following: Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (by registering with a SIPS URI as a contact). The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents proxies from cheating. Thus SIPS cannot guarantee that TLS usage will be truly respected end-to-end on each segment of a request path. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS will be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS. The fourth paragraph of section 26.4.4 needs to be deleted. The last sentence of the fifth paragraph of section 26.4.5 needs to be reworded as follows: Audet Expires October 15, 2007 [Page 52] Internet-Draft SIPS April 2007 (...) S/MIME or, preferably, [RFC4474] may also be used (...) Appendix C. Open issues 1. Do we deprecate the "last hop retarget upgrade exception"? The document currently assumes that it IS deprecated, as this is the preference of the author. * Advantages of deprecating are that it greatly simplifies the specification as there is no need for Double Record Route anymore, or for UAS to have to look at both To header and Request-URI to know if the request was indeed sent over TLS on every hop. It also makes it much more consistent with the rest of the spec since it has been deprecated for "downgrades" as well as for "forwarding upgrades". * Disadvantage is that it would not allow for automatically retargeting to a more secure mechanism. * A counter argument is that you can still use TLS transport for the next hop, and in fact, we would recommend using it when possible. This would be particularly obvious to do when sip- outbound is used. Furthemore, you could also use redirection instead of retargeting (i.e., 3XX) to sips. 2. Do we need the sips option tag? * Advantages of the option tag are that it allows for backward compatibility with implementations that have implemented SIPS as per RFC 3261, but not as per this specification. * Disadvantage is, well, one more option tag. Author's Address Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 2456 Email: audet@nortel.com Audet Expires October 15, 2007 [Page 53] Internet-Draft SIPS April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Audet Expires October 15, 2007 [Page 54]