4 NETWORK WORKING GROUP L. Zhu
5 Internet-Draft K. Jaganathan
6 Expires: November 21, 2005 Microsoft Corporation
12 OCSP Support for PKINIT
13 draft-ietf-krb-wg-ocsp-for-pkinit-05
17 This document is an Internet-Draft and is subject to all provisions
18 of Section 3 of RFC 3667.
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.
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-
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.
46 Copyright (C) The Internet Society (2005).
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
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
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
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
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.
238 This document was based on conversations among the authors, Jeffrey
239 Altman, Sam Hartman, Martin Rex and other members of the Kerberos
244 7.1 Normative References
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
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
293 Microsoft Corporation
298 Email: lzhu@microsoft.com
302 Microsoft Corporation
307 Email: karthikj@microsoft.com
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
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.
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.
391 Funding for the RFC Editor function is currently provided by the
397 Zhu, et al. Expires November 21, 2005 [Page 7]