1NETWORK WORKING GROUP L. Zhu 2Internet-Draft K. Jaganathan 3Expires: May 21, 2005 Microsoft Corporation 4 N. Williams 5 Sun Microsystems 6 November 20, 2004 7 8 9 OCSP Support for PKINIT 10 draft-ietf-krb-wg-ocsp-for-pkinit-02 11 12Status of this Memo 13 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on May 21, 2005. 38 39Copyright Notice 40 41 Copyright (C) The Internet Society (2004). 42 43Abstract 44 45 This document defines a mechanism to enable in-band transmission of 46 OCSP responses. These responses are used to verify the validity of 47 the certificates used in PKINIT - the Kerberos Version 5 extension 48 that provides for the use of public key cryptography. 49 50 51 52 53Zhu, et al. Expires May 21, 2005 [Page 1] 54 55Internet-Draft OCSP Support for PKINIT November 2004 56 57 58Table of Contents 59 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Conventions Used in This Document . . . . . . . . . . . . . 4 62 3. Message Definition . . . . . . . . . . . . . . . . . . . . . 5 63 4. Security Considerations . . . . . . . . . . . . . . . . . . 6 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 65 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . 8 66 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 68 Intellectual Property and Copyright Statements . . . . . . . 10 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 109Zhu, et al. Expires May 21, 2005 [Page 2] 110 111Internet-Draft OCSP Support for PKINIT November 2004 112 113 1141. Introduction 115 116 Online Certificate Status Protocol (OCSP) [RFC2560] enables 117 applications to obtain timely information regarding the revocation 118 status of a certificate. Because OCSP responses are well-bounded and 119 small in size, constrained clients may wish to use OCSP to check the 120 validity of KDC certificates in order to avoid transmission of large 121 Certificate Revocation Lists (CRLs) and therefore save bandwidth on 122 constrained networks [OCSP-PROFILE]. 123 124 This document defines a pre-authentication type [CLARIFICATIONS], 125 where the client and the KDC MAY piggyback OCSP responses for 126 certificates used in authentication exchanges, as defined in 127 [PKINIT]. 128 129 By using this OPTIONAL extension, PKINIT clients and the KDC can 130 maximize the reuse of cached OCSP responses. 131 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 165Zhu, et al. Expires May 21, 2005 [Page 3] 166 167Internet-Draft OCSP Support for PKINIT November 2004 168 169 1702. Conventions Used in This Document 171 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 175 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 221Zhu, et al. Expires May 21, 2005 [Page 4] 222 223Internet-Draft OCSP Support for PKINIT November 2004 224 225 2263. Message Definition 227 228 A pre-authentication type identifier is defined for this mechanism: 229 230 PA-PK-OCSP-RESPONSE 16 231 232 The corresponding pre-authentication field contains OCSP data as 233 follows: 234 235 PA-PK-OCSP-DATA ::= SEQUENCE OF OcspResponse 236 237 OcspResponse ::= OCTET STRING 238 -- contains a complete OCSP response, 239 -- defined in [RFC2560] 240 241 The client MAY send OCSP responses for certificates used in 242 PA-PK-AS-REQ [PKINIT] via a PA-PK-OCSP-RESPONSE. 243 244 The KDC that receives a PA-PK-OCSP-RESPONSE the SHOULD send a 245 PA-PK-OCSP-RESPONSE in response. The client can request a 246 PA-PK-OCSP-RESPONSE by using an empty sequence in its request. 247 248 The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a 249 PA-PK-OCSP-RESPONSE from the client. 250 251 The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for 252 certificates used in PA-PK-AS-REP [PKINIT]. 253 254 Note the lack of integrity protection for the empty or missing OCSP 255 response; lack of an expected OCSP response from the KDC for the 256 KDC's certificates SHOULD be treated as an error by the client, 257 unless it is configured otherwise. 258 259 When using OCSP, the response is signed by the OCSP server, which is 260 trusted by the receiver. Depending on local policy, further 261 verification of the validity of the OCSP servers MAY need to be done. 262 263 The client and the KDC SHOULD ignore invalid OCSP responses received 264 via this mechanism, and they MAY implement CRL processing logic as a 265 fall-back position, if the OCSP responses received via this mechanism 266 alone are not sufficient for the verification of certificate 267 validity. The client and/or the KDC MAY ignore a valid OCSP response 268 and perform their own revocation status verification independently. 269 270 271 272 273 274 275 276 277Zhu, et al. Expires May 21, 2005 [Page 5] 278 279Internet-Draft OCSP Support for PKINIT November 2004 280 281 2824. Security Considerations 283 284 The pre-authentication data in this document do not actually 285 authenticate any principals, and MUST be used in conjunction with 286 PKINIT. 287 288 There is a downgrade attack against clients which want OCSP responses 289 from the KDC for the KDC's certificates. The clients, however, can 290 treat the absence of valid OCSP responses as an error, based on their 291 local configuration. 292 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 333Zhu, et al. Expires May 21, 2005 [Page 6] 334 335Internet-Draft OCSP Support for PKINIT November 2004 336 337 3385. IANA Considerations 339 340 This document defines a new pre-authentication type for use with 341 PKINIT to encode OCSP responses. The official value for this padata 342 identifier need to be acquired from IANA. 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389Zhu, et al. Expires May 21, 2005 [Page 7] 390 391Internet-Draft OCSP Support for PKINIT November 2004 392 393 3946. Acknowledgements 395 396 This document was based on conversations among the authors, Jeffrey 397 Altman, Sam Hartman, Martin Rex and other members of the Kerberos 398 working group. 399 4007 References 401 402 [CLARIFICATIONS] 403 Neuman, B., Yu, Y., Hartman, S. and K. Raeburn, "The 404 Kerberos Network Authentication Service (V5)", 405 draft-ietf-krb-wg-kerberos-clarifications, Work in 406 progress. 407 408 [OCSP-PROFILE] 409 Deacon, A. and R. Hurst, "Lightweight OCSP Profile for 410 High Volume Environments", 411 draft-ietf-pkix-lightweight-ocsp-profile, Work in 412 progress. 413 414 [PKINIT] Tung, B., Neuman, B. and S. Medvinsky, "Public Key 415 Cryptography for Initial Authentication in Kerberos", 416 draft-ietf-cat-kerberos-pk-init, Work in progress. 417 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 421 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C. 422 Adams, "X.509 Internet Public Key Infrastructure Online 423 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 424 425 426Authors' Addresses 427 428 Larry Zhu 429 Microsoft Corporation 430 One Microsoft Way 431 Redmond, WA 98052 432 US 433 434 EMail: lzhu@microsoft.com 435 436 437 Karthik Jaganathan 438 Microsoft Corporation 439 One Microsoft Way 440 Redmond, WA 98052 441 US 442 443 EMail: karthikj@microsoft.com 444 445 446 447 448Zhu, et al. Expires May 21, 2005 [Page 8] 449 450Internet-Draft OCSP Support for PKINIT November 2004 451 452 453 Nicolas Williams 454 Sun Microsystems 455 5300 Riata Trace Ct 456 Austin, TX 78727 457 US 458 459 EMail: Nicolas.Williams@sun.com 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504Zhu, et al. Expires May 21, 2005 [Page 9] 505 506Internet-Draft OCSP Support for PKINIT November 2004 507 508 509Intellectual Property Statement 510 511 The IETF takes no position regarding the validity or scope of any 512 Intellectual Property Rights or other rights that might be claimed to 513 pertain to the implementation or use of the technology described in 514 this document or the extent to which any license under such rights 515 might or might not be available; nor does it represent that it has 516 made any independent effort to identify any such rights. Information 517 on the procedures with respect to rights in RFC documents can be 518 found in BCP 78 and BCP 79. 519 520 Copies of IPR disclosures made to the IETF Secretariat and any 521 assurances of licenses to be made available, or the result of an 522 attempt made to obtain a general license or permission for the use of 523 such proprietary rights by implementers or users of this 524 specification can be obtained from the IETF on-line IPR repository at 525 http://www.ietf.org/ipr. 526 527 The IETF invites any interested party to bring to its attention any 528 copyrights, patents or patent applications, or other proprietary 529 rights that may cover technology that may be required to implement 530 this standard. Please address the information to the IETF at 531 ietf-ipr@ietf.org. 532 533 534Disclaimer of Validity 535 536 This document and the information contained herein are provided on an 537 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 538 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 539 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 540 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 541 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 542 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 543 544 545Copyright Statement 546 547 Copyright (C) The Internet Society (2004). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 550 551 552Acknowledgment 553 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society. 556 557 558 559 560Zhu, et al. Expires May 21, 2005 [Page 10] 561 562 563