< draft-ietf-mip6-aaa-ha-goals-02.txt		draft-ietf-mip6-aaa-ha-goals-03.txt >
	Mobile IPv6 WG G. Giaretta		Mobile IPv6 WG G. Giaretta
	Internet-Draft I. Guardini		Internet-Draft I. Guardini
	Expires: December 28, 2006 E. Demaria		Intended status: Standards Track E. Demaria
	Telecom Italia		Expires: March 16, 2007 Telecom Italia
	J. Bournelle		J. Bournelle
	GET/INT		GET/INT
	R. Lopez		R. Lopez
	Univ. of Murcia		Univ. of Murcia
	June 26, 2006		September 12, 2006
	Goals for AAA-HA interface		AAA Goals for Mobile IPv6
	draft-ietf-mip6-aaa-ha-goals-02		draft-ietf-mip6-aaa-ha-goals-03
	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 39 ¶		skipping to change at page 1, line 39 ¶
	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 28, 2006.		This Internet-Draft will expire on March 16, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	In commercial deployments Mobile IPv6 can be a service offered by a		In commercial deployments Mobile IPv6 can be a service offered by a
	Mobility Services Provider (MSP). In this case all protocol		Mobility Services Provider (MSP). In this case all protocol
	operations may need to be explicitly authorized and traced, requiring		operations may need to be explicitly authorized and traced, requiring
	the interaction between Mobile IPv6 and the AAA infrastructure.		the interaction between Mobile IPv6 and the AAA infrastructure.
	Integrating the AAA infrastructure offers also a solution component		Integrating the AAA infrastructure offers also a solution component
	for Mobile IPv6 bootstrapping in integrated and split scenarios.		for Mobile IPv6 bootstrapping in integrated and split scenarios.
	This document describes various scenarios where a AAA interface for		This document describes various scenarios where a AAA interface for
	Mobile IPv6 is actually required. Additionally, it lists design		Mobile IPv6 is actually required. Additionally, it lists design
	goals and requirements for such an interface.		goals and requirements for such an interface.
	Table of Contents		Table of Contents
	1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Bootstrapping scenarios . . . . . . . . . . . . . . . . . . . 4		4. Bootstrapping Scenarios . . . . . . . . . . . . . . . . . . . 4
	4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Split Scenario . . . . . . . . . . . . . . . . . . . . . . 4
	4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5		4.2. Integrated Scenario . . . . . . . . . . . . . . . . . . . 5
	5. Goals for the split scenario . . . . . . . . . . . . . . . . . 6		5. Goals for the Split Scenario . . . . . . . . . . . . . . . . . 6
	5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6		5.1. General goals . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Service Authorization . . . . . . . . . . . . . . . . . . 7		5.2. Service Authorization . . . . . . . . . . . . . . . . . . 7
	5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7		5.3. Accounting . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8		5.4. Mobile Node Authentication . . . . . . . . . . . . . . . . 8
	5.5. Provisioning of configuration parameters . . . . . . . . . 8		5.5. Provisioning of Configuration Parameters . . . . . . . . . 8
	6. Goals for the Integrated scenario . . . . . . . . . . . . . . 8		6. Goals for the Integrated Scenario . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 8		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 9		10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . . 9		10.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	Intellectual Property and Copyright Statements . . . . . . . . . . 12		Intellectual Property and Copyright Statements . . . . . . . . . . 12
	1. Terminology		1. Introduction
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [1].
	2. Introduction
	Mobile IPv6 [2] was originally designed as a protocol without any		Mobile IPv6 [1] was originally designed as a protocol without any
	integration with the AAA infrastructure of the Mobility Service		integration with the AAA infrastructure. Nonetheless, in some
	Provider (MSP) that offers mobility service. Nonetheless, in some
	environments it might be desirable to authenticate the user based on		environments it might be desirable to authenticate the user based on
	existing credentials stored in the AAA infrastructure, to authorize		existing credentials stored at the AAA server to authorize protocol
	protocol operations and to enable accounting. Due to this		operations, to enable accounting and credit control. Due to this
	requirement, Mobile IPv6 might require the interaction with the AAA		requirement, Mobile IPv6 might require the interaction with the AAA
	infrastructure. Integrating the AAA infrastructure offers also a		infrastructure. Integrating the AAA infrastructure offers also a
	solution component for Mobile IPv6 bootstrapping [3] in split [4] and		solution component for Mobile IPv6 bootstrapping [2] in split [3] and
	integrated [5] scenarios.		integrated [4] scenarios.
	This document describes various scenarios where a AAA interface is		This document describes various scenarios where a AAA interface is
	required. Additionally, it lists design goals and requirements for		required. Additionally, it lists design goals and requirements for
	such an interface.		such an interface.
	This document only describes requirements, goals and scenarios. It		This document only describes requirements, goals and scenarios. It
	does not provide solutions.		does not provide solutions.
	Notice that this document builds on the security model of the AAA		Notice that this document builds on the security model of the AAA
	infrastructure. As such, the end host shares credentials with the		infrastructure. As such, the end host/user shares credentials with
	home AAA server and the communication between the AAA server and the		the home AAA server and the communication between the AAA server and
	AAA client may be protected. If the AAA server and the AAA client		the AAA client may be protected. If the AAA server and the AAA
	are not part of the same administrative domain, then some sort of		client are not part of the same administrative domain, then some sort
	contractual relationship between the involved administrative domains		of contractual relationship between the involved administrative
	is typically in place in form of roaming agreements.		domains is typically in place in form of roaming agreements.
			2. Terminology
			The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in RFC 2119 [5].
			Some of the terms are also extracted from [2].
	3. Motivation		3. Motivation
	Mobile IPv6 specification [2] requires that Mobile Nodes (MNs) are		Mobile IPv6 specification [1] requires that Mobile Nodes (MNs) are
	provisioned with a set of configuration parameters, namely the Home		provisioned with a set of configuration parameters, namely the Home
	Address and the Home Agent Address, in order to accomplish a home		Address and the Home Agent Address, in order to accomplish a home
	registration. Moreover MNs and Home Agents (HAs) must share the		registration. Moreover, MNs and Home Agents (HAs) must share the
	cryptographic material needed to protect Mobile IPv6 signaling (e.g.		cryptographic material needed in order to setup IPsec security
	shared keys or certificates to setup IPsec security associations).		associations to protect Mobile IPv6 signaling (e.g. shared keys or
			certificates).
	One approach is to statically provision the necessary configuration		One approach is to statically provision the necessary configuration
	parameters at MNs and HAs. This solution is sub-optimal from a		parameters at MNs and HAs. This solution is sub-optimal from a
	deployment perspective, especially in large networks with a lot of		deployment perspective, especially in large networks with a lot of
	users (e.g., a mobile operator network). For this reason the Mobile		users (e.g., a mobile operator network). For this reason the Mobile
	IPv6 bootstrapping problem was investigated [3]. Based on the		IPv6 bootstrapping problem was investigated and is described in [2].
	analysed scenarios (i.e. integrated and split), two solutions were		Based on the analysed scenarios, two solutions were developed. The
	developed. The solution for the split scenario is described in [4]		solution for the split scenario is described in [3] and the one for
	and the one for the integrated scenario can be found at [5]. A key		the integrated scenario can be found at [4]. A key point behind
	point behind these mechanisms is that, whenever static provisioning		these scenarios is that, whenever static provisioning is not
	is not feasible, the AAA infrastructure of the MSP can be used as the		feasible, the AAA infrastructure of the MSP can be used as the
	central element to enable dynamic Mobile IPv6 bootstrapping. In this		central element to enable dynamic Mobile IPv6 bootstrapping. In this
	case the AAA infrastructure can be exploited to offload the end		case the AAA infrastructure can be exploited to offload the end
	host's authentication to the AAA server as well as to deliver the		host's authentication to the AAA server as well as to deliver the
	necessary configuration parameters to the HA.		necessary configuration parameters to the HA.
	Moreover, in case Mobile IPv6 is a service offered by a Mobility		Moreover, in case Mobile IPv6 is a service offered by a Mobility
	Service Provider (MSP), all protocol operations (e.g. home		Service Provider (MSP), all protocol operations (e.g., home
	registrations) may need to be explicitly authorized and monitored		registrations) may need to be explicitly authorized and monitored
	(e.g. for accounting purposes). This can be accomplished relying on		(e.g., for accounting purposes). This can be accomplished relying on
	the AAA infrastructure of the MSP, that stores users' service		the AAA infrastructure of the MSP that stores user profiles and
	profiles and credentials.		credentials.
	The deployment of this service model requires the availability of an
	interface between the AAA infrastructure and the HA, that can be seen
	as the Network Access Server (NAS) for Mobile IPv6. The core
	capabilities that should be supported by this interface include
	Mobile IPv6 service authorization and maintenance (e.g. asynchronous
	service termination) as well as the exchange of accounting data.
	This basic set of features is needed in any Mobile IPv6 bootstrapping
	scenario.
	There is therefore space for the definition of a general AAA-HA		In the split scenario, the deployment of this service model requires
	communication interface capable to support the basic features		the availability of an interface between the Home Agent and the AAA
	described above (e.g. authorization and accounting) as well as the		infrastructure. The core capabilities that should be supported by
	extended capabilities (e.g. transfer of configuration data) needed to		this interface include Mobile IPv6 service authorization and
	enable various dynamic Mobile IPv6 bootstrapping scenarios.		maintenance (e.g. asynchronous service termination) as well as the
			exchange of accounting data. This basic set of features is needed in
			any Mobile IPv6 bootstrapping scenario. In the integrated scenario,
			the AAA server also delivers some Mobile IPv6 parameters to the NAS.
	4. Bootstrapping scenarios		4. Bootstrapping Scenarios
	This section describes some bootstrapping scenarios in which a		This section describes some bootstrapping scenarios in which a
	communication between the AAA infrastructure of the Mobility Service		communication between the AAA infrastructure of the Mobility Service
	Provider and the Home Agent is needed.		Provider and the Home Agent is needed.
	4.1. Split Scenario		4.1. Split Scenario
	In the split scenario [4], there is the assumption that the mobility		In the split scenario [3], there is the assumption that the mobility
	service and network access service are separate. This implies that		service and network access service are not provided by the same
	the mobility service can be authorized by a different entity		administrative entity. This implies that the mobility service can be
	deploying its own AAA infrastructure. The entity offering the		authorized by a different entity deploying its own AAA
	mobility service is called Mobility Service Provider (MSP) while the		infrastructure. The entity offering the mobility service is called
	entity authorizing the service is the Mobility Service Authorizer		Mobility Service Provider (MSP) while the entity authorizing the
	(MSA).		service is the Mobility Service Authorizer (MSA).
	In this scenario, the Mobile Node discovers the Home Agent Address		In this scenario, the Mobile Node discovers the Home Agent Address
	using the Domain Name Service (DNS). It queries the address based on		using the Domain Name Service (DNS). It queries the address based on
	the Home Agent name or by service name. In the former case, the		the Home Agent name or by service name. In the former case, the
	Mobile Node is configured with the Fully Qualified Domain Name (FDQN)		Mobile Node is configured with the Fully Qualified Domain Name (FDQN)
	of the Home Agent. In the latter case, the document [4] defines a		of the Home Agent. In the latter case, [3] defines a new service
	new service resource record (SRV RR).		resource record (SRV RR).
	Then the Mobile Node performs an IKEv2 [6] exchange with the HA to		Then the Mobile Node performs an IKEv2 [6] exchange with the HA to
	setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure		setup IPsec SAs (to protect Mobile IPv6 signaling) and to configure
	its Home Address (HoA). The IKEv2 Mobile Node to Home Agent		its Home Address (HoA). The IKEv2 Mobile Node to Home Agent
	authentication can be done using either public key signatures or the		authentication can be done using either public key signatures or the
	Extensible Authentication Protocol (EAP).		Extensible Authentication Protocol (EAP).
	If EAP is used for authentication, the operator can choose any		If EAP is used for authentication, the operator can choose any
	available EAP authentication methods. Note that even if EAP is used,		available EAP methods. Note that even if EAP is used, the MN
	the MN authenticates the HA using public key signature based		authenticates the HA using public key based authentication. Based on
	authentication. The HA may rely on a remote EAP server. In this		IKEv2, the HA may rely on a remote EAP server. In this case, a AAA
	case, a AAA protocol such as RADIUS EAP [7] or Diameter EAP [8] must		protocol such as RADIUS EAP [7]/Diameter EAP [8] must be used between
	be used between the HA and the home EAP server. This allows a pool		the HA and the home EAP server. This allows a pool of HAs to rely on
	of HAs to rely on the same EAP server to authenticate Mobile Nodes.		the same EAP server to authenticate Mobile Nodes. It also allows the
	It also allows the roaming mobility case in which the Mobile Node		roaming mobility case in which the Mobile Node obtains the mobility
	obtains the mobility service in a different administrative domain		service in a different administrative domain (MSP != MSA).
	(MSP != MSA).
	The Mobile Node may also want to update its FQDN in the DNS with the		The Mobile Node may also want to update its FQDN in the DNS with the
	newly allocated Home Address. The document [4] recommends that the		newly allocated Home Address. [3] recommends that the HA performs the
	HA performs the DNS entry update on behalf of the Mobile Node. For		DNS entry update on behalf of the Mobile Node. For that purpose, the
	that purpose, the Mobile Node indicates its FDQN in the IKEv2		Mobile Node indicates its FDQN in the IKEv2 exchange (IDii field in
	exchange (IDii field in IKE_AUTH) and adds a DNS Update Option in the		IKE_AUTH) and adds a DNS Update Option in the Binding Update message
	Binding Update message sent to the HA.		sent to the HA.
	When the Mobile Node uses a Home Agent belonging to a different		When the Mobile Node uses a Home Agent belonging to a different
	administrative domain (MSP != MSA), the local HA may not share a		administrative domain (MSP != MSA), the local HA may not share a
	security association with the home DNS server. In this case, the		security association with the home DNS server. In this case, [3]
	document [4] suggests the home AAA server to be responsible of the		suggests that the home AAA server is responsible for the update.
	update. Thus the HA should send to the home AAA server the FDQN-HoA		Thus, the HA should send to the home AAA server the (FDQN, HoA) pair.
	pair through the AAA protocol. Note that the AAA exchange between		Note that the AAA exchange between the HA and the AAA server is
	the HA and the AAA infrastructure is normally terminated before the		normally terminated before the HA receives the Binding Update
	HA receives the Binding Update message. The reason is that the		message. The reason is that the authentication has succeeded if the
	authentication has succeeded if the Mobile Node is able to send the		Mobile Node is able to send the BU.
	BU.
	4.2. Integrated Scenario		4.2. Integrated Scenario
	In the integrated scenario [5], the assumption is which the mobile		In the integrated scenario [4], the assumption is that the user is
	user's mobility service is authorized by the same authorizer than		authenticated and authorized by the same authorizer than network
	network access service. Basically Mobility Service Authorizer (MSA)		access service. The Mobility Service Authorizer (MSA) and the Access
	and the Access Service Authorizer (ASA) are the same entity. The		Service Authorizer (ASA) are the same entity.
	scenario considers two cases:
	1. Mobile Node requests a home agent to its home domain (ASA/MSA).
	2. Mobile Node requests a home agent to the Access Service Provider
	(ASP)
	In the first case, Home Agent is allocated by user's home domain. In		Two scenarios are possible. In the first case, the Home Agent is
	the second case it is allocated by user's visited domain. In both		allocated by the user's home domain. In the second case it is
	cases, it is assumed that the AAA server in the home domain (AAAH)		allocated by an entity in the visited domain. In both cases, it is
	authorizes both network access service and mobility service.		assumed that the AAA server in the home domain (AAAH) authorizes both
			network access service and mobility service.
	In this scenario, Mobile Node discovers the Home Agent Address using		In this scenario, Mobile Node discovers the Home Agent Address using
	DHCPv6. During network access service authentication and		DHCPv6. During network access service authentication and
	authorization, AAAH also verifies if authenticating user is		authorization, AAAH also verifies if authenticating user is
	authorized to use mobility service. In affirmative case, AAAH sends		authorized to use mobility service. In affirmative case, the AAAH
	to the Network Access Server (NAS) where the Mobile Node is attached,		sends the information about the assigned home agent to the Network
	the information about the assigned home agent. Then NAS stores that		Access Server (NAS) where the Mobile Node is currently attached.
	information. To request home agent data, Mobile Node sends a DHCPv6		Then, the NAS stores the received information. To request home agent
	Information Request to the All_DHCP_Relay_Agents_and_Servers		data, the Mobile Node sends a DHCPv6 Information Request to the
	multicast address. With this request, Mobile Node can specify if it		All_DHCP_Relay_Agents_and_Servers multicast address. With this
	wants a home agent provided by the visited domain (ASP) or by the		request, the Mobile Node can specify if it wants a home agent
	home domain (ASA). In both cases, the NAS acts a DHCPv6 relay. When		provided by the visited domain (ASP/MSP) or by the home domain (ASA/
	the NAS receives DHCPv6 Information Request then it attaches home		MSA). In both cases, the NAS acts a DHCPv6 relay. When the NAS
	agent information received from AAAH in a new DHC Relay Agent Option		receives the DHCPv6 Information Request then it sends home agent
			information received from AAAH in a new DHC Relay Agent Option as
	defined in [9].		defined in [9].
	In case Mobile Node cannot acquire home agent information via DHCPv6,		In case the Mobile Node cannot acquire home agent information via
	it can try the default mechanism based on DNS described in [4].		DHCPv6, it can try the default mechanism based on DNS described in
	After the Mobile Node has acquired home agent information, the		[3]. After the Mobile Node has acquired the home agent information,
	mechanism used to bootstrap the HoA, IPsec Security Association, and		the mechanism used to bootstrap the HoA, IPsec Security Association,
	Authentication and Authorization with the MSA is the same described		and Authentication and Authorization with the MSA is the same
	in the bootstrapping solution for split scenario [4].		described in the bootstrapping solution for split scenario [3].
	5. Goals for the split scenario		5. Goals for the Split Scenario
	The motivations and scenarios illustrated for the split scenario		Section 4 raises the need to define extensions for the AAA protocol
	raise the need to define an interface between the AAAH server and the		used between the AAAH server and the HA. The following sections list
	HA. The following sections list a set of goals for this interface.		a set of goals.
	5.1. General goals		5.1. General goals
	G1.1 The AAAH server and the HA MUST be able to authenticate each
			G1.1 The AAAH server and the HA MUST be able to authenticate each
	other (mutual authentication) in order to prevent the installation		other (mutual authentication) in order to prevent the installation
	of unauthorized state on the HA.		of unauthorized state on the HA. In some deployment scenarios, it
			may not be feasible for HA and AAAH to mutually authenticate each
			other. For example, let us consider the case where MSP is not the
			MSA. In such a case, several AAA intermediate proxies could
			forward MIP6 bootstrapping information back and forth between HA
			and AAA. Thus, to prevent the installation of unauthorized state
			on the HA, the path between HA and AAAH should be trustworthy>/
	G1.2 The AAA-HA interface MUST provide integrity protection in order		G1.2 The AAA-HA interface MUST provide integrity protection in order
	to prevent any alteration of exchanged data (e.g. Mobile IPv6		to prevent any alteration of exchanged data (e.g., Mobile IPv6
	configuration parameters).		configuration parameters).
	G1.3 The AAA-HA interface MUST provide replay protection.		G1.3 The AAA-HA interface MUST provide replay protection.
	G1.4 The AAA-HA interface SHOULD provide confidentiality since it may		G1.4 The AAA-HA interface SHOULD provide confidentiality since it
	be used to transfer keying material (e.g. shared key generated		may be used to transfer keying material (e.g., shared key
	during EAP authentication).		generated during EAP method authentication).
	G1.5 The AAA-HA interface SHOULD support inactive peer detection.		G1.5 The AAA-HA interface SHOULD support inactive peer detection.
	This functionality can be used by the AAAH server to maintain a		This functionality can be used by the AAAH server to maintain a
	list of active HAs (e.g. useful for HA selection).		list of active HAs.
	5.2. Service Authorization		5.2. Service Authorization
	G2.1 The AAA-HA interface SHOULD allow the use of Network Access		G2.1 The AAA-HA interface SHOULD allow the use of Network Access
	Identifier (NAI) to identify the mobile node.		Identifier (NAI) to identify the user.
	G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile		G2.2 The HA SHOULD be able to query the AAAH server to verify Mobile
	IPv6 service authorization for the mobile node.		IPv6 service authorization for the mobile node.
	G2.3 The AAAH server MAY assign explicit operational limitations and		G2.3 The AAAH server MAY assign explicit operational limitations and
	authorization restrictions on the HA (e.g. packet filters, QoS		authorization restrictions on the HA (e.g., packet filters, QoS
	parameters).		parameters).
	G2.4 The AAAH server MUST be able to send an authorization lifetime		G2.4 The AAAH server MUST be able to send an authorization lifetime
	to the HA to limit Mobile IPv6 session duration for the MN.		to the HA to limit Mobile IPv6 session duration for the MN.
	G2.5 The HA MUST be able to request to the AAAH server an extension		G2.5 The HA MUST be able to request to the AAAH server an extension
	of the authorization lifetime granted to the MN.		of the authorization lifetime granted to the MN.
	G2.6 The AAAH server MUST be able to force the HA to terminate an		G2.6 The AAAH server MUST be able to force the HA to terminate an
	active Mobile IPv6 session for authorization policy reasons (e.g.		active Mobile IPv6 session for authorization policy reasons (e.g.,
	credit exhaustion).		credit exhaustion).
	5.3. Accounting		5.3. Accounting
	G3.1 The AAA-HA interface MUST support the transfer of accounting
			G3.1 The AAA-HA interface MUST support the transfer of accounting
	records needed for service control and charging. These include		records needed for service control and charging. These include
	(but may not be limited to): time of binding cache entry creation		(but may not be limited to): time of binding cache entry creation
	and deletion, octets sent and received by the mobile node in Bi-		and deletion, octets sent and received by the mobile node in bi-
	directional Tunneling, etc.		directional tunneling, etc.
	5.4. Mobile Node Authentication		5.4. Mobile Node Authentication
	G4.1 The AAA-HA interface MUST support pass-through EAP		G4.1 The AAA-HA interface MUST support pass-through EAP
	authentication with the HA working as EAP authenticator operating		authentication with the HA working as EAP authenticator operating
	in pass-through mode and the AAAH server working as back-end		in pass-through mode and the AAAH server working as back-end
	authentication server.		authentication server.
	5.5. Provisioning of configuration parameters		5.5. Provisioning of Configuration Parameters
	G5.1 The HA SHOULD be able to communicate to the AAAH server the Home		G5.1 The HA SHOULD be able to communicate to the AAAH server the
	Address allocated to the MN (e.g. for allowing the AAAH server to		Home Address allocated to the MN (e.g., for allowing the AAAH
	perform DNS update on behalf of the MN).		server to perform a DNS update on behalf of the MN).
	G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is		G5.2 The AAAH SHOULD be able to indicate to the HA if the MN is
	authorized to autoconfigure its Home Address.		authorized to autoconfigure its Home Address.
	6. Goals for the Integrated scenario		6. Goals for the Integrated Scenario
	In the integrated scenario, the AAA server provides the HA		In the integrated scenario, the AAA server provides the HA
	information to the NAS as part of the whole AAA operations for		information to the NAS as part of the whole AAA operations for
	network access. Next goals are considered in addition to those		network access. Next goals are considered in addition to those
	described in section Section 5.		described in section Section 5.
	G6.1 The AAAH server MUST be able to communicate the Home-Agent		G6.1 The AAAH server MUST be able to communicate the Home Agent
	Information (Address or FQDN) to the NAS.		Information (IP Address or FQDN) to the NAS.
	G6.2 The NAS SHOULD be able to notify to the AAA infrastructure that		G6.2 The NAS SHOULD be able to notify that it supports the
	it supports the functionalities described in [5].		functionalities described in [4].
			G6.3 The ASP/MSP SHOULD be able to indicate to the MSA if it can
			allocate a Home Agent to the MN.
			G6.4 The AAA server of the MSA MUST be able to indicate to the NAS
			whether the MN is authorized to use a local Home Agent (i.e. a
			Home Agent in the ASP/MSP)
	7. IANA Considerations		7. IANA Considerations
	No new message formats or services are defined in this document.		This document does not require actions by IANA.
	8. Security Considerations		8. Security Considerations
	As stated in section Section 5.1 the AAA-HA interface must provide
	mutual authentication, integrity and replay protection. Furthermore,		As stated in Section 5.1 the AAA-HA interface must provide mutual
	if security parameters (e.g. IKE pre-shared key) are transferred		authentication, integrity and replay protection. Furthermore, if
	through this interface, confidentiality is a feature that is strongly		security parameters (e.g., IKE pre-shared key) are transferred
	recommended to be supported. However note that some suitable		through this interface, confidentiality is strongly recommended to be
	interfaces may not provide end-to-end confidentiality between AAA and		supported. However note that AAA protocols does not support this
	HA (e.g. AAA protocols).		unless it exists a direct connection between corresponding entities.
	9. Acknowledgements		9. Acknowledgements
	The authors would like to thank James Kempf, Alper Yegin, Vijay		The authors would like to thank James Kempf, Alper Yegin, Vijay
	Devarapalli, Basavaraj Patil, Gopal Dommety for their comments and		Devarapalli, Basavaraj Patil, Gopal Dommety and Madjid Nakhjiri for
	feedback. Moreover the authors would like to thank Hannes Tschofenig		their comments and feedback. Moreover the authors would like to
	for his deep technical and editorial review of the draft. Finally		thank Hannes Tschofenig for his deep technical and editorial review
	the authors would like to thank also the European Commission support		of the draft.
	in the co-funding of the ENABLE project, where this work is partly
	being developed.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	Levels", BCP 14, RFC 2119, March 1997.
	[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
	IPv6", RFC 3775, June 2004.		IPv6", RFC 3775, June 2004.
	10.2. Informative References		[2] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping
			Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in
			progress), May 2006.
	[3] Giaretta, G. and A. Patel, "Problem Statement for bootstrapping		[3] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
	Mobile IPv6", draft-ietf-mip6-bootstrap-ps-05 (work in		draft-ietf-mip6-bootstrapping-split-02 (work in progress),
	progress), May 2006.		March 2006.
	[4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",		[4] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
	draft-ietf-mip6-bootstrapping-split-02 (work in progress),		the Integrated Scenario",
	March 2006.		draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
			progress), June 2006.
	[5] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for		[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	the Integrated Scenario",		Levels", BCP 14, RFC 2119, March 1997.
	draft-ietf-mip6-bootstrapping-integrated-dhc-01 (work in
	progress), June 2006.		10.2. Informative References
	[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	RFC 4306, December 2005.		RFC 4306, December 2005.
	[7] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial		[7] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
	In User Service) Support For Extensible Authentication Protocol		In User Service) Support For Extensible Authentication Protocol
	(EAP)", RFC 3579, September 2003.		(EAP)", RFC 3579, September 2003.
	[8] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible		[8] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,		Authentication Protocol (EAP) Application", RFC 4072,
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 4 ¶
	Email: ivano.guardini@telecomitalia.it		Email: ivano.guardini@telecomitalia.it
	Elena Demaria		Elena Demaria
	Telecom Italia Lab		Telecom Italia Lab
	via G. Reiss Romoli, 274		via G. Reiss Romoli, 274
	TORINO, 10148		TORINO, 10148
	Italy		Italy
	Email: elena.demaria@telecomitalia.it		Email: elena.demaria@telecomitalia.it
	Julien Bournelle		Julien Bournelle
	GET/INT		GET/INT
	9 rue Charles Fourier		9 rue Charles Fourier
	Evry 91011		Evry 91011
	France		France
	Email: julien.bournelle@int-evry.fr		Email: julien.bournelle@int-evry.fr
	Rafa Marin Lopez		Rafa Marin Lopez
	University of Murcia		University of Murcia
	30071 Murcia		30071 Murcia
	Spain		Spain
	Email: rafa@dif.um.es		Email: rafa@dif.um.es
	Intellectual Property Statement		Full Copyright Statement
			Copyright (C) The Internet Society (2006).
			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.
			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.
			Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be		on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.		found in BCP 78 and BCP 79.
	skipping to change at page 12, line 29 ¶		skipping to change at page 12, line 45 ¶
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	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 (2006). 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		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is provided by the IETF
	Internet Society.		Administrative Support Activity (IASA).
End of changes. 67 change blocks.
	208 lines changed or deleted		210 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/