SIP WG V. Gurbani Internet-Draft A. Jeffrey Expires: December 28, 2006 Lucent Technologies, Inc./Bell Laboratories June 26, 2006 Domain Certificates in the Session Initiation Protocol (SIP) draft-gurbani-sip-domain-certs-01 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 December 28, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document attempts to clarify the use of domain certificates in the Session Initiation Protocol (SIP). Currently, there is much ambiguity surrounding domain -- or site -- certificates. Gurbani & Jeffrey Expires December 28, 2006 [Page 1] Internet-Draft Domain Certs June 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 4. A Possible Solution to Conveying the Peer Identity . . . . . 4 5. Registrars and Redirect Servers . . . . . . . . . . . . . . 5 6. Proxy Servers, Identities and SIP Headers . . . . . . . . . 6 7. Server Farms and Certificate Content . . . . . . . . . . . . 8 7.1 Choosing a Server in the Proxy Farm . . . . . . . . . . . 9 7.2 Authenticating a Server From the Proxy Farm . . . . . . . 9 8. Virtual SIP Servers and Certificate Content . . . . . . . . 10 9. Wildcards in dNSName Type . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1 Normative References . . . . . . . . . . . . . . . . . . 13 12.2 Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 14 A. Retargetting in SIP . . . . . . . . . . . . . . . . . . . . 14 B. Retargetting and Identity . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . 18 Gurbani & Jeffrey Expires December 28, 2006 [Page 2] Internet-Draft Domain Certs June 2006 1. 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 RFC 2119 [1]. 2. Introduction Transport Layer Security (TLS) [3] has started to appear in an increasing number of Session Initiation Protocol (SIP) [2] implementations. TLS depends on the Internet X.509 Public Key Infrastructure [4] for its proper use and function. Despite the appearance of TLS in SIP implementations, an enduring question has remained regarding the contents of the certificates for domain verification. We hope that the discussion in this document provides some guidelines in this area. Moreover, TLS by itself only provides security guarantees for the transport layer. In this document, we also discuss the requirements of SIPS message processing to ensure that these security guarantees are also provided at the application layer. The discussion in this document is pertinent to a certificate used for a TLS connection. It may not apply in its entirety to a certificate used in S/MIME, for instance. 3. Problem Statement Put succinctly, the problem can be summarized as how should hosts be identified in a certificate that purports to authoritatively represent a domain from which a request is being sent from, or a domain to which a request is being sent to? Not surprisingly, the answer has varied depending on the exact assumptions under consideration. In SIP, proxy servers, redirect servers, and registrars must posses domain certificates by which their identity is conveyed in an authoritative fashion to a client. Conversely, a proxy server in particular, accepting inter-domain requests from other proxy servers may ask of equivalent domain certificate from its peer. As such, a domain certificate must provide two pieces of identification. First, it must provide an assurance the peer presenting the certificate is an authority for the domain, and second, since TLS in SIP is defined on a hop-by-hop basis, the certificate must also convey the identity of the host that presents the certificate. It is conceivable that the latter identification be made optional; however, an explicit binding in this fashion is preferable to implicitly assuming that a certificate presented that does not contain the canonical name of the Gurbani & Jeffrey Expires December 28, 2006 [Page 3] Internet-Draft Domain Certs June 2006 host does indeed belong to the said host. TLS connections are made between individual hosts, thus conveying the identity of the host directly in the certificate in the form of a canonical host name provides a strong guarantee that the host is indeed who it purports to be. 4. A Possible Solution to Conveying the Peer Identity A TLS client connecting to a TLS server, and a TLS server who has received a certificate from a TLS client need to ensure that the identity of the peer is contained in the certificate. Traditionally, the identity of the peer in the form of a domain name was carried in the Common Name field of the Subject field. However, RFC 3280 [4] has mandated that such identities now be carried in the subjectAltName extension. Accordingly, the recommendations of the SIP working group have been to populate the X.509v3 subjectAltName extension. However, this is underspecified in RFC 3261, which mentions subjectAltName in conjunction with S/MIME only and not TLS. For S/MIME certificates, the subjectAltName provides additional identities of the certificate holder, some in the form of a SIP URI. RFC 3261 does not provide any guidelines on the use of subjectAltName for TLS certificates. As a result, some implementations populate only the Common Name field of the Subject field with a domain name, and others populate only the subjectAltName extension, while still others populate both. This leads to problems when attempting to interpret the certificate contents in a uniform manner. As a possible answer to the problem of conveying identity described above, it seems appropriate that TLS certificates contain two identities in the subjectAltName X.509v3 extension. The first identity would be a Uniform Resource Identifier (URI), more specifically, a SIP URI. This URI corresponds to the name of the domain over which that certificate is asserting its authority (e.g., "URI:sip:example.com"). The second identity would correspond to a domain name system label, more specifically, the canonical name of the host (e.g., "DNS:proxy-1.example.com") to who the certificate belongs. Note that RFC 3261 states that "Proxy servers, redirect servers and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname." (Section 26.3.1) The notion that a domain certificate contains, at the very least, the two identities mentioned above is well worth consideration and further discussion. It solves the problem identified in Section 5.1 of [8], as well as satisfy the RFC 3261 concept on what should be Gurbani & Jeffrey Expires December 28, 2006 [Page 4] Internet-Draft Domain Certs June 2006 contained in a site (or domain) certificate (Section 26.3.1 of RFC 3261, quoted above). As an example, consider that the autonomous domain example.com is applying for a certificate from an authority. As part of the certificate request, it will ask the following two identities be bound to the generated certificate: "URI:sip:example.com", and "DNS: proxy-1.example.com". The former (domain) URI asserts the ownership of the domain to the holder of the certificate, and the latter (host) URI identifies the particular host on hop-by-hop TLS connections. Aspects of this document have been discussed on the SIP working group mailing list and some consensus appears to be coalescing around how to identify a downstream server when the said server presents a certificate upon contact. More specifically, when a client asks for a certificate from the server, and receives one, the certificate must assert an identity corresponding to the name that the client performed a RFC3263-type resolution on. A certificate asserting an identity of "sip:example.com" provides a sufficient anchor for identifying the said server if the client was attempting to connect to a Request-URI (R-URI) (or the URI in the topmost Route header, if one existed) that contained a domainname of "example.com". In this direction (i.e., the server presenting a certificate for verification), it is not absolutely required to search for a canonical hostname as an identity in the certificate (i.e., if RFC3263 leads to the choice of "proxy-1.example.com", then it is not necessary to specifically look for a dNSName SAN extension matching this canonical name). In fact, certain deployments specifically forbid this (SIP Identity [9] mentions an example of RFC3263 resolution on "sip:jon@example.com" leading to a service located at "sip1.example.org"). For the remainder of this document, the term "domain URI" will be used to describe the identity contained in the subjectAltName URI of the form "URI:sip:example.com", and the term "host URI" will be used to describe the identity (canonical hostname) contained in the subjectAltName domain name system label of the form "DNS:proxy- 1.example.com". 5. Registrars and Redirect Servers The identities in the certificate are leveraged by clients to authenticate the registrars and redirect servers they are connecting to. When a client forms a TLS connection to a registrar, it will be presented with a certificate corresponding to the registrar. To assure the client that it is indeed conversing with the correct registrar, the domain URI in the certificate should matches the R-URI the client was trying to reach (in a REGISTER request, the R-URI Gurbani & Jeffrey Expires December 28, 2006 [Page 5] Internet-Draft Domain Certs June 2006 typically names the location service for which the registration is meant, for example, "REGISTER sip:example.com"). Note that this only works as intended if the client and the registrar are in the same domain. If the client is in a visited network, it may have to go through a chain of TLS intermediaries in order to reach its home registrar, and thus it may not be able to directly access the certificate of the home registrar or to open a TLS connection to it. In SIP, redirect servers are used in lieu of proxy servers to offload the processing of a request to the client. As such, the steps that a client would normally use to ascertain the identity of a proxy server are just as applicable when identifying a redirect server. These are outlined in the next section. Needless to say, registrars and redirect servers should authenticate the clients as well. This can be done by asking for a X509 certificate of the client if the client possesses one, or by other means such as HTTP Digest authentication. 6. Proxy Servers, Identities and SIP Headers For the following discussion, assume the standard SIP trapezoid shown in Figure 1: P1 ------------------ P2 (proxy.example.com) (proxy.biloxi.com) V V / \ / \ / \ / \ User Agent User Agent (sip:alice@example.com) (sip:bob@biloxi.com) Figure 1: Traditional SIP Trapezoid P1 establishes a TLS connection to P2 on behalf of the sender of the request, Alice. P1 is presented with P2's certificate. P1 must ensure that the certificate is not expired and is rooted in a trusted hierarchy. Next, P1 compares the domain URI in the certificate against the domainname in the next hop URI -- which could be the R-URI or the topmost Route header -- and looks for a match. If they Gurbani & Jeffrey Expires December 28, 2006 [Page 6] Internet-Draft Domain Certs June 2006 match, P1 can be certain that P2 adequately represents the biloxi.com domain. Note that under some circumstances, the next hop URI may not contain contents that will be amenable to an RFC3263-type of resolution; it may contain a fully-qualified domain name instead of an identifier that would normally be used as input to the RFC3263 process. In such cases, having the host URI in the certificate is a help since P1 can match the host URI in the certificate to the next hop URI to gain confidence in the veracity of the connection. P2 may ask of a certificate from P1. Since P1 is a proxy, it has a certificate, which it presents to P2. P2 now proceeds to do mutual authentication of P1. It should ensure that the certificate is not expired and is rooted in a trusted hierarchy. Additionally, because of the transitive trust nature of TLS connections in SIP, the only attribute that P2 can absolutely depend on verifying of P1 is that it (i.e., P1) represents a host in the example.com domain. To this extent, matching the topmost Via sent-by with one of the URIs in the SAN of the presented certificate will give P2 the confidence regarding adequate representation of the example.com domain by P1. Note that RFC3261 Section 26.3.2.2 essentially allows P2 to match the domainname in the P1's certificate with the domainname of the From header field in the INVITE request for mutual verification. This, however, may not always work due to retargetting since in this case the From header will not correspond to the administrative domain from which the request has been proxied (see Appendix A). Furthermore, the From header may contain an alternative URI such as the tel URI instead of SIP or SIPS URI. Thus, other techniques such as examining the Via trail may additionally be used. Since the issuance of RFC3261, the SIP WG has also expanded considerable resources in SIP Identity [9]. SIP Identity makes it possible for a sending domain to authoritatively assert the originator of a SIP message. This mechanism is much more robust that ensuring that the domainname in the From header matches the one stored in the certificate. The minor irritant in SIP Identity and per-hop transitive nature of TLS connections means that if P2 gets a request from P1 over a TLS connection, and this request has an Identity header (and Identity-Info header), P2 cannot assume that P1 inserted those headers. Some other element upstream of P1 could have inserted them (these headers are not removed by intermediaries; see Appendix B). Thus, it appears that the Via sent-by is the only appropriate SIP header that can be used by P2 to provide it adequate confidence regarding representation of the example.com domain by P1. Gurbani & Jeffrey Expires December 28, 2006 [Page 7] Internet-Draft Domain Certs June 2006 7. Server Farms and Certificate Content In many deployments, a bank of SIP servers are logically treated as one SIP entity. Such clusters of SIP servers, or server farms, are routinely used for load balancing and reliability. Server farms have an interesting intersection with the identities stored in certificates. Generally speaking, it seems appropriate to have at least two identities stored in the certificate. One would correspond to a top level URI and the other one would be specific to that host. The following discussion outlines this in more detail. Figure 2 contains a proxy farm consisting of two SIP servers. This farm is identified by an advertised address of "example.com", i.e., any request that emanates from this farm has a sent-by value of "example.com". Conversely, any requests destined to this farm is done by performing a RFC 3263 [5] resolution of the domain name "example.com". +-----------+ +-----------+ +---------+ | | | | | | | host-a1 | | host-a2 | | Proxy B | | 192.0.2.1 | | 192.0.2.2 | | | +-----------+ +-----------+ +---------+ |________________________________| |_____________| example.com biloxi.com Figure 2: A Server Farm. Here is a partial DNS zone file corresponding to the above farm. $ORIGIN example.com. ; order pref. flags service regexp replacement NAPTR 100 50 "s" "SIPS+D2T" "" _sips._tcp.example.com. ;; pri. weight port target _sips._tcp.example.com. IN SRV 0 1 5061 host-a1.example.com. IN SRV 0 1 5061 host-a2.example.com. host-a1 A 192.0.2.1 host-a2 A 192.0.2.2 Now, assume that each server in the farm has a unique certificate that contains two identities of type dNSName in subjectAltName extension. The first one is "DNS:example.com" and the second Gurbani & Jeffrey Expires December 28, 2006 [Page 8] Internet-Draft Domain Certs June 2006 identity corresponds to the actual host name. The two identities work in concert to provide the appropriate identification and authentication to hosts outside the server farm. 7.1 Choosing a Server in the Proxy Farm When a SIP server outside the server farm wants to choose a server from the farm, it will follow the normal RFC 3263 [5] resolution process to find an appropriate server. In Figure 2, consider that Proxy B wants to choose one of the two servers in the farm. Let's assume that it executes the RFC 3263 server resolution process and arrives at a choice of host-a1.example.com. It now makes a TLS connection to host-a1.example.com and is presented with a certificate from host-a1. Proxy B must ensure that the canonical host name that it used to establish the connection -- host-a1.example.com -- appears as one of the identities in the subjectAltName extension. If this is not the case, then the connection must be closed and the authentication of the server from the proxy farm would be considered to have failed. It goes without saying that host-a1.example.com must mutually authenticate Proxy B. If Proxy B itself is a cluster of proxies, then the steps in the next section can be applied to the authentication of Proxy B. 7.2 Authenticating a Server From the Proxy Farm When any of the servers in the farm establish a TLS connection to Proxy B in a different administrative domain (biloxi.com), they should be prepared to present a certificate if asked by Proxy B. For the sake of this discussion, assume that proxy B asks for a certificate when it accepts a TLS connection. Proxy B now has the certificate of one of the host from the server farm. Proxy B also has a SIP request that contains the following topmost Via header ("received" parameter has been added by Proxy B): Via: SIP/2.0/TLS example.com;branch=z9hG4bK7cx8177; received=192.0.2.2 To authenticate the host in the server farm that sent the request, Proxy B follows the following logic: 1. Verifies that the certificate presented is not expired and that it is rooted in a trusted certificate chain. Gurbani & Jeffrey Expires December 28, 2006 [Page 9] Internet-Draft Domain Certs June 2006 2. Void. 3. Resolve the "sent-by" by performing a DNS SRV lookup for service "_sips" and transport "_tcp". If this fails, go to Step 5. Otherwise, this will result in one or more relevant A/AAAA records. Ensure that one of these records resolves to the IP address in the "received" parameter. 4. If the "sent-by" had a non-default port number, then this port number must match the port number corresponding to the A record that matched in the above step. Got to step 7, authentication is successful. It is open to discussion whether the port number should be used in the matching rule. 5. If DNS SRV lookup failed, then chances are that the contents of the "sent-by" contain a canonical host name. Thus, this name must match the host URI stored in the certificate. If there is no match, the connection should be closed and processing proceeds to step 7; authentication has failed. 6. If the host name in "sent-by" matches the host URI stored in the certificate, then ensure that it resolves to the IP address in the "received" parameter. If so, authentication is successful, otherwise it has failed. Note: This is open to discussion since it allocates a lower probability of a compromised DNS when compared to a compromised certificate. 7. Process is complete. Open issue: Will all of this work if the proxy farm is behind a NAT? In that case, P1 will add a "received" parameter that corresponds to the IP address of the middlebox and not that of the appropriate server from the proxy farm. Open issue: Will all of this work if the proxy farm is behind a TLS accelerator? This is similar to the problem of NATs, but the certificate is issued to the accelerator, not to the proxy. 8. Virtual SIP Servers and Certificate Content The closest guidance in SIP today regarding certificates and virtual SIP servers occurs in SIP Identity ([9], Section 13.4). The quoted section states that, "... certificates have varying ways of describing their subjects, and may indeed have multiple subjects, especially in the 'virtual hosting' cases where multiple domains are managed by a single application." This appears to imply that one certificate will have multiple SANs (or Subject) fields, each such field corresponding to a discrete virtual server that represents a single domain? Since only one certificate is needed for multiple domains, the keying material Gurbani & Jeffrey Expires December 28, 2006 [Page 10] Internet-Draft Domain Certs June 2006 management is simpler, but what happens if one of the domains no longer wants to continue the business relationship with the hosting service? Is the entire certificate to be revoked? Is it conceivable that each domain have a distinct certificate that is provided to the hosting service? Certainly, this means that the domain must share the domain's private key with the hosting service. TLS extensions [7] like the extended client hello allow TLS clients to provide to the TLS server the name of the server they are contacting. Thus, the server can present the correct certificate to establish the TLS connection. TODO: Need some more discussion on the mailing list around this issue. What is the recommended procedure here? 9. Wildcards in dNSName Type RFC 2818 (HTTP over TLS) [6] allows the dNSName component to contain a wildcard; e.g., "DNS:*.example.com". RFC 3280 [4], while not disallowing this explicitly, leaves the interpretation of wildcards to the individual specification. RFC 3261 does not provide any guidelines on the presence of wildcards in certificates. The consensus from the working group discussion leans in the favor of not using them in SIP. 10. Security Considerations The goals of TLS include the following security guarantees at the transport layer: Confidentiality: packets tunneled through TLS can only be read by the sender and receiver. Integrity: packets tunneled through TLS can only be modified by the sender and receiver. Authenticity: each principal is authenticated to the other as posessing a private key for which a certificate has been issued. Moreover, this certificate has not been revoked, and is backed by a certificate chain leading to a mutually trusted trust anchor. By itself, these security guarantees do not immediately lift to guarantees at the application layer. RFC 3261 states that: The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the "domainname" portion of the From header field in the INVITE request. Gurbani & Jeffrey Expires December 28, 2006 [Page 11] Internet-Draft Domain Certs June 2006 This requires each authoritative proxy for atlanta.com to be issued with a certificate containing "atlanta.com" as its subject. This has two problems: 1. It does not correspond to common TLS usage, which is to use a certificate identifying the host. If proxy.biloxi.com is allowed to require that the subject of the certificate contains a DNS entry corresponding to the IP address of proxy1.atlanta.com, then this in turn requires every authoritative proxy for atlanta.com to be registered with the DNS entry atlanta.com. Hence it is impossible for a domain to use different SIP proxies as incoming and outgoing proxies. 2. It makes forensics in the case of compromise more complex. If a malicious principal is discovered making use of a certificate for a private key issued to proxy1.atlanta.com, there is little to identify which of atlanta.com's SIP proxies has been compromised. If the certificate contains proxy1.atlanta.com's name as well as atlanta.com's name, then the forensics are simpler. Fortunately, both of these problems are addressed by having two identities in domain certificate as outlined in Section 3. We expect that appropriate processing requirements of domain certificates will provide the following security guarantees at the application level: Confidentiality: SIPS messages from alice@atlanta.com to bob@biloxi.com can only be read by alice@atlanta.com, bob@biloxi.com, and SIP proxies issued with domain certificates for atlanta.com or biloxi.com. Integrity: SIPS messages from alice@atlanta.com to bob@biloxi.com can only be modified by alice@atlanta.com, bob@biloxi.com, and SIP proxies issued with domain certificates for atlanta.com or biloxi.com. Authenticity: alice@atlanta.com and proxy.atlanta.com are mutually authenticated, and moreover proxy.atlanta.com is authenticated to alice@atlanta.com as an authoritative proxy for domain atlanta.com. Similar mutual authentication guarantees are given between proxy.atlanta.com and proxy.biloxi.com and between proxy.biloxi.com and bob@biloxi.com. As a result, alice@atlanta.com is transitively mutually authenticated to bob@biloxi.com (assuming trust in the authoritative proxies for atlanta.com and biloxi.com). Moreover, if a suitable media key exchange mechanism (such as DH-HMAC with null encryption [DH-HMAC]) is used to protect the media between alice@atlanta.com and bob@biloxi.com, then these guarantees are also provided for the media streams. Gurbani & Jeffrey Expires December 28, 2006 [Page 12] Internet-Draft Domain Certs June 2006 11. Acknowledgments The discussion on proxy farms in Section 7 is inspired by earlier versions of Rohan Mahy's connect-reuse draft. Scott Lawrence suggested the idea of a certificate containing two identities. Jeroen van Bemmel provided comments to draft versions of this document. 12. References 12.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] 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. [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280. 12.2 Informative References [5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Location SIP Servers", RFC 3263, June 2002. [6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [7] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [8] Gurbani, V. and A. Jeffrey, "The Use of Transport Layer Security (TLS) in the Session Initiation Protocol (SIP)", draft-gurbani-sip-tls-use-00.txt (work in progress), February 2006. [9] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06.txt (work in progress), October 2005. Gurbani & Jeffrey Expires December 28, 2006 [Page 13] Internet-Draft Domain Certs June 2006 Authors' Addresses Vijay K. Gurbani Lucent Technologies, Inc./Bell Laboratories 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA Phone: +1 630 224-0216 Email: vkg at aCm dot OrG Alan S.A. Jeffrey Lucent Technologies, Inc./Bell Laboratories 2701 Lucent Lane Room 9F-534 Lisle, IL 60532 USA Email: ajeffrey at bell hyphen labs dot com Appendix A. Retargetting in SIP Re-targetting breaks down several security assumptions in SIP. For instance, consider the following call flow: Gurbani & Jeffrey Expires December 28, 2006 [Page 14] Internet-Draft Domain Certs June 2006 P1 P2 P3 (example.com) (atlanta.com) (biloxi.com) | | | +--F1---------->| | | +--F2--------->| ... Figure 3: Retargetting in SIP F1: INVITE sips:bob@atlanta.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=... Via: SIP/2.0/TLS alice-pc.example.com;branch=... From: Alice ;tag=891jhh To: Bob ... F2: INVITE sips:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TLS proxy.atlanta.com;branch=... Via: SIP/2.0/TLS proxy.example.com;branch=... Via: SIP/2.0/TLS alice-pc.example.com;branch=... From: Alice ;tag=891jhh To: Bob ... Alice sends a request to Bob through her outbound proxy (F1). The request ends up at Bob's inbound proxy, P2. Bob is currently not in the atlanta.com domain and has his forwarding rules set such that all requests are forwarded to an alternate domain, biloxi.com. P2 now retargets the request to Bob's forwarding address in the biloxi.com domain (F2). When the biloxi.com proxy gets the incoming request, the "domainname" component in the From SIP header will not match the domain URI stored in the certificate (which will "URI:sip:atlanta.com"). If the biloxi.com proxy has a strict policy to reject requests that do not match the administrative domain from which they have been proxied, the session setup will fail. Gurbani & Jeffrey Expires December 28, 2006 [Page 15] Internet-Draft Domain Certs June 2006 Appendix B. Retargetting and Identity P1 P2 P3 (example.com) (atlanta.com) (biloxi.com) | | | +--F1---------->| | | +--F2--------->| ... Figure 4: Retargetting with Identity F1: INVITE sips:bob@atlanta.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=... Via: SIP/2.0/TLS alice-pc.example.com;branch=... From: Alice ;tag=891jhh To: Bob Identity: "kj0P4..." Identity-Info: ;alg=rsa-sha1 ... F2: INVITE sips:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TLS proxy.atlanta.com;branch=... Via: SIP/2.0/TLS proxy.example.com;branch=... Via: SIP/2.0/TLS alice-pc.example.com;branch=... From: Alice ;tag=891jhh To: Bob Identity: "kj0P4..." Identity-Info: ;alg=rsa-sha1 ... Alice sends a request to Bob through her outbound proxy (F1). The request ends up at Bob's inbound proxy, P2. Bob is currently not in the atlanta.com domain and has his forwarding rules set such that all requests are forwarded to an alternate domain, biloxi.com. P2 now retargets the request to Bob's forwarding address in the biloxi.com domain (F2). When P3 gets the request from P2, the only attribute that P3 can absolutely depend on to mutually authenticate P2 is the topmost Via sent-by. This gives P3 some guarantee that P2 represents a host in the atlanta.com domain. P3 cannot depend on the domainname in the From header; that contains a completely different domain than atlanta.com. Neither can it depend on the Identity headers inserted Gurbani & Jeffrey Expires December 28, 2006 [Page 16] Internet-Draft Domain Certs June 2006 by the originating proxy. These correspond, of course, to the originating proxy and not to the proxy in the atlanta.com domain. Gurbani & Jeffrey Expires December 28, 2006 [Page 17] Internet-Draft Domain Certs June 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Gurbani & Jeffrey Expires December 28, 2006 [Page 18]