]>
Commit | Line | Data |
---|---|---|
f91513e3 MW |
1 | |
2 | ||
3 | ||
4 | Network Working Group M. Myers | |
5 | Internet-Draft TraceRoute Security LLC | |
6 | Expires: January 12, 2007 H. Tschofenig | |
7 | Siemens | |
8 | July 11, 2006 | |
9 | ||
10 | ||
11 | OCSP Extensions to IKEv2 | |
12 | draft-myers-ikev2-ocsp-03.txt | |
13 | ||
14 | Status of this Memo | |
15 | ||
16 | By submitting this Internet-Draft, each author represents that any | |
17 | applicable patent or other IPR claims of which he or she is aware | |
18 | have been or will be disclosed, and any of which he or she becomes | |
19 | aware will be disclosed, in accordance with Section 6 of BCP 79. | |
20 | ||
21 | Internet-Drafts are working documents of the Internet Engineering | |
22 | Task Force (IETF), its areas, and its working groups. Note that | |
23 | other groups may also distribute working documents as Internet- | |
24 | Drafts. | |
25 | ||
26 | Internet-Drafts are draft documents valid for a maximum of six months | |
27 | and may be updated, replaced, or obsoleted by other documents at any | |
28 | time. It is inappropriate to use Internet-Drafts as reference | |
29 | material or to cite them other than as "work in progress." | |
30 | ||
31 | The list of current Internet-Drafts can be accessed at | |
32 | http://www.ietf.org/ietf/1id-abstracts.txt. | |
33 | ||
34 | The list of Internet-Draft Shadow Directories can be accessed at | |
35 | http://www.ietf.org/shadow.html. | |
36 | ||
37 | This Internet-Draft will expire on January 12, 2007. | |
38 | ||
39 | Copyright Notice | |
40 | ||
41 | Copyright (C) The Internet Society (2006). | |
42 | ||
43 | Abstract | |
44 | ||
45 | While IKEv2 supports public key based authentication (PKI), the | |
46 | corresponding use of in-band CRLs is problematic due to unbounded CRL | |
47 | size. The size of an OCSP response is however well-bounded and | |
48 | small. This document defines the "OCSP Content" extension to IKEv2. | |
49 | A CERTREQ payload with "OCSP Content" identifies one or more trusted | |
50 | OCSP responders and is a request for inclusion of an OCSP response in | |
51 | the IKEv2 handshake. A cooperative recipient of such a request | |
52 | ||
53 | ||
54 | ||
55 | Myers & Tschofenig Expires January 12, 2007 [Page 1] | |
56 | \f | |
57 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
58 | ||
59 | ||
60 | responds with a CERT payload containing the appropriate OCSP | |
61 | response. This content is recognizable via the same "OCSP Content" | |
62 | identifier. | |
63 | ||
64 | When certificates are used with IKEv2, the communicating peers need a | |
65 | mechanism to determine the revocation status of the peer's | |
66 | certificate. OCSP is one such mechanism. This document applies when | |
67 | OCSP is desired and security policy prevents one of the IKEv2 peers | |
68 | from accessing the relevant OCSP responder directly. Firewalls are | |
69 | often deployed in a manner that prevents such access by IKEv2 peers | |
70 | outside of an enterprise network. | |
71 | ||
72 | ||
73 | Table of Contents | |
74 | ||
75 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |
76 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |
77 | 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 | |
78 | 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5 | |
79 | 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5 | |
80 | 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6 | |
81 | 4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 | |
82 | 4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6 | |
83 | 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 | |
84 | 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8 | |
85 | 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9 | |
86 | 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |
87 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |
88 | 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 | |
89 | 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 | |
90 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | |
91 | Intellectual Property and Copyright Statements . . . . . . . . . . 14 | |
92 | ||
93 | ||
94 | ||
95 | ||
96 | ||
97 | ||
98 | ||
99 | ||
100 | ||
101 | ||
102 | ||
103 | ||
104 | ||
105 | ||
106 | ||
107 | ||
108 | ||
109 | ||
110 | ||
111 | Myers & Tschofenig Expires January 12, 2007 [Page 2] | |
112 | \f | |
113 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
114 | ||
115 | ||
116 | 1. Introduction | |
117 | ||
118 | Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] | |
119 | supports a range of authentication mechanisms, including the use of | |
120 | public key based authentication. Confirmation of certificate | |
121 | reliability is essential to achieve the security assurances public | |
122 | key cryptography provides. One fundamental element of such | |
123 | confirmation is reference to certificate revocation status (see | |
124 | [RFC3280] for additional detail). | |
125 | ||
126 | The historic means of determining certificate revocation status is | |
127 | through the use of Certificate Revocation Lists (CRLs). IKEv2 allows | |
128 | CRLs to be exchanged in-band via the CERT payload. | |
129 | ||
130 | CRLs can however grow unbounded in size. Many real-world examples | |
131 | exist to demonstrate the impracticality of including a multi-megabyte | |
132 | file in an IKE exchange. This constraint is particularly acute in | |
133 | bandwidth limited environments (e.g., mobile communications). The | |
134 | net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) | |
135 | acquisition of these data, should they even be used at all. | |
136 | ||
137 | Reliance on OOB methods can be further complicated if access to | |
138 | revocation data requires use of IPsec (and therefore IKE) to | |
139 | establish secure and authorized access to the CRLs of an IKE | |
140 | participant. Such network access deadlock further contributes to a | |
141 | reduced reliance on certificate revocation status in favor of blind | |
142 | trust. | |
143 | ||
144 | OCSP [RFC2560] offers a useful alternative. The size of an OCSP | |
145 | response is bounded and small and therefore suitable for in-band | |
146 | IKEv2 signaling of a certificate's revocation status. | |
147 | ||
148 | This document defines an extension to IKEv2 that enables the use of | |
149 | OCSP for in-band signaling of certificate revocation status. A new | |
150 | content encoding is defined for use in the CERTREQ and CERT payloads. | |
151 | A CERTREQ payload with "OCSP Content" identifies one or more trusted | |
152 | OCSP responders and is a request for inclusion of an OCSP response in | |
153 | the IKEv2 handshake. A cooperative recipient of such a request | |
154 | responds with a CERT payload containing the appropriate OCSP | |
155 | response. This content is recognizable via the same "OCSP Content" | |
156 | identifier. | |
157 | ||
158 | ||
159 | ||
160 | ||
161 | ||
162 | ||
163 | ||
164 | ||
165 | ||
166 | ||
167 | Myers & Tschofenig Expires January 12, 2007 [Page 3] | |
168 | \f | |
169 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
170 | ||
171 | ||
172 | 2. Terminology | |
173 | ||
174 | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |
175 | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |
176 | document are to be interpreted as described in RFC 2119 [RFC2119]. | |
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 | Myers & Tschofenig Expires January 12, 2007 [Page 4] | |
224 | \f | |
225 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
226 | ||
227 | ||
228 | 3. Extension Definition | |
229 | ||
230 | With reference to Section 3.6 of [IKEv2], the values for the Cert | |
231 | Encoding field of the CERT payload are extended as follows (see also | |
232 | the IANA Considerations section of this document): | |
233 | ||
234 | Certificate Encoding Value | |
235 | -------------------- ----- | |
236 | OCSP Content 14 | |
237 | ||
238 | 3.1. OCSP Request | |
239 | ||
240 | A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ | |
241 | Payload indicates the presence of one or more OCSP Responder | |
242 | certificate hashes in the Certificate Authority field of the CERTREQ | |
243 | payload. | |
244 | ||
245 | The presence of OCSP Content (14) in a CERTREQ message: | |
246 | ||
247 | 1. identifies one or more OCSP responders trusted by the sender; | |
248 | ||
249 | 2. notifies the recipient of sender's support for the OCSP extension | |
250 | to IKEv2; and | |
251 | ||
252 | 3. notifies the recipient of sender's desire to receive OCSP | |
253 | confirmation in a subsequent CERT payload. | |
254 | ||
255 | 3.2. OCSP Response | |
256 | ||
257 | A value of OCSP Content (14) in the Cert Encoding field of a CERT | |
258 | Payload indicates the presence of an OCSP Response in the Certificate | |
259 | Data field of the CERT payload. | |
260 | ||
261 | Correlation between an OCSP Response CERT payload and a corresponding | |
262 | CERT payload carrying a certificate can be achieved by matching the | |
263 | OCSP response CertID field to the certificate. See [RFC2560] for the | |
264 | definition of OCSP response content. | |
265 | ||
266 | ||
267 | ||
268 | ||
269 | ||
270 | ||
271 | ||
272 | ||
273 | ||
274 | ||
275 | ||
276 | ||
277 | ||
278 | ||
279 | Myers & Tschofenig Expires January 12, 2007 [Page 5] | |
280 | \f | |
281 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
282 | ||
283 | ||
284 | 4. Extension Requirements | |
285 | ||
286 | 4.1. OCSP Request | |
287 | ||
288 | Section 3.7 of [IKEv2] allows for the concatenation of trust anchor | |
289 | hashes as the Certification Authority value of a single CERTREQ | |
290 | message. There is no means however to indicate which among those | |
291 | hashes relates to the certificate of a trusted OCSP responder. | |
292 | ||
293 | Therefore an OCSP Request as defined in Section 3.1 above SHALL be | |
294 | transmitted separate from any other CERTREQ payloads in an IKEv2 | |
295 | exchange. | |
296 | ||
297 | Where it is useful to identify more than one trusted OCSP responder, | |
298 | each such identification SHALL be concatenated in a manner identical | |
299 | to the method documented in Section 3.7 of [IKEv2] regarding the | |
300 | assembly of multiple trust anchor hashes. | |
301 | ||
302 | The Certification Authority value in an OCSP Request CERTREQ SHALL be | |
303 | computed and produced in a manner identical to that of trust anchor | |
304 | hashes as documented in Section 3.7 of [IKEv2]. | |
305 | ||
306 | Upon receipt of an OCSP Response CERT payload corresponding to a | |
307 | prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the | |
308 | OCSP response into path validation logic defined by [RFC3280]. | |
309 | ||
310 | The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if | |
311 | either: | |
312 | ||
313 | 1. the corresponding OCSP Response CERT payload indicates that the | |
314 | subject certificate is revoked; OR | |
315 | ||
316 | 2. the corresponding OCSP Response CERT payload indicates an OCSP | |
317 | error (e.g., malformedRequest, internalError, tryLater, | |
318 | sigRequired, unauthorized, etc.). | |
319 | ||
320 | The sender of an OCSP Request CERTREQ SHOULD accept an IKEv2 exchange | |
321 | if a corresponding OCSP Response CERT payload is not received. This | |
322 | might be an indication that this OCSP extension is not supported. | |
323 | ||
324 | 4.2. OCSP Response | |
325 | ||
326 | Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD | |
327 | acquire the related OCSP-based assertion and produce and transmit an | |
328 | OCSP Response CERT payload corresponding to the certificate needed to | |
329 | verify its signature on IKEv2 payloads. | |
330 | ||
331 | An OCSP Response CERT payload SHALL be transmitted separate from any | |
332 | ||
333 | ||
334 | ||
335 | Myers & Tschofenig Expires January 12, 2007 [Page 6] | |
336 | \f | |
337 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
338 | ||
339 | ||
340 | other CERT payload in an IKEv2 exchange. | |
341 | ||
342 | The means by which an OCSP response may be acquired for production of | |
343 | an OCSP Response CERT payload is out of scope of this document. | |
344 | ||
345 | The structure and encoding of the Certificate Data field of an OCSP | |
346 | Response CERT payload SHALL be identical to that defined in | |
347 | [RFC2560]. | |
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 | Myers & Tschofenig Expires January 12, 2007 [Page 7] | |
392 | \f | |
393 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
394 | ||
395 | ||
396 | 5. Examples and Discussion | |
397 | ||
398 | This section shows the standard IKEv2 message examples with both | |
399 | peers, the initiator and the responder, using public key based | |
400 | authentication, CERTREQ and CERT payloads. The first instance | |
401 | corresponds to Section 1.2 of [IKEv2], the illustrations of which are | |
402 | reproduced below for reference. | |
403 | ||
404 | 5.1. Peer to Peer | |
405 | ||
406 | Application of the IKEv2 extensions defined in this document to the | |
407 | peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as | |
408 | follows. Messages are numbered for ease of reference. | |
409 | ||
410 | ||
411 | Initiator Responder | |
412 | ----------- ----------- | |
413 | (1) HDR, SAi1, KEi, Ni --> | |
414 | ||
415 | (2) <-- HDR, SAr1, KEr, Nr, | |
416 | CERTREQ(OCSP Request) | |
417 | (3) HDR, SK {IDi, CERT(certificate),--> | |
418 | CERT(OCSP Response), | |
419 | CERTREQ(OCSP Request), | |
420 | [IDr,] AUTH, SAi2, TSi, TSr} | |
421 | ||
422 | (4) <-- HDR, SK {IDr, | |
423 | CERT(certificate), | |
424 | CERT(OCSP Response), | |
425 | AUTH, SAr2, TSi, TSr} | |
426 | ||
427 | In (2) Responder sends an OCSP Request CERTREQ payload identifying | |
428 | one or more OCSP responders trusted by Responder. In response, | |
429 | Initiator sends in (3) both a CERT payload carrying its certificate | |
430 | and an OCSP Response CERT payload covering that certificate. In (3) | |
431 | Initiator also requests an OCSP response via the OCSP Request CERTREQ | |
432 | payload. In (4) Responder returns its certificate and a separate | |
433 | OCSP Response CERT payload covering that certificate. | |
434 | ||
435 | It is important to note that in this scenario, the Responder in (2) | |
436 | does not yet possess the Initiator's certificate and therefore cannot | |
437 | form an OCSP request. [RFC2560] allows for pre-produced responses. | |
438 | It is thus easily inferred that OCSP responses can be produced in the | |
439 | absence of a corresponding request (OCSP nonces notwithstanding). In | |
440 | such instances OCSP Requests are simply index values into these data. | |
441 | ||
442 | It is also important in extending IKEv2 towards OCSP in this scenario | |
443 | that the Initiator has certain knowledge that the Responder is | |
444 | ||
445 | ||
446 | ||
447 | Myers & Tschofenig Expires January 12, 2007 [Page 8] | |
448 | \f | |
449 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
450 | ||
451 | ||
452 | capable of and willing to participate in the extension. Yet the | |
453 | Responder will only trust one or more OCSP responder signatures. | |
454 | These factors motivate the definition of OCSP Responder Hash | |
455 | extension. | |
456 | ||
457 | 5.2. Extended Authentication Protocol (EAP) | |
458 | ||
459 | Another scenario of pressing interest is the use of EAP to | |
460 | accommodate multiple end users seeking enterprise access to an IPsec | |
461 | gateway. As with the preceding section, the following illustration | |
462 | is extracted from [IKEv2]. In the event of a conflict between this | |
463 | document and[IKEv2] regarding these illustrations, [IKEv2] SHALL | |
464 | dominate. | |
465 | ||
466 | ||
467 | Initiator Responder | |
468 | ----------- ----------- | |
469 | (1) HDR, SAi1, KEi, Ni --> | |
470 | (2) <-- HDR, SAr1, KEr, Nr | |
471 | (3) HDR, SK {IDi, --> | |
472 | CERTREQ(OCSP Request), | |
473 | [IDr,] AUTH, SAi2, TSi, TSr} | |
474 | (4) <-- HDR, SK {IDr, | |
475 | CERT(certificate), | |
476 | CERT(OCSP Response), | |
477 | AUTH, EAP} | |
478 | (5) HDR, SK {EAP} --> | |
479 | ||
480 | (6) <-- HDR, SK {EAP (success)} | |
481 | ||
482 | (7) HDR, SK {AUTH} --> | |
483 | ||
484 | (8) <-- HDR, SK {AUTH, SAr2, TSi, | |
485 | TSr } | |
486 | ||
487 | In the EAP scenario, messages (5) through (8) are not relevant to | |
488 | this document. Note that while [IKEv2] allows for the optional | |
489 | inclusion of a CERTREQ in (2), this document asserts no need of its | |
490 | use. It is assumed that environments including this optional payload | |
491 | and yet wishing to implement the OCSP extension to IKEv2 are | |
492 | sufficiently robust as to accommodate this redundant payload. | |
493 | ||
494 | ||
495 | ||
496 | ||
497 | ||
498 | ||
499 | ||
500 | ||
501 | ||
502 | ||
503 | Myers & Tschofenig Expires January 12, 2007 [Page 9] | |
504 | \f | |
505 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
506 | ||
507 | ||
508 | 6. Security Considerations | |
509 | ||
510 | For the reasons noted above, OCSP request as defined in Section 3.1 | |
511 | is used in place of OCSP request syntax to trigger production and | |
512 | transmission of an OCSP response. OCSP as defined in [RFC2560] may | |
513 | contain a nonce request extension to improve security against replay | |
514 | attacks (see Section 4.4.1 of [RFC2560] for further details). The | |
515 | OCSP Request defined by this document cannot accommodate nonces. | |
516 | [RFC2560] deals with this aspect by allowing pre-produced responses. | |
517 | ||
518 | [RFC2560] points to this replay vulnerability and indicates: "The use | |
519 | of precomputed responses allows replay attacks in which an old (good) | |
520 | response is replayed prior to its expiration date but after the | |
521 | certificate has been revoked. Deployments of OCSP should carefully | |
522 | evaluate the benefit of precomputed responses against the probability | |
523 | of a replay attack and the costs associated with its successful | |
524 | execution." Nodes SHOULD make the required freshness of an OCSP | |
525 | Response configurable. | |
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 | Myers & Tschofenig Expires January 12, 2007 [Page 10] | |
560 | \f | |
561 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
562 | ||
563 | ||
564 | 7. IANA Considerations | |
565 | ||
566 | This document defines one new field type for use in the IKEv2 Cert | |
567 | Encoding field of the Certificate Payload format. Official | |
568 | assignment of the "OCSP Content" extension to the Cert Encoding table | |
569 | of Section 3.6 of [IKEv2] needs to be acquired from IANA. | |
570 | ||
571 | Certificate Encoding Value | |
572 | -------------------- ----- | |
573 | OCSP Content 14 | |
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 | ||
614 | ||
615 | Myers & Tschofenig Expires January 12, 2007 [Page 11] | |
616 | \f | |
617 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
618 | ||
619 | ||
620 | 8. Acknowledgements | |
621 | ||
622 | The authors would like to thank Russ Housley for his support. | |
623 | Additionally, we would like to thank Pasi Eronen, Nicolas Williams, | |
624 | Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their | |
625 | review. | |
626 | ||
627 | 9. Normative References | |
628 | ||
629 | [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", | |
630 | RFC 4306, December 2005. | |
631 | ||
632 | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |
633 | Requirement Levels", BCP 14, RFC 2119, March 1997. | |
634 | ||
635 | [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. | |
636 | Adams, "X.509 Internet Public Key Infrastructure Online | |
637 | Certificate Status Protocol - OCSP", RFC 2560, June 1999. | |
638 | ||
639 | [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet | |
640 | X.509 Public Key Infrastructure Certificate and | |
641 | Certificate Revocation List (CRL) Profile", RFC 3280, | |
642 | April 2002. | |
643 | ||
644 | ||
645 | ||
646 | ||
647 | ||
648 | ||
649 | ||
650 | ||
651 | ||
652 | ||
653 | ||
654 | ||
655 | ||
656 | ||
657 | ||
658 | ||
659 | ||
660 | ||
661 | ||
662 | ||
663 | ||
664 | ||
665 | ||
666 | ||
667 | ||
668 | ||
669 | ||
670 | ||
671 | Myers & Tschofenig Expires January 12, 2007 [Page 12] | |
672 | \f | |
673 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
674 | ||
675 | ||
676 | Authors' Addresses | |
677 | ||
678 | Michael Myers | |
679 | TraceRoute Security LLC | |
680 | ||
681 | ||
682 | Email: mmyers@fastq.com | |
683 | ||
684 | ||
685 | Hannes Tschofenig | |
686 | Siemens | |
687 | Otto-Hahn-Ring 6 | |
688 | Munich, Bavaria 81739 | |
689 | Germany | |
690 | ||
691 | Email: Hannes.Tschofenig@siemens.com | |
692 | URI: http://www.tschofenig.com | |
693 | ||
694 | ||
695 | ||
696 | ||
697 | ||
698 | ||
699 | ||
700 | ||
701 | ||
702 | ||
703 | ||
704 | ||
705 | ||
706 | ||
707 | ||
708 | ||
709 | ||
710 | ||
711 | ||
712 | ||
713 | ||
714 | ||
715 | ||
716 | ||
717 | ||
718 | ||
719 | ||
720 | ||
721 | ||
722 | ||
723 | ||
724 | ||
725 | ||
726 | ||
727 | Myers & Tschofenig Expires January 12, 2007 [Page 13] | |
728 | \f | |
729 | Internet-Draft OCSP Extensions to IKEv2 July 2006 | |
730 | ||
731 | ||
732 | Intellectual Property Statement | |
733 | ||
734 | The IETF takes no position regarding the validity or scope of any | |
735 | Intellectual Property Rights or other rights that might be claimed to | |
736 | pertain to the implementation or use of the technology described in | |
737 | this document or the extent to which any license under such rights | |
738 | might or might not be available; nor does it represent that it has | |
739 | made any independent effort to identify any such rights. Information | |
740 | on the procedures with respect to rights in RFC documents can be | |
741 | found in BCP 78 and BCP 79. | |
742 | ||
743 | Copies of IPR disclosures made to the IETF Secretariat and any | |
744 | assurances of licenses to be made available, or the result of an | |
745 | attempt made to obtain a general license or permission for the use of | |
746 | such proprietary rights by implementers or users of this | |
747 | specification can be obtained from the IETF on-line IPR repository at | |
748 | http://www.ietf.org/ipr. | |
749 | ||
750 | The IETF invites any interested party to bring to its attention any | |
751 | copyrights, patents or patent applications, or other proprietary | |
752 | rights that may cover technology that may be required to implement | |
753 | this standard. Please address the information to the IETF at | |
754 | ietf-ipr@ietf.org. | |
755 | ||
756 | ||
757 | Disclaimer of Validity | |
758 | ||
759 | This document and the information contained herein are provided on an | |
760 | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS | |
761 | OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |
762 | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |
763 | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE | |
764 | INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED | |
765 | WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |
766 | ||
767 | ||
768 | Copyright Statement | |
769 | ||
770 | Copyright (C) The Internet Society (2006). This document is subject | |
771 | to the rights, licenses and restrictions contained in BCP 78, and | |
772 | except as set forth therein, the authors retain all their rights. | |
773 | ||
774 | ||
775 | Acknowledgment | |
776 | ||
777 | Funding for the RFC Editor function is currently provided by the | |
778 | Internet Society. | |
779 | ||
780 | ||
781 | ||
782 | ||
783 | Myers & Tschofenig Expires January 12, 2007 [Page 14] | |
784 | \f | |
785 |