idnits 2.17.1 draft-myers-ikev2-ocsp-04.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 434. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 445. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 458. ** 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 issues found here. 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 15, 2006) is 6426 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 (~~), 1 warning (==), 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 Intended status: Standards Track H. Tschofenig 5 Expires: March 19, 2007 Siemens 6 September 15, 2006 8 OCSP Extensions to IKEv2 9 draft-myers-ikev2-ocsp-04.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 19, 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 44 Certificate Revocation List (CRL) size. The size of an Online 45 Certificate Status Protocol (OCSP) response is however well-bounded 46 and small. This document defines the "OCSP Content" extension to 47 IKEv2. A CERTREQ payload with "OCSP Content" identifies zero or more 48 trusted OCSP responders and is a request for inclusion of an OCSP 49 response in the IKEv2 handshake. A cooperative recipient of such a 50 request responds with a CERT payload containing the appropriate OCSP 51 response. This content is recognizable via the same "OCSP Content" 52 identifier. 54 When certificates are used with IKEv2, the communicating peers need a 55 mechanism to determine the revocation status of the peer's 56 certificate. OCSP is one such mechanism. This document applies when 57 OCSP is desired and security policy prevents one of the IKEv2 peers 58 from accessing the relevant OCSP responder directly. Firewalls are 59 often deployed in a manner that prevents such access by IKEv2 peers 60 outside of an enterprise network. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Extension Definition . . . . . . . . . . . . . . . . . . . . . 6 67 3.1. OCSP Request . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. OCSP Response . . . . . . . . . . . . . . . . . . . . . . 7 69 4. Extension Requirements . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Request for OCSP Support . . . . . . . . . . . . . . . . . 8 71 4.2. Response to OCSP Support . . . . . . . . . . . . . . . . . 8 72 5. Examples and Discussion . . . . . . . . . . . . . . . . . . . 9 73 5.1. Peer to Peer . . . . . . . . . . . . . . . . . . . . . . . 9 74 5.2. Extended Authentication Protocol (EAP) . . . . . . . . . . 10 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 78 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 80 Intellectual Property and Copyright Statements . . . . . . . . . . 16 82 1. Introduction 84 Version 2 of the Internet Key Exchange (IKE) protocol [IKEv2] 85 supports a range of authentication mechanisms, including the use of 86 public key based authentication. Confirmation of certificate 87 reliability is essential to achieve the security assurances public 88 key cryptography provides. One fundamental element of such 89 confirmation is reference to certificate revocation status (see 90 [RFC3280] for additional detail). 92 The traditional means of determining certificate revocation status is 93 through the use of Certificate Revocation Lists (CRLs). IKEv2 allows 94 CRLs to be exchanged in-band via the CERT payload. 96 CRLs can however grow unbounded in size. Many real-world examples 97 exist to demonstrate the impracticality of including a multi-megabyte 98 file in an IKE exchange. This constraint is particularly acute in 99 bandwidth limited environments (e.g., mobile communications). The 100 net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) 101 acquisition of these data, should they even be used at all. 103 Reliance on OOB methods can be further complicated if access to 104 revocation data requires use of IPsec (and therefore IKE) to 105 establish secure and authorized access to the CRLs of an IKE 106 participant. Such network access deadlock further contributes to a 107 reduced reliance on certificate revocation status in favor of blind 108 trust. 110 OCSP [RFC2560] offers a useful alternative. The size of an OCSP 111 response is bounded and small and therefore suitable for in-band 112 IKEv2 signaling of a certificate's revocation status. 114 This document defines an extension to IKEv2 that enables the use of 115 OCSP for in-band signaling of certificate revocation status. A new 116 content encoding is defined for use in the CERTREQ and CERT payloads. 117 A CERTREQ payload with "OCSP Content" identifies zero or more trusted 118 OCSP responders and is a request for inclusion of an OCSP response in 119 the IKEv2 handshake. A cooperative recipient of such a request 120 responds with a CERT payload containing the appropriate OCSP 121 response. This content is recognizable via the same "OCSP Content" 122 identifier. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 This document defines the following terms: 132 OCSP request: 134 An OCSP request refers the CERTREQ payload that contains a new 135 content encoding, referred as OCSP Content, that conforms to the 136 definition and behavior specified in Section 3.1. 138 OCSP response: 140 An OCSP response refers the CERT payload that contains a new 141 content encoding, referred as OCSP Content, that conforms to the 142 definition and behavior specified in Section 3.2. 144 OCSP responder: 146 The term OCSP responder refers to the entity that accepts requests 147 from an OCSP client and returns responses as defined in [RFC2560]. 148 Note that the OCSP responder does not refer to the party that 149 sends the CERT message. 151 3. Extension Definition 153 With reference to Section 3.6 of [IKEv2], the values for the Cert 154 Encoding field of the CERT payload are extended as follows (see also 155 the IANA Considerations section of this document): 157 Certificate Encoding Value 158 -------------------- ----- 159 OCSP Content 14 161 3.1. OCSP Request 163 A value of OCSP Content (14) in the Cert Encoding field of a CERTREQ 164 Payload indicates the presence of zero or more OCSP responder 165 certificate hashes in the Certificate Authority field of the CERTREQ 166 payload. Section 2.2 of [RFC2560] defines responses and they belong 167 to one of the following three groups: 169 (a) the CA who issued the certificate 171 (b) a Trusted Responder whose public key is trusted by the requester 173 (c) a CA Designated Responder (Authorized Responder) who holds a 174 specially marked certificate issued directly by the CA, indicating 175 that the responder may issue OCSP responses for that CA 177 In case of (a) the use of hashes in the CERTREQ message is not needed 178 since the OCSP response is signed by the CA who issued the 179 certificate. In case of (c) the OCSP response is signed by the CA 180 Designated Responder whereby the sender of the CERTREQ message does 181 not know the public key in advance. The presence of OCSP Content in 182 a CERTREQ message will identify one or more OCSP responders trusted 183 by the sender in case of (b). 185 The presence of OCSP Content (14) in a CERTREQ message: 187 1. identifies zero or more OCSP responders trusted by the sender; 189 2. notifies the recipient of sender's support for the OCSP extension 190 to IKEv2; and 192 3. notifies the recipient of sender's desire to receive OCSP 193 confirmation in a subsequent CERT payload. 195 3.2. OCSP Response 197 A value of OCSP Content (14) in the Cert Encoding field of a CERT 198 Payload indicates the presence of an OCSP response in the Certificate 199 Data field of the CERT payload. 201 Correlation between an OCSP response CERT payload and a corresponding 202 CERT payload carrying a certificate can be achieved by matching the 203 OCSP response CertID field to the certificate. See [RFC2560] for the 204 definition of OCSP response content. 206 4. Extension Requirements 208 4.1. Request for OCSP Support 210 Section 3.7 of [IKEv2] allows for the concatenation of trust anchor 211 hashes as the Certification Authority value of a single CERTREQ 212 message. There is no means however to indicate which among those 213 hashes, if present, relates to the certificate of a trusted OCSP 214 responder. 216 Therefore an OCSP request as defined in Section 3.1 above is 217 transmitted separate from any other CERTREQ payloads in an IKEv2 218 exchange. 220 Where it is useful to identify more than one trusted OCSP responder, 221 each such identification SHALL be concatenated in a manner identical 222 to the method documented in Section 3.7 of [IKEv2] regarding the 223 assembly of multiple trust anchor hashes. 225 The Certification Authority value in an OCSP request CERTREQ SHALL be 226 computed and produced in a manner identical to that of trust anchor 227 hashes as documented in Section 3.7 of [IKEv2]. 229 Upon receipt of an OCSP response CERT payload corresponding to a 230 prior OCSP request CERTREQ, the CERTREQ sender SHALL incorporate the 231 OCSP response into path validation logic defined by [RFC3280]. 233 The sender of an OCSP request CERTREQ SHOULD accept an IKEv2 exchange 234 if a corresponding OCSP response CERT payload is not received. This 235 might be an indication that this OCSP extension is not supported. In 236 this case, the peer SHOULD attempt to determine certificate 237 revocation status by some other means. 239 4.2. Response to OCSP Support 241 Upon receipt of an OCSP request CERTREQ payload, the recipient SHOULD 242 acquire the related OCSP-based assertion and produce and transmit an 243 OCSP response CERT payload corresponding to the certificate needed to 244 verify its signature on IKEv2 payloads. 246 An OCSP response CERT payload is transmitted separate from any other 247 CERT payload in an IKEv2 exchange. 249 The means by which an OCSP response may be acquired for production of 250 an OCSP response CERT payload is out of scope of this document. 252 The Certificate Data field of an OCSP response CERT payload SHALL 253 contain a DER-encoded OCSPResponse structure as defined in [RFC2560]. 255 5. Examples and Discussion 257 This section shows the standard IKEv2 message examples with both 258 peers, the initiator and the responder, using public key based 259 authentication, CERTREQ and CERT payloads. The first instance 260 corresponds to Section 1.2 of [IKEv2], the illustrations of which are 261 reproduced below for reference. 263 5.1. Peer to Peer 265 Application of the IKEv2 extensions defined in this document to the 266 peer-to-peer exchange defined in Section 1.2 of [IKEv2] is as 267 follows. Messages are numbered for ease of reference. 269 Initiator Responder 270 ----------- ----------- 271 (1) HDR, SAi1, KEi, Ni --> 273 (2) <-- HDR, SAr1, KEr, Nr, 274 CERTREQ(OCSP Request) 275 (3) HDR, SK {IDi, CERT(certificate),--> 276 CERT(OCSP Response), 277 CERTREQ(OCSP Request), 278 [IDr,] AUTH, SAi2, TSi, TSr} 280 (4) <-- HDR, SK {IDr, 281 CERT(certificate), 282 CERT(OCSP Response), 283 AUTH, SAr2, TSi, TSr} 285 OCSP Extensions to Baseline IKEv2 287 In (2) Responder sends an OCSP request CERTREQ payload identifying 288 zero or more OCSP responders trusted by the Responder. In response, 289 Initiator sends in (3) both a CERT payload carrying its certificate 290 and an OCSP response CERT payload covering that certificate. In (3) 291 Initiator also requests an OCSP response via the OCSP request CERTREQ 292 payload. In (4) the Responder returns its certificate and a separate 293 OCSP response CERT payload covering that certificate. 295 It is important to note that in this scenario, the Responder in (2) 296 does not yet possess the Initiator's certificate and therefore cannot 297 form an OCSP request as defined in [RFC2560]. To bypass this problem 298 hashes are used as defined in Section 4.1. In such instances OCSP 299 Requests are simply index values into these data. It is thus easily 300 inferred that OCSP responses can be produced in the absence of a 301 corresponding request (provided that OCSP nonces are not used, see 302 Section 6). 304 It is also important in extending IKEv2 towards OCSP in this scenario 305 that the Initiator has certain knowledge that the Responder is 306 capable of and willing to participate in the extension. Yet the 307 Responder will only trust one or more OCSP responder signatures. 308 These factors motivate the definition of OCSP responder hash 309 extension. 311 5.2. Extended Authentication Protocol (EAP) 313 Another scenario of pressing interest is the use of EAP to 314 accommodate multiple end users seeking enterprise access to an IPsec 315 gateway. As with the preceding section, the following illustration 316 is extracted from [IKEv2]. In the event of a conflict between this 317 document and[IKEv2] regarding these illustrations, [IKEv2] SHALL 318 dominate. 320 Initiator Responder 321 ----------- ----------- 322 (1) HDR, SAi1, KEi, Ni --> 323 (2) <-- HDR, SAr1, KEr, Nr 324 (3) HDR, SK {IDi, --> 325 CERTREQ(OCSP Request), 326 [IDr,] AUTH, SAi2, TSi, TSr} 327 (4) <-- HDR, SK {IDr, 328 CERT(certificate), 329 CERT(OCSP Response), 330 AUTH, EAP} 331 (5) HDR, SK {EAP} --> 333 (6) <-- HDR, SK {EAP (success)} 335 (7) HDR, SK {AUTH} --> 337 (8) <-- HDR, SK {AUTH, SAr2, TSi, 338 TSr } 340 OCSP Extensions to EAP in IKEv2 342 In the EAP scenario, messages (5) through (8) are not relevant to 343 this document. Note that while [IKEv2] allows for the optional 344 inclusion of a CERTREQ in (2), this document asserts no need of its 345 use. It is assumed that environments including this optional payload 346 and yet wishing to implement the OCSP extension to IKEv2 are 347 sufficiently robust as to accommodate this redundant payload. 349 6. Security Considerations 351 For the reasons noted above, OCSP request as defined in Section 3.1 352 is used in place of OCSP request syntax to trigger production and 353 transmission of an OCSP response. OCSP as defined in [RFC2560] may 354 contain a nonce request extension to improve security against replay 355 attacks (see Section 4.4.1 of [RFC2560] for further details). The 356 OCSP request defined by this document cannot accommodate nonces. 357 [RFC2560] deals with this aspect by allowing pre-produced responses. 359 [RFC2560] points to this replay vulnerability and indicates: "The use 360 of precomputed responses allows replay attacks in which an old (good) 361 response is replayed prior to its expiration date but after the 362 certificate has been revoked. Deployments of OCSP should carefully 363 evaluate the benefit of precomputed responses against the probability 364 of a replay attack and the costs associated with its successful 365 execution." Nodes SHOULD make the required freshness of an OCSP 366 response configurable. 368 7. IANA Considerations 370 This document defines one new field type for use in the IKEv2 Cert 371 Encoding field of the Certificate Payload format. Official 372 assignment of the "OCSP Content" extension to the Cert Encoding table 373 of Section 3.6 of [IKEv2] needs to be acquired from IANA. 375 Certificate Encoding Value 376 -------------------- ----- 377 OCSP Content 14 379 8. Acknowledgements 381 The authors would like to thank Russ Housley for his support. 382 Additionally, we would like to thank Pasi Eronen, Nicolas Williams, 383 Liqiang (Larry) Zhu, Lakshminath Dondeti and Paul Hoffman for their 384 review. Pasi gave us invaluable last call comments. We would also 385 like to thank Tom Taylor for his Gen-ART review. 387 9. Normative References 389 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 390 RFC 4306, December 2005. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 396 Adams, "X.509 Internet Public Key Infrastructure Online 397 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 399 [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet 400 X.509 Public Key Infrastructure Certificate and 401 Certificate Revocation List (CRL) Profile", RFC 3280, 402 April 2002. 404 Authors' Addresses 406 Michael Myers 407 TraceRoute Security LLC 409 Email: mmyers@fastq.com 411 Hannes Tschofenig 412 Siemens 413 Otto-Hahn-Ring 6 414 Munich, Bavaria 81739 415 Germany 417 Email: Hannes.Tschofenig@siemens.com 418 URI: http://www.tschofenig.com 420 Full Copyright Statement 422 Copyright (C) The Internet Society (2006). 424 This document is subject to the rights, licenses and restrictions 425 contained in BCP 78, and except as set forth therein, the authors 426 retain all their rights. 428 This document and the information contained herein are provided on an 429 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 430 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 431 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 432 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 433 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 434 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 436 Intellectual Property 438 The IETF takes no position regarding the validity or scope of any 439 Intellectual Property Rights or other rights that might be claimed to 440 pertain to the implementation or use of the technology described in 441 this document or the extent to which any license under such rights 442 might or might not be available; nor does it represent that it has 443 made any independent effort to identify any such rights. Information 444 on the procedures with respect to rights in RFC documents can be 445 found in BCP 78 and BCP 79. 447 Copies of IPR disclosures made to the IETF Secretariat and any 448 assurances of licenses to be made available, or the result of an 449 attempt made to obtain a general license or permission for the use of 450 such proprietary rights by implementers or users of this 451 specification can be obtained from the IETF on-line IPR repository at 452 http://www.ietf.org/ipr. 454 The IETF invites any interested party to bring to its attention any 455 copyrights, patents or patent applications, or other proprietary 456 rights that may cover technology that may be required to implement 457 this standard. Please address the information to the IETF at 458 ietf-ipr@ietf.org. 460 Acknowledgment 462 Funding for the RFC Editor function is provided by the IETF 463 Administrative Support Activity (IASA).