doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                             K. Jaganathan
   5 Expires: August 4, 2005                            Microsoft Corporation
   6                                                              N. Williams
   7                                                         Sun Microsystems
   8                                                         January 31, 2005
   9
  10
  11                         OCSP Support for PKINIT
  12                    draft-ietf-krb-wg-ocsp-for-pkinit-04
  13
  14 Status of this Memo
  15
  16    This document is an Internet-Draft and is subject to all provisions
  17    of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
  18    author represents that any applicable patent or other IPR claims of
  19    which he or she is aware have been or will be disclosed, and any of
  20    which he or she become aware will be disclosed, in accordance with
  21    RFC 3668.
  22
  23    Internet-Drafts are working documents of the Internet Engineering
  24    Task Force (IETF), its areas, and its working groups.  Note that
  25    other groups may also distribute working documents as
  26    Internet-Drafts.
  27
  28    Internet-Drafts are draft documents valid for a maximum of six months
  29    and may be updated, replaced, or obsoleted by other documents at any
  30    time.  It is inappropriate to use Internet-Drafts as reference
  31    material or to cite them other than as "work in progress."
  32
  33    The list of current Internet-Drafts can be accessed at
  34    http://www.ietf.org/ietf/1id-abstracts.txt.
  35
  36    The list of Internet-Draft Shadow Directories can be accessed at
  37    http://www.ietf.org/shadow.html.
  38
  39    This Internet-Draft will expire on August 4, 2005.
  40
  41 Copyright Notice
  42
  43    Copyright (C) The Internet Society (2005).
  44
  45 Abstract
  46
  47    This document defines a mechanism to enable in-band transmission of
  48    Online Certificate Status Protocol (OCSP) responses in the Kerberos
  49    network authentication protocol.  These responses are used to verify
  50    the validity of the certificates used in PKINIT - the Kerberos
  51
  52
  53
  54 Zhu, et al.              Expires August 4, 2005                 [Page 1]
  55 \f
  56 Internet-Draft           OCSP Support for PKINIT            January 2005
  57
  58
  59    Version 5 extension that provides for the use of public key
  60    cryptography.
  61
  62 Table of Contents
  63
  64    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
  66    3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
  67    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
  68    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
  69    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
  70    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
  71      7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
  72      7.2   Informative References . . . . . . . . . . . . . . . . . .  5
  73        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
  74        Intellectual Property and Copyright Statements . . . . . . . .  7
  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 August 4, 2005                 [Page 2]
 111 \f
 112 Internet-Draft           OCSP Support for PKINIT            January 2005
 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 the certificates for Kerberos Key Distribution Center
 122    (KDC) in order to avoid transmission of large Certificate Revocation
 123    Lists (CRLs) and therefore save bandwidth on constrained networks
 124    [OCSP-PROFILE].
 125
 126    This document defines a pre-authentication type [CLARIFICATIONS],
 127    where the client and the KDC MAY piggyback OCSP responses for
 128    certificates used in authentication exchanges, as defined in
 129    [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              16
 145
 146    The corresponding padata-value field [CLARIFICATIONS] contains the
 147    DER [X60] encoding of the following ASN.1 type:
 148
 149           PKOcspData ::= SEQUENCE OF OcspResponse
 150
 151           OcspResponse ::= OCTET STRING
 152                          -- contains a complete OCSP response,
 153                          -- defined in [RFC2560]
 154
 155    The client MAY send OCSP responses for certificates used in
 156    PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
 157
 158    The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a
 159    PA-PK-OCSP-RESPONSE containing OCSP responses for certificates used
 160    in the KDC's PA-PK-AS-REP.  The client can request a
 161    PA-PK-OCSP-RESPONSE by using a PKOcspData containing an empty
 162    sequence.
 163
 164
 165
 166 Zhu, et al.              Expires August 4, 2005                 [Page 3]
 167 \f
 168 Internet-Draft           OCSP Support for PKINIT            January 2005
 169
 170
 171    The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
 172    PA-PK-OCSP-RESPONSE from the client.
 173
 174    The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
 175    certificates used in PA-PK-AS-REP [PKINIT].
 176
 177    Note the lack of integrity protection for the empty or missing OCSP
 178    response; lack of an expected OCSP response from the KDC for the
 179    KDC's certificates SHOULD be treated as an error by the client,
 180    unless it is configured otherwise.
 181
 182    When using OCSP, the response is signed by the OCSP server, which is
 183    trusted by the receiver.  Depending on local policy, further
 184    verification of the validity of the OCSP servers may be needed
 185
 186    The client and the KDC SHOULD ignore invalid OCSP responses received
 187    via this mechanism, and they MAY implement CRL processing logic as a
 188    fall-back position, if the OCSP responses received via this mechanism
 189    alone are not sufficient for the verification of certificate
 190    validity.  The client and/or the KDC MAY ignore a valid OCSP response
 191    and perform their own revocation status verification independently.
 192
 193 4.  Security Considerations
 194
 195    The pre-authentication data in this document do not actually
 196    authenticate any principals, but is designed to be used in
 197    conjunction with PKINIT.
 198
 199    There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
 200    data and PKINIT pre-authentication data other than a given OCSP
 201    response corresponding to a certificate used in a PKINIT
 202    pre-authentication data element.  Attacks involving removal or
 203    replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
 204    are, at worst, downgrade attacks, where a PKINIT client or KDC would
 205    proceed without use of CRLs or OCSP for certificate validation, or
 206    denial of service attacks, where a PKINIT client or KDC that cannot
 207    validate the other's certificate without an accompanying OCSP
 208    response might reject the AS exchange or where they might have to
 209    download very large CRLs in order to continue.  Kerberos V does not
 210    protect against denial-of-service attacks, therefore the
 211    denial-of-service aspect of these attacks are acceptable.
 212
 213    If a PKINIT client or KDC cannot validate certificates without the
 214    aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
 215    exchange, possibly according to local configuration.
 216
 217
 218
 219
 220
 221
 222 Zhu, et al.              Expires August 4, 2005                 [Page 4]
 223 \f
 224 Internet-Draft           OCSP Support for PKINIT            January 2005
 225
 226
 227 5.  IANA Considerations
 228
 229    No IANA actions are required for this document.
 230
 231 6.  Acknowledgements
 232
 233    This document was based on conversations among the authors, Jeffrey
 234    Altman, Sam Hartman, Martin Rex and other members of the Kerberos
 235    working group.
 236
 237 7.  References
 238
 239 7.1  Normative References
 240
 241    [CLARIFICATIONS]
 242               RFC-Editor: To be replaced by RFC number for draft-ietf-
 243               krb-wg-kerberos-clarifications.  Work in Progress.
 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    [X690]     ASN.1 encoding rules: Specification of Basic Encoding
 256               Rules (BER), Canonical Encoding Rules (CER) and
 257               Distinguished Encoding Rules (DER), ITU-T Recommendation
 258               X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
 259
 260 7.2  Informative References
 261
 262    [OCSP-PROFILE]
 263               RFC-Editor: To be replaced by RFC number for draft-deacon-
 264               lightweight-ocsp-profile.  Work in Progress.
 265
 266
 267 Authors' Addresses
 268
 269    Larry Zhu
 270    Microsoft Corporation
 271    One Microsoft Way
 272    Redmond, WA  98052
 273    US
 274
 275    Email: lzhu@microsoft.com
 276
 277
 278
 279
 280
 281 Zhu, et al.              Expires August 4, 2005                 [Page 5]
 282 \f
 283 Internet-Draft           OCSP Support for PKINIT            January 2005
 284
 285
 286    Karthik Jaganathan
 287    Microsoft Corporation
 288    One Microsoft Way
 289    Redmond, WA  98052
 290    US
 291
 292    Email: karthikj@microsoft.com
 293
 294
 295    Nicolas Williams
 296    Sun Microsystems
 297    5300 Riata Trace Ct
 298    Austin, TX  78727
 299    US
 300
 301    Email: Nicolas.Williams@sun.com
 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
 335
 336
 337 Zhu, et al.              Expires August 4, 2005                 [Page 6]
 338 \f
 339 Internet-Draft           OCSP Support for PKINIT            January 2005
 340
 341
 342 Intellectual Property Statement
 343
 344    The IETF takes no position regarding the validity or scope of any
 345    Intellectual Property Rights or other rights that might be claimed to
 346    pertain to the implementation or use of the technology described in
 347    this document or the extent to which any license under such rights
 348    might or might not be available; nor does it represent that it has
 349    made any independent effort to identify any such rights.  Information
 350    on the procedures with respect to rights in RFC documents can be
 351    found in BCP 78 and BCP 79.
 352
 353    Copies of IPR disclosures made to the IETF Secretariat and any
 354    assurances of licenses to be made available, or the result of an
 355    attempt made to obtain a general license or permission for the use of
 356    such proprietary rights by implementers or users of this
 357    specification can be obtained from the IETF on-line IPR repository at
 358    http://www.ietf.org/ipr.
 359
 360    The IETF invites any interested party to bring to its attention any
 361    copyrights, patents or patent applications, or other proprietary
 362    rights that may cover technology that may be required to implement
 363    this standard.  Please address the information to the IETF at
 364    ietf-ipr@ietf.org.
 365
 366
 367 Disclaimer of Validity
 368
 369    This document and the information contained herein are provided on an
 370    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 371    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 372    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 373    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 374    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 375    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 376
 377
 378 Copyright Statement
 379
 380    Copyright (C) The Internet Society (2005).  This document is subject
 381    to the rights, licenses and restrictions contained in BCP 78, and
 382    except as set forth therein, the authors retain all their rights.
 383
 384
 385 Acknowledgment
 386
 387    Funding for the RFC Editor function is currently provided by the
 388    Internet Society.
 389
 390
 391
 392
 393 Zhu, et al.              Expires August 4, 2005                 [Page 7]
 394 \f