SIP Audet Internet-Draft Nortel Networks Updates: 3261 (if approved) August 17, 2006 Intended status: Standards Track Expires: February 18, 2007 Guidelines for the use of the SIPS URI Scheme in the Session Initiation Protocol (SIP) draft-audet-sip-sips-guidelines-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 February 18, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document provides clarifications, guidelines and new requirements concerning the use of SIPS URI Scheme in the Session Initiation Protocol (SIP). Audet Expires February 18, 2007 [Page 1]
Internet-Draft SIPS Guidelines August 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Meaning of SIPS . . . . . . . . . . . . . . . . . . . . . . . 3 4. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. SIPS in a Dialog . . . . . . . . . . . . . . . . . . . . . . . 9 7. Usage of tls and TLS parameters . . . . . . . . . . . . . . . 10 8. GRUU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. Complete Solution . . . . . . . . . . . . . . . . . . . . . . 12 10. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Alice Calls Bob's SIPS AOR . . . . . . . . . . . . . . . 14 10.2. Alice Calls Bob's SIP AOR . . . . . . . . . . . . . . . . 22 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 13. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 15.1. Normative References . . . . . . . . . . . . . . . . . . 33 15.2. Informational References . . . . . . . . . . . . . . . . 33 Appendix A. To-Be-Done . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Explicit Registration alternative . . . . . . . . . . 35 B.1. AOR is to be reachable only with a SIPS AOR . . . . . . . 36 B.2. AOR is to be reachable with both a SIPS and SIP AOR . . . 37 B.3. AOR is to be reachable only with a SIP AOR . . . . . . . 38 Appendix C. Background . . . . . . . . . . . . . . . . . . . . . 39 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 Intellectual Property and Copyright Statements . . . . . . . . . . 44 Audet Expires February 18, 2007 [Page 2]
Internet-Draft SIPS Guidelines August 2006 1. Introduction The meaning and usage of the SIPS URI scheme and of TLS is at best underspecified in SIP [RFC3261] and has been the source of confusion for implementors. This document provides clarifications, guidelines and new requirements concerning the use of the SIPS URI scheme. I 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Meaning of SIPS RFC 3261/19.1 describes a SIPS URI as follows: A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Section 26.2.2 re-iterates it, with regards to Request-URIs: When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address- of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. Let's take the classic SIP trapezoid to explain the meaning of a sips:b@B URI. Audet Expires February 18, 2007 [Page 3]
Internet-Draft SIPS Guidelines August 2006 .......................... ........................... . . . . . +-------+ . . +-------+ . . | | . . | | . . | Proxy |-----TLS---- | Proxy | . . | A | . . | B | . . | | . . | | . . / +-------+ . . +-------+ \ . . / . . \ . . / . . \ . . TLS . . Policy-based . . / . . \ . . / . . \ . . / . . \ . . +-------+ . . +-------+ . . | | . . | | . . | UA a | . . | UA b | . . | | . . | | . . +-------+ . . +-------+ . . Domain A . . Domain B . .......................... ........................... SIP trapezoid In this case, if a@A is sending a request to sips:b@B, the following will apply: TLS MUST be used between UA a@A and Proxy A TLS MUST be used between Proxy A and Proxy B TLS MAY be used between Proxy B and UA b@B, depending on local policy. One may then wonder why TLS is mandatory between UA a@A and Proxy A but not between Proxy A and UA b@B. The main reason is that RFC 3261 [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 client-server TLS would be used, where UA b would be the client and Proxy B would be the server. Therefore, only client-initiated connections would be able to support TLS. The consequence is that an RFC 3261-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 believe erroneously, the last-hop exception was not created to allow for using a SIPS URI to address a UAs that do not support TLS : the last-hop exception was an attempt to allow for incoming requests TLS when a SIPS URI is used, and does not apply to outgoing requests. Audet Expires February 18, 2007 [Page 4]
Internet-Draft SIPS Guidelines August 2006 OPEN ISSUE: There has been many people expressing the opinion that we should deprecate the "last-hop exception" rule, and nobody so far that objected to it (at least not since it became clear that the exception does not allow for supporting clients that don't support TLS). The author of this draft is one who favors deprecating the "last-hop exception" rule in this specification. Furthemore, consider the problem of using SIPS inside a dialog. If a@A sends a request to b@B using a SIPS Request-URI, according to RFC 3261/8.1.1.8, then the contact MUST contain a SIPS URI as well. This means that b@B, upon sending a new Request (e.g., a BYE), will have to use a SIP URI (unless Record-Route is used). This implies that b@B must understand SIPS in the first place, and must also support TLS (again, unless Record-Route happens to be used). The SIPS scheme implies transitive trust. Obviously, there is nothing that prevents a proxy to cheat and pretend that TLS was used when in fact is was not (see RFC 3261/26.4.4). While SIPS is useful to request that a resource be contacted securely, it is not useful as an indication that a resource was in fact contacted security. Therefore, it is not appropriate to infer that because an incoming request had a Request-URI (or To header) containing a SIPS URI, that it necessarily garantees that the request was in fact transmitted security hop-by-hop. Some have been tempted to believe that the SIPS 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 [I-D.ietf-sip-identity] describes an integrity protection mechanism. 4. Routing This specification mandates that SIP and SIPS URIs that are identical except for the scheme itself (e.g., sip:alice@example.com and sips:alice@example.com) MUST refer to the same resource. This requirement is implicit in RFC 3261/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 securily". Note that 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. Although not mandated specifically in RFC 3261, the implication is that a resource described by a SIPS URI can not be "downgraded" to a SIP URI Audet Expires February 18, 2007 [Page 5]
Internet-Draft SIPS Guidelines August 2006 by just changing the scheme. This specification mandates that a resource described by a SIPS URI MUST NOT be "downgraded" to a SIP URI by changing the scheme, or by sending the associated rquest over a non secure link. For example, sip:bob@example.com and sips:bob@example.com AORs MUST refer to the same user "Bob": 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 26.4.4/RFC 3261). 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. It is the association of the AOR with the Contact in the REGISTER that will determine the reachability of the AOR. At first glance, section 19.1.4/RFC 3261 seems to contradict this idea by stating that a SIP and a SIPS URI are never equivalent. Specifically, it says they are never equivalent for the purpose of comparing bindings in Contact URIs in REGISTER requests. The key point is that this statement applies to the Contact bindings in a registration: it is the association of the Contact 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 (e.g., sips:bob@bobphone.example.com), the registar and the location service then knows that Bob (bob@example.com) is reachable at sips:bob@bobphone.example.com. If a request is sent to sips:bob@bobphone.example.com, Bob's proxy will route it to Bob at sips:bob@bobphone.example.com. If a request is sent to sip:bob@bobphone.example.com, Bob's proxy will also route it to Bob at sips:bob@bobphone.example.com (because of the "upgrade" scenario described above). However, if Bob had registered instead with a SIP Contact (e.g., sip:bob@bobphone.example.com), then a request to sips:bob@example.com would not be routed to Bob, since there is no SIPS contact for Bob, and "downgrades" from SIPS to SIP are not allowed. See Section 10 for illustrative call flows. Since upgrading from SIP to SIPS is allowed it 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 (either because TLS or SIPS is not supported). When 416 is received, the request could be re-attempted with a SIP URI, but the user should be informed. 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 February 18, 2007 [Page 6]
Internet-Draft SIPS Guidelines August 2006 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 being redirected from SIPS to SIP: therefore, it is RECOMMENDED that the proxy forwards the 3XX to the UAC instead of recursing, in order to allow for the UAC to take the appropriate action. Section 16.6 and 16.7 of RFC 3261 explain that if Route or Request- URI contains a SIPS URI, then the corresponding inserted Record-Route MUST be a SIPS URI. It also explains that if the request is received over TLS without using a SIPS URI, then the Recored-Route MUST NOT be a SIPS URI. The same rules apply to the Path Header [RFC3327] and Service-Route [RFC3608]. The presence of a SIPS Request-URI does not necessarily indicate that the request was sent end-to-end securely. As described in 26.4.4/RFC 3261, a proxy may legitimaly retarget a request from SIP to SIPS. Therefore, a UAS MUST NOT assume on the basis of the Request-URI alone that SIPS was used for the entire request path. An example of a case where a proxy legitimally retargets from SIP to SIPS shown in Section 10. So how does a UAS know if the SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS can not know for sure. However, 26.4.4/RFC 3261 recommends how a UAS may make some checks to validate the security. Here is a summary of a potential algorithm: o If the URI in the To header is a SIPS URI and the Request-URI is a SIPS, then the dialog is "tentatively" secure. See below. o If the URI in the To header is SIPS and the Request-URI is SIP and there is some other security mechanism (e.g., IPsec) securing the last hop, then the dialog may be "tentatively" secure. See below. o Otherwise the dialog is insecure. o If the dialog was "tentatively" secure, it is RECOMMENDED that the security be checked by checking both the Via headers and the Record-route, as described in 26.4.4/RFC 3261. Again, it should be restated that all the checking may be circumvented by any proxy on the path that does not follow the rules and recommendations of this document and of RFC 3261: SIPS implies transitive trust. Proxies MAY have their own policy regarding routing of requests to SIP or SIPS URIs. For example, a proxy in a critical environment may Audet Expires February 18, 2007 [Page 7]
Internet-Draft SIPS Guidelines August 2006 be configured to only route SIPS. Some proxies MAY be configured to detect uncompliancies and reject unsecure requests. For example, it could inspect Request-URIs, Path, Record-Route, To, From, Contacts and Via headers to enforce SIPS. 26.4.4/RFC 3261 also explains that S/MIME may also be used by the originating UAC to ensure that the original form of the To header field is carried end-to-end. While not specifically mentioned in 26.4.4/RFC 3261, this is meant to imply that [RFC3893] would be used to "tunnel" important headers (such as To and From) in an encrypted 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, another approach is to use the SIP Identity mechanism defined in [I-D.ietf-sip-identity]. SIP Identity creates a signed identity digest which includes, amongst other things, the AOR of the sender (from the From header) and the AOR of the original destination (from the To header). It is RECOMMENDED that a UAC use the mechanism in [I-D.ietf-sip-identity] instead of the one defined in RFC 3893. 5. Registration This section describes the registration procedures of SIP versus SIP Contacts that follows from the discussion in Section 4. The USC registers either a SIPS or a SIP AOR. From a routing perspective, it does not matter which one is used for registration as they are routed to the same resource. However, if an SIPS AOR is used, a SIPS Contact MUST also be used. If a SIP AOR is used, a SIP Contact MUST also be used. Those are 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 secure" MUST address the Registrar using a SIPS Request-URI, MUST use TLS, MUST register with a SIPS AOR and a SIPS Contact, and must NOT accept requests addressed to a SIP Request-URI. A UA with a policy of "best-effort security" MUST address the Registrar using a SIPS Request-URI, MUST use TLS, MUST register with a SIPS AOR and a SIPS Contact, and MUST accept requests addressed to either SIP or SIPS Request-URIs. A UA with a policy of "No security" MUST address the Registrar using a SIP Request-URI, MUST NOT use TLS, MUST register with a SIP AOR and SIP Contact, and MUST accept requests addressed only to a SIP Request-URI. Audet Expires February 18, 2007 [Page 8]
Internet-Draft SIPS Guidelines August 2006 If proxies (such as outbound proxies) are present in the path between the UA and the registrar, they MUST insert the Path header [RFC3327]. A registrar MUST only accept a binding to a SIPS Contact if all the appropriate URIs are of the SIPS schem: i.e., the Request-URI, the AOR (i.e., To header), the From header, the Contacts and all the Path headers. OPEN ISSUE: What error code should be returned if not ? Should it be 403 "Forbidden"? The usage of the "transport" URI parameter in Contacts in registration is of dubious usefulnes. The assumption is that a UAC may 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 transport be listed as separate contacts (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? It is therefore RECOMMENDED that UACs do not use any transport URI parameters in Contacts in REGISTER. For backward compatibility, a registrar MUST accept a REGISTER message with a transport URI parameter in the Contact. It is RECOMMENDED that a registrar ignores that parameter, i.e., that it will not influence routing. A registrar MUST record the scheme of the Contact. 6. SIPS in a Dialog There MUST be only one Contact in any request resulting in the establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER). As mandated by RFC 3261/8.1.1.8, t, if the Request-URI (or top Route header field) contains a SIPS URI, the Contact header MUST be a SIPS URI as well. This poses a very significant problem if Record-Route is not used in that if the remote end end does not support SIPS, it will not be able to send a mid-dialog request to the client. 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 Audet Expires February 18, 2007 [Page 9]
Internet-Draft SIPS Guidelines August 2006 header contained a SIPS URI or if the Contact header contained one and there was no Record-Route header. If a UAS does not support SIPS, it MUST reject a request to a SIPS Request-URI with response code 416 "Unsupported URI scheme". Upon receiveing a 416 a UAC SHOULD NOT re-attempt the request with a SIP URI by automatically replacing the SIPS scheme with a SIP scheme. If the UAC does re-attempt the call with a SIP URI, it SHOULD inform to the user that the security level is downgraded. If a UAS does not support SIP, it MUST reject a request to a SIP Request-URI with response code 416 "Unsupported URI scheme". Upon receiveing a 416 a UAC SHOULD re-attempt the request with a SIPS URI by automatically replacing the SIP scheme with a SIPS scheme. If the Request-URI is a SIP URI, then the UAC needs to be careful about what to use in the Contact (in case Record-Route is not used end-to-end). If the Contact is a SIPS URI, it means that it will only accept mid-dialog requests that are over secure transport. Since the Request-URI is in this case a SIP URI, it is quite possible that the UA sending a request to that URI may not be able to send requests to SIPS URIs. It is therefore RECOMMENDED that in this case, the Contact be a SIP URI, even if the request is sent over a secure transport (e.g., the first hop could be re-using a TLS connection to the proxy 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 SHOULD include a Contact header with a SIPS URI if the original request used a SIPS Request-URI. OPEN ISSUE: Handling of annomalies are not very well defined in RFC 3261. What if a UAS receives a SIP Contact replacing a SIPS contact in a target refresh? Should the UAC tear down the dialog if it can not cope with the unexpected response? 7. Usage of tls and TLS parameters RFC 3261/26.2.2 makes it clear that the use of the "transport=tls" URI transport parameter in SIPS or SIP URIs has been deprecated: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because Audet Expires February 18, 2007 [Page 10]
Internet-Draft SIPS Guidelines August 2006 it was specific to a single hop of the request. This is a change since RFC 2543. Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports. However, the "tls" parameter has not been eliminated from the ABNF in RFC 3261/25, and RFC 3261/26.2.1 has a vague reference to it. This has been a source of confusion. Those omissions are errors in RFC 3261. NOTE: This needs to be in corrected in RFC 3261. This specification mandates that the "transport=tls" parameter MUST NOT be used. However, for backward compatibility, if a "transport=tls" parameter is received, it SHOULD be interpreted as per the following guidelines: o RFC 3261/16.7 states the transport parameter (e.g., with tcp or udp) SHOULD NOT be used in Record-Route unless it has knowledge that the next upstream element that will be in the path of subsequent supports this transport. Generally, it is RECOMMENDED that the transport parameter never be used in a Record-Route, Route or Path header. Since thet transport=tls URI parameter has been deprecated, it MUST NOT be used in Route, Record-Route or Path headers. o In a Contact in a dialog, it MAY be interpreted as a request to send the request using TLS. Note that this would only have a significance if [I-D.ietf-sip-outbound], Record-Route and 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 (a big if), then that connection could be re-used anyways, regardless of the presense of the transport parameter. It MAY also be ignored by the UAS. o In a Contact in a REGISTER, it the REGISTER is sent over TLS 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 (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. o In a Request-URI, the transport parameter is useless in general because it is hop-by-hop. Audet Expires February 18, 2007 [Page 11]
Internet-Draft SIPS Guidelines August 2006 o In a Contact 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. For Via headers, the following transport "UDP", "TCP", "TLS", "SCTP", and "TLS-SCTP" [RFC4168] are supported. 8. GRUU GRUU [I-D.ietf-sip-gruu] specifies that when a GRUU is assigned to an instance ID/AOR pair, both SIP and SIPS GRUUs will be assigned. It also specificies that when a GRUU is obtained through registration, if the To header 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. GRUU therefore follows the same logic as the one described in Section 5. OPEN ISSUE How should the UAC react if the returned GRUU is SIP but the To was SIPS? OPEN ISSUE How should the UAC react if the returned GRUU is SIPS but the To was SIP? 9. Complete Solution The restrictions described in this document have consequences on the applicability of the SIPS URI scheme. First and foremost, it makes it very clear that the SIPS scheme is only usable when TLS is available end-to-end for the resource to be accessed, even the last hop despite the last-hop exception rule, since the last hop becomes the first hop for requests in the reverse direction. Another consequence, is that when a client-server TLS model is used, it is impossible for the server to establish a TLS connection with the client. The last-hop exception rule provides a not very elegant way around this. However, the RECOMMENDED approach is to use Client Initiated Connections in SIP [I-D.ietf-sip-outbound], as greatly facilitates the use of TLS in general with SIP, and SIPS in particular. Client Initiated Connections in SIP allows for the use of the Client/ Audet Expires February 18, 2007 [Page 12]
Internet-Draft SIPS Guidelines August 2006 Server TLS model, where only the UA can initiate a TLS connection with its proxy, since the TLS connection between the UA and it's proxy is kept alive and available all the time, without some of the restrictions mentioned earlier. Yet another consequence is that if Record-Route is not used (or Path header for REGISTER), the SIPS URI in the Contact in a request must be reachable. This implies that a client-server TLS model can not be used, and that rather, a mutual TLS model has to be used. It further implies that to be usable, the certificate of the entity corresponding to the SIPS URI resource must be known to the initiator of the request (e.g., either through a Global PKI, a known root certificate, etc.). This restricts the applicability of a deployment scenario without Record-Route to closed systems (e.g., a small enterprise). A scalable system using the SIPS URI sheme would typically require the use of [I-D.ietf-sip-outbound] between UAs and their respective servers, as well as Record-route being used end-to-end, and Path header [RFC3327] for registration . 10. Call Flows In the following examples, Bob has two clients, one is a SIP PC client running on his computer, and the other one is a SIP Phone. The PC client does not support SIPS (and does not support TLS either) and consequently only registers with a SIP address. The SIP phone however does support SIPS and TLS, and consequently registers with a SIPS address. 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. 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 Oubound 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 Proxy B. The following subsections illustrates two examples. In the first one, Alice calls Bob using Bob's SIPS URI, and in the second one, Alice calls Bob's SIP AOR. Audet Expires February 18, 2007 [Page 13]
Internet-Draft SIPS Guidelines August 2006 10.1. Alice Calls Bob's SIPS AOR In this first example, Alice calls Bob's SIPS address (sips:bob@example.com). Proxy B consults the binding in the registration database, and finds the 2 Contact 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, and therefore the request is only sent to sips:bob@bobphone.example.com. Proxy B inserts itself in the Record- Route. Bob answers. Outbound Outbound Bob@bobpc Proxy B Registrar Proxy A Alice | | | | | | REGISTER F1 | | | | |---------------->|REGISTER F2 | | | | |----------->| | | | | 200 F3 | | | | 200 F4 |<-----------| | | |---------------->| | | | | | | | | | Bob@phone | | | | | | | | | | | |REGISTER F5 | | | | | |----------->|REGISTER F6 | | | | | |----------->| | | | | | 200 F7 | | | | | 200 F8 |<-----------| | | | |----------->| | | | | | | | 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 Audet Expires February 18, 2007 [Page 14]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com> From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: path Route: <sip:proxyb.example.com;lr> Contact: <sip:bob@bobpc.example.com> ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;reg-id=1 Expires: 7200 Content-Length: 0 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 <sip:bob@example.com> From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: path Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr> Contact: <sip:bob@bobpc.example.com> ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;reg-id=1 Expires: 7200 Content-Length: 0 Audet Expires February 18, 2007 [Page 15]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com>;tag=2493K59K9 From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: outbound Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr> Contact: <sip:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 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 <sip:bob@example.com>;tag=2493K59K9 From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Supported: outbound Path: <sip:laksdyjanseg237+fsdf@proxyb.example.com;lr> Contact: <sip:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128>" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 Audet Expires February 18, 2007 [Page 16]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com> From: Bob <sips:bob@example.com>;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: path Route: <sips:proxyb.example.com;lr> Contact: <sips:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>" ;reg-id=1 Expires: 7200 Content-Length: 0 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 <sips:bob@example.com> From: Bob <sips:bob@example.com>;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: path Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr> Contact: <sips:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>" ;reg-id=1 Expires: 7200 Content-Length: 0 Audet Expires February 18, 2007 [Page 17]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com>;tag=5150 From: Bob <sips:bob@example.com>;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: outbound Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr> Contact: <sips:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:50 GMT Content-Length: 0 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 <sips:bob@example.com>;tag=5150 From: Bob <sips:bob@example.com>;tag=90210 Call-ID: faif9a@qwefnwdclk CSeq: 12 REGISTER Supported: outbound Path: <sips:psodkfsj+34+kkls@proxyb.example.com;lr> Contact: <sips:bob@bobphone.example.com> ;+sip.instance="<urn:uuid:6F85D4E3-E8AA-46AA-B768-BF39D5912143>" ;reg-id=1 ;expires=7200 Date: Mon, 12 Jun 2006 16:43:50 GMT Content-Length: 0 Audet Expires February 18, 2007 [Page 18]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Route: <sips:proxya.example.net;lr> Contact: <sips:alice@alice-1.example.net> 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sips:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:alice@alice-1.example.net> Content-Type: application/sdp Content-Length: {as per SDP} {SDP not shown} Audet Expires February 18, 2007 [Page 19]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>, <sips:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:alice@alice-1.example.net> 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires February 18, 2007 [Page 20]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>, <sips:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>, <sips:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>, <sips:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> Content-Length: 0 Audet Expires February 18, 2007 [Page 21]
Internet-Draft SIPS Guidelines August 2006 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: <sips:UJH-hUdvb65@proxyb.example.com;lr>, <sips:KFndf+47KsFH@proxya.example.net;lr> Content-Lenght: 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: <sips:KFndf+47KsFH@proxya.example.net;lr> Content-Lenght: 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 <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Lenght: 0 10.2. Alice Calls Bob's SIP AOR In the second example, Alice calls Bob's SIP address instead (sip:bob@example.com). Proxy B consults the binding in the registration database, and finds the 2 Contact 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 Audet Expires February 18, 2007 [Page 22]
Internet-Draft SIPS Guidelines August 2006 Contact and the SIPS Contact, and therefore the request is forked sent to sip:bob@boppc.example.com and sips:bob@bobphone.example.com. 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 February 18, 2007 [Page 23]
Internet-Draft SIPS Guidelines August 2006 Outbound Outbound Bob@bobpc Proxy B Registrar Proxy A Alice | | | | | | REGISTER F1 | | | | |---------------->|REGISTER F2 | | | | |----------->| | | | | 200 F3 | | | | 200 F4 |<-----------| | | |---------------->| | | | | | | | | | Bob@phone | | | | | | | | | | | |REGISTER F5 | | | | | |----------->|REGISTER F6 | | | | | |----------->| | | | | | 200 F7 | | | | | 200 F8 |<-----------| | | | |----------->| | | | | | | INVITE F9 | | | INVITE F11 |<-----------| | INVITE F13' |<------------------------| 100 F10 | |<----------------| 100 F12 |----------->| | 100 F14' |------------------------>| | |---------------->| | | | 180 F15' | | | |---------------->| 180 F16' | | | |------------------------>| 180 F17' | | | 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 Audet Expires February 18, 2007 [Page 24]
Internet-Draft SIPS Guidelines August 2006 Messages F1-F8 are identical to the ones in Section 10.1. The other messages are as follows. 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Route: <sip:proxya.example.net;lr> Contact: <sip:alice@alice-1.example.net> 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 <sips:bob@example.com> From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires February 18, 2007 [Page 25]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:alice@alice-1.example.net> 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/TCP proxya.example.net:5060;branch=z9hG4bKpouet Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires February 18, 2007 [Page 26]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:alice@alice-1.example.net> 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires February 18, 2007 [Page 27]
Internet-Draft SIPS Guidelines August 2006 F15' 180 (INVITE) Bob's PC Client -> Proxy B SIP 2.0 200 OK 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 <sip:bob@example.com>;tag=963258 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:bob@bobpc.example.com> Content-Length: 0 F16' 180 (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 <sip:bob@example.com>;tag=963258 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:bob@bobpc.example.com> Content-Length: 0 F17' 180 (INVITE) Proxy A -> Alice SIP 2.0 200 OK Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout To: Bob <sip:bob@example.com>;tag=963258 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:bob@bobpc.example.com> Content-Length: 0 Audet Expires February 18, 2007 [Page 28]
Internet-Draft SIPS Guidelines August 2006 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.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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sip:alice@alice-1.example.net> 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 Audet Expires February 18, 2007 [Page 29]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> 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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> Content-Length: 0 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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Record-Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Contact: <sips:bob@bobphone.example.com> Content-Length: 0 Audet Expires February 18, 2007 [Page 30]
Internet-Draft SIPS Guidelines August 2006 F18 ACK Alice -> Proxy A ACK sips:bob@bobphone.example.com SIP/2.0 Via: SIP/2.0/TCP alice-1.example.net:5060;branch=z9hG4bKprout Max-Forwards: 70 To: Bob <sips:bob@example.com>;tag=5551212 From: Alice <sips:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: <sip:UJH-hUdvb65@proxyb.example.com;lr>, <sip:KFndf+47KsFH@proxya.example.net;lr> Content-Lenght: 0 F19 ACK Proxy A -> Proxy B ACK sips: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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Route: <sip:KFndf+47KsFH@proxya.example.net;lr> Content-Lenght: 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=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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 ACK Content-Lenght: 0 Audet Expires February 18, 2007 [Page 31]
Internet-Draft SIPS Guidelines August 2006 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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Lenght: 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 <sip:bob@example.com>;tag=5551212 From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 CANCEL Content-Lenght: 0 F22' 487 (INVITE) Proxy B -> Bob's PC Client SIP 2.0 487 Request Terrminated 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 <sip:bob@example.com> From: Alice <sip:alice@example.net>;tag=8675309 Call-ID: lzksjf8723k@sodk6587 CSeq: 1 INVITE Content-Length: 0 11. Security Considerations Most of this document can be considered to be security considerations since it applies to the usage of the SIPS URI. 12. IANA Considerations There are no IANA considerations. Audet Expires February 18, 2007 [Page 32]
Internet-Draft SIPS Guidelines August 2006 13. IAB Considerations There are no IAB considerations. 14. Acknowledgments The author would like to thank Jon Peterson, Cullen Jennings, John Elwell, Jonathan Rosenberg, Paul Kyzivat, Eric Rescorla, Rifaat Shekh-Yusef and Peter Reissner for their valuable input. 15. References 15.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. 15.2. Informational References [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [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, Audet Expires February 18, 2007 [Page 33]
Internet-Draft SIPS Guidelines August 2006 September 2004. [RFC3892] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, 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. [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 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-04 (work in progress), June 2006. [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-10 (work in progress), August 2006. [I-D.ietf-sip-identity] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06 (work in progress), October 2005. Appendix A. To-Be-Done TBD: Need to look at Replaces [RFC3891], Join [RFC3911] and Target- Dialog. For example, what if this header field is received in a request to a SIPS URI but the dialog to which it relates has a SIP local target, or vice-versa? TBD: Third-party call control [RFC3725] may also have its own set of issues to investigate. Audet Expires February 18, 2007 [Page 34]
Internet-Draft SIPS Guidelines August 2006 REFER [RFC3515] and also [RFC3892] introduces its own set of issues with sips: OPEN ISSUE: What if a UA with not support for TLS receives a SIPS URI in a Refer-to header in a REFER request? Does it reject the REFER, or accept REFER and send back a 416 in a NOTIFY? OPEN ISSUE How should the UAC sending a REFER react if it receives a 416 in response to the REFER? OPEN ISSUE What if a UA with TLS support receives a SIP URI in a Refer-to header? Is it allowed to "upgrade" to a SIPS URI? It is probably a bad idea in most scenarios, unless it already knows that the other ends supports TLS (and has a SIPS URI). Appendix B. Explicit Registration alternative This section describes an alternative to using implicit registrations as per the main document. It is included in this draft only to demonstrate what would be the logical conclusion of pursuing an explicit registration mechanism. This appendix is intented to be removed in a later revision to this draft. This approach allows the UA to explicitly tell it's registrar how it can be contacted, i.e., it allows the UA to decide what security can be used for reachability of its AOR. o AOR is to be reachable only with a SIPS AOR o AOR is to be reachable with both a SIPS and SIP AOR o AOR is to be reachable only with a SIP AOR This section provides examples on how the various SIP and SIPS URIs used in different headers should be used for providing these policies. This section makes use of the capability to use multiple contacts in a REGISTER to bind various addresses (with their respective allowable transport, such as UDP, TCP or TLS/TCP) in each of these contacts. It uses the q-value to indicate which address/ transport are preferable. If the REGISTER request is sent over secure transport to the registrar, the Request-URI MUST be a sips URI. This means that the Register transaction itself is secure. The To header indicates the AOR. If the To header is a SIPS URI, it means that the UA is only reachable using a SIPS AOR. If the To header is a SIP URI, it means that the UA is possibly reachable with both a SIP and possibly a SIPS URI. The meaning of the Contact header in REGISTER is different than in Audet Expires February 18, 2007 [Page 35]
Internet-Draft SIPS Guidelines August 2006 other methods. The Contacts in the REGISTER associates the Contacts with the AOR (in the To header). When the UAC registers, it MUST include all the Contact values in the REGISTER corresponding to each transport it supports, using a q-value as appropriate to prioritize the transports. The Registrar MUST NOT infer any Contact URI (e.g., infer a SIPS Contact from a SIP Contact). However the Registrar MUST infer a SIPS AOR from a SIP AOR in the To header, if there is a SIPS Contact listed. If there is no SIPS Contact listed, the Registrar MUST NOT infer a SIPS AOR from a SIP AOR in the To header unless the last hop is secured using some other means than TLS (e.g., IPsec). The Registrar MUST respond to the REGISTER with a 200 OK listing all the successfully registered contacts. Note that the Registrar may decide to accept one or many of the listed contacts. B.1. AOR is to be reachable only with a SIPS AOR If an AOR is to be reachable only with a SIPS AOR, the Contacts and the Request-URI MUST be SIPS URIs. TLS transport MUST be used to perform the registration, and the Via header MUST indicate TLS. REGISTER sips:registrar.example.com SIP/2.0 Via: SIP/2.0/TLS bobphone.example.com:5060;branch=z9hG4bKnashds Max-Forwards: 70 To: Bob <sips:bob@example.com> From: Bob <sips:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sips:bob@bobphone.example.com;transport=tcp> Expires: 7200 Content-Length: 0 The registrar responds with a 200 OK as follows: Audet Expires February 18, 2007 [Page 36]
Internet-Draft SIPS Guidelines August 2006 SIP 2.0 200 OK Via: SIP/2.0/TLS bobphone.example.com:5060;branch=z9hG4bKnashds; received=192.0.2.4 To: Bob <sips:bob@example.com>;tag=2493K59K9 From: Bob <sips:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sips:bob@bobphone.example.com;transport=tcp>;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 The registrar MUST respond to the REGISTER using the same TLS connection. B.2. AOR is to be reachable with both a SIPS and SIP AOR In many practical network deployment, one may want to use a SIPS AOR when possible, but still allow for a SIP AOR 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 Request-URI MUST be a SIPS URI, and the Via must indicate TLS. The REGISTER message will be as follows: REGISTER sips:registrar.example.com SIP/2.0 Via: SIP/2.0/TLS bobphone.example.com:5060;branch=z9hG4bKnashds Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sips:bob@bobphone.example.com;transport=tcp>;q=0.7, <sip:bob@bobphone.example.com;transport=tcp>;q=0.5, <sip:bob@bobphone.example.com;transport=udp>;q=0.1 Expires: 7200 Content-Length: 0 In this example, the registrar responds with a 200 OK as follows, and list all the registered Contacts. Audet Expires February 18, 2007 [Page 37]
Internet-Draft SIPS Guidelines August 2006 SIP 2.0 200 OK Via: SIP/2.0/TLS bobphone.example.com:5060;branch=z9hG4bKnashds; received=192.0.2.4 To: Bob <sip:bob@example.com>;tag=2493K59K9 From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sips:bob@bobphone.example.com;transport=tcp>;expires=7200, <sip:bob@bobphone.example.com;transport=tcp>;expires=7200, <sip:bob@bobphone.example.com;transport=udp>;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 B.3. AOR is to be reachable only with a SIP AOR In some cases, disabling a SIPS AOR completely and only use a SIP AOR may be desireable (although it is strongly discourage). This may apply for example when the equipment does not support TLS. The Contacts MUST also be SIP URIs. The REGISTER message will be as follows: REGISTER sip:registrar.example.com SIP/2.0 Via: SIP/2.0/TCP bobphone.example.com:5060;branch=z9hG4bKnashds Max-Forwards: 70 To: Bob <sip:bob@example.com> From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@bobphone.example.com;transport=tcp>;q=0.5, <sip:bob@bobphone.example.com;transport=udp>;q=0.2 Expires: 7200 Content-Length: 0 The registrar responds with a 200 OK as follows, and lists all the registered Contacts: Audet Expires February 18, 2007 [Page 38]
Internet-Draft SIPS Guidelines August 2006 SIP 2.0 200 OK Via: SIP/2.0/TCP bobphone.example.com:5060;branch=z9hG4bKnashds; received=192.0.2.4 To: Bob <sip:bob@example.com>;tag=2493K59K9 From: Bob <sip:bob@example.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@bobphone.example.com;transport=tcp>;expires=7200, <sip:bob@bobphone.example.com;transport=udp>;expires=7200 Date: Mon, 12 Jun 2006 16:43:12 GMT Content-Length: 0 Appendix C. Background This section is included for reference purposes. It is intended that this appendix will be removed in a further revision of this draft. The use of the SIPS URI scheme in SIP is scattered throughout the following sections of [RFC3261]. 8.1.1.8 describes the use of the Contact header field. Of particular importance are the following statements: The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. 8.1.3.4 describes processing of 3XX responses. Of particular importance is the following statement: If the original request had a SIPS URI in the Request-URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. 8.1.3.5 and 8.2.2.1 implies that if a SIPS is not supported by UAS, it can reject it with a 416, and the UAC SHOULD retry the request with a SIP URI. However, although not discussed in RFC 3261, the user should be informed. 10.2.1 describes address binding of SIPS AOR during registration: If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of Audet Expires February 18, 2007 [Page 39]
Internet-Draft SIPS Guidelines August 2006 the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. 12.1.1 describes the UAS behavior when creating a dialog with a SIPS Request-URI or a top Record-Route header: If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record- Route header field, the Contact header field in the response MUST be a SIPS URI. 12.1.2 describes the UAC behavior when creating a dialog with a SIPS Request-URI or a top Recored-Route header. Of particular importance are the following statements: If the request has a Request-URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE. 12.2.1.1 expands on what this secure flag means when doing any target refresh requests within that dialog: A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the "secure" flag is true, that URI MUST be a SIPS URI. 16.6 bullet 4 describes Record Route processing for SIPS URIs by proxies: If the Request-URI contains a SIPS URI, or the topmost Route header field value [...] contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value [...], MUST insert a Record-Route header field that is not a SIPS URI. 16.7 describes proxy response forwarding with Record-Route: Audet Expires February 18, 2007 [Page 40]
Internet-Draft SIPS Guidelines August 2006 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: Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules: o 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 [RFC4346]. 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: Audet Expires February 18, 2007 [Page 41]
Internet-Draft SIPS Guidelines August 2006 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: Location services are not required to provide a SIPS binding for a SIPS Request-URI. Although location services are commonly populated by user registrations (as described in Section 10.2.1), various other protocols and interfaces could conceivably supply contact addresses for an AOR, and these tools are free to map SIPS URIs to SIP URIs as appropriate. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it is up to the entity that processes the Contact header field of a redirection to determine the propriety of the contact addresses. Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. [...] The reader should also be familiar with [RFC3263] which describes the use of DNS with SIPS schemes. Finally, because in practical implementations TLS will often be Audet Expires February 18, 2007 [Page 42]
Internet-Draft SIPS Guidelines August 2006 implemented using client-initiated connections, the reader should be familar with [I-D.ietf-sip-outbound]. Author's Address Francois Audet Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US Phone: +1 408 495 3756 Email: audet@nortel.com Audet Expires February 18, 2007 [Page 43]
Internet-Draft SIPS Guidelines August 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 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 February 18, 2007 [Page 44]