2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Network Working Group M. Myers
|
|
|
|
|
Request for Comments: 4806 TraceRoute Security LLC
|
|
|
|
|
Category: Standards Track H. Tschofenig
|
|
|
|
|
Siemens Networks GmbH & Co KG
|
|
|
|
|
February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Status of This Memo
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
This document specifies an Internet standards track protocol for the
|
|
|
|
|
Internet community, and requests discussion and suggestions for
|
|
|
|
|
improvements. Please refer to the current edition of the "Internet
|
|
|
|
|
Official Protocol Standards" (STD 1) for the standardization state
|
|
|
|
|
and status of this protocol. Distribution of this memo is unlimited.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
Copyright Notice
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Copyright (C) The IETF Trust (2006).
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
While the Internet Key Exchange Protocol version 2 (IKEv2) supports
|
|
|
|
|
public key based authentication, the corresponding use of in-band
|
|
|
|
|
Certificate Revocation Lists (CRL) is problematic due to unbounded
|
|
|
|
|
CRL size. The size of an Online Certificate Status Protocol (OCSP)
|
|
|
|
|
response is however well-bounded and small. This document defines
|
|
|
|
|
the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP
|
|
|
|
|
Content" identifies zero 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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 1]
|
|
|
|
|
|
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Table of Contents
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
|
|
|
|
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
|
|
|
|
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
|
|
|
|
|
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
|
|
|
|
|
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
|
|
|
|
|
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
|
|
|
|
|
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
|
|
|
|
|
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
|
|
|
|
|
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
|
|
|
|
|
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
reliability is essential in order to achieve the security assurances
|
|
|
|
|
public key cryptography provides. One fundamental element of such
|
2006-09-27 14:10:32 +00:00
|
|
|
|
confirmation is reference to certificate revocation status (see
|
|
|
|
|
[RFC3280] for additional detail).
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
The traditional means of determining certificate revocation status is
|
2006-09-27 14:10:32 +00:00
|
|
|
|
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
|
|
|
|
|
CRLs to be exchanged in-band via the CERT payload.
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
However, CRLs can grow unbounded in size. Many real-world examples
|
2006-09-27 14:10:32 +00:00
|
|
|
|
exist to demonstrate the impracticality of including a multi-megabyte
|
|
|
|
|
file in an IKE exchange. This constraint is particularly acute in
|
2008-04-02 13:20:14 +00:00
|
|
|
|
bandwidth-limited environments (e.g., mobile communications). The
|
2006-09-27 14:10:32 +00:00
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
reduced reliance on the status of certificate revocations in favor of
|
|
|
|
|
blind trust.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Myers & Tschofenig Standards Track [Page 2]
|
|
|
|
|
|
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
|
|
|
|
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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.
|
2008-04-02 13:20:14 +00:00
|
|
|
|
A CERTREQ payload with "OCSP Content" identifies zero or more trusted
|
2006-09-27 14:10:32 +00:00
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
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].
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
This document defines the following terms:
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
OCSP request:
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
An OCSP request refers to the CERTREQ payload that contains a new
|
|
|
|
|
content encoding, referred to as OCSP Content, that conforms to
|
|
|
|
|
the definition and behavior specified in Section 3.1.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
OCSP response:
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
An OCSP response refers to the CERT payload that contains a new
|
|
|
|
|
content encoding, referred to as OCSP Content, that conforms to
|
|
|
|
|
the definition and behavior specified in Section 3.2.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
OCSP responder:
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
The term OCSP responder refers to the entity that accepts requests
|
|
|
|
|
from an OCSP client and returns responses as defined in [RFC2560].
|
|
|
|
|
Note that the OCSP responder does not refer to the party that
|
|
|
|
|
sends the CERT message.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 3]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Payload indicates the presence of zero or more OCSP responder
|
2006-09-27 14:10:32 +00:00
|
|
|
|
certificate hashes in the Certificate Authority field of the CERTREQ
|
2008-04-02 13:20:14 +00:00
|
|
|
|
payload. Section 2.2 of [RFC2560] defines responses, which belong to
|
|
|
|
|
one of the following three groups:
|
|
|
|
|
|
|
|
|
|
(a) the CA who issued the certificate
|
|
|
|
|
|
|
|
|
|
(b) a Trusted Responder whose public key is trusted by the requester
|
|
|
|
|
|
|
|
|
|
(c) a CA Designated Responder (Authorized Responder) who holds a
|
|
|
|
|
specially marked certificate issued directly by the CA,
|
|
|
|
|
indicating that the responder may issue OCSP responses for that
|
|
|
|
|
CA
|
|
|
|
|
|
|
|
|
|
In case of (a), the use of hashes in the CERTREQ message is not
|
|
|
|
|
needed since the OCSP response is signed by the CA who issued the
|
|
|
|
|
certificate. In case of (c), the OCSP response is signed by the CA
|
|
|
|
|
Designated Responder whereby the sender of the CERTREQ message does
|
|
|
|
|
not know the public key in advance. The presence of OCSP Content in
|
|
|
|
|
a CERTREQ message will identify one or more OCSP responders trusted
|
|
|
|
|
by the sender in case of (b).
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
The presence of OCSP Content (14) in a CERTREQ message:
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
1. identifies zero or more OCSP responders trusted by the sender;
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 4]
|
|
|
|
|
|
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
3.2. OCSP Response
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
4. Extension Requirements
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
4.1. Request for OCSP Support
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
hashes, if present, relates to the certificate of a trusted OCSP
|
|
|
|
|
responder.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Therefore, an OCSP request, as defined in Section 3.1 above, is
|
2006-09-27 14:10:32 +00:00
|
|
|
|
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.
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
The Certification Authority value in an OCSP request CERTREQ SHALL be
|
2006-09-27 14:10:32 +00:00
|
|
|
|
computed and produced in a manner identical to that of trust anchor
|
|
|
|
|
hashes as documented in Section 3.7 of [IKEv2].
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Upon receipt of an OCSP response CERT payload corresponding to a
|
|
|
|
|
prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
|
2006-09-27 14:10:32 +00:00
|
|
|
|
OCSP response into path validation logic defined by [RFC3280].
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Note that the lack of an OCSP response CERT payload after sending an
|
|
|
|
|
OCSP request CERT payload might be an indication that this OCSP
|
|
|
|
|
extension is not supported. As a result, it is recommended that
|
|
|
|
|
nodes be configured to require a response only if it is known that
|
|
|
|
|
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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 5]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
4.2. Response to OCSP Support
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
An OCSP response CERT payload is transmitted separate from any other
|
|
|
|
|
CERT payload in an IKEv2 exchange.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
The Certificate Data field of an OCSP response CERT payload SHALL
|
|
|
|
|
contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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}
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
OCSP Extensions to Baseline IKEv2
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 6]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
In (2), Responder sends an OCSP request CERTREQ payload identifying
|
|
|
|
|
zero or more OCSP responders trusted by the 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), the 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 as defined in [RFC2560]. To bypass this
|
|
|
|
|
problem, hashes are used as defined in Section 4.1. In such
|
|
|
|
|
instances, OCSP Requests are simply index values into these data.
|
|
|
|
|
Thus, it is easily inferred that OCSP responses can be produced in
|
|
|
|
|
the absence of a corresponding request (provided that OCSP nonces are
|
|
|
|
|
not used, see Section 6).
|
|
|
|
|
|
|
|
|
|
It is also important in extending IKEv2 toward OCSP in this scenario
|
|
|
|
|
that the Initiator has certain knowledge that the Responder is
|
2006-09-27 14:10:32 +00:00
|
|
|
|
capable of and willing to participate in the extension. Yet the
|
|
|
|
|
Responder will only trust one or more OCSP responder signatures.
|
2008-04-02 13:20:14 +00:00
|
|
|
|
These factors motivate the definition of OCSP responder hash
|
2006-09-27 14:10:32 +00:00
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
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
|
2006-09-27 14:10:32 +00:00
|
|
|
|
is extracted from [IKEv2]. In the event of a conflict between this
|
2008-04-02 13:20:14 +00:00
|
|
|
|
document and [IKEv2] regarding these illustrations, [IKEv2] SHALL
|
2006-09-27 14:10:32 +00:00
|
|
|
|
dominate.
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Myers & Tschofenig Standards Track [Page 7]
|
|
|
|
|
|
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
|
|
|
|
|
|
|
|
|
|
2006-09-27 14:10:32 +00:00
|
|
|
|
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 }
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
OCSP Extensions to EAP in IKEv2
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
In the EAP scenario, messages (5) through (8) are not relevant to
|
|
|
|
|
this document.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
6. Security Considerations
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
For the reasons noted above, an OCSP request, as defined in Section
|
|
|
|
|
3.1, is used in place of an 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.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
[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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
response configurable.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 8]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
2008-04-02 13:20:14 +00:00
|
|
|
|
of Section 3.6 of [IKEv2] has been acquired from IANA.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
Certificate Encoding Value
|
|
|
|
|
-------------------- -----
|
|
|
|
|
OCSP Content 14
|
|
|
|
|
|
|
|
|
|
8. Acknowledgements
|
|
|
|
|
|
|
|
|
|
The authors would like to thank Russ Housley for his support.
|
|
|
|
|
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their
|
|
|
|
|
review. Pasi gave us invaluable last-call comments. We would also
|
|
|
|
|
like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us
|
|
|
|
|
IESG review comments.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 9]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Authors' Addresses
|
|
|
|
|
|
|
|
|
|
Michael Myers
|
|
|
|
|
TraceRoute Security LLC
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
EMail: mmyers@fastq.com
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hannes Tschofenig
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Siemens Networks GmbH & Co KG
|
2006-09-27 14:10:32 +00:00
|
|
|
|
Otto-Hahn-Ring 6
|
|
|
|
|
Munich, Bavaria 81739
|
|
|
|
|
Germany
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
EMail: Hannes.Tschofenig@siemens.com
|
2006-09-27 14:10:32 +00:00
|
|
|
|
URI: http://www.tschofenig.com
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
|
|
|
|
|
Myers & Tschofenig Standards Track [Page 10]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
RFC 4806 OCSP Extensions to IKEv2 February 2007
|
|
|
|
|
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Full Copyright Statement
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Copyright (C) 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.
|
|
|
|
|
|
|
|
|
|
Intellectual Property
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Acknowledgement
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Funding for the RFC Editor function is currently provided by the
|
|
|
|
|
Internet Society.
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-02 13:20:14 +00:00
|
|
|
|
Myers & Tschofenig Standards Track [Page 11]
|
2006-09-27 14:10:32 +00:00
|
|
|
|
|