< draft-ietf-pana-framework-09.txt		draft-ietf-pana-framework-10.txt >
	PANA Working Group P. Jayaraman		PANA Working Group P. Jayaraman
	Internet-Draft Net.Com		Internet-Draft Net.Com
	Expires: December 14, 2007 R. Lopez		Intended status: Informational R. Lopez
	Univ. of Murcia		Expires: March 9, 2008 Univ. of Murcia
	Y. Ohba (Ed.)		Y. Ohba (Ed.)
	Toshiba		Toshiba
	M. Parthasarathy		M. Parthasarathy
	Nokia		Nokia
	A. Yegin		A. Yegin
	Samsung		Samsung
	June 12, 2007		September 6, 2007
	Protocol for Carrying Authentication for Network Access (PANA) Framework		Protocol for Carrying Authentication for Network Access (PANA) Framework
	draft-ietf-pana-framework-09		draft-ietf-pana-framework-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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 becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		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
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 December 14, 2007.		This Internet-Draft will expire on March 9, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines the general PANA framework functional elements,		This document defines the general PANA framework functional elements,
	high-level call flow, and deployment environments.		high-level call flow, and deployment environments.
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	layer that uses IP between the protocol end points.		layer that uses IP between the protocol end points.
	The motivation to define such a protocol and the requirements are		The motivation to define such a protocol and the requirements are
	described in [RFC4058]. Protocol details are documented in		described in [RFC4058]. Protocol details are documented in
	[I-D.ietf-pana-pana]. Upon following a successful PANA		[I-D.ietf-pana-pana]. Upon following a successful PANA
	authentication, per-data-packet security can be achieved by using		authentication, per-data-packet security can be achieved by using
	physical security, link-layer ciphering, or IPsec		physical security, link-layer ciphering, or IPsec
	[I-D.ietf-pana-ipsec]. The server implementation of PANA may or may		[I-D.ietf-pana-ipsec]. The server implementation of PANA may or may
	not be co-located with the entity enforcing the per-packet access		not be co-located with the entity enforcing the per-packet access
	control function. When the server for PANA and per-packet access		control function. When the server for PANA and per-packet access
	control entities are separate, SNMP [I-D.ietf-pana-snmp] may be used		control entities are separate, a protocol (e.g.,
	to carry information between the two nodes.		[I-D.ietf-ancp-protocol]) may be used to carry information between
			the two nodes.
	PANA is intended to be used in any access network regardless of the		PANA is intended to be used in any access network regardless of the
	underlying security. For example, the network might be physically		underlying security. For example, the network might be physically
	secured, or secured by means of cryptographic mechanisms after the		secured, or secured by means of cryptographic mechanisms after the
	successful client-network authentication.		successful client-network authentication. While mandatory to
			implement behavior for a PANA deployment is the integrity of PANA
			messages when the EAP method produces MSK, there is no mandatory to
			implement support for network security either at the link-layer or
			network-layer.
	This document defines the general framework for describing how these		This document defines the general framework for describing how these
	various PANA and other network access authentication elements		various PANA and other network access authentication elements
	interact with each other, especially considering the two basic types		interact with each other, especially considering the two basic types
	of deployment environments.		of deployment environments.
	1.1. Specification of Requirements		1.1. Specification of Requirements
	In this document, several words are used to signify the requirements		In this document, several words are used to signify the requirements
	of the specification. These words are often capitalized. The key		of the specification. These words are often capitalized. The key
	skipping to change at page 4, line 27 ¶		skipping to change at page 4, line 27 ¶
	(protocols, APIs) among them.		(protocols, APIs) among them.
	RADIUS,		RADIUS,
	Diameter,		Diameter,
	+-----+ PANA +-----+ LDAP, API, etc. +-----+		+-----+ PANA +-----+ LDAP, API, etc. +-----+
	| PaC |<----------------->| PAA |<------------------->| AS |		| PaC |<----------------->| PAA |<------------------->| AS |
	+-----+ +-----+ +-----+		+-----+ +-----+ +-----+
	^ ^		^ ^
	| |		| |
	| +-----+ |		| +-----+ |
	IKE, +-------->| EP |<--------+ SNMP, API, etc.		IKE, +-------->| EP |<--------+ ANCP, API, etc.
	4-way handshake, +-----+		4-way handshake, +-----+
	etc. .		etc. .
	.		.
	.		.
	v		v
	Data traffic		Data traffic
	Figure 1: PANA Functional Model		Figure 1: PANA Functional Model
	PANA Client (PaC):		PANA Client (PaC):
	skipping to change at page 5, line 17 ¶		skipping to change at page 5, line 17 ¶
	public access networks), a protocol needs to run between the two.		public access networks), a protocol needs to run between the two.
	AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are		AAA protocols like RADIUS [RFC2865] and Diameter [RFC3588] are
	commonly used for this purpose.		commonly used for this purpose.
	The PAA is also responsible for updating the access control state		The PAA is also responsible for updating the access control state
	(i.e., filters) depending on the creation and deletion of the		(i.e., filters) depending on the creation and deletion of the
	authorization state. The PAA communicates the updated state to		authorization state. The PAA communicates the updated state to
	the Enforcement Points in the network. If the PAA and EP are		the Enforcement Points in the network. If the PAA and EP are
	residing on the same node, an API is sufficient for this		residing on the same node, an API is sufficient for this
	communication. Otherwise, a protocol is required to carry the		communication. Otherwise, a protocol is required to carry the
	authorized client attributes from the PAA to the EP. Separated		authorized client attributes from the PAA to the EP.
	PAA and EPs MUST implement SNMP [I-D.ietf-pana-snmp], although the
	use of this protocol is optional (i.e., a substitute PAA-to-EP
	protocol may be used).
	The PAA resides on a node that is typically called a NAS (network		The PAA resides on a node that is typically called a NAS (network
	access server) in the access network. For example on a BRAS		access server) in the access network. For example on a BRAS
	(Broadband Remote Access Server) [DSL] in DSL networks, or PDSN		(Broadband Remote Access Server) [DSL] in DSL networks, or PDSN
	(Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may		(Packet Data Serving Node) [3GPP2] in 3GPP2 networks. The PAA may
	be one or more IP hops away from the PaCs.		be one or more IP hops away from the PaCs.
	Authentication Server (AS):		Authentication Server (AS):
	The server implementation that is in charge of verifying the		The server implementation that is in charge of verifying the
	skipping to change at page 5, line 51 ¶		skipping to change at page 5, line 48 ¶
	The access control implementation that is in charge of allowing		The access control implementation that is in charge of allowing
	access (data traffic) of authorized clients while preventing		access (data traffic) of authorized clients while preventing
	access by others. An EP learns the attributes of the authorized		access by others. An EP learns the attributes of the authorized
	clients from the PAA.		clients from the PAA.
	The EP uses non-cryptographic or cryptographic filters to		The EP uses non-cryptographic or cryptographic filters to
	selectively allow and discard data packets. These filters may be		selectively allow and discard data packets. These filters may be
	applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec].		applied at the link-layer or the IP-layer [I-D.ietf-pana-ipsec].
	When cryptographic access control is used, a secure association		When cryptographic access control is used, a secure association
	protocol (e.g., [RFC2409], [RFC4306], [802.11i]) needs to run		protocol ([RFC3748]) needs to run between the PaC and EP. After
	between the PaC and EP. After completion of the secure		completion of the secure association protocol, link or network
	association protocol, link or network layer per-packet security		layer per-packet security (for example TKIP, IPsec ESP) is enabled
	(for example TKIP, IPsec ESP) is enabled for integrity protection,		for integrity protection, data origin authentication, replay
	data origin authentication, replay protection and optionally		protection and optionally confidentiality protection.
	confidentiality protection.
	An EP is located between the access network (the topology within		An EP is located between the access network (the topology within
	reach of any client) and the accessed network (the topology within		reach of any client) and the accessed network (the topology within
	reach of only authorized clients). It must be located		reach of only authorized clients). It must be located
	strategically in a local area network to minimize the access of		strategically in a local area network to minimize the access of
	unauthorized clients. It is recommended but not mandated that the		unauthorized clients. It is recommended but not mandated that the
	EP be on-path between the PaC and the PAA for the aforementioned		EP be on-path between the PaC and the PAA for the aforementioned
	reason. For example, the EP can be hosted on the switch that is		reason. For example, the EP can be hosted on the switch that is
	directly connected to the clients in a wired network. That way		directly connected to the clients in a wired network. That way
	the EP can drop unauthorized packets before they reach any other		the EP can drop unauthorized packets before they reach any other
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	address configuration takes place.		address configuration takes place.
	An initially unauthorized PaC starts the PANA authentication by		An initially unauthorized PaC starts the PANA authentication by
	discovering the PAA, followed by the EAP exchange over PANA. The PAA		discovering the PAA, followed by the EAP exchange over PANA. The PAA
	interacts with the AS during this process. Upon receiving the		interacts with the AS during this process. Upon receiving the
	authentication and authorization result from the AS, the PAA informs		authentication and authorization result from the AS, the PAA informs
	the PaC about the result of its network access request.		the PaC about the result of its network access request.
	If the PaC is authorized to gain the access to the network, the PAA		If the PaC is authorized to gain the access to the network, the PAA
	also sends the PaC-specific attributes (e.g., IP address,		also sends the PaC-specific attributes (e.g., IP address,
	cryptographic keys, etc.) to the EP by using another protocol (e.g.,		cryptographic keys, etc.) to the EP by using another protocol. The
	SNMP). The EP uses this information to alter its filters for		EP uses this information to alter its filters for allowing data
	allowing data traffic from and to the PaC to pass through.		traffic from and to the PaC to pass through.
	In case cryptographic access control needs to be enabled after the		In case cryptographic access control needs to be enabled after the
	PANA authentication, a secure association protocol runs between the		PANA authentication, a secure association protocol runs between the
	PaC and the EP. Dynamic parameters required for that protocol (e.g.,		PaC and the EP. Dynamic parameters required for that protocol (e.g.,
	endpoint identity, shared secret) are derived from successful PANA		endpoint identity, shared secret) are derived from successful PANA
	authentication; these parameters are used to authenticate the PaC to		authentication; these parameters are used to authenticate the PaC to
	the EP and vice-versa as part of creating the security association.		the EP and vice-versa as part of creating the security association.
	For example, see [I-D.ietf-pana-ipsec] for how it is done for IKE		For example, see [I-D.ietf-pana-ipsec] for how it is done for IKE
	based on using a key-generating EAP method for PANA between the PaC		[RFC2409] [RFC4306] based on using a key-generating EAP method for
	and PAA. The secure association protocol exchange produces the		PANA between the PaC and PAA. The secure association protocol
	required security associations between the PaC and the EP to enable		exchange produces the required security associations between the PaC
	cryptographic data traffic protection. Per-packet cryptographic data		and the EP to enable cryptographic data traffic protection. Per-
	traffic protection introduces additional per-packet overhead but the		packet cryptographic data traffic protection introduces additional
	overhead exists only between the PaC and EP and will not affect		per-packet overhead but the overhead exists only between the PaC and
	communications beyond the EP.		EP and will not affect communications beyond the EP.
	Finally, filters that are installed at the EP allow general purpose		Finally, filters that are installed at the EP allow general purpose
	data traffic to flow between the PaC and the intranet/Internet.		data traffic to flow between the PaC and the intranet/Internet.
	4. Environments		4. Environments
	PANA can be used on any network environment whether there is a lower-		PANA can be used on any network environment whether there is a lower-
	layer secure channel between the PaC and the EP prior to PANA, or one		layer secure channel between the PaC and the EP prior to PANA, or one
	has to be enabled upon successful PANA authentication.		has to be enabled upon successful PANA authentication.
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	by means of cryptographic protection (a.2). By the time the		by means of cryptographic protection (a.2). By the time the
	client requests access to the network-layer services, it is		client requests access to the network-layer services, it is
	already authenticated and authorized for accessing the radio		already authenticated and authorized for accessing the radio
	channel, and link-layer ciphering is enabled.		channel, and link-layer ciphering is enabled.
	The presence of a secure channel before PANA exchange eliminates		The presence of a secure channel before PANA exchange eliminates
	the need for executing a secure association protocol after PANA.		the need for executing a secure association protocol after PANA.
	The PANA session can be associated with the communication channel		The PANA session can be associated with the communication channel
	it was carried over. Also, the choice of EAP authentication		it was carried over. Also, the choice of EAP authentication
	method depends on the presence of this security during PANA run.		method depends on the presence of this security during PANA run.
	For example, weak authentication methods, such as EAP-MD5, may be
	used for such networks but not for the others.
	b. Networks where a secure channel is created after running PANA		b. Networks where a secure channel is created after running PANA
	These are the networks where there is no lower-layer protection		These are the networks where there is no lower-layer protection
	prior to running PANA. A successful PANA authentication enables		prior to running PANA. A successful PANA authentication enables
	generation of cryptographic keys that are used with a secure		generation of cryptographic keys that are used with a secure
	association protocol to enable per-packet cryptographic		association protocol to enable per-packet cryptographic
	protection.		protection.
	PANA authentication is run on an insecure channel that is		PANA authentication is run on an insecure channel that is
	skipping to change at page 14, line 26 ¶		skipping to change at page 14, line 26 ¶
	[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange		[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
	(IKE)", RFC 2409, November 1998.		(IKE)", RFC 2409, November 1998.
	[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication		[RFC4016] Parthasarathy, M., "Protocol for Carrying Authentication
	and Network Access (PANA) Threat Analysis and Security		and Network Access (PANA) Threat Analysis and Security
	Requirements", RFC 4016, March 2005.		Requirements", RFC 4016, March 2005.
	[I-D.ietf-pana-snmp]
	Mghazli, Y., "SNMP usage for PAA-EP interface",
	draft-ietf-pana-snmp-06 (work in progress), June 2006.
	[I-D.ietf-pana-pana]		[I-D.ietf-pana-pana]
	Forsberg, D., "Protocol for Carrying Authentication for		Forsberg, D., "Protocol for Carrying Authentication for
	Network Access (PANA)", draft-ietf-pana-pana-15 (work in		Network Access (PANA)", draft-ietf-pana-pana-17 (work in
	progress), May 2007.		progress), June 2007.
	[I-D.ietf-pana-ipsec]		[I-D.ietf-pana-ipsec]
	Parthasarathy, M., "PANA Enabling IPsec based Access		Parthasarathy, M., "PANA Enabling IPsec based Access
	Control", draft-ietf-pana-ipsec-07 (work in progress),		Control", draft-ietf-pana-ipsec-07 (work in progress),
	July 2005.		July 2005.
	[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,		[RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang,
	"Protocol for Carrying Authentication for Network Access		"Protocol for Carrying Authentication for Network Access
	(PANA) Requirements", RFC 4058, May 2005.		(PANA) Requirements", RFC 4058, May 2005.
	skipping to change at page 15, line 8 ¶		skipping to change at page 15, line 5 ¶
	8.2. Informative References		8.2. Informative References
	[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,		[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
	"Remote Authentication Dial In User Service (RADIUS)",		"Remote Authentication Dial In User Service (RADIUS)",
	RFC 2865, June 2000.		RFC 2865, June 2000.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588, September 2003.		Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
	[802.11i] Institute of Electrical and Electronics Engineers, "IEEE		[I-D.ietf-ancp-protocol]
	Standard for Information technology - Telecommunications		Wadhwa, S., "Protocol for Access Node Control Mechanism in
	and information exchange between systems - Local and		Broadband Networks", draft-ietf-ancp-protocol-01 (work in
	metropolitan area networks - Specific requirements Part		progress), July 2007.
	11: Wireless LAN Medium Access Control (MAC) and Physical
	Layer (PHY) specifications Amendment 6: Medium Access
	Control (MAC) Security Enhancements", IEEE Standard
	802.11i, 2004.
	[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless		[3GPP2] 3rd Generation Partnership Project 2, "cdma2000 Wireless
	IP Network Standard", 3GPP2 P.S0001-B/v2.0,		IP Network Standard", 3GPP2 P.S0001-B/v2.0,
	September 2004.		September 2004.
	Authors' Addresses		Authors' Addresses
	Prakash Jayaraman		Prakash Jayaraman
	Network Equipment Technologies, Inc.		Network Equipment Technologies, Inc.
	6900 Paseo Padre Parkway		6900 Paseo Padre Parkway
End of changes. 15 change blocks.
	45 lines changed or deleted		36 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/