third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-00.txt

   1
   2 NETWORK WORKING GROUP                                             L. Zhu
   3 Internet-Draft                                             K. Jaganathan
   4 Expires: February 8, 2005                          Microsoft Corporation
   5                                                              N. Williams
   6                                                         Sun Microsystems
   7                                                          August 10, 2004
   8
   9
  10                         OCSP Support for PKINIT
  11                     draft-ietf-krb-wg-ocsp-for-pkinit-00
  12
  13 Status of this Memo
  14
  15    This document is an Internet-Draft and is subject to all provisions
  16    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
  17    author represents that any applicable patent or other IPR claims of
  18    which he or she is aware have been or will be disclosed, and any of
  19    which he or she become aware will be disclosed, in accordance with
  20    RFC 3668.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as
  25    Internet-Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt.
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    This Internet-Draft will expire on February 8, 2005.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The Internet Society (2004).
  43
  44 Abstract
  45
  46    This document defines a mechanism to enable in-band transmission of
  47    OCSP responses.  These responses are used to verify the validity of
  48    the certificates used in PKINIT - the Kerberos Version 5 extension
  49    that provides for the use of public key cryptography.
  50
  51
  52
  53
  54 Zhu, et al.             Expires February 8, 2005                [Page 1]
  55 \f
  56 Internet-Draft          OCSP Support for PKINIT              August 2004
  57
  58
  59 Table of Contents
  60
  61    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
  62    2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
  63    3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
  64    4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
  65    5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
  66    6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  67         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
  68         Intellectual Property and Copyright Statements . . . . . . . . 9
  69
  70
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Zhu, et al.             Expires February 8, 2005                [Page 2]
 111 \f
 112 Internet-Draft          OCSP Support for PKINIT              August 2004
 113
 114
 115 1.  Introduction
 116
 117    Online Certificate Status Protocol (OCSP) [RFC2560] enables
 118    applications to obtain timely information regarding the revocation
 119    status of a certificate.  Because OCSP responses are well-bounded and
 120    small in size, constrained clients may wish to use OCSP to check the
 121    validity of KDC certificates in order to avoid transmission of large
 122    Certificate Revocation Lists (CRLs) and therefore save bandwidth on
 123    constrained networks.
 124
 125    This document defines a pre-authentication type [CLARIFICATIONS],
 126    where the client and the KDC MAY piggyback OCSP responses for
 127    certificates used in authentication exchanges, as defined in
 128    [PKINIT].
 129
 130    By using this OPTIONAL extension, PKINIT clients and the KDC can
 131    maximize the reuse of cached OCSP responses.
 132
 133
 134
 135
 136
 137
 138
 139
 140
 141
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166 Zhu, et al.             Expires February 8, 2005                [Page 3]
 167 \f
 168 Internet-Draft          OCSP Support for PKINIT              August 2004
 169
 170
 171 2.  Conventions Used in This Document
 172
 173    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 174    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 175    document are to be interpreted as described in [RFC2119].
 176
 177
 178
 179
 180
 181
 182
 183
 184
 185
 186
 187
 188
 189
 190
 191
 192
 193
 194
 195
 196
 197
 198
 199
 200
 201
 202
 203
 204
 205
 206
 207
 208
 209
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222 Zhu, et al.             Expires February 8, 2005                [Page 4]
 223 \f
 224 Internet-Draft          OCSP Support for PKINIT              August 2004
 225
 226
 227 3.  Message Definition
 228
 229    A pre-authentication type identifier is defined for this mechanism:
 230
 231               PA-PK-OCSP-RESPONSE              16
 232
 233    The corresponding pre-authentication field contains OCSP data as
 234    follows:
 235
 236           PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
 237
 238           OcspResponse ::= OCTET STRING
 239                          -- contains a complete OCSP response,
 240                          -- defined in [RFC2560]
 241
 242    The client MAY send OCSP responses for certificates used in
 243    PA-PK-AS-REQ via a PA-PK-OCSP-RESPONSE.
 244
 245    The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
 246    PA-PK-OCSP-RESPONSE in response.  The client can request a
 247    PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
 248
 249    Note the lack of integrity protection for the empty or missing OCSP
 250    response; lack of an expected OCSP response from the KDC for the
 251    KDC's certificates SHOULD be treated as an error by the client,
 252    unless it is configured otherwise.
 253
 254    When using OCSP, the response is signed by the OCSP server, which is
 255    trusted by the receiver.  Depending on local policy, further
 256    verification of the validity of the OCSP servers MAY need to be done.
 257
 258    The client and the KDC SHOULD ignore invalid OCSP responses received
 259    via this mechanism, and they MAY implement CRL processing logic as a
 260    fall-back position, if the OCSP responses received via this mechanism
 261    alone are not sufficient for the verification of certificate
 262    validity.  The client and/or the KDC MAY ignore a valid OCSP response
 263    and perform their own revocation status verification independently.
 264
 265    The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
 266    PA-PK-OCSP-RESPONSE from the client.
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278 Zhu, et al.             Expires February 8, 2005                [Page 5]
 279 \f
 280 Internet-Draft          OCSP Support for PKINIT              August 2004
 281
 282
 283 4.  Security Considerations
 284
 285    The pre-authentication data in this document do not actually
 286    authenticate any principals, and MUST be used in conjunction with
 287    PKINIT.
 288
 289    There is a downgrade attack against clients which want OCSP responses
 290    from the KDC for the KDC's certificates.  The clients, however, can
 291    treat the absence of valid OCSP responses as an error, based on their
 292    local configuration.
 293
 294
 295
 296
 297
 298
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334 Zhu, et al.             Expires February 8, 2005                [Page 6]
 335 \f
 336 Internet-Draft          OCSP Support for PKINIT              August 2004
 337
 338
 339 5.  IANA Considerations
 340
 341    This document defines a new pre-authentication type for use with
 342    PKINIT to encode OCSP responses.  The official value for this padata
 343    identifier need to be acquired from IANA.
 344
 345 6  References
 346
 347    [CLARIFICATIONS]
 348               Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
 349               Kerberos Network Authentication Service (V5)",
 350               draft-ietf-krb-wg-kerberos-clarifications, Work in
 351               progress.
 352
 353    [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
 354               Initial Authentication in Kerberos",
 355               draft-ietf-cat-kerberos-pk-init, Work in progress.
 356
 357    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 358               Requirement Levels", BCP 14, RFC 2119, March 1997.
 359
 360    [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
 361               Adams, "X.509 Internet Public Key Infrastructure Online
 362               Certificate Status Protocol - OCSP", RFC 2560, June 1999.
 363
 364
 365 Authors' Addresses
 366
 367    Larry Zhu
 368    Microsoft Corporation
 369    One Microsoft Way
 370    Redmond, WA  98052
 371    US
 372
 373    EMail: lzhu@microsoft.com
 374
 375
 376    Karthik Jaganathan
 377    Microsoft Corporation
 378    One Microsoft Way
 379    Redmond, WA  98052
 380    US
 381
 382    EMail: karthikj@microsoft.com
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392 Zhu, et al.             Expires February 8, 2005                [Page 7]
 393 \f
 394 Internet-Draft          OCSP Support for PKINIT              August 2004
 395
 396
 397    Nicolas Williams
 398    Sun Microsystems
 399    5300 Riata Trace Ct
 400    Austin, TX  78727
 401    US
 402
 403    EMail: Nicolas.Williams@sun.com
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448 Zhu, et al.             Expires February 8, 2005                [Page 8]
 449 \f
 450 Internet-Draft          OCSP Support for PKINIT              August 2004
 451
 452
 453 Intellectual Property Statement
 454
 455    The IETF takes no position regarding the validity or scope of any
 456    Intellectual Property Rights or other rights that might be claimed to
 457    pertain to the implementation or use of the technology described in
 458    this document or the extent to which any license under such rights
 459    might or might not be available; nor does it represent that it has
 460    made any independent effort to identify any such rights.  Information
 461    on the procedures with respect to rights in RFC documents can be
 462    found in BCP 78 and BCP 79.
 463
 464    Copies of IPR disclosures made to the IETF Secretariat and any
 465    assurances of licenses to be made available, or the result of an
 466    attempt made to obtain a general license or permission for the use of
 467    such proprietary rights by implementers or users of this
 468    specification can be obtained from the IETF on-line IPR repository at
 469    http://www.ietf.org/ipr.
 470
 471    The IETF invites any interested party to bring to its attention any
 472    copyrights, patents or patent applications, or other proprietary
 473    rights that may cover technology that may be required to implement
 474    this standard.  Please address the information to the IETF at
 475    ietf-ipr@ietf.org.
 476
 477
 478 Disclaimer of Validity
 479
 480    This document and the information contained herein are provided on an
 481    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 482    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 483    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 484    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 485    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 486    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 487
 488
 489 Copyright Statement
 490
 491    Copyright (C) The Internet Society (2004).  This document is subject
 492    to the rights, licenses and restrictions contained in BCP 78, and
 493    except as set forth therein, the authors retain all their rights.
 494
 495
 496 Acknowledgment
 497
 498    This document was based on conversations among the authors, Jeffrey
 499    Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
 500    working group.
 501
 502
 503 Zhu, et al.             Expires February 8, 2005                [Page 9]
 504 \f
 505