restructured file layout
[strongswan.git] / doc / standards / draft-myers-ikev2-ocsp-03.txt
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