3
NETWORK WORKING GROUP L. Zhu
4
Internet-Draft K. Jaganathan
5
Expires: August 4, 2005 Microsoft Corporation
11
OCSP Support for PKINIT
12
draft-ietf-krb-wg-ocsp-for-pkinit-04
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
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
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."
33
The list of current Internet-Drafts can be accessed at
34
http://www.ietf.org/ietf/1id-abstracts.txt.
36
The list of Internet-Draft Shadow Directories can be accessed at
37
http://www.ietf.org/shadow.html.
39
This Internet-Draft will expire on August 4, 2005.
43
Copyright (C) The Internet Society (2005).
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
54
Zhu, et al. Expires August 4, 2005 [Page 1]
56
Internet-Draft OCSP Support for PKINIT January 2005
59
Version 5 extension that provides for the use of public key
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
110
Zhu, et al. Expires August 4, 2005 [Page 2]
112
Internet-Draft OCSP Support for PKINIT January 2005
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
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
131
By using this OPTIONAL extension, PKINIT clients and the KDC can
132
maximize the reuse of cached OCSP responses.
134
2. Conventions Used in This Document
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].
140
3. Message Definition
142
A pre-authentication type identifier is defined for this mechanism:
144
PA-PK-OCSP-RESPONSE 16
146
The corresponding padata-value field [CLARIFICATIONS] contains the
147
DER [X60] encoding of the following ASN.1 type:
149
PKOcspData ::= SEQUENCE OF OcspResponse
151
OcspResponse ::= OCTET STRING
152
-- contains a complete OCSP response,
153
-- defined in [RFC2560]
155
The client MAY send OCSP responses for certificates used in
156
PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE.
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
166
Zhu, et al. Expires August 4, 2005 [Page 3]
168
Internet-Draft OCSP Support for PKINIT January 2005
171
The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a
172
PA-PK-OCSP-RESPONSE from the client.
174
The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for
175
certificates used in PA-PK-AS-REP [PKINIT].
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.
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
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.
193
4. Security Considerations
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.
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.
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.
222
Zhu, et al. Expires August 4, 2005 [Page 4]
224
Internet-Draft OCSP Support for PKINIT January 2005
227
5. IANA Considerations
229
No IANA actions are required for this document.
233
This document was based on conversations among the authors, Jeffrey
234
Altman, Sam Hartman, Martin Rex and other members of the Kerberos
239
7.1 Normative References
242
RFC-Editor: To be replaced by RFC number for draft-ietf-
243
krb-wg-kerberos-clarifications. Work in Progress.
245
[PKINIT] RFC-Editor: To be replaced by RFC number for draft-ietf-
246
cat-kerberos-pk-init. Work in Progress.
248
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
249
Requirement Levels", BCP 14, RFC 2119, March 1997.
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.
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.
260
7.2 Informative References
263
RFC-Editor: To be replaced by RFC number for draft-deacon-
264
lightweight-ocsp-profile. Work in Progress.
270
Microsoft Corporation
275
Email: lzhu@microsoft.com
281
Zhu, et al. Expires August 4, 2005 [Page 5]
283
Internet-Draft OCSP Support for PKINIT January 2005
287
Microsoft Corporation
292
Email: karthikj@microsoft.com
301
Email: Nicolas.Williams@sun.com
337
Zhu, et al. Expires August 4, 2005 [Page 6]
339
Internet-Draft OCSP Support for PKINIT January 2005
342
Intellectual Property Statement
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.
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.
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
367
Disclaimer of Validity
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.
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.
387
Funding for the RFC Editor function is currently provided by the
393
Zhu, et al. Expires August 4, 2005 [Page 7]
added
removed
doc/standardisation/draft-ietf-krb-wg-ocsp-for-pkinit-04.txt
