< draft-yegin-eap-boot-rfc3118-01.txt		draft-yegin-eap-boot-rfc3118-02.txt >
	Network Working Group A. Yegin		Dynamic Host Configuration H. Tschofenig
	Internet Draft Samsung		Internet-Draft Siemens
	H. Tschofenig		Expires: August 5, 2006 A. Yegin
	Siemens Corporate Technology		Samsung
	D. Forsberg		D. Forsberg
	Nokia		Nokia
			February 2006
	Expires: July 2005 January 2005
	Bootstrapping RFC3118 Delayed DHCP Authentication		Bootstrapping RFC3118 Delayed DHCP Authentication Using EAP-based
	Using EAP-based Network Access Authentication		Network Access Authentication
	<draft-yegin-eap-boot-rfc3118-01.txt>		draft-yegin-eap-boot-rfc3118-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, each author represents that any
	patent or other IPR claims of which I am aware have been disclosed,		applicable patent or other IPR claims of which he or she is aware
	and any of which I become aware will be disclosed, in accordance with		have been or will be disclosed, and any of which he or she becomes
	RFC 3668.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	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
	other groups may also distribute working documents as		other groups may also distribute working documents as Internet-
	Internet-Drafts.		Drafts.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on July, 2005.		This Internet-Draft will expire on August 5, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005). All Rights Reserved.		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	DHCP authentication extension (RFC3118) cannot be widely deployed		The DHCP authentication extension (RFC 3118) cannot be widely
	due to lack of an out-of-band key agreement protocol for DHCP		deployed due to lack of a key agreement protocol. This document
	clients and servers. This draft outlines how EAP-based network		outlines how EAP-based network access authentication mechanisms can
	access authentication mechanisms can be used to establish a local		be used to establish bootstrap keying material that can be used to
	trust relation and generate keys that can be used in conjunction		subsequently use RFC 3118 security.
	with RFC3118.
	Yegin, et al. Expires July 2005
	[Page 2] EAP-boot-RFC3118 January 2005
	Table of Contents		Table of Contents
	1.0 Introduction.................................................2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.0 Terminology..................................................3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.0 Overview and Building Blocks.................................4		3. Overview and Building Blocks . . . . . . . . . . . . . . . . . 6
	4.0 Building DHCP SA.............................................5		4. Buliding DHCP SA . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. 802.1X....................................................5		4.1. 802.1X . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.2. PPP.......................................................5		4.2. PPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.3. PANA......................................................7		4.3. PANA . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.4. Computing DHCP SA.........................................8		4.4. Computing DHCP SA . . . . . . . . . . . . . . . . . . . . 11
	5.0 Delivering DHCP SA..........................................10		5. Delivering DHCP SA . . . . . . . . . . . . . . . . . . . . . . 13
	6.0 Using DHCP SA...............................................11		6. Using DHCP SA . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.0 Security Considerations.....................................13		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8.0 IANA Considerations.........................................16		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	9.0 Open Issues.................................................16		9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23
	10.0 References.................................................16		10. Acknowledegments . . . . . . . . . . . . . . . . . . . . . . . 24
	11.0 Acknowledgments............................................17		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
	12.0 Author's Addresses.........................................18		11.1. Normative References . . . . . . . . . . . . . . . . . . . 25
			11.2. Informative References . . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
			Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1.0 Introduction		1. Introduction
	EAP [EAP] provides a network access authentication framework by		The Extensible Authentication Protocol (EAP) [RFC3748] provides a
	carrying authentication process between the hosts and the access		network access authentication framework by carrying authentication
	networks. The combination of EAP with a AAA architecture allows		process between the hosts and the access networks. The combination
	authentication and authorization of a roaming user to an access		of EAP with a AAA architecture allows authentication and
	network. A successful authentication between a client and the		authorization of a roaming user to an access network. A successful
	network produces a dynamically created trust relation between the		authentication between a client and the network produces a
	two. Various EAP authentication methods (e.g., EAP-TLS, EAP-SIM)		dynamically created trust relation between the two. Almost all EAP
	are capable of generating cryptographic keys between the client and		methods (e.g., EAP-TLS, EAP-SIM) are capable of generating
	the local authentication agent (network access server - NAS) after		cryptographic keys between the EAP peer and the EAP server. Using
	the successful authentication. These keys are commonly used in		key transport via the AAA infrastructure the EAP server makes the
	conjunction with per-packet security mechanisms (e.g., link-layer		EAP-provided keying material available to the Authenticator (e.g.,
	ciphering).		Network Access Server; NAS) after a successful authentication
			attempt. These keys are commonly used in conjunction with per-packet
			security mechanisms (e.g., link-layer ciphering). This procedure is
			described in [I-D.ietf-eap-keying].
	DHCP [RFC2131] is a protocol which provides an end host with the		DHCP [RFC2131] is a protocol which provides a host with configuration
	configuration parameters. The base DHCP does not include any		parameters. The base DHCP does not include any security mechanism,
	security mechanism, hence it is vulnerable to a number of security		hence it is vulnerable to a number of security threats. The security
	threats. Security considerations section of RFC 2131 identifies this		considerations section of RFC 2131 [RFC2131] identifies it as "quite
	protocol as "quite insecure" and lists various security threats.		insecure" and lists various security threats.
	RFC 3118 is the DHCP authentication protocol which defines how to		RFC 3118 [RFC3118] is the DHCP authentication protocol that defines
	authenticate various DHCP messages. It does not support roaming		how to authenticate various DHCP messages. It does not support
	clients and assumes out-of band or manual key establishment. These		roaming clients and assumes out-of-band or manual key establishment.
	limitations have been inhibiting widespread deployment of this		These limitations have been inhibiting widespread deployment of this
	security mechanism [DHC-THREAT].		security mechanism as noted in a DHCPv4 threat analysis [I-D.ietf-
			dhc-v4-threat-analysis].
	It is possible to use the authentication and key exchange procedure		It is possible to use the authentication and key exchange procedure
	executed during the network access authentication to bootstrap a		executed during the network access authentication to bootstrap a
	security association for DHCP. The trust relation created during the		security association for DHCP. The access authentication procedure
	access authentication process can be used with RFC 3118 to provide		can be utilized to dynamically provide the keying material to RFC
			3118 based security protection for DHCP. This document defines how
	Yegin, et al. Expires July 2005		to use the EAP-based access authentication procedure to bootstrap RFC
	[Page 3] EAP-boot-RFC3118 January 2005		3118 security.
	security for DHCP. This document defines how to use EAP-based access
	authentication process to bootstrap RFC 3118 for securing DHCP.
	The general framework of the mechanism described in this I-D can be		The general framework of the mechanism described in this I-D can be
	outlined as follows:		outlined as follows:
	(1) The client gains network access by utilizing an EAP		1. The client gains network access by utilizing an EAP method that
	authentication method that generates session keys. As part of		generates session keys. As part of the network access process,
	the network access process, the client and the authentication		the client and the authentication agent (NAS) communicate their
	agent (NAS) communicate their intention to create a DHCP		intention to create a DHCP security association and exchange the
	security association and exchange the required parameters		required parameters (e.g., nonce, key ID, etc.) The required
	(e.g., nonce, key ID, etc.) The required information exchange		information exchange is handled by the EAP lower-layer which also
	is handled by the EAP lower-layer which also carries EAP.		carries EAP.
	(2) Although the newly generated DHCP SA is already available to		2. Although the newly generated DHCP SA is already available to the
	the DHCP client, in case the NAS (acting as a DHCP relay) and		DHCP client, in case the NAS (acting as a DHCP relay) and the
	the DHCP server are not co-located, the SA parameters need to		DHCP server are not co-located, the SA parameters need to be
	be communicated to the DHCP server. This requires a protocol		communicated to the DHCP server. This requires a protocol
	exchange, which can be piggybacked with the DHCP signaling.		exchange, which can be piggybacked with the DHCP signaling.
	(3) The DHCP signaling that immediately follows the network access		3. The DHCP signaling that immediately follows the network access
	authentication process utilizes RFC3118 to secure the protocol		authentication process utilizes RFC 3118 to secure the protocol
	exchange. Both the client and the server rely on the DHCP SA		exchange. Both the client and the server rely on the DHCP SA to
	to compute and verify the authentication codes.		compute and verify the authentication codes.
	This framework requires extensions to the EAP lower-layers (PPP		This framework requires extensions to the EAP lower-layers (PPP
	[PPP], IEEE 802.1X [8021X], PANA [PANA]) to carry the supplemental		[RFC1661], IEEE 802.1X , PANA [I-D.ietf-pana-pana]) to carry the
	parameters required for the generation of the DHCP SA. Another		supplemental parameters required for the generation of the DHCP SA.
	extension is required to carry the DHCP SA parameters from a DHCP		Another extension is required to carry the DHCP SA parameters from a
	relay to a DHCP server. RFC3118 can be used without any		DHCP relay to a DHCP server. RFC 3118 can be used without any
	modifications or extensions.		modifications or extensions.
	2.0 Terminology		2. Terminology
	This document uses the following terms:
	- DHCP Security Association		In this document, the key words "MAY", "MUST, "MUST NOT",
			OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be
			interpreted as described in [RFC2119].
	To secure DHCP messages a number of parameters including the key		This document uses the following terms:
	that is shared between the client (DHCP client) and the DHCP server
	have to be established. These parameters are collectively referred
	to as DHCP security association (or in short DHCP SA).
	DHCP SA can be considered as a group security association. The DHCP		DHCP Security Association:
	SA parameters are provided to the DHCP server as soon as the client
	chooses the server to carry out DHCP. The same DHCP SA can be used
	by any one of the DHCP servers that are available to the client.
	Yegin, et al. Expires July 2005		To secure DHCP messages a number of parameters including the key
	[Page 4] EAP-boot-RFC3118 January 2005		that is shared between the client (DHCP client) and the DHCP
			server have to be established. These parameters are collectively
			referred to as DHCP security association (or in short DHCP SA).
	- DHCP Key		DHCP SA can be considered as a group security association. The
			DHCP SA parameters are provided to the DHCP server as soon as the
			client chooses the server to carry out DHCP. The same DHCP SA can
			be used by any one of the DHCP servers that are available to the
			client.
	This term refers to the fresh and unique session key dynamically		DHCP Key:
	established between the DHCP client and the DHCP server. This key is
	used to protect DHCP messages as described in [RFC3118].
	In this document, the key words "MAY", "MUST, "MUST NOT",		This term refers to the fresh and unique session key dynamically
	OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be		established between the DHCP client and the DHCP server. This key
	interpreted as described in [RFC2119].		is used to protect DHCP messages as described in [RFC3118].
	3.0 Overview and Building Blocks		3. Overview and Building Blocks
	The bootstrapping mechanism requires protocol interaction between		The bootstrapping mechanism requires protocol interaction between the
	the client host (which acts as a DHCP client), the NAS and the DHCP		client host (which acts as a DHCP client), the NAS and the DHCP
	server. A security association will be established between the DHCP		server. A security association will be established between the DHCP
	server and the DHCP client to protect the DHCP messages.		server and the DHCP client to protect the DHCP messages.
	A DHCP SA is generated based on the EAP SA after a successful EAP		A DHCP SA is generated based on the EAP method derived key after a
	authentication. Both the client and the NAS should agree on the		successful EAP method protocol run. Both the client and the NAS
	generation of a DHCP SA after the EAP SA is created. This involves a		should agree on the generation of a DHCP SA after the EAP SA is
	handshake between the two and exchange of additional parameters		created. This involves a handshake between the two and exchange of
	(such as nonce, key ID, etc.). These additional information needs to		additional parameters (such as nonce, key ID, etc.). These
	be carried over the EAP lower-layer that also carries the EAP		additional information needs to be carried over the EAP lower-layer
	payloads.		that also carries the EAP payloads.
	The DHCP SA is ultimately needed by the DHCP client and the DHCP		The DHCP SA is ultimately needed by the DHCP client and the DHCP
	server. On the network side, the DHCP SA information needs to be		server. On the network side, the DHCP SA information needs to be
	transferred from the NAS (where it is generated) to the DHCP server		transferred from the NAS (where it is generated) to the DHCP server
	(where it will be used). On the client host side, it is transferred		(where it will be used). On the client host side, it is transferred
	from the network access authentication client to the DHCP client.		from the network access authentication client to the DHCP client.
	NAS is always located one IP hop away from the client. If the DHCP		NAS is always located one IP hop away from the client. If the DHCP
	server is on the same link, it can be co-located with the NAS. When		server is on the same link, it can be co-located with the NAS. When
	the NAS and the DHCP server are co-located, an internal mechanism,		the NAS and the DHCP server are co-located, an internal mechanism,
	such as an API, is sufficient for transferring the SA information.		such as an API, is sufficient for transferring the SA information.
	If the DHCP server is multiple hops away from the DHCP client, then		If the DHCP server is multiple hops away from the DHCP client, then
	there must be a DHCP relay on the same link as the client. In that		there must be a DHCP relay on the same link as the client. In that
	case, the NAS should be co-located with the DHCP relay.		case, the NAS should be co-located with the DHCP relay
	[DS02] enables transmission of AAA-related RADIUS attributes from a		[RFC4014] enables transmission of AAA-related RADIUS attributes from
	DHCP relay to a DHCP server in the form of relay agent information		a DHCP relay to a DHCP server in the form of relay agent information
	options. DHCP SA is generated at the end of the AAA process, and		options. DHCP SA is generated at the end of the AAA process, and
	therefore it can be provided to the DHCP server in a sub-option		therefore it can be provided to the DHCP server in a sub-option
	carried along with other AAA-related information. Confidentiality,		carried along with other AAA-related information. Confidentiality,
	replay, and integrity protection of this exchange MUST be provided.		replay, and integrity protection of this exchange MUST be provided.
	[RD03] proposes IPsec protection of the DHCP messages exchanged		[I-D.ietf-dhc-relay-agent-ipsec] proposes IPsec protection of the
	between the DHCP relay and the DHCP server. DHCP objects (protected		DHCP messages exchanged between the DHCP relay and the DHCP server.
	with IPsec) can therefore be used to communicate the necessary		DHCP objects (protected with IPsec) can therefore be used to
	parameters.		communicate the necessary parameters.
	Yegin, et al. Expires July 2005
	[Page 5] EAP-boot-RFC3118 January 2005
	Two different deployment scenarios are illustrated in Figure 1.		Two different deployment scenarios are illustrated in Figure 1.
	+---------+ +------------------+		+---------+ +------------------+
	|EAP Peer/| |EAP Authenticator/|		|EAP Peer/| |EAP Authenticator/|
	| DHCP |<============>| DHCP server |		| DHCP |<============>| DHCP server |
	| client | EAP and DHCP | |		| client | EAP and DHCP | |
	+---------+ +------------------+		+---------+ +------------------+
	Client Host NAS		Client Host NAS
	+---------+ +------------------+ +-----------+		+---------+ +------------------+ +-----------+
	|EAP Peer/| |EAP Authenticator/| | |		|EAP Peer/| |EAP Authenticator/| | |
	| DHCP |<============>| DHCP relay |<========>|DHCP server|		| DHCP |<============>| DHCP relay |<========>|DHCP server|
	| client | EAP and DHCP | | DHCP | |		| client | EAP and DHCP | | DHCP | |
	+---------+ +------------------+ +-----------+		+---------+ +------------------+ +-----------+
	Client Host NAS		Client Host NAS
	Figure 1: Protocols and end points.		Figure 1: Protocols and end points.
	When the DHCP SA information is received by the DHCP server and		When the DHCP SA information is received by the DHCP server and
	client, it can be used along with RFC3118 to protect DHCP messages		client, it can be used along with RFC 3118 to protect DHCP messages
	against various security threats. This draft provides the guidelines		against various security threats. This draft provides the guidelines
	regarding how the RFC3118 protocol fields should be filled in based		regarding how the RFC 3118 protocol fields should be filled in based
	on the DHCP SA.		on the DHCP SA.
	4.0 Building DHCP SA		4. Buliding DHCP SA
	DHCP SA is created at the end of the EAP-based access authentication		DHCP SA is created at the end of the EAP-based access authentication
	process. This section describes extensions to the EAP lower-layers		process. This section describes extensions to the EAP lower-layers
	for exchanging the additional information, and the process of		for exchanging the additional information, and the process of
	generating the DHCP SA.		generating the DHCP SA.
	4.1. 802.1X		4.1. 802.1X
	TBD.		[Editor's Note: This work needs to be done outside the IETF.]
	4.2. PPP		4.2. PPP
	A new IPCP configuration option is defined in order to bootstrap		A new IPCP configuration option is defined in order to bootstrap DHCP
	DHCP SA between the PPP peers. Each end of the link must separately		SA between the PPP peers. Each end of the link must separately
	request this option for mutual establishment of DHCP SA. Only one		request this option for mutual establishment of DHCP SA. Only one
	side sending the option will not produce any state.		side sending the option will not produce any state.
	Yegin, et al. Expires July 2005
	[Page 6] EAP-boot-RFC3118 January 2005
	The detailed DHCP-SA Configuration Option is presented below.		The detailed DHCP-SA Configuration Option is presented below.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Reserved |		| Type | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Secret ID |		| Secret ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Nonce Data ~		~ Nonce Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Type		Figure 2: DHCP SA Configuration Option
	TBD
	Length		Type
	>=24		o TBD
	Reserved		Length
	A 16-bit value reserved for future use. It MUST be initialized		o >=24
	to zero by the sender, and ignored by the receiver.
	Secret ID		Reserved
	32 bit value that identifies the DHCP Key produced as a result		o A 16-bit value reserved for future use. It MUST be initialized to
	of the bootstrapping process. This value is determined by the		zero by the sender, and ignored by the receiver.
	NAS and sent to the client. The NAS determines this value by
	randomly picking a number from the available secret ID pool. If
	the client does not request DHCP-SA configuration option, this
	value is returned to the available identifiers pool. Otherwise,
	it is allocated to the client until the DHCP SA expires. The
	client MUST set this field to all 0s in its own request.
	Nonce Data (variable length)		Secret ID
			o 32 bit value that identifies the DHCP Key produced as a result of
			the bootstrapping process. This value is determined by the NAS
			and sent to the client. The NAS determines this value by randomly
			picking a number from the available secret ID pool. If the client
			does not request DHCP-SA configuration option, this value is
			returned to the available identifiers pool. Otherwise, it is
			allocated to the client until the DHCP SA expires. The client
			MUST set this field to all 0s in its own request.
	Contains the random data generated by the transmitting entity.		Nonce Data (variable length)
	This field contains the Nonce_client value when the option is
	sent by client, and the Nonce_NAS value when the option is sent
	by NAS. Nonce value MUST be randomly chosen and MUST be at least
	128 bits in size. Nonce values MUST NOT be reused.
	Yegin, et al. Expires July 2005		o Contains the random data generated by the transmitting entity.
	[Page 7] EAP-boot-RFC3118 January 2005		This field contains the Nonce_client value when the option is sent
			by client, and the Nonce_NAS value when the option is sent by NAS.
			Nonce value MUST be randomly chosen and MUST be at least 128 bits
			in size. Nonce values MUST NOT be reused.
	4.3. PANA		4.3. PANA
	A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP-		A new PANA AVP is defined in order to bootstrap DHCP SA. The DHCP-
	AVP is included in the PANA-Bind-Request message if PAA (NAS) is		AVP is included in the PANA-Bind-Request message if PAA (NAS) is
	offering DHCP SA bootstrapping service. If the PaC wants to proceed		offering DHCP SA bootstrapping service. If the PaC wants to proceed
	with creating DHCP SA at the end of the PANA authentication, it MUST		with creating DHCP SA at the end of the PANA authentication, it MUST
	include DHCP-AVP in its PANA-Bind-Answer message.		include DHCP-AVP in its PANA-Bind-Answer message.
	Absence of this AVP in the PANA-Bind-Request message sent by the PAA		Absence of this AVP in the PANA-Bind-Request message sent by the PAA
	indicates unavailability of this additional service. In that case,		indicates unavailability of this additional service. In that case,
	PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore		PaC MUST NOT include DHCP-AVP in its response, and PAA MUST ignore
	received DHCP-AVP. When this AVP is received by the PaC, it may or		received DHCP-AVP. When this AVP is received by the PaC, it may or
	may not include the AVP in its response depending on its desire to		may not include the AVP in its response depending on its desire to
	create a DHCP SA. A DHCP SA can be created as soon as each entity		create a DHCP SA. A DHCP SA can be created as soon as each entity
	has received and sent one DHCP-AVP.		has received and sent one DHCP-AVP.
	The detailed DHCP-AVP format is presented below.		The detailed DHCP-AVP format is presented below:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AVP Code |		| AVP Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AVP Flags | AVP Length |		| AVP Flags | AVP Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Secret ID |		| Secret ID |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	~ Nonce Data ~		~ Nonce Data ~
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	AVP Code		Figure 3: DHCP AVP Format
	TBD		AVP Code
	AVP Flags		o TBD
	The AVP Flags field is eight bits. The following bits are		AVP Flags
	assigned:
			o The AVP Flags field is eight bits. The following bits are
			assigned:
	0 1 2 3 4 5 6 7		0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|V M r r r r r r|		|V M r r r r r r|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	M(andatory)		Figure 4: DHCP AVP Flags
	- The 'M' Bit, known as the Mandatory bit, indicates		M(andatory)
	whether support of the AVP is required. This bit is not
	set in DHCP-AVP.
	Yegin, et al. Expires July 2005		o The 'M' Bit, known as the Mandatory bit, indicates whether support
	[Page 8] EAP-boot-RFC3118 January 2005		of the AVP is required. This bit is not set in DHCP-AVP.
	V(endor)		V(endor)
	- The 'V' bit, known as the Vendor-Specific bit, indicates		o The 'V' bit, known as the Vendor-Specific bit, indicates whether
	whether the optional Vendor-Id field is present in the AVP		the optional Vendor-Id field is present in the AVP header. This
	header. This bit is not set in DHCP-AVP.		bit is not set in DHCP-AVP.
	r(eserved)		r(eserved)
	- These flag bits are reserved for future use, and MUST be		o These flag bits are reserved for future use, and MUST be set to
	set to zero, and ignored by the receiver.		zero, and ignored by the receiver.
	AVP Length		AVP Length
	The AVP Length field is three octets, and indicates the number		o The AVP Length field is three octets, and indicates the number of
	of octets in this AVP including the AVP Code, AVP Length, AVP		octets in this AVP including the AVP Code, AVP Length, AVP Flags,
	Flags, and AVP data.		and AVP data.
	Secret ID		Secret ID
	A 32-bit value that identifies the DHCP Key produced as a		o A 32-bit value that identifies the DHCP Key produced as a result
	result of the bootstrapping process. This value is determined		of the bootstrapping process. This value is determined by the PAA
	by the PAA and sent to the PaC. The PAA determines this value		and sent to the PaC. The PAA determines this value by randomly
	by randomly picking a number from the available secret ID pool.		picking a number from the available secret ID pool. If PaC's
	If PaC's response does not contain DHCP-AVP then this value is		response does not contain DHCP-AVP then this value is returned to
	returned to the available identifiers pool. Otherwise, it is		the available identifiers pool. Otherwise, it is allocated to the
	allocated to the PaC until the DHCP SA expires. The PaC MUST		PaC until the DHCP SA expires. The PaC MUST set this field to all
	set this field to all 0s in its response.		0s in its response.
	Nonce Data (variable length)		Nonce Data (variable length)
	Contains the random data generated by the transmitting entity.		o Contains the random data generated by the transmitting entity.
	This field contains the Nonce_client value when the AVP is sent		This field contains the Nonce_client value when the AVP is sent by
	by PaC, and the Nonce_NAS value when the AVP is sent by PAA.		PaC, and the Nonce_NAS value when the AVP is sent by PAA. Nonce
	Nonce value MUST be randomly chosen and MUST be at least 128		value MUST be randomly chosen and MUST be at least 128 bits in
	bits in size. Nonce values MUST NOT be reused.		size. Nonce values MUST NOT be reused.
	4.4. Computing DHCP SA		4.4. Computing DHCP SA
	The key derivation procedure is reused from IKE [RFC2409]. The		The key derivation procedure is reused from IKE [RFC2409]. The
	character '|' denotes concatenation.		character '|' denotes concatenation.
	DHCP Key = HMAC-MD5(AAA-key, const | Secret ID | Nonce_client |		DHCP Key = HMAC-SHA1(AAA-key, const | Secret ID | Nonce_client |
	Nonce_NAS)		Nonce_NAS)
	Yegin, et al. Expires July 2005
	[Page 9] EAP-boot-RFC3118 January 2005
	The values have the following meaning:		The values have the following meaning:
	- AAA-key:		AAA-key:
	A key derived by the EAP peer and EAP (authentication) server		A key derived by the EAP peer and EAP (authentication) server and
	and transported to the authenticator (NAS) at the end of the		transported to the authenticator (NAS) at the end of the
	successful network access AAA.		successful network access AAA.
	- const:		const:
	This is a string constant. The value of the const parameter is		This is a string constant. The value of the const parameter is
	set to "EAP RFC3118 Bootstrapping".		set to "EAP RFC 3118 Bootstrapping".
	- Secret ID:		Secret ID:
	The unique identifier of the DHCP key as carried by the EAP		The unique identifier of the DHCP key as carried by the EAP lower-
	lower-layer protocol extension.		layer protocol extension.
	- Nonce_client:		Nonce Client:
	This random number is provided by the client and carried by the		This random number is provided by the client and carried by the
	EAP lower-layer protocol extension.		EAP lower-layer protocol extension.
	- Nonce_NAS:		Nonce NAS:
	This random number is provided by the NAS and carried by the		This random number is provided by the NAS and carried by the EAP
	EAP lower-layer protocol.		lower-layer protocol.
	- DHCP Key:		DHCP Key:
	This session key is 128-bit in length and used as the session		This session key is 128-bit in length and used as the session key
	key for securing DHCP messages. Figure 1 of [EAP-Key] refers to		for securing DHCP messages. Figure 1 of [EAP-Key] refers to this
	this derived key as a Transient Session Key (TSK).		derived key as a Transient Session Key (TSK).
	The lifetime of the DHCP security association has to be limited to		The lifetime of the DHCP security association has to be limited to
	prevent the DHCP server from storing state information indefinitely.		prevent the DHCP server from storing state information indefinitely.
	The lifetime of the DHCP SA should be set to the lifetime of the		The lifetime of the DHCP SA SHOULD be set equal to the lifetime of
	network access service. The client host, NAS, and the DHCP server		the network access service. The client host, NAS, and the DHCP
	should be (directly or indirectly) aware of this lifetime at the end		server SHOULD be (directly or indirectly) aware of this lifetime at
	of a network access AAA.		the end of a network access AAA.
	The PaC can at any time trigger a new bootstrapping protocol run to		The PaC can at any time trigger a new bootstrapping protocol run to
	establish a new security association with the DHCP server. The IP		establish a new security association with the DHCP server. The IP
	address lease time SHOULD be limited by the DHCP SA lifetime.		address lease time SHOULD be limited by the DHCP SA lifetime
	Yegin, et al. Expires July 2005
	[Page 10] EAP-boot-RFC3118 January 2005
	5.0 Delivering DHCP SA		5. Delivering DHCP SA
	When the NAS and the DHCP server are not co-located, the DHCP SA		When the NAS and the DHCP server are not co-located, the DHCP SA
	information is carried from the NAS (DHCP relay) to the DHCP server		information is carried from the NAS (DHCP relay) to the DHCP server
	in a DHCP relay agent info option. This sub-option can be included		in a DHCP relay agent info option. This sub-option can be included
	along with the RADIUS attributes sub-option that is carried after		along with the RADIUS attributes sub-option that is carried after the
	the network access authentication.		network access authentication.
	The format of the DHCP SA sub-option is:		The format of the DHCP SA sub-option is:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| SubOpt Code | Length | Reserved |		| SubOpt Code | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Secret ID |		| Secret ID |
	skipping to change at line 487 ¶		skipping to change at page 13, line 34 ¶
	+ +		+ +
	| |		| |
	+ DHCP Key +		+ DHCP Key +
	| |		| |
	+ +		+ +
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Lifetime |		| Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	SubOpt Code		Figure 5: DHCP SA Suboption
	TBD		subopt code:
	Length		TBD
	This value is set to 26.		Length:
	Reserved		This value is set to 26.
	A 16-bit value reserved for future use. It MUST be initialized		Reserved:
	to zero by the sender, and ignored by the receiver.
	Secret ID		A 16-bit value reserved for future use. It MUST be initialized to
			zero by the sender, and ignored by the receiver.
	This is the 32-bit value assigned by the NAS and used to		Secret ID:
	identify the DHCP key.
	DHCP Key		This is the 32-bit value assigned by the NAS and used to identify
			the DHCP key.
	128-bit DHCP key computed by the NAS is carried in this field.		DHCP Key:
	Yegin, et al. Expires July 2005		128-bit DHCP key computed by the NAS is carried in this field.
	[Page 11] EAP-boot-RFC3118 January 2005
	Lifetime		Lifetime:
	The lifetime of the DHCP SA. This Unsigned32 value contains the		The lifetime of the DHCP SA. This Unsigned32 value contains the
	number of seconds remaining before the DHCP SA is considered		number of seconds remaining before the DHCP SA is considered
	expired.		expired.
	6.0 Using DHCP SA		6. Using DHCP SA
	Once the DHCP SA is in place, it is used along with RFC3118 to		Once the DHCP SA is in place, it is used along with RFC 3118 to
	secure the DHCP protocol exchange.		secure the DHCP protocol exchange.
	[RFC3118] defines two security protocols with a newly defined		RFC 3118 [RFC3118] defines two security protocols with a newly
	authentication option:		defined authentication option:
	- Configuration token		o Configuration token
	- Delayed authentication
	The generic format of the authentication option is defined in		o Delayed authentication
	Section 2 of [RFC3118] and contains the following fields:
	- Code		The generic format of the authentication option is defined in Section
			2 of RFC 3118 [RFC3118] and contains the following fields:
	The value for the Code field of this authentication option is		o Code
	90.
	- Length		o Delayed authentication
	The Length field indicates the length of the authentication		The value for the Code field of this authentication option is 90.
	option payload.
	- Protocol		o Length
	[RFC3118] defines two values for the Protocol field - zero and		The Length field indicates the length of the authentication option
	one. A value of zero indicates the usage of the configuration		payload.
	token authentication option.
	As described in Section 4 of [RFC3118] the configuration token		o Protocol
	only provides weak entity authentication. Hence its usage is
	not recommended. This authentication option will not be
	considered for the purpose of bootstrapping.
	A value of one in the Protocol field in the authentication		RFC 3118 [RFC3118] defines two values for the Protocol field - zero
	option indicates the delayed authentication. The usage of this		and one. A value of zero indicates the usage of the configuration
	option is subsequently assumed in this document.		token authentication option.
	Since the value for this field is known in advance it does not		As described in Section 4 of RFC 3118 [RFC3118] the configuration
	need to be negotiated between the DHCP client and DHCP server.		token only provides weak entity authentication. Hence its usage is
			not recommended. This authentication option will not be considered
			for the purpose of bootstrapping.
	Yegin, et al. Expires July 2005		A value of one in the Protocol field in the authentication option
	[Page 12] EAP-boot-RFC3118 January 2005		indicates the delayed authentication. The usage of this option is
			subsequently assumed in this document.
	- Algorithm		Since the value for this field is known in advance it does not need
			to be negotiated between the DHCP client and DHCP server.
	[RFC3118] only defines the usage of HMAC-MD5 (value 1 in the		o Algorithm
	Algorithm field). This document assumes that HMAC-MD5 is used
	to protect DHCP messages.
	Since the value for this field is known in advance it does not		RFC 3118 [RFC3118] only defines the usage of HMAC-MD5 (value 1 in the
	need to be negotiated. [TBD: Consider future algorithm support]		Algorithm field). This document assumes that HMAC-MD5 is used to
			protect DHCP messages.
	- Replay Detection Method (RDM)		Since the value for this field is known in advance it does not need
			to be negotiated. [Editor's Note: Consider future algorithm support]
	The value of zero for the RDM name space is assigned to use a		o Replay Detection Method (RDM)
	monotonically increasing value.
	Since the value for this field is known in advance it does not		The value of zero for the RDM name space is assigned to use a
	need to be negotiated.		monotonically increasing value.
	- Replay Detection		Since the value for this field is known in advance it does not need
			to be negotiated.
	This field contains the value that is used for replay		o Replay Detection
	protection. This value MUST be monotonically increasing
	according to the provided replay detection method. An initial
	value must, however, be set. In case of bootstrapping with EAP
	an initial value of zero is used. The length of 64 bits (and a
	start-value of zero) ensures that a sequence number rollover is
	very unlikely to occur.
	Since the value for this field is known in advance it does not		This field contains the value that is used for replay protection.
	need to be negotiated.		This value MUST be monotonically increasing according to the provided
			replay detection method. An initial value must, however, be set. In
			case of bootstrapping with EAP an initial value of zero is used. The
			length of 64 bits (and a start-value of zero) ensures that a sequence
			number rollover is very unlikely to occur.
	- Authentication Information		Since the value for this field is known in advance it does not need
			to be negotiated.
	The content of this field depends on the type of message where		o Authentication Information
	the authentication option is used. Section 5.2 of [RFC3118]
	does not provide content for the DHCPDISCOVER and the
	DHCPINFORM message. Hence for these messages no additional
	considerations need to be specified in this document.
	For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of		The content of this field depends on the type of message where the
	the Authentication Information field is given as:		authentication option is used. Section 5.2 of RFC 3118 [RFC3118]
			does not provide content for the DHCPDISCOVER and the DHCPINFORM
			message. Hence for these messages no additional considerations need
			to be specified in this document.
	- Secret ID (32 bits)		Since the value for this field is known in advance it does not need
	- HMAC-MD5 (128 bits)		to be negotiated.
	The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If		For a DHCPOFFER, DHCPREQUEST or DHCPACK message the content of the
	there are multiple NASes per DHCP server, this identifier space		Authentication Information field is given as:
	might need to be pre-partitioned among the NASes.]
	HMAC-MD5 is the output of the key message digest computation. Note		o Secret ID (32 bits)
	that not all fields of the DHCP message are protected as described
	in [RFC3118].
	Yegin, et al. Expires July 2005		o HMAC-MD5 (128 bits)
	[Page 13] EAP-boot-RFC3118 January 2005
	7.0 Security Considerations		The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If
			there are multiple NASes per DHCP server, this identifier space might
			need to be pre-partitioned among the NASes.]
			HMAC-MD5 is the output of the key message digest computation. Note
			that not all fields of the DHCP message are protected as described in
			RFC 3118 [RFC3118].
			7. Security Considerations
	This document describes a mechanism for dynamically establishing a		This document describes a mechanism for dynamically establishing a
	security association to protect DHCP signaling messages.		security association to protect DHCP signaling messages.
	If the NAS and the DHCP server are co-located then the session keys		If the NAS and the DHCP server are co-located then the session keys
	and the security parameters are transferred locally (via an API		and the security parameters are transferred locally (via an API
	call). Some security protocols already exercise similar methodology		call). Some security protocols already exercise similar methodology
	to separate functionality.		to separate functionality.
	If the NAS and the DHCP server are not co-located then there is some		If the NAS and the DHCP server are not co-located then there is some
	similarity to the requirements and issues discussed with the EAP		similarity to the requirements and issues discussed with the EAP
	Keying Framework (see [AS+03]). Figure 2 is originally taken from		Keying Framework (see [I-D.ietf-eap-keying]). The DHCP key is a TSK
	Section 4.1 of [AS+03] and extended accordingly. DHCP key is a TSK		(Transient Session Key from [I-D.ietf-eap-keying]). The key is
	(Transient Session Key [AS+03]). The key is generated by both the		generated by both the DHCP client and the DHCP relay, and transported
	DHCP client and the DHCP relay, and transported from the DHCP relay		from the DHCP relay to the DHCP server. The DHCP protocol exchange
	to the DHCP server. DHCP protocol traffic between the DHCP client		between the DHCP client and DHCP server is protected using this key.
	and DHCP server is protected using this key.
	EAP peer (DHCP client) +-----------------------+ DHCP server		EAP peer (DHCP client) +-----------------------+ DHCP server
	/\ /		/\ /
	/ \ Protocol: EAP /		/ \ Protocol: EAP /
	/ \ lower-layer; /		/ \ lower-layer; /
	/ \ Auth: Mutual; /		/ \ Auth: Mutual; /
	/ \ Unique key: /		/ \ Unique key: /
	Protocol: EAP; / \ DHCP key /		Protocol: EAP; / \ DHCP key /
	Auth: Mutual; / \ / Protocol: DHCP, or API;		Auth: Mutual; / \ / Protocol: DHCP, or API;
	Unique keys: MK, / \ / Auth: Mutual;		Unique keys: MK, / \ / Auth: Mutual;
	TEKs, EMSK / \ / Unique key: DHCP key		TEKs, EMSK / \ / Unique key: DHCP key
	/ \ /		/ \ /
	/ \ /		/ \ /
	Auth. server +----------------------+ Authenticator		Auth. server +----------------------+ Authenticator
	Protocol: AAA; (NAS, DHCP relay)		Protocol: AAA; (NAS, DHCP relay)
	Auth: Mutual;		Auth: Mutual;
	Unique key:		Unique key:
	AAA session key		AAA session key
	Figure 2: Keying Architecture		Figure 6: Keying Architecture
	Figure 2 describes the participating entities and the protocols
	executed among them. It must be ensured that the derived session key
	between the DHCP client and the server is fresh and unique.
	Yegin, et al. Expires July 2005		Figure 6 describes the participating entities and the protocols
	[Page 14] EAP-boot-RFC3118 January 2005		executed among them. It must be ensured that the derived session key
			between the DHCP client and the DHCP server is fresh and unique.
	The key transport mechanism, which is used to carry the session key		The key transport mechanism, which is used to carry the session key
	between the NAS and DHCP server, must provide the following		between the NAS and DHCP server, must provide the following
	functionality:		functionality:
	- Confidentiality protection		o Confidentiality protection
	- Replay protection
	- Integrity protection
	Furthermore it is necessary that the two parties (DHCP server and		o Replay protection
			o Integrity protection
			Furthermore, it is necessary that the two parties (DHCP server and
	the NAS) authorize the establishment of the DHCP security		the NAS) authorize the establishment of the DHCP security
	association.		association.
	At IETF 56 Russ Housley presented a list of recommendations for key		Below we provide a list of security properties of the suggested
	management protocols which describe requirements for an acceptable		mechanism:
	solution. Although the presentation focused on NASREQ some issues
	might be also applicable in this context.
	- Algorithm independence:		Algorithm independence:
	This proposal bootstraps a DHCP security association for RFC 3118		This proposal bootstraps a DHCP security association for RFC 3118
	where only a single integrity algorithm (namely HMAC-MD5) is		where only a single integrity algorithm (namely HMAC-MD5) is
	proposed which is mandatory to implement.		proposed which is mandatory to implement.
	- Establish strong, fresh session keys (maintain algorithm		Establish strong, fresh session keys (maintain algorithm
	independence):		independence):
	This scheme relies on EAP methods to provide strong and fresh		This scheme relies on EAP methods to provide strong and fresh
	session keys for each initial authentication and key exchange		session keys for each initial authentication and key exchange
	protocol run. Furthermore the key derivation function provided in		protocol run. Furthermore the key derivation function provided in
	Section 4.4 contains random numbers provided by the client and the		Section 4.4 contains random numbers provided by the client and the
	NAS which additionally add randomness to the generated key.		NAS which additionally add randomness to the generated key.
	- Replay protection:
	Replay protection is provided at different places.
	The EAP method executed between the EAP peer and the EAP server MUST
	provide a replay protection mechanism.
	Additionally random numbers and the secret ID are included in the
	key derivation procedure which aim to provide a fresh and unique
	session key between the DHCP client and the DHCP server.
	Furthermore, the key transport mechanism between the NAS and the
	DHCP server must also provide replay protection (in addition to
	confidentiality protection).
	Finally, the security mechanisms provided in RFC 3118, for which
	this draft bootstraps the security association, also provides replay
	protection.
	Yegin, et al. Expires July 2005
	[Page 15] EAP-boot-RFC3118 January 2005
	- Authenticate all parties:
	Authentication between the EAP peer and the EAP server is based on
	the used EAP method. After a successful authentication and protocol
	run, the host and the NAS in the network provide AAA-key
	confirmation either based on the 4-way handshake in IEEE 802.11i or
	based on the protected PANA exchange. DHCP key confirmation between
	the DHCP client and server is provided with the first protected DHCP
	message exchange.
	- Perform authorization:
	Authorization for network access is provided during the EAP
	exchange. The authorization procedure for DHCP bootstrapping is
	executed by the NAS before this service is offered to the client.
	The NAS might choose not to include DHCP-AVP or DHCP SA
	Configuration Option during network access authorization based on
	the authorization policies.
	- Maintain confidentiality of session keys:
	The DHCP session keys are only known to the intended parties (i.e.,
	to the DHCP client, relay [TBD: is that OK?], and server). The EAP
	protocol itself does not transport keys. The exchanged random
	numbers which are incorporated into the key derivation function do
	not need to be kept confidential.
	DHCP relay agent information MUST be protected using [RD03] with
	non-null IPsec encryption.
	- Confirm selection of "best" cipher-suite:
	This proposal does not provide confidentiality protection of DHCP
	signaling messages. Only a single algorithm is offered for integrity
	protection. Hence no algorithm negotiation and therefore no
	confirmation of the selection occur.
	- Uniquely name session keys:
	The DHCP SA is uniquely identified using a Secret ID (described in
	[RFC3118] and reused in this document).
	- Compromised NAS and DHCP server:		Replay protection:
	A compromised NAS may leak the DHCP session key and the EAP derived		Replay protection is provided at different places. The EAP method
	session key (e.g., AAA-key). It will furthermore allow corruption of		executed between the EAP peer and the EAP server MUST provide a
	the DHCP protocol executed between the hosts and the DHCP server		replay protection mechanism. Additionally random numbers and the
	since NAS either acts as a DHCP relay or a DHCP server.		secret ID are included in the key derivation procedure which aim
			to provide a fresh and unique session key between the DHCP client
			and the DHCP server. Furthermore, the key transport mechanism
			between the NAS and the DHCP server must also provide replay
			protection (in addition to confidentiality protection). Finally,
			the security mechanisms provided in RFC 3118, for which this draft
			bootstraps the security association, also provides replay
			protection.
	A compromised NAS may also allow creation of further DHCP SAs or		Authenticate all parties:
	other known attacks on the DHCP protocol (e.g., address depletion).
	Yegin, et al. Expires July 2005		Authentication between the EAP peer and the EAP server is based on
	[Page 16] EAP-boot-RFC3118 January 2005		the used EAP method. After a successful authentication and
			protocol run, the host and the NAS in the network provide AAA-key
			confirmation either based on the 4-way handshake in IEEE 802.11i
			or based on the protected PANA exchange. DHCP key confirmation
			between the DHCP client and server is provided with the first
			protected DHCP message exchange.
	A compromised NAS will not be able to modify, replay, inject DHCP		Perform authorization:
	messages which use security associations established without the
	EAP-based bootstrapping mechanism (e.g., manually configured DHCP
	SAs).
	On the other hand, a compromised DHCP server may only leak the DHCP		Authorization for network access is provided during the EAP
	key information. AAA-key will not be compromised in this case.		exchange. The authorization procedure for DHCP bootstrapping is
			executed by the NAS before this service is offered to the client.
			The NAS might choose not to include DHCP-AVP or DHCP SA
			Configuration Option during network access authorization based on
			the authorization policies.
	- Bind key to appropriate context:		Maintain confidentiality of session keys:
	The key derivation function described in Section 4.4 includes		The DHCP session keys are only known to the intended parties
	parameters (such as the secret ID and a constant) which prevents		(i.e., to the DHCP client, relay, and server). The EAP protocol
	reuse of the established session key for other purposes.		itself does not transport keys. The exchanged random numbers
			which are incorporated into the key derivation function do not
			need to be kept confidential. DHCP relay agent information MUST
			be protected using [RFC4014] with non-null IPsec encryption.
	8.0 IANA Considerations		Confirm selection of 'best' cipher-suite:
	TBD		This proposal does not provide confidentiality protection of DHCP
			signaling messages. Only a single algorithm is offered for
			integrity protection. Hence no algorithm negotiation and
			therefore no confirmation of the selection occur.
	9.0 Open Issues		Uniquely name session keys:
	This document describes a bootstrapping procedure for [RFC3118]. The		The DHCP SA is uniquely identified using a Secret ID (described in
	same procedure could be applied for [DHCPv6].		[RFC3118] and reused in this document).
	10.0 References		Compromised NAS and DHCP server:
	[DHCPv6] R. Droms, J. Bound, B. Volz, T. Lemon, C. Perkins and M.		A compromised NAS may leak the DHCP session key and the EAP
	Carney: "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",		derived session key (e.g., AAA-key). It will furthermore allow
	Internet-Draft, (work in progress), November, 2002.		corruption of the DHCP protocol executed between the hosts and the
			DHCP server since NAS either acts as a DHCP relay or a DHCP
			server. A compromised NAS may also allow creation of further DHCP
			SAs or other known attacks on the DHCP protocol (e.g., address
			depletion). A compromised NAS will not be able to modify, replay,
			inject DHCP messages which use security associations established
			without the EAP-based bootstrapping mechanism (e.g., manually
			configured DHCP SAs). On the other hand, a compromised DHCP
			server may only leak the DHCP key information. AAA-key will not
			be compromised in this case.
	[PANA] D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin:		Bind key to appropriate context:
	"Protocol for Carrying Authentication for Network Access (PANA)",
	Internet-Draft, (work in progress), March, 2003.
	[RFC3118] R. Droms and W. Arbaugh: "Authentication for DHCP		The key derivation function described in Section 4.4 includes
	Messages", RFC 3118, June 2001.		parameters (such as the secret ID and a constant) which prevents
			reuse of the established session key for other purposes.
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		8. IANA Considerations
	(IKE)", RFC 2409, November 1998.
	[RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,		[Editor's Note: A future version of this draft will provide IANA
	"Internet Security Association and Key Management Protocol		considerations.]
	(ISAKMP)", RFC 2408, November 1998.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		9. Open Issues
	Requirement Levels", BCP 14, RFC 2119, March 1997.
	[PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.:		This document describes a bootstrapping procedure for DHCPv4. The
	"Protocol for Carrying Authentication for Network Access (PANA)		same procedure could be applied for DHCPv6 but is not described in
			this document.
	Yegin, et al. Expires July 2005		10. Acknowledegments
	[Page 17] EAP-boot-RFC3118 January 2005
	Requirements and Terminology", Internet-Draft, (work in progress),		We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for
	April, 2003.		their feedback to this document. Additionally, we would to thank
			Ralph Droms, Allison Mankin and Barr Hibbs for their support to
			continue this work.
	[DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option		11. References
	for the DHCP Relay Agent Information", Internet-Draft, (work in
	progress), October, 2002.
	[SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication		11.1. Normative References
	Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in
	progress), April, 2003.
	[AS+03] Aboba, B., Simon, D., Arkko, J. and H. Levkowetz: "EAP		[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
	Keying Framework", Internet-Draft, (work in progress), October 2003.		RFC 1661, July 1994.
	[RFC2132] Alexander, S. and Droms, R.: "DHCP Options and BOOTP		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Vendor Extensions", RFC 2132, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2131] R. Droms: "Dynamic Host Configuration Protocol", RFC 2131,		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
	March 1997.		RFC 2131, March 1997.
	[WH+03] J. Walker, R. Housley, and N. Cam-Winget, "AAA key		[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
	distribution", Internet Draft, (work in progress), April 2002.		Messages", RFC 3118, June 2001.
	[RFC2548] Zorn, G., "Microsoft Vendor-Specific RADIUS Attributes",		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
	RFC 2548, March 1999.		Levkowetz, "Extensible Authentication Protocol (EAP)",
			RFC 3748, June 2004.
	[CFB02] Calhoun, P., Farrell, S., Bulley, W., "Diameter CMS Security		[RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication
	Application", Internet-Draft, (work in progress), March 2002.		Dial-In User Service (RADIUS) Attributes Suboption for the
			Dynamic Host Configuration Protocol (DHCP) Relay Agent
			Information Option", RFC 4014, February 2005.
	[RD03] R. Droms: "Authentication of DHCP Relay Agent Options Using		11.2. Informative References
	IPsec", Internet-Draft (work in progress), August 2003.
	[SE03] J. Salowey and P. Eronen: "EAP Key Derivation for Multiple		[I-D.ietf-dhc-relay-agent-ipsec]
	Applications", Internet-Draft (work in progress), June 2003.		Droms, R., "Authentication of DHCP Relay Agent Options
			Using IPsec", draft-ietf-dhc-relay-agent-ipsec-02 (work in
			progress), May 2005.
	[DHC-THREAT] Hibbs, R., Smith, C., Volz, B., Zohar, M., "Dynamic		[I-D.ietf-dhc-v4-threat-analysis]
	Host Configuration Protocol for IPv4 (DHCPv4) Threat Analysis",		Hibbs, R., Smith, C., Volz, B., and M. Zohar, "Dynamic
	Internet-draft (expired), June 2003.		Host Configuration Protocol for IPv4 (DHCPv4) Threat
			Analysis", draft-ietf-dhc-v4-threat-analysis-02 (work in
			progress), April 2004.
	[8021X] IEEE Standard for Local and Metropolitan Area Networks,		[I-D.ietf-eap-keying]
	"Port-Based Network Access Control", IEEE Std 802.1X-2001.		Aboba, B., "Extensible Authentication Protocol (EAP) Key
			Management Framework", draft-ietf-eap-keying-09 (work in
			progress), January 2006.
	[PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD		[I-D.ietf-pana-pana]
	51), July 1994.		Forsberg, D., "Protocol for Carrying Authentication for
			Network Access (PANA)", draft-ietf-pana-pana-10 (work in
			progress), July 2005.
	11.0 Acknowledgments		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
			(IKE)", RFC 2409, November 1998.
	We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for		Authors' Addresses
	their useful feedback to this work.
	Yegin, et al. Expires July 2005		Hannes Tschofenig
	[Page 18] EAP-boot-RFC3118 January 2005		Siemens
			Otto-Hahn-Ring 6
			Munich, Bayern 81739
			Germany
	12.0 Author's Addresses		Email: Hannes.Tschofenig@siemens.com
			URI: http://www.tschofenig.com
	Alper E. Yegin		Alper E. Yegin
	Samsung Advanced Institute of Technology		Samsung
	75 West Plumeria Drive		Istanbul,
	San Jose, CA 95134		Turkey
	USA
	Phone: +1 408 544 5656
	EMail: alper.yegin@samsung.com
	Hannes Tschofenig		Phone:
	Siemens AG		Email: alper01.yegin@partner.samsung.com
	Otto-Hahn-Ring 6
	81739 Munich
	Germany
	EMail: Hannes.Tschofenig@siemens.com
	Dan Forsberg		Dan Forsberg
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 NOKIA GROUP, Finland		FIN-00045
			Finland
	Phone: +358 50 4839470		Phone: +358 50 4839470
	EMail: dan.forsberg@nokia.com		Email: dan.forsberg@nokia.com
	Intellectual Property Statement		Intellectual Property Statement
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	skipping to change at line 938 ¶		skipping to change at page 28, line 41 ¶
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
	Yegin, et al. Expires July 2005
End of changes. 200 change blocks.
	549 lines changed or deleted		492 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/