idnits 2.17.1 draft-myers-ikev2-ocsp-03.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 414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 391. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 398. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 404. ** 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 (July 11, 2006) is 6499 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: January 12, 2007 H. Tschofenig 5 Siemens 6 July 11, 2006 8 OCSP Extensions to IKEv2 9 draft-myers-ikev2-ocsp-03.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 January 12, 2007. 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 the "OCSP Content" extension to IKEv2. 46 A CERTREQ payload with "OCSP Content" identifies one or more trusted 47 OCSP responders and is a request for inclusion of an OCSP response in 48 the IKEv2 handshake. A cooperative recipient of such a request 49 responds with a CERT payload containing the appropriate OCSP 50 response. This content is recognizable via the same "OCSP Content" 51 identifier. 53 When certificates are used with IKEv2, the communicating peers need a 54 mechanism to determine the revocation status of the peer's 55 certificate. OCSP is one such mechanism. This document applies when 56 OCSP is desired and security policy prevents one of the IKEv2 peers 57 from accessing the relevant OCSP responder directly. Firewalls are 58 often deployed in a manner that prevents such access by IKEv2 peers 59 outside of an enterprise network. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 6 69 4.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 6 71 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 8 72 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 8 73 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 79 Intellectual Property and Copyright Statements . . . . . . . . . . 14 81 1. Introduction 83 Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] 84 supports a range of authentication mechanisms, including the use of 85 public key based authentication. Confirmation of certificate 86 reliability is essential to achieve the security assurances public 87 key cryptography provides. One fundamental element of such 88 confirmation is reference to certificate revocation status (see 89 [RFC3280] for additional detail). 91 The historic means of determining certificate revocation status is 92 through the use of Certificate Revocation Lists (CRLs). IKEv2 allows 93 CRLs to be exchanged in-band via the CERT payload. 95 CRLs can however grow unbounded in size. Many real-world examples 96 exist to demonstrate the impracticality of including a multi-megabyte 97 file in an IKE exchange. This constraint is particularly acute in 98 bandwidth limited environments (e.g., mobile communications). The 99 net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) 100 acquisition of these data, should they even be used at all. 102 Reliance on OOB methods can be further complicated if access to 103 revocation data requires use of IPsec (and therefore IKE) to 104 establish secure and authorized access to the CRLs of an IKE 105 participant. Such network access deadlock further contributes to a 106 reduced reliance on certificate revocation status in favor of blind 107 trust. 109 OCSP [RFC2560] offers a useful alternative. The size of an OCSP 110 response is bounded and small and therefore suitable for in-band 111 IKEv2 signaling of a certificate's revocation status. 113 This document defines an extension to IKEv2 that enables the use of 114 OCSP for in-band signaling of certificate revocation status. A new 115 content encoding is defined for use in the CERTREQ and CERT payloads. 116 A CERTREQ payload with "OCSP Content" identifies one or more trusted 117 OCSP responders and is a request for inclusion of an OCSP response in 118 the IKEv2 handshake. A cooperative recipient of such a request 119 responds with a CERT payload containing the appropriate OCSP 120 response. This content is recognizable via the same "OCSP Content" 121 identifier. 123 2. Terminology 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 3. Extension Definition 131 With reference to Section 3.6 of [IKEv2], the values for the Cert 132 Encoding field of the CERT payload are extended as follows (see also 133 the IANA Considerations section of this document): 135 Certificate Encoding Value 136 -------------------- ----- 137 OCSP Content 14 139 3.1. OCSP Request 141 A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ 142 Payload indicates the presence of one or more OCSP Responder 143 certificate hashes in the Certificate Authority field of the CERTREQ 144 payload. 146 The presence of OCSP Content (14) in a CERTREQ message: 148 1. identifies one or more OCSP responders trusted by the sender; 150 2. notifies the recipient of sender's support for the OCSP extension 151 to IKEv2; and 153 3. notifies the recipient of sender's desire to receive OCSP 154 confirmation in a subsequent CERT payload. 156 3.2. OCSP Response 158 A value of OCSP Content (14) in the Cert Encoding field of a CERT 159 Payload indicates the presence of an OCSP Response in the Certificate 160 Data field of the CERT payload. 162 Correlation between an OCSP Response CERT payload and a corresponding 163 CERT payload carrying a certificate can be achieved by matching the 164 OCSP response CertID field to the certificate. See [RFC2560] for the 165 definition of OCSP response content. 167 4. Extension Requirements 169 4.1. OCSP Request 171 Section 3.7 of [IKEv2] allows for the concatenation of trust anchor 172 hashes as the Certification Authority value of a single CERTREQ 173 message. There is no means however to indicate which among those 174 hashes relates to the certificate of a trusted OCSP responder. 176 Therefore an OCSP Request as defined in Section 3.1 above SHALL be 177 transmitted separate from any other CERTREQ payloads in an IKEv2 178 exchange. 180 Where it is useful to identify more than one trusted OCSP responder, 181 each such identification SHALL be concatenated in a manner identical 182 to the method documented in Section 3.7 of [IKEv2] regarding the 183 assembly of multiple trust anchor hashes. 185 The Certification Authority value in an OCSP Request CERTREQ SHALL be 186 computed and produced in a manner identical to that of trust anchor 187 hashes as documented in Section 3.7 of [IKEv2]. 189 Upon receipt of an OCSP Response CERT payload corresponding to a 190 prior OCSP Request CERTREQ, the CERTREQ sender SHALL incorporate the 191 OCSP response into path validation logic defined by [RFC3280]. 193 The sender of an OCSP Request CERTREQ MAY abort an IKEv2 exchange if 194 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 Request CERTREQ SHOULD accept an IKEv2 exchange 204 if a corresponding OCSP Response CERT payload is not received. This 205 might be an indication that this OCSP extension is not supported. 207 4.2. OCSP Response 209 Upon receipt of an OCSP Request CERTREQ payload, the recipient SHOULD 210 acquire the related OCSP-based assertion and produce and transmit an 211 OCSP Response CERT payload corresponding to the certificate needed to 212 verify its signature on IKEv2 payloads. 214 An OCSP Response CERT payload SHALL be transmitted separate from any 215 other CERT payload in an IKEv2 exchange. 217 The means by which an OCSP response may be acquired for production of 218 an OCSP Response CERT payload is out of scope of this document. 220 The structure and encoding of the Certificate Data field of an OCSP 221 Response CERT payload SHALL be identical to that defined in 222 [RFC2560]. 224 5. Examples and Discussion 226 This section shows the standard IKEv2 message examples with both 227 peers, the initiator and the responder, using public key based 228 authentication, CERTREQ and CERT payloads. The first instance 229 corresponds to Section 1.2 of [IKEv2], the illustrations of which are 230 reproduced below for reference. 232 5.1. Peer to Peer 234 Application of the IKEv2 extensions defined in this document to the 235 peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as 236 follows. Messages are numbered for ease of reference. 238 Initiator Responder 239 ----------- ----------- 240 (1) HDR, SAi1, KEi, Ni --> 242 (2) <-- HDR, SAr1, KEr, Nr, 243 CERTREQ(OCSP Request) 244 (3) HDR, SK {IDi, CERT(certificate),--> 245 CERT(OCSP Response), 246 CERTREQ(OCSP Request), 247 [IDr,] AUTH, SAi2, TSi, TSr} 249 (4) <-- HDR, SK {IDr, 250 CERT(certificate), 251 CERT(OCSP Response), 252 AUTH, SAr2, TSi, TSr} 254 In (2) Responder sends an OCSP Request CERTREQ payload identifying 255 one or more OCSP responders trusted by Responder. In response, 256 Initiator sends in (3) both a CERT payload carrying its certificate 257 and an OCSP Response CERT payload covering that certificate. In (3) 258 Initiator also requests an OCSP response via the OCSP Request CERTREQ 259 payload. In (4) Responder returns its certificate and a separate 260 OCSP Response CERT payload covering that certificate. 262 It is important to note that in this scenario, the Responder in (2) 263 does not yet possess the Initiator's certificate and therefore cannot 264 form an OCSP request. [RFC2560] allows for pre-produced responses. 265 It is thus easily inferred that OCSP responses can be produced in the 266 absence of a corresponding request (OCSP nonces notwithstanding). In 267 such instances OCSP Requests are simply index values into these data. 269 It is also important in extending IKEv2 towards OCSP in this scenario 270 that the Initiator has certain knowledge that the Responder is 271 capable of and willing to participate in the extension. Yet the 272 Responder will only trust one or more OCSP responder signatures. 273 These factors motivate the definition of OCSP Responder Hash 274 extension. 276 5.2. Extended Authentication Protocol (EAP) 278 Another scenario of pressing interest is the use of EAP to 279 accommodate multiple end users seeking enterprise access to an IPsec 280 gateway. As with the preceding section, the following illustration 281 is extracted from [IKEv2]. In the event of a conflict between this 282 document and[IKEv2] regarding these illustrations, [IKEv2] SHALL 283 dominate. 285 Initiator Responder 286 ----------- ----------- 287 (1) HDR, SAi1, KEi, Ni --> 288 (2) <-- HDR, SAr1, KEr, Nr 289 (3) HDR, SK {IDi, --> 290 CERTREQ(OCSP Request), 291 [IDr,] AUTH, SAi2, TSi, TSr} 292 (4) <-- HDR, SK {IDr, 293 CERT(certificate), 294 CERT(OCSP Response), 295 AUTH, EAP} 296 (5) HDR, SK {EAP} --> 298 (6) <-- HDR, SK {EAP (success)} 300 (7) HDR, SK {AUTH} --> 302 (8) <-- HDR, SK {AUTH, SAr2, TSi, 303 TSr } 305 In the EAP scenario, messages (5) through (8) are not relevant to 306 this document. Note that while [IKEv2] allows for the optional 307 inclusion of a CERTREQ in (2), this document asserts no need of its 308 use. It is assumed that environments including this optional payload 309 and yet wishing to implement the OCSP extension to IKEv2 are 310 sufficiently robust as to accommodate this redundant payload. 312 6. Security Considerations 314 For the reasons noted above, OCSP request as defined in Section 3.1 315 is used in place of OCSP request syntax to trigger production and 316 transmission of an OCSP response. OCSP as defined in [RFC2560] may 317 contain a nonce request extension to improve security against replay 318 attacks (see Section 4.4.1 of [RFC2560] for further details). The 319 OCSP Request defined by this document cannot accommodate nonces. 320 [RFC2560] deals with this aspect by allowing pre-produced responses. 322 [RFC2560] points to this replay vulnerability and indicates: "The use 323 of precomputed responses allows replay attacks in which an old (good) 324 response is replayed prior to its expiration date but after the 325 certificate has been revoked. Deployments of OCSP should carefully 326 evaluate the benefit of precomputed responses against the probability 327 of a replay attack and the costs associated with its successful 328 execution." Nodes SHOULD make the required freshness of an OCSP 329 Response configurable. 331 7. IANA Considerations 333 This document defines one new field type for use in the IKEv2 Cert 334 Encoding field of the Certificate Payload format. Official 335 assignment of the "OCSP Content" extension to the Cert Encoding table 336 of Section 3.6 of [IKEv2] needs to be acquired from IANA. 338 Certificate Encoding Value 339 -------------------- ----- 340 OCSP Content 14 342 8. Acknowledgements 344 The authors would like to thank Russ Housley for his support. 345 Additionally, we would like to thank Pasi Eronen, Nicolas Williams, 346 Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their 347 review. 349 9. Normative References 351 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 352 RFC 4306, December 2005. 354 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 355 Requirement Levels", BCP 14, RFC 2119, March 1997. 357 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 358 Adams, "X.509 Internet Public Key Infrastructure Online 359 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 361 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 362 X.509 Public Key Infrastructure Certificate and 363 Certificate Revocation List (CRL) Profile", RFC 3280, 364 April 2002. 366 Authors' Addresses 368 Michael Myers 369 TraceRoute Security LLC 371 Email: mmyers@fastq.com 373 Hannes Tschofenig 374 Siemens 375 Otto-Hahn-Ring 6 376 Munich, Bavaria 81739 377 Germany 379 Email: Hannes.Tschofenig@siemens.com 380 URI: http://www.tschofenig.com 382 Intellectual Property Statement 384 The IETF takes no position regarding the validity or scope of any 385 Intellectual Property Rights or other rights that might be claimed to 386 pertain to the implementation or use of the technology described in 387 this document or the extent to which any license under such rights 388 might or might not be available; nor does it represent that it has 389 made any independent effort to identify any such rights. Information 390 on the procedures with respect to rights in RFC documents can be 391 found in BCP 78 and BCP 79. 393 Copies of IPR disclosures made to the IETF Secretariat and any 394 assurances of licenses to be made available, or the result of an 395 attempt made to obtain a general license or permission for the use of 396 such proprietary rights by implementers or users of this 397 specification can be obtained from the IETF on-line IPR repository at 398 http://www.ietf.org/ipr. 400 The IETF invites any interested party to bring to its attention any 401 copyrights, patents or patent applications, or other proprietary 402 rights that may cover technology that may be required to implement 403 this standard. Please address the information to the IETF at 404 ietf-ipr@ietf.org. 406 Disclaimer of Validity 408 This document and the information contained herein are provided on an 409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 411 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 412 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 413 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 416 Copyright Statement 418 Copyright (C) The Internet Society (2006). This document is subject 419 to the rights, licenses and restrictions contained in BCP 78, and 420 except as set forth therein, the authors retain all their rights. 422 Acknowledgment 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.