]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
1 | |
2 | ||
3 | ||
f91513e3 | 4 | |
f91513e3 | 5 | |
f91513e3 | 6 | |
d6bd078a MW |
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 | |
11 | February 2007 | |
f91513e3 | 12 | |
f91513e3 | 13 | |
d6bd078a | 14 | Online Certificate Status Protocol (OCSP) Extensions to IKEv2 |
f91513e3 | 15 | |
d6bd078a | 16 | Status of This Memo |
f91513e3 | 17 | |
d6bd078a MW |
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. | |
f91513e3 MW |
23 | |
24 | Copyright Notice | |
25 | ||
d6bd078a | 26 | Copyright (C) The IETF Trust (2006). |
f91513e3 MW |
27 | |
28 | Abstract | |
29 | ||
d6bd078a MW |
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. | |
f91513e3 MW |
41 | |
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. | |
49 | ||
50 | ||
f91513e3 MW |
51 | |
52 | ||
53 | ||
54 | ||
55 | ||
56 | ||
57 | ||
d6bd078a MW |
58 | Myers & Tschofenig Standards Track [Page 1] |
59 | \f | |
60 | RFC 4806 OCSP Extensions to IKEv2 February 2007 | |
f91513e3 MW |
61 | |
62 | ||
d6bd078a | 63 | Table of Contents |
f91513e3 | 64 | |
d6bd078a MW |
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 | |
f91513e3 MW |
80 | |
81 | 1. Introduction | |
82 | ||
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 | |
d6bd078a MW |
86 | reliability is essential in order to achieve the security assurances |
87 | public key cryptography provides. One fundamental element of such | |
f91513e3 MW |
88 | confirmation is reference to certificate revocation status (see |
89 | [RFC3280] for additional detail). | |
90 | ||
d6bd078a | 91 | The traditional means of determining certificate revocation status is |
f91513e3 MW |
92 | through the use of Certificate Revocation Lists (CRLs). IKEv2 allows |
93 | CRLs to be exchanged in-band via the CERT payload. | |
94 | ||
d6bd078a | 95 | However, CRLs can grow unbounded in size. Many real-world examples |
f91513e3 MW |
96 | exist to demonstrate the impracticality of including a multi-megabyte |
97 | file in an IKE exchange. This constraint is particularly acute in | |
d6bd078a | 98 | bandwidth-limited environments (e.g., mobile communications). The |
f91513e3 MW |
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. | |
101 | ||
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 | |
d6bd078a MW |
106 | reduced reliance on the status of certificate revocations in favor of |
107 | blind trust. | |
108 | ||
109 | ||
110 | ||
111 | ||
112 | ||
113 | ||
114 | Myers & Tschofenig Standards Track [Page 2] | |
115 | \f | |
116 | RFC 4806 OCSP Extensions to IKEv2 February 2007 | |
117 | ||
f91513e3 MW |
118 | |
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. | |
122 | ||
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. | |
d6bd078a | 126 | A CERTREQ payload with "OCSP Content" identifies zero or more trusted |
f91513e3 MW |
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" | |
131 | identifier. | |
132 | ||
f91513e3 MW |
133 | 2. Terminology |
134 | ||
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]. | |
138 | ||
d6bd078a | 139 | This document defines the following terms: |
f91513e3 | 140 | |
d6bd078a | 141 | OCSP request: |
f91513e3 | 142 | |
d6bd078a MW |
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. | |
f91513e3 | 146 | |
d6bd078a | 147 | OCSP response: |
f91513e3 | 148 | |
d6bd078a MW |
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. | |
f91513e3 | 152 | |
d6bd078a | 153 | OCSP responder: |
f91513e3 | 154 | |
d6bd078a MW |
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. | |
f91513e3 MW |
159 | |
160 | ||
161 | ||
162 | ||
163 | ||
164 | ||
165 | ||
166 | ||
167 | ||
168 | ||
169 | ||
d6bd078a | 170 | Myers & Tschofenig Standards Track [Page 3] |
f91513e3 | 171 | \f |
d6bd078a | 172 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
f91513e3 MW |
173 | |
174 | ||
175 | 3. Extension Definition | |
176 | ||
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): | |
180 | ||
181 | Certificate Encoding Value | |
182 | -------------------- ----- | |
183 | OCSP Content 14 | |
184 | ||
185 | 3.1. OCSP Request | |
186 | ||
187 | A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ | |
d6bd078a | 188 | Payload indicates the presence of zero or more OCSP responder |
f91513e3 | 189 | certificate hashes in the Certificate Authority field of the CERTREQ |
d6bd078a MW |
190 | payload. Section 2.2 of [RFC2560] defines responses, which belong to |
191 | one of the following three groups: | |
192 | ||
193 | (a) the CA who issued the certificate | |
194 | ||
195 | (b) a Trusted Responder whose public key is trusted by the requester | |
196 | ||
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 | |
200 | CA | |
201 | ||
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). | |
f91513e3 MW |
209 | |
210 | The presence of OCSP Content (14) in a CERTREQ message: | |
211 | ||
d6bd078a | 212 | 1. identifies zero or more OCSP responders trusted by the sender; |
f91513e3 MW |
213 | |
214 | 2. notifies the recipient of sender's support for the OCSP extension | |
215 | to IKEv2; and | |
216 | ||
217 | 3. notifies the recipient of sender's desire to receive OCSP | |
218 | confirmation in a subsequent CERT payload. | |
219 | ||
f91513e3 MW |
220 | |
221 | ||
222 | ||
223 | ||
224 | ||
225 | ||
d6bd078a MW |
226 | Myers & Tschofenig Standards Track [Page 4] |
227 | \f | |
228 | RFC 4806 OCSP Extensions to IKEv2 February 2007 | |
f91513e3 MW |
229 | |
230 | ||
d6bd078a | 231 | 3.2. OCSP Response |
f91513e3 | 232 | |
d6bd078a MW |
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. | |
f91513e3 | 236 | |
d6bd078a MW |
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. | |
f91513e3 MW |
241 | |
242 | 4. Extension Requirements | |
243 | ||
d6bd078a | 244 | 4.1. Request for OCSP Support |
f91513e3 MW |
245 | |
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 | |
d6bd078a MW |
249 | hashes, if present, relates to the certificate of a trusted OCSP |
250 | responder. | |
f91513e3 | 251 | |
d6bd078a | 252 | Therefore, an OCSP request, as defined in Section 3.1 above, is |
f91513e3 MW |
253 | transmitted separate from any other CERTREQ payloads in an IKEv2 |
254 | exchange. | |
255 | ||
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. | |
260 | ||
d6bd078a | 261 | The Certification Authority value in an OCSP request CERTREQ SHALL be |
f91513e3 MW |
262 | computed and produced in a manner identical to that of trust anchor |
263 | hashes as documented in Section 3.7 of [IKEv2]. | |
264 | ||
d6bd078a MW |
265 | Upon receipt of an OCSP response CERT payload corresponding to a |
266 | prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the | |
f91513e3 MW |
267 | OCSP response into path validation logic defined by [RFC3280]. |
268 | ||
d6bd078a MW |
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 | |
276 | some other means. | |
f91513e3 | 277 | |
f91513e3 | 278 | |
f91513e3 | 279 | |
f91513e3 | 280 | |
f91513e3 | 281 | |
d6bd078a | 282 | Myers & Tschofenig Standards Track [Page 5] |
f91513e3 | 283 | \f |
d6bd078a | 284 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
f91513e3 MW |
285 | |
286 | ||
d6bd078a | 287 | 4.2. Response to OCSP Support |
f91513e3 | 288 | |
d6bd078a MW |
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. | |
f91513e3 | 293 | |
d6bd078a MW |
294 | An OCSP response CERT payload is transmitted separate from any other |
295 | CERT payload in an IKEv2 exchange. | |
f91513e3 | 296 | |
d6bd078a MW |
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. | |
f91513e3 | 299 | |
d6bd078a MW |
300 | The Certificate Data field of an OCSP response CERT payload SHALL |
301 | contain a DER-encoded OCSPResponse structure as defined in [RFC2560]. | |
f91513e3 MW |
302 | |
303 | 5. Examples and Discussion | |
304 | ||
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. | |
310 | ||
311 | 5.1. Peer to Peer | |
312 | ||
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. | |
316 | ||
f91513e3 MW |
317 | Initiator Responder |
318 | ----------- ----------- | |
319 | (1) HDR, SAi1, KEi, Ni --> | |
320 | ||
321 | (2) <-- HDR, SAr1, KEr, Nr, | |
322 | CERTREQ(OCSP Request) | |
323 | (3) HDR, SK {IDi, CERT(certificate),--> | |
324 | CERT(OCSP Response), | |
325 | CERTREQ(OCSP Request), | |
326 | [IDr,] AUTH, SAi2, TSi, TSr} | |
327 | ||
328 | (4) <-- HDR, SK {IDr, | |
329 | CERT(certificate), | |
330 | CERT(OCSP Response), | |
331 | AUTH, SAr2, TSi, TSr} | |
332 | ||
d6bd078a | 333 | OCSP Extensions to Baseline IKEv2 |
f91513e3 | 334 | |
f91513e3 MW |
335 | |
336 | ||
337 | ||
d6bd078a | 338 | Myers & Tschofenig Standards Track [Page 6] |
f91513e3 | 339 | \f |
d6bd078a | 340 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
f91513e3 MW |
341 | |
342 | ||
d6bd078a MW |
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. | |
350 | ||
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). | |
359 | ||
360 | It is also important in extending IKEv2 toward OCSP in this scenario | |
361 | that the Initiator has certain knowledge that the Responder is | |
f91513e3 MW |
362 | capable of and willing to participate in the extension. Yet the |
363 | Responder will only trust one or more OCSP responder signatures. | |
d6bd078a | 364 | These factors motivate the definition of OCSP responder hash |
f91513e3 MW |
365 | extension. |
366 | ||
367 | 5.2. Extended Authentication Protocol (EAP) | |
368 | ||
369 | Another scenario of pressing interest is the use of EAP to | |
370 | accommodate multiple end users seeking enterprise access to an IPsec | |
d6bd078a MW |
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 | |
f91513e3 | 375 | is extracted from [IKEv2]. In the event of a conflict between this |
d6bd078a | 376 | document and [IKEv2] regarding these illustrations, [IKEv2] SHALL |
f91513e3 MW |
377 | dominate. |
378 | ||
379 | ||
d6bd078a MW |
380 | |
381 | ||
382 | ||
383 | ||
384 | ||
385 | ||
386 | ||
387 | ||
388 | ||
389 | ||
390 | ||
391 | ||
392 | ||
393 | ||
394 | Myers & Tschofenig Standards Track [Page 7] | |
395 | \f | |
396 | RFC 4806 OCSP Extensions to IKEv2 February 2007 | |
397 | ||
398 | ||
f91513e3 MW |
399 | Initiator Responder |
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, | |
407 | CERT(certificate), | |
408 | CERT(OCSP Response), | |
409 | AUTH, EAP} | |
410 | (5) HDR, SK {EAP} --> | |
411 | ||
412 | (6) <-- HDR, SK {EAP (success)} | |
413 | ||
414 | (7) HDR, SK {AUTH} --> | |
415 | ||
416 | (8) <-- HDR, SK {AUTH, SAr2, TSi, | |
417 | TSr } | |
418 | ||
d6bd078a | 419 | OCSP Extensions to EAP in IKEv2 |
f91513e3 | 420 | |
d6bd078a MW |
421 | In the EAP scenario, messages (5) through (8) are not relevant to |
422 | this document. | |
f91513e3 MW |
423 | |
424 | 6. Security Considerations | |
425 | ||
d6bd078a MW |
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. | |
f91513e3 MW |
432 | [RFC2560] deals with this aspect by allowing pre-produced responses. |
433 | ||
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 | |
d6bd078a | 441 | response configurable. |
f91513e3 MW |
442 | |
443 | ||
444 | ||
445 | ||
446 | ||
447 | ||
448 | ||
449 | ||
d6bd078a | 450 | Myers & Tschofenig Standards Track [Page 8] |
f91513e3 | 451 | \f |
d6bd078a | 452 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
f91513e3 MW |
453 | |
454 | ||
455 | 7. IANA Considerations | |
456 | ||
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 | |
d6bd078a | 460 | of Section 3.6 of [IKEv2] has been acquired from IANA. |
f91513e3 MW |
461 | |
462 | Certificate Encoding Value | |
463 | -------------------- ----- | |
464 | OCSP Content 14 | |
465 | ||
f91513e3 MW |
466 | 8. Acknowledgements |
467 | ||
468 | The authors would like to thank Russ Housley for his support. | |
469 | Additionally, we would like to thank Pasi Eronen, Nicolas Williams, | |
d6bd078a MW |
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. | |
f91513e3 MW |
474 | |
475 | 9. Normative References | |
476 | ||
477 | [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | |
478 | RFC 4306, December 2005. | |
479 | ||
480 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
481 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
482 | ||
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. | |
486 | ||
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, | |
490 | April 2002. | |
491 | ||
492 | ||
493 | ||
494 | ||
495 | ||
496 | ||
497 | ||
498 | ||
499 | ||
500 | ||
501 | ||
502 | ||
503 | ||
504 | ||
505 | ||
d6bd078a | 506 | Myers & Tschofenig Standards Track [Page 9] |
f91513e3 | 507 | \f |
d6bd078a | 508 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
f91513e3 MW |
509 | |
510 | ||
511 | Authors' Addresses | |
512 | ||
513 | Michael Myers | |
514 | TraceRoute Security LLC | |
515 | ||
d6bd078a | 516 | EMail: mmyers@fastq.com |
f91513e3 MW |
517 | |
518 | ||
519 | Hannes Tschofenig | |
d6bd078a | 520 | Siemens Networks GmbH & Co KG |
f91513e3 MW |
521 | Otto-Hahn-Ring 6 |
522 | Munich, Bavaria 81739 | |
523 | Germany | |
524 | ||
d6bd078a | 525 | EMail: Hannes.Tschofenig@siemens.com |
f91513e3 MW |
526 | URI: http://www.tschofenig.com |
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 | ||
d6bd078a MW |
561 | |
562 | Myers & Tschofenig Standards Track [Page 10] | |
f91513e3 | 563 | \f |
d6bd078a MW |
564 | RFC 4806 OCSP Extensions to IKEv2 February 2007 |
565 | ||
f91513e3 | 566 | |
d6bd078a | 567 | Full Copyright Statement |
f91513e3 | 568 | |
d6bd078a MW |
569 | Copyright (C) The IETF Trust (2007). |
570 | ||
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. | |
574 | ||
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. | |
582 | ||
583 | Intellectual Property | |
f91513e3 MW |
584 | |
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. | |
593 | ||
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. | |
600 | ||
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 | |
605 | ietf-ipr@ietf.org. | |
606 | ||
d6bd078a | 607 | Acknowledgement |
f91513e3 | 608 | |
d6bd078a MW |
609 | Funding for the RFC Editor function is currently provided by the |
610 | Internet Society. | |
f91513e3 MW |
611 | |
612 | ||
f91513e3 | 613 | |
f91513e3 MW |
614 | |
615 | ||
616 | ||
617 | ||
d6bd078a | 618 | Myers & Tschofenig Standards Track [Page 11] |
f91513e3 | 619 | \f |