786 lines
21 KiB
Plaintext
786 lines
21 KiB
Plaintext
|
||
|
||
|
||
Network Working Group M. Myers
|
||
Internet-Draft TraceRoute Security LLC
|
||
Expires: January 12, 2007 H. Tschofenig
|
||
Siemens
|
||
July 11, 2006
|
||
|
||
|
||
OCSP Extensions to IKEv2
|
||
draft-myers-ikev2-ocsp-03.txt
|
||
|
||
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 12, 2007.
|
||
|
||
Copyright Notice
|
||
|
||
Copyright (C) The Internet Society (2006).
|
||
|
||
Abstract
|
||
|
||
While IKEv2 supports public key based authentication (PKI), the
|
||
corresponding use of in-band CRLs is problematic due to unbounded CRL
|
||
size. The size of an OCSP response is however well-bounded and
|
||
small. This document defines the "OCSP Content" extension to IKEv2.
|
||
A CERTREQ payload with "OCSP Content" identifies one or more trusted
|
||
OCSP responders and is a request for inclusion of an OCSP response in
|
||
the IKEv2 handshake. A cooperative recipient of such a request
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 1]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
responds with a CERT payload containing the appropriate OCSP
|
||
response. This content is recognizable via the same "OCSP Content"
|
||
identifier.
|
||
|
||
When certificates are used with IKEv2, the communicating peers need a
|
||
mechanism to determine the revocation status of the peer's
|
||
certificate. OCSP is one such mechanism. This document applies when
|
||
OCSP is desired and security policy prevents one of the IKEv2 peers
|
||
from accessing the relevant OCSP responder directly. Firewalls are
|
||
often deployed in a manner that prevents such access by IKEv2 peers
|
||
outside of an enterprise network.
|
||
|
||
|
||
Table of Contents
|
||
|
||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
|
||
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6
|
||
4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6
|
||
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8
|
||
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8
|
||
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9
|
||
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
|
||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
|
||
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
|
||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
Intellectual Property and Copyright Statements . . . . . . . . . . 14
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 2]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
1. Introduction
|
||
|
||
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
|
||
supports a range of authentication mechanisms, including the use of
|
||
public key based authentication. Confirmation of certificate
|
||
reliability is essential to achieve the security assurances public
|
||
key cryptography provides. One fundamental element of such
|
||
confirmation is reference to certificate revocation status (see
|
||
[RFC3280] for additional detail).
|
||
|
||
The historic means of determining certificate revocation status is
|
||
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
|
||
CRLs to be exchanged in-band via the CERT payload.
|
||
|
||
CRLs can however grow unbounded in size. Many real-world examples
|
||
exist to demonstrate the impracticality of including a multi-megabyte
|
||
file in an IKE exchange. This constraint is particularly acute in
|
||
bandwidth limited environments (e.g., mobile communications). The
|
||
net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
|
||
acquisition of these data, should they even be used at all.
|
||
|
||
Reliance on OOB methods can be further complicated if access to
|
||
revocation data requires use of IPsec (and therefore IKE) to
|
||
establish secure and authorized access to the CRLs of an IKE
|
||
participant. Such network access deadlock further contributes to a
|
||
reduced reliance on certificate revocation status in favor of blind
|
||
trust.
|
||
|
||
OCSP [RFC2560] offers a useful alternative. The size of an OCSP
|
||
response is bounded and small and therefore suitable for in-band
|
||
IKEv2 signaling of a certificate's revocation status.
|
||
|
||
This document defines an extension to IKEv2 that enables the use of
|
||
OCSP for in-band signaling of certificate revocation status. A new
|
||
content encoding is defined for use in the CERTREQ and CERT payloads.
|
||
A CERTREQ payload with "OCSP Content" identifies one or more trusted
|
||
OCSP responders and is a request for inclusion of an OCSP response in
|
||
the IKEv2 handshake. A cooperative recipient of such a request
|
||
responds with a CERT payload containing the appropriate OCSP
|
||
response. This content is recognizable via the same "OCSP Content"
|
||
identifier.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 3]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
2. Terminology
|
||
|
||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
|
||
document are to be interpreted as described in RFC 2119 [RFC2119].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 4]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
3. Extension Definition
|
||
|
||
With reference to Section 3.6 of [IKEv2], the values for the Cert
|
||
Encoding field of the CERT payload are extended as follows (see also
|
||
the IANA Considerations section of this document):
|
||
|
||
Certificate Encoding Value
|
||
-------------------- -----
|
||
OCSP Content 14
|
||
|
||
3.1. OCSP Request
|
||
|
||
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
|
||
Payload indicates the presence of one or more OCSP Responder
|
||
certificate hashes in the Certificate Authority field of the CERTREQ
|
||
payload.
|
||
|
||
The presence of OCSP Content (14) in a CERTREQ message:
|
||
|
||
1. identifies one or more OCSP responders trusted by the sender;
|
||
|
||
2. notifies the recipient of sender's support for the OCSP extension
|
||
to IKEv2; and
|
||
|
||
3. notifies the recipient of sender's desire to receive OCSP
|
||
confirmation in a subsequent CERT payload.
|
||
|
||
3.2. OCSP Response
|
||
|
||
A value of OCSP Content (14) in the Cert Encoding field of a CERT
|
||
Payload indicates the presence of an OCSP Response in the Certificate
|
||
Data field of the CERT payload.
|
||
|
||
Correlation between an OCSP Response CERT payload and a corresponding
|
||
CERT payload carrying a certificate can be achieved by matching the
|
||
OCSP response CertID field to the certificate. See [RFC2560] for the
|
||
definition of OCSP response content.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 5]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
4. Extension Requirements
|
||
|
||
4.1. OCSP Request
|
||
|
||
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
|
||
hashes as the Certification Authority value of a single CERTREQ
|
||
message. There is no means however to indicate which among those
|
||
hashes relates to the certificate of a trusted OCSP responder.
|
||
|
||
Therefore an OCSP Request as defined in Section 3.1 above SHALL be
|
||
transmitted separate from any other CERTREQ payloads in an IKEv2
|
||
exchange.
|
||
|
||
Where it is useful to identify more than one trusted OCSP responder,
|
||
each such identification SHALL be concatenated in a manner identical
|
||
to the method documented in Section 3.7 of [IKEv2] regarding the
|
||
assembly of multiple trust anchor hashes.
|
||
|
||
The Certification Authority value in an OCSP Request CERTREQ SHALL be
|
||
computed and produced in a manner identical to that of trust anchor
|
||
hashes as documented in Section 3.7 of [IKEv2].
|
||
|
||
Upon receipt of an OCSP Response CERT payload corresponding to a
|
||
prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the
|
||
OCSP response into path validation logic defined by [RFC3280].
|
||
|
||
The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if
|
||
either:
|
||
|
||
1. the corresponding OCSP Response CERT payload indicates that the
|
||
subject certificate is revoked; OR
|
||
|
||
2. the corresponding OCSP Response CERT payload indicates an OCSP
|
||
error (e.g., malformedRequest, internalError, tryLater,
|
||
sigRequired, unauthorized, etc.).
|
||
|
||
The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange
|
||
if a corresponding OCSP Response CERT payload is not received. This
|
||
might be an indication that this OCSP extension is not supported.
|
||
|
||
4.2. OCSP Response
|
||
|
||
Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD
|
||
acquire the related OCSP-based assertion and produce and transmit an
|
||
OCSP Response CERT payload corresponding to the certificate needed to
|
||
verify its signature on IKEv2 payloads.
|
||
|
||
An OCSP Response CERT payload SHALL be transmitted separate from any
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 6]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
other CERT payload in an IKEv2 exchange.
|
||
|
||
The means by which an OCSP response may be acquired for production of
|
||
an OCSP Response CERT payload is out of scope of this document.
|
||
|
||
The structure and encoding of the Certificate Data field of an OCSP
|
||
Response CERT payload SHALL be identical to that defined in
|
||
[RFC2560].
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 7]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
5. Examples and Discussion
|
||
|
||
This section shows the standard IKEv2 message examples with both
|
||
peers, the initiator and the responder, using public key based
|
||
authentication, CERTREQ and CERT payloads. The first instance
|
||
corresponds to Section 1.2 of [IKEv2], the illustrations of which are
|
||
reproduced below for reference.
|
||
|
||
5.1. Peer to Peer
|
||
|
||
Application of the IKEv2 extensions defined in this document to the
|
||
peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
|
||
follows. Messages are numbered for ease of reference.
|
||
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
(1) HDR, SAi1, KEi, Ni -->
|
||
|
||
(2) <-- HDR, SAr1, KEr, Nr,
|
||
CERTREQ(OCSP Request)
|
||
(3) HDR, SK {IDi, CERT(certificate),-->
|
||
CERT(OCSP Response),
|
||
CERTREQ(OCSP Request),
|
||
[IDr,] AUTH, SAi2, TSi, TSr}
|
||
|
||
(4) <-- HDR, SK {IDr,
|
||
CERT(certificate),
|
||
CERT(OCSP Response),
|
||
AUTH, SAr2, TSi, TSr}
|
||
|
||
In (2) Responder sends an OCSP Request CERTREQ payload identifying
|
||
one or more OCSP responders trusted by Responder. In response,
|
||
Initiator sends in (3) both a CERT payload carrying its certificate
|
||
and an OCSP Response CERT payload covering that certificate. In (3)
|
||
Initiator also requests an OCSP response via the OCSP Request CERTREQ
|
||
payload. In (4) Responder returns its certificate and a separate
|
||
OCSP Response CERT payload covering that certificate.
|
||
|
||
It is important to note that in this scenario, the Responder in (2)
|
||
does not yet possess the Initiator's certificate and therefore cannot
|
||
form an OCSP request. [RFC2560] allows for pre-produced responses.
|
||
It is thus easily inferred that OCSP responses can be produced in the
|
||
absence of a corresponding request (OCSP nonces notwithstanding). In
|
||
such instances OCSP Requests are simply index values into these data.
|
||
|
||
It is also important in extending IKEv2 towards OCSP in this scenario
|
||
that the Initiator has certain knowledge that the Responder is
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 8]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
capable of and willing to participate in the extension. Yet the
|
||
Responder will only trust one or more OCSP responder signatures.
|
||
These factors motivate the definition of OCSP Responder Hash
|
||
extension.
|
||
|
||
5.2. Extended Authentication Protocol (EAP)
|
||
|
||
Another scenario of pressing interest is the use of EAP to
|
||
accommodate multiple end users seeking enterprise access to an IPsec
|
||
gateway. As with the preceding section, the following illustration
|
||
is extracted from [IKEv2]. In the event of a conflict between this
|
||
document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
|
||
dominate.
|
||
|
||
|
||
Initiator Responder
|
||
----------- -----------
|
||
(1) HDR, SAi1, KEi, Ni -->
|
||
(2) <-- HDR, SAr1, KEr, Nr
|
||
(3) HDR, SK {IDi, -->
|
||
CERTREQ(OCSP Request),
|
||
[IDr,] AUTH, SAi2, TSi, TSr}
|
||
(4) <-- HDR, SK {IDr,
|
||
CERT(certificate),
|
||
CERT(OCSP Response),
|
||
AUTH, EAP}
|
||
(5) HDR, SK {EAP} -->
|
||
|
||
(6) <-- HDR, SK {EAP (success)}
|
||
|
||
(7) HDR, SK {AUTH} -->
|
||
|
||
(8) <-- HDR, SK {AUTH, SAr2, TSi,
|
||
TSr }
|
||
|
||
In the EAP scenario, messages (5) through (8) are not relevant to
|
||
this document. Note that while [IKEv2] allows for the optional
|
||
inclusion of a CERTREQ in (2), this document asserts no need of its
|
||
use. It is assumed that environments including this optional payload
|
||
and yet wishing to implement the OCSP extension to IKEv2 are
|
||
sufficiently robust as to accommodate this redundant payload.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 9]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
6. Security Considerations
|
||
|
||
For the reasons noted above, OCSP request as defined in Section 3.1
|
||
is used in place of OCSP request syntax to trigger production and
|
||
transmission of an OCSP response. OCSP as defined in [RFC2560] may
|
||
contain a nonce request extension to improve security against replay
|
||
attacks (see Section 4.4.1 of [RFC2560] for further details). The
|
||
OCSP Request defined by this document cannot accommodate nonces.
|
||
[RFC2560] deals with this aspect by allowing pre-produced responses.
|
||
|
||
[RFC2560] points to this replay vulnerability and indicates: "The use
|
||
of precomputed responses allows replay attacks in which an old (good)
|
||
response is replayed prior to its expiration date but after the
|
||
certificate has been revoked. Deployments of OCSP should carefully
|
||
evaluate the benefit of precomputed responses against the probability
|
||
of a replay attack and the costs associated with its successful
|
||
execution." Nodes SHOULD make the required freshness of an OCSP
|
||
Response configurable.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 10]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
7. IANA Considerations
|
||
|
||
This document defines one new field type for use in the IKEv2 Cert
|
||
Encoding field of the Certificate Payload format. Official
|
||
assignment of the "OCSP Content" extension to the Cert Encoding table
|
||
of Section 3.6 of [IKEv2] needs to be acquired from IANA.
|
||
|
||
Certificate Encoding Value
|
||
-------------------- -----
|
||
OCSP Content 14
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 11]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
8. Acknowledgements
|
||
|
||
The authors would like to thank Russ Housley for his support.
|
||
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
|
||
Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
|
||
review.
|
||
|
||
9. Normative References
|
||
|
||
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
|
||
RFC 4306, December 2005.
|
||
|
||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||
|
||
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
|
||
Adams, "X.509 Internet Public Key Infrastructure Online
|
||
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
|
||
|
||
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
|
||
X.509 Public Key Infrastructure Certificate and
|
||
Certificate Revocation List (CRL) Profile", RFC 3280,
|
||
April 2002.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 12]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
Authors' Addresses
|
||
|
||
Michael Myers
|
||
TraceRoute Security LLC
|
||
|
||
|
||
Email: mmyers@fastq.com
|
||
|
||
|
||
Hannes Tschofenig
|
||
Siemens
|
||
Otto-Hahn-Ring 6
|
||
Munich, Bavaria 81739
|
||
Germany
|
||
|
||
Email: Hannes.Tschofenig@siemens.com
|
||
URI: http://www.tschofenig.com
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 13]
|
||
|
||
Internet-Draft OCSP Extensions to IKEv2 July 2006
|
||
|
||
|
||
Intellectual Property Statement
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
|
||
Disclaimer of Validity
|
||
|
||
This document and the information contained herein are provided on an
|
||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
|
||
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
||
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
|
||
Copyright Statement
|
||
|
||
Copyright (C) The Internet Society (2006). This document is subject
|
||
to the rights, licenses and restrictions contained in BCP 78, and
|
||
except as set forth therein, the authors retain all their rights.
|
||
|
||
|
||
Acknowledgment
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
Myers & Tschofenig Expires January 12, 2007 [Page 14]
|
||
|
||
|