1
2NETWORK WORKING GROUP                                             L. Zhu
3Internet-Draft                                             K. Jaganathan
4Expires: February 8, 2005                          Microsoft Corporation
5                                                             N. Williams
6                                                        Sun Microsystems
7                                                         August 10, 2004
8
9
10                        OCSP Support for PKINIT
11                    draft-ietf-krb-wg-ocsp-for-pkinit-00
12
13Status of this Memo
14
15   This document is an Internet-Draft and is subject to all provisions
16   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
17   author represents that any applicable patent or other IPR claims of
18   which he or she is aware have been or will be disclosed, and any of
19   which he or she become aware will be disclosed, in accordance with
20   RFC 3668.
21
22   Internet-Drafts are working documents of the Internet Engineering
23   Task Force (IETF), its areas, and its working groups.  Note that
24   other groups may also distribute working documents as
25   Internet-Drafts.
26
27   Internet-Drafts are draft documents valid for a maximum of six months
28   and may be updated, replaced, or obsoleted by other documents at any
29   time.  It is inappropriate to use Internet-Drafts as reference
30   material or to cite them other than as "work in progress."
31
32   The list of current Internet-Drafts can be accessed at
33   http://www.ietf.org/ietf/1id-abstracts.txt.
34
35   The list of Internet-Draft Shadow Directories can be accessed at
36   http://www.ietf.org/shadow.html.
37
38   This Internet-Draft will expire on February 8, 2005.
39
40Copyright Notice
41
42   Copyright (C) The Internet Society (2004).
43
44Abstract
45
46   This document defines a mechanism to enable in-band transmission of
47   OCSP responses.  These responses are used to verify the validity of
48   the certificates used in PKINIT - the Kerberos Version 5 extension
49   that provides for the use of public key cryptography.
50
51
52
53
54Zhu, et al.             Expires February 8, 2005                [Page 1]
55
56Internet-Draft          OCSP Support for PKINIT              August 2004
57
58
59Table of Contents
60
61   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
62   2.   Conventions Used in This Document  . . . . . . . . . . . . . . 4
63   3.   Message Definition . . . . . . . . . . . . . . . . . . . . . . 5
64   4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 6
65   5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 7
66   6.   References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
67        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
68        Intellectual Property and Copyright Statements . . . . . . . . 9
69
70
71
72
73
74
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
110Zhu, et al.             Expires February 8, 2005                [Page 2]
111
112Internet-Draft          OCSP Support for PKINIT              August 2004
113
114
1151.  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 KDC certificates in order to avoid transmission of large
122   Certificate Revocation Lists (CRLs) and therefore save bandwidth on
123   constrained networks.
124
125   This document defines a pre-authentication type [CLARIFICATIONS],
126   where the client and the KDC MAY piggyback OCSP responses for
127   certificates used in authentication exchanges, as defined in
128   [PKINIT].
129
130   By using this OPTIONAL extension, PKINIT clients and the KDC can
131   maximize the reuse of cached OCSP responses.
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166Zhu, et al.             Expires February 8, 2005                [Page 3]
167
168Internet-Draft          OCSP Support for PKINIT              August 2004
169
170
1712.  Conventions Used in This Document
172
173   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
174   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
175   document are to be interpreted as described in [RFC2119].
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222Zhu, et al.             Expires February 8, 2005                [Page 4]
223
224Internet-Draft          OCSP Support for PKINIT              August 2004
225
226
2273.  Message Definition
228
229   A pre-authentication type identifier is defined for this mechanism:
230
231              PA-PK-OCSP-RESPONSE              16
232
233   The corresponding pre-authentication field contains OCSP data as
234   follows:
235
236          PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse
237
238          OcspResponse ::= OCTET STRING
239                         -- contains a complete OCSP response,
240                         -- defined in [RFC2560]
241
242   The client MAY send OCSP responses for certificates used in
243   PA-PK-AS-REQ via a PA-PK-OCSP-RESPONSE.
244
245   The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a
246   PA-PK-OCSP-RESPONSE in response.  The client can request a
247   PA-PK-OCSP-RESPONSE by using an empty sequence in its request.
248
249   Note the lack of integrity protection for the empty or missing OCSP
250   response; lack of an expected OCSP response from the KDC for the
251   KDC's certificates SHOULD be treated as an error by the client,
252   unless it is configured otherwise.
253
254   When using OCSP, the response is signed by the OCSP server, which is
255   trusted by the receiver.  Depending on local policy, further
256   verification of the validity of the OCSP servers MAY need to be done.
257
258   The client and the KDC SHOULD ignore invalid OCSP responses received
259   via this mechanism, and they MAY implement CRL processing logic as a
260   fall-back position, if the OCSP responses received via this mechanism
261   alone are not sufficient for the verification of certificate
262   validity.  The client and/or the KDC MAY ignore a valid OCSP response
263   and perform their own revocation status verification independently.
264
265   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
266   PA-PK-OCSP-RESPONSE from the client.
267
268
269
270
271
272
273
274
275
276
277
278Zhu, et al.             Expires February 8, 2005                [Page 5]
279
280Internet-Draft          OCSP Support for PKINIT              August 2004
281
282
2834.  Security Considerations
284
285   The pre-authentication data in this document do not actually
286   authenticate any principals, and MUST be used in conjunction with
287   PKINIT.
288
289   There is a downgrade attack against clients which want OCSP responses
290   from the KDC for the KDC's certificates.  The clients, however, can
291   treat the absence of valid OCSP responses as an error, based on their
292   local configuration.
293
294
295
296
297
298
299
300
301
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
334Zhu, et al.             Expires February 8, 2005                [Page 6]
335
336Internet-Draft          OCSP Support for PKINIT              August 2004
337
338
3395.  IANA Considerations
340
341   This document defines a new pre-authentication type for use with
342   PKINIT to encode OCSP responses.  The official value for this padata
343   identifier need to be acquired from IANA.
344
3456  References
346
347   [CLARIFICATIONS]
348              Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The
349              Kerberos Network Authentication Service (V5)", 
350              draft-ietf-krb-wg-kerberos-clarifications, Work in 
351              progress.
352
353   [PKINIT]   Tung, B. and B. Neuman, "Public Key Cryptography for
354              Initial Authentication in Kerberos", 
355              draft-ietf-cat-kerberos-pk-init, Work in progress.
356
357   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
358              Requirement Levels", BCP 14, RFC 2119, March 1997.
359
360   [RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
361              Adams, "X.509 Internet Public Key Infrastructure Online
362              Certificate Status Protocol - OCSP", RFC 2560, June 1999.
363
364
365Authors' Addresses
366
367   Larry Zhu
368   Microsoft Corporation
369   One Microsoft Way
370   Redmond, WA  98052
371   US
372
373   EMail: lzhu@microsoft.com
374
375
376   Karthik Jaganathan
377   Microsoft Corporation
378   One Microsoft Way
379   Redmond, WA  98052
380   US
381
382   EMail: karthikj@microsoft.com
383
384
385
386
387
388
389
390
391
392Zhu, et al.             Expires February 8, 2005                [Page 7]
393
394Internet-Draft          OCSP Support for PKINIT              August 2004
395
396
397   Nicolas Williams
398   Sun Microsystems
399   5300 Riata Trace Ct
400   Austin, TX  78727
401   US
402
403   EMail: Nicolas.Williams@sun.com
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448Zhu, et al.             Expires February 8, 2005                [Page 8]
449
450Internet-Draft          OCSP Support for PKINIT              August 2004
451
452
453Intellectual Property Statement
454
455   The IETF takes no position regarding the validity or scope of any
456   Intellectual Property Rights or other rights that might be claimed to
457   pertain to the implementation or use of the technology described in
458   this document or the extent to which any license under such rights
459   might or might not be available; nor does it represent that it has
460   made any independent effort to identify any such rights.  Information
461   on the procedures with respect to rights in RFC documents can be
462   found in BCP 78 and BCP 79.
463
464   Copies of IPR disclosures made to the IETF Secretariat and any
465   assurances of licenses to be made available, or the result of an
466   attempt made to obtain a general license or permission for the use of
467   such proprietary rights by implementers or users of this
468   specification can be obtained from the IETF on-line IPR repository at
469   http://www.ietf.org/ipr.
470
471   The IETF invites any interested party to bring to its attention any
472   copyrights, patents or patent applications, or other proprietary
473   rights that may cover technology that may be required to implement
474   this standard.  Please address the information to the IETF at
475   ietf-ipr@ietf.org.
476
477
478Disclaimer of Validity
479
480   This document and the information contained herein are provided on an
481   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
482   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
483   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
484   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
485   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
486   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
487
488
489Copyright Statement
490
491   Copyright (C) The Internet Society (2004).  This document is subject
492   to the rights, licenses and restrictions contained in BCP 78, and
493   except as set forth therein, the authors retain all their rights.
494
495
496Acknowledgment
497
498   This document was based on conversations among the authors, Jeffrey 
499   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 
500   working group.
501
502
503Zhu, et al.             Expires February 8, 2005                [Page 9]
504
505
506