1 2 3 4 5 6 7Network Working Group L. Zhu 8Request for Comments: 4557 K. Jaganathan 9Category: Standards Track Microsoft Corporation 10 N. Williams 11 Sun Microsystems 12 June 2006 13 14 15 Online Certificate Status Protocol (OCSP) Support for 16 Public Key Cryptography for 17 Initial Authentication in Kerberos (PKINIT) 18 19Status of This Memo 20 21 This document specifies an Internet standards track protocol for the 22 Internet community, and requests discussion and suggestions for 23 improvements. Please refer to the current edition of the "Internet 24 Official Protocol Standards" (STD 1) for the standardization state 25 and status of this protocol. Distribution of this memo is unlimited. 26 27Copyright Notice 28 29 Copyright (C) The Internet Society (2006). 30 31Abstract 32 33 This document defines a mechanism to enable in-band transmission of 34 Online Certificate Status Protocol (OCSP) responses in the Kerberos 35 network authentication protocol. These responses are used to verify 36 the validity of the certificates used in Public Key Cryptography for 37 Initial Authentication in Kerberos (PKINIT), which is the Kerberos 38 Version 5 extension that provides for the use of public key 39 cryptography. 40 41Table of Contents 42 43 1. Introduction ....................................................2 44 2. Conventions Used in This Document ...............................2 45 3. Message Definition ..............................................2 46 4. Security Considerations .........................................3 47 5. Acknowledgements ................................................4 48 6. References ......................................................4 49 6.1. Normative References .......................................4 50 6.2. Informative References .....................................4 51 52 53 54 55 56 57 58Zhu, et al. Standards Track [Page 1] 59 60RFC 4557 OCSP Support for PKINIT June 2006 61 62 631. Introduction 64 65 Online Certificate Status Protocol (OCSP) [RFC2560] enables 66 applications to obtain timely information regarding the revocation 67 status of a certificate. Because OCSP responses are well bounded and 68 small in size, constrained clients may wish to use OCSP to check the 69 validity of the certificates for Kerberos Key Distribution Center 70 (KDC) in order to avoid transmission of large Certificate Revocation 71 Lists (CRLs) and therefore save bandwidth on constrained networks 72 [OCSP-PROFILE]. 73 74 This document defines a pre-authentication type [RFC4120], where the 75 client and the KDC MAY piggyback OCSP responses for certificates used 76 in authentication exchanges, as defined in [RFC4556]. 77 78 By using this OPTIONAL extension, PKINIT clients and the KDC can 79 maximize the reuse of cached OCSP responses. 80 812. Conventions Used in This Document 82 83 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 84 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 85 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 86 873. Message Definition 88 89 A pre-authentication type identifier is defined for this mechanism: 90 91 PA-PK-OCSP-RESPONSE 18 92 93 The corresponding padata-value field [RFC4120] contains the DER [X60] 94 encoding of the following ASN.1 type: 95 96 PKOcspData ::= SEQUENCE OF OcspResponse 97 -- If more than one OcspResponse is 98 -- included, the first OcspResponse 99 -- MUST contain the OCSP response 100 -- for the signer's certificate. 101 -- The signer refers to the client for 102 -- AS-REQ, and the KDC for the AS-REP, 103 -- respectively. 104 105 OcspResponse ::= OCTET STRING 106 -- Contains a complete OCSP response, 107 -- as defined in [RFC2560]. 108 109 The client MAY send OCSP responses for certificates used in PA-PK- 110 AS-REQ [RFC4556] via a PA-PK-OCSP-RESPONSE. 111 112 113 114Zhu, et al. Standards Track [Page 2] 115 116RFC 4557 OCSP Support for PKINIT June 2006 117 118 119 The KDC that receives a PA-PK-OCSP-RESPONSE SHOULD send a PA-PK- 120 OCSP-RESPONSE containing OCSP responses for certificates used in the 121 KDC's PA-PK-AS-REP. The client can request a PA-PK-OCSP-RESPONSE by 122 using a PKOcspData containing an empty sequence. 123 124 The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a 125 PA-PK-OCSP-RESPONSE from the client. 126 127 The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for 128 certificates used in PA-PK-AS-REP [RFC4556]. 129 130 Note the lack of integrity protection for the empty or missing OCSP 131 response; lack of an expected OCSP response from the KDC for the 132 KDC's certificates SHOULD be treated as an error by the client, 133 unless it is configured otherwise. 134 135 When using OCSP, the response is signed by the OCSP server, which is 136 trusted by the receiver. Depending on local policy, further 137 verification of the validity of the OCSP servers may be needed 138 139 The client and the KDC SHOULD ignore invalid OCSP responses received 140 via this mechanism, and they MAY implement CRL processing logic as a 141 fall-back position, if the OCSP responses received via this mechanism 142 alone are not sufficient for the verification of certificate 143 validity. The client and/or the KDC MAY ignore a valid OCSP response 144 and perform its own revocation status verification independently. 145 1464. Security Considerations 147 148 The pre-authentication data in this document do not actually 149 authenticate any principals, but are designed to be used in 150 conjunction with PKINIT. 151 152 There is no binding between PA-PK-OCSP-RESPONSE pre-authentication 153 data and PKINIT pre-authentication data other than a given OCSP 154 response corresponding to a certificate used in a PKINIT pre- 155 authentication data element. Attacks involving removal or 156 replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements 157 are, at worst, downgrade attacks, where a PKINIT client or KDC would 158 proceed without use of CRLs or OCSP for certificate validation, or 159 denial-of-service attacks, where a PKINIT client or KDC that cannot 160 validate the other's certificate without an accompanying OCSP 161 response might reject the AS exchange or might have to download very 162 large CRLs in order to continue. Kerberos V does not protect against 163 denial-of-service attacks; therefore, the denial-of-service aspect of 164 these attacks is acceptable. 165 166 167 168 169 170Zhu, et al. Standards Track [Page 3] 171 172RFC 4557 OCSP Support for PKINIT June 2006 173 174 175 If a PKINIT client or KDC cannot validate certificates without the 176 aid of a valid PA-PK-OCSP-RESPONSE, then it SHOULD fail the AS 177 exchange, possibly according to local configuration. 178 1795. Acknowledgements 180 181 This document was based on conversations among the authors, Jeffrey 182 Altman, Sam Hartman, Martin Rex, and other members of the Kerberos 183 working group. 184 1856. References 186 1876.1. Normative References 188 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997. 191 192 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and 193 C. Adams, "X.509 Internet Public Key Infrastructure 194 Online Certificate Status Protocol - OCSP", RFC 2560, 195 June 1999. 196 197 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 198 Kerberos Network Authentication Service (V5)", RFC 199 4120, July 2005. 200 201 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for 202 Initial Authentication in Kerberos (PKINIT)", RFC 203 4556, June 2006. 204 205 [X690] ASN.1 encoding rules: Specification of Basic Encoding 206 Rules (BER), Canonical Encoding Rules (CER) and 207 Distinguished Encoding Rules (DER), ITU-T 208 Recommendation X.690 (1997) | ISO/IEC International 209 Standard 8825-1:1998. 210 2116.2. Informative References 212 213 [OCSP-PROFILE] Deacon, A. and R. Hurst, "Lightweight OCSP Profile for 214 High Volume Environments", Work in Progress, May 2006. 215 216 217 218 219 220 221 222 223 224 225 226Zhu, et al. Standards Track [Page 4] 227 228RFC 4557 OCSP Support for PKINIT June 2006 229 230 231Authors' Addresses 232 233 Larry Zhu 234 Microsoft Corporation 235 One Microsoft Way 236 Redmond, WA 98052 237 US 238 239 EMail: lzhu@microsoft.com 240 241 242 Karthik Jaganathan 243 Microsoft Corporation 244 One Microsoft Way 245 Redmond, WA 98052 246 US 247 248 EMail: karthikj@microsoft.com 249 250 251 Nicolas Williams 252 Sun Microsystems 253 5300 Riata Trace Ct 254 Austin, TX 78727 255 US 256 257 EMail: Nicolas.Williams@sun.com 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282Zhu, et al. Standards Track [Page 5] 283 284RFC 4557 OCSP Support for PKINIT June 2006 285 286 287Full Copyright Statement 288 289 Copyright (C) The Internet Society (2006). 290 291 This document is subject to the rights, licenses and restrictions 292 contained in BCP 78, and except as set forth therein, the authors 293 retain all their rights. 294 295 This document and the information contained herein are provided on an 296 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 297 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 298 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 299 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 300 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 301 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 303Intellectual Property 304 305 The IETF takes no position regarding the validity or scope of any 306 Intellectual Property Rights or other rights that might be claimed to 307 pertain to the implementation or use of the technology described in 308 this document or the extent to which any license under such rights 309 might or might not be available; nor does it represent that it has 310 made any independent effort to identify any such rights. Information 311 on the procedures with respect to rights in RFC documents can be 312 found in BCP 78 and BCP 79. 313 314 Copies of IPR disclosures made to the IETF Secretariat and any 315 assurances of licenses to be made available, or the result of an 316 attempt made to obtain a general license or permission for the use of 317 such proprietary rights by implementers or users of this 318 specification can be obtained from the IETF on-line IPR repository at 319 http://www.ietf.org/ipr. 320 321 The IETF invites any interested party to bring to its attention any 322 copyrights, patents or patent applications, or other proprietary 323 rights that may cover technology that may be required to implement 324 this standard. Please address the information to the IETF at 325 ietf-ipr@ietf.org. 326 327Acknowledgement 328 329 Funding for the RFC Editor function is provided by the IETF 330 Administrative Support Activity (IASA). 331 332 333 334 335 336 337 338Zhu, et al. Standards Track [Page 6] 339 340