1
2
3
4NETWORK WORKING GROUP                                             L. Zhu
5Internet-Draft                                             K. Jaganathan
6Expires: November 21, 2005                         Microsoft Corporation
7                                                             N. Williams
8                                                        Sun Microsystems
9                                                            May 20, 2005
10
11
12                        OCSP Support for PKINIT
13                   draft-ietf-krb-wg-ocsp-for-pkinit-05
14
15Status of this Memo
16
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.
30
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."
35
36   The list of current Internet-Drafts can be accessed at
37   http://www.ietf.org/ietf/1id-abstracts.txt.
38
39   The list of Internet-Draft Shadow Directories can be accessed at
40   http://www.ietf.org/shadow.html.
41
42   This Internet-Draft will expire on November 21, 2005.
43
44Copyright Notice
45
46   Copyright (C) The Internet Society (2005).
47
48Abstract
49
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
54
55
56
57Zhu, et al.             Expires November 21, 2005               [Page 1]
58
59Internet-Draft           OCSP Support for PKINIT                May 2005
60
61
62   Version 5 extension that provides for the use of public key
63   cryptography.
64
65Table of Contents
66
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
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
112
113Zhu, et al.             Expires November 21, 2005               [Page 2]
114
115Internet-Draft           OCSP Support for PKINIT                May 2005
116
117
1181.  Introduction
119
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].
128
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].
133
134   By using this OPTIONAL extension, PKINIT clients and the KDC can
135   maximize the reuse of cached OCSP responses.
136
1372.  Conventions Used in This Document
138
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].
142
1433.  Message Definition
144
145   A pre-authentication type identifier is defined for this mechanism:
146
147              PA-PK-OCSP-RESPONSE              18
148
149   The corresponding padata-value field [CLARIFICATIONS] contains the
150   DER [X60] encoding of the following ASN.1 type:
151
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.
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   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
166
167
168
169Zhu, et al.             Expires November 21, 2005               [Page 3]
170
171Internet-Draft           OCSP Support for PKINIT                May 2005
172
173
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.
177
178   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
179   PK-OCSP-RESPONSE from the client.
180
181   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
182   certificates used in PA-PK-AS-REP [PKINIT].
183
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.
188
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
192
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.
199
2004.  Security Considerations
201
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.
205
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.
219
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
222
223
224
225Zhu, et al.             Expires November 21, 2005               [Page 4]
226
227Internet-Draft           OCSP Support for PKINIT                May 2005
228
229
230   exchange, possibly according to local configuration.
231
2325.  IANA Considerations
233
234   No IANA actions are required for this document.
235
2366.  Acknowledgements
237
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.
241
2427.  References
243
2447.1  Normative References
245
246   [CLARIFICATIONS]
247              RFC-Editor: To be replaced by RFC number for draft-ietf-
248              krb-wg-kerberos-clarifications.  Work in Progress. 
249
250   [PKINIT]   RFC-Editor: To be replaced by RFC number for draft-ietf-
251              cat-kerberos-pk-init.  Work in Progress. 
252
253   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
254              Requirement Levels", BCP 14, RFC 2119, March 1997.
255
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.
259
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.
264
2657.2  Informative References
266
267   [OCSP-PROFILE]
268              RFC-Editor: To be replaced by RFC number for draft-deacon-
269              lightweight-ocsp-profile.  Work in Progress.  
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285Zhu, et al.             Expires November 21, 2005               [Page 5]
286
287Internet-Draft           OCSP Support for PKINIT                May 2005
288
289
290Authors' Addresses
291
292   Larry Zhu
293   Microsoft Corporation
294   One Microsoft Way
295   Redmond, WA  98052
296   US
297
298   Email: lzhu@microsoft.com
299
300
301   Karthik Jaganathan
302   Microsoft Corporation
303   One Microsoft Way
304   Redmond, WA  98052
305   US
306
307   Email: karthikj@microsoft.com
308
309
310   Nicolas Williams
311   Sun Microsystems
312   5300 Riata Trace Ct
313   Austin, TX  78727
314   US
315
316   Email: Nicolas.Williams@sun.com
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341Zhu, et al.             Expires November 21, 2005               [Page 6]
342
343Internet-Draft           OCSP Support for PKINIT                May 2005
344
345
346Intellectual Property Statement
347
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.
356
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.
363
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.
369
370
371Disclaimer of Validity
372
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.
380
381
382Copyright Statement
383
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.
387
388
389Acknowledgment
390
391   Funding for the RFC Editor function is currently provided by the
392   Internet Society.
393
394
395
396
397Zhu, et al.             Expires November 21, 2005               [Page 7]
398
399
400