< draft-ietf-aaa-eap-09.txt		draft-ietf-aaa-eap-10.txt >
	Network Working Group P. Eronen, Ed.		Network Working Group P. Eronen, Ed.
	Internet-Draft Nokia		Internet-Draft Nokia
	Expires: February 10, 2005 T. Hiller		Expires: May 18, 2005 T. Hiller
	Lucent Technologies		Lucent Technologies
	G. Zorn		G. Zorn
	Cisco Systems		Cisco Systems
	August 12, 2004		November 17, 2004
	Diameter Extensible Authentication Protocol (EAP) Application		Diameter Extensible Authentication Protocol (EAP) Application
	draft-ietf-aaa-eap-09.txt		draft-ietf-aaa-eap-10.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		This document is an Internet-Draft and is subject to all provisions
	patent or other IPR claims of which I am aware have been disclosed,		of section 3 of RFC 3667. By submitting this Internet-Draft, each
	and any of which I become aware will be disclosed, in accordance with		author represents that any applicable patent or other IPR claims of
			which he or she is aware have been or will be disclosed, and any of
			which he or she become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-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 February 10, 2005.		This Internet-Draft will expire on May 18, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004).
	Abstract		Abstract
	The Extensible Authentication Protocol (EAP) provides a standard		The Extensible Authentication Protocol (EAP) provides a standard
	mechanism for support of various authentication methods. This		mechanism for support of various authentication methods. This
	document defines the Command-Codes and AVPs necessary to carry EAP		document defines the Command-Codes and AVPs necessary to carry EAP
	packets between a Network Access Server (NAS) and a back-end		packets between a Network Access Server (NAS) and a back-end
	authentication server.		authentication server.
	Conventions used in this document		Conventions used in this document
	skipping to change at page 3, line 14 ¶		skipping to change at page 3, line 16 ¶
	8.3 Negotiation attacks . . . . . . . . . . . . . . . . . . . 28		8.3 Negotiation attacks . . . . . . . . . . . . . . . . . . . 28
	8.4 Session key distribution . . . . . . . . . . . . . . . . . 29		8.4 Session key distribution . . . . . . . . . . . . . . . . . 29
	8.5 Privacy issues . . . . . . . . . . . . . . . . . . . . . . 29		8.5 Privacy issues . . . . . . . . . . . . . . . . . . . . . . 29
	8.6 Note about EAP and impersonation . . . . . . . . . . . . . 30		8.6 Note about EAP and impersonation . . . . . . . . . . . . . 30
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
	10.1 Normative References . . . . . . . . . . . . . . . . . . . . 31		10.1 Normative References . . . . . . . . . . . . . . . . . . . . 31
	10.2 Informative References . . . . . . . . . . . . . . . . . . . 31		10.2 Informative References . . . . . . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 32
	A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33		A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . . 38		Intellectual Property and Copyright Statements . . . . . . . . 39
	1. Introduction		1. Introduction
	The Extensible Authentication Protocol (EAP), defined in [EAP], is an		The Extensible Authentication Protocol (EAP), defined in [EAP], is an
	authentication framework which supports multiple authentication		authentication framework which supports multiple authentication
	mechanisms. EAP may be used on dedicated links as well as switched		mechanisms. EAP may be used on dedicated links as well as switched
	circuits, and wired as well as wireless links.		circuits, and wired as well as wireless links.
	To date, EAP has been implemented with hosts and routers that connect		To date, EAP has been implemented with hosts and routers that connect
	via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802		via switched circuits or dial-up lines using PPP [RFC1661], IEEE 802
	wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points		wired switches [IEEE-802.1X], and IEEE 802.11 wireless access points
	[IEEE-802.11i]. EAP has also been adopted for IPsec remote access in		[IEEE-802.11i]. EAP has also been adopted for IPsec remote access in
	IKEv2 [IKEv2].		IKEv2 [IKEv2].
	This document specifies the Diameter EAP application that carries EAP		This document specifies the Diameter EAP application that carries EAP
	packets between a Network Access Server (NAS) working as an EAP		packets between a Network Access Server (NAS) working as an EAP
	Authenticator and a back-end authentication server. The Diameter EAP		Authenticator and a back-end authentication server. The Diameter EAP
	application is based on NASREQ and is intended for similar		application is based on the Diameter Network Access Server
	environments as NASREQ.		Application [NASREQ] and is intended for similar environments as
			NASREQ.
	In Diameter EAP application, authentication occurs between the EAP		In Diameter EAP application, authentication occurs between the EAP
	client and its home Diameter server. This end-to-end authentication		client and its home Diameter server. This end-to-end authentication
	reduces the possibility for fraudulent authentication, such as replay		reduces the possibility for fraudulent authentication, such as replay
	and man-in-the-middle attacks. End-to-end authentication also		and man-in-the-middle attacks. End-to-end authentication also
	provides a possibility for mutual authentication, which is not		provides a possibility for mutual authentication, which is not
	possible with PAP and CHAP in a roaming PPP environment.		possible with PAP and CHAP in a roaming PPP environment.
	The Diameter EAP application relies heavily on [NASREQ], and in		The Diameter EAP application relies heavily on [NASREQ], and in
	earlier drafts was part of the Diameter NASREQ application. It can		earlier drafts was part of the Diameter NASREQ application. It can
	also be used in conjunction with NASREQ, selecting the application		also be used in conjunction with NASREQ, selecting the application
	based on the used authentication mechanism (EAP or PAP/CHAP). The		based on the used authentication mechanism (EAP or PAP/CHAP). The
	Diameter EAP application defines new Command-Codes and new AVPs, and		Diameter EAP application defines new Command-Codes and new AVPs
	can work together with RADIUS EAP support [RFC3579].		(Attribute-Value Pairs), and can work together with RADIUS EAP
			support [RFC3579].
	2. Extensible Authentication Protocol Support in Diameter		2. Extensible Authentication Protocol Support in Diameter
	2.1 Advertising application support		2.1 Advertising application support
	Diameter nodes conforming to this specification MAY advertise support		Diameter nodes conforming to this specification MAY advertise support
	by including the value of TBD-BY-IANA in the Auth-Application-Id AVP		by including the value of TBD-BY-IANA in the Auth-Application-Id AVP
	of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer		of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer
	command [BASE].		command [BASE].
	If the NAS receives a response with the Result-Code set to		If the NAS receives a response with the Result-Code set to
	DIAMETER_APPLICATION_UNSUPPORTED [BASE], it is an indication that the		DIAMETER_APPLICATION_UNSUPPORTED [BASE], it is an indication that the
	Diameter server in the home realm does not support EAP. If possible,		Diameter server in the home realm does not support EAP. If possible,
	the access device MAY attempt to negotiate another authentication		the access device MAY attempt to negotiate another authentication
	protocol, such as PAP or CHAP. An access device SHOULD be cautious		protocol, such as PAP or CHAP. An access device SHOULD be cautious
	when determining whether a less secure authentication protocol will		when determining whether a less secure authentication protocol will
	be used, since this could be a result of a bidding down attack (see		be used, since this could be a result of a downgrade attack (see
	Section 8.3).		Section 8.3).
	2.2 Protocol Overview		2.2 Protocol Overview
	The EAP conversation between the authenticating peer and the access		The EAP conversation between the authenticating peer and the access
	device begins with the initiation of EAP within a link layer, such as		device begins with the initiation of EAP within a link layer, such as
	PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been		PPP [RFC1661] or IEEE 802.11i [IEEE-802.11i]. Once EAP has been
	initiated, the access device will typically send to the Diameter		initiated, the access device will typically send to the Diameter
	server a Diameter-EAP-Request message with an empty EAP-Payload AVP,		server a Diameter-EAP-Request message with an empty EAP-Payload AVP,
	signifying an EAP-Start.		signifying an EAP-Start.
	skipping to change at page 11, line 41 ¶		skipping to change at page 11, line 41 ¶
	| | EAP-Payload(EAP Success) |		| | EAP-Payload(EAP Success) |
	| | EAP-Master-Session-Key |		| | EAP-Master-Session-Key |
	| | (authorization AVPs) |		| | (authorization AVPs) |
	|<-------------------------------|<-------------------------------|		|<-------------------------------|<-------------------------------|
	2.4 Invalid packets		2.4 Invalid packets
	While acting as a pass-through, the NAS MUST validate the EAP header		While acting as a pass-through, the NAS MUST validate the EAP header
	fields (Code, Identifier, Length) prior to forwarding an EAP packet		fields (Code, Identifier, Length) prior to forwarding an EAP packet
	to or from the Diameter server. On receiving an EAP packet from the		to or from the Diameter server. On receiving an EAP packet from the
	peer, the NAS checks the Code (2) and Length fields, and matches the		peer, the NAS checks the Code (Code 2=Response) and Length fields,
	Identifier value against the current Identifier, supplied by the		and matches the Identifier value against the current Identifier,
	Diameter server in the most recently validated EAP Request. On		supplied by the Diameter server in the most recently validated EAP
	receiving an EAP packet from the Diameter server (encapsulated within		Request. On receiving an EAP packet from the Diameter server
	a Diameter-EAP-Answer), the NAS checks the Code (1) and Length		(encapsulated within a Diameter-EAP-Answer), the NAS checks the Code
	fields, then updates the current Identifier value. Pending EAP		(Code 1=Request) and Length fields, then updates the current
	Responses that do not match the current Identifier value are silently		Identifier value. Pending EAP Responses that do not match the
	discarded by the NAS.		current Identifier value are silently discarded by the NAS.
	Since EAP method fields (Type, Type-Data) are typically not validated		Since EAP method fields (Type, Type-Data) are typically not validated
	by a NAS operating as a pass-through, despite these checks it is		by a NAS operating as a pass-through, despite these checks it is
	possible for a NAS to forward an invalid EAP packet to or from the		possible for a NAS to forward an invalid EAP packet to or from the
	Diameter server.		Diameter server.
	A Diameter server receiving an EAP-Payload AVP it does not understand		A Diameter server receiving an EAP-Payload AVP it does not understand
	SHOULD make the determination of whether the error is fatal or		SHOULD make the determination of whether the error is fatal or
	non-fatal based on the EAP Type. A Diameter server determining that		non-fatal based on the EAP Type. A Diameter server determining that
	a fatal error has occurred MUST send an a Diameter-EAP-Answer with a		a fatal error has occurred MUST send a Diameter-EAP-Answer with a
	failure Result-Code and an EAP-Payload AVP encapsulating an EAP		failure Result-Code and an EAP-Payload AVP encapsulating an EAP
	Failure packet. A Diameter server determining that a non-fatal error		Failure packet. A Diameter server determining that a non-fatal error
	has occurred MUST send a Diameter-EAP-Answer with		has occurred MUST send a Diameter-EAP-Answer with
	DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To		DIAMETER_MULTI_ROUND_AUTH Result-Code, but no EAP-Payload AVP. To
	simplify RADIUS translation, this message MUST also include an		simplify RADIUS translation, this message MUST also include an
	EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent		EAP-Reissued-Payload AVP encapsulating the previous EAP Request sent
	by the server.		by the server.
	When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and		When receiving a Diameter-EAP-Answer without an EAP-Payload AVP (and
	DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the		DIAMETER_MULTI_ROUND_AUTH Result-Code), the NAS SHOULD discard the
	skipping to change at page 13, line 25 ¶		skipping to change at page 13, line 25 ¶
	as to provide the Diameter server with this information.		as to provide the Diameter server with this information.
	A Diameter server having received a Framed-MTU AVP in a		A Diameter server having received a Framed-MTU AVP in a
	Diameter-EAP-Request message MUST NOT send any subsequent packet in		Diameter-EAP-Request message MUST NOT send any subsequent packet in
	this EAP conversation containing EAP-Payload AVP whose length exceeds		this EAP conversation containing EAP-Payload AVP whose length exceeds
	the length specified by the Framed-MTU value, taking the link type		the length specified by the Framed-MTU value, taking the link type
	(specified by the NAS-Port-Type AVP) into account. For example, as		(specified by the NAS-Port-Type AVP) into account. For example, as
	noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE		noted in [RFC3580] Section 3.10, for a NAS-Port-Type value of IEEE
	802.11, the RADIUS server may send an EAP packet as large as		802.11, the RADIUS server may send an EAP packet as large as
	Framed-MTU minus four (4) octets, taking into account the additional		Framed-MTU minus four (4) octets, taking into account the additional
	overhead for the IEEE 802.1X Version (1), Type (1) and Body Length		overhead for the IEEE 802.1X Version (1 octet), Type (1 octet) and
	(2) fields.		Body Length (2 octets) fields.
	2.7 Accounting		2.7 Accounting
	When a user is authenticated using EAP, the NAS MAY include an		When a user is authenticated using EAP, the NAS MAY include an
	Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in		Accounting-Auth-Method AVP [NASREQ] with value 5 (EAP) in
	Accounting-Request messages. This document specifies one additional		Accounting-Request messages. This document specifies one additional
	AVP for accounting messages: one or more Accounting-EAP-Auth-Method		AVP for accounting messages: one or more Accounting-EAP-Auth-Method
	AVPs (see Section 4.1.5) MAY be included in Accounting-Request		AVPs (see Section 4.1.5) MAY be included in Accounting-Request
	messages to indicate the EAP method(s) used to authenticate the user.		messages to indicate the EAP method(s) used to authenticate the user.
	If the NAS has authenticated the user with a locally implemented EAP		If the NAS has authenticated the user with a locally implemented EAP
	method, it knows the method used and SHOULD include it in an		method, it knows the method used and SHOULD include it in an
	Accounting-EAP-Auth-Method AVP.		Accounting-EAP-Auth-Method AVP.
	If the authentication was done using Diameter-EAP-Request/Answer		If the authentication was done using Diameter-EAP-Request/Answer
	messages, the Diameter server SHOULD include one more more		messages, the Diameter server SHOULD include one or more
	Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a		Accounting-EAP-Auth-Method AVPs in Diameter-EAP-Answer packets with a
	successful result code. In this case, the NAS SHOULD include these		successful result code. In this case, the NAS SHOULD include these
	AVPs in Accounting-Request messages.		AVPs in Accounting-Request messages.
	2.8 Usage guidelines		2.8 Usage guidelines
	2.8.1 User-Name AVP		2.8.1 User-Name AVP
	Unless the access device interprets the EAP-Response/Identity packet		Unless the access device interprets the EAP-Response/Identity packet
	returned by the authenticating peer, it will not have access to the		returned by the authenticating peer, it will not have access to the
	skipping to change at page 14, line 41 ¶		skipping to change at page 14, line 41 ¶
	a failure Result-Code with an encapsulated EAP Success, it will not		a failure Result-Code with an encapsulated EAP Success, it will not
	grant access to the peer. However, on receiving the EAP Success, the		grant access to the peer. However, on receiving the EAP Success, the
	peer will be lead to believe that access was granted.		peer will be lead to believe that access was granted.
	This situation can be difficult to avoid when Diameter proxy agents		This situation can be difficult to avoid when Diameter proxy agents
	make authorization decisions (that is, proxies can change the		make authorization decisions (that is, proxies can change the
	Result-Code AVP sent by the home server). Since the responsibility		Result-Code AVP sent by the home server). Since the responsibility
	for avoiding conflicts lies with the Diameter server, the NAS MUST		for avoiding conflicts lies with the Diameter server, the NAS MUST
	NOT "manufacture" EAP result packets in order to correct		NOT "manufacture" EAP result packets in order to correct
	contradictory messages that it receives. This behavior, originally		contradictory messages that it receives. This behavior, originally
	mandated within [IEEE-802.1X], will be deprecated in the future.		mandated within [IEEE-802.1X], is now deprecated.
	2.8.3 Displayable messages		2.8.3 Displayable messages
	The Reply-Message AVP [NASREQ] contains text which may be displayed		The Reply-Message AVP [NASREQ] contains text which may be displayed
	to the user. Note that the NAS does not necessarily have any		to the user. Note that the NAS does not necessarily have any
	facility for actually sending these messages to the user. In any		facility for actually sending these messages to the user. In any
	case, the NAS MUST NOT manufacture any EAP packets (such as		case, the NAS MUST NOT manufacture any EAP packets (such as
	EAP-Request/Notification) from Reply-Message AVPs.		EAP-Request/Notification) from Reply-Message AVPs.
	2.8.4 Role reversal		2.8.4 Role reversal
	skipping to change at page 16, line 9 ¶		skipping to change at page 16, line 9 ¶
	[NASREQ] ensure that an Access-Request without the State attribute		[NASREQ] ensure that an Access-Request without the State attribute
	maps to a a new Diameter Session-Id AVP value. Furthermore, a		maps to a a new Diameter Session-Id AVP value. Furthermore, a
	translation agent will always include a State attribute in		translation agent will always include a State attribute in
	Access-Challenge messages, making sure that the State attribute is		Access-Challenge messages, making sure that the State attribute is
	available for a RADIUS NAS.		available for a RADIUS NAS.
	3. Command-Codes		3. Command-Codes
	This section defines new Command-Code values that MUST be supported		This section defines new Command-Code values that MUST be supported
	by all Diameter implementations conforming to this specification.		by all Diameter implementations conforming to this specification.
	The following Command Codes are defined in this section:		The following commands are defined in this section:
	Command-Name Abbrev. Code Reference		Command-Name Abbrev. Code Reference
	--------------------------------------------------------		--------------------------------------------------------
	Diameter-EAP-Request DER 268 3.1		Diameter-EAP-Request DER 268 3.1
	Diameter-EAP-Answer DEA 268 3.2		Diameter-EAP-Answer DEA 268 3.2
	When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used		When the NASREQ AA-Request (AAR) or AA-Answer (AAA) commands are used
	for AUTHORIZE_ONLY messages in conjunction with EAP (see Section		for AUTHORIZE_ONLY messages in conjunction with EAP (see Section
	2.3.3), an Application Identifier value of 1 (NASREQ) is used, and		2.3.3), an Application Identifier value of 1 (NASREQ) is used, and
	the commands follow the rules and ABNF defined in [NASREQ].		the commands follow the rules and ABNF defined in [NASREQ].
	skipping to change at page 20, line 40 ¶		skipping to change at page 20, line 40 ¶
	receiving it from the AAA server. As a result, a Key-Name AVP sent		receiving it from the AAA server. As a result, a Key-Name AVP sent
	in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter		in a Diameter-EAP-Request MUST NOT contain any data. A home Diameter
	server receiving a Diameter-EAP-Request with a Key-Name AVP with		server receiving a Diameter-EAP-Request with a Key-Name AVP with
	non-empty data MUST silently discard the AVP. In addition, the home		non-empty data MUST silently discard the AVP. In addition, the home
	Diameter server SHOULD include this AVP in Diameter-EAP-Response only		Diameter server SHOULD include this AVP in Diameter-EAP-Response only
	if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request.		if an empty EAP-Key-Name AVP was present in Diameter-EAP-Request.
	4.1.5 Accounting-EAP-Auth-Method AVP		4.1.5 Accounting-EAP-Auth-Method AVP
	The Accounting-EAP-Auth-Method AVP (AVP Code TBD-BY-IANA) is of type		The Accounting-EAP-Auth-Method AVP (AVP Code TBD-BY-IANA) is of type
	Unsigned64. In case of expanded types [EAP, Section 5.7], the least		Unsigned64. In case of expanded types [EAP, Section 5.7], this AVP
	significant 32 bits contain the Vendor-Type field, and the next 24		contains the value ((Vendor-Id * 2^32) + Vendor-Type).
	bits contain the Vendor-Id field.
	The use of this AVP is described in Section 2.7.		The use of this AVP is described in Section 2.7.
	5. AVP Occurrence Tables		5. AVP Occurrence Tables
	The following tables use these symbols:		The following tables use these symbols:
	0 The AVP MUST NOT be present in the message		0 The AVP MUST NOT be present in the message
	0+ Zero or more instances of the AVP MAY be present in the		0+ Zero or more instances of the AVP MAY be present in the
	message		message
	skipping to change at page 26, line 35 ¶		skipping to change at page 26, line 35 ¶
	Authorization can involve local Access Control Lists (ACLs),		Authorization can involve local Access Control Lists (ACLs),
	information contained in certificates, or some other means. See		information contained in certificates, or some other means. See
	[BASE] for more discussion and related security considerations. Note		[BASE] for more discussion and related security considerations. Note
	that authorization issues are particularly relevant when Diameter		that authorization issues are particularly relevant when Diameter
	redirects are used. While redirection reduces the number of nodes		redirects are used. While redirection reduces the number of nodes
	which have access to the contents of Diameter messages, a compromised		which have access to the contents of Diameter messages, a compromised
	Diameter agent may not supply the right home server's address. If		Diameter agent may not supply the right home server's address. If
	the Diameter client is unable to tell whether this particular server		the Diameter client is unable to tell whether this particular server
	is authorized to act as the home server for this particular user, the		is authorized to act as the home server for this particular user, the
	security of the communications rests on the redirect agent, even if		security of the communications rests on the redirect agent.
	redirects are used.
	The hop-by-hop security mechanisms (IPsec and TLS) combined with		The hop-by-hop security mechanisms (IPsec and TLS) combined with
	proper authorization provide good protection against "outside"		proper authorization provide good protection against "outside"
	attackers (denial-of-service is, of course, possible). The remaining		attackers, except for denial-of-service attacks. The remaining part
	part of this section deals with attacks by nodes that have been		of this section deals with attacks by nodes that have been properly
	properly authorized (to function as a NAS, Diameter agent, or		authorized (to function as a NAS, Diameter agent, or Diameter server)
	Diameter server) but abuse their authorization or have been		but abuse their authorization or have been compromised. In general,
	compromised. In general, it is not possible to completely protect		it is not possible to completely protect against attacks by
	against attacks by compromised nodes, but this section offers some		compromised nodes, but this section offers some advice that can be
	advice that can be used to limit the extent of the damage.		used to limit the extent of the damage.
	Attacks involving eavesdropping or modification of EAP messages are		Attacks involving eavesdropping or modification of EAP messages are
	beyond the scope of these document. See [EAP] for discussion of		beyond the scope of these document. See [EAP] for discussion of
	these security considerations (including method negotiation,		these security considerations (including method negotiation,
	dictionary attacks, and privacy issues). While these attacks can be		dictionary attacks, and privacy issues). While these attacks can be
	carried out by an attacker between the client and the NAS,		carried out by an attacker between the client and the NAS,
	compromised NASes and Diameter agents are naturally also in a good		compromised NASes and Diameter agents are naturally also in a good
	position to modify and eavesdrop the EAP messages.		position to modify and eavesdrop the EAP messages.
	Similarly, attacks involving whatever link layer protocol is used		Similarly, attacks involving whatever link layer protocol is used
	skipping to change at page 29, line 21 ¶		skipping to change at page 29, line 20 ¶
	authenticated via Diameter. In such cases, if any peers of the NAS		authenticated via Diameter. In such cases, if any peers of the NAS
	MUST do EAP, then the NAS MUST attempt to negotiate EAP for every		MUST do EAP, then the NAS MUST attempt to negotiate EAP for every
	session. This avoids forcing a peer to support more than one		session. This avoids forcing a peer to support more than one
	authentication type, which could weaken security.		authentication type, which could weaken security.
	8.4 Session key distribution		8.4 Session key distribution
	Since there are currently no end-to-end (NAS-to-home server) security		Since there are currently no end-to-end (NAS-to-home server) security
	mechanisms specified for Diameter, any agents that process		mechanisms specified for Diameter, any agents that process
	Diameter-EAP-Answer messages can see the contents of the		Diameter-EAP-Answer messages can see the contents of the
	EAP-Session-Key AVP. For this reason, this specification strongly		EAP-Master-Session-Key AVP. For this reason, this specification
	recommends avoiding Diameter agents when they cannot be trusted to		strongly recommends avoiding Diameter agents when they cannot be
	keep the keys secret.		trusted to keep the keys secret.
	In environments where agents are present, several factors should be		In environments where agents are present, several factors should be
	considered when deciding whether the agents that are authorized (and		considered when deciding whether the agents that are authorized (and
	considered "trustworthy enough") to grant access to users and specify		considered "trustworthy enough") to grant access to users and specify
	various authorization and tunneling AVPs are also "trustworthy		various authorization and tunneling AVPs are also "trustworthy
	enough" to handle the session keys. These factors include (but are		enough" to handle the session keys. These factors include (but are
	not limited to) the type of access provided (e.g., public Internet or		not limited to) the type of access provided (e.g., public Internet or
	corporate internet), security level of the agents, and the		corporate internet), security level of the agents, and the
	possibilities for attacking user's traffic after it has been		possibilities for attacking user's traffic after it has been
	decrypted by the NAS.		decrypted by the NAS.
	skipping to change at page 30, line 27 ¶		skipping to change at page 30, line 24 ¶
	when EAP mutual authentication is used, it occurs between the user		when EAP mutual authentication is used, it occurs between the user
	and the Diameter home server. See [EAPKey] for an extensive		and the Diameter home server. See [EAPKey] for an extensive
	discussion about the details and their implications.		discussion about the details and their implications.
	However, one issue is worth pointing out here. As described in		However, one issue is worth pointing out here. As described in
	[EAPKey], the current EAP architecture does not allow the home server		[EAPKey], the current EAP architecture does not allow the home server
	to restrict what service parameters or identities (such as SSID or		to restrict what service parameters or identities (such as SSID or
	BSSID in 802.11 wireless LANs) are advertised by the NAS to the		BSSID in 802.11 wireless LANs) are advertised by the NAS to the
	client. That is, a compromised NAS can change its BSSID or SSID,		client. That is, a compromised NAS can change its BSSID or SSID,
	thus appearing to offer a different service than intended. Even if		thus appearing to offer a different service than intended. Even if
	these parameters are included in Diameter-EAP-Request messages, the		these parameters are included in Diameter-EAP-Answer messages, the
	NAS can tell different values to the client.		NAS can tell different values to the client.
	Thus, the possession of the session keys by the NAS proves that the		Thus, the possession of the session keys by the NAS proves that the
	user is talking to *some* authorized NAS, but a compromised NAS can		user is talking to *some* authorized NAS, but a compromised NAS can
	lie about its exact identity. See [EAPKey] for discussion how		lie about its exact identity. See [EAPKey] for discussion how
	individual EAP methods can provide authentication of NAS service		individual EAP methods can provide authentication of NAS service
	parameters and identities.		parameters and identities.
	Note that the usefulness of such authentication may be rather limited		Note that the usefulness of such authentication may be rather limited
	in many environments. For instance, in wireless LANs the user does		in many environments. For instance, in wireless LANs the user does
	skipping to change at page 31, line 45 ¶		skipping to change at page 31, line 43 ¶
	and Metropolitan Area Networks: Port-Based Network Access		and Metropolitan Area Networks: Port-Based Network Access
	Control", IEEE Standard 802.1X, September 2001.		Control", IEEE Standard 802.1X, September 2001.
	[IEEE-802.11i]		[IEEE-802.11i]
	Institute of Electrical and Electronics Engineers, "IEEE		Institute of Electrical and Electronics Engineers, "IEEE
	Standard for Information technology - Telecommunications		Standard for Information technology - Telecommunications
	and information exchange between systems - Local and		and information exchange between systems - Local and
	metropolitan area networks - Specific requirements - Part		metropolitan area networks - Specific requirements - Part
	11: Wireless Medium Access Control (MAC) and Physical		11: Wireless Medium Access Control (MAC) and Physical
	Layer (PHY) Specifications: Amendment 6: Medium Access		Layer (PHY) Specifications: Amendment 6: Medium Access
	Control (MAC) Security Enhancements", IEEE Draft P802.11i/		Control (MAC) Security Enhancements", IEEE Standard
	D10.0 (work in progress), April 2004.		802.11i-2004, July 2004.
	[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)		[IKEv2] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
	Protocol", draft-ietf-ipsec-ikev2-14 (work in progress),		Protocol", draft-ietf-ipsec-ikev2-14 (work in progress),
	June 2004.		June 2004.
	[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,		[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
	RFC 1661, July 1994.		RFC 1661, July 1994.
	[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",		[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
	RFC 2548, March 1999.		RFC 2548, March 1999.
	skipping to change at page 33, line 4 ¶		skipping to change at page 32, line 41 ¶
	Authors' Addresses		Authors' Addresses
	Pasi Eronen (editor)		Pasi Eronen (editor)
	Nokia Research Center		Nokia Research Center
	P.O. Box 407		P.O. Box 407
	FIN-00045 Nokia Group		FIN-00045 Nokia Group
	Finland		Finland
	EMail: pasi.eronen@nokia.com		EMail: pasi.eronen@nokia.com
	Tom Hiller		Tom Hiller
	Lucent Technologies		Lucent Technologies
	1960 Lucent Lane		1960 Lucent Lane
	Naperville, IL 60566		Naperville, IL 60566
	USA		USA
	Phone: +1 630 979 7673		Phone: +1 630 979 7673
	EMail: tom.hiller@lucent.com		EMail: tom.hiller@lucent.com
	Glen Zorn		Glen Zorn
	Cisco Systems		Cisco Systems
	500 108th Avenue N.E., Suite 500		500 108th Avenue N.E., Suite 500
	Bellevue, WA 98004		Bellevue, WA 98004
	USA		USA
	Phone: +1 425 344 8113		Phone: +1 425 344 8113
	EMail: gwz@cisco.com		EMail: gwz@cisco.com
	Appendix A. Changelog		Appendix A. Changelog
	(This section will not appear in the final version submitted to RFC		(This section should be removed by the RFC editor.)
	editor.)
			Changes from -09 to -10:
			o Nits from IESG review:
			o Section 2.1: clarification, "bidding down attack" -> "downgrade
			attack".
			o Section 2.8.2: clarified text about manufacturing messages and
			802.1X.
			o Section 4.1.4: typo, "Diameter-EAP-Response" ->
			"Diameter-EAP-Answer".
			o Section 4.1.5: clarified text about expanded types and
			Accounting-EAP-Auth-Method AVP.
			o Section 8.4: typo, "EAP-Session-Key AVP" ->
			"EAP-Master-Session-Key AVP".
			o Other minor nits from IESG review:
			o Section 1: spelled out NASREQ and AVP when mentioned for the first
			time.
			o Section 2.3, clarified "(1)" -> "(Code 1=Request)" and "(2)" ->
			"(Code 2=Response)".
			o Section 2.4: typo, "an a" -> "a".
			o Section 2.6, clarified "(1)" -> "(1 octet)" and "(2)" -> "(2
			octets)".
			o Section 2.7: typo, "more more" -> "or more".
			o Section 3: clarified "The following Command Codes are defined..."
			-> "The following commands are defined...".
			o Section 8.1: removed superflous and slightly confusing words "even
			if redirects are used" from the last sentence of the third
			paragraph.
			o Section 8.1, clarification, "(denial-of-service is, of course,
			possible)" -> "except for denial-of-service attacks".
			o Section 10.2: IEEE 802.11i is no longer "work in progress".
	Changes from -08.a to -09.a:		Changes from -08.a to -09.a:
	o Updated ABNFs and AVP occurrence tables to match NASREQ -17 (issue		o Updated ABNFs and AVP occurrence tables to match NASREQ -17 (issue
	466): Removed Session-Timeout, Idle-Timeout, Class and Failed-AVP		466): Removed Session-Timeout, Idle-Timeout, Class and Failed-AVP
	from DER (and reordered ABNF to match NASREQ). Added Failed-AVP		from DER (and reordered ABNF to match NASREQ). Added Failed-AVP
	and QoS-Filter-Rule to DEA.		and QoS-Filter-Rule to DEA.
	o Clarified that EAP-Key-Name in DER must be empty (issue 465).		o Clarified that EAP-Key-Name in DER must be empty (issue 465).
End of changes. 26 change blocks.
	50 lines changed or deleted		96 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/