Check the GSS-API checksum exists before trying to use it [CVE-2010-1321]
[heimdal.git] / doc / standardisation / draft-ietf-krb-wg-ocsp-for-pkinit-05.txt
blobe777e327291cd43f4271034019db67d7e11aa5aa
4 NETWORK WORKING GROUP                                             L. Zhu
5 Internet-Draft                                             K. Jaganathan
6 Expires: November 21, 2005                         Microsoft Corporation
7                                                              N. Williams
8                                                         Sun Microsystems
9                                                             May 20, 2005
12                         OCSP Support for PKINIT
13                    draft-ietf-krb-wg-ocsp-for-pkinit-05
15 Status of this Memo
17    This document is an Internet-Draft and is subject to all provisions
18    of Section 3 of RFC 3667. 
19    
20    By submitting this Internet-Draft, each author represents
21    that any applicable patent or other IPR claims of which he
22    or she is aware have been or will be disclosed, and any of
23    which he or she becomes aware will be disclosed, in
24    accordance with Section 6 of BCP 79.
25    
26    Internet-Drafts are working documents of the Internet Engineering
27    Task Force (IETF), its areas, and its working groups.  Note that
28    other groups may also distribute working documents as Internet-
29    Drafts.
31    Internet-Drafts are draft documents valid for a maximum of six months
32    and may be updated, replaced, or obsoleted by other documents at any
33    time.  It is inappropriate to use Internet-Drafts as reference
34    material or to cite them other than as "work in progress."
36    The list of current Internet-Drafts can be accessed at
37    http://www.ietf.org/ietf/1id-abstracts.txt.
39    The list of Internet-Draft Shadow Directories can be accessed at
40    http://www.ietf.org/shadow.html.
42    This Internet-Draft will expire on November 21, 2005.
44 Copyright Notice
46    Copyright (C) The Internet Society (2005).
48 Abstract
50    This document defines a mechanism to enable in-band transmission of
51    Online Certificate Status Protocol (OCSP) responses in the Kerberos
52    network authentication protocol.  These responses are used to verify
53    the validity of the certificates used in PKINIT - the Kerberos
57 Zhu, et al.             Expires November 21, 2005               [Page 1]
59 Internet-Draft           OCSP Support for PKINIT                May 2005
62    Version 5 extension that provides for the use of public key
63    cryptography.
65 Table of Contents
67    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
68    2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
69    3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
70    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
71    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
72    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
73    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
74      7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
75      7.2   Informative References . . . . . . . . . . . . . . . . . .  5
76        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
77        Intellectual Property and Copyright Statements . . . . . . . .  7
113 Zhu, et al.             Expires November 21, 2005               [Page 2]
115 Internet-Draft           OCSP Support for PKINIT                May 2005
118 1.  Introduction
120    Online Certificate Status Protocol (OCSP) [RFC2560] enables
121    applications to obtain timely information regarding the revocation
122    status of a certificate.  Because OCSP responses are well-bounded and
123    small in size, constrained clients may wish to use OCSP to check the
124    validity of the certificates for Kerberos Key Distribution Center
125    (KDC) in order to avoid transmission of large Certificate Revocation
126    Lists (CRLs) and therefore save bandwidth on constrained networks
127    [OCSP-PROFILE].
129    This document defines a pre-authentication type [CLARIFICATIONS],
130    where the client and the KDC MAY piggyback OCSP responses for
131    certificates used in authentication exchanges, as defined in
132    [PKINIT].
134    By using this OPTIONAL extension, PKINIT clients and the KDC can
135    maximize the reuse of cached OCSP responses.
137 2.  Conventions Used in This Document
139    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
140    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
141    document are to be interpreted as described in [RFC2119].
143 3.  Message Definition
145    A pre-authentication type identifier is defined for this mechanism:
147               PA-PK-OCSP-RESPONSE              18
149    The corresponding padata-value field [CLARIFICATIONS] contains the
150    DER [X60] encoding of the following ASN.1 type:
152           PKOcspData ::= SEQUENCE OF OcspResponse
153                          -- If more than one OcspResponse is
154                          -- included, the first OcspResponse
155                          -- MUST contain the OCSP response
156                          -- for the signer's certificate.
158           OcspResponse ::= OCTET STRING
159                          -- Contains a complete OCSP response,
160                          -- as defined in [RFC2560].
162    The client MAY send OCSP responses for certificates used in PA-PK-AS-
163    REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
165    The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
169 Zhu, et al.             Expires November 21, 2005               [Page 3]
171 Internet-Draft           OCSP Support for PKINIT                May 2005
174    OCSP-RESPONSE containing OCSP responses for certificates used in the
175    KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
176    using a PKOcspData containing an empty sequence.
178    The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
179    PK-OCSP-RESPONSE from the client.
181    The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
182    certificates used in PA-PK-AS-REP [PKINIT].
184    Note the lack of integrity protection for the empty or missing OCSP
185    response; lack of an expected OCSP response from the KDC for the
186    KDC's certificates SHOULD be treated as an error by the client,
187    unless it is configured otherwise.
189    When using OCSP, the response is signed by the OCSP server, which is
190    trusted by the receiver.  Depending on local policy, further
191    verification of the validity of the OCSP servers may be needed
193    The client and the KDC SHOULD ignore invalid OCSP responses received
194    via this mechanism, and they MAY implement CRL processing logic as a
195    fall-back position, if the OCSP responses received via this mechanism
196    alone are not sufficient for the verification of certificate
197    validity.  The client and/or the KDC MAY ignore a valid OCSP response
198    and perform their own revocation status verification independently.
200 4.  Security Considerations
202    The pre-authentication data in this document do not actually
203    authenticate any principals, but is designed to be used in
204    conjunction with PKINIT.
206    There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
207    data and PKINIT pre-authentication data other than a given OCSP
208    response corresponding to a certificate used in a PKINIT pre-
209    authentication data element.  Attacks involving removal or
210    replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
211    are, at worst, downgrade attacks, where a PKINIT client or KDC would
212    proceed without use of CRLs or OCSP for certificate validation, or
213    denial of service attacks, where a PKINIT client or KDC that cannot
214    validate the other's certificate without an accompanying OCSP
215    response might reject the AS exchange or where they might have to
216    download very large CRLs in order to continue.  Kerberos V does not
217    protect against denial-of-service attacks, therefore the denial-of-
218    service aspect of these attacks are acceptable.
220    If a PKINIT client or KDC cannot validate certificates without the
221    aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
225 Zhu, et al.             Expires November 21, 2005               [Page 4]
227 Internet-Draft           OCSP Support for PKINIT                May 2005
230    exchange, possibly according to local configuration.
232 5.  IANA Considerations
234    No IANA actions are required for this document.
236 6.  Acknowledgements
238    This document was based on conversations among the authors, Jeffrey
239    Altman, Sam Hartman, Martin Rex and other members of the Kerberos
240    working group.
242 7.  References
244 7.1  Normative References
246    [CLARIFICATIONS]
247               RFC-Editor: To be replaced by RFC number for draft-ietf-
248               krb-wg-kerberos-clarifications.  Work in Progress. 
250    [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
251               cat-kerberos-pk-init.  Work in Progress. 
253    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
254               Requirement Levels", BCP 14, RFC 2119, March 1997.
256    [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
257               Adams, "X.509 Internet Public Key Infrastructure Online
258               Certificate Status Protocol - OCSP", RFC 2560, June 1999.
260    [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
261               Rules (BER), Canonical Encoding Rules (CER) and 
262               Distinguished Encoding Rules (DER), ITU-T Recommendation 
263               X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
265 7.2  Informative References
267    [OCSP-PROFILE]
268               RFC-Editor: To be replaced by RFC number for draft-deacon-
269               lightweight-ocsp-profile.  Work in Progress.  
285 Zhu, et al.             Expires November 21, 2005               [Page 5]
287 Internet-Draft           OCSP Support for PKINIT                May 2005
290 Authors' Addresses
292    Larry Zhu
293    Microsoft Corporation
294    One Microsoft Way
295    Redmond, WA  98052
296    US
298    Email: lzhu@microsoft.com
301    Karthik Jaganathan
302    Microsoft Corporation
303    One Microsoft Way
304    Redmond, WA  98052
305    US
307    Email: karthikj@microsoft.com
310    Nicolas Williams
311    Sun Microsystems
312    5300 Riata Trace Ct
313    Austin, TX  78727
314    US
316    Email: Nicolas.Williams@sun.com
341 Zhu, et al.             Expires November 21, 2005               [Page 6]
343 Internet-Draft           OCSP Support for PKINIT                May 2005
346 Intellectual Property Statement
348    The IETF takes no position regarding the validity or scope of any
349    Intellectual Property Rights or other rights that might be claimed to
350    pertain to the implementation or use of the technology described in
351    this document or the extent to which any license under such rights
352    might or might not be available; nor does it represent that it has
353    made any independent effort to identify any such rights.  Information
354    on the procedures with respect to rights in RFC documents can be
355    found in BCP 78 and BCP 79.
357    Copies of IPR disclosures made to the IETF Secretariat and any
358    assurances of licenses to be made available, or the result of an
359    attempt made to obtain a general license or permission for the use of
360    such proprietary rights by implementers or users of this
361    specification can be obtained from the IETF on-line IPR repository at
362    http://www.ietf.org/ipr.
364    The IETF invites any interested party to bring to its attention any
365    copyrights, patents or patent applications, or other proprietary
366    rights that may cover technology that may be required to implement
367    this standard.  Please address the information to the IETF at
368    ietf-ipr@ietf.org.
371 Disclaimer of Validity
373    This document and the information contained herein are provided on an
374    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
375    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
376    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
377    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
378    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
379    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
382 Copyright Statement
384    Copyright (C) The Internet Society (2005).  This document is subject
385    to the rights, licenses and restrictions contained in BCP 78, and
386    except as set forth therein, the authors retain all their rights.
389 Acknowledgment
391    Funding for the RFC Editor function is currently provided by the
392    Internet Society.
397 Zhu, et al.             Expires November 21, 2005               [Page 7]