7
Network Working Group M. Myers
8
Request for Comments: 4806 TraceRoute Security LLC
9
Category: Standards Track H. Tschofenig
10
Siemens Networks GmbH & Co KG
14
Online Certificate Status Protocol (OCSP) Extensions to IKEv2
18
This document specifies an Internet standards track protocol for the
19
Internet community, and requests discussion and suggestions for
20
improvements. Please refer to the current edition of the "Internet
21
Official Protocol Standards" (STD 1) for the standardization state
22
and status of this protocol. Distribution of this memo is unlimited.
26
Copyright (C) The IETF Trust (2006).
30
While the Internet Key Exchange Protocol version 2 (IKEv2) supports
31
public key based authentication, the corresponding use of in-band
32
Certificate Revocation Lists (CRL) is problematic due to unbounded
33
CRL size. The size of an Online Certificate Status Protocol (OCSP)
34
response is however well-bounded and small. This document defines
35
the "OCSP Content" extension to IKEv2. A CERTREQ payload with "OCSP
36
Content" identifies zero or more trusted OCSP responders and is a
37
request for inclusion of an OCSP response in the IKEv2 handshake. A
38
cooperative recipient of such a request responds with a CERT payload
39
containing the appropriate OCSP response. This content is
40
recognizable via the same "OCSP Content" identifier.
42
When certificates are used with IKEv2, the communicating peers need a
43
mechanism to determine the revocation status of the peer's
44
certificate. OCSP is one such mechanism. This document applies when
45
OCSP is desired and security policy prevents one of the IKEv2 peers
46
from accessing the relevant OCSP responder directly. Firewalls are
47
often deployed in a manner that prevents such access by IKEv2 peers
48
outside of an enterprise network.
58
Myers & Tschofenig Standards Track [Page 1]
60
RFC 4806 OCSP Extensions to IKEv2 February 2007
65
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
66
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
67
3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 4
68
3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 4
69
3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5
70
4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 5
71
4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 5
72
4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 6
73
5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 6
74
5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 6
75
5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 7
76
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
77
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
78
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
79
9. Normative References . . . . . . . . . . . . . . . . . . . . . 9
83
Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2]
84
supports a range of authentication mechanisms, including the use of
85
public key based authentication. Confirmation of certificate
86
reliability is essential in order to achieve the security assurances
87
public key cryptography provides. One fundamental element of such
88
confirmation is reference to certificate revocation status (see
89
[RFC3280] for additional detail).
91
The traditional means of determining certificate revocation status is
92
through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
93
CRLs to be exchanged in-band via the CERT payload.
95
However, CRLs can grow unbounded in size. Many real-world examples
96
exist to demonstrate the impracticality of including a multi-megabyte
97
file in an IKE exchange. This constraint is particularly acute in
98
bandwidth-limited environments (e.g., mobile communications). The
99
net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
100
acquisition of these data, should they even be used at all.
102
Reliance on OOB methods can be further complicated if access to
103
revocation data requires use of IPsec (and therefore IKE) to
104
establish secure and authorized access to the CRLs of an IKE
105
participant. Such network access deadlock further contributes to a
106
reduced reliance on the status of certificate revocations in favor of
114
Myers & Tschofenig Standards Track [Page 2]
116
RFC 4806 OCSP Extensions to IKEv2 February 2007
119
OCSP [RFC2560] offers a useful alternative. The size of an OCSP
120
response is bounded and small and therefore suitable for in-band
121
IKEv2 signaling of a certificate's revocation status.
123
This document defines an extension to IKEv2 that enables the use of
124
OCSP for in-band signaling of certificate revocation status. A new
125
content encoding is defined for use in the CERTREQ and CERT payloads.
126
A CERTREQ payload with "OCSP Content" identifies zero or more trusted
127
OCSP responders and is a request for inclusion of an OCSP response in
128
the IKEv2 handshake. A cooperative recipient of such a request
129
responds with a CERT payload containing the appropriate OCSP
130
response. This content is recognizable via the same "OCSP Content"
135
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
136
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
137
document are to be interpreted as described in RFC 2119 [RFC2119].
139
This document defines the following terms:
143
An OCSP request refers to the CERTREQ payload that contains a new
144
content encoding, referred to as OCSP Content, that conforms to
145
the definition and behavior specified in Section 3.1.
149
An OCSP response refers to the CERT payload that contains a new
150
content encoding, referred to as OCSP Content, that conforms to
151
the definition and behavior specified in Section 3.2.
155
The term OCSP responder refers to the entity that accepts requests
156
from an OCSP client and returns responses as defined in [RFC2560].
157
Note that the OCSP responder does not refer to the party that
158
sends the CERT message.
170
Myers & Tschofenig Standards Track [Page 3]
172
RFC 4806 OCSP Extensions to IKEv2 February 2007
175
3. Extension Definition
177
With reference to Section 3.6 of [IKEv2], the values for the Cert
178
Encoding field of the CERT payload are extended as follows (see also
179
the IANA Considerations section of this document):
181
Certificate Encoding Value
182
-------------------- -----
187
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
188
Payload indicates the presence of zero or more OCSP responder
189
certificate hashes in the Certificate Authority field of the CERTREQ
190
payload. Section 2.2 of [RFC2560] defines responses, which belong to
191
one of the following three groups:
193
(a) the CA who issued the certificate
195
(b) a Trusted Responder whose public key is trusted by the requester
197
(c) a CA Designated Responder (Authorized Responder) who holds a
198
specially marked certificate issued directly by the CA,
199
indicating that the responder may issue OCSP responses for that
202
In case of (a), the use of hashes in the CERTREQ message is not
203
needed since the OCSP response is signed by the CA who issued the
204
certificate. In case of (c), the OCSP response is signed by the CA
205
Designated Responder whereby the sender of the CERTREQ message does
206
not know the public key in advance. The presence of OCSP Content in
207
a CERTREQ message will identify one or more OCSP responders trusted
208
by the sender in case of (b).
210
The presence of OCSP Content (14) in a CERTREQ message:
212
1. identifies zero or more OCSP responders trusted by the sender;
214
2. notifies the recipient of sender's support for the OCSP extension
217
3. notifies the recipient of sender's desire to receive OCSP
218
confirmation in a subsequent CERT payload.
226
Myers & Tschofenig Standards Track [Page 4]
228
RFC 4806 OCSP Extensions to IKEv2 February 2007
233
A value of OCSP Content (14) in the Cert Encoding field of a CERT
234
Payload indicates the presence of an OCSP response in the Certificate
235
Data field of the CERT payload.
237
Correlation between an OCSP response CERT payload and a corresponding
238
CERT payload carrying a certificate can be achieved by matching the
239
OCSP response CertID field to the certificate. See [RFC2560] for the
240
definition of OCSP response content.
242
4. Extension Requirements
244
4.1. Request for OCSP Support
246
Section 3.7 of [IKEv2] allows for the concatenation of trust anchor
247
hashes as the Certification Authority value of a single CERTREQ
248
message. There is no means however to indicate which among those
249
hashes, if present, relates to the certificate of a trusted OCSP
252
Therefore, an OCSP request, as defined in Section 3.1 above, is
253
transmitted separate from any other CERTREQ payloads in an IKEv2
256
Where it is useful to identify more than one trusted OCSP responder,
257
each such identification SHALL be concatenated in a manner identical
258
to the method documented in Section 3.7 of [IKEv2] regarding the
259
assembly of multiple trust anchor hashes.
261
The Certification Authority value in an OCSP request CERTREQ SHALL be
262
computed and produced in a manner identical to that of trust anchor
263
hashes as documented in Section 3.7 of [IKEv2].
265
Upon receipt of an OCSP response CERT payload corresponding to a
266
prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
267
OCSP response into path validation logic defined by [RFC3280].
269
Note that the lack of an OCSP response CERT payload after sending an
270
OCSP request CERT payload might be an indication that this OCSP
271
extension is not supported. As a result, it is recommended that
272
nodes be configured to require a response only if it is known that
273
all peers do in fact support this extension. Otherwise, it is
274
recommended that the nodes be configured to try OCSP and, if there is
275
no response, attempt to determine certificate revocation status by
282
Myers & Tschofenig Standards Track [Page 5]
284
RFC 4806 OCSP Extensions to IKEv2 February 2007
287
4.2. Response to OCSP Support
289
Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD
290
acquire the related OCSP-based assertion and produce and transmit an
291
OCSP response CERT payload corresponding to the certificate needed to
292
verify its signature on IKEv2 payloads.
294
An OCSP response CERT payload is transmitted separate from any other
295
CERT payload in an IKEv2 exchange.
297
The means by which an OCSP response may be acquired for production of
298
an OCSP response CERT payload is out of scope of this document.
300
The Certificate Data field of an OCSP response CERT payload SHALL
301
contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
303
5. Examples and Discussion
305
This section shows the standard IKEv2 message examples with both
306
peers, the initiator and the responder, using public key based
307
authentication, CERTREQ and CERT payloads. The first instance
308
corresponds to Section 1.2 of [IKEv2], the illustrations of which are
309
reproduced below for reference.
313
Application of the IKEv2 extensions defined in this document to the
314
peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as
315
follows. Messages are numbered for ease of reference.
318
----------- -----------
319
(1) HDR, SAi1, KEi, Ni -->
321
(2) <-- HDR, SAr1, KEr, Nr,
322
CERTREQ(OCSP Request)
323
(3) HDR, SK {IDi, CERT(certificate),-->
325
CERTREQ(OCSP Request),
326
[IDr,] AUTH, SAi2, TSi, TSr}
328
(4) <-- HDR, SK {IDr,
331
AUTH, SAr2, TSi, TSr}
333
OCSP Extensions to Baseline IKEv2
338
Myers & Tschofenig Standards Track [Page 6]
340
RFC 4806 OCSP Extensions to IKEv2 February 2007
343
In (2), Responder sends an OCSP request CERTREQ payload identifying
344
zero or more OCSP responders trusted by the Responder. In response,
345
Initiator sends in (3) both a CERT payload carrying its certificate
346
and an OCSP response CERT payload covering that certificate. In (3),
347
Initiator also requests an OCSP response via the OCSP request CERTREQ
348
payload. In (4), the Responder returns its certificate and a
349
separate OCSP response CERT payload covering that certificate.
351
It is important to note that in this scenario, the Responder in (2)
352
does not yet possess the Initiator's certificate and therefore cannot
353
form an OCSP request as defined in [RFC2560]. To bypass this
354
problem, hashes are used as defined in Section 4.1. In such
355
instances, OCSP Requests are simply index values into these data.
356
Thus, it is easily inferred that OCSP responses can be produced in
357
the absence of a corresponding request (provided that OCSP nonces are
358
not used, see Section 6).
360
It is also important in extending IKEv2 toward OCSP in this scenario
361
that the Initiator has certain knowledge that the Responder is
362
capable of and willing to participate in the extension. Yet the
363
Responder will only trust one or more OCSP responder signatures.
364
These factors motivate the definition of OCSP responder hash
367
5.2. Extended Authentication Protocol (EAP)
369
Another scenario of pressing interest is the use of EAP to
370
accommodate multiple end users seeking enterprise access to an IPsec
371
gateway. Note that OCSP is used for the certificate status check of
372
the server side IKEv2 certificate and not for certificates that may
373
be used within EAP methods (either by the EAP peer or the EAP
374
server). As with the preceding section, the following illustration
375
is extracted from [IKEv2]. In the event of a conflict between this
376
document and [IKEv2] regarding these illustrations, [IKEv2] SHALL
394
Myers & Tschofenig Standards Track [Page 7]
396
RFC 4806 OCSP Extensions to IKEv2 February 2007
400
----------- -----------
401
(1) HDR, SAi1, KEi, Ni -->
402
(2) <-- HDR, SAr1, KEr, Nr
403
(3) HDR, SK {IDi, -->
404
CERTREQ(OCSP Request),
405
[IDr,] AUTH, SAi2, TSi, TSr}
406
(4) <-- HDR, SK {IDr,
410
(5) HDR, SK {EAP} -->
412
(6) <-- HDR, SK {EAP (success)}
414
(7) HDR, SK {AUTH} -->
416
(8) <-- HDR, SK {AUTH, SAr2, TSi,
419
OCSP Extensions to EAP in IKEv2
421
In the EAP scenario, messages (5) through (8) are not relevant to
424
6. Security Considerations
426
For the reasons noted above, an OCSP request, as defined in Section
427
3.1, is used in place of an OCSP request syntax to trigger production
428
and transmission of an OCSP response. OCSP, as defined in [RFC2560],
429
may contain a nonce request extension to improve security against
430
replay attacks (see Section 4.4.1 of [RFC2560] for further details).
431
The OCSP request defined by this document cannot accommodate nonces.
432
[RFC2560] deals with this aspect by allowing pre-produced responses.
434
[RFC2560] points to this replay vulnerability and indicates: "The use
435
of precomputed responses allows replay attacks in which an old (good)
436
response is replayed prior to its expiration date but after the
437
certificate has been revoked. Deployments of OCSP should carefully
438
evaluate the benefit of precomputed responses against the probability
439
of a replay attack and the costs associated with its successful
440
execution." Nodes SHOULD make the required freshness of an OCSP
441
response configurable.
450
Myers & Tschofenig Standards Track [Page 8]
452
RFC 4806 OCSP Extensions to IKEv2 February 2007
455
7. IANA Considerations
457
This document defines one new field type for use in the IKEv2 Cert
458
Encoding field of the Certificate Payload format. Official
459
assignment of the "OCSP Content" extension to the Cert Encoding table
460
of Section 3.6 of [IKEv2] has been acquired from IANA.
462
Certificate Encoding Value
463
-------------------- -----
468
The authors would like to thank Russ Housley for his support.
469
Additionally, we would like to thank Pasi Eronen, Nicolas Williams,
470
Liqiang (Larry) Zhu, Lakshminath Dondeti, and Paul Hoffman for their
471
review. Pasi gave us invaluable last-call comments. We would also
472
like to thank Tom Taylor for his Gen-ART review. Jari Arkko gave us
473
IESG review comments.
475
9. Normative References
477
[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
478
RFC 4306, December 2005.
480
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
481
Requirement Levels", BCP 14, RFC 2119, March 1997.
483
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
484
Adams, "X.509 Internet Public Key Infrastructure Online
485
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
487
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
488
X.509 Public Key Infrastructure Certificate and
489
Certificate Revocation List (CRL) Profile", RFC 3280,
506
Myers & Tschofenig Standards Track [Page 9]
508
RFC 4806 OCSP Extensions to IKEv2 February 2007
514
TraceRoute Security LLC
516
EMail: mmyers@fastq.com
520
Siemens Networks GmbH & Co KG
522
Munich, Bavaria 81739
525
EMail: Hannes.Tschofenig@siemens.com
526
URI: http://www.tschofenig.com
562
Myers & Tschofenig Standards Track [Page 10]
564
RFC 4806 OCSP Extensions to IKEv2 February 2007
567
Full Copyright Statement
569
Copyright (C) The IETF Trust (2007).
571
This document is subject to the rights, licenses and restrictions
572
contained in BCP 78, and except as set forth therein, the authors
573
retain all their rights.
575
This document and the information contained herein are provided on an
576
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
577
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
578
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
579
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
580
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
581
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
583
Intellectual Property
585
The IETF takes no position regarding the validity or scope of any
586
Intellectual Property Rights or other rights that might be claimed to
587
pertain to the implementation or use of the technology described in
588
this document or the extent to which any license under such rights
589
might or might not be available; nor does it represent that it has
590
made any independent effort to identify any such rights. Information
591
on the procedures with respect to rights in RFC documents can be
592
found in BCP 78 and BCP 79.
594
Copies of IPR disclosures made to the IETF Secretariat and any
595
assurances of licenses to be made available, or the result of an
596
attempt made to obtain a general license or permission for the use of
597
such proprietary rights by implementers or users of this
598
specification can be obtained from the IETF on-line IPR repository at
599
http://www.ietf.org/ipr.
601
The IETF invites any interested party to bring to its attention any
602
copyrights, patents or patent applications, or other proprietary
603
rights that may cover technology that may be required to implement
604
this standard. Please address the information to the IETF at
609
Funding for the RFC Editor function is currently provided by the
618
Myers & Tschofenig Standards Track [Page 11]
added
removed
doc/standards/rfc4806.txt
