P2PSIP B. Lowekamp Internet-Draft J. Deverick Intended status: Standards Track SIPeerior Expires: January 2, 2008 July 1, 2007 Security Extensions for RELOAD draft-lowekamp-p2psip-reload-security-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 January 2, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract P2PSIP deployments require the ability to authenticate both peers and resources (users) without the active presence of a trusted entity in the system. We describe how to use signature attributes in RELOAD messages to ensure authentication and integrity for communications between peers and to authenticate resource registrations. We describe a shared-secret implementation and a public-key implementation that can be selected as appropriate for an overlay's security requirements. Lowekamp & Deverick Expires January 2, 2008 [Page 1] Internet-Draft RELOAD Security July 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Security Algorithms in RELOAD . . . . . . . . . . . . . . 4 3.2. Security Process . . . . . . . . . . . . . . . . . . . . . 5 3.3. Options for Securing SIP Sessions . . . . . . . . . . . . 6 4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Peer Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 8 5.2. Processing Requests . . . . . . . . . . . . . . . . . . . 8 5.3. Processing Responses . . . . . . . . . . . . . . . . . . . 9 6. HMAC Security Algorithm . . . . . . . . . . . . . . . . . . . 9 6.1. Validating Messages . . . . . . . . . . . . . . . . . . . 9 7. RSA Security Algorithm . . . . . . . . . . . . . . . . . . . . 10 7.1. Validating Messages . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8.1. Protecting the ID Namespace . . . . . . . . . . . . . . . 11 8.2. Protecting the resource namespace . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Lowekamp & Deverick Expires January 2, 2008 [Page 2] Internet-Draft RELOAD Security July 2007 1. Introduction RELOAD provides peer-to-peer registration and resource location that can be used for P2PSIP applications. A secure P2PSIP network requires protection from a variety of security threats. Joining peers should only be admitted into an overlay if they are authorized members of that overlay. Resources (users) should be authenticated before communication begins. The overlay's links and the data registered on the peers should be protected from attackers. Without such security measures in place, attackers can generate false identities and become peers in the system, where they can interfere with message routing and maintenance of the overlay structure. They can also masquerade as other, valid users or resources in the overlay, possibly generating false responses to resource requests. The goal of RELOAD is to scale gracefully from ad hoc groups of a few people to an overlay of millions of peers across the globe. As such, there is no one security model that fits the needs of all envisioned environments: for the small network establishing a certificate chain is difficult, while for a global network the unrestricted ability to insert resources and devise useful Peer IDs is a clear invitation to insecurity. To address this issue, the RELOAD security extensions offer two different security models. The first is based on a shared secret key and is applicable to small environments where deployment of more complicated schemes is impractical. The second is a public key certificate system applicable to larger deployments in which the administrative costs of public key management is preferable to the scalability issues of shared secret keys. One of these models should be selected according to the needs of the overlay and the anticipated deployment scenario. Both approaches provide an implementation of the SIGNATURE attribute as defined in RELOAD[I-D.bryan-p2psip-reload]. The essential concept is that the SIGNATURE attribute encapsulates both a timestamp to prevent replay and a cryptographic signature over the data to which it applies. The public key signature also includes the principal making the signature. Additional security algorithms may be supported by RELOAD. Each scheme requires an algorithm identifier for the header and must define the attributes used by that security algorithm. A portion of the attribute identifier space is reserved for security algorithms. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Lowekamp & Deverick Expires January 2, 2008 [Page 3] Internet-Draft RELOAD Security July 2007 document are to be interpreted as described in RFC 2119 [RFC2119]. Terminology defined in RFC 3261 [RFC3261] is used without definition. We use also the terminology and definitions from Concepts and Terminology for Peer to Peer SIP [I-D.willis-p2psip-concepts] and REsource LOcation And Discovery (RELOAD) [I-D.bryan-p2psip-reload] extensively in this document. 3. Overview The RELOAD SIGNATURE attribute serves two purposes. The first is to ensure message integrity and to authenticate the messages themselves. Because a P2PSIP peer can modify its internal state, and thus the topology of the overlay, based on the messages it receives from other peers, all messages that are received must be authenticated to ensure they are from an authorized member of the overlay. The second purpose is to authenticate resource registrations. P2P resources are stored on and supplied in responses by the responsible peer(s). One vulnerability in such systems is that the responsible peer is able to provide forged responses for its resources if it wishes to attack the network. By including a SIGNATURE attribute in a resource registration that is included along with the resource registration in query responses, the resource itself is authenticating the validity of the registration. The only remaining avenue for attack is a denial-of-service attack by returning 404 in response to a query. 3.1. Security Algorithms in RELOAD We described three security algorithms for RELOAD. The algorithm used is identified by the SECURITY octet in the RELOAD header. Additional security algorithms can be defined and indicated with new SECURITY octet identifiers. NONE Running without a security algorithm no SIGNATURE attribute. It is a totally unsecured protocol. OPEN ISSUE: It would be trivial to support a SIGNATURE attribute that merely uses self- signed certificates for security, possibly relying on another external mechanism to validate them, or minimally allow the self- signed certificates to be used to assert repeatable identity. HMAC Shared secret security relies on a single key that is shared between all members of the overlay. It is appropriate for small groups that wish to form a private network without complexity. HMAC SIGNATUREs contain a timestamp and an HMAC-SHA1 signature of the data being secured. Lowekamp & Deverick Expires January 2, 2008 [Page 4] Internet-Draft RELOAD Security July 2007 RSA Public key security relies on a public-key system with a CA that is responsible for issuing certificates to all peers and resources in the overlay prior to their joining. Because each peer posesses the CA's certificate, they can verify the certificates of the other entities in the overlay without further communication. RSA SIGNATUREs contain a timestamp, optional certificate, and an RSA- SHA1 signature of the data being secured. 3.2. Security Process Generally speaking, there are two processes that are secured by this approach: DHT maintenance and resource registration. The signatories for DHT maintenance are peers in the system. For resource registrations, the resources themselves provide signatures. This distinction is unimportant in the shared secret model, where the same key is used to create all SIGNATUREs. In the public key system, however, peers and resources may be issued different key-certificate pairs. It is also possible for a resource to be bound to one or more peers, containing the peer IDs as subjectAltNames in its certificate. In such a case, the same key may be used to sign, and corresponding certificate used to validate, both peer and resource communication, though conceptually they are distinct. Jennings discusses other possible ways of assigning certificates and PeerIDs[I-D.jennings-p2psip-security]. DHT maintenance, including peer registrations, authenticate messages by verifying that the SIGNATURE attribute at the end of the message was generated with the overlay key, in the case of the shared-secret model. In the public-key certificate model, receiving nodes verify that the signature was generated using the key associated with the source peer ID as assigned by the certificate authority for the overlay. The certificate is carried in the SOURCE-INFO attribute of the message. Resource registrations are authenticated by the RESOURCE- INFO.BODY.SIGNATURE included in each RESOURCE-INFO.BODY. Once a resource is registered in the overlay, its signed registration is included as a resource ticket in all responses to queries for that resource. This resource ticket prevents subversive peers from forging registrations directly, and limits them to attacks on the routing or a simple DoS by not providing any registration information to queries. This is particularly important as peers join and leave the overlay; the resulting changes in the structure of the DHT commonly result in resource migration among peers. Requiring that the original, signed registration be included in responses inhibits rogue peers' abilities to claim that they host resources not legitimately migrated to them. Lowekamp & Deverick Expires January 2, 2008 [Page 5] Internet-Draft RELOAD Security July 2007 3.3. Options for Securing SIP Sessions This document describes securing the signalling in RELOAD. However, it does not directly secure the SIP sessions themselves. The certificates used and distributed by the RSA security model are capable of securing the SIP sessions, and simple extensions to SIP can be implemented to achieve this within a P2PSIP overlay. However, most SIP security models for conventional SIP assume the existence of a trusted entity that actively participates by providing keys or signing messages, and to support secure communication from a P2PSIP peer to a conventional SIP peer, one of these techniques must be used. Many of these models can be used directly if a P2PSIP overlay has a designated peer responsible for communication with conventional SIP UAs. For example, sip-certs authentication [I-D.ietf-sip-certs] can be used directly if an overlay is provisioned with a credential server. However, requiring centralized servers is not desireable for P2PSIP. [I-D.lowekamp-p2psip-dsip-security] also proposed extensions to [RFC4474] that could be used to secure SIP sessions, but supporting them outside the overlay would require conventional SIP UAs to implement those extensions. 4. Syntax This document defines three identifiers for the security algorithm: NONE : 0x01 HMAC : 0x02 RSA : 0x03 Several new attributes are defined. Technically each of the previous security algorithms can define its own set of attributes in the attribute space reserved for security algorithms. However, we will use the same set of attributes for each algorithm for convenience. A SIGNATURE type (used for SIGNATURE, PEER-SIGNATURE, and RESOURCE- INFO.BODY.SIGNATURE) can contain the following attributes: TIMESTAMP : 0x0801 DIGEST : 0x0802 where TIMESTAMP is a 32-bit encoding of seconds since the epoch and DIGEST is an HMAC-SHA1 or RSA-SHA1 digest byte stream as appropriate. TIMESTAMP is not used in HMAC. PEER-CERTIFICATE and RESOURCE-CERTIFICATE contain only the X.509 certificate as its value. Lowekamp & Deverick Expires January 2, 2008 [Page 6] Internet-Draft RELOAD Security July 2007 4.1. Example Below is an example of a resource registration request message presented in ascii format. It registers a sip contact for alice@example.com, an email address to forward, and supplies the certificate for both the resource registration and the source-info. Version: 0x01 Method: 0x11 DHT: 0x0 Security: 0x03 Hash: 0x0 Source ID: 463ac413c4 Destination ID: a6c5927a45 -------Attributes------- SOURCE-INFO: PEER-ID: 463ac413c4 PEER-IP-PORT: 10.4.1.2:5060 PEER-CERT: 23d634... PEER-EXPIRATION: 300 RESOURCE: RESOURCE-INFO.KEY: alice@example.com RESOURCE-INFO.BODY: RESOURCE-INFO.BODY.ENTRY: sip:alice@10.4.1.2:5060 RESOURCE-INFO.BODY.EXPIRATION: 300 RESOURCE-INFO.BODY.PEER-INFO: PEER-ID: 463AC413C4 RESOURCE-INFO.BODY.SIGNATURE: TIMESTAMP: 946702799 DIGEST: 3037e... RESOURCE-INFO.BODY RESOURCE-INFO.BODY.ENTRY: mailto:alice@example.com RESOURCE-INFO.BODY.EXPIRATION: 24000 RESOURCE-INFO.BODY.PARAMETER: RESOURCE-INFO.BODY.PARAMETER.KEY: type RESOURCE-INFO.BODY.PARAMETER.OP: 0x1 RESOURCE-INFO.BODY.PARAMETER.VALUE: voicemail RESOURCE-INFO.BODY.SIGNATURE: TIMESTAMP: 946702799 DIGEST: 5f271b1... RESOURCE-INFO.BODY RESOURCE-INFO.BODY.CERTIFICATE: 23d634... 5. Peer Behavior This draft applies to all messages sent between peers in a RELOAD overlay. Lowekamp & Deverick Expires January 2, 2008 [Page 7] Internet-Draft RELOAD Security July 2007 5.1. Sender Behavior When using a security algorithm that requires SIGNATUREs (HMAC and RSA in this draft), a sender MUST include a SIGNATURE as the last attribute of the message. The SIGNATURE applies to all data in the message from the 8th byte in the header (indicating the protocol version, etc) to the final byte preceding the DIGEST in the SIGNATURE. The DIGEST MUST be the last attribute in the SIGNATURE and all other attributes of the SIGNATURE MUST be generated prior to calculating the DIGTEST. For the RSA security algorithm, or other certificate-based algorithm, the sender MUST include a PEER-CERT attribute in the SOURCE-INFO. If the DHT algorithm in use requires or allows peers to forward portions of their routing table in their messages, the sender MUST provide a SIGNATURE as the last attribute in the SOURCE-INFO attribute. As a component of SOURCE-INFO, this SIGNATURE applies only to the data in the SOURCE-INFO. Signing the SOURCE-INFO separately allows other peers to trust the routing table entries they receive from their neighbors because that SOURCE-INFO will be included as part of the routing table entry. OPEN ISSUE: Optionally the PEER-CERT could be left out of the message if it is being sent to a peer that has previously received (and cached) the certificate. However, this then requires an error- response that indicates the certificate must be included. We have gone with simplicity to simply require the certificate always be included. A sender must also include a SIGNATURE as the final attribute in each RESOURCE-INFO.BODY attribute included in their message. In the case of a RESOURCE-PUT, the peer is responsible for generating the SIGNATURE. In other operations, such as the response to a RESOURCE- GET or in a RESOURCE-TRANSFER, the original RESOURCE-INFO.BODY first received MUST be transferred as originally sent, including its SIGNATURE. The RESOURCE-INFO.BODY.CERTIFICATE is included as the sole entry in a RESOURCE-INFO.BODY. It must always be included in a message that includes one of the RESOURCE-INFO.BODY.SIGNATURE fields that uses that signature. It is included as a separate BODY to avoid unnecessary duplication. It does not include a SIGNATURE of its own because the certificate is already signed by the CA. 5.2. Processing Requests When using a security algorithm that requires SIGNATUREs, a peer MUST NOT perform any action in response to a Request that changes state or Lowekamp & Deverick Expires January 2, 2008 [Page 8] Internet-Draft RELOAD Security July 2007 returns information stored in the overlay without validating the SIGNATURE at the end of the request message. A peer MAY proxy or redirect a request without validation, and it may return error codes indicating an error in the request, without validating the request, however it MUST NOT process a DHT maintenance request or resource registration that it is responsible for in any way, including generating a 404, until it has completed validation of the message's SIGNATURE. A peer MUST NOT generate a response that contains any RESOURCE- INFO.BODY that it has not previously verified the SIGNATURE for and verified that the signing entity matches the RESOURCE-INFO.KEY to which the RESOURCE-INFO.BODY belongs. All responses to requests, whether successful or an error response, MUST contain a SIGNATURE generated by the responding peer. 5.3. Processing Responses When using a security algorithm that requires SIGNATUREs, a peer MUST NOT perform any action based on a response without validating the SIGNATURE of the response message. This includes reacting to an error code that may be generated without validating the corresponding request. After validating the response message to a resource query, the requesting peer MUST validate the SIGNATURE in each RESOURCE- INFO.BODY and confirm that the signing entity matches the RESOURCE- INFO.KEY before storing any information about that resource or passing knowledge of the response to the application. 6. HMAC Security Algorithm To secure a small-scale network, perhaps an office environment or small group of people who wish to communicate together, a shared secret will suffice. Rather than relying on a domain certificate, therefore, the DIGEST field consists of an HMAC-SHA1 [RFC2104] hash of the data being signed. The DIGEST is encoded as a raw byte array rather than in base64 encoding. Because shared secrets are shared between all peers in the overlay, there is no need to fetch one, therefore no PEER-CERT is required. 6.1. Validating Messages Validating messages signed with a shared secret is simple because all messages are signed with the same shared secret. Therefore the Lowekamp & Deverick Expires January 2, 2008 [Page 9] Internet-Draft RELOAD Security July 2007 message can be validated without fetching any external information. A request that is received without a signature MUST be rejected with a 401 error code. A request with an incorrect SIGNATURE MUST be rejected with a 431 error code. 7. RSA Security Algorithm The RSA security algorithm requires the existence of a CA responsible for the overlay. Typically each user registering for the overlay will receive a certificate for their identity within the overlay (AoR) and a small number of PeerIDs as subjectAltNames to identity peers they intend to use (allowing for multiple PeerIDs for multiple UAs the user may wish to have on the overlay simultaneously). The CA SHOULD issue such PeerIDs consecutively to prevent a single user from controlling multiple portions of the overlay. Other than consecutive PeerIDs assigned to the same user, PeerIDs SHOULD be assigned uniformly across the namespace. For the RSA security scheme, the DIGEST field consists of an RSA-SHA1 hash of the data being signed in raw byte-stream encoding. The PEER- CERT attribute consists of a DER encoded X.509v3 certificate[RFC2585]. Each peer must be provisioned with the CA's certificate as well as its own private key and certificate, signed by the CA. When using the RSA security algorithm, each peer SHOULD be provisioned with a reliable method for time synchronization. Each peer MUST calculate its Transaction IDs by dividing the TransactionID into two 32-bit quantities. The first is the boot-time of the peer in seconds since the epoch. The second is a counter that starts at zero and is incremented for each new request that is sent. 7.1. Validating Messages Before validating the DIGEST on the message, the peer must confirm that the certificate included in the message is signed by the CA. Separately, when validating signatures on resources, the peer must confirm that the certificate included in the 8. Security Considerations No security scheme is stronger than the security with which it is administered. If the shared-secret passphrase for the HMAC security scheme is discovered by an attacker, then the security of the entire Lowekamp & Deverick Expires January 2, 2008 [Page 10] Internet-Draft RELOAD Security July 2007 scheme is lost. Similarly, for the RSA security scheme, if the CA is compromised and an attacker can generate arbitrary certificates, the security of the scheme is compromised. Although it is fundamental to the security of both of these schemes, the provisioning of peers with either the shared secret passphrase or with a private key and certificate is beyond the scope of this draft. The RSA security scheme secures the namespace, but if an individual peer is compromised or if an attacker obtains a certificate from the CA, then a number of subversive peers can still appear in the overlay, compromising (not returning) registrations they are responsible for and possibly subverting routing to other compromised peers. To defend against such compromised peers, a resource search must still consist of parallel searches for replicated registrations. The ultimate reliability of such an overlay is a statistical question based on the replication factor and the percentage of compromised peers. The whole-message SIGNATURE provides integrity and authentication for the message. It includes all fields of the head not modified per-hop and all attributes originally included in the message. (ROUTE-LOG attributes are added by on-path peers and follow the SIGNATURE in the message.) To prevent replay attacks, the SIGNATURE covers the TransactionID and includes a timestamp. The timestamp is useful only if all peers have synchronized clocks. To further prevent replay attacks, the definition of TransactionID in the RSA algorithm allows a peer to identify new transactions by storing only a small amount of state for each peer. 8.1. Protecting the ID Namespace When used properly, both schemes sufficiently inhibit attackers attempting to join the overlay. The RSA scheme, in particular, further protects the ID namespace by reducing the impact of compromising a single authorized peer of the overlay, whereas an attacker compromising a single peer in the shared-secret scheme can obtain the shared secret and thus compromise the entire namespace. 8.2. Protecting the resource namespace The shared-secret scheme protects the overlay from unauthorized peers joining the overlay, but it provides no protection from a compromised peer inserting arbitrary resource registrations, performing a Sybil attack[Sybil], or performing other attacks on the resources. The RSA scheme prevents an attacker compromising a single peer from being able to forge the registration for more than that peer's resources. Furthermore, although a subversive peer can refuse to Lowekamp & Deverick Expires January 2, 2008 [Page 11] Internet-Draft RELOAD Security July 2007 return registration entries for resources for which it is responsible or in response to requests routed through it (404 Not Found responses), it cannot return forged registrations because it cannot authenticate such registrations. Therefore parallel searches for redundant registrations mitigate most of the affects of a compromised peer. Once a resource is registered, the corresponding Resource Ticket is used in queries for that resource, migrated between peers, and generally considered public knowledge. As it is inherently intended to be replayed, the value selected in the Expires header of the original registration must be chosen carefully to ensure that responses to future queries do not direct the querier to a location over which the resource no longer has control. 9. IANA Considerations This document will require additions to IANA registries. 10. References 10.1. Normative References [I-D.bryan-p2psip-reload] Bryan, D., Zangrilli, M., and B. Lowekamp, "REsource LOcation And Discovery (RELOAD)", Internet Draft draft-bryan-p2psip-reload-00, June 2007. [I-D.ietf-sip-certs] Jennings, C., "Certificate Management Service for The Session Initiation Protocol (SIP)", draft-ietf-sip-certs-03 (work in progress), March 2007. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Lowekamp & Deverick Expires January 2, 2008 [Page 12] Internet-Draft RELOAD Security July 2007 Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. 10.2. Informative References [I-D.jennings-p2psip-security] Jennings, C., "Security Mechanisms for Peer to Peer SIP", draft-jennings-p2psip-security-00 (work in progress), February 2007. [I-D.lowekamp-p2psip-dsip-security] Lowekamp, B. and J. Deverick, "Authenticated Identity Extensions to dSIP", Internet Draft draft-lowekamp-p2psip-dsip-security-00, March 2007. [I-D.willis-p2psip-concepts] Willis, D., "Concepts and Terminology for Peer to Peer SIP", draft-willis-p2psip-concepts-04 (work in progress), March 2007. [Sybil] Douceur, J., "The Sybil Attack", March 2002. Authors' Addresses Bruce B. Lowekamp SIPeerior 3000 Easter Circle Williamsburg, VA 23188 USA Phone: +1 757 565 0101 Email: lowekamp@sipeerior.com James W. Deverick SIPeerior 3000 Easter Circle Williamsburg, VA 23188 USA Phone: +1 757 565 0101 Email: jdeverick@sipeerior.com Lowekamp & Deverick Expires January 2, 2008 [Page 13] Internet-Draft RELOAD Security July 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). Lowekamp & Deverick Expires January 2, 2008 [Page 14]