IPSEC Working Group M. Myers Internet-Draft TraceRoute Security LLC Expires: December 31, 2004 H. Tschofenig Siemens July 2004 OCSP Extensions to IKEv2 draft-myers-ipsec-ikev2-oscp-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 31, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract While IKEv2 supports public key based authentication (PKI), the corresponding use of in-band CRLs is problematic due to unbounded CRL size. The size of an OCSP response is however well-bounded and small. This document defines two extensions to IKEv2 which enable the use of OCSP for in-band signaling of certificate revocation status. Two new content encodings are defined for use in the CERTREQ and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash CERTREQ payload triggers transmission of an OCSP Response CERT payload. Myers & Tschofenig Expires November 30, 2004 [Page 1] Internet-Draft OCSP Extensions to IKEv2 June 2004 1. Introduction Version 2 of the Internet Key Exchange protocol [IKEv2] supports a range of authentication mechanisms, including the use of public key based authentication (PKI). Confirmation of certificate reliability is essential to achieve the security assurances PKI provides. One fundamental element of such confirmation is reference to certificate revocation status (see [RFC3280] for additional detail). The historic means of determining certificate revocation status is through the use of Certificate Revocation Lists (CRLs). IKEv2 allows CRLs to be exchanged in-band via the CERT payload. CRLs can however grow unbounded in size. Many real-world examples exist to demonstrate the impracticality of including a multi-megabyte file in an IKE exchange. This constraint is particularly acute in bandwidth limited environments (e.g. mobile communications). The net effect is exclusion of in-band CRLs in favor of out-of-band (OOB) acquisition of these data, should they even be used at all. Reliance on OOB methods can be further complicated if access to revocation data requires use of IPSEC (and therefore IKE) to establish secure and authorized access to the CRLs of an IKE participant. Such network access deadlock further contributes to a reduced reliance on certificate revocation status in favor of blind trust. OCSP [RFC2560] offers a useful alternative. The size of an OCSP response is bounded and small and therefore suitable for in-band IKEv2 signaling of a certificate's revocation status. This document defines two extensions to IKEv2 that enable the use of OCSP for in-band signaling of certificate revocation status. Two new content encodings are defined for use in the CERTREQ and CERT payloads: OCSP Responder Hash and OCSP Response. An OCSP Responder Hash CERTREQ payload triggers transmission of an OCSP Response CERT payload. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Extension Definition With reference to Section 3.6 of [IKEv2], the values for the Cert Encoding field of the CERT payload are extended as follows (see also the IANA Considerations section of this document): Certificate Encoding Value -------------------- ----- OCSP Responder Hash 14 OCSP Response 15 Myers & Tschofenig Expires November 30, 2004 [Page 2] Internet-Draft OCSP Extensions to IKEv2 June 2004 3.1 OCSP Responder Hash A value of OCSP Responder Hash (14) in the Cert Encoding field of a CERTREQ Payload indicates the presence of an OCSP Responder certificate hash in the Certificate Authority field of the CERTREQ payload. The presence of the OCSP Responder Hash in a CERTREQ message: 1. identifies an OCSP responder trusted by the sender; 2. notifies the recipient of sender's support for the OCSP extension to IKEv2; and 3 notifies the recipient of sender's desire to receive OCSP confirmation in a subsequent CERT payload. 3.2 OCSP Response A value of OCSP Response (15) in the Cert Encoding field of a CERT Payload indicates the presence of an OCSP Response in the Certificate Data field of the CERT payload. Correlation between an OCSP Response CERT payload and a corresponding CERT payload carrying a certificate can be achieved by matching the OCSP response CertID field to the certificate. See [RFC2560] for the definition of OCSP response content. 4. Extension Requirements [IKEv2] allows for multiple CERT and CERTREQ payloads in an exchange. 4.1 OCSP Responder Hash Section 3.7 of [IKEv2] allows for the concatenation of trust anchor hashes as the Certification Authority value of a single CERTREQ message. There is no means however to indicate which among those hashes relates to the certificate of a trusted OCSP responder. Therefore an OCSP Responder Hash CERTREQ SHALL be transmitted separate from any other CERTREQ payloads in an IKEv2 exchange. Where it is useful to identify more than one trusted OCSP responder, each such identification SHALL be transmitted via separate OCSP Responder Hash CERTREQ payloads. The Certification Authority value in an OCSP Responder CERTREQ SHALL be computed and produced in a manner identical to that of trust anchor hashes as documented in Section 3.7 of [IKEv2] with the exception that each such hash SHALL be expressed in a separate CERTREQ payload. Myers & Tschofenig Expires November 30, 2004 [Page 3] Internet-Draft OCSP Extensions to IKEv2 June 2004 Upon receipt of an OCSP Response CERT payload corresponding to a prior OCSP Responder Hash CERTREQ, the CERTREQ sender SHALL incorporate the OCSP response into path validation logic defined by [RFC3280]. The sender of an OCSP Responder Hash CERTREQ SHALL abort an IKEv2 exchange if either: 1. the corresponding OCSP Response CERT payload indicates that the subject certificate is revoked; 2. the corresponding OCSP Response CERT payload indicates an OCSP error (e.g. malformedRequest, internalError, tryLater, sigRequired, unauthorized, etc.); 3. a corresponding OCSP Response CERT payload is not received; OR 4. a [TBD] IKEv2 error is received indicating inability to respond. 4.2 OCSP Response Upon receipt of an OCSP Responder Hash CERTREQ payload, the recipient SHALL either: 1. acquire the related OCSP-based assertion and produce and transmit an OCSP Response CERT payload corresponding to the certificate needed to verify its signature on IKEv2 payloads; OR 2. transmit a [TBD] IKEv2 error. The recipient of an OCSP Responder Hash CERTREQ payload SHALL NOT ignore the request. At a minimum, a [TBD] IKEv2 error SHALL be sent. An OCSP Response CERT payload SHALL be transmitted separate from any other CERT payload in an IKEv2 exchange. Where multiple OCSP responses are useful to an environment, each such SHALL be transmitted via separate OCSP Response CERT payloads. The means by which an OCSP response may be acquired for production of an OCSP Response CERT payload is out of scope of this document. The structure and encoding of the Certificate Data field of an OCSP Response CERT payload SHALL be identical to that defined in [RFC2560]. 5. Examples and Discussion This section shows the standard IKEv2 message examples with both peers, the initiator and the responder, using public key based authentication, CERTREQ and CERT payloads. The first instance corresponds to Section 1.2 of [IKEv2], the illustrations of which are reproduced below for reference. Myers & Tschofenig Expires November 30, 2004 [Page 4] Internet-Draft OCSP Extensions to IKEv2 June 2004 5.1 Baseline Application of the IKEv2 extensions defined in this document to the baseline exchange defined in Section 1.2 of [IKEv2] is as follows. Messages are numbered for ease of reference. Initiator Responder ----------- ----------- (1) HDR, SAi1, KEi, Ni --> (2) <-- HDR, SAr1, KEr, Nr, CERTREQ(OCSP Responder Hash) (3) HDR, SK {IDi, CERT(certificate), --> CERT(OCSP Response), CERTREQ(OCSP Responder Hash), [IDr,] AUTH, SAi2, TSi, TSr} (4) <-- HDR, SK {IDr, CERT(certificate), CERT(OCSP Response), AUTH, SAr2, TSi, TSr} Figure 1: OCSP Extensions to Baseline IKEv2 In (2) Responder sends an OCSP Responder Hash CERTREq payload identifying an OCSP responder trusted by Responder. In response, Initiator sends in (3) both a CERT payload carrying its certificate and an OCSP Response CERT payload covering that certificate. In (3) Initiator also requests an OCSP response via the OCSP Responder Hash CERTREQ payload. In (4) Responder returns its certificate and a separate OCSP Response CERT payload covering that certificate. It is important to note that in this scenario, Responder in (2) is not yet in possession of Initiator's certificate and therefore cannot form an OCSP request. However, [RFC2560] allows for pre-produced responses. It is thus easily inferred that OCSP responses can be produced in the absence of a corresponding request (OCSP nonces notwithstanding). In such instances OCSP Requests are simply index values into these data. It is also important in extending IKEv2 towards OCSP in this scenario that Initiator have certain knowledge Responder is capable of and willing to participate in the extension. Yet Responder will only trust one or more OCSP responder signatures. These factors motivate the definition of OCSP Responder Hash extension. 5.2 Extended Authentication Protocol (EAP) Another scenario of pressing interest is the use of EAP to accommodate multiple end users seeking enterprise access to an IPSEC gateway. As with the preceding section, the following illustration is extracted from [IKEv2]. In the event of a conflict between this document and [IKEv2] regarding these illustrations, [IKEv2] SHALL dominate. Myers & Tschofenig Expires November 30, 2004 [Page 5] Internet-Draft OCSP Extensions to IKEv2 June 2004 Initiator Responder ----------- ----------- (1) HDR, SAi1, KEi, Ni --> (2) <-- HDR, SAr1, KEr, Nr (3) HDR, SK {IDi, --> CERTREQ(OCSP Responder Hash), [IDr,] AUTH, SAi2, TSi, TSr} (4) <-- HDR, SK {IDr, CERT(certificate), CERT(OCSP Response), AUTH, EAP} (5) HDR, SK {EAP} --> (6) <-- HDR, SK {EAP (success)} (7) HDR, SK {AUTH} --> (8) <-- HDR, SK {AUTH, SAr2, TSi, TSr } Figure 2: OCSP Extensions to EAP in IKEv2 In the EAP scenario, messages (5) through (8) are not relevant to this document. Note that while [IKEv2] allows for the optional inclusion of a CERTREQ in (2), this document asserts no need of its use. It is assumed that environments including this optional payload and yet wishing to implement the OCSP extension to IKEv2 are sufficiently robust as to accommodate this redundant payload. 6. Security Considerations For the reasons noted above, OCSP Responder Hash is used in place of OCSP request syntax to trigger production and transmission of an OCSP response. OCSP as defined in [RFC2560] may contain a nonce request extension to improve security against replay attacks (see Section 4.4.1 of [RFC2560] for further details). The OCSP Responder Hash does not contain such a nonce. But because the OCSP interaction is embedded in IKEv2, replay protection is nonetheless provided to the extent IKEv2 mitigates such attacks on its exchanges. 6. IANA Considerations This document defines two new field types for use in the IKEv2 Cert Encoding field of the Certificate Payload format. Official values for "OCSP Responder Hash" and "OCSP Response" extensions to the Cert Encoding table of Section 3.6 of [IKEv2] need to be acquired from IANA. Myers & Tschofenig Expires November 30, 2004 [Page 6] Internet-Draft OCSP Extensions to IKEv2 June 2004 7. References 7.1 Normative References [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-14 (work in progress), June 2004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S. and Adams, C., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999 [RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. Authors' Addresses Michael Myers TraceRoute Security LLC EMail: mmyers@fastq.com Hannes Tschofenig Siemens Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Myers & Tschofenig Expires November 30, 2004 [Page 7] Internet-Draft OCSP Extensions to IKEv2 June 2004 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Myers & Tschofenig Expires November 30, 2004 [Page 8]