1 2NETWORK WORKING GROUP L. Zhu 3Internet-Draft K. Jaganathan 4Expires: February 8, 2005 Microsoft Corporation 5 N. Williams 6 Sun Microsystems 7 August 10, 2004 8 9 10 OCSP Support for PKINIT 11 draft-ietf-krb-wg-ocsp-for-pkinit-00 12 13Status of this Memo 14 15 This document is an Internet-Draft and is subject to all provisions 16 of section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 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 25 Internet-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 February 8, 2005. 39 40Copyright Notice 41 42 Copyright (C) The Internet Society (2004). 43 44Abstract 45 46 This document defines a mechanism to enable in-band transmission of 47 OCSP responses. These responses are used to verify the validity of 48 the certificates used in PKINIT - the Kerberos Version 5 extension 49 that provides for the use of public key cryptography. 50 51 52 53 54Zhu, et al. Expires February 8, 2005 [Page 1] 55 56Internet-Draft OCSP Support for PKINIT August 2004 57 58 59Table of Contents 60 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 63 3. Message Definition . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 68 Intellectual Property and Copyright Statements . . . . . . . . 9 69 70 71 72 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 110Zhu, et al. Expires February 8, 2005 [Page 2] 111 112Internet-Draft OCSP Support for PKINIT August 2004 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 KDC certificates in order to avoid transmission of large 122 Certificate Revocation Lists (CRLs) and therefore save bandwidth on 123 constrained networks. 124 125 This document defines a pre-authentication type [CLARIFICATIONS], 126 where the client and the KDC MAY piggyback OCSP responses for 127 certificates used in authentication exchanges, as defined in 128 [PKINIT]. 129 130 By using this OPTIONAL extension, PKINIT clients and the KDC can 131 maximize the reuse of cached OCSP responses. 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166Zhu, et al. Expires February 8, 2005 [Page 3] 167 168Internet-Draft OCSP Support for PKINIT August 2004 169 170 1712. Conventions Used in This Document 172 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 175 document are to be interpreted as described in [RFC2119]. 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222Zhu, et al. Expires February 8, 2005 [Page 4] 223 224Internet-Draft OCSP Support for PKINIT August 2004 225 226 2273. Message Definition 228 229 A pre-authentication type identifier is defined for this mechanism: 230 231 PA-PK-OCSP-RESPONSE 16 232 233 The corresponding pre-authentication field contains OCSP data as 234 follows: 235 236 PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse 237 238 OcspResponse ::= OCTET STRING 239 -- contains a complete OCSP response, 240 -- defined in [RFC2560] 241 242 The client MAY send OCSP responses for certificates used in 243 PA-PK-AS-REQ via a PA-PK-OCSP-RESPONSE. 244 245 The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a 246 PA-PK-OCSP-RESPONSE in response. The client can request a 247 PA-PK-OCSP-RESPONSE by using an empty sequence in its request. 248 249 Note the lack of integrity protection for the empty or missing OCSP 250 response; lack of an expected OCSP response from the KDC for the 251 KDC's certificates SHOULD be treated as an error by the client, 252 unless it is configured otherwise. 253 254 When using OCSP, the response is signed by the OCSP server, which is 255 trusted by the receiver. Depending on local policy, further 256 verification of the validity of the OCSP servers MAY need to be done. 257 258 The client and the KDC SHOULD ignore invalid OCSP responses received 259 via this mechanism, and they MAY implement CRL processing logic as a 260 fall-back position, if the OCSP responses received via this mechanism 261 alone are not sufficient for the verification of certificate 262 validity. The client and/or the KDC MAY ignore a valid OCSP response 263 and perform their own revocation status verification independently. 264 265 The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a 266 PA-PK-OCSP-RESPONSE from the client. 267 268 269 270 271 272 273 274 275 276 277 278Zhu, et al. Expires February 8, 2005 [Page 5] 279 280Internet-Draft OCSP Support for PKINIT August 2004 281 282 2834. Security Considerations 284 285 The pre-authentication data in this document do not actually 286 authenticate any principals, and MUST be used in conjunction with 287 PKINIT. 288 289 There is a downgrade attack against clients which want OCSP responses 290 from the KDC for the KDC's certificates. The clients, however, can 291 treat the absence of valid OCSP responses as an error, based on their 292 local configuration. 293 294 295 296 297 298 299 300 301 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 334Zhu, et al. Expires February 8, 2005 [Page 6] 335 336Internet-Draft OCSP Support for PKINIT August 2004 337 338 3395. IANA Considerations 340 341 This document defines a new pre-authentication type for use with 342 PKINIT to encode OCSP responses. The official value for this padata 343 identifier need to be acquired from IANA. 344 3456 References 346 347 [CLARIFICATIONS] 348 Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The 349 Kerberos Network Authentication Service (V5)", 350 draft-ietf-krb-wg-kerberos-clarifications, Work in 351 progress. 352 353 [PKINIT] Tung, B. and B. Neuman, "Public Key Cryptography for 354 Initial Authentication in Kerberos", 355 draft-ietf-cat-kerberos-pk-init, Work in progress. 356 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 359 360 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. 361 Adams, "X.509 Internet Public Key Infrastructure Online 362 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 363 364 365Authors' Addresses 366 367 Larry Zhu 368 Microsoft Corporation 369 One Microsoft Way 370 Redmond, WA 98052 371 US 372 373 EMail: lzhu@microsoft.com 374 375 376 Karthik Jaganathan 377 Microsoft Corporation 378 One Microsoft Way 379 Redmond, WA 98052 380 US 381 382 EMail: karthikj@microsoft.com 383 384 385 386 387 388 389 390 391 392Zhu, et al. Expires February 8, 2005 [Page 7] 393 394Internet-Draft OCSP Support for PKINIT August 2004 395 396 397 Nicolas Williams 398 Sun Microsystems 399 5300 Riata Trace Ct 400 Austin, TX 78727 401 US 402 403 EMail: Nicolas.Williams@sun.com 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448Zhu, et al. Expires February 8, 2005 [Page 8] 449 450Internet-Draft OCSP Support for PKINIT August 2004 451 452 453Intellectual Property Statement 454 455 The IETF takes no position regarding the validity or scope of any 456 Intellectual Property Rights or other rights that might be claimed to 457 pertain to the implementation or use of the technology described in 458 this document or the extent to which any license under such rights 459 might or might not be available; nor does it represent that it has 460 made any independent effort to identify any such rights. Information 461 on the procedures with respect to rights in RFC documents can be 462 found in BCP 78 and BCP 79. 463 464 Copies of IPR disclosures made to the IETF Secretariat and any 465 assurances of licenses to be made available, or the result of an 466 attempt made to obtain a general license or permission for the use of 467 such proprietary rights by implementers or users of this 468 specification can be obtained from the IETF on-line IPR repository at 469 http://www.ietf.org/ipr. 470 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary 473 rights that may cover technology that may be required to implement 474 this standard. Please address the information to the IETF at 475 ietf-ipr@ietf.org. 476 477 478Disclaimer of Validity 479 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 483 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 484 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 485 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 487 488 489Copyright Statement 490 491 Copyright (C) The Internet Society (2004). This document is subject 492 to the rights, licenses and restrictions contained in BCP 78, and 493 except as set forth therein, the authors retain all their rights. 494 495 496Acknowledgment 497 498 This document was based on conversations among the authors, Jeffrey 499 Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 500 working group. 501 502 503Zhu, et al. Expires February 8, 2005 [Page 9] 504 505 506