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 August 29, 2007.
Copyright © The IETF Trust (2007).
This document describes mechanisms to authenticate peer and resource identities within a distributed SIP overlay. It makes use of existing identity frameworks, modifying them as necessary to accommodate the specific needs of a peer-to-peer environment.
3.1. Security Models
3.2. Security Process
3.3. Example Message Flow
4. Peer Behavior
4.1. Changes to RFC4474
4.2. Resource Tickets
4.3. Sender Behavior
4.4. Processing Requests
4.5. Processing Responses
5. Shared Secret
5.1. Validating Messages
6.1. Selecting the Authenticating Identity for Messages
6.2. Validating Messages
6.3. Fetching Certificates
7. Security Considerations
7.1. Protecting the ID Namespace
7.2. Protecting the resource namespace
8. IANA Considerations
10.1. Normative References
10.2. Informative References
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
The distributed Session Initiation Protocol (dSIP) extends traditional SIP by providing peer-to-peer registration and resource location. While most security mechanisms for dSIP derive naturally from its client-server counterpart, certain considerations must be made for the peer-to-peer extensions provided by the protocol. Joining peers should only be admitted into an overlay if they are authorized members of that overlay. Resources should be authenticated to ensure genuine communication among them.
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 dSIP 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 dSIP 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 make use of the Identity digest-string header presented in RFC 4474. In that specification, this digest over certain header fields and the message body is signed by an authentication service for the domain in which the communication is occurring. Because the concept of a specific, server-based, central authentication service role is antithetical to the dSIP paradigm, this approach modifies how the Identity header is signed when messages are being constructed. Details on the changes as applicable to each security model are presented in Section 3.1 (Security Models)
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,” October 2006.) [I‑D.willis‑p2psip‑concepts] and dSIP: A P2P Approach to SIP Registration and Resource Location (Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” February 2007.) [I‑D.bryan‑p2psip‑dsip] extensively in this document.
Instead of violating the distributed nature of dSIP by implementing the RFC 4474 authentication service as central server, the dSIP Security Extensions require communication endpoints to sign and validate correspondence directly. The method by which this is done varies depending on the security model being used. In both models, the Identity digest-string is generated without modification as described in P2P Identity, but the protocol by which the digest is signed (and by extension the verification protocol) changes. Additionally, we modify the contents of the Identity-Info header as necessary to provide message recipients required information to validate incoming messages. For both security models, the details of key and certificate provisioning are beyond the scope of this document, and we assume that they are provided by some out of band mechanism.
The shared secret signature process is straightforward. After the identity digest-string is generated, the endpoint encrypts it with the shared secret key for the overlay, and populates the Identity header with the encrypted value. It also injects a string identifying the algorithm used to generate the Identity value in the Identity-Info header. The recipient of the message can then generate the same digest-string, and encrypt it with the same shared key and algorithm, comparing the result to the value presented in the Identity header of the message. If the value generated by the recipient does not match the value contained in the Identity header, the message should be considered unauthorized and rejected.
In the public key certificate model, each endpoint has a different private key and a corresponding public key certificate issued by a certificate authority for the overlay. When an endpoint prepares an outbound message, it generates the identity digest-string and signs it with its unique private key. In addition, it fills the Identity-Info header with the sip URI of the certificate that the recipient needs to verify the identity signature. When the recipient receives the message, it may have a preloaded or cached copy of the necessary certificate. If not, it can subscribe to the URI indicated in the Identity-Info header using the SIP event notification extensions defined in sip-certs (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” October 2006.) [I‑D.ietf‑sip‑certs] to fetch the needed certificate. When the certificate arrives, the recipient must first verify that it is signed by the CA for the overlay. Once the validity of the certificate is confirmed, the recipient can use the certificate to verify the signed digest-string in the Identity header of the original message and accept or reject the message appropriately. The fetched certificate may, as a matter of local policy, be cached for future verifications.
Generally speaking, there are two processes that are secured by this approach: DHT maintenance and resource registrations and migrations. 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 Identity headers. In the public key certificate system, however, it is possible for peers and resources to 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 in general they are distinct.
DHT maintenance, including peer registrations, authenticate messages by verifying that the Identity header 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 header was generated using the key associated with the specified peer ID as assigned by the certificate authority for the overlay.
Resource registrations are identical to peer registrations in the shared-secret model. In the certificate-based model, however, the verification process uses the certificate for the resource indicated in the From header, rather than the peer ID.
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.
To illustrate the message flow generated by the security extensions, consider a resource registration and query. Because it is the most complex scenario, assume that the public key certificate model is used, and that no certificates have been preloaded or cached by peers in the system.
Peer 0 Peer 1 Peer 2 | | | |(1) REGISTER | | |------------------>| | | resource r | | | | | |(2) SUBSCRIBE | | |<------------------| | | cert for r | | | | | |(3) NOTIFY | | |------------------>| | | cert for r | | | | | |(4) 200 | | |<------------------| | | | | | |(5) REGISTER | | |<------------------| | | query r from s | | | | | |(6) SUBSCRIBE | | |------------------>| | | cert for s | | | | | |(7) NOTIFY | | |<------------------| | | cert for s | | | | | |(8) 200 | | |------------------>| | | response r | | | | |(9) SUBSCRIBE | | |<--------------------------------------| | cert for r | | | | | |(10) NOTIFY | | |-------------------------------------->| | cert for r | |
In (1), resource r is registered at peer 1. Since peer 1 does not have a copy of r's certificate to verify the Identity header for r's registration, it subscribes to the URI indicated by the Identity-Info header of the REGISTER message. In this case, that header contains the URI of peer 0. Peer 0, on receipt of the certificate subscription request (2), issues a notification response (3) containing r's certificate. At this point, peer 1 validates that the certificate is signed by the overlay's certificate authority, then uses the certificate to verify the Identity field in the original registration for resource r. Because the signature is valid, peer 1 issues a 200 OK (4) to peer 0, indicating that r has been registered successfully.
Later, resource s wishes to query resource r. After locating r as described in dSIP and omitted from this diagram, s queries peer 1 (5) for resource r. The REGISTER message used for this query contains a signed digest-string that peer 1 must validate. Because peer 1 does not have a copy of s's certificate, it subscribes to peer 2 (6), the URI provided by resource s in the Identity-Info header. Resource s at peer 2 responds with its certificate (7), allowing peer 1 to verify the resource request. Once the verification is complete, peer 1 responds (8) to the resource query. Included in the response to s's query is a copy of r's original registration at peer 1. In order to trust that the response is valid, s must verify that the copy of r's registration actually originated from r and has not yet expired. It does so by subscribing (9) to peer 0 as indicated in by the Identity-Info header of the encapsulated registration. Peer 0 responds with a copy of r's certificate (10), which s uses to verify that the response it received from its query for resource r ultimately originated from r's valid registration.
Note that the responses in steps (4) or (8) could also be 401 Unauthorized if the certificates received by the corresponding notifications could not verify the requests in (1) and (5), respectively. In the first case, this would result in a failed registration for resource r. In the second, the query for r from resource s would be refused. Finally, if the certificate retrieved in (10) fails to verify the encapsulated copy of r's registration received in (8), then s should treat the response as unauthorized and discard it.
This draft applies to all messages sent between peers in a dSIP overlay. Such messages are identifiable by the presence of the token 'dht' in the message's Require header. The provisions provided by this document are not applicable to messages that do not satisfy this prerequisite. If the overlay requires dSIP-identity security to be used, then all messages sent that perform any dht or resource maintenance or queries (any message with a Require: p2p) MUST include the appropriate Identity and Identity-Info headers. Messages received that do not contain an Identity header MUST be rejected with a 428 Use Identity Header response code. Extensions defined in this document MUST NOT appear in any message that does not include a "dht" token in the Require header.
Because we interpret the Identity and Identity-Info headers from RFC 4474 differently, we have to prevent implementations of conventional RFC 4474 from being adversely affected. By requiring that this specification only apply to messages with the Require dht header, standard RFC 4474 implementations should not see the modified messages. Whether or not this is satisfactory to address the concern remains an open question.
dSIP-identity is an extension of RFC 4474 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474]. Unless this draft specifies otherwise, all behavior described in RFC 4474 is followed in generating the dSIP-identity headers. In particular, digest-string is determined in the same manner. The two major exceptions are:
- Response Authentication:
- Unlike RFC 4474, responses MUST include an Identity header used to validate the response. Although the sender does not always know which peer will ultimately respond to a request, it can assert that the response it receives originated from an authorized member of the overlay.
- Fetching Certificates:
- For certificate-based security, RFC 4474 specifies that implementations MUST support HTTP and HTTPS URIs in the Identity-Info header. All peers compliant with this specification MUST support HTTP and HTTPS URIs for retrieving certificates from peers providing such a server. In addition, all peers compliant with this specification MUST support the "certificate" SIP Event Package from sip-certs (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” October 2006.) [I‑D.ietf‑sip‑certs] both as subscriber and notifier. A peer MUST NOT provide an HTTP or HTTPS URI for its Identity-Info unless it knows that no NAT traversal techniques will be required to contact that server (i.e. it knows its server has an unfirewalled port at an address that is directly routable by all peers in the overlay). Because this is difficult to know in advance, peers SHOULD rely on the Event Package technique.
A peer receiving a resource registration for which it is responsible stores the registration itself and additionally MUST store the digest-string, Identity, and Identity-Info from the actual request message used to send the registration. This information stored from the request message will be known as a resource ticket. The resource ticket MUST be returned in the body of any 200 OK response the responsible peer returns in response to a query for the resource it is responsible for. The ticket allows the querying entity to validate that the actual resource performed the indicated registration.
When sending a message, the sender implements the authentication service described in RFC 4474 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474].
A peer MUST NOT perform any action that changes state or returns information stored in the overlay without validating the Identity signature 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, such as 413, 414, 420, etc 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.
An important exception to the above rule is that in certificate-based security schemes, a peer MUST NOT validate a SUBSCRIBE request for the peer's certificate if it requires fetching the certificate of the peer submitting the request. This exception avoids deadlock fetching certificates.
A peer MUST NOT perform any action based on a response without validating the Identity signature of the response message. This includes reacting to an error code such as 420 response that may be generated without validating the corresponding request.
After validating the response message to a resource query, if the result code is a 200 OK, the peer MUST confirm that the response contains a resource ticket. The peer MUST then separately validate the resource ticket. Because resource tickets are longer-lived than standard messages, the peer SHOULD allow a longer validity period with respect to the Date header of the message, although not in excess of the Expires value of the resource ticket.
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 Identity 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 digest-string.
Because shared secrets are shared between all peers in the overlay, there is no need to fetch one, therefore Identity-Info stores only the name of the algorithm used to sign the message. This requires a change in the syntax of the Identity-Info header to allow the ident-info parameter to be omitted:
Identity-Info = "Identity-Info" HCOLON ident-uri-info / ( ident-info-params *( SEMI ident-info-params ) ) ident-uri-info = ident-info *( SEMI ident-info-params )
where ident-uri-info is the definition of Identity-Info from RFC 4474 and ident-info-params is used as the only element of Identity-Info only when used for a security mechanism such as shared secret where no certificates must be identified or retrieved.
Messages using shared secrets must contain an "alg" parameter. This specification defines the value "hmac-sha1" for the "alg" parameter. Messages MUST additionally contain the token "dSIP" as an ident-info-extension to indicate the type of processing required to validate the message. Therefore, the Identity-Info header will be
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. When validating a message, the receiver MUST verify that the Identity header presents the correct 'hmac-sha1' hash obtained by hashing the message's digest-string using the overlay's shared secret as the key. Any message that provides incorrect Identity information MUST be rejected with a 438 Invalid Identity Header response code.
Certificate-based implementations of dSIP-identity require 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.
Each peer must be provisioned with the CA's certificate as well as its own private key and certificate, signed by the CA.
For peers providing their certificates to other peers through the "certificate" SIP Event Package [I‑D.ietf‑sip‑certs] (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” October 2006.), ident-info in Identity-Info typically will be the P2P URI of the peer. Peers hosting resources with separate certificates MUST use different URIs for each certificate, but each URI MUST contain the peerID of the peer hosting that resource so that SUBSCRIBE messages can be routed to the correct peer.
Messages sent using certificate-based dSIP-identity MUST include the tokens 'alg=rsa-sha1' and 'dSIP' in the Identity-Info Header. This is in addition to the URI from which the sender's certificate can be retrieved.
All request messages MUST be signed with the identity specified in the From header. For DHT maintenance (peer registration and queries), this will also be the same as the PeerID header, i.e. the identity of the peer originating the request. For resource registrations and queries, this will be the identity of the resource performing the operation. In the typical case, a UA will have a single certificate that is used for both the user's identity and peer ID, so these may be the same certificate.
All response messages MUST be signed with the identity specified in the PeerID header, which identifies the peer generating the response and authenticates the response as having been generated by an authorized peer. The requesting peer might also validate that the responding peer has an appropriate PeerID to be responsible for that portion of the namespace, but such validation is outside the scope of this draft and may have negative implications for resource caching or other optimizations.
Note that a resource migration, which is a third party registration used to move resources as the peers responsible for those resource IDs change due to joining or exiting peers, is signed using the key of the admitting or exiting peer and uses that peer's URI as it's From address. The resource ticket MUST be included in the body of that request.
To validate a message, a peer first checks its certificate cache to see whether it has a certificate corresponding to the authenticating identity used to sign the message. If it does not, it MUST fetch the certificate using the URI in Identity-Info and defer further processing of the message until validation can be completed. A peer MUST NOT validate a "certificate" SIP Event Package SUBSCRIBE request for the peer's certificate if it does not already possess the certificate of the subscribing peer. It MUST respond to such requests without verification.
The peer MUST use the certificate corresponding to the authenticating identity appropriate for the type of message, as described above in Section 6.1 (Selecting the Authenticating Identity for Messages). The peer MUST NOT use Identity-Info to determine which certificate to use. If a certificate retrieved from the URI specified in Identity-Info does not match the appropriate authenticating identity or is not signed by the certificate authority for the overlay, the peer MUST reject that message with a 438 Invalid Identity Header response code.
After confirming that it has the correct certificate, the peer follows the procedures specified in RFC 4474 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474] to verify the signature.
A peer uses the "certificate" SIP Event Package[I‑D.ietf‑sip‑certs] (Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” October 2006.) to fetch certificates. Because CA-signed certificates are long-lived, the peer SHOULD issue the SUBSCRIBE with Expires header of 0 to specify only a single NOTIFY response is desired.
After receiving the NOTIFY response, the peer MUST verify that the certificate received is signed by the overlay's CA. Certificates that are not signed by the overlay's CA MUST immediately be discarded and any message validations waiting for the certificates to be fetched MUST immediately be rejected with a 437 Unsupported Certificate response code.
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 scheme is lost. Similarly, for the dSIP-identity 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 an private key and certificate is beyond the scope of this draft.
The dSIP-identity 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.
Because this protocol relies on digest-string from RFC 4474 (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) [RFC4474], it provides the same message integrity, authentication, and defense against replay attacks offered by that specification. It also shares the same weaknesses, described in Section 13 of RFC 4474. In particular, because Identity and Identity-Info headers can be replaced by an attacker, it is up to the recipient to ensure that the certificate used to sign this message matches the claimed sender of the message and that the certificate is signed by the proper CA for the particular overlay.
When used properly, both schemes sufficiently inhibit attackers attempting to join the overlay. The dSIP-identity 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 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] (Douceur, J., “The Sybil Attack,” March 2002.), or performing other attacks on the resources.
The dSIP-identity 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 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.
This document defines the "dSIP" token as an ident-info-extension to the Identity-Info header.
A team of people have worked on the various drafts related to the dSIP protocol and extensions thereof. The team consists of: David Bryan, Eric Cooper, James Deverick, Cullen Jennings, Bruce Lowekamp, Philip Matthews, and Marcia Zangrilli.
Thanks to all who have been actively participating in the P2PSIP efforts. Special thanks to Spencer Dawkins, Enrico Marocco, and Jean-Francois Wauthy for providing editorial feedback, and Henry Sinnreich, Eric Rescorla, and Alan Johnston for various discussions related to this work.
|[I-D.bryan-p2psip-dsip]||Bryan, D., Lowekamp, B., and C. Jennings, “dSIP: A P2P Approach to SIP Registration and Resource Location,” Internet Draft draft-bryan-p2psip-dsip-00, February 2007.|
|[I-D.ietf-sip-certs]||Jennings, C., “Certificate Management Service for The Session Initiation Protocol (SIP),” draft-ietf-sip-certs-02 (work in progress), October 2006.|
|[I-D.willis-p2psip-concepts]||Willis, D., “Concepts and Terminology for Peer to Peer SIP,” draft-willis-p2psip-concepts-03 (work in progress), October 2006.|
|[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).|
|[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.|
|[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 firstname.lastname@example.org.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).