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