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 9, 2008.
Copyright © The IETF Trust (2007).
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, each intended for a different deployment scenario. Administrators can be select an implementation as appropriate for an overlay's security requirements.
3.1. Security Properties
3.2. Security Algorithms in RELOAD
3.3. Security Process
3.4. Options for Securing SIP Sessions
5. Peer Behavior
5.1. Sender Behavior
5.2. Processing Requests
5.3. Processing Responses
6. HMAC Security Algorithm
6.1. Validating Messages
7. CERTS Security Algorithm
7.1. Validating Messages
8. Security Considerations
8.1. Protecting the ID Namespace
8.2. Protecting the resource namespace
9. IANA Considerations
10.1. Normative References
10.2. Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
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 overlays 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] (Bryan, D., Zangrilli, M., and B. Lowekamp, “REsource LOcation And Discovery (RELOAD),” July 2007.). 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.
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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
Terminology defined in RFC 3261 (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261] is used without definition.
We use also the terminology and definitions from Concepts and Terminology for Peer to Peer SIP (Willis, D., “Concepts and Terminology for Peer to Peer SIP,” March 2007.) [I‑D.willis‑p2psip‑concepts] and REsource LOcation And Discovery (RELOAD) (Bryan, D., Zangrilli, M., and B. Lowekamp, “REsource LOcation And Discovery (RELOAD),” July 2007.) [I‑D.bryan‑p2psip‑reload] extensively in this document.
This section provides an informative overview of the RELOAD security algorithms.
P2P overlays are subject to attacks by subversive nodes that may attempt to disrupt routing, corrupt or remove user registrations, or eavesdrop on signalling. The security algorithms we describe in this draft are intended to protect DHT routing and user registration information in RELOAD messages.
To protect the signaling, the first requirement is to ensure that all messages are received from authorized members of the overlay. For this reason, RELOAD provides a SIGNATURE attribute that appears at the end of each message. This SIGNATURE can be used to authenticate the message origin as a legitimate member of the overlay.
Beyond that, however, the contents of the message must be authenticated. For information received from an individual peer, the end-of-message SIGNATURE ensures that the message was sent by another authorized peer. However, because a single peer may be compromised, trusting all content sent by that peer may be unadviseable. Therefore, RELOAD also applies SIGNATURE attributes to smaller internal data elements that describe other peers. For example, peer A may learn from peer B that there is a third peer C that would be a good fit for its routing table. peer A does not have to trust peer B that this peer C is trustworthy because the information peer B forwards to peer A about peer C actually has its own signature from peer C embedded in that component of the message. This is how RELOAD avoids the transitive trust problem: any information learned about a new peer is always learned from data signed by that new peer, not from a different peer.
RELOAD applies the same SIGNATURE approach to resource registrations. The message containing the resource registration is signed by the originating peer, but the contents of the registration itself is signed by the resource. This registration, with included SIGNATURE, is returned in response to resource queries and is migrated as the responsible peer changes. Again, the resource itself is authenticating its registration, not the responsible peer or other peers along the path the query takes.
This draft currently does not address message secrecy. Because the routing header is separate from the attributes in the message, a cryptographic encapsulation for the message attributes could easily be devised for messages whose destination is a specific peer, rather than a search for the responsible peer for a particular ID.
This draft presents a brief discussion and outlines possible solutions for securing SIP sessions between P2PSIP peers. Additional work on this issue and on securing sessions between a P2PSIP peer and a conventional SIP peer or a peer in another overlay is required.
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.
- Running without a security algorithm and 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.
- Shared secret security relies on a single key that is shared among 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.
- 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. CERTS SIGNATUREs contain a timestamp, optional certificate, and an RSA-SHA1 signature of the data being secured.
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] (Jennings, C., “Security Mechanisms for Peer to Peer SIP,” February 2007.).
DHT maintenance messages, including peer registrations, are authenticated 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 overlay 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.
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 CERTS security model are capable of securing the SIP sessions, and simple extensions to SIP can be implemented to achieve this within a P2PSIP overlay. In particular, the CERTS model allows a direct implementation of S/MIME authentication [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).
Most deployed security models for conventional SIP assume the existence of a trusted entity that actively participates by providing keys or signing messages; 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 (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” March 2007.) [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] (Lowekamp, B. and J. Deverick, “Authenticated Identity Extensions to dSIP,” March 2007.) also proposed extensions to [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) that could be used to secure SIP sessions, but supporting them outside the overlay would require conventional SIP UAs to implement those extensions.
This document defines three identifiers for the security algorithm:
NONE : 0x01 HMAC : 0x02 CERTS : 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.
Below is an example of a resource registration request message presented in ascii format. It registers a sip contact for email@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: firstname.lastname@example.org RESOURCE-INFO.BODY: RESOURCE-INFO.BODY.ENTRY: sip:email@example.com: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:firstname.lastname@example.org 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...
This draft applies to all messages sent between peers in a RELOAD overlay.
When using a security algorithm that requires SIGNATUREs (HMAC and CERTS 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 DIGEST. For the CERTS 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 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 inside 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.
For security algorithms requiring certificates, such as CERTS, the RESOURCE-INFO.BODY.CERTIFICATE is included as the sole entry in a RESOURCE-INFO.BODY. This RESOURCE-INFO.BODY must always be included in a message that includes one of the RESOURCE-INFO.BODY.SIGNATURE fields that uses that signature. In other words, whenever a RESOURCE attribute is included in a message, it will contain at least two RESOURCE-INFO.BODY members, one of which will contain the certificate for the resource. The certificate is included as a separate BODY to avoid unnecessary duplication. The BODY containing the certificate does not include a SIGNATURE because the certificate is already signed by the CA.
When using a security algorithm that requires SIGNATUREs, a peer MUST NOT perform any action in response to a Request that changes its state or 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.
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.
To secure a small-scale network, perhaps an office environment or other 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 (Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication,” February 1997.) [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.
Validating messages signed with a shared secret is simple because all messages are signed with the same shared secret. Therefore the 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.
The CERTS 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 CERTS 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] (Housley, R. and P. Hoffman, “Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP,” May 1999.).
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 CERTS 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. This information can be used by a receiving peer to prevent replay attacks.
Before validating a SIGNATURE, the peer must ensure that the accompanying certificate is signed by the certificate authority for the overlay. A request that is received without a required SIGNATURE or CERTIFICATE MUST be rejected with a 401 error code. A request received with an incorrect SIGNATURE MUST be rejected with a 431 error code.
The receiving peer MUST ensure that the SIGNATURE is the last attribute of the body except for any ROUTE-LOG attributes that were added by peers as the message was routed along the overlay. Any attributes other than ROUTE-LOG that follow the top-level SIGNATURE MUST be ignored.
No security scheme is stronger than the security with which it is administered. If the shared secret key for the HMAC security scheme is discovered by an attacker, then the security of the entire scheme is lost. Similarly, for the CERTS security scheme, if the CA is compromised and an attacker can generate arbitrary certificates, the scheme becomes insecure. Although it is fundamental to the security of both of these schemes, the provisioning of peers with either the shared secret key or with a private key and certificate is beyond the scope of this draft.
The whole-message SIGNATURE provides integrity and authentication for the message. It includes all fields of the header 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. ROUTE-LOG attributes MUST be appended to the end of the message because the intermediate peers cannot change any portion of the body of the message that would cause the SIGNATURE to be invalid. 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 CERTS algorithm allows a peer to identify new transactions by storing only a small amount of state for each peer.
When used properly, both schemes sufficiently inhibit attackers attempting to join the overlay. The CERTS 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.
The CERTS 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. While these peers cannot falsify responses to resource queries, they can respond with 404 error messages, effecting a DoS attack on the resource registration. They can also subvert routing to other compromised peers. To defend against such attacks, a resource search must still consist of parallel searches for replicated registrations.
The shared-secret scheme prohibits unauthorized peers from joining the overlay, but it provides no protection from a compromised peer inserting arbitrary resource registrations, performing a Sybil attack[Sybil] (Douceur, J., “The Sybil Attack,” March 2002.), or performing other attacks on the resources.
The CERTS 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 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 provide authentication for such registrations. Therefore parallel searches for redundant registrations mitigate most of the affects of a compromised peer. The ultimate reliability of such an overlay is a statistical question based on the replication factor and the percentage of compromised peers.
Once a resource is registered, the corresponding RESOURCE-INFO.BODY is used as a response to 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.
This document will require additions to IANA registries.
|[I-D.bryan-p2psip-reload]||Bryan, D., Zangrilli, M., and B. Lowekamp, “REsource LOcation And Discovery (RELOAD),” Internet Draft draft-bryan-p2psip-reload-01, July 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 (TXT, HTML, XML).|
|[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. 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.|
|[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.|
|Bruce B. Lowekamp|
|3000 Easter Circle|
|Williamsburg, VA 23188|
|Phone:||+1 757 565 0101|
|James W. Deverick|
|3000 Easter Circle|
|Williamsburg, VA 23188|
|Phone:||+1 757 565 0101|
Copyright © 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.
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 email@example.com.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).