doc/standardisation/rfc4557.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                             L. Zhu
   8 Request for Comments: 4557                                 K. Jaganathan
   9 Category: Standards Track                          Microsoft Corporation
  10                                                              N. Williams
  11                                                         Sun Microsystems
  12                                                                June 2006
  13
  14
  15          Online Certificate Status Protocol (OCSP) Support for
  16                       Public Key Cryptography for
  17               Initial Authentication in Kerberos (PKINIT)
  18
  19 Status of This Memo
  20
  21    This document specifies an Internet standards track protocol for the
  22    Internet community, and requests discussion and suggestions for
  23    improvements.  Please refer to the current edition of the "Internet
  24    Official Protocol Standards" (STD 1) for the standardization state
  25    and status of this protocol.  Distribution of this memo is unlimited.
  26
  27 Copyright Notice
  28
  29    Copyright (C) The Internet Society (2006).
  30
  31 Abstract
  32
  33    This document defines a mechanism to enable in-band transmission of
  34    Online Certificate Status Protocol (OCSP) responses in the Kerberos
  35    network authentication protocol.  These responses are used to verify
  36    the validity of the certificates used in Public Key Cryptography for
  37    Initial Authentication in Kerberos (PKINIT), which is the Kerberos
  38    Version 5 extension that provides for the use of public key
  39    cryptography.
  40
  41 Table of Contents
  42
  43    1. Introduction ....................................................2
  44    2. Conventions Used in This Document ...............................2
  45    3. Message Definition ..............................................2
  46    4. Security Considerations .........................................3
  47    5. Acknowledgements ................................................4
  48    6. References ......................................................4
  49       6.1. Normative References .......................................4
  50       6.2. Informative References .....................................4
  51
  52
  53
  54
  55
  56
  57
  58 Zhu, et al.                 Standards Track                     [Page 1]
  59 \f
  60 RFC 4557                OCSP Support for PKINIT                June 2006
  61
  62
  63 1.  Introduction
  64
  65    Online Certificate Status Protocol (OCSP) [RFC2560] enables
  66    applications to obtain timely information regarding the revocation
  67    status of a certificate.  Because OCSP responses are well bounded and
  68    small in size, constrained clients may wish to use OCSP to check the
  69    validity of the certificates for Kerberos Key Distribution Center
  70    (KDC) in order to avoid transmission of large Certificate Revocation
  71    Lists (CRLs) and therefore save bandwidth on constrained networks
  72    [OCSP-PROFILE].
  73
  74    This document defines a pre-authentication type [RFC4120], where the
  75    client and the KDC MAY piggyback OCSP responses for certificates used
  76    in authentication exchanges, as defined in [RFC4556].
  77
  78    By using this OPTIONAL extension, PKINIT clients and the KDC can
  79    maximize the reuse of cached OCSP responses.
  80
  81 2.  Conventions Used in This Document
  82
  83    In this document, the key words "MUST", "MUST NOT", "REQUIRED",
  84    "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
  85    and "OPTIONAL" are to be interpreted as described in [RFC2119].
  86
  87 3.  Message Definition
  88
  89    A pre-authentication type identifier is defined for this mechanism:
  90
  91               PA-PK-OCSP-RESPONSE              18
  92
  93    The corresponding padata-value field [RFC4120] contains the DER [X60]
  94    encoding of the following ASN.1 type:
  95
  96           PKOcspData ::= SEQUENCE OF OcspResponse
  97                          -- If more than one OcspResponse is
  98                          -- included, the first OcspResponse
  99                          -- MUST contain the OCSP response
 100                          -- for the signer's certificate.
 101                          -- The signer refers to the client for
 102                          -- AS-REQ, and the KDC for the AS-REP,
 103                          -- respectively.
 104
 105           OcspResponse ::= OCTET STRING
 106                          -- Contains a complete OCSP response,
 107                          -- as defined in [RFC2560].
 108
 109    The client MAY send OCSP responses for certificates used in PA-PK-
 110    AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
 111
 112
 113
 114 Zhu, et al.                 Standards Track                     [Page 2]
 115 \f
 116 RFC 4557                OCSP Support for PKINIT                June 2006
 117
 118
 119    The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
 120    OCSP-RESPONSE containing OCSP responses for certificates used in the
 121    KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
 122    using a PKOcspData containing an empty sequence.
 123
 124    The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
 125    PA-PK-OCSP-RESPONSE from the client.
 126
 127    The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
 128    certificates used in PA-PK-AS-REP [RFC4556].
 129
 130    Note the lack of integrity protection for the empty or missing OCSP
 131    response; lack of an expected OCSP response from the KDC for the
 132    KDC's certificates SHOULD be treated as an error by the client,
 133    unless it is configured otherwise.
 134
 135    When using OCSP, the response is signed by the OCSP server, which is
 136    trusted by the receiver.  Depending on local policy, further
 137    verification of the validity of the OCSP servers may be needed
 138
 139    The client and the KDC SHOULD ignore invalid OCSP responses received
 140    via this mechanism, and they MAY implement CRL processing logic as a
 141    fall-back position, if the OCSP responses received via this mechanism
 142    alone are not sufficient for the verification of certificate
 143    validity.  The client and/or the KDC MAY ignore a valid OCSP response
 144    and perform its own revocation status verification independently.
 145
 146 4.  Security Considerations
 147
 148    The pre-authentication data in this document do not actually
 149    authenticate any principals, but are designed to be used in
 150    conjunction with PKINIT.
 151
 152    There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
 153    data and PKINIT pre-authentication data other than a given OCSP
 154    response corresponding to a certificate used in a PKINIT pre-
 155    authentication data element.  Attacks involving removal or
 156    replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
 157    are, at worst, downgrade attacks, where a PKINIT client or KDC would
 158    proceed without use of CRLs or OCSP for certificate validation, or
 159    denial-of-service attacks, where a PKINIT client or KDC that cannot
 160    validate the other's certificate without an accompanying OCSP
 161    response might reject the AS exchange or might have to download very
 162    large CRLs in order to continue.  Kerberos V does not protect against
 163    denial-of-service attacks; therefore, the denial-of-service aspect of
 164    these attacks is acceptable.
 165
 166
 167
 168
 169
 170 Zhu, et al.                 Standards Track                     [Page 3]
 171 \f
 172 RFC 4557                OCSP Support for PKINIT                June 2006
 173
 174
 175    If a PKINIT client or KDC cannot validate certificates without the
 176    aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
 177    exchange, possibly according to local configuration.
 178
 179 5.  Acknowledgements
 180
 181    This document was based on conversations among the authors, Jeffrey
 182    Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
 183    working group.
 184
 185 6.  References
 186
 187 6.1.  Normative References
 188
 189    [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
 190                   Requirement Levels", BCP 14, RFC 2119, March 1997.
 191
 192    [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
 193                   C. Adams, "X.509 Internet Public Key Infrastructure
 194                   Online Certificate Status Protocol - OCSP", RFC 2560,
 195                   June 1999.
 196
 197    [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 198                   Kerberos Network Authentication Service (V5)", RFC
 199                   4120, July 2005.
 200
 201    [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
 202                   Initial Authentication in Kerberos (PKINIT)", RFC
 203                   4556, June 2006.
 204
 205    [X690]         ASN.1 encoding rules: Specification of Basic Encoding
 206                   Rules (BER), Canonical Encoding Rules (CER) and
 207                   Distinguished Encoding Rules (DER), ITU-T
 208                   Recommendation X.690 (1997) | ISO/IEC International
 209                   Standard 8825-1:1998.
 210
 211 6.2.  Informative References
 212
 213    [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
 214                   High Volume Environments", Work in Progress, May 2006.
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Zhu, et al.                 Standards Track                     [Page 4]
 227 \f
 228 RFC 4557                OCSP Support for PKINIT                June 2006
 229
 230
 231 Authors' Addresses
 232
 233    Larry Zhu
 234    Microsoft Corporation
 235    One Microsoft Way
 236    Redmond, WA  98052
 237    US
 238
 239    EMail: lzhu@microsoft.com
 240
 241
 242    Karthik Jaganathan
 243    Microsoft Corporation
 244    One Microsoft Way
 245    Redmond, WA  98052
 246    US
 247
 248    EMail: karthikj@microsoft.com
 249
 250
 251    Nicolas Williams
 252    Sun Microsystems
 253    5300 Riata Trace Ct
 254    Austin, TX  78727
 255    US
 256
 257    EMail: Nicolas.Williams@sun.com
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Zhu, et al.                 Standards Track                     [Page 5]
 283 \f
 284 RFC 4557                OCSP Support for PKINIT                June 2006
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (2006).
 290
 291    This document is subject to the rights, licenses and restrictions
 292    contained in BCP 78, and except as set forth therein, the authors
 293    retain all their rights.
 294
 295    This document and the information contained herein are provided on an
 296    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 297    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 298    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 299    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 300    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 301    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 302
 303 Intellectual Property
 304
 305    The IETF takes no position regarding the validity or scope of any
 306    Intellectual Property Rights or other rights that might be claimed to
 307    pertain to the implementation or use of the technology described in
 308    this document or the extent to which any license under such rights
 309    might or might not be available; nor does it represent that it has
 310    made any independent effort to identify any such rights.  Information
 311    on the procedures with respect to rights in RFC documents can be
 312    found in BCP 78 and BCP 79.
 313
 314    Copies of IPR disclosures made to the IETF Secretariat and any
 315    assurances of licenses to be made available, or the result of an
 316    attempt made to obtain a general license or permission for the use of
 317    such proprietary rights by implementers or users of this
 318    specification can be obtained from the IETF on-line IPR repository at
 319    http://www.ietf.org/ipr.
 320
 321    The IETF invites any interested party to bring to its attention any
 322    copyrights, patents or patent applications, or other proprietary
 323    rights that may cover technology that may be required to implement
 324    this standard.  Please address the information to the IETF at
 325    ietf-ipr@ietf.org.
 326
 327 Acknowledgement
 328
 329    Funding for the RFC Editor function is provided by the IETF
 330    Administrative Support Activity (IASA).
 331
 332
 333
 334
 335
 336
 337
 338 Zhu, et al.                 Standards Track                     [Page 6]
 339 \f