aboutsummaryrefslogtreecommitdiffstats
path: root/doc/standards/draft-myers-ikev2-ocsp-03.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/standards/draft-myers-ikev2-ocsp-03.txt')
-rw-r--r--doc/standards/draft-myers-ikev2-ocsp-03.txt785
1 files changed, 785 insertions, 0 deletions
diff --git a/doc/standards/draft-myers-ikev2-ocsp-03.txt b/doc/standards/draft-myers-ikev2-ocsp-03.txt
new file mode 100644
index 000000000..fb59fc958
--- /dev/null
+++ b/doc/standards/draft-myers-ikev2-ocsp-03.txt
@@ -0,0 +1,785 @@
+
+
+
+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]
+
+
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-10 22:33:47 +0000