1
2
3
4
5
6
7Network Working Group                                             L. Zhu
8Request for Comments: 4557                                 K. Jaganathan
9Category: Standards Track                          Microsoft Corporation
10                                                             N. Williams
11                                                        Sun Microsystems
12                                                               June 2006
13
14
15         Online Certificate Status Protocol (OCSP) Support for
16                      Public Key Cryptography for
17              Initial Authentication in Kerberos (PKINIT)
18
19Status of This Memo
20
21   This document specifies an Internet standards track protocol for the
22   Internet community, and requests discussion and suggestions for
23   improvements.  Please refer to the current edition of the "Internet
24   Official Protocol Standards" (STD 1) for the standardization state
25   and status of this protocol.  Distribution of this memo is unlimited.
26
27Copyright Notice
28
29   Copyright (C) The Internet Society (2006).
30
31Abstract
32
33   This document defines a mechanism to enable in-band transmission of
34   Online Certificate Status Protocol (OCSP) responses in the Kerberos
35   network authentication protocol.  These responses are used to verify
36   the validity of the certificates used in Public Key Cryptography for
37   Initial Authentication in Kerberos (PKINIT), which is the Kerberos
38   Version 5 extension that provides for the use of public key
39   cryptography.
40
41Table of Contents
42
43   1. Introduction ....................................................2
44   2. Conventions Used in This Document ...............................2
45   3. Message Definition ..............................................2
46   4. Security Considerations .........................................3
47   5. Acknowledgements ................................................4
48   6. References ......................................................4
49      6.1. Normative References .......................................4
50      6.2. Informative References .....................................4
51
52
53
54
55
56
57
58Zhu, et al.                 Standards Track                     [Page 1]
59
60RFC 4557                OCSP Support for PKINIT                June 2006
61
62
631.  Introduction
64
65   Online Certificate Status Protocol (OCSP) [RFC2560] enables
66   applications to obtain timely information regarding the revocation
67   status of a certificate.  Because OCSP responses are well bounded and
68   small in size, constrained clients may wish to use OCSP to check the
69   validity of the certificates for Kerberos Key Distribution Center
70   (KDC) in order to avoid transmission of large Certificate Revocation
71   Lists (CRLs) and therefore save bandwidth on constrained networks
72   [OCSP-PROFILE].
73
74   This document defines a pre-authentication type [RFC4120], where the
75   client and the KDC MAY piggyback OCSP responses for certificates used
76   in authentication exchanges, as defined in [RFC4556].
77
78   By using this OPTIONAL extension, PKINIT clients and the KDC can
79   maximize the reuse of cached OCSP responses.
80
812.  Conventions Used in This Document
82
83   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
84   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
85   and "OPTIONAL" are to be interpreted as described in [RFC2119].
86
873.  Message Definition
88
89   A pre-authentication type identifier is defined for this mechanism:
90
91              PA-PK-OCSP-RESPONSE              18
92
93   The corresponding padata-value field [RFC4120] contains the DER [X60]
94   encoding of the following ASN.1 type:
95
96          PKOcspData ::= SEQUENCE OF OcspResponse
97                         -- If more than one OcspResponse is
98                         -- included, the first OcspResponse
99                         -- MUST contain the OCSP response
100                         -- for the signer's certificate.
101                         -- The signer refers to the client for
102                         -- AS-REQ, and the KDC for the AS-REP,
103                         -- respectively.
104
105          OcspResponse ::= OCTET STRING
106                         -- Contains a complete OCSP response,
107                         -- as defined in [RFC2560].
108
109   The client MAY send OCSP responses for certificates used in PA-PK-
110   AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE.
111
112
113
114Zhu, et al.                 Standards Track                     [Page 2]
115
116RFC 4557                OCSP Support for PKINIT                June 2006
117
118
119   The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK-
120   OCSP-RESPONSE containing OCSP responses for certificates used in the
121   KDC's PA-PK-AS-REP.  The client can request a PA-PK-OCSP-RESPONSE by
122   using a PKOcspData containing an empty sequence.
123
124   The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
125   PA-PK-OCSP-RESPONSE from the client.
126
127   The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
128   certificates used in PA-PK-AS-REP [RFC4556].
129
130   Note the lack of integrity protection for the empty or missing OCSP
131   response; lack of an expected OCSP response from the KDC for the
132   KDC's certificates SHOULD be treated as an error by the client,
133   unless it is configured otherwise.
134
135   When using OCSP, the response is signed by the OCSP server, which is
136   trusted by the receiver.  Depending on local policy, further
137   verification of the validity of the OCSP servers may be needed
138
139   The client and the KDC SHOULD ignore invalid OCSP responses received
140   via this mechanism, and they MAY implement CRL processing logic as a
141   fall-back position, if the OCSP responses received via this mechanism
142   alone are not sufficient for the verification of certificate
143   validity.  The client and/or the KDC MAY ignore a valid OCSP response
144   and perform its own revocation status verification independently.
145
1464.  Security Considerations
147
148   The pre-authentication data in this document do not actually
149   authenticate any principals, but are designed to be used in
150   conjunction with PKINIT.
151
152   There is no binding between PA-PK-OCSP-RESPONSE pre-authentication
153   data and PKINIT pre-authentication data other than a given OCSP
154   response corresponding to a certificate used in a PKINIT pre-
155   authentication data element.  Attacks involving removal or
156   replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements
157   are, at worst, downgrade attacks, where a PKINIT client or KDC would
158   proceed without use of CRLs or OCSP for certificate validation, or
159   denial-of-service attacks, where a PKINIT client or KDC that cannot
160   validate the other's certificate without an accompanying OCSP
161   response might reject the AS exchange or might have to download very
162   large CRLs in order to continue.  Kerberos V does not protect against
163   denial-of-service attacks; therefore, the denial-of-service aspect of
164   these attacks is acceptable.
165
166
167
168
169
170Zhu, et al.                 Standards Track                     [Page 3]
171
172RFC 4557                OCSP Support for PKINIT                June 2006
173
174
175   If a PKINIT client or KDC cannot validate certificates without the
176   aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS
177   exchange, possibly according to local configuration.
178
1795.  Acknowledgements
180
181   This document was based on conversations among the authors, Jeffrey
182   Altman, Sam Hartman, Martin Rex, and other members of the Kerberos
183   working group.
184
1856.  References
186
1876.1.  Normative References
188
189   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
190                  Requirement Levels", BCP 14, RFC 2119, March 1997.
191
192   [RFC2560]      Myers, M., Ankney, R., Malpani, A., Galperin, S., and
193                  C. Adams, "X.509 Internet Public Key Infrastructure
194                  Online Certificate Status Protocol - OCSP", RFC 2560,
195                  June 1999.
196
197   [RFC4120]      Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
198                  Kerberos Network Authentication Service (V5)", RFC
199                  4120, July 2005.
200
201   [RFC4556]      Zhu, L. and B. Tung, "Public Key Cryptography for
202                  Initial Authentication in Kerberos (PKINIT)", RFC
203                  4556, June 2006.
204
205   [X690]         ASN.1 encoding rules: Specification of Basic Encoding
206                  Rules (BER), Canonical Encoding Rules (CER) and
207                  Distinguished Encoding Rules (DER), ITU-T
208                  Recommendation X.690 (1997) | ISO/IEC International
209                  Standard 8825-1:1998.
210
2116.2.  Informative References
212
213   [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for
214                  High Volume Environments", Work in Progress, May 2006.
215
216
217
218
219
220
221
222
223
224
225
226Zhu, et al.                 Standards Track                     [Page 4]
227
228RFC 4557                OCSP Support for PKINIT                June 2006
229
230
231Authors' Addresses
232
233   Larry Zhu
234   Microsoft Corporation
235   One Microsoft Way
236   Redmond, WA  98052
237   US
238
239   EMail: lzhu@microsoft.com
240
241
242   Karthik Jaganathan
243   Microsoft Corporation
244   One Microsoft Way
245   Redmond, WA  98052
246   US
247
248   EMail: karthikj@microsoft.com
249
250
251   Nicolas Williams
252   Sun Microsystems
253   5300 Riata Trace Ct
254   Austin, TX  78727
255   US
256
257   EMail: Nicolas.Williams@sun.com
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Zhu, et al.                 Standards Track                     [Page 5]
283
284RFC 4557                OCSP Support for PKINIT                June 2006
285
286
287Full Copyright Statement
288
289   Copyright (C) The Internet Society (2006).
290
291   This document is subject to the rights, licenses and restrictions
292   contained in BCP 78, and except as set forth therein, the authors
293   retain all their rights.
294
295   This document and the information contained herein are provided on an
296   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
297   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
298   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
299   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
300   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
301   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
302
303Intellectual Property
304
305   The IETF takes no position regarding the validity or scope of any
306   Intellectual Property Rights or other rights that might be claimed to
307   pertain to the implementation or use of the technology described in
308   this document or the extent to which any license under such rights
309   might or might not be available; nor does it represent that it has
310   made any independent effort to identify any such rights.  Information
311   on the procedures with respect to rights in RFC documents can be
312   found in BCP 78 and BCP 79.
313
314   Copies of IPR disclosures made to the IETF Secretariat and any
315   assurances of licenses to be made available, or the result of an
316   attempt made to obtain a general license or permission for the use of
317   such proprietary rights by implementers or users of this
318   specification can be obtained from the IETF on-line IPR repository at
319   http://www.ietf.org/ipr.
320
321   The IETF invites any interested party to bring to its attention any
322   copyrights, patents or patent applications, or other proprietary
323   rights that may cover technology that may be required to implement
324   this standard.  Please address the information to the IETF at
325   ietf-ipr@ietf.org.
326
327Acknowledgement
328
329   Funding for the RFC Editor function is provided by the IETF
330   Administrative Support Activity (IASA).
331
332
333
334
335
336
337
338Zhu, et al.                 Standards Track                     [Page 6]
339
340