< draft-myers-ipsec-ikev2-oscp-01.txt		draft-myers-ipsec-ikev2-oscp-02.txt >
	IPSEC Working Group M. Myers		IPSEC Working Group M. Myers
	Internet-Draft TraceRoute Security LLC		Internet-Draft TraceRoute Security LLC
	Expires May 2005 H. Tschofenig		Expires August 2005 H. Tschofenig
	Siemens		Siemens
	November 2004		February 2005
	OCSP Extensions to IKEv2		OCSP Extensions to IKEv2
	draft-myers-ipsec-ikev2-oscp-01.txt		draft-myers-ipsec-ikev2-oscp-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		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		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 2, line 9 ¶		skipping to change at page 2, line 9 ¶
	OCSP [RFC2560] is one such mechanism. This document applies when OCSP		OCSP [RFC2560] is one such mechanism. This document applies when OCSP
	is desired and security policy prevents one of the IKEv2 peers from		is desired and security policy prevents one of the IKEv2 peers from
	accessing the relevant OCSP responder directly. Firewalls are often		accessing the relevant OCSP responder directly. Firewalls are often
	deployed in a manner that prevents such access by IKEv2 peers outside		deployed in a manner that prevents such access by IKEv2 peers outside
	of an enterprise network.		of an enterprise network.
	1. Introduction		1. Introduction
	Version 2 of the Internet Key Exchange protocol [IKEv2] supports a		Version 2 of the Internet Key Exchange protocol [IKEv2] supports a
	range of authentication mechanisms, including the use of public key		range of authentication mechanisms, including the use of public key
	based authentication (PKI). Confirmation of certificate reliability is		based authentication. Confirmation of certificate reliability is
	essential to achieve the security assurances PKI provides. One		essential to achieve the security assurances public key cryptography
	fundamental element of such confirmation is reference to certificate		provides. One fundamental element of such confirmation is reference to
	revocation status (see [RFC3280] for additional detail).		certificate revocation status (see [RFC3280] for additional detail).
	The historic means of determining certificate revocation status is		The historic means of determining certificate revocation status is
	through the use of Certificate Revocation Lists (CRLs). IKEv2 allows		through the use of Certificate Revocation Lists (CRLs). IKEv2 allows
	CRLs to be exchanged in-band via the CERT payload.		CRLs to be exchanged in-band via the CERT payload.
	CRLs can however grow unbounded in size. Many real-world examples		CRLs can however grow unbounded in size. Many real-world examples
	exist to demonstrate the impracticality of including a multi-megabyte		exist to demonstrate the impracticality of including a multi-megabyte
	file in an IKE exchange. This constraint is particularly acute in		file in an IKE exchange. This constraint is particularly acute in
	bandwidth limited environments (e.g. mobile communications). The net		bandwidth limited environments (e.g. mobile communications). The net
	effect is exclusion of in-band CRLs in favor of out-of-band (OOB)		effect is exclusion of in-band CRLs in favor of out-of-band (OOB)
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	With reference to Section 3.6 of [IKEv2], the values for the Cert		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		Encoding field of the CERT payload are extended as follows (see also
	the IANA Considerations section of this document):		the IANA Considerations section of this document):
	Certificate Encoding Value		Certificate Encoding Value
	-------------------- -----		-------------------- -----
	OCSP Responder Hash 14		OCSP Responder Hash 14
	OCSP Response 15		OCSP Response 15
	3.1 OCSP Responder Hash		3.1 OCSP Responder Hash
	A value of OCSP Responder Hash (14) in the Cert Encoding field of a		A value of OCSP Responder Hash (14) in the Cert Encoding field of a
	CERTREQ Payload indicates the presence of an OCSP Responder certificate		CERTREQ Payload indicates the presence of an OCSP Responder certificate
	hash in the Certificate Authority field of the CERTREQ payload.		hash in the Certificate Authority field of the CERTREQ payload.
	The presence of the OCSP Responder Hash in a CERTREQ message:		The presence of the OCSP Responder Hash in a CERTREQ message:
	1. identifies an OCSP responder trusted by the sender;		1. identifies an OCSP responder trusted by the sender;
	2. notifies the recipient of sender's support for the		2. notifies the recipient of sender's support for the
	skipping to change at page 4, line 26 ¶		skipping to change at page 4, line 26 ¶
	error (e.g. malformedRequest, internalError, tryLater,		error (e.g. malformedRequest, internalError, tryLater,
	sigRequired, unauthorized, etc.);		sigRequired, unauthorized, etc.);
	3. a corresponding OCSP Response CERT payload is not received; OR		3. a corresponding OCSP Response CERT payload is not received; OR
	4. a [TBD] IKEv2 error is received indicating inability to respond.		4. a [TBD] IKEv2 error is received indicating inability to respond.
	4.2 OCSP Response		4.2 OCSP Response
	Upon receipt of an OCSP Responder Hash CERTREQ payload, the recipient		Upon receipt of an OCSP Responder Hash CERTREQ payload, the recipient
	SHALL either:		SHOULD acquire the related OCSP-based assertion and produce and
			transmit an OCSP Response CERT payload corresponding to the certificate
	1. acquire the related OCSP-based assertion and produce		needed to verify its signature on IKEv2 payloads.
	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		An OCSP Response CERT payload SHALL be transmitted separate from any
	other CERT payload in an IKEv2 exchange.		other CERT payload in an IKEv2 exchange.
	Where multiple OCSP responses are useful to an environment, each such		Where multiple OCSP responses are useful to an environment, each such
	SHALL be transmitted via separate OCSP Response CERT payloads.		SHALL be transmitted via separate OCSP Response CERT payloads.
	The means by which an OCSP response may be acquired for production of		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.		an OCSP Response CERT payload is out of scope of this document.
	skipping to change at page 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	CERTREQ(OCSP Responder Hash),		CERTREQ(OCSP Responder Hash),
	[IDr,] AUTH, SAi2, TSi, TSr}		[IDr,] AUTH, SAi2, TSi, TSr}
	(4) <-- HDR, SK {IDr,		(4) <-- HDR, SK {IDr,
	CERT(certificate),		CERT(certificate),
	CERT(OCSP Response),		CERT(OCSP Response),
	AUTH, SAr2, TSi, TSr}		AUTH, SAr2, TSi, TSr}
	Figure 1: OCSP Extensions to Baseline IKEv2		Figure 1: OCSP Extensions to Baseline IKEv2
	In (2) Responder sends an OCSP Responder Hash CERTREq payload		In (2) Responder sends an OCSP Responder Hash CERTREQ payload
	identifying an OCSP responder trusted by Responder. In response,		identifying an OCSP responder trusted by Responder. In response,
	Initiator sends in (3) both a CERT payload carrying its certificate and		Initiator sends in (3) both a CERT payload carrying its certificate and
	an OCSP Response CERT payload covering that certificate. In (3)		an OCSP Response CERT payload covering that certificate. In (3)
	Initiator also requests an OCSP response via the OCSP Responder Hash		Initiator also requests an OCSP response via the OCSP Responder Hash
	CERTREQ payload. In (4) Responder returns its certificate and a		CERTREQ payload. In (4) Responder returns its certificate and a
	separate OCSP Response CERT payload covering that certificate.		separate OCSP Response CERT payload covering that certificate.
	It is important to note that in this scenario, Responder in (2) is not		It is important to note that in this scenario, the Responder in (2)
	yet in possession of Initiator's certificate and therefore cannot form		does not yet possess the Initiator's certificate and therefore cannot
	an OCSP request. However, [RFC2560] allows for pre-produced responses.		form an OCSP request. [RFC2560] allows for pre-produced responses. It
	It is thus easily inferred that OCSP responses can be produced in the		is thus easily inferred that OCSP responses can be produced in the
	absence of a corresponding request (OCSP nonces notwithstanding). In		absence of a corresponding request (OCSP nonces notwithstanding). In
	such instances OCSP Requests are simply index values into these data.		such instances OCSP Requests are simply index values into these data.
	It is also important in extending IKEv2 towards OCSP in this scenario		It is also important in extending IKEv2 towards OCSP in this scenario
	that Initiator have certain knowledge Responder is capable of and		that the Initiator has certain knowledge that the Responder is capable
	willing to participate in the extension. Yet Responder will only trust		of and willing to participate in the extension. Yet the Responder will
	one or more OCSP responder signatures. These factors motivate the		only trust one or more OCSP responder signatures. These factors
	definition of OCSP Responder Hash extension.		motivate the definition of OCSP Responder Hash extension.
	5.2 Extended Authentication Protocol (EAP)		5.2 Extended Authentication Protocol (EAP)
	Another scenario of pressing interest is the use of EAP to accommodate		Another scenario of pressing interest is the use of EAP to accommodate
	multiple end users seeking enterprise access to an IPSEC gateway. As		multiple end users seeking enterprise access to an IPsec gateway. As
	with the preceding section, the following illustration is extracted		with the preceding section, the following illustration is extracted
	from [IKEv2]. In the event of a conflict between this document and		from [IKEv2]. In the event of a conflict between this document and
	[IKEv2] regarding these illustrations, [IKEv2] SHALL dominate.		[IKEv2] regarding these illustrations, [IKEv2] SHALL dominate.
	Initiator Responder		Initiator Responder
	----------- -----------		----------- -----------
	(1) HDR, SAi1, KEi, Ni -->		(1) HDR, SAi1, KEi, Ni -->
	(2) <-- HDR, SAr1, KEr, Nr		(2) <-- HDR, SAr1, KEr, Nr
	(3) HDR, SK {IDi, -->		(3) HDR, SK {IDi, -->
	CERTREQ(OCSP Responder Hash),		CERTREQ(OCSP Responder Hash),
	[IDr,] AUTH, SAi2, TSi, TSr}		[IDr,] AUTH, SAi2, TSi, TSr}
	(4) <-- HDR, SK {IDr,		(4) <-- HDR, SK {IDr,
	CERT(certificate),		CERT(certificate),
	CERT(OCSP Response),		CERT(OCSP Response),
	AUTH, EAP}		AUTH, EAP}
	(5) HDR, SK {EAP} -->		(5) HDR, SK {EAP} -->
	(6) <-- HDR, SK {EAP (success)}		(6) <-- HDR, SK {EAP (success)}
	(7) HDR, SK {AUTH} -->		(7) HDR, SK {AUTH} -->
	(8) <-- HDR, SK {AUTH, SAr2, TSi,		(8) <-- HDR, SK {AUTH, SAr2, TSi,
	TSr }		TSr }
	Figure 2: OCSP Extensions to EAP in IKEv2		Figure 2: OCSP Extensions to EAP in IKEv2
	skipping to change at page 7, line 5 ¶		skipping to change at page 6, line 52 ¶
	IKEv2, replay protection is nonetheless provided to the extent IKEv2		IKEv2, replay protection is nonetheless provided to the extent IKEv2
	mitigates such attacks on its exchanges.		mitigates such attacks on its exchanges.
	6. IANA Considerations		6. IANA Considerations
	This document defines two new field types for use in the IKEv2 Cert		This document defines two new field types for use in the IKEv2 Cert
	Encoding field of the Certificate Payload format. Official values for		Encoding field of the Certificate Payload format. Official values for
	"OCSP Responder Hash" and "OCSP Response" extensions to the Cert		"OCSP Responder Hash" and "OCSP Response" extensions to the Cert
	Encoding table of Section 3.6 of [IKEv2] need to be acquired from IANA.		Encoding table of Section 3.6 of [IKEv2] need to be acquired from IANA.
			Certificate Encoding Value
			-------------------- -----
			OCSP Responder Hash 14
			OCSP Response 15
	7. References		7. References
	7.1 Normative References		7.1 Normative References
	[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-14 (work in progress), June 2004		draft-ietf-ipsec-ikev2-14 (work in progress), June 2004
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", March 1997.		Requirement Levels", March 1997.
End of changes. 15 change blocks.
	33 lines changed or deleted		26 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/