SIP WG V. Gurbani, Ed. Internet-Draft A. Jeffrey Expires: October 6, 2006 Lucent Technologies, Inc./Bell Laboratories April 4, 2006 Domain Certificates in the Session Initiation Protocol (SIP) draft-gurbani-sip-domain-certs-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on October 6, 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 October 6, 2006 [Page 1] Internet-Draft Domain Certs April 2006 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 3 4. Peer Identity . . . . . . . . . . . . . . . . . . . . . . . 4 5. Registrars and Redirect Servers . . . . . . . . . . . . . . 5 6. Proxy Servers, Identities and SIP Headers . . . . . . . . . 6 7. Server Farms and Certificate Content . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . 10 10. Security Considerations . . . . . . . . . . . . . . . . . . 11 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 12.1 Normative References . . . . . . . . . . . . . . . . . . 12 12.2 Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 A. Retargetting in SIP . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Gurbani & Jeffrey Expires October 6, 2006 [Page 2] Internet-Draft Domain Certs April 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 October 6, 2006 [Page 3] Internet-Draft Domain Certs April 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. 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 [7], as well as satisfy the RFC 3261 concept on what should be contained in a site (or domain) certificate (Section 26.3.1 of RFC 3261, quoted above). In the sections below, we apply the concept of a certificate containing the two identities to typical scenarios in SIP to discuss its merits and discover any shortcomings. 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". 4. 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 Gurbani & Jeffrey Expires October 6, 2006 [Page 4] Internet-Draft Domain Certs April 2006 to populate the X.509v3 subjectAltName extension. However, this is under specified 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. A specific recommendation for TLS certificates should be that the certificate has the X.509v3 subjectAltName extension populated with a dNSName type that identifies the host (the "host URI"). Do we need to worry about certificates pre-dating RFC 3280 that had the name of the host in the Common Name field of Subject field? Some operators may have paid for these certificates for web servers and may now find themselves reusing the certificates for SIP servers (hopefully, not simultaneously!). Additionally, it should also be recommended that the X.509v3 subjectAltName extension for proxy servers, registrars, and redirect servers contain a "domain URI" that asserts the ownership of a domain to the holder of the certificate. 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. 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 Request-URI (R-URI) the client was trying to reach (in a REGISTER request, the R-URI typically names the location service for which the registration is meant, for example, "REGISTER sip:example.com"). Additionally, the client will have more confidence if the host URI in the certificate matches the canonical name of the server it had established a TLS connection to. Gurbani & Jeffrey Expires October 6, 2006 [Page 5] Internet-Draft Domain Certs April 2006 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 Request from Alice to Bob, through P1: INVITE sips:bob@biloxi.com SIP/2.0 Via: SIP/2.0/TLS proxy.example.com;branch=... Via: SIP/2.0/TLS alice-pc.example.com;branch=... To: SpongeBob Squarepants From: Alice ;tag=jki981-1 Identity: ... ... Gurbani & Jeffrey Expires October 6, 2006 [Page 6] Internet-Draft Domain Certs April 2006 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 To header field or the next hop URI -- which could be the R-URI or the topmost Route header -- and looks for a match. If they match, P1 can be certain that P2 has authority over the biloxi.com domain. Additionally, P1 matches the host URI in the certificate against the canonical name of the server that it had established a TLS connection to. If they match, P1 can be sure of the specific identity of the host it has established the TLS connection to. 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. P2 must ensure that the certificate is not expired and is rooted in a trusted hierarchy. Next, P2 examines the domainname in the From header and matches it to the domain URI stored in the certificate (c.f. Section 26.3.2.2 of RFC 3261). If they match, P2 can be certain that P1 has authority over the example.com domain. However, if they do not match, P2 cannot assume the converse; i.e., P2 cannot assume that P1 does not have authority over the example.com domain. Due to retargetting, the From header may not correspond to the administrative domain from which the request has been proxied (see Appendix A). Other techniques, such as examining the Via trail may be used. And finally, P2 should match the sent-by value of the topmost Via against the host URI stored in the certificate. A match will provide further confidence to P2 on the veracity of P1's certificate. It is open to discussion whether P2 should perform a reverse DNS lookup of the address it inserted in the "received" parameter of the topmost Via header and use the result to match against the host URI in the certificate (as opposed to blindly trusting the sent-by inserted by the sender). Possessing a certificate and the associated key does not mean that the certificate is meant for the host it is actually installed on. P2 could have more confidence if it performs reverse DNS to match the host name in the certificate (assuming that DNS itself has not been compromised). 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 Gurbani & Jeffrey Expires October 6, 2006 [Page 7] Internet-Draft Domain Certs April 2006 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 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. Gurbani & Jeffrey Expires October 6, 2006 [Page 8] Internet-Draft Domain Certs April 2006 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. 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. Gurbani & Jeffrey Expires October 6, 2006 [Page 9] Internet-Draft Domain Certs April 2006 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 To put in. 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. However, it may seem appropriate that wildcards should not be used in certificates. Even if they are used, it appears appropriate that each host possesses a unique certificate (i.e., unique serial number) as opposed to sharing a wildcard certificate among all hosts. In the latter case, the private key will need to be shared across all hosts and a compromise of the key at any one of the hosts would render the entire proxy farm to be Gurbani & Jeffrey Expires October 6, 2006 [Page 10] Internet-Draft Domain Certs April 2006 insecure. 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. 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 Gurbani & Jeffrey Expires October 6, 2006 [Page 11] Internet-Draft Domain Certs April 2006 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. 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 Gurbani & Jeffrey Expires October 6, 2006 [Page 12] Internet-Draft Domain Certs April 2006 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] 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. Authors' Addresses Vijay K. Gurbani (editor) 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 October 6, 2006 [Page 13] Internet-Draft Domain Certs April 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 October 6, 2006 [Page 14] Internet-Draft Domain Certs April 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 October 6, 2006 [Page 15]