< draft-tschofenig-dime-mip6-split-00.txt		draft-tschofenig-dime-mip6-split-01.txt >
	Diameter Maintanence and H. Tschofenig		Diameter Maintanence and H. Tschofenig
	Extensions (DIME) Siemens		Extensions (DIME) Siemens
	Internet-Draft T. Tsenov		Internet-Draft T. Tsenov
	Expires: August 31, 2006		Expires: September 7, 2006
	G. Giaretta		G. Giaretta
	TILab		TILab
	J. Bournelle		J. Bournelle
	GET/INT		GET/INT
	February 27, 2006		March 6, 2006
	Mobile IPv6 Bootstrapping using Diameter in the Split Scenario		Mobile IPv6 Bootstrapping using Diameter in the Split Scenario
	draft-tschofenig-dime-mip6-split-00.txt		draft-tschofenig-dime-mip6-split-01.txt
	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 August 31, 2006.		This Internet-Draft will expire on September 7, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	In Mobile IPv6 deployment a need for an interaction between the Home		In Mobile IPv6 deployment a need for an interaction between the Home
	Agent, the AAA infrastructure of the Mobile Service Provider (MSP)		Agent, the AAA infrastructure of the Mobile Service Provider (MSP)
	and the Mobility Service Authorizer (MSA) has been identified. This		and the Mobility Service Authorizer (MSA) has been identified. This
	document provides a description of the functionality that allows to		document provides a description of the functionality that allows to
	meet the goals outlined in the MIPv6 AAA Goals document.		meet the goals outlined in the MIPv6 AAA Goals document.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Bootstrapping Mobile IPv6 in the Split Scenario . . . . . . . 5
	3.1. General goals . . . . . . . . . . . . . . . . . . . . . . 5		4. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 5		4.1. General goals . . . . . . . . . . . . . . . . . . . . . . 8
	3.1.2. Dead peer detection - the HA-AAA interface SHOULD		4.1.1. G1.1 - G1.4 Security . . . . . . . . . . . . . . . . . 8
	support inactive peer detection. . . . . . . . . . . . 5		4.1.2. Dead peer detection - the HA-AAA interface SHOULD
	3.2. Service Authorization . . . . . . . . . . . . . . . . . . 5		support inactive peer detection. . . . . . . . . . . . 8
	3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of		4.2. Service Authorization . . . . . . . . . . . . . . . . . . 8
			4.2.1. G2.1. The HA-AAA interface SHOULD allow the use of
	Network Access Identifier (NAI) to identify the		Network Access Identifier (NAI) to identify the
	mobile node. . . . . . . . . . . . . . . . . . . . . . 5		mobile node. . . . . . . . . . . . . . . . . . . . . . 8
	3.2.2. G2.2. The HA SHOULD be able to query the AAAH		4.2.2. G2.2. The HA SHOULD be able to query the AAAH
	server to verify Mobile IPv6 service authorization		server to verify Mobile IPv6 service authorization
	for the mobile node. . . . . . . . . . . . . . . . . . 6		for the mobile node. . . . . . . . . . . . . . . . . . 9
	3.2.3. G2.3. The AAAH server SHOULD be able to enforce		4.2.3. G2.3. The AAAH server SHOULD be able to enforce
	explicit operational limitations and authorization		explicit operational limitations and authorization
	restrictions on the HA.( e.g. packet filters, QoS		restrictions on the HA.( e.g. packet filters, QoS
	parameters). . . . . . . . . . . . . . . . . . . . . . 6		parameters). . . . . . . . . . . . . . . . . . . . . . 9
	3.2.4. G2.4 - G2.6. Issues addressing the maintenance of		4.2.4. G2.4 - G2.6. Issues addressing the maintenance of
	a Mobile IPv6 session by the AAAH server, e.g.		a Mobile IPv6 session by the AAAH server, e.g.
	authorization lifetime, extension of the		authorization lifetime, extension of the
	authorization lifetime and explicit session		authorization lifetime and explicit session
	termination by the AAAH server side. . . . . . . . . . 6		termination by the AAAH server side. . . . . . . . . . 9
	3.2.5. G2.7. The AAAH server SHOULD be able to retrieve		4.3. Accounting - G3.1. The HA-AAA interface MUST support
	the Mobile IPv6 state associated to a specific MN
	from the correspondent HA. This MAY be useful to
	periodically verify the Mobile IPv6 service status. . 7
	3.3. Accounting - G3.1. The HA-AAA interface MUST support
	the transfer of accounting records needed for service		the transfer of accounting records needed for service
	control and charging . . . . . . . . . . . . . . . . . . . 7		control and charging . . . . . . . . . . . . . . . . . . . 10
	3.4. Mobile Node Authentication (G4.1. and G4.2.) . . . . . . . 7		4.4. Mobile Node Authentication (G4.1.) . . . . . . . . . . . . 10
	3.5. Provisioning of configuration parameters . . . . . . . . . 8		4.5. Provisioning of Configuration Parameters . . . . . . . . . 10
	4. Bootstrapping Mobile IPv6 in the split scenario . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	5. Security considerations . . . . . . . . . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 15		8.2. Informative References . . . . . . . . . . . . . . . . . . 14
	8.2. Informative References . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16		Intellectual Property and Copyright Statements . . . . . . . . . . 16
	Intellectual Property and Copyright Statements . . . . . . . . . . 17
	1. Introduction		1. Introduction
	In Mobile IPv6 deployment, authentication, authorization and		In Mobile IPv6 deployment, authentication, authorization and
	accounting issues in the protocol operations are approached by using		accounting issues in the protocol operations are approached by using
	the AAA infrastructure. The [8] document presents a number of		the AAA infrastructure. The [8] document presents a number of
	bootstrapping scenarios using the HA-AAA interface and defines a list		bootstrapping scenarios using the HA-AAA interface and defines a list
	of requirements that this interface should cover. This document		of requirements that this interface should cover. This document
	deals with the functional capabilities of the Diameter protocol as a		deals with the functional capabilities of the Diameter protocol as a
	AAA protocol applicable for the split scenario.		AAA protocol applicable for the split scenario.
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	the level of AVP's support provides interoperability. Usage of IPsec		the level of AVP's support provides interoperability. Usage of IPsec
	and TLS for transport hop-by-hop security, possible support for AVP		and TLS for transport hop-by-hop security, possible support for AVP
	integrity and confidentiality and usage of peer-to-peer model (any		integrity and confidentiality and usage of peer-to-peer model (any
	Diameter node can initiate a request message) provide flexibility of		Diameter node can initiate a request message) provide flexibility of
	the Diameter AAA applications to fit to specific requirements.		the Diameter AAA applications to fit to specific requirements.
	In the following sections we try to specify by which means a possible		In the following sections we try to specify by which means a possible
	Diameter application would cover the requirements for the HA-AAA		Diameter application would cover the requirements for the HA-AAA
	interface specified in [8].		interface specified in [8].
	3. Goals		3. Bootstrapping Mobile IPv6 in the Split Scenario
			In the split scenario for bootstrapping Mobile IPv6 [2], the MN
			discovers HA through DNS mechanism. Then it uses IKEv2 [3] to setup
			IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus
			the MN. As such, the MN can use its credentials (obtained from the
			MSA) to be authenticated for the IPv6 mobility service. The HA MAY
			rely on a EAP server co-located on a AAA server for this purpose. In
			this case, a HA-AAA interface is needed. This interface MUST support
			transport of EAP packets.
			+----+ IKEv2 +----+ Diameter EAP +---+
			| MN |<----------->| HA |<-------------------->|AAA|
			+----+ +----+ +---+
			Figure 1: Diameter EAP as the HA-AAA interface in Split
			scenario
			For this purpose, the HA can use Diameter EAP Application [4] (cf.
			Figure 1). As shown in the previous section, this protocol fulfill
			goals described in [8]
			MN HA AAAH
			-- -- ----
			IKE_SA_INIT
			<------------------------------>
			HDR, SK{IDi,[CERTREQ,] [IDr,]
			SAi2, TSi, TSr}
			------------------------------->
			DER (EAP-Response)
			------------------------>
			DEA (EAP-Request)
			<------------------------
			HDR, SK {IDr, [CERT,] AUTH,
			EAP }
			<-------------------------------
			HDR, SK {EAP}
			-------------------------------->
			DER (EAP-Response)
			------------------------>
			DEA (EAP-Request)
			<------------------------
			HDR, SK{EAP-Request}
			<-------------------------------
			HDR, SK{EAP-Response}
			-------------------------------->
			DER (EAP-Response)
			------------------------>
			... ...
			DEA (EAP-Success)
			<------------------------
			HDR, SK{EAP-Success}
			<-------------------------------
			HDR, SK{AUTH}
			------------------------------->
			HDR, SK {AUTH, SAr2, TSi, TSr }
			<-------------------------------
			Figure 2: IKEv2 Diameter EAP
			MN and HA start with an IKE_SA_INIT to setup the IKE SA. The MN
			indicates its desire to use EAP by not including the AUTH payload in
			the third message. However it indicates its identity (e.g. NAI) by
			using the IDi field. If the HA supports EAP for authentication, it
			forwards the identity to the AAAH by sending a Diameter-EAP-Request
			(DER) message containing the identity in the EAP-Payload AVP and in
			the User-Name AVP. Based on this identity, the AAAH chooses an
			authentication method and sends the first EAP-Request in the
			Diameter-EAP-Answer message. During the EAP authentication phase,
			the HA relays EAP packets between the MN and the AAAH. If the
			authentication succeeds and if the MN is authorized to use Mobile
			IPv6 service, the AAAH sends a DEA message containing the EAP-success
			and the AAA-Key derived from the EAP authentication method . Note
			that EAP authentication methods that do not derive keys are not
			recommended. This key is used by both MN and HA to generate the AUTH
			payload. In the latter message, MN and HA finish to setup IPsec SAs
			for Mobile IPv6.
			4. Goals
	In presentation of the analysis of goals and possible design		In presentation of the analysis of goals and possible design
	solutions by Diameter we follow the classification, labels and naming		solutions by Diameter we follow the classification, labels and naming
	assigned in the document [8], where these goals are identified.		assigned in the document [8], where these goals are identified.
	Since several of the issues MIGHT be addressed in similar way or by		Since several of the issues might be addressed in similar way or by
	similar Diameter functionality, we have grouped these issues and have		similar Diameter functionality, we have grouped these issues and have
	given a general description of the groups.		given a general description of the groups.
	3.1. General goals		4.1. General goals
	3.1.1. G1.1 - G1.4 Security		4.1.1. G1.1 - G1.4 Security
	As design goals for an AAA interface, G1.1 - G1.4 goals specify		As design goals for an AAA interface, G1.1 - G1.4 goals specify
	standard requirements for a AAA protocol - mutual authentication of		standard requirements for a AAA protocol - mutual authentication of
	the peers, integrity, replay protection and confidentiality. IPsec		the peers, integrity, replay protection and confidentiality. IPsec
	or TLS provide the hop-by-hop security. Combined, they SHOULD be		or TLS provide the hop-by-hop security. Combined, they SHOULD be
	able to provide the range of security services required for the HA-		able to provide the range of security services required for the HA-
	AAA interface.		AAA interface.
	3.1.2. Dead peer detection - the HA-AAA interface SHOULD support		4.1.2. Dead peer detection - the HA-AAA interface SHOULD support
	inactive peer detection.		inactive peer detection.
	Two possible approaches MIGHT be considered here:		Two possible approaches might be considered here:
	o AAAH server and Home Agent establish a transport connection		o AAAH server and Home Agent establish a transport connection
	between each other. In this case Diameter heartbeat messages		between each other. In this case Diameter heartbeat messages
	called Watch-Dog-Request/Answer, which are exchanged over this		called Device-Watchdog-Request/Answer [1], which are exchanged
	connection to test for its aliveness, MAY be used to detect		over this connection to test for its aliveness, MAY be used to
	inactivity in any of the two Diameter peers.		detect inactivity in any of the two Diameter peers.
	o AAAH server and Home Agent do not have transport connection. In		o AAAH server and Home Agent do not have transport connection. In
	this case inactive peer detection functionality SHOULD be provided		this case inactive peer detection functionality SHOULD be provided
	into the Diameter session - service stateless Diameter sessions		into the Diameter session - service stateless Diameter sessions
	MIGHT be established between the AAAH server and the range of		might be established between the AAAH server and the range of
	MSP's Home Agents for detecting HAs availability.		MSP's Home Agents for detecting HAs availability.
	3.2. Service Authorization		4.2. Service Authorization
	3.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network		4.2.1. G2.1. The HA-AAA interface SHOULD allow the use of Network
	Access Identifier (NAI) to identify the mobile node.		Access Identifier (NAI) to identify the mobile node.
	Identification by User-Name AVP [1], which has a format consistent		Identification by User-Name AVP [1], which has a format consistent
	with the NAI specifications, is common for Diameter applications.		with the NAI specifications, is common for Diameter applications.
	Diameter provides functionality for routing of Diameter requests		Diameter provides functionality for routing of Diameter requests
	based on the information included in the User-Name AVP.		based on the information included in the User-Name AVP.
	3.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify		4.2.2. G2.2. The HA SHOULD be able to query the AAAH server to verify
	Mobile IPv6 service authorization for the mobile node.		Mobile IPv6 service authorization for the mobile node.
	Based on the peer-to-peer model, Diameter design gives the		Based on the peer-to-peer model, Diameter design gives the
	functionality that any Diameter node can initiate a request message.		functionality that any Diameter node can initiate a request message.
	This, combined with the support of EAP, would provide flexible		This, combined with the support of EAP, would provide flexible
	solutions for this issue. Currently several Diameter application		solutions for this issue. Currently several Diameter application
	standardized or under work-in-progress address different types of		standardized or under work-in-progress address different types of
	authorization - network access [2], credit control [9], quality of		authorization - network access [5], credit control [9], quality of
	service [10]. This MIGHT allow re-use of present AVPs over the		service [10]. This might allow re-use of present AVPs over the
	AAAH-HA interface.		AAAH-HA interface.
	3.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit		4.2.3. G2.3. The AAAH server SHOULD be able to enforce explicit
	operational limitations and authorization restrictions on the		operational limitations and authorization restrictions on the
	HA.( e.g. packet filters, QoS parameters).		HA.( e.g. packet filters, QoS parameters).
	Several present Diameter applications, standardized or under work-in-		Several present Diameter applications, standardized or under work-in-
	progress address an operation and authorization control over specific		progress address an operation and authorization control over specific
	services and have defined appropriate AVPs. NAS-Filter-Rule AVP,		services and have defined appropriate AVPs. NAS-Filter-Rule AVP,
	defined by Diameter NASREQ application [2], provides IP packet filter		defined by Diameter NASREQ application [5], provides IP packet filter
	description. QoS-Filter-Rule AVP defined by Diameter NASREQ		description. QoS-Filter-Rule AVP defined by Diameter NASREQ
	application and QSPEC AVP defined by Diameter QoS Authorization [10]		application and QSPEC AVP defined by Diameter QoS Authorization [10]
	provide QoS parameter description. Credit Control application [9]		provide QoS parameter description. Credit Control application [9]
	provides cost control over requested services. AVPs MAY be re-used		provides cost control over requested services. AVPs MAY be re-used
	for providing required functionality over the AAAH-HA interface.		for providing required functionality over the AAAH-HA interface.
	This, combined with the possibility that any node can initiate		This, combined with the possibility that any node can initiate
	request message, gives control to the AAAH server over HA's		request message, gives control to the AAAH server over HA's
	functionality.		functionality.
	3.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6		4.2.4. G2.4 - G2.6. Issues addressing the maintenance of a Mobile IPv6
	session by the AAAH server, e.g. authorization lifetime,		session by the AAAH server, e.g. authorization lifetime,
	extension of the authorization lifetime and explicit session		extension of the authorization lifetime and explicit session
	termination by the AAAH server side.		termination by the AAAH server side.
	Diameter base protocol provides a powerful set of commands and AVPs		Diameter base protocol provides a powerful set of commands and AVPs
	for management of the authorization and accounting sessions. A		for management of the authorization and accounting sessions. A
	number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout-		number of AVPs (Auth-Lifetime-AVP, Grace-Period-AVP, Session-Timeout-
	AVP) handle the duration (in time) of an authorization session [1].		AVP) handle the duration (in time) of an authorization session [1].
	Additional AVPs for measuring the authorization duration in units		Additional AVPs for measuring the authorization duration in units
	different that time are specified too [9]. Exchanging of application		different that time are specified too [9]. Exchanging of application
	specific authorization request/answer messages provides extension of		specific authorization request/answer messages provides extension of
	the authorization session. Initiation of the re-authorization by		the authorization session. Initiation of the re-authorization by
	both sides could be supported. Both sides could initiate session		both sides could be supported. Both sides could initiate session
	termination, by using Diameter Session Termination and Abort Session		termination, by using Diameter Session Termination and Abort Session
	messages.		messages.
	All these are applied to the Diameter session used for authorization		All these are applied to the Diameter session used for authorization
	of a Mobile IPv6 session and need to be applied appropriately to this		of a Mobile IPv6 session and need to be applied appropriately to this
	Mobile IPv6 session too.		Mobile IPv6 session too.
	3.2.5. G2.7. The AAAH server SHOULD be able to retrieve the Mobile IPv6		4.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer
	state associated to a specific MN from the correspondent HA.
	This MAY be useful to periodically verify the Mobile IPv6
	service status.
	This issue has two sides:
	1. How the AAAH SHOULD know which HA to contact to retrieve current
	status of MN's Mobile IPv6 service in case of stateless MSP
	architecture and several servicing AAA servers? - As analyzed
	into the [11], this need would be required for re-authorization
	and in this case the provision of HA info could be provided from
	the MN during the re-authentication session between NM and AAAH
	server.
	2. Once having the HA info, AAAH SHOULD contact it to verify the
	status of MN's Mobile IPv6 service. - This could be performed by
	Request/Response messages initiated by the AAAH server. This
	functionality is supported by the Diameter protocol and currently
	is applied into Diameter SIP application for updating user
	profiles at Diameter client (i.e., SIP server).
	3.3. Accounting - G3.1. The HA-AAA interface MUST support the transfer
	of accounting records needed for service control and charging		of accounting records needed for service control and charging
	Diameter accounting protocol provides a variety of options - real-		Diameter accounting protocol provides a variety of options - real-
	time accounting, event/session-type accounting records, fault		time accounting, event/session-type accounting records, fault
	resilience, correlation of accounting records. Requirements for the		resilience, correlation of accounting records. Requirements for the
	accounting services over AAAH-HA interface are standard. Definition		accounting services over AAAH-HA interface are standard. Definition
	or re-used of AVPs for the specific accounting records combined with		or re-used of AVPs for the specific accounting records combined with
	the functionality of the Diameter accounting protocol SHOULD provide		the functionality of the Diameter accounting protocol SHOULD provide
	desired accounting services.		desired accounting services.
	3.4. Mobile Node Authentication (G4.1. and G4.2.)		4.4. Mobile Node Authentication (G4.1.)
	These issues require the functionality of AAAH server working as a		These issues require the functionality of AAAH server working as a
	back-end authentication server and HA working as NAS and EAP		back-end authentication server and HA working as NAS and EAP
	authenticator in pass-through mode for providing a mobile node		authenticator in pass-through mode for providing a mobile node
	authentication. These functionalities are provided by Diameter		authentication. These functionalities are provided by Diameter
	NASREQ and EAP applications, and MIGHT be re-used at the AAAH-AH		NASREQ and EAP applications, and might be re-used at the AAAH-AH
	interface.[2], [3]		interface.[5], [4]
	3.5. Provisioning of configuration parameters
	Issues G5.1 - G5.3 are related to capability of exchanging and
	negotiating of operational parameters for Mobile IPv6 protocol
	bootstrapping and providing appropriate security level for this
	information.
	Diameter provides secure transport by means of IPsec, TLS and
	possible AVPs integrity and confidentiality support (currently with
	no interest from the community). Several AVPs could be re-used for
	carrying the operational parameters for the Mobile IPv6
	bootstrapping. Framed-IPv6-Prefix AVP, Login-IPv6-Host AVP, Framed-
	Interface-Id AVP, Framed-IPv6-Route AVP defined by NASREQ MIGHT be
	used for home address provision and AVPs defined in EAP application
	MIGHT be used for key transport [3].
	4. Bootstrapping Mobile IPv6 in the split scenario
	In the split scenario for bootstrapping Mobile IPv6 [4], the MN
	discovers HA through DNS mechanism. Then it uses IKEv2 [5] to setup
	IPsec SAs. IKEv2 supports EAP to authenticate the Initiator and thus
	the MN. As such, the MN can use its credentials (obtained from the
	MSA) to be authenticated for the IPv6 mobility service. The HA MAY
	rely on a EAP server co-located on a AAA server for this purpose. In
	this case, a HA-AAA interface is needed. This interface MUST support
	transport of EAP packets.
	+----+ IKEv2 +----+ Diameter EAP +---+
	| MN |<----------->| HA |<-------------------->|AAA|
	+----+ +----+ +---+
	Figure 1: Diameter EAP as the HA-AAA interface in Split scenario
	For this purpose, the HA can use Diameter EAP Application [3] (cf.
	Figure 1). As shown in the previous section, this protocol fulfill
	goals described in [8]
	MN HA AAAH
	-- -- ----
	IKE_SA_INIT
	<------------------------------>
	HDR, SK{IDi,[CERTREQ,] [IDr,]
	SAi2, TSi, TSr}
	------------------------------->
	DER (EAP-Response)
	------------------------>
	DEA (EAP-Request)
	<------------------------
	HDR, SK {IDr, [CERT,] AUTH,
	EAP }
	<-------------------------------
	HDR, SK {EAP}
	-------------------------------->
	DER (EAP-Response)
	------------------------>
	DEA (EAP-Request)
	<------------------------
	HDR, SK{EAP-Request}
	<-------------------------------
	HDR, SK{EAP-Response}
	-------------------------------->
	DER (EAP-Response)
	------------------------>
	... ...
	DEA (EAP-Success)		4.5. Provisioning of Configuration Parameters
	<------------------------
	HDR, SK{EAP-Success}
	<-------------------------------
	HDR, SK{AUTH}
	------------------------------->
	HDR, SK {AUTH, SAr2, TSi, TSr }
	<-------------------------------
	Figure 2: IKEv2 Diameter EAP		Several AVPs could be re-used for carrying the home address of the NM
			to the AAAH server. Framed-IPv6-Prefix AVP in conjunction with
			Framed-Interface-Id AVP, Framed-IPv6-Route AVP or Login-IPv6-Host AVP
			defined by NASREQ might be used for home address communication to the
			AAAH [4].
	MN and HA start with an IKE_SA_INIT to setup the IKE SA. The MN		Even if not explicitly mentioned as goal the AAAH server needs in
	indicates its desire to use EAP by not including the AUTH payload in		some cases the FQDN from the MN if he should do an DNS update of his
	the third message. However it indicates its identity (e.g. NAI) by		behalf. The MN FQDN could be delivered during the IKEv2 exchange
	using the IDi field. If the HA supports EAP for authentication, it		between the HA and the MN (in the IDii field in IKE_AUTH). This FQDN
	forwards the identity to the AAAH by sending a Diameter-EAP-Request		must, if not already known by the AAAH delivered to it. [Editor's
	(DER) message containing the identity in the EAP-Payload AVP and in		Note: An appropriate AVP for carrying the FQDN has not yet been
	the User-Name AVP. Based on this identity, the AAAH chooses an		found.]
	authentication method and sends the first EAP-Request in the
	Diameter-EAP-Answer message. During the EAP authentication phase,
	the HA relays EAP packets between the MN and the AAAH. If the
	authentication succeeds and if the MN is authorized to use Mobile
	IPv6 service, the AAAH sends a DEA message containing the EAP-success
	and the AAA-Key derived from the EAP authentication method . Note
	that EAP authentication methods that do not derive keys are not
	recommended. This key is used by both MN and HA to generate the AUTH
	payload. In the latter message, MN and HA finish to setup IPsec SAs
	for Mobile IPv6.
	5. Security considerations		5. Security Considerations
	[Editor's Note: Since the document is not complete it is necessary to		[Editor's Note: Since the document is not complete it is necessary to
	state that the security consideration section is incomplete as well.		state that the security consideration section is incomplete as well.
	Hence, it is only possible to refer to the security issues raised in		Hence, it is only possible to refer to the security issues raised in
	the Mobile IPv6 and Diameter protocol related documents mentioned		the Mobile IPv6 and Diameter protocol related documents mentioned
	here, such as [11], [8] and [1].]		here, such as [11], [8] and [1].]
	6. IANA Considerations		6. IANA Considerations
	The AVP code for the Home-Agent AVP needs to be allocated.		No new message formats or command codes are defined in this document.
	7. Acknowledgements		7. Acknowledgements
	We would like to thank the MIPv6 Bootstrapping Design Team for their		We would like to thank the MIPv6 Bootstrapping Design Team for their
	comments. Additionally, we would like to thank Junghoon Jee for his		comments. Additionally, we would like to thank Junghoon Jee and
	feedback.		Florian Kohlmayer for their input.
			Parts of this document are a byproduct of the ENABLE Project,
			partially funded by the European Commission under its Sixth Framework
			Programme. It is provided "as is" and without any express or implied
			warranties, including, without limitation, the implied warranties of
			fitness for a particular purpose. The views and conclusions
			contained herein are those of the authors and should not be
			interpreted as necessarily representing the official policies or
			endorsements, either expressed or implied, of the ENABLE Project or
			the European Commission.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,		[1] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko,
	"Diameter Base Protocol", RFC 3588, September 2003.		"Diameter Base Protocol", RFC 3588, September 2003.
	[2] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter		[2] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
	Network Access Server Application", RFC 4005, August 2005.
	[3] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
	Authentication Protocol (EAP) Application", RFC 4072,
	August 2005.
	[4] Giaretta, G., "Mobile IPv6 bootstrapping in split scenario",
	draft-ietf-mip6-bootstrapping-split-01 (work in progress),		draft-ietf-mip6-bootstrapping-split-01 (work in progress),
	October 2005.		October 2005.
	[5] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",		[3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
	draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.		draft-ietf-ipsec-ikev2-17 (work in progress), October 2004.
			[4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
			Authentication Protocol (EAP) Application", RFC 4072,
			August 2005.
			[5] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter
			Network Access Server Application", RFC 4005, August 2005.
	[6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for		[6] Chowdhury, K. and A. Yegin, "MIP6-bootstrapping via DHCPv6 for
	the Integrated Scenario",		the Integrated Scenario",
	draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in		draft-ietf-mip6-bootstrapping-integrated-dhc-00 (work in
	progress), October 2005.		progress), October 2005.
	[7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network		[7] Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
	Services", BCP 17, RFC 2219, October 1997.		Services", BCP 17, RFC 2219, October 1997.
	8.2. Informative References		8.2. Informative References
End of changes. 37 change blocks.
	183 lines changed or deleted		168 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/