idnits 2.17.1 draft-ietf-krb-wg-ocsp-for-pkinit-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 251. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 5) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 19, 2005) is 6849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'X60' is mentioned on line 94, but not defined == Unused Reference: 'X690' is defined on line 192, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) -- Possible downref: Non-RFC (?) normative reference: ref. 'X690' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft K. Jaganathan 4 Expires: January 20, 2006 Microsoft Corporation 5 N. Williams 6 Sun Microsystems 7 July 19, 2005 9 OCSP Support for PKINIT 10 draft-ietf-krb-wg-ocsp-for-pkinit-06 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 20, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document defines a mechanism to enable in-band transmission of 44 Online Certificate Status Protocol (OCSP) responses in the Kerberos 45 network authentication protocol. These responses are used to verify 46 the validity of the certificates used in PKINIT - the Kerberos 47 Version 5 extension that provides for the use of public key 48 cryptography. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 54 3. Message Definition . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 58 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 7.1 Normative References . . . . . . . . . . . . . . . . . . . 5 60 7.2 Informative References . . . . . . . . . . . . . . . . . . 5 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5 62 Intellectual Property and Copyright Statements . . . . . . . . 7 64 1. Introduction 66 Online Certificate Status Protocol (OCSP) [RFC2560] enables 67 applications to obtain timely information regarding the revocation 68 status of a certificate. Because OCSP responses are well-bounded and 69 small in size, constrained clients may wish to use OCSP to check the 70 validity of the certificates for Kerberos Key Distribution Center 71 (KDC) in order to avoid transmission of large Certificate Revocation 72 Lists (CRLs) and therefore save bandwidth on constrained networks 73 [OCSP-PROFILE]. 75 This document defines a pre-authentication type [RFC4120], where the 76 client and the KDC MAY piggyback OCSP responses for certificates used 77 in authentication exchanges, as defined in [PKINIT]. 79 By using this OPTIONAL extension, PKINIT clients and the KDC can 80 maximize the reuse of cached OCSP responses. 82 2. Conventions Used in This Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 3. Message Definition 90 A pre-authentication type identifier is defined for this mechanism: 92 PA-PK-OCSP-RESPONSE 18 94 The corresponding padata-value field [RFC4120] contains the DER [X60] 95 encoding of the following ASN.1 type: 97 PKOcspData ::= SEQUENCE OF OcspResponse 98 -- If more than one OcspResponse is 99 -- included, the first OcspResponse 100 -- MUST contain the OCSP response 101 -- for the signer's certificate. 102 -- The signer refers to the client for 103 -- AS-REQ, and the KDC for the AS-REP, 104 -- respectively. 106 OcspResponse ::= OCTET STRING 107 -- Contains a complete OCSP response, 108 -- as defined in [RFC2560]. 110 The client MAY send OCSP responses for certificates used in PA-PK-AS- 111 REQ [PKINIT] via a PA-PK-OCSP-RESPONSE. 113 The KDC that receives a PA-PK-OCSP-RESPONSE then SHOULD send a PA-PK- 114 OCSP-RESPONSE containing OCSP responses for certificates used in the 115 KDC's PA-PK-AS-REP. The client can request a PA-PK-OCSP-RESPONSE by 116 using a PKOcspData containing an empty sequence. 118 The KDC MAY send a PA-PK-OCSP-RESPONSE when it does not receive a PA- 119 PK-OCSP-RESPONSE from the client. 121 The PA-PK-OCSP-RESPONSE sent by the KDC contains OCSP responses for 122 certificates used in PA-PK-AS-REP [PKINIT]. 124 Note the lack of integrity protection for the empty or missing OCSP 125 response; lack of an expected OCSP response from the KDC for the 126 KDC's certificates SHOULD be treated as an error by the client, 127 unless it is configured otherwise. 129 When using OCSP, the response is signed by the OCSP server, which is 130 trusted by the receiver. Depending on local policy, further 131 verification of the validity of the OCSP servers may be needed 133 The client and the KDC SHOULD ignore invalid OCSP responses received 134 via this mechanism, and they MAY implement CRL processing logic as a 135 fall-back position, if the OCSP responses received via this mechanism 136 alone are not sufficient for the verification of certificate 137 validity. The client and/or the KDC MAY ignore a valid OCSP response 138 and perform their own revocation status verification independently. 140 4. Security Considerations 142 The pre-authentication data in this document do not actually 143 authenticate any principals, but is designed to be used in 144 conjunction with PKINIT. 146 There is no binding between PA-PK-OCSP-RESPONSE pre-authentication 147 data and PKINIT pre-authentication data other than a given OCSP 148 response corresponding to a certificate used in a PKINIT pre- 149 authentication data element. Attacks involving removal or 150 replacement of PA-PK-OCSP-RESPONSE pre-authentication data elements 151 are, at worst, downgrade attacks, where a PKINIT client or KDC would 152 proceed without use of CRLs or OCSP for certificate validation, or 153 denial of service attacks, where a PKINIT client or KDC that cannot 154 validate the other's certificate without an accompanying OCSP 155 response might reject the AS exchange or where they might have to 156 download very large CRLs in order to continue. Kerberos V does not 157 protect against denial-of-service attacks, therefore the denial-of- 158 service aspect of these attacks are acceptable. 160 If a PKINIT client or KDC cannot validate certificates without the 161 aid of a valid PA-PK-OCSP-RESPONSE then it SHOULD fail the AS 162 exchange, possibly according to local configuration. 164 5. IANA Considerations 166 No IANA actions are required for this document. 168 6. Acknowledgements 170 This document was based on conversations among the authors, Jeffrey 171 Altman, Sam Hartman, Martin Rex and other members of the Kerberos 172 working group. 174 7. References 176 7.1 Normative References 178 [PKINIT] RFC-Editor: To be replaced by RFC number for draft-ietf- 179 cat-kerberos-pk-init. Work in Progress. 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 185 Adams, "X.509 Internet Public Key Infrastructure Online 186 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 188 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 189 Kerberos Network Authentication Service (V5)", RFC 4120, 190 July 2005. 192 [X690] ASN.1 encoding rules: Specification of Basic Encoding 193 Rules (BER), Canonical Encoding Rules (CER) and 194 Distinguished Encoding Rules (DER), ITU-T Recommendation 195 X.690 (1997) | ISO/IEC International Standard 8825-1:1998. 197 7.2 Informative References 199 [OCSP-PROFILE] 200 RFC-Editor: To be replaced by RFC number for draft-deacon- 201 lightweight-ocsp-profile. Work in Progress. 203 Authors' Addresses 205 Larry Zhu 206 Microsoft Corporation 207 One Microsoft Way 208 Redmond, WA 98052 209 US 211 Email: lzhu@microsoft.com 213 Karthik Jaganathan 214 Microsoft Corporation 215 One Microsoft Way 216 Redmond, WA 98052 217 US 219 Email: karthikj@microsoft.com 221 Nicolas Williams 222 Sun Microsystems 223 5300 Riata Trace Ct 224 Austin, TX 78727 225 US 227 Email: Nicolas.Williams@sun.com 229 Intellectual Property Statement 231 The IETF takes no position regarding the validity or scope of any 232 Intellectual Property Rights or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; nor does it represent that it has 236 made any independent effort to identify any such rights. Information 237 on the procedures with respect to rights in RFC documents can be 238 found in BCP 78 and BCP 79. 240 Copies of IPR disclosures made to the IETF Secretariat and any 241 assurances of licenses to be made available, or the result of an 242 attempt made to obtain a general license or permission for the use of 243 such proprietary rights by implementers or users of this 244 specification can be obtained from the IETF on-line IPR repository at 245 http://www.ietf.org/ipr. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights that may cover technology that may be required to implement 250 this standard. Please address the information to the IETF at 251 ietf-ipr@ietf.org. 253 Disclaimer of Validity 255 This document and the information contained herein are provided on an 256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Copyright Statement 265 Copyright (C) The Internet Society (2005). This document is subject 266 to the rights, licenses and restrictions contained in BCP 78, and 267 except as set forth therein, the authors retain all their rights. 269 Acknowledgment 271 Funding for the RFC Editor function is currently provided by the 272 Internet Society.