SIP WG V. Gurbani Internet-Draft Bell Laboratories, Alcatel-Lucent Updates: 3261 (if approved) S. Lawrence Intended status: Best Current Pingtel Corp. Practice A. Jeffrey Expires: September 6, 2007 Bell Laboratories, Alcatel-Lucent March 5, 2007 Domain Certificates in the Session Initiation Protocol (SIP) draft-gurbani-sip-domain-certs-04 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 September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document attempts to clarify the use of domain certificates in the Session Initiation Protocol (SIP). Gurbani, et al. Expires September 6, 2007 [Page 1]
Internet-Draft Domain Certs March 2007 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Abstract Syntax Notation . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. SIP Domain To Host Resolution . . . . . . . . . . . . . . . . 4 4.1. Identifying a specific host . . . . . . . . . . . . . . . 5 4.2. Mutual Interdomain Authentication . . . . . . . . . . . . 6 5. Conveying Identity in Certificates . . . . . . . . . . . . . . 6 6. Restricting Usage To SIP . . . . . . . . . . . . . . . . . . . 8 6.1. Extended Key Usage Values for SIP Domains . . . . . . . . 8 7. UAC Considerations . . . . . . . . . . . . . . . . . . . . . . 9 8. UAS Considerations . . . . . . . . . . . . . . . . . . . . . . 9 9. Proxy Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Guidelines for CA . . . . . . . . . . . . . . . . . . . . . . 9 11. Virtual SIP Servers and Certificate Content . . . . . . . . . 10 12. Wildcards in dNSName Type . . . . . . . . . . . . . . . . . . 10 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 15.2. Informative References . . . . . . . . . . . . . . . . . . 12 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Gurbani, et al. Expires September 6, 2007 [Page 2]
Internet-Draft Domain Certs March 2007 1. Terminology 1.1. Key Words 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]. 1.2. Abstract Syntax Notation All X.509 certificate X.509 [5] extensions are defined using ASN.1 X.680 [6],X.690 [7]. 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 clarity 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 TLS uses X.509 Public Key Infrastructure [4] to bind an identity, or a set of identities, to the holder of a X.509 v3 certificate. Accordingly, the recommendations of the SIP working group have been to populate the X.509v3 subjectAltName extension with an identity. 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 Uniform Resource Identifier (URI). RFC 3261 does not provide any guidelines on the identity (or identities) to be populated in subjectAltName for TLS certificates. This leads to problems when Gurbani, et al. Expires September 6, 2007 [Page 3]
Internet-Draft Domain Certs March 2007 attempting to interpret the certificate contents in a uniform manner. The use of TLS in SIP should address two concerns: first, it should identify a SIP resource in the form of a domain over which the certificate is asserting its authority; and second, it should provide a guarantee at the transport layer that the peer with whom a TLS connection is being established is indeed who they purport to be. The latter deals with identifying hosts at the transport layer for a secure TLS connection, and the former identifies a SIP domain for the application using the TLS connection to perform any authorization, should such a need arise. The two concerns enumerated above correspond to two specific problem areas that are currently visible in SIP's use of X.509 certificates. First, the contents of certificates must be such that it allows for mutual inter-domain authentication; and second, there must be means available to allow an upstream SIP host to deterministically "pin" a route through one proxy from a farm of downstream proxies. The rest of the document is organized as follows: Section 4 further explores the areas of concern identified above. Section 5 proposes the use of two identitied in an X.509 certificate to solve the concerns identified above. Section 6 defines a mechanism to allow a host to to assert its authority over a SIP domain. Section 7 and Section 8 contain considerations for user agent clients (UACs) and user agent servers (UAS), respectively, and Section 9 discusses the effect on proxies. Section 10 outlines the guidelines for a certificate authority (CA) when it issues certificates for SIP use. Section 11, Section 12 and Section 13 discusses aspects related to contents of certificates for virtual SIP servers, the presence of wildcards in domain certificates, and security considerations, respectively. 4. SIP Domain To Host Resolution Routing in SIP is performed by executing RFC3263 procedures on a URI. There are two cases to consider; we first take the simplest of cases: a request is to be routed based on a generic URI (sips:alice@example.com.) Through a series of untrusted Domain Name Service (DNS) manipulations, a connection is established to a server that presents a certificate with an identity of "sip:example.com". Here, since the host portion of the URI (example.com) matches the identity stored in the certificate, the connection is deemed to be authenticated (to be sure, other checks must be done on the received certificate, for example, ensuring that the certificated is rooted in a trusted hierarchy, and ensuring that the certificate is in its validity period). Gurbani, et al. Expires September 6, 2007 [Page 4]
Internet-Draft Domain Certs March 2007 This is the way HTTPS operates, and SIPS simply borrows this behavior from HTTP. 4.1. Identifying a specific host A more complicated case in SIP occurs when the URI that is used to route a request does not correspond to the identity in the presented certificate. For instance, what is the expected behavior if the URI used for routing is "sips:downtown.example.com" and the certificate presented contains an identity of "sip:example.com"? Here, "downtown" could be a specific host in the "example.com" domain, or it could be a subordinate domain. Note that a domain name in an X.509 certificates should be interpreted only as a sequence of octets that should match the URI used to reach the host. No inference should be made based on the DNS name hierarchy. In such cases, the general recommendation has been that the host that is contacted using a specific URI should present a certificate that contains exactly that same URI. In terms of SIP, this generally implies that a proxy that wants to remain on the path of subsequent signaling must insert into the Record-Route header an URI that it is guaranteed to possess credentials for. If the proxy wanted to insert a fully qualified domain name (FQDN) in the Record-Route header, it should have a certificate that states this credential, otherwise, it should insert a domain URI into the Record-Route header (i.e., "sips: example.com" instead of "sips:downtown.example.com"). A potential problem in inserting a domain URI is that RFC 3263 [8] resolution on that URI may result in a different proxy than the one that originally inserted the URI. While this is not a concern when choosing any proxy from a server farm, it is a problem when the choice of a proxy needs to be deterministic (the "pinning" problem.) One way to combat this is to arrange for the proxy to possess two certificates -- one corresponding to the identity "sip:example.com" and the other corresponding to the identity "sip: downtown.example.com" -- and have it present the right one when contacted. While technically this is feasible through the use of TLS extensions [10], administratively it requires the proxy vendor to acquire two distinct certificates. In this document, we propose the use of one certificate with two identities as described above to solve the "pinning" problem as well as the mutual inter-domain authentication problem. Gurbani, et al. Expires September 6, 2007 [Page 5]
Internet-Draft Domain Certs March 2007 4.2. Mutual Interdomain Authentication [2] section 26.3.2.2 "Interdomain Requests" discusses the requirement that when a TLS connection is created between two proxies, those proxies should each validate the certificate presented by the other during the TLS handshake. For example, suppose that alice@example.com creates an INVITE for bob@example.net; her user agent routes the request to some proxy in her domain, example.com. Suppose, now, that example.com is a large organization that maintains several SIP proxies, and normal resolution rules cause her INVITE to be sent to an outbound proxy proxyA.example.com, which then uses RFC 3263 [8] resolution and finds that proxyB.example.net is a valid proxy for example.net using TLS. proxyA.example.com requests a TLS connection to proxyB.example.net, and each presents a certificate to authenticate that connection. The authentication problem for proxyA is straightforward - if we assume secure DNS, then proxyA already knows that proxyB is a valid proxy for the SIP domain example.net, so it only needs a valid certificate from proxyB that contains the fully qualified host name proxyB.example.net, or a SIP URI that asserts proxy B's authority over example.net domain, i.e., a certificate that asserts the identity "sip:example.net". The problem for proxyB is different, however; it is presented with a connection from a specific host, but what it needs to determine is whether or not that connection can be treated as coming from a particular SIP domain. If it receives a certificate that contains only the name proxyA.example.com, then it cannot determine that proxyA is authorized to act as a SIP outbound proxy for example.com, because example.com may use different systems for inbound messages so SIP DNS resolution of example.com may not lead to proxyA.example.com (if this is the case, proxyB should not reuse this connection if it needs to send a request to example.com). The certificate usage in SIP should not require that every outbound proxy for a domain must also be an inbound proxy for that domain, but should provide for certificate based binding of the SIP domain name to a particular connection. 5. Conveying Identity in Certificates As a possible answer to the problem of conveying identities, we propose that TLS certificates contain two identities in subjectAltName X.509v3 extensions. The first identity is a SIP URI for the domain. This URI asserts that the system is authoritative for the SIP domain that it names (e.g., "sip:example.com"). The Gurbani, et al. Expires September 6, 2007 [Page 6]
Internet-Draft Domain Certs March 2007 second identity is a domain name system label, more specifically, the canonical name of the host (e.g., "sip:downtown.example.com"); this second name asserts that the system is authoritative for the name used for the transport address. Including both identities solves the problem identified in Section 5.1 of [11], as well as satisfying the RFC 3261 concept of what should be contained in a site (or domain) certificate (Section 26.3.1 of RFC 3261, quoted below). Proxy servers, redirect servers and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. 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:sips:example.com", and "DNS:downtown.example.com". The latter DNS label provides assurance at the transport layer that the the certificate corresponds to a host that was the target of the TLS connection, while the former SIPS URI binds the holder of the certificate with a domain URI for which it is authoritatively responsible. This information may be subsequently used by the application to make authorization decisions of the form outlined in Section 26.3.2.2 of RFC3261. Currently, there isn't a strong consensus in the WG around the issue of maintaining two identities in a certificate, even though it appears to solve the "pinning" problem described above. The main barrier to the lack of consensus are financial and administrative. While technically this solution is attractive because it binds a certificate to an identity at the transport and application layers, it does imply that a service provider will need to obtain multiple certificates from a CA. This may be cost- prohibitive, and furthermore there is an administrative cost to the service provider as it ensures that the certificate is bound to the appropriate host. There are two other proposals for "pinning" a deterministic proxy from a proxy farm. 1. The use of "maddr" parameter has been proposed to carry the FQDN of the proxy; i.e., "Record-Route: <sips: example.com;maddr=proxy1.example.com;lr>". The advantages are backwards compatiblity, reduces the need to obtain multiple certificates (each corresponding to a FQDN of a host). 2. The outbound-discovery [13] draft provides an alternative way for proxies to construct the URI that they use in the Record-Route header such that the domain parts of these URIs always match Gurbani, et al. Expires September 6, 2007 [Page 7]
Internet-Draft Domain Certs March 2007 their TLS certificates. The advantage of this scheme is that it works across NATs, but the disadvantage is its complexity. 6. Restricting Usage To SIP The intent of this draft is to define certificate usage for binding a SIP domain name to a connection. A SIP domain name is frequently (perhaps even usually) textually identical to the same DNS name used for other purposes. For example, the DNS name example.com may serve as a SIP domain name, an email domain name, and web service name. Since these different services within a single organization may well be administered independently and hosted separately, it should be possible to create a certificate that binds the DNS name to its usage as a SIP domain name without creating the implication that the usage is also valid for some other purpose. RFC 3280 [4] section 4.2.1.13 defines a mechanism for this purpose: an "Extended Key Usage" attribute. Certificates to be used as described by this document MAY include an id-kp-SIPdomain attribute to indicate that the name bindings are restricted to usage in SIP. 6.1. Extended Key Usage Values for SIP Domains RFC 3280 [4] specifies the extended key usage X.509 certificate extension. The extension indicates one or more purposes for which the certified public key may be used. The extended key usage extension can be used in conjunction with key usage extension, which indicates the intended purpose of the certified public key. The extended key usage extension syntax is repeated here for convenience: ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId KeyPurposeId ::= OBJECT IDENTIFIER This specification defines the KeyPurposeId id-kp-sipDomain. Inclusion of this KeyPurposeId in a certificate indicates usage of any DNS names in the certificate is restricted to SIP. Whether or not to include this restriction is up to the certificate issuer, but if it is included, it MUST be marked as critical so that implementations that do not understand it will not accept the certificate for any other purpose. id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } Gurbani, et al. Expires September 6, 2007 [Page 8]
Internet-Draft Domain Certs March 2007 id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp VALUE-TBD } 7. UAC Considerations When a UAC receives a certificate from a server, it MUST ensure that the certificate asserts one of the two identities that the UAC used to reach the server: If the UAC performed RFC3263 resolution on the URI to reach the server, the SIP or SIPS identity stored in the certificate MUST be matched. Otherwise, if RFC3263 resolution on the URI failed, the UAC MUST match the DNS label in the certificate with the name of the server that it opened a TLS connection to. 8. UAS Considerations When a UAS accepts a TLS connection, it presents its X.509 certificate to the client. A UAS may optionally ask the upstream client for a certificate. If the client is in possession of one, it will be presented to the UAS for mutual authentication. If the UAS has a policy to only accept TLS connections from trusted peers, it MAY inspect the domain in the SIP URI of the certificate. If the domain is one that is allowed by such a policy, the TLS connection can be considered to be authenticated. The specifics of creating such a policy and of providing it to the UAS are outside the scope of standardization and are not discussed in this document. 9. Proxy Considerations A proxy acts as a UAS for requests arriving to it, and as a UAC when it proxies request downstream. As a UAS, it MUST follow the behavior of Section 8; and as a UAC, it MUST follow the behavior specified in Section 7. 10. Guidelines for CA When issuing a certificate with two identities as described in this recommendation, a certificate authority should validate the authority for both usages; that the party to whom the certificate is authoritative for both names. Note that the two names may not have any relationship at all in the DNS. For example, if a service provider (example.net) is hosting SIP services for a customer (example.com), then each proxy in the Gurbani, et al. Expires September 6, 2007 [Page 9]
Internet-Draft Domain Certs March 2007 example.net farm may need to be able to present certificates with the SIP identity URI:sip:example.com and the transport layer identity DNS:proxy1.example.net. 11. Virtual SIP Servers and Certificate Content The closest guidance in SIP today regarding certificates and virtual SIP servers occurs in SIP Identity ([12], 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 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 [10] 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? 12. Wildcards in dNSName Type RFC 2818 (HTTP over TLS) [9] 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. Gurbani, et al. Expires September 6, 2007 [Page 10]
Internet-Draft Domain Certs March 2007 13. 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. We expect that appropriate processing requirements of domain certificates will provide the following security guarantees at the application level: Confidentiality: SIPS messages from alice@example.com to bob@example.edu can only be read by alice@example.com, bob@example.edu, and SIP proxies issued with domain certificates for example.com or example.edu. Integrity: SIPS messages from alice@example.com to bob@example.edu can only be modified by alice@example.com, bob@example.edu, and SIP proxies issued with domain certificates for example.com or example.edu. Authenticity: alice@example.com and proxy.example.com are mutually authenticated, and moreover proxy.example.com is authenticated to alice@example.com as an authoritative proxy for domain example.com. Similar mutual authentication guarantees are given between proxy.example.com and proxy.example.edu and between proxy.example.edu and bob@example.edu. As a result, alice@example.com is transitively mutually authenticated to bob@example.edu (assuming trust in the authoritative proxies for example.com and example.edu). 14. Acknowledgments The following IETF contributors provided substantive input to this document: Jeroen van Bemmel, Michael Hammer, Cullen Jennings, Paul Kyzivat, Derek MacDonald, Dave Oran, Jon Peterson, Eric Rescorla, Jonathan Rosenberg, and Russ Housley. 15. References Gurbani, et al. Expires September 6, 2007 [Page 11]
Internet-Draft Domain Certs March 2007 15.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, April 2002. [5] International International Telephone and Telegraph Consultative Committee, "Information Technology - Open Systems Interconnection - The Directory: Authentication Framework", CCITT Recommendation X.509, November 1988. [6] International International Telephone and Telegraph Consultative Committee, "Specification of Abstract Syntax Notation One (ASN.1): Specification of Basic Notation", CCITT Recommendation X.680, July 1994. [7] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 1994. 15.2. Informative References [8] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Location SIP Servers", RFC 3263, June 2002. [9] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [10] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [11] 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. [12] Peterson, J. and C. Jennings, "Enhancements for Authenticated Gurbani, et al. Expires September 6, 2007 [Page 12]
Internet-Draft Domain Certs March 2007 Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-06.txt (work in progress), October 2005. [13] Rosenberg, J., "Discovering Outbound Proxies and Providing High Availability with Client Initiated Connections in the Session Initiation Protocol (SIP)", draft-rosenberg-sip-outbound-discovery-mid-dialog-00.txt (work in progress), October 2006. Appendix A. ASN.1 Module SIPDomainCertExtn { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-sip-domain-extns2007(VALUE-TBD) } DEFINITIONS IMPLICIT TAGS ::= BEGIN -- OID Arcs id-pe OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 1 } id-kp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 3 } id-aca OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) 10 } -- Extended Key Usage Values id-kp-sipDomain OBJECT IDENTIFIER ::= { id-kp VALUE-TBD } END Gurbani, et al. Expires September 6, 2007 [Page 13]
Internet-Draft Domain Certs March 2007 Authors' Addresses Vijay K. Gurbani Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-546 Lisle, IL 60532 USA Phone: +1 630 224-0216 Email: vkg at bell hyphen labs dot com Scott Lawrence Pingtel Corp. 400 West Cummings Park Suite 2200 Woburn, MA 01801 USA Phone: +1 781 938 5306 Email: slawrence@pingtel.com Alan S.A. Jeffrey Bell Laboratories, Alcatel-Lucent 2701 Lucent Lane Room 9F-534 Lisle, IL 60532 USA Email: ajeffrey at bell hyphen labs dot com Gurbani, et al. Expires September 6, 2007 [Page 14]
Internet-Draft Domain Certs March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Gurbani, et al. Expires September 6, 2007 [Page 15]