< draft-yegin-eap-boot-rfc3118-00.txt		draft-yegin-eap-boot-rfc3118-01.txt >
	Network Working Group A. Yegin		Network Working Group A. Yegin
	Internet Draft DoCoMo USA Labs		Internet Draft Samsung
	H. Tschofenig		H. Tschofenig
	Siemens Corporate Technology		Siemens Corporate Technology
	D. Forsberg		D. Forsberg
	Nokia		Nokia
	Expires: August 2004 February 2004		Expires: July 2005 January 2005
	Bootstrapping RFC3118 Delayed DHCP Authentication		Bootstrapping RFC3118 Delayed DHCP Authentication
	Using EAP-based Network Access Authentication		Using EAP-based Network Access Authentication
	<draft-yegin-eap-boot-rfc3118-00.txt>		<draft-yegin-eap-boot-rfc3118-01.txt>
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		By submitting this Internet-Draft, I certify that any applicable
	with all provisions of Section 10 of RFC2026.		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		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 Internet-		other groups may also distribute working documents as
	Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at any
	at any time. It is inappropriate to use Internet-Drafts as		time. It is inappropriate to use Internet-Drafts as reference
	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.
	Abstract		This Internet-Draft will expire on July, 2005.
			Copyright Notice
			Copyright (C) The Internet Society (2005). All Rights Reserved.
			Abstract
	DHCP authentication extension (RFC3118) cannot be widely deployed		DHCP authentication extension (RFC3118) cannot be widely deployed
	due to lack of an out-of-band key agreement protocol for DHCP		due to lack of an out-of-band key agreement protocol for DHCP
	clients and servers. This draft outlines how EAP-based network		clients and servers. This draft outlines how EAP-based network
	access authentication mechanisms can be used to establish a local		access authentication mechanisms can be used to establish a local
	trust relation and generate keys that can be used in conjunction		trust relation and generate keys that can be used in conjunction
	with RFC3118.		with RFC3118.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 2] EAP-boot-RFC3118 February 2004		[Page 2] EAP-boot-RFC3118 January 2005
	Table of Contents		Table of Contents
	1.0 Introduction.................................................2		1.0 Introduction.................................................2
	2.0 Terminology..................................................3		2.0 Terminology..................................................3
	3.0 Overview and Building Blocks.................................4		3.0 Overview and Building Blocks.................................4
	4.0 Building DHCP SA.............................................5		4.0 Building DHCP SA.............................................5
	4.1. 802.1X....................................................5		4.1. 802.1X....................................................5
	4.2. PPP.......................................................5		4.2. PPP.......................................................5
	4.3. PANA......................................................7		4.3. PANA......................................................7
	skipping to change at line 98 ¶		skipping to change at line 107 ¶
	authenticate various DHCP messages. It does not support roaming		authenticate various DHCP messages. It does not support roaming
	clients and assumes out-of band or manual key establishment. These		clients and assumes out-of band or manual key establishment. These
	limitations have been inhibiting widespread deployment of this		limitations have been inhibiting widespread deployment of this
	security mechanism [DHC-THREAT].		security mechanism [DHC-THREAT].
	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 trust relation created during the
	access authentication process can be used with RFC 3118 to provide		access authentication process can be used with RFC 3118 to provide
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 3] EAP-boot-RFC3118 February 2004		[Page 3] EAP-boot-RFC3118 January 2005
	security for DHCP. This document defines how to use EAP-based access		security for DHCP. This document defines how to use EAP-based access
	authentication process to bootstrap RFC 3118 for securing DHCP.		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
	authentication method that generates session keys. As part of		authentication method that generates session keys. As part of
	the network access process, the client and the authentication		the network access process, the client and the authentication
	skipping to change at line 149 ¶		skipping to change at line 158 ¶
	To secure DHCP messages a number of parameters including the key		To secure DHCP messages a number of parameters including the key
	that is shared between the client (DHCP client) and the DHCP server		that is shared between the client (DHCP client) and the DHCP server
	have to be established. These parameters are collectively referred		have to be established. These parameters are collectively referred
	to as DHCP security association (or in short DHCP SA).		to as DHCP security association (or in short DHCP SA).
	DHCP SA can be considered as a group security association. The DHCP		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		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		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.		by any one of the DHCP servers that are available to the client.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 4] EAP-boot-RFC3118 February 2004		[Page 4] EAP-boot-RFC3118 January 2005
	- DHCP Key		- DHCP Key
	This term refers to the fresh and unique session key dynamically		This term refers to the fresh and unique session key dynamically
	established between the DHCP client and the DHCP server. This key is		established between the DHCP client and the DHCP server. This key is
	used to protect DHCP messages as described in [RFC3118].		used to protect DHCP messages as described in [RFC3118].
	In this document, the key words "MAY", "MUST, "MUST NOT",		In this document, the key words "MAY", "MUST, "MUST NOT",
	OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be		OPTIONAL","RECOMMENDED "SHOULD", and "SHOULD NOT", are to be
	interpreted as described in [RFC2119].		interpreted as described in [RFC2119].
	skipping to change at line 202 ¶		skipping to change at line 211 ¶
	DHCP relay to a DHCP server in the form of relay agent information		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		[RD03] proposes IPsec protection of the DHCP messages exchanged
	between the DHCP relay and the DHCP server. DHCP objects (protected		between the DHCP relay and the DHCP server. DHCP objects (protected
	with IPsec) can therefore be used to communicate the necessary		with IPsec) can therefore be used to communicate the necessary
	parameters.		parameters.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 5] EAP-boot-RFC3118 February 2004		[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
	skipping to change at line 238 ¶		skipping to change at line 247 ¶
	4.0 Building DHCP SA		4.0 Building 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		TBD.
	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 SA between the PPP peers. Each end of the link must separately		DHCP 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 August 2004		Yegin, et al. Expires July 2005
	[Page 6] EAP-boot-RFC3118 February 2004		[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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at line 291 ¶		skipping to change at line 300 ¶
	NAS and sent to the client. The NAS determines this value by		NAS and sent to the client. The NAS determines this value by
	randomly picking a number from the available secret ID pool. If		randomly picking a number from the available secret ID pool. If
	the client does not request DHCP-SA configuration option, this		the client does not request DHCP-SA configuration option, this
	value is returned to the available identifiers pool. Otherwise,		value is returned to the available identifiers pool. Otherwise,
	it is allocated to the client until the DHCP SA expires. The		it is allocated to the client until the DHCP SA expires. The
	client MUST set this field to all 0s in its own request.		client MUST set this field to all 0s in its own request.
	Nonce Data (variable length)		Nonce Data (variable length)
	Contains the random data generated by the transmitting entity.		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 option is
	by client, and the Nonce_NAS value when the AVP is sent by NAS.		sent by client, and the Nonce_NAS value when the option is sent
	Nonce value MUST be randomly chosen and MUST be at least 128		by NAS. Nonce value MUST be randomly chosen and MUST be at least
	bits in size. Nonce values MUST NOT be reused.		128 bits in size. Nonce values MUST NOT be reused.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 7] EAP-boot-RFC3118 February 2004		[Page 7] EAP-boot-RFC3118 January 2005
	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
	skipping to change at line 351 ¶		skipping to change at line 360 ¶
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	|V M r r r r r r|		|V M r r r r r r|
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	M(andatory)		M(andatory)
	- The 'M' Bit, known as the Mandatory bit, indicates		- The 'M' Bit, known as the Mandatory bit, indicates
	whether support of the AVP is required. This bit is not		whether support of the AVP is required. This bit is not
	set in DHCP-AVP.		set in DHCP-AVP.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 8] EAP-boot-RFC3118 February 2004		[Page 8] EAP-boot-RFC3118 January 2005
	V(endor)		V(endor)
	- The 'V' bit, known as the Vendor-Specific bit, indicates		- The 'V' bit, known as the Vendor-Specific bit, indicates
	whether the optional Vendor-Id field is present in the AVP		whether the optional Vendor-Id field is present in the AVP
	header. This bit is not set in DHCP-AVP.		header. This bit is not set in DHCP-AVP.
	r(eserved)		r(eserved)
	- These flag bits are reserved for future use, and MUST be		- These flag bits are reserved for future use, and MUST be
	skipping to change at line 398 ¶		skipping to change at line 407 ¶
	bits in size. Nonce values MUST NOT be reused.		bits in 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-MD5(AAA-key, const | Secret ID | Nonce_client |
	Nonce_NAS)		Nonce_NAS)
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 9] EAP-boot-RFC3118 February 2004		[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 transported to the authenticator (NAS) at the end of the		and transported to the authenticator (NAS) at the end of the
	successful network access AAA.		successful network access AAA.
	- const:		- const:
	skipping to change at line 446 ¶		skipping to change at line 455 ¶
	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 to the lifetime of the
	network access service. The client host, NAS, and the DHCP server		network access service. The client host, NAS, and the DHCP server
	should be (directly or indirectly) aware of this lifetime at the end		should be (directly or indirectly) aware of this lifetime at the end
	of a network access AAA.		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 August 2004		Yegin, et al. Expires July 2005
	[Page 10] EAP-boot-RFC3118 February 2004		[Page 10] EAP-boot-RFC3118 January 2005
	5.0 Delivering DHCP SA		5.0 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 network access authentication.		the network access authentication.
	The format of the DHCP SA sub-option is:		The format of the DHCP SA sub-option is:
	skipping to change at line 500 ¶		skipping to change at line 509 ¶
	Secret ID		Secret ID
	This is the 32-bit value assigned by the NAS and used to		This is the 32-bit value assigned by the NAS and used to
	identify the DHCP key.		identify the DHCP key.
	DHCP Key		DHCP Key
	128-bit DHCP key computed by the NAS is carried in this field.		128-bit DHCP key computed by the NAS is carried in this field.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 11] EAP-boot-RFC3118 February 2004		[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.0 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 RFC3118 to
	skipping to change at line 551 ¶		skipping to change at line 560 ¶
	not recommended. This authentication option will not be		not recommended. This authentication option will not be
	considered for the purpose of bootstrapping.		considered for the purpose of bootstrapping.
	A value of one in the Protocol field in the authentication		A value of one in the Protocol field in the authentication
	option indicates the delayed authentication. The usage of this		option indicates the delayed authentication. The usage of this
	option is subsequently assumed in this document.		option is subsequently assumed in this document.
	Since the value for this field is known in advance it does not		Since the value for this field is known in advance it does not
	need to be negotiated between the DHCP client and DHCP server.		need to be negotiated between the DHCP client and DHCP server.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 12] EAP-boot-RFC3118 February 2004		[Page 12] EAP-boot-RFC3118 January 2005
	- Algorithm		- Algorithm
	[RFC3118] only defines the usage of HMAC-MD5 (value 1 in the		[RFC3118] only defines the usage of HMAC-MD5 (value 1 in the
	Algorithm field). This document assumes that HMAC-MD5 is used		Algorithm field). This document assumes that HMAC-MD5 is used
	to protect DHCP messages.		to protect DHCP messages.
	Since the value for this field is known in advance it does not		Since the value for this field is known in advance it does not
	need to be negotiated. [TBD: Consider future algorithm support]		need to be negotiated. [TBD: Consider future algorithm support]
	skipping to change at line 606 ¶		skipping to change at line 615 ¶
	- HMAC-MD5 (128 bits)		- HMAC-MD5 (128 bits)
	The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If		The Secret ID is chosen by the NAS to prevent collisions. [NOTE: If
	there are multiple NASes per DHCP server, this identifier space		there are multiple NASes per DHCP server, this identifier space
	might need to be pre-partitioned among the NASes.]		might need to be pre-partitioned among the NASes.]
	HMAC-MD5 is the output of the key message digest computation. Note		HMAC-MD5 is the output of the key message digest computation. Note
	that not all fields of the DHCP message are protected as described		that not all fields of the DHCP message are protected as described
	in [RFC3118].		in [RFC3118].
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 13] EAP-boot-RFC3118 February 2004		[Page 13] EAP-boot-RFC3118 January 2005
	7.0 Security Considerations		7.0 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.
	skipping to change at line 652 ¶		skipping to change at line 661 ¶
	Auth: Mutual;		Auth: Mutual;
	Unique key:		Unique key:
	AAA session key		AAA session key
	Figure 2: Keying Architecture		Figure 2: Keying Architecture
	Figure 2 describes the participating entities and the protocols		Figure 2 describes the participating entities and the protocols
	executed among them. It must be ensured that the derived session key		executed among them. It must be ensured that the derived session key
	between the DHCP client and the server is fresh and unique.		between the DHCP client and the server is fresh and unique.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 14] EAP-boot-RFC3118 February 2004		[Page 14] EAP-boot-RFC3118 January 2005
	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		- Confidentiality protection
	- Replay protection		- Replay protection
	- Integrity protection		- Integrity protection
	Furthermore it is necessary that the two parties (DHCP server and		Furthermore it is necessary that the two parties (DHCP server and
	skipping to change at line 706 ¶		skipping to change at line 715 ¶
	session key between the DHCP client and the DHCP server.		session key between the DHCP client and the DHCP server.
	Furthermore, the key transport mechanism between the NAS and the		Furthermore, the key transport mechanism between the NAS and the
	DHCP server must also provide replay protection (in addition to		DHCP server must also provide replay protection (in addition to
	confidentiality protection).		confidentiality protection).
	Finally, the security mechanisms provided in RFC 3118, for which		Finally, the security mechanisms provided in RFC 3118, for which
	this draft bootstraps the security association, also provides replay		this draft bootstraps the security association, also provides replay
	protection.		protection.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 15] EAP-boot-RFC3118 February 2004		[Page 15] EAP-boot-RFC3118 January 2005
	- Authenticate all parties:		- Authenticate all parties:
	Authentication between the EAP peer and the EAP server is based on		Authentication between the EAP peer and the EAP server is based on
	the used EAP method. After a successful authentication and protocol		the used EAP method. After a successful authentication and protocol
	run, the host and the NAS in the network provide AAA-key		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		confirmation either based on the 4-way handshake in IEEE 802.11i or
	based on the protected PANA exchange. DHCP key confirmation between		based on the protected PANA exchange. DHCP key confirmation between
	the DHCP client and server is provided with the first protected DHCP		the DHCP client and server is provided with the first protected DHCP
	message exchange.		message exchange.
	skipping to change at line 761 ¶		skipping to change at line 770 ¶
	- Compromised NAS and DHCP server:		- Compromised NAS and DHCP server:
	A compromised NAS may leak the DHCP session key and the EAP derived		A compromised NAS may leak the DHCP session key and the EAP derived
	session key (e.g., AAA-key). It will furthermore allow corruption of		session key (e.g., AAA-key). It will furthermore allow corruption of
	the DHCP protocol executed between the hosts and the DHCP server		the DHCP protocol executed between the hosts and the DHCP server
	since NAS either acts as a DHCP relay or a 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		A compromised NAS may also allow creation of further DHCP SAs or
	other known attacks on the DHCP protocol (e.g., address depletion).		other known attacks on the DHCP protocol (e.g., address depletion).
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 16] EAP-boot-RFC3118 February 2004		[Page 16] EAP-boot-RFC3118 January 2005
	A compromised NAS will not be able to modify, replay, inject DHCP		A compromised NAS will not be able to modify, replay, inject DHCP
	messages which use security associations established without the		messages which use security associations established without the
	EAP-based bootstrapping mechanism (e.g., manually configured DHCP		EAP-based bootstrapping mechanism (e.g., manually configured DHCP
	SAs).		SAs).
	On the other hand, a compromised DHCP server may only leak the DHCP		On the other hand, a compromised DHCP server may only leak the DHCP
	key information. AAA-key will not be compromised in this case.		key information. AAA-key will not be compromised in this case.
	- Bind key to appropriate context:		- Bind key to appropriate context:
	skipping to change at line 813 ¶		skipping to change at line 822 ¶
	[RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,		[RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner,
	"Internet Security Association and Key Management Protocol		"Internet Security Association and Key Management Protocol
	(ISAKMP)", RFC 2408, November 1998.		(ISAKMP)", RFC 2408, November 1998.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.:		[PY+02] Penno, R., Yegin, A., Ohba, Y., Tsirtsis, G., Wang, C.:
	"Protocol for Carrying Authentication for Network Access (PANA)		"Protocol for Carrying Authentication for Network Access (PANA)
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 17] EAP-boot-RFC3118 February 2004		[Page 17] EAP-boot-RFC3118 January 2005
	Requirements and Terminology", Internet-Draft, (work in progress),		Requirements and Terminology", Internet-Draft, (work in progress),
	April, 2003.		April, 2003.
	[DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option		[DS02] Droms, R. and Schnizlein, J.: "RADIUS Attributes Sub-option
	for the DHCP Relay Agent Information", Internet-Draft, (work in		for the DHCP Relay Agent Information", Internet-Draft, (work in
	progress), October, 2002.		progress), October, 2002.
	[SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication		[SL+03] Stapp, M. and Lemon, T. and R. Droms: "The Authentication
	Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in		Suboption for the DHCP Relay Agent Option", Internet-Draft, (work in
	skipping to change at line 866 ¶		skipping to change at line 875 ¶
	"Port-Based Network Access Control", IEEE Std 802.1X-2001.		"Port-Based Network Access Control", IEEE Std 802.1X-2001.
	[PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD		[PPP] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661 (STD
	51), July 1994.		51), July 1994.
	11.0 Acknowledgments		11.0 Acknowledgments
	We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for		We would like to thank Yoshihiro Ohba and Mohan Parthasarathy for
	their useful feedback to this work.		their useful feedback to this work.
	Yegin, et al. Expires August 2004		Yegin, et al. Expires July 2005
	[Page 18] EAP-boot-RFC3118 February 2004		[Page 18] EAP-boot-RFC3118 January 2005
	12.0 Author's Addresses		12.0 Author's Addresses
	Alper E. Yegin		Alper E. Yegin
	DoCoMo USA Labs		Samsung Advanced Institute of Technology
	181 Metro Drive, Suite 300		75 West Plumeria Drive
	San Jose, CA, 95110		San Jose, CA 95134
	USA		USA
	Phone: +1 408 451 4743		Phone: +1 408 544 5656
	Email: alper@docomolabs-usa.com		EMail: alper.yegin@samsung.com
	Hannes Tschofenig		Hannes Tschofenig
	Siemens AG		Siemens AG
	Otto-Hahn-Ring 6		Otto-Hahn-Ring 6
	81739 Munich		81739 Munich
	Germany		Germany
	EMail: Hannes.Tschofenig@siemens.com		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 NOKIA GROUP, Finland
	Phone: +358 50 4839470		Phone: +358 50 4839470
	EMail: dan.forsberg@nokia.com		EMail: dan.forsberg@nokia.com
	Full Copyright Statement		Intellectual Property Statement
	Copyright (C) The Internet Society (2004). All Rights Reserved.		The IETF takes no position regarding the validity or scope of any
	This document and translations of it may be copied and furnished to		Intellectual Property Rights or other rights that might be claimed to
	others, and derivative works that comment on or otherwise explain it		pertain to the implementation or use of the technology described in
	or assist in its implementation may be prepared, copied, published		this document or the extent to which any license under such rights
	and distributed, in whole or in part, without restriction of any		might or might not be available; nor does it represent that it has
	kind, provided that the above copyright notice and this paragraph		made any independent effort to identify any such rights. Information
	are included on all such copies and derivative works. However, this		on the procedures with respect to rights in RFC documents can be
	document itself may not be modified in any way, such as by removing		found in BCP 78 and BCP 79.
	the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of
	developing Internet standards in which case the procedures for
	copyrights defined in the Internet Standards process must be
	followed, or as required to translate it into languages other than
	English.
	The limited permissions granted above are perpetual and will not be		Copies of IPR disclosures made to the IETF Secretariat and any
	revoked by the Internet Society or its successors or assigns.		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.
	This document and the information contained herein is provided on an		The IETF invites any interested party to bring to its attention any
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		copyrights, patents or patent applications, or other proprietary
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		rights that may cover technology that may be required to implement
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		this standard. Please address the information to the IETF at
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		ietf-ipr@ietf.org.
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Yegin, et al. Expires August 2004		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 (2005). 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.
			Yegin, et al. Expires July 2005
End of changes. 36 change blocks.
	82 lines changed or deleted		88 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/