4 Network Working Group M. Myers
5 Internet-Draft TraceRoute Security LLC
6 Expires: January 12, 2007 H. Tschofenig
11 OCSP Extensions to IKEv2
12 draft-myers-ikev2-ocsp-03.txt
16 By submitting this Internet-Draft, each author represents that any
17 applicable patent or other IPR claims of which he or she is aware
18 have been or will be disclosed, and any of which he or she becomes
19 aware will be disclosed, in accordance with Section 6 of BCP 79.
21 Internet-Drafts are working documents of the Internet Engineering
22 Task Force (IETF), its areas, and its working groups. Note that
23 other groups may also distribute working documents as Internet-
26 Internet-Drafts are draft documents valid for a maximum of six months
27 and may be updated, replaced, or obsoleted by other documents at any
28 time. It is inappropriate to use Internet-Drafts as reference
29 material or to cite them other than as "work in progress."
31 The list of current Internet-Drafts can be accessed at
32 http://www.ietf.org/ietf/1id-abstracts.txt.
34 The list of Internet-Draft Shadow Directories can be accessed at
35 http://www.ietf.org/shadow.html.
37 This Internet-Draft will expire on January 12, 2007.
41 Copyright (C) The Internet Society (2006).
45 While IKEv2 supports public key based authentication (PKI), the
46 corresponding use of in-band CRLs is problematic due to unbounded CRL
47 size. The size of an OCSP response is however well-bounded and
48 small. This document defines the "OCSP Content" extension to IKEv2.
49 A CERTREQ payload with "OCSP Content" identifies one or more trusted
50 OCSP responders and is a request for inclusion of an OCSP response in
51 the IKEv2 handshake. A cooperative recipient of such a request
55 Myers & Tschofenig Expires January 12, 2007 [Page 1]
57 Internet-Draft OCSP Extensions to IKEv2 July 2006
60 responds with a CERT payload containing the appropriate OCSP
61 response. This content is recognizable via the same "OCSP Content"
64 When certificates are used with IKEv2, the communicating peers need a
65 mechanism to determine the revocation status of the peer's
66 certificate. OCSP is one such mechanism. This document applies when
67 OCSP is desired and security policy prevents one of the IKEv2 peers
68 from accessing the relevant OCSP responder directly. Firewalls are
69 often deployed in a manner that prevents such access by IKEv2 peers
70 outside of an enterprise network.
75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
77 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5
78 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5
79 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
80 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6
81 4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6
82 4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6
83 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8
84 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8
85 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9
86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
88 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
89 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12
90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
91 Intellectual Property and Copyright Statements . . . . . . . . . . 14
111 Myers & Tschofenig Expires January 12, 2007 [Page 2]
113 Internet-Draft OCSP Extensions to IKEv2 July 2006
118 Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
119 supports a range of authentication mechanisms, including the use of
120 public key based authentication. Confirmation of certificate
121 reliability is essential to achieve the security assurances public
122 key cryptography provides. One fundamental element of such
123 confirmation is reference to certificate revocation status (see
124 [RFC3280] for additional detail).
126 The historic means of determining certificate revocation status is
127 through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
128 CRLs to be exchanged in-band via the CERT payload.
130 CRLs can however grow unbounded in size. Many real-world examples
131 exist to demonstrate the impracticality of including a multi-megabyte
132 file in an IKE exchange. This constraint is particularly acute in
133 bandwidth limited environments (e.g., mobile communications). The
134 net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
135 acquisition of these data, should they even be used at all.
137 Reliance on OOB methods can be further complicated if access to
138 revocation data requires use of IPsec (and therefore IKE) to
139 establish secure and authorized access to the CRLs of an IKE
140 participant. Such network access deadlock further contributes to a
141 reduced reliance on certificate revocation status in favor of blind
144 OCSP [RFC2560] offers a useful alternative. The size of an OCSP
145 response is bounded and small and therefore suitable for in-band
146 IKEv2 signaling of a certificate's revocation status.
148 This document defines an extension to IKEv2 that enables the use of
149 OCSP for in-band signaling of certificate revocation status. A new
150 content encoding is defined for use in the CERTREQ and CERT payloads.
151 A CERTREQ payload with "OCSP Content" identifies one or more trusted
152 OCSP responders and is a request for inclusion of an OCSP response in
153 the IKEv2 handshake. A cooperative recipient of such a request
154 responds with a CERT payload containing the appropriate OCSP
155 response. This content is recognizable via the same "OCSP Content"
167 Myers & Tschofenig Expires January 12, 2007 [Page 3]
169 Internet-Draft OCSP Extensions to IKEv2 July 2006
174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
176 document are to be interpreted as described in RFC 2119 [RFC2119].
223 Myers & Tschofenig Expires January 12, 2007 [Page 4]
225 Internet-Draft OCSP Extensions to IKEv2 July 2006
228 3. Extension Definition
230 With reference to Section 3.6 of [IKEv2], the values for the Cert
231 Encoding field of the CERT payload are extended as follows (see also
232 the IANA Considerations section of this document):
234 Certificate Encoding Value
235 -------------------- -----
240 A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
241 Payload indicates the presence of one or more OCSP Responder
242 certificate hashes in the Certificate Authority field of the CERTREQ
245 The presence of OCSP Content (14) in a CERTREQ message:
247 1. identifies one or more OCSP responders trusted by the sender;
249 2. notifies the recipient of sender's support for the OCSP extension
252 3. notifies the recipient of sender's desire to receive OCSP
253 confirmation in a subsequent CERT payload.
257 A value of OCSP Content (14) in the Cert Encoding field of a CERT
258 Payload indicates the presence of an OCSP Response in the Certificate
259 Data field of the CERT payload.
261 Correlation between an OCSP Response CERT payload and a corresponding
262 CERT payload carrying a certificate can be achieved by matching the
263 OCSP response CertID field to the certificate. See [RFC2560] for the
264 definition of OCSP response content.
279 Myers & Tschofenig Expires January 12, 2007 [Page 5]
281 Internet-Draft OCSP Extensions to IKEv2 July 2006
284 4. Extension Requirements
288 Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
289 hashes as the Certification Authority value of a single CERTREQ
290 message. There is no means however to indicate which among those
291 hashes relates to the certificate of a trusted OCSP responder.
293 Therefore an OCSP Request as defined in Section 3.1 above SHALL be
294 transmitted separate from any other CERTREQ payloads in an IKEv2
297 Where it is useful to identify more than one trusted OCSP responder,
298 each such identification SHALL be concatenated in a manner identical
299 to the method documented in Section 3.7 of [IKEv2] regarding the
300 assembly of multiple trust anchor hashes.
302 The Certification Authority value in an OCSP Request CERTREQ SHALL be
303 computed and produced in a manner identical to that of trust anchor
304 hashes as documented in Section 3.7 of [IKEv2].
306 Upon receipt of an OCSP Response CERT payload corresponding to a
307 prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the
308 OCSP response into path validation logic defined by [RFC3280].
310 The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if
313 1. the corresponding OCSP Response CERT payload indicates that the
314 subject certificate is revoked; OR
316 2. the corresponding OCSP Response CERT payload indicates an OCSP
317 error (e.g., malformedRequest, internalError, tryLater,
318 sigRequired, unauthorized, etc.).
320 The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange
321 if a corresponding OCSP Response CERT payload is not received. This
322 might be an indication that this OCSP extension is not supported.
326 Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD
327 acquire the related OCSP-based assertion and produce and transmit an
328 OCSP Response CERT payload corresponding to the certificate needed to
329 verify its signature on IKEv2 payloads.
331 An OCSP Response CERT payload SHALL be transmitted separate from any
335 Myers & Tschofenig Expires January 12, 2007 [Page 6]
337 Internet-Draft OCSP Extensions to IKEv2 July 2006
340 other CERT payload in an IKEv2 exchange.
342 The means by which an OCSP response may be acquired for production of
343 an OCSP Response CERT payload is out of scope of this document.
345 The structure and encoding of the Certificate Data field of an OCSP
346 Response CERT payload SHALL be identical to that defined in
391 Myers & Tschofenig Expires January 12, 2007 [Page 7]
393 Internet-Draft OCSP Extensions to IKEv2 July 2006
396 5. Examples and Discussion
398 This section shows the standard IKEv2 message examples with both
399 peers, the initiator and the responder, using public key based
400 authentication, CERTREQ and CERT payloads. The first instance
401 corresponds to Section 1.2 of [IKEv2], the illustrations of which are
402 reproduced below for reference.
406 Application of the IKEv2 extensions defined in this document to the
407 peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
408 follows. Messages are numbered for ease of reference.
412 ----------- -----------
413 (1) HDR, SAi1, KEi, Ni -->
415 (2) <-- HDR, SAr1, KEr, Nr,
416 CERTREQ(OCSP Request)
417 (3) HDR, SK {IDi, CERT(certificate),-->
419 CERTREQ(OCSP Request),
420 [IDr,] AUTH, SAi2, TSi, TSr}
422 (4) <-- HDR, SK {IDr,
425 AUTH, SAr2, TSi, TSr}
427 In (2) Responder sends an OCSP Request CERTREQ payload identifying
428 one or more OCSP responders trusted by Responder. In response,
429 Initiator sends in (3) both a CERT payload carrying its certificate
430 and an OCSP Response CERT payload covering that certificate. In (3)
431 Initiator also requests an OCSP response via the OCSP Request CERTREQ
432 payload. In (4) Responder returns its certificate and a separate
433 OCSP Response CERT payload covering that certificate.
435 It is important to note that in this scenario, the Responder in (2)
436 does not yet possess the Initiator's certificate and therefore cannot
437 form an OCSP request. [RFC2560] allows for pre-produced responses.
438 It is thus easily inferred that OCSP responses can be produced in the
439 absence of a corresponding request (OCSP nonces notwithstanding). In
440 such instances OCSP Requests are simply index values into these data.
442 It is also important in extending IKEv2 towards OCSP in this scenario
443 that the Initiator has certain knowledge that the Responder is
447 Myers & Tschofenig Expires January 12, 2007 [Page 8]
449 Internet-Draft OCSP Extensions to IKEv2 July 2006
452 capable of and willing to participate in the extension. Yet the
453 Responder will only trust one or more OCSP responder signatures.
454 These factors motivate the definition of OCSP Responder Hash
457 5.2. Extended Authentication Protocol (EAP)
459 Another scenario of pressing interest is the use of EAP to
460 accommodate multiple end users seeking enterprise access to an IPsec
461 gateway. As with the preceding section, the following illustration
462 is extracted from [IKEv2]. In the event of a conflict between this
463 document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
468 ----------- -----------
469 (1) HDR, SAi1, KEi, Ni -->
470 (2) <-- HDR, SAr1, KEr, Nr
471 (3) HDR, SK {IDi, -->
472 CERTREQ(OCSP Request),
473 [IDr,] AUTH, SAi2, TSi, TSr}
474 (4) <-- HDR, SK {IDr,
478 (5) HDR, SK {EAP} -->
480 (6) <-- HDR, SK {EAP (success)}
482 (7) HDR, SK {AUTH} -->
484 (8) <-- HDR, SK {AUTH, SAr2, TSi,
487 In the EAP scenario, messages (5) through (8) are not relevant to
488 this document. Note that while [IKEv2] allows for the optional
489 inclusion of a CERTREQ in (2), this document asserts no need of its
490 use. It is assumed that environments including this optional payload
491 and yet wishing to implement the OCSP extension to IKEv2 are
492 sufficiently robust as to accommodate this redundant payload.
503 Myers & Tschofenig Expires January 12, 2007 [Page 9]
505 Internet-Draft OCSP Extensions to IKEv2 July 2006
508 6. Security Considerations
510 For the reasons noted above, OCSP request as defined in Section 3.1
511 is used in place of OCSP request syntax to trigger production and
512 transmission of an OCSP response. OCSP as defined in [RFC2560] may
513 contain a nonce request extension to improve security against replay
514 attacks (see Section 4.4.1 of [RFC2560] for further details). The
515 OCSP Request defined by this document cannot accommodate nonces.
516 [RFC2560] deals with this aspect by allowing pre-produced responses.
518 [RFC2560] points to this replay vulnerability and indicates: "The use
519 of precomputed responses allows replay attacks in which an old (good)
520 response is replayed prior to its expiration date but after the
521 certificate has been revoked. Deployments of OCSP should carefully
522 evaluate the benefit of precomputed responses against the probability
523 of a replay attack and the costs associated with its successful
524 execution." Nodes SHOULD make the required freshness of an OCSP
525 Response configurable.
559 Myers & Tschofenig Expires January 12, 2007 [Page 10]
561 Internet-Draft OCSP Extensions to IKEv2 July 2006
564 7. IANA Considerations
566 This document defines one new field type for use in the IKEv2 Cert
567 Encoding field of the Certificate Payload format. Official
568 assignment of the "OCSP Content" extension to the Cert Encoding table
569 of Section 3.6 of [IKEv2] needs to be acquired from IANA.
571 Certificate Encoding Value
572 -------------------- -----
615 Myers & Tschofenig Expires January 12, 2007 [Page 11]
617 Internet-Draft OCSP Extensions to IKEv2 July 2006
622 The authors would like to thank Russ Housley for his support.
623 Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
624 Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
627 9. Normative References
629 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
630 RFC 4306, December 2005.
632 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
633 Requirement Levels", BCP 14, RFC 2119, March 1997.
635 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
636 Adams, "X.509 Internet Public Key Infrastructure Online
637 Certificate Status Protocol - OCSP", RFC 2560, June 1999.
639 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
640 X.509 Public Key Infrastructure Certificate and
641 Certificate Revocation List (CRL) Profile", RFC 3280,
671 Myers & Tschofenig Expires January 12, 2007 [Page 12]
673 Internet-Draft OCSP Extensions to IKEv2 July 2006
679 TraceRoute Security LLC
682 Email: mmyers@fastq.com
688 Munich, Bavaria 81739
691 Email: Hannes.Tschofenig@siemens.com
692 URI: http://www.tschofenig.com
727 Myers & Tschofenig Expires January 12, 2007 [Page 13]
729 Internet-Draft OCSP Extensions to IKEv2 July 2006
732 Intellectual Property Statement
734 The IETF takes no position regarding the validity or scope of any
735 Intellectual Property Rights or other rights that might be claimed to
736 pertain to the implementation or use of the technology described in
737 this document or the extent to which any license under such rights
738 might or might not be available; nor does it represent that it has
739 made any independent effort to identify any such rights. Information
740 on the procedures with respect to rights in RFC documents can be
741 found in BCP 78 and BCP 79.
743 Copies of IPR disclosures made to the IETF Secretariat and any
744 assurances of licenses to be made available, or the result of an
745 attempt made to obtain a general license or permission for the use of
746 such proprietary rights by implementers or users of this
747 specification can be obtained from the IETF on-line IPR repository at
748 http://www.ietf.org/ipr.
750 The IETF invites any interested party to bring to its attention any
751 copyrights, patents or patent applications, or other proprietary
752 rights that may cover technology that may be required to implement
753 this standard. Please address the information to the IETF at
757 Disclaimer of Validity
759 This document and the information contained herein are provided on an
760 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
761 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
762 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
763 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
764 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
765 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
770 Copyright (C) The Internet Society (2006). This document is subject
771 to the rights, licenses and restrictions contained in BCP 78, and
772 except as set forth therein, the authors retain all their rights.
777 Funding for the RFC Editor function is currently provided by the
783 Myers & Tschofenig Expires January 12, 2007 [Page 14]