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