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