1
2
3
4NETWORK WORKING GROUP                                             L. Zhu
5Internet-Draft                                             K. Jaganathan
6Expires: January 20, 2006                          Microsoft Corporation
7                                                             N. Williams
8                                                        Sun Microsystems
9                                                           July 19, 2005
10
11
12                        OCSP Support for PKINIT
13                  draft-ietf-krb-wg-ocsp-for-pkinit-06
14
15Status of this Memo
16
17   By submitting this Internet-Draft, each author represents that any
18   applicable patent or other IPR claims of which he or she is aware
19   have been or will be disclosed, and any of which he or she becomes
20   aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Internet-
25   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 January 20, 2006.
39
40Copyright Notice
41
42   Copyright (C) The Internet Society (2005).
43
44Abstract
45
46   This document defines a mechanism to enable in-band transmission of
47   Online Certificate Status Protocol (OCSP) responses in the Kerberos
48   network authentication protocol.  These responses are used to verify
49   the validity of the certificates used in PKINIT - the Kerberos
50   Version 5 extension that provides for the use of public key
51   cryptography.
52
53
54
55Zhu, et al.             Expires January 20, 2006                [Page 1]
56
57Internet-Draft           OCSP Support for PKINIT               July 2005
58
59
60Table of Contents
61
62   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
63   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
64   3.  Message Definition . . . . . . . . . . . . . . . . . . . . . .  3
65   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  4
66   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
67   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  5
68   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  5
69     7.1   Normative References . . . . . . . . . . . . . . . . . . .  5
70     7.2   Informative References . . . . . . . . . . . . . . . . . .  5
71       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  5
72       Intellectual Property and Copyright Statements . . . . . . . .  7
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
110
111Zhu, et al.             Expires January 20, 2006                [Page 2]
112
113Internet-Draft           OCSP Support for PKINIT               July 2005
114
115
1161.  Introduction
117
118   Online Certificate Status Protocol (OCSP) [RFC2560] enables
119   applications to obtain timely information regarding the revocation
120   status of a certificate.  Because OCSP responses are well-bounded and
121   small in size, constrained clients may wish to use OCSP to check the
122   validity of the certificates for Kerberos Key Distribution Center
123   (KDC) in order to avoid transmission of large Certificate Revocation
124   Lists (CRLs) and therefore save bandwidth on constrained networks
125   [OCSP-PROFILE].
126
127   This document defines a pre-authentication type [RFC4120], where the
128   client and the KDC MAY piggyback OCSP responses for certificates used
129   in authentication exchanges, as defined in [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              18
145
146   The corresponding padata-value field [RFC4120] contains the DER [X60]
147   encoding of the following ASN.1 type:
148
149          PKOcspData ::= SEQUENCE OF OcspResponse
150                         -- If more than one OcspResponse is
151                         -- included, the first OcspResponse
152                         -- MUST contain the OCSP response
153                         -- for the signer's certificate.
154                         -- The signer refers to the client for
155                         -- AS-REQ, and the KDC for the AS-REP,
156                         -- respectively.
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
166
167Zhu, et al.             Expires January 20, 2006                [Page 3]
168
169Internet-Draft           OCSP Support for PKINIT               July 2005
170
171
172   The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK-
173   OCSP-RESPONSE containing OCSP responses for certificates used in the
174   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
175   using a PKOcspData containing an empty sequence.
176
177   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA-
178   PK-OCSP-RESPONSE from the client.
179
180   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
181   certificates used in PA-PK-AS-REP [PKINIT].
182
183   Note the lack of integrity protection for the empty or missing OCSP
184   response; lack of an expected OCSP response from the KDC for the
185   KDC's certificates SHOULD be treated as an error by the client,
186   unless it is configured otherwise.
187
188   When using OCSP, the response is signed by the OCSP server, which is
189   trusted by the receiver.  Depending on local policy, further
190   verification of the validity of the OCSP servers may be needed
191
192   The client and the KDC SHOULD ignore invalid OCSP responses received
193   via this mechanism, and they MAY implement CRL processing logic as a
194   fall-back position, if the OCSP responses received via this mechanism
195   alone are not sufficient for the verification of certificate
196   validity.  The client and/or the KDC MAY ignore a valid OCSP response
197   and perform their own revocation status verification independently.
198
1994.  Security Considerations
200
201   The pre-authentication data in this document do not actually
202   authenticate any principals, but is designed to be used in
203   conjunction with PKINIT.
204
205   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
206   data and PKINIT pre-authentication data other than a given OCSP
207   response corresponding to a certificate used in a PKINIT pre-
208   authentication data element.  Attacks involving removal or
209   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
210   are, at worst, downgrade attacks, where a PKINIT client or KDC would
211   proceed without use of CRLs or OCSP for certificate validation, or
212   denial of service attacks, where a PKINIT client or KDC that cannot
213   validate the other's certificate without an accompanying OCSP
214   response might reject the AS exchange or where they might have to
215   download very large CRLs in order to continue.  Kerberos V does not
216   protect against denial-of-service attacks, therefore the denial-of-
217   service aspect of these attacks are acceptable.
218
219   If a PKINIT client or KDC cannot validate certificates without the
220
221
222
223Zhu, et al.             Expires January 20, 2006                [Page 4]
224
225Internet-Draft           OCSP Support for PKINIT               July 2005
226
227
228   aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS
229   exchange, possibly according to local configuration.
230
2315.  IANA Considerations
232
233   No IANA actions are required for this document.
234
2356.  Acknowledgements
236
237   This document was based on conversations among the authors, Jeffrey
238   Altman, Sam Hartman, Martin Rex and other members of the Kerberos
239   working group.
240
2417.  References
242
2437.1  Normative References
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   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
256              Kerberos Network Authentication Service (V5)", RFC 4120,
257              July 2005.
258
259   [X690]     ASN.1 encoding rules: Specification of Basic Encoding 
260              Rules (BER), Canonical Encoding Rules (CER) and 
261              Distinguished Encoding Rules (DER), ITU-T Recommendation 
262              X.690 (1997) | ISO/IEC International Standard 8825-1:1998.
263
2647.2  Informative References
265
266   [OCSP-PROFILE]
267              RFC-Editor: To be replaced by RFC number for draft-deacon-
268              lightweight-ocsp-profile.  Work in Progress.  
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283Zhu, et al.             Expires January 20, 2006                [Page 5]
284
285Internet-Draft           OCSP Support for PKINIT               July 2005
286
287
288Authors' Addresses
289
290   Larry Zhu
291   Microsoft Corporation
292   One Microsoft Way
293   Redmond, WA  98052
294   US
295
296   Email: lzhu@microsoft.com
297
298
299   Karthik Jaganathan
300   Microsoft Corporation
301   One Microsoft Way
302   Redmond, WA  98052
303   US
304
305   Email: karthikj@microsoft.com
306
307
308   Nicolas Williams
309   Sun Microsystems
310   5300 Riata Trace Ct
311   Austin, TX  78727
312   US
313
314   Email: Nicolas.Williams@sun.com
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339Zhu, et al.             Expires January 20, 2006                [Page 6]
340
341Internet-Draft           OCSP Support for PKINIT               July 2005
342
343
344Intellectual Property Statement
345
346   The IETF takes no position regarding the validity or scope of any
347   Intellectual Property Rights or other rights that might be claimed to
348   pertain to the implementation or use of the technology described in
349   this document or the extent to which any license under such rights
350   might or might not be available; nor does it represent that it has
351   made any independent effort to identify any such rights.  Information
352   on the procedures with respect to rights in RFC documents can be
353   found in BCP 78 and BCP 79.
354
355   Copies of IPR disclosures made to the IETF Secretariat and any
356   assurances of licenses to be made available, or the result of an
357   attempt made to obtain a general license or permission for the use of
358   such proprietary rights by implementers or users of this
359   specification can be obtained from the IETF on-line IPR repository at
360   http://www.ietf.org/ipr.
361
362   The IETF invites any interested party to bring to its attention any
363   copyrights, patents or patent applications, or other proprietary
364   rights that may cover technology that may be required to implement
365   this standard.  Please address the information to the IETF at
366   ietf-ipr@ietf.org.
367
368
369Disclaimer of Validity
370
371   This document and the information contained herein are provided on an
372   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
373   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
374   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
375   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
376   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
377   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
378
379
380Copyright Statement
381
382   Copyright (C) The Internet Society (2005).  This document is subject
383   to the rights, licenses and restrictions contained in BCP 78, and
384   except as set forth therein, the authors retain all their rights.
385
386
387Acknowledgment
388
389   Funding for the RFC Editor function is currently provided by the
390   Internet Society.
391
392
393
394
395Zhu, et al.             Expires January 20, 2006                [Page 7]
396
397
398