idnits 2.17.1 draft-myers-ikev2-ocsp-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 410. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 400. ** 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 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 (September 25, 2005) is 6787 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) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsec M. Myers 3 Internet-Draft TraceRoute Security LLC 4 Expires: March 29, 2006 H. Tschofenig 5 Siemens 6 September 25, 2005 8 OCSP Extensions to IKEv2 9 draft-myers-ikev2-ocsp-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 29, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 While IKEv2 supports public key based authentication (PKI), the 43 corresponding use of in-band CRLs is problematic due to unbounded CRL 44 size. The size of an OCSP response is however well-bounded and 45 small. This document defines two extensions to IKEv2 which enable 46 the use of OCSP for in-band signaling of certificate revocation 47 status. Two new content encodings are defined for use in the CERTREQ 48 and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP 49 Responder Hash CERTREQ payload triggers transmission of an OCSP 50 Response CERT payload. 52 When certificates are used with IKEv2, the communicating peers need a 53 mechanism to determine the revocation status of the peer's 54 certificate. OCSP is one such mechanism. This document applies when 55 OCSP is desired and security policy prevents one of the IKEv2 peers 56 from accessing the relevant OCSP responder directly. Firewalls are 57 often deployed in a manner that prevents such access by IKEv2 peers 58 outside of an enterprise network. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. OCSP Responder Hash . . . . . . . . . . . . . . . . . . . 5 66 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6 68 4.1. OCSP Responder Hash . . . . . . . . . . . . . . . . . . . 6 69 4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6 70 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 71 5.1. Baseline . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 76 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 Intellectual Property and Copyright Statements . . . . . . . . . . 14 80 1. Introduction 82 Version 2 of the Internet Key Exchange protocol [IKEv2] supports a 83 range of authentication mechanisms, including the use of public key 84 based authentication. Confirmation of certificate reliability is 85 essential to achieve the security assurances public key cryptography 86 provides. One fundamental element of such confirmation is reference 87 to certificate revocation status (see [RFC3280] for additional 88 detail). 90 The historic means of determining certificate revocation status is 91 through the use of Certificate Revocation Lists (CRLs). IKEv2 allows 92 CRLs to be exchanged in-band via the CERT payload. 94 CRLs can however grow unbounded in size. Many real-world examples 95 exist to demonstrate the impracticality of including a multi-megabyte 96 file in an IKE exchange. This constraint is particularly acute in 97 bandwidth limited environments (e.g. mobile communications). The net 98 effect is exclusion of in-band CRLs in favor of out-of-band (OOB) 99 acquisition of these data, should they even be used at all. 101 Reliance on OOB methods can be further complicated if access to 102 revocation data requires use of IPsec (and therefore IKE) to 103 establish secure and authorized access to the CRLs of an IKE 104 participant. Such network access deadlock further contributes to a 105 reduced reliance on certificate revocation status in favor of blind 106 trust. 108 OCSP [RFC2560] offers a useful alternative. The size of an OCSP 109 response is bounded and small and therefore suitable for in-band 110 IKEv2 signaling of a certificate's revocation status. 112 This document defines two extensions to IKEv2 that enable the use of 113 OCSP for in-band signaling of certificate revocation status. Two new 114 content encodings are defined for use in the CERTREQ and CERT 115 payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder 116 Hash CERTREQ payload triggers transmission of an OCSP Response CERT 117 payload. 119 2. Terminology 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119 [RFC2119]. 125 3. Extension Definition 127 With reference to Section 3.6 of [IKEv2], the values for the Cert 128 Encoding field of the CERT payload are extended as follows (see also 129 the IANA Considerations section of this document): 131 Certificate Encoding Value 132 -------------------- ----- 133 OCSP Responder Hash 14 134 OCSP Response 15 136 3.1. OCSP Responder Hash 138 A value of OCSP Responder Hash (14) in the Cert Encoding field of a 139 CERTREQ Payload indicates the presence of an OCSP Responder 140 certificate hash in the Certificate Authority field of the CERTREQ 141 payload. 143 The presence of the OCSP Responder Hash in a CERTREQ message: 145 1. identifies an OCSP responder trusted by the sender; 147 2. notifies the recipient of sender's support for the OCSP extension 148 to IKEv2; and 150 3. notifies the recipient of sender's desire to receive OCSP 151 confirmation in a subsequent CERT payload. 153 3.2. OCSP Response 155 A value of OCSP Response (15) in the Cert Encoding field of a CERT 156 Payload indicates the presence of an OCSP Response in the Certificate 157 Data field of the CERT payload. 159 Correlation between an OCSP Response CERT payload and a corresponding 160 CERT payload carrying a certificate can be achieved by matching the 161 OCSP response CertID field to the certificate. See [RFC2560] for the 162 definition of OCSP response content. 164 4. Extension Requirements 166 [IKEv2] allows for multiple CERT and CERTREQ payloads in an exchange. 168 4.1. OCSP Responder Hash 170 Section 3.7 of [IKEv2] allows for the concatenation of trust anchor 171 hashes as the Certification Authority value of a single CERTREQ 172 message. There is no means however to indicate which among those 173 hashes relates to the certificate of a trusted OCSP responder. 175 Therefore an OCSP Responder Hash CERTREQ SHALL be transmitted 176 separate from any other CERTREQ payloads in an IKEv2 exchange. 178 Where it is useful to identify more than one trusted OCSP responder, 179 each such identification SHALL be transmitted via separate OCSP 180 Responder Hash CERTREQ payloads. 182 The Certification Authority value in an OCSP Responder CERTREQ SHALL 183 be computed and produced in a manner identical to that of trust 184 anchor hashes as documented in Section 3.7 of [IKEv2] with the 185 exception that each such hash SHALL be expressed in a separate 186 CERTREQ payload. 188 Upon receipt of an OCSP Response CERT payload corresponding to a 189 prior OCSP Responder Hash CERTREQ, the CERTREQ sender SHALL 190 incorporate the OCSP response into path validation logic defined by 191 [RFC3280]. 193 The sender of an OCSP Responder Hash CERTREQ MAY abort an IKEv2 194 exchange if either: 196 1. the corresponding OCSP Response CERT payload indicates that the 197 subject certificate is revoked; OR 199 2. the corresponding OCSP Response CERT payload indicates an OCSP 200 error (e.g. malformedRequest, internalError, tryLater, 201 sigRequired, unauthorized, etc.). 203 The sender of an OCSP Responder Hash CERTREQ SHOULD accept an IKEv2 204 exchange if a corresponding OCSP Response CERT payload is not 205 received. This might be an indication that this OCSP extension is 206 not supported. 208 4.2. OCSP Response 210 Upon receipt of an OCSP Responder Hash CERTREQ payload, the recipient 211 SHOULD acquire the related OCSP-based assertion and produce and 212 transmit an OCSP Response CERT payload corresponding to the 213 certificate needed to verify its signature on IKEv2 payloads. 215 An OCSP Response CERT payload SHALL be transmitted separate from any 216 other CERT payload in an IKEv2 exchange. 218 Where multiple OCSP responses are useful to an environment, each such 219 SHALL be transmitted via separate OCSP Response CERT payloads. 221 The means by which an OCSP response may be acquired for production of 222 an OCSP Response CERT payload is out of scope of this document. 224 The structure and encoding of the Certificate Data field of an OCSP 225 Response CERT payload SHALL be identical to that defined in 226 [RFC2560]. 228 5. Examples and Discussion 230 This section shows the standard IKEv2 message examples with both 231 peers, the initiator and the responder, using public key based 232 authentication, CERTREQ and CERT payloads. The first instance 233 corresponds to Section 1.2 of [IKEv2], the illustrations of which are 234 reproduced below for reference. 236 5.1. Baseline 238 Application of the IKEv2 extensions defined in this document to the 239 baseline exchange defined in Section 1.2 of [IKEv2] is as follows. 240 Messages are numbered for ease of reference. 242 Initiator Responder 243 ----------- ----------- 244 (1) HDR, SAi1, KEi, Ni --> 246 (2) <-- HDR, SAr1, KEr, Nr, 247 CERTREQ(OCSP Responder Hash) 248 (3) HDR, SK {IDi, CERT(certificate),--> 249 CERT(OCSP Response), 250 CERTREQ(OCSP Responder Hash), 251 [IDr,] AUTH, SAi2, TSi, TSr} 253 (4) <-- HDR, SK {IDr, 254 CERT(certificate), 255 CERT(OCSP Response), 256 AUTH, SAr2, TSi, TSr} 258 In (2) Responder sends an OCSP Responder Hash CERTREQ payload 259 identifying an OCSP responder trusted by Responder. In response, 260 Initiator sends in (3) both a CERT payload carrying its certificate 261 and an OCSP Response CERT payload covering that certificate. In (3) 262 Initiator also requests an OCSP response via the OCSP Responder Hash 263 CERTREQ payload. In (4) Responder returns its certificate and a 264 separate OCSP Response CERT payload covering that certificate. 266 It is important to note that in this scenario, the Responder in (2) 267 does not yet possess the Initiator's certificate and therefore cannot 268 form an OCSP request. [RFC2560] allows for pre-produced responses. 269 It is thus easily inferred that OCSP responses can be produced in the 270 absence of a corresponding request (OCSP nonces notwithstanding). In 271 such instances OCSP Requests are simply index values into these data. 273 It is also important in extending IKEv2 towards OCSP in this scenario 274 that the Initiator has certain knowledge that the Responder is 275 capable of and willing to participate in the extension. Yet the 276 Responder will only trust one or more OCSP responder signatures. 277 These factors motivate the definition of OCSP Responder Hash 278 extension. 280 5.2. Extended Authentication Protocol (EAP) 282 Another scenario of pressing interest is the use of EAP to 283 accommodate multiple end users seeking enterprise access to an IPsec 284 gateway. As with the preceding section, the following illustration 285 is extracted from [IKEv2]. In the event of a conflict between this 286 document and[IKEv2] regarding these illustrations, [IKEv2] SHALL 287 dominate. 289 Initiator Responder 290 ----------- ----------- 291 (1) HDR, SAi1, KEi, Ni --> 292 (2) <-- HDR, SAr1, KEr, Nr 293 (3) HDR, SK {IDi, --> 294 CERTREQ(OCSP Responder Hash), 295 [IDr,] AUTH, SAi2, TSi, TSr} 296 (4) <-- HDR, SK {IDr, 297 CERT(certificate), 298 CERT(OCSP Response), 299 AUTH, EAP} 300 (5) HDR, SK {EAP} --> 302 (6) <-- HDR, SK {EAP (success)} 304 (7) HDR, SK {AUTH} --> 306 (8) <-- HDR, SK {AUTH, SAr2, TSi, 307 TSr } 309 In the EAP scenario, messages (5) through (8) are not relevant to 310 this document. Note that while [IKEv2] allows for the optional 311 inclusion of a CERTREQ in (2), this document asserts no need of its 312 use. It is assumed that environments including this optional payload 313 and yet wishing to implement the OCSP extension to IKEv2 are 314 sufficiently robust as to accommodate this redundant payload. 316 6. Security Considerations 318 For the reasons noted above, OCSP Responder Hash is used in place of 319 OCSP request syntax to trigger production and transmission of an OCSP 320 response. OCSP as defined in [RFC2560] may contain a nonce request 321 extension to improve security against replay attacks (see Section 322 4.4.1 of [RFC2560] for further details). The OCSP Responder Hash 323 does not contain such a nonce. [RFC2560] deals with this aspect by 324 allowing pre-produced responses. 326 7. IANA Considerations 328 This document defines two new field types for use in the IKEv2 Cert 329 Encoding field of the Certificate Payload format. Official values 330 for "OCSP Responder Hash" and "OCSP Response" extensions to the Cert 331 Encoding table of Section 3.6 of [IKEv2] need to be acquired from 332 IANA. 334 Certificate Encoding Value 335 -------------------- ----- 336 OCSP Responder Hash 14 337 OCSP Response 15 339 8. Acknowledgements 341 The authors would like to thank Russ Housley for this support and 342 Pasi Eronen for his review. 344 9. Normative References 346 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 347 draft-ietf-ipsec-ikev2-17 (work in progress), 348 October 2004. 350 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 351 Requirement Levels", BCP 14, RFC 2119, March 1997. 353 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 354 Adams, "X.509 Internet Public Key Infrastructure Online 355 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 357 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 358 X.509 Public Key Infrastructure Certificate and 359 Certificate Revocation List (CRL) Profile", RFC 3280, 360 April 2002. 362 Authors' Addresses 364 Michael Myers 365 TraceRoute Security LLC 367 Email: mmyers@fastq.com 369 Hannes Tschofenig 370 Siemens 371 Otto-Hahn-Ring 6 372 Munich, Bavaria 81739 373 Germany 375 Email: Hannes.Tschofenig@siemens.com 376 URI: http://www.tschofenig.com 378 Intellectual Property Statement 380 The IETF takes no position regarding the validity or scope of any 381 Intellectual Property Rights or other rights that might be claimed to 382 pertain to the implementation or use of the technology described in 383 this document or the extent to which any license under such rights 384 might or might not be available; nor does it represent that it has 385 made any independent effort to identify any such rights. Information 386 on the procedures with respect to rights in RFC documents can be 387 found in BCP 78 and BCP 79. 389 Copies of IPR disclosures made to the IETF Secretariat and any 390 assurances of licenses to be made available, or the result of an 391 attempt made to obtain a general license or permission for the use of 392 such proprietary rights by implementers or users of this 393 specification can be obtained from the IETF on-line IPR repository at 394 http://www.ietf.org/ipr. 396 The IETF invites any interested party to bring to its attention any 397 copyrights, patents or patent applications, or other proprietary 398 rights that may cover technology that may be required to implement 399 this standard. Please address the information to the IETF at 400 ietf-ipr@ietf.org. 402 Disclaimer of Validity 404 This document and the information contained herein are provided on an 405 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 406 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 407 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 408 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 409 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 410 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 412 Copyright Statement 414 Copyright (C) The Internet Society (2005). This document is subject 415 to the rights, licenses and restrictions contained in BCP 78, and 416 except as set forth therein, the authors retain all their rights. 418 Acknowledgment 420 Funding for the RFC Editor function is currently provided by the 421 Internet Society.