1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
|
<pre>Network Working Group M. Myers
Request for Comments: 4806 TraceRoute Security LLC
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
February 2007
<span class="h1">Online Certificate Status Protocol (OCSP) Extensions to IKEv2</span>
Status of This Memo
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.
Copyright Notice
Copyright (C) The IETF Trust (2006).
Abstract
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.
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.
<span class="grey">Myers & Tschofenig Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Extension Definition . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. OCSP Response . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Extension Requirements . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Request for OCSP Support . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-4.2">4.2</a>. Response to OCSP Support . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5">5</a>. Examples and Discussion . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a>. Extended Authentication Protocol (EAP) . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-9">9</a>. Normative References . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Version 2 of the Internet Key Exchange (IKE) protocol [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>]
supports a range of authentication mechanisms, including the use of
public key based authentication. Confirmation of certificate
reliability is essential in order to achieve the security assurances
public key cryptography provides. One fundamental element of such
confirmation is reference to certificate revocation status (see
[<a href="./rfc3280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3280</a>] for additional detail).
The traditional 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.
However, CRLs can 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 the status of certificate revocations in favor of
blind trust.
<span class="grey">Myers & Tschofenig Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
OCSP [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>] 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 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.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This document defines the following terms:
OCSP request:
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 <a href="#section-3.1">Section 3.1</a>.
OCSP response:
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 <a href="#section-3.2">Section 3.2</a>.
OCSP responder:
The term OCSP responder refers to the entity that accepts requests
from an OCSP client and returns responses as defined in [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>].
Note that the OCSP responder does not refer to the party that
sends the CERT message.
<span class="grey">Myers & Tschofenig Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Extension Definition</span>
With reference to Section 3.6 of [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>], 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
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. OCSP Request</span>
A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ
Payload indicates the presence of zero or more OCSP responder
certificate hashes in the Certificate Authority field of the CERTREQ
payload. <a href="./rfc2560#section-2.2">Section 2.2 of [RFC2560]</a> 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).
The presence of OCSP Content (14) in a CERTREQ message:
1. identifies zero 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.
<span class="grey">Myers & Tschofenig Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. OCSP Response</span>
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 [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>] for the
definition of OCSP response content.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Extension Requirements</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Request for OCSP Support</span>
Section 3.7 of [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] 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, if present, relates to the certificate of a trusted OCSP
responder.
Therefore, an OCSP request, as defined in <a href="#section-3.1">Section 3.1</a> above, is
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 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] 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 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>].
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 [<a href="./rfc3280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3280</a>].
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.
<span class="grey">Myers & Tschofenig Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Response to OCSP Support</span>
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 is transmitted separate from any 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 Certificate Data field of an OCSP response CERT payload SHALL
contain a DER-encoded OCSPResponse structure as defined in [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Examples and Discussion</span>
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 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>], the illustrations of which are
reproduced below for reference.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Peer to Peer</span>
Application of the IKEv2 extensions defined in this document to the
peer-to-peer exchange defined in Section 1.2 of [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] 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}
OCSP Extensions to Baseline IKEv2
<span class="grey">Myers & Tschofenig Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
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 [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>]. To bypass this
problem, hashes are used as defined in <a href="#section-4.1">Section 4.1</a>. 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 <a href="#section-6">Section 6</a>).
It is also important in extending IKEv2 toward OCSP in this scenario
that the Initiator has certain knowledge that the Responder is
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.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Extended Authentication Protocol (EAP)</span>
Another scenario of pressing interest is the use of EAP to
accommodate multiple end users seeking enterprise access to an IPsec
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 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>]. In the event of a conflict between this
document and [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] regarding these illustrations, [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] SHALL
dominate.
<span class="grey">Myers & Tschofenig Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
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 }
OCSP Extensions to EAP in IKEv2
In the EAP scenario, messages (5) through (8) are not relevant to
this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
For the reasons noted above, an OCSP request, as defined in <a href="#section-3.1">Section</a>
<a href="#section-3.1">3.1</a>, is used in place of an OCSP request syntax to trigger production
and transmission of an OCSP response. OCSP, as defined in [<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>],
may contain a nonce request extension to improve security against
replay attacks (see <a href="./rfc2560#section-4.4.1">Section 4.4.1 of [RFC2560]</a> for further details).
The OCSP request defined by this document cannot accommodate nonces.
[<a href="./rfc2560" title=""X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"">RFC2560</a>] deals with this aspect by allowing pre-produced responses.
[<a id="ref-RFC2560">RFC2560</a>] 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.
<span class="grey">Myers & Tschofenig Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
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 [<a href="#ref-IKEv2" title=""Internet Key Exchange (IKEv2) Protocol"">IKEv2</a>] has been acquired from IANA.
Certificate Encoding Value
-------------------- -----
OCSP Content 14
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
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. 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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Normative References</span>
[<a id="ref-IKEv2">IKEv2</a>] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
<a href="./rfc4306">RFC 4306</a>, December 2005.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC2560">RFC2560</a>] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", <a href="./rfc2560">RFC 2560</a>, June 1999.
[<a id="ref-RFC3280">RFC3280</a>] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", <a href="./rfc3280">RFC 3280</a>,
April 2002.
<span class="grey">Myers & Tschofenig Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
Authors' Addresses
Michael Myers
TraceRoute Security LLC
EMail: mmyers@fastq.com
Hannes Tschofenig
Siemens Networks GmbH & Co KG
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
URI: <a href="http://www.tschofenig.com">http://www.tschofenig.com</a>
<span class="grey">Myers & Tschofenig Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4806">RFC 4806</a> OCSP Extensions to IKEv2 February 2007</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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
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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
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
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Myers & Tschofenig Standards Track [Page 11]
</pre>
|
