idnits 2.17.1 draft-myers-ikev2-ocsp-02.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 420. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 410. ** 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 (June 23, 2006) is 6516 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 4306 (ref. 'IKEv2') (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Myers 3 Internet-Draft TraceRoute Security LLC 4 Expires: December 25, 2006 H. Tschofenig 5 Siemens 6 June 23, 2006 8 OCSP Extensions to IKEv2 9 draft-myers-ikev2-ocsp-02.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 December 25, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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 (IKE) protocol [IKEv2] 83 supports a range of authentication mechanisms, including the use of 84 public key based authentication. Confirmation of certificate 85 reliability is essential to achieve the security assurances public 86 key cryptography provides. One fundamental element of such 87 confirmation is reference to certificate revocation status (see 88 [RFC3280] for additional 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 98 net 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]. If multiple 185 hashes are produced then these hashes are tconcatenated in one 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 [RFC2560] points to this replay vulnerability and indicates: "The use 327 of precomputed responses allows replay attacks in which an old (good) 328 response is replayed prior to its expiration date but after the 329 certificate has been revoked. Deployments of OCSP should carefully 330 evaluate the benefit of precomputed responses against the probability 331 of a replay attack and the costs associated with its successful 332 execution." Nodes SHOULD make the required freshness of an OCSP 333 Response configurable. 335 7. IANA Considerations 337 This document defines two new field types for use in the IKEv2 Cert 338 Encoding field of the Certificate Payload format. Official values 339 for "OCSP Responder Hash" and "OCSP Response" extensions to the Cert 340 Encoding table of Section 3.6 of [IKEv2] need to be acquired from 341 IANA. 343 Certificate Encoding Value 344 -------------------- ----- 345 OCSP Responder Hash 14 346 OCSP Response 15 348 8. Acknowledgements 350 The authors would like to thank Russ Housley for his support. 351 Additionally, we would like to thank Pasi Eronen, Nicolas Williams, 352 Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their 353 review. 355 9. Normative References 357 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 358 RFC 4306, December 2005. 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 364 Adams, "X.509 Internet Public Key Infrastructure Online 365 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 367 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 368 X.509 Public Key Infrastructure Certificate and 369 Certificate Revocation List (CRL) Profile", RFC 3280, 370 April 2002. 372 Authors' Addresses 374 Michael Myers 375 TraceRoute Security LLC 377 Email: mmyers@fastq.com 379 Hannes Tschofenig 380 Siemens 381 Otto-Hahn-Ring 6 382 Munich, Bavaria 81739 383 Germany 385 Email: Hannes.Tschofenig@siemens.com 386 URI: http://www.tschofenig.com 388 Intellectual Property Statement 390 The IETF takes no position regarding the validity or scope of any 391 Intellectual Property Rights or other rights that might be claimed to 392 pertain to the implementation or use of the technology described in 393 this document or the extent to which any license under such rights 394 might or might not be available; nor does it represent that it has 395 made any independent effort to identify any such rights. Information 396 on the procedures with respect to rights in RFC documents can be 397 found in BCP 78 and BCP 79. 399 Copies of IPR disclosures made to the IETF Secretariat and any 400 assurances of licenses to be made available, or the result of an 401 attempt made to obtain a general license or permission for the use of 402 such proprietary rights by implementers or users of this 403 specification can be obtained from the IETF on-line IPR repository at 404 http://www.ietf.org/ipr. 406 The IETF invites any interested party to bring to its attention any 407 copyrights, patents or patent applications, or other proprietary 408 rights that may cover technology that may be required to implement 409 this standard. Please address the information to the IETF at 410 ietf-ipr@ietf.org. 412 Disclaimer of Validity 414 This document and the information contained herein are provided on an 415 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 416 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 417 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 418 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 419 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 420 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Copyright Statement 424 Copyright (C) The Internet Society (2006). This document is subject 425 to the rights, licenses and restrictions contained in BCP 78, and 426 except as set forth therein, the authors retain all their rights. 428 Acknowledgment 430 Funding for the RFC Editor function is currently provided by the 431 Internet Society.