doc/specifications/draft-ietf-krb-wg-ocsp-for-pkinit-06.txt

   1
   2
   3
   4 NETWORK WORKING GROUP                                             L. Zhu
   5 Internet-Draft                                             K. Jaganathan
   6 Expires: January 20, 2006                          Microsoft Corporation
   7                                                              N. Williams
   8                                                         Sun Microsystems
   9                                                            July 19, 2005
  10
  11
  12                         OCSP Support for PKINIT
  13                   draft-ietf-krb-wg-ocsp-for-pkinit-06
  14
  15 Status of this Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  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 Internet-
  25    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 January 20, 2006.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The Internet Society (2005).
  43
  44 Abstract
  45
  46    This document defines a mechanism to enable in-band transmission of
  47    Online Certificate Status Protocol (OCSP) responses in the Kerberos
  48    network authentication protocol.  These responses are used to verify
  49    the validity of the certificates used in PKINIT - the Kerberos
  50    Version 5 extension that provides for the use of public key
  51    cryptography.
  52
  53
  54
  55 Zhu, et al.             Expires January 20, 2006                [Page 1]
  56 \f
  57 Internet-Draft           OCSP Support for PKINIT               July 2005
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  64    3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
  65    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
  66    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
  67    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
  68    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  69      7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
  70      7.2   Informative References . . . . . . . . . . . . . . . . . .  5
  71        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
  72        Intellectual Property and Copyright Statements . . . . . . . .  7
  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
 111 Zhu, et al.             Expires January 20, 2006                [Page 2]
 112 \f
 113 Internet-Draft           OCSP Support for PKINIT               July 2005
 114
 115
 116 1.  Introduction
 117
 118    Online Certificate Status Protocol (OCSP) [RFC2560] enables
 119    applications to obtain timely information regarding the revocation
 120    status of a certificate.  Because OCSP responses are well-bounded and
 121    small in size, constrained clients may wish to use OCSP to check the
 122    validity of the certificates for Kerberos Key Distribution Center
 123    (KDC) in order to avoid transmission of large Certificate Revocation
 124    Lists (CRLs) and therefore save bandwidth on constrained networks
 125    [OCSP-PROFILE].
 126
 127    This document defines a pre-authentication type [RFC4120], where the
 128    client and the KDC MAY piggyback OCSP responses for certificates used
 129    in authentication exchanges, as defined in [PKINIT].
 130
 131    By using this OPTIONAL extension, PKINIT clients and the KDC can
 132    maximize the reuse of cached OCSP responses.
 133
 134 2.  Conventions Used in This Document
 135
 136    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 137    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 138    document are to be interpreted as described in [RFC2119].
 139
 140 3.  Message Definition
 141
 142    A pre-authentication type identifier is defined for this mechanism:
 143
 144               PA-PK-OCSP-RESPONSE              18
 145
 146    The corresponding padata-value field [RFC4120] contains the DER [X60]
 147    encoding of the following ASN.1 type:
 148
 149           PKOcspData ::= SEQUENCE OF OcspResponse
 150                          -- If more than one OcspResponse is
 151                          -- included, the first OcspResponse
 152                          -- MUST contain the OCSP response
 153                          -- for the signer's certificate.
 154                          -- The signer refers to the client for
 155                          -- AS-REQ, and the KDC for the AS-REP,
 156                          -- respectively.
 157
 158           OcspResponse ::= OCTET STRING
 159                          -- Contains a complete OCSP response,
 160                          -- as defined in [RFC2560].
 161
 162    The client MAY send OCSP responses for certificates used in PA-PK-AS-
 163    REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
 164
 165
 166
 167 Zhu, et al.             Expires January 20, 2006                [Page 3]
 168 \f
 169 Internet-Draft           OCSP Support for PKINIT               July 2005
 170
 171
 172    The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
 173    OCSP-RESPONSE containing OCSP responses for certificates used in the
 174    KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
 175    using a PKOcspData containing an empty sequence.
 176
 177    The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
 178    PK-OCSP-RESPONSE from the client.
 179
 180    The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
 181    certificates used in PA-PK-AS-REP [PKINIT].
 182
 183    Note the lack of integrity protection for the empty or missing OCSP
 184    response; lack of an expected OCSP response from the KDC for the
 185    KDC's certificates SHOULD be treated as an error by the client,
 186    unless it is configured otherwise.
 187
 188    When using OCSP, the response is signed by the OCSP server, which is
 189    trusted by the receiver.  Depending on local policy, further
 190    verification of the validity of the OCSP servers may be needed
 191
 192    The client and the KDC SHOULD ignore invalid OCSP responses received
 193    via this mechanism, and they MAY implement CRL processing logic as a
 194    fall-back position, if the OCSP responses received via this mechanism
 195    alone are not sufficient for the verification of certificate
 196    validity.  The client and/or the KDC MAY ignore a valid OCSP response
 197    and perform their own revocation status verification independently.
 198
 199 4.  Security Considerations
 200
 201    The pre-authentication data in this document do not actually
 202    authenticate any principals, but is designed to be used in
 203    conjunction with PKINIT.
 204
 205    There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
 206    data and PKINIT pre-authentication data other than a given OCSP
 207    response corresponding to a certificate used in a PKINIT pre-
 208    authentication data element.  Attacks involving removal or
 209    replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
 210    are, at worst, downgrade attacks, where a PKINIT client or KDC would
 211    proceed without use of CRLs or OCSP for certificate validation, or
 212    denial of service attacks, where a PKINIT client or KDC that cannot
 213    validate the other's certificate without an accompanying OCSP
 214    response might reject the AS exchange or where they might have to
 215    download very large CRLs in order to continue.  Kerberos V does not
 216    protect against denial-of-service attacks, therefore the denial-of-
 217    service aspect of these attacks are acceptable.
 218
 219    If a PKINIT client or KDC cannot validate certificates without the
 220
 221
 222
 223 Zhu, et al.             Expires January 20, 2006                [Page 4]
 224 \f
 225 Internet-Draft           OCSP Support for PKINIT               July 2005
 226
 227
 228    aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
 229    exchange, possibly according to local configuration.
 230
 231 5.  IANA Considerations
 232
 233    No IANA actions are required for this document.
 234
 235 6.  Acknowledgements
 236
 237    This document was based on conversations among the authors, Jeffrey
 238    Altman, Sam Hartman, Martin Rex and other members of the Kerberos
 239    working group.
 240
 241 7.  References
 242
 243 7.1  Normative References
 244
 245    [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
 246               cat-kerberos-pk-init.  Work in Progress.
 247
 248    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 249               Requirement Levels", BCP 14, RFC 2119, March 1997.
 250
 251    [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
 252               Adams, "X.509 Internet Public Key Infrastructure Online
 253               Certificate Status Protocol - OCSP", RFC 2560, June 1999.
 254
 255    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 256               Kerberos Network Authentication Service (V5)", RFC 4120,
 257               July 2005.
 258
 259    [X690]     ASN.1 encoding rules: Specification of Basic Encoding
 260               Rules (BER), Canonical Encoding Rules (CER) and
 261               Distinguished Encoding Rules (DER), ITU-T Recommendation
 262               X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
 263
 264 7.2  Informative References
 265
 266    [OCSP-PROFILE]
 267               RFC-Editor: To be replaced by RFC number for draft-deacon-
 268               lightweight-ocsp-profile.  Work in Progress.
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282
 283 Zhu, et al.             Expires January 20, 2006                [Page 5]
 284 \f
 285 Internet-Draft           OCSP Support for PKINIT               July 2005
 286
 287
 288 Authors' Addresses
 289
 290    Larry Zhu
 291    Microsoft Corporation
 292    One Microsoft Way
 293    Redmond, WA  98052
 294    US
 295
 296    Email: lzhu@microsoft.com
 297
 298
 299    Karthik Jaganathan
 300    Microsoft Corporation
 301    One Microsoft Way
 302    Redmond, WA  98052
 303    US
 304
 305    Email: karthikj@microsoft.com
 306
 307
 308    Nicolas Williams
 309    Sun Microsystems
 310    5300 Riata Trace Ct
 311    Austin, TX  78727
 312    US
 313
 314    Email: Nicolas.Williams@sun.com
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339 Zhu, et al.             Expires January 20, 2006                [Page 6]
 340 \f
 341 Internet-Draft           OCSP Support for PKINIT               July 2005
 342
 343
 344 Intellectual Property Statement
 345
 346    The IETF takes no position regarding the validity or scope of any
 347    Intellectual Property Rights or other rights that might be claimed to
 348    pertain to the implementation or use of the technology described in
 349    this document or the extent to which any license under such rights
 350    might or might not be available; nor does it represent that it has
 351    made any independent effort to identify any such rights.  Information
 352    on the procedures with respect to rights in RFC documents can be
 353    found in BCP 78 and BCP 79.
 354
 355    Copies of IPR disclosures made to the IETF Secretariat and any
 356    assurances of licenses to be made available, or the result of an
 357    attempt made to obtain a general license or permission for the use of
 358    such proprietary rights by implementers or users of this
 359    specification can be obtained from the IETF on-line IPR repository at
 360    http://www.ietf.org/ipr.
 361
 362    The IETF invites any interested party to bring to its attention any
 363    copyrights, patents or patent applications, or other proprietary
 364    rights that may cover technology that may be required to implement
 365    this standard.  Please address the information to the IETF at
 366    ietf-ipr@ietf.org.
 367
 368
 369 Disclaimer of Validity
 370
 371    This document and the information contained herein are provided on an
 372    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 373    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 374    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 375    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 376    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 377    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 378
 379
 380 Copyright Statement
 381
 382    Copyright (C) The Internet Society (2005).  This document is subject
 383    to the rights, licenses and restrictions contained in BCP 78, and
 384    except as set forth therein, the authors retain all their rights.
 385
 386
 387 Acknowledgment
 388
 389    Funding for the RFC Editor function is currently provided by the
 390    Internet Society.
 391
 392
 393
 394
 395 Zhu, et al.             Expires January 20, 2006                [Page 7]
 396 \f
 397