doc/standards/rfc4806.txt

   1
   2
   3
   4
   5
   6
   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
  12
  13
  14      Online Certificate Status Protocol (OCSP) Extensions to IKEv2
  15
  16 Status of This Memo
  17
  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.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The IETF Trust (2006).
  27
  28 Abstract
  29
  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.
  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
  51
  52
  53
  54
  55
  56
  57
  58 Myers & Tschofenig          Standards Track                     [Page 1]
  59 \f
  60 RFC 4806                OCSP Extensions to IKEv2           February 2007
  61
  62
  63 Table of Contents
  64
  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
  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
  86    reliability is essential in order to achieve the security assurances
  87    public key cryptography provides.  One fundamental element of such
  88    confirmation is reference to certificate revocation status (see
  89    [RFC3280] for additional detail).
  90
  91    The traditional means of determining certificate revocation status is
  92    through the use of Certificate Revocation Lists (CRLs).  IKEv2 allows
  93    CRLs to be exchanged in-band via the CERT payload.
  94
  95    However, CRLs can grow unbounded in size.  Many real-world examples
  96    exist to demonstrate the impracticality of including a multi-megabyte
  97    file in an IKE exchange.  This constraint is particularly acute in
  98    bandwidth-limited environments (e.g., mobile communications).  The
  99    net effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
 100    acquisition of these data, should they even be used at all.
 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
 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
 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.
 126    A CERTREQ payload with "OCSP Content" identifies zero or more trusted
 127    OCSP responders and is a request for inclusion of an OCSP response in
 128    the IKEv2 handshake.  A cooperative recipient of such a request
 129    responds with a CERT payload containing the appropriate OCSP
 130    response.  This content is recognizable via the same "OCSP Content"
 131    identifier.
 132
 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
 139    This document defines the following terms:
 140
 141    OCSP request:
 142
 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.
 146
 147    OCSP response:
 148
 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.
 152
 153    OCSP responder:
 154
 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.
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Myers & Tschofenig          Standards Track                     [Page 3]
 171 \f
 172 RFC 4806                OCSP Extensions to IKEv2           February 2007
 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
 188    Payload indicates the presence of zero or more OCSP responder
 189    certificate hashes in the Certificate Authority field of the CERTREQ
 190    payload.  Section 2.2 of [RFC2560] defines responses, which belong to
 191    one of the following three groups:
 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).
 209
 210    The presence of OCSP Content (14) in a CERTREQ message:
 211
 212    1.  identifies zero or more OCSP responders trusted by the sender;
 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
 220
 221
 222
 223
 224
 225
 226 Myers & Tschofenig          Standards Track                     [Page 4]
 227 \f
 228 RFC 4806                OCSP Extensions to IKEv2           February 2007
 229
 230
 231 3.2.  OCSP Response
 232
 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.
 236
 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.
 241
 242 4.  Extension Requirements
 243
 244 4.1.  Request for OCSP Support
 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
 249    hashes, if present, relates to the certificate of a trusted OCSP
 250    responder.
 251
 252    Therefore, an OCSP request, as defined in Section 3.1 above, is
 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
 261    The Certification Authority value in an OCSP request CERTREQ SHALL be
 262    computed and produced in a manner identical to that of trust anchor
 263    hashes as documented in Section 3.7 of [IKEv2].
 264
 265    Upon receipt of an OCSP response CERT payload corresponding to a
 266    prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the
 267    OCSP response into path validation logic defined by [RFC3280].
 268
 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.
 277
 278
 279
 280
 281
 282 Myers & Tschofenig          Standards Track                     [Page 5]
 283 \f
 284 RFC 4806                OCSP Extensions to IKEv2           February 2007
 285
 286
 287 4.2.  Response to OCSP Support
 288
 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.
 293
 294    An OCSP response CERT payload is transmitted separate from any other
 295    CERT payload in an IKEv2 exchange.
 296
 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.
 299
 300    The Certificate Data field of an OCSP response CERT payload SHALL
 301    contain a DER-encoded OCSPResponse structure as defined in [RFC2560].
 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
 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
 333                      OCSP Extensions to Baseline IKEv2
 334
 335
 336
 337
 338 Myers & Tschofenig          Standards Track                     [Page 6]
 339 \f
 340 RFC 4806                OCSP Extensions to IKEv2           February 2007
 341
 342
 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
 362    capable of and willing to participate in the extension.  Yet the
 363    Responder will only trust one or more OCSP responder signatures.
 364    These factors motivate the definition of OCSP responder hash
 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
 371    gateway.  Note that OCSP is used for the certificate status check of
 372    the server side IKEv2 certificate and not for certificates that may
 373    be used within EAP methods (either by the EAP peer or the EAP
 374    server).  As with the preceding section, the following illustration
 375    is extracted from [IKEv2].  In the event of a conflict between this
 376    document and [IKEv2] regarding these illustrations, [IKEv2] SHALL
 377    dominate.
 378
 379
 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
 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
 419                       OCSP Extensions to EAP in IKEv2
 420
 421    In the EAP scenario, messages (5) through (8) are not relevant to
 422    this document.
 423
 424 6.  Security Considerations
 425
 426    For the reasons noted above, an OCSP request, as defined in Section
 427    3.1, is used in place of an OCSP request syntax to trigger production
 428    and transmission of an OCSP response.  OCSP, as defined in [RFC2560],
 429    may contain a nonce request extension to improve security against
 430    replay attacks (see Section 4.4.1 of [RFC2560] for further details).
 431    The OCSP request defined by this document cannot accommodate nonces.
 432    [RFC2560] deals with this aspect by allowing pre-produced responses.
 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
 441    response configurable.
 442
 443
 444
 445
 446
 447
 448
 449
 450 Myers & Tschofenig          Standards Track                     [Page 8]
 451 \f
 452 RFC 4806                OCSP Extensions to IKEv2           February 2007
 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
 460    of Section 3.6 of [IKEv2] has been acquired from IANA.
 461
 462                Certificate Encoding               Value
 463                --------------------               -----
 464                OCSP Content                        14
 465
 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,
 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.
 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
 506 Myers & Tschofenig          Standards Track                     [Page 9]
 507 \f
 508 RFC 4806                OCSP Extensions to IKEv2           February 2007
 509
 510
 511 Authors' Addresses
 512
 513    Michael Myers
 514    TraceRoute Security LLC
 515
 516    EMail: mmyers@fastq.com
 517
 518
 519    Hannes Tschofenig
 520    Siemens Networks GmbH & Co KG
 521    Otto-Hahn-Ring 6
 522    Munich, Bavaria  81739
 523    Germany
 524
 525    EMail: Hannes.Tschofenig@siemens.com
 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
 561
 562 Myers & Tschofenig          Standards Track                    [Page 10]
 563 \f
 564 RFC 4806                OCSP Extensions to IKEv2           February 2007
 565
 566
 567 Full Copyright Statement
 568
 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
 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
 607 Acknowledgement
 608
 609    Funding for the RFC Editor function is currently provided by the
 610    Internet Society.
 611
 612
 613
 614
 615
 616
 617
 618 Myers & Tschofenig          Standards Track                    [Page 11]
 619 \f