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