< draft-myers-ikev2-ocsp-04.txt   draft-myers-ikev2-ocsp-05.txt >
Network Working Group M. Myers Network Working Group M. Myers
Internet-Draft TraceRoute Security LLC Internet-Draft TraceRoute Security LLC
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: March 19, 2007 Siemens Expires: April 25, 2007 Siemens
September 15, 2006 October 22, 2006
OCSP Extensions to IKEv2 OCSP Extensions to IKEv2
draft-myers-ikev2-ocsp-04.txt draft-myers-ikev2-ocsp-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 19, 2007. This Internet-Draft will expire on April 25, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
While IKEv2 supports public key based authentication (PKI), the While IKEv2 supports public key based authentication (PKI), the
corresponding use of in-band CRLs is problematic due to unbounded corresponding use of in-band CRLs is problematic due to unbounded
Certificate Revocation List (CRL) size. The size of an Online Certificate Revocation List (CRL) size. The size of an Online
skipping to change at page 3, line 15 skipping to change at page 3, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 6 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 6
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 7 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 7
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 8 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 8
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 8 4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 8
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 8 4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 8
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 9 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 10
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 10 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 9. Normative References . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17
1. Introduction 1. Introduction
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
supports a range of authentication mechanisms, including the use of supports a range of authentication mechanisms, including the use of
public key based authentication. Confirmation of certificate public key based authentication. Confirmation of certificate
reliability is essential to achieve the security assurances public reliability is essential to achieve the security assurances public
key cryptography provides. One fundamental element of such key cryptography provides. One fundamental element of such
confirmation is reference to certificate revocation status (see confirmation is reference to certificate revocation status (see
[RFC3280] for additional detail). [RFC3280] for additional detail).
skipping to change at page 8, line 32 skipping to change at page 8, line 32
assembly of multiple trust anchor hashes. assembly of multiple trust anchor hashes.
The Certification Authority value in an OCSP request CERTREQ SHALL be The Certification Authority value in an OCSP request CERTREQ SHALL be
computed and produced in a manner identical to that of trust anchor computed and produced in a manner identical to that of trust anchor
hashes as documented in Section 3.7 of [IKEv2]. hashes as documented in Section 3.7 of [IKEv2].
Upon receipt of an OCSP response CERT payload corresponding to a Upon receipt of an OCSP response CERT payload corresponding to a
prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
OCSP response into path validation logic defined by [RFC3280]. OCSP response into path validation logic defined by [RFC3280].
The sender of an OCSP request CERTREQ SHOULD accept an IKEv2 exchange Note that the lack of an OCSP response CERT payload after sending an
if a corresponding OCSP response CERT payload is not received. This OCSP request CERT payload might be an indication that this OCSP
might be an indication that this OCSP extension is not supported. In extension is not supported. As a result, it is recommended that
this case, the peer SHOULD attempt to determine certificate nodes be configured to require a response only if it is known that
revocation status by some other means. all peers do in fact support this extension. Otherwise, it is
recommended that the nodes be configured to try OCSP and, if there is
no response, attempt to determine certificate revocation status by
some other means.
4.2. Response to OCSP Support 4.2. Response to OCSP Support
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD
acquire the related OCSP-based assertion and produce and transmit an acquire the related OCSP-based assertion and produce and transmit an
OCSP response CERT payload corresponding to the certificate needed to OCSP response CERT payload corresponding to the certificate needed to
verify its signature on IKEv2 payloads. verify its signature on IKEv2 payloads.
An OCSP response CERT payload is transmitted separate from any other An OCSP response CERT payload is transmitted separate from any other
CERT payload in an IKEv2 exchange. CERT payload in an IKEv2 exchange.
skipping to change at page 10, line 17 skipping to change at page 11, line 17
that the Initiator has certain knowledge that the Responder is that the Initiator has certain knowledge that the Responder is
capable of and willing to participate in the extension. Yet the capable of and willing to participate in the extension. Yet the
Responder will only trust one or more OCSP responder signatures. Responder will only trust one or more OCSP responder signatures.
These factors motivate the definition of OCSP responder hash These factors motivate the definition of OCSP responder hash
extension. extension.
5.2. Extended Authentication Protocol (EAP) 5.2. Extended Authentication Protocol (EAP)
Another scenario of pressing interest is the use of EAP to Another scenario of pressing interest is the use of EAP to
accommodate multiple end users seeking enterprise access to an IPsec accommodate multiple end users seeking enterprise access to an IPsec
gateway. As with the preceding section, the following illustration gateway. Note that OCSP is used for the certificate status check of
the server side IKEv2 certificate and not for certificates that may
be used within EAP methods (either by the EAP peer or the EAP
server). As with the preceding section, the following illustration
is extracted from [IKEv2]. In the event of a conflict between this is extracted from [IKEv2]. In the event of a conflict between this
document and[IKEv2] regarding these illustrations, [IKEv2] SHALL document and[IKEv2] regarding these illustrations, [IKEv2] SHALL
dominate. dominate.
Initiator Responder Initiator Responder
----------- ----------- ----------- -----------
(1) HDR, SAi1, KEi, Ni --> (1) HDR, SAi1, KEi, Ni -->
(2) <-- HDR, SAr1, KEr, Nr (2) <-- HDR, SAr1, KEr, Nr
(3) HDR, SK {IDi, --> (3) HDR, SK {IDi, -->
CERTREQ(OCSP Request), CERTREQ(OCSP Request),
skipping to change at page 10, line 45 skipping to change at page 11, line 48
(6) <-- HDR, SK {EAP (success)} (6) <-- HDR, SK {EAP (success)}
(7) HDR, SK {AUTH} --> (7) HDR, SK {AUTH} -->
(8) <-- HDR, SK {AUTH, SAr2, TSi, (8) <-- HDR, SK {AUTH, SAr2, TSi,
TSr } TSr }
OCSP Extensions to EAP in IKEv2 OCSP Extensions to EAP in IKEv2
In the EAP scenario, messages (5) through (8) are not relevant to In the EAP scenario, messages (5) through (8) are not relevant to
this document. Note that while [IKEv2] allows for the optional this document.
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.
6. Security Considerations 6. Security Considerations
For the reasons noted above, OCSP request as defined in Section 3.1 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 is used in place of OCSP request syntax to trigger production and
transmission of an OCSP response. OCSP as defined in [RFC2560] may transmission of an OCSP response. OCSP as defined in [RFC2560] may
contain a nonce request extension to improve security against replay contain a nonce request extension to improve security against replay
attacks (see Section 4.4.1 of [RFC2560] for further details). The attacks (see Section 4.4.1 of [RFC2560] for further details). The
OCSP request defined by this document cannot accommodate nonces. OCSP request defined by this document cannot accommodate nonces.
[RFC2560] deals with this aspect by allowing pre-produced responses. [RFC2560] deals with this aspect by allowing pre-produced responses.
skipping to change at page 13, line 11 skipping to change at page 14, line 11
Certificate Encoding Value Certificate Encoding Value
-------------------- ----- -------------------- -----
OCSP Content 14 OCSP Content 14
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Russ Housley for his support. The authors would like to thank Russ Housley for his support.
Additionally, we would like to thank Pasi Eronen, Nicolas Williams, Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their
review. Pasi gave us invaluable last call comments. We would also review. Pasi gave us invaluable last call comments. We would also
like to thank Tom Taylor for his Gen-ART review. like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us
IESG review comments.
9. Normative References 9. Normative References
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
 End of changes. 8 change blocks. 
25 lines changed or deleted 28 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/