< draft-song-mobile-ipv4-auth-secgeneration-00.txt		draft-song-mobile-ipv4-auth-secgeneration-01.txt >
	JunHyuk Song		JunHyuk Song
	INTERNET DRAFT ChaeYong Chong		INTERNET DRAFT ChaeYong Chong
	29 June 2001 Samsung Elec.		04 July 2001 Emfro Kim
			Samsung Elec.
	Dongkie Leigh		Dongkie Leigh
	SK telecom		SK telecom
	Raymond Hsu		Raymond Hsu
	Qualcomm Inc.		Qualcomm Inc.
	Mobile IPv4 Authentication Shared key Generation		Mobile IPv4 Authentication Shared key Generation
	draft-song-mobile-ipv4-auth-secgeneration-00.txt		draft-song-mobile-ipv4-auth-secgeneration-01.txt
	Status of This Memo		Status of This Memo
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026. Internet-Drafts are working		all provisions of Section 10 of RFC2026. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its working groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet-Drafts.		working documents as Internet-Drafts.
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 38 ¶
	The list of current Internet-Drafts can be accessed at:		The list of current Internet-Drafts can be accessed at:
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at:		The list of Internet-Draft Shadow Directories can be accessed at:
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	Abstract		Abstract
	Mobile Node and Home Agent servers used in nowadays can provide		Mobile Node and Home Agent servers used in nowadays can provide
	authentication and authorization services mostly by the MN-HA and		authentication and authorization services mostly by the MN-HA and
	MN-AAA Authentication. However, this kind of Security Association is		MN-AAA Authentication. However, this is only possible if Mobile Node
	only possible if Mobile Node previously share the same shared secrets		previously share the same shared secrets with Home Agent and AAA.
	with Home Agent and AAA. Based on the assumption that the SA between		Based on the assumption that the SA between Mobile Node and Home AAA
	Mobile Node and Home AAA is strong, it is possible to use that		is strong, and the FAC issued from a Foreign Agent can provide
	security association to dynamically update MN-AAA Authentication		reasonable randomness. It is possible to use that security
	shared secret and create security associations between the Mobile		association and the FAC to create a security associations between the
	Node and foreign agent and its home agent. This document specifies		Mobile Node and its Home Agent. This document specifies a method
	the method to dynamically update the shared secret used for MN-AAA		to dynamically create a shared secret used for MN-HA extension
	extension and create shared secret used for MN-HA extension among		between Mobile Node and Home Agent, based on MN-AAA shared secret,
	Mobile Node, Foreign Agent and Home Agent, based on MN-AAA shared		NAI, and Foreign Agent Challenge.
	secret, NAI, Foreign Agent IP address and Foreign Agent Challenge.
	Contents		Contents
	Status of This Memo 1		Status of This Memo 1
	Abstract 1		Abstract 1
	1. Introduction.......................................................3		1. Introduction.......................................................3
			1.2 Acronym.......................................................3
	2. The parameters used for Dynamic MN-HA shared secret generation ....3		2. The parameters used for Dynamic MN-HA shared secret generation ....4
			2.1 Mobile IP Agent Advertisement Challenge Extension.............4
	2.1 Mobile IP Agent Advertisement Challenge Extension.............3
	2.2 Network Access Identifier (NAI)...............................4		2.2 Network Access Identifier (NAI)...............................4
			2.3 Master MN-AAA shared secret...................................5
	2.3 MN-AAA shared secret..........................................4		3. MN-HA shared secret creation.......................................5
			3.1 MN-HA shared key creation by Mobile Node......................5
	3. MN-AAA shared secret update........................................4		3.2 MN-HA shared key creation by AAA..............................5
	3.1 MN-AAA key update by Mobile Node..............................4
	3.2 MN-AAA key update by AAA......................................5
	4. MN-HA shared secret creation.......................................5
	4.1 MN-HA key creation by Mobile Node.............................5
	4.2 MN-HA shared key creation by AAA..............................5		4. Key Management.....................................................6
			4.1 MN-HA key management.........................................7
			4.2 DIAMETER consideration........................................8
	5 Operation description...............................................6		5. Operation description..............................................9
	6 Security Considerations.............................................6		6. Security Considerations............................................9
	Appendix A - 3G Wireless example......................................7		Appendix A - 3G Wireless example......................................9
	Appendix B - MN-FA shared key consideration...........................8		Appendix B - MN-FA shared key consideration..........................11
	References............................................................8		References...........................................................11
	Addresses.............................................................9		Addresses............................................................12
	1. Introduction		1. Introduction
	In Mobile IP, AAA servers is in use nowadays to identify and		In Mobile IP, AAA servers is in use nowadays to identify and
	authenticate the mobile node by the Network Access Identifier (NAI)		authenticate the mobile node by the Network Access Identifier (NAI)
	[1] and MN-AAA authenticator [3]. Besides the mobile node is required		[1] and MN-AAA authenticator [3]. In addition, the mobile node is
	to have a security association with its home agent [2]. Mobile IP		required to have a security association with its home agent [2].
	defines an MN-HA authentication extension by which a mobile node can		Mobile IP defines an MN-HA authentication extension by which a mobile
	authenticate itself to a home agent. However it is not currently		node can authenticate itself to a home agent. However it is not
	defined how Mobile Node, Home Agent and AAA obtain and update the		currently defined how Mobile Node, Home Agent and AAA obtain
	shared secret used in computing MN-AAA and MN-HA authenticator.		the shared secrets used in computing MN-AAA and MN-HA
	Based on the assumption that the SA between Mobile Node and Home AAA		authenticator. Based on the assumption that the SA between Mobile
	is strong, it is possible to use that security association to create		Node and Home AAA is strong, and the FAC issued from a Foreign Agent
	security associations between the Mobile Node and its Home Agent.		can provide reasonable randomness. It is possible to use that
	This document specifies the method to dynamically update the shared		security association and FAC to create security associations between
	secret used for MN-AAA extension and create shared secret used for		the Mobile Node and its Home Agent. This document specifies a
	MN-HA extension among Mobile Node, Foreign Agent and Home Agent,		method to dynamically a create shared secret used for MN-HA extension
	based on MN-AAA shared secret, NAI, Foreign Agent IP address and		between Mobile Node and Home Agent, based on the MN-AAA shared
	Foreign Agent Challenge.		secret, NAI, and Foreign Agent Challenge.
			1.1 Acronym
			MN : Mobile Node
			FA : Foreign Agent
			HA : Home Agent
			AAA : Authentication, Authorization , and Accounting
			AAAH : Home AAA
			AAAF : Foreign AAA
			AR : Access Request
			AA : Access Accept
			FAC : Foreign Agent Challenge
			RRQ : Mobile IP Registration Request
			RRP : Mobile IP Registration Reply
			SPI : Security Parameter Index
			Key : Shared Secret
			PDSN : Packet Data Serving Node
	2. The parameters used for Dynamic MN-HA shared secret generation		2. The parameters used for Dynamic MN-HA shared secret generation
	This section defines the parameters used for MN-HA shared secret		This section defines the parameters used for the session MN-AAA
	generation and MN-AAA shared secret update.		shared secret and MN-HA shared secret generation.
	2.1 Mobile IP Agent Advertisement Challenge Extension		2.1 Mobile IP Agent Advertisement Challenge Extension
	Currently Foreign Agent Challenge extension [3] is defined and in use		Currently Foreign Agent Challenge extension [3] is defined and in use
	for 3G wireless system. That challenge extension is sent with the		for 3G wireless system. That challenge extension is sent with the
	Agent Advertisement by the Foreign Agent, in order to used by Mobile		Agent Advertisement by the Foreign Agent, in order to be used by
	Node to create the MN-AAA authentication extension for its Mobile IP		Mobile Node to create the MN-AAA authentication extension for its
	Registration Request.		Mobile IP Registration Request.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Challenge ...		| Type | Length | Challenge ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: The Challenge Extension [3]		Figure 1: The Challenge Extension [3]
	Type 24		Type 24
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 51 ¶
	for AAA to identify the clients.		for AAA to identify the clients.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | MN-NAI ...		| Type | Length | MN-NAI ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: The Mobile Node NAI Extension [9]		Figure 2: The Mobile Node NAI Extension [9]
	Type 131 (skippable)		Type 131 (skippable)
	Length The length in bytes of the MN-NAI field		Length The length in bytes of the MN-NAI field
	MN-NAI A string in the NAI format defined in [1]		MN-NAI A string in the NAI format defined in [1]
	2.3 MN-AAA shared secret		2.3 MN-AAA shared secret
	MN-AAA shared secret is the key used to compute MN-AAA authentication		The MN-AAA shared secret is the key used to compute the MN-AAA
	extension.		authentication extension.
	3. MN-AAA shared secret update		3. MN-HA shared secret creation
	This section describes how the current MN-AAA shared secret is		This section describes the MN-HA shared secret creation by the Mobile
	updated by Mobile Node and AAA. How the initial MN-AAA shared secret		Node and AAA.
	is distributed to the Mobile Node and AAA is out of scope of this
	document
	3.1 MN-AAA key update by Mobile Node		3.1 MN-HA key creation by Mobile Node
	1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent		1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent
	Advertisement.		Advertisement [3].
	2. The mobile node uses the FA Challenge, its own NAI, and the		2. The mobile node uses the FA Challenge, its own NAI, and the
	previously assigned MN-AAA shared secret to calculate:		MN-AAA shared secret to calculate:
	Current MN-AAA shared key =		MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge |
	HMAC-MD5(Initial MN-AAA-key | FA Challenge | MN NAI |		MN NAI | MN-AAA-key)
	Initial MN-AAA-key)
	3.2 MN-AAA key update by AAA		3.2 MN-HA shared key creation by AAA
	1. AAA identifies Foreign Agent Challenge and MN's NAI from the AAA		1. AAA identifies Foreign Agent Challenge and the MN's NAI from the
	message		AAA message.
	2. AAA uses the FA Challenge, MN's NAI and the initially assigned		2. AAA uses the FA Challenge, MN's NAI, and MN-AAA shared
	MN-AAA shared secret to calculate:		secret to calculate:
	Current MN-AAA shared key =		MN-HA shared key = HMAC-MD5(MN-AAA-key | FA Challenge |
	HMAC-MD5(Initial MN-AAA-key | FA Challenge | MN NAI |		MN NAI | MN-AAA-key)
	Initial MN-AAA-key)
	4. MN-HA shared secret creation		4. Key Management
	This section describes the MN-HA shared secret creation by the Mobile		MN-HA shared key lifetime management is OPTIONAL. It MAY be used to
	Node and AAA.		increase the entropy of MN-HA shared key, or reduce the MN-HA
			shared key fetching between the HA and the AAA server if RADIUS is
			used.
	4.1 MN-HA key creation by Mobile Node		(Note: In real time, it in not likely MN-HA shared secret is ever
			refreshed during MIP session, because MN-HA shared secret is
			session specific, and MN-HA shared secret lifetime must be
			reasonably greater than MIP re-registration lifetime.
			The lifetime of MN-HA shared secret is operator configurable.
			MN-HA shared secret may be refreshed on every re-registration
			or used for until user terminate the session.)
	1. Mobile Node identifies Foreign Agent Challenge in Mobile IP Agent		Mobile Node MAY optionally configured with a lifetime of MN-HA shared
	Advertisement.		secret. Home Agent MAY optionally have a lifetime of MN-HA shared
			key, as received from AAAH along with MN-HA shared key, according to
			a user profile.
	2. The mobile node uses the FA Challenge, its own NAI, and the		The length of the lifetime is operator configurable and it SHOULD be
	currently generated MN-AAA shared secret to calculate:		greater than the MIP re-registration time. Home Agent MUST fetch the
			pre-fixed MN-HA shared secret lifetime and MN-HA shared secret from
			AAAH.
	MN-HA shared key = HMAC-MD5(Current MN-AAA-key | FA Challenge |		The Identification field in Mobile IP Registration Request is used
	MN NAI | Current MN-AAA-key)		for preventing possible replay attack and delayed duplicate message
			to arrive at the home agent. It contains mandatory timestamp and
			optional nonce [2]. This Identification field in Mobile IP
			Registration Request is used to let Home Agent to check the validity
			of MN-HA shared secret.
	4.2 MN-HA shared key creation by AAA		Below is 64 bits Identification field of MIP RRQ message.
	1. AAA identifies Foreign Agent Challenge and the MN's NAI from the		0 1 2 3
	AAA message.		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| |
			+ Identification +
			| |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	2. AAA calculates uses the FA Challenge, MN's NAI, and the currently		When MN creates MN-HA shared secret, the timestamp is issued.
	generated MN-AAA shared secret to calculate:		The timestamp of MN-HA shared key is placed in the high-order 32 bits
			of MIP RRQ Identification field. This high order bit of
			Identification field is from MN's own time of day [2].
			The high-order 32 bits of MIP RRQ Identification field is used for
			the HA to configure the expiration time for the MN-HA shared key.
	MN-HA shared key = HMAC-MD5(Current MN-AAA-key | FA Challenge |		The low-order 32 bits of MIP RRQ Identification field MAY be
	MN NAI | Current MN-AAA-key)		optionally used to enable FA and HA to refresh shared key.
			4.1 MN-HA shared key lifetime Management for Dynamic Mobile IP Home
			Agent Allocation case with RADIUS based AAA (see Appendix A)
			When HA receives RRQ, the HA fetches MN-HA shared secret from AAA in
			the following case 1 and 3
			1. New MIP registration case.
			In this case, there is no previously assigned MN-HA shared secret
			for the matching NAI or MN IP address. Even if there is a
			previously assigned MN-HA shared secret for the matching NAI or MN
			IP address, HA should not use that MN-HA shared key, because it is
			new Mobile IP session.
			The HA SHOULD use the home agent field or the home address field in
			the MIP RRQ to differentiate the new MIP registration case from the
			MIP re-registration case. If the home agent field or home address
			field of MIP RRQ is equal to "0.0.0.0", the HA identifies this as a
			new MIP registration.
			Mobile Node MAY optionally use the low-order 32 bits of MIP RRQ
			Identification field as the indicator whether MN-HA shared secret
			is refreshed. If the low-order 32 bits of MIP RRQ Identification
			field is equal to current MN-HA shared secret's timestamp, HA MAY
			identify this as a new MIP registration or MN-HA shared secret is
			currently refreshed.
			Upon identifying MIP RRQ as a new registration message, HA MUST
			send AAA message to fetch MN-HA shared secret and its lifetime.
			2. Re-registration case with valid MN-HA shared key.
			In this case, there is a previously assigned MN-HA shared secret
			for the matching NAI or MN IP address and the lifetime of MN-HA
			shared key is valid.
			Upon the receipt of an MIP RRQ, if there is previously assigned
			MN-HA shared key and it is not new MIP registration case, the Home
			Agent MUST check the validity of the lifetime of MN-HA shared key.
			If the high order bit of Identification field is smaller than
			the expected lifetime of MN-HA shared secret, Home Agent
			shall authenticate RRQ with stored MN-HA shared secret, and send RRP
			after necessary MIP processing. The expected lifetime of
			MN-HA is derived by adding a lifetime of MN-HA shared key and the
			timestamp of MN-HA shared key.
			3. Re-registration case with expired MN-HA shared key lifetime.
			In this case, there is previously assigned MN-HA shared secret for
			matching NAI or MN IP address. But the lifetime of stored MN-HA
			shared key is already expired.
			Upon the receipt of an MIP RRQ, the HA MUST check if it is an
			initial MIP registration or MIP re-registration. In the case of
			MIP re-registration, the HA shall check whether or not the lifetime
			of MN-HA shared key is expired. If the high order bit of
			Identification field is greater than the expected lifetime of MN-HA
			shared secret, HA shall send AAA message to fetch MN-HA shared
			secret and its lifetime. After the receipt of MN-HA shared secret and
			lifetime, Home Agent MUST authenticate the MIP RRQ, and the HA shall
			set the timer for MN-HA shared secret according to the timestamp in
			the high-order 32 bits of the MIP RRQ Identification field.
			4.2 DIAMETER consideration
			For DIAMETER based AAA, the MN-HA shared secret key management
			described in section 4.1 may not be needed for home agent. Because
			MN will decide the lifetime of updating MN-HA shared secret, and the
			updated MN-HA shared key will be delivered to HA by DIAMETER HAR
			message.
	5. Operation description		5. Operation description
	Home Agent shall obtain MN-HA shared secret from AAA.		Home Agent MUST obtain MN-HA shared secret from AAA. The MN-HA
	The key fetching method varies from RADIUS [7] to DIAMETER [8] and		shared key is session specific, and shall be used until termination
	it is out of scope of this document.		of MIP session or MIP re-registration.
			The home agent MAY optionally set the lifetime of MN-HA shared
			secret. The lifetime of MN-HA shared key is operator configurable.
			The key fetching method varies from RADIUS [7] to DIAMETER [8] and it
			is outside the scope of this document.
	6. Security Considerations		6. Security Considerations
	The key generation method described in this document provides the		The key generation method described in this document provides the
	reasonable level of security by dynamically creating and updating the		reasonable level of security by dynamically creating the
	shared secrets. Since this key generation method depends on already		shared secrets. Since this key generation method depends on the
	available key materials used in Mobile IP, it does not require new		key materials(i.e., NAI, FAC, MN-AAA shared secret) that are
	key materials. Foreign Agent Challenge is used to avoid replay		available already in Mobile IP, it does not require any new key
	attack and enhance the security. Therefore the weakest point		materials.
	of this scheme is on the security of the shared secret for MN-AAA.
	Since the MN-AAA shared secret is dynamically updated for every MIP		Foreign Agent Challenge is used to avoid replay attack and enhance
	registration after it assigned first time, therefore the risk of		entropy. It is the same FAC that used for MN-AAA authentication
	exposing the MN-AAA shared secret is minimal.		extension generation. The randomness of FAC depends on random
			number generator in the Foreign Agent. However, if FA is malicious
			and is sending static FAC continuously rather than random FAC,
			"chosen cipher text attack" is possible. Although the cost and time
			to reverse engineering the value generated by MD5 is not practical,
			it is not impossible. Therefore in order to counter this potential
			attack, FAC extension sent from the FA to AAAF SHOULD be
			authenticated by the shared secret between the FA and AAAF.
			Furthermore, it is assumed that the communication between AAAF and
			AAAH is secured.
			Based on the assumptions, the randomness of FAC is guaranteed;
			therefore, the security of this method is as good as the MN-AAA
			authentication based on RFC-3012
	Appendix A - 3G Wireless Example		Appendix A - 3G Wireless Example
	In 3GPP2 Wireless system, both RADIUS and DIAMETER is supported as		In 3GPP2 Wireless system, both RADIUS and DIAMETER is supported as
	the AAA protocols. This document suggests a method of dynamically		the AAA protocols. This document suggests a method of dynamically
	creating and maintaining the shared secrets for MN-AAA and MN-HA		creating and maintaining the MN-HA shared secret. This scheme is
	authentication. This is especially beneficial for the case of		especially beneficial for the case of dynamic HA allocation.
	dynamic HA allocation. In 3G wireless systems, if each Mobile Node
	and Home Agent has the same static shared secret for MN-HA
	authentication, it would be problematic for dynamic HA allocation
	because each HA generally has no knowledge of all the MN-HA shared
	secrets. On the other hand, configuring all the HAs with all the
	MN-HA shared secrets in an administration domain raises concerns
	in security and scalability.
	+--------------+ +--------------+		In 3G wireless systems, if each Mobile Node and Home Agent has the
	| |------------------->| |		same static shared secret for MN-HA authentication, it would be
	| AAAF | | AAAH |		problematic for dynamic HA allocation because each HA generally has
	| |<-------------------| |		no knowledge of all the MN-HA shared secrets. On the other hand,
	+--------------+ +--------------+		configuring all the HAs with all the MN-HA shared secrets in an
	^ | ^ |		administration domain raises concerns in security and scalability.
	| | | |
	| v | v		+--------------+ AR +--------------+
	+-----+ +--------------+ +--------------+		| |------------------>| |
	| | | | | |		| AAAF | | AAAH |
	| MS |----->| PDSN/FA |------------------->| Home Agent |		| RADIUS |<------------------| RADIUS |
	| |<-----| |<-------------------| |		+--------------+ AA +--------------+
	+-----+ +--------------+ +--------------+		^ | ^ |
			| | | |
			AR | | AA AR | | AA
			| v | v
			+-----+ +--------------+ +--------------+
			| | RRQ | | RRQ | |
			| MS |-------->| PDSN/FA |------------------>| Home Agent |
			| |<--------| |<------------------| |
			+-----+ RRP +--------------+ RRP +--------------+
	Figure 3 (3G Wireless Network)		Figure 3 (3G Wireless Network)
	If this scheme applied to the 3GPP2 Wireless Network in figure 3, the		If this scheme applied to the 3GPP2 Wireless Network in figure 3,
	Mobile station (MS) shall update its pre-assigned MN-AAA shared		MS shall create the MN-HA shared secret by running HMAC-MD5 with
	secret by running HMAC-MD5 with input of its NAI, Foreign Agent		input of its NAI, Foreign Agent challenge, and MN-AAA key.
	Challenge, and the MN-AAA key. Then MS shall create the MN-HA shared
	secret by running HMAC-MD5 with input of its NAI, Foreign Agent		In the case of RADIUS based AAA, two scenarios MAY be possible
	challenge, and newly generated MN-AAA key. When AAAH receives the		depends on how PDSN is configured. Currently IS-835 only optionally
	AAA message, relayed from AAAF, AAAH shall update the MN-AAA shared		support MN-AAA authentication in case of MIP re-registration.
	secret for that MS by using the same parameters from the AAA message.
	Upon completing the MN-AAA authentication, AAAH shall generate the		1. PDSN configured to send Access Request message extension to AAAH
	MN-HA shared secret by using the same parameters that the MS used.		for MN-AAA authentication
	How Home Agent obtain that shared secret for MN-HA is up to AAA
	protocol. In the case of using the RADIUS protocol, Home Agent shall		2. PDSN configured not to send Access Request message to AAAH for
	send the Access Request message to fetch MN-HA shared secret. In the		MN-HA authentication
	case of using DIAMETER protocol, the MN-HA Shared Secret will be
	sent to HA by the HAR message. [10]		In the first case, the mobile will create the MN-HA shared key with
			input of NAI, FAC, and MN-AAA shared key. The mobile shall send RRQ
			with "0.0.0.0" in the Home Agent Address field. Upon successfully
			completing the MN-AAA authentication, AAAH shall generate the MN-HA
			shared secret by using the same parameters that the MS used. Home
			Agent MAY fetch MN-HA shared key for each re-registration happens
			or MAY cache MN-HA shared key during certain period of time defined
			in the lifetime of MN-HA shared secret.
			In the second case, MIP re-registration totally depends on the MN-HA
			authentication, since MN-AAA authentication shall only performed for
			the first MIP registration. The mobile will create the MN-HA shared
			key with input of NAI, FAC, and MN-AAA shared key. The mobile shall
			send RRQ with "0.0.0.0" in the Home Agent Address field. After
			successful MN-AAA authentication by AAAH, HA shall receive RRQ from
			PDSN. When HA receives RRQ, HA SHOULD send RADIUS Access Request
			message with NAI and FAC. Upon receiving the Access Request, AAA
			SHOULD generate the MN-HA shared key by using the same parameters
			that the MS used. HA will receive MN-HA shared key along with
			lifetime. HA MAY optionally sends fetching message along with FAC
			and NAI upon every re-registration happens or MAY cache MN-HA shared
			key during certain period of time defined in the lifetime of MN-HA
			shared secret. The main difference from the first case is that HA
			identifies FAC from RRQ and sends Access Request with FAC to AAAH.
			In the case of using DIAMETER protocol, the MN-HA Shared Secret will
			be sent to HA by the HAR message. [10]
	Appendix B - MN-FA shared key consideration		Appendix B - MN-FA shared key consideration
	Mobile Node and AAA now can easily derive MN-FA shared key by running		Mobile Node and AAA now can easily derive MN-FA shared key by running
	the HMAC-MD5 with input of MN-AAA shared secret, FA's IP address,		the HMAC-MD5 with input of MN-HA shared secret, FA's IP address, FAC
	MN's NAI. This method has better scalability and less administrative		and MN's NAI. This method has better scalability and less
	effort than provisioning MN-FA shared secrets. In face it is		administrative effort than provisioning MN-FA shared secrets.
	administrative prohibitive to provision all MNs and FAs with static		In face it is administrative prohibitive to provision all MNs and FAs
	shared secrets.		with static shared secrets.
	References		References
	[1] B. Aboba and M. Beadles. The Network Access Identifier.		[1] B. Aboba and M. Beadles. The Network Access Identifier.
	Request for Comments (Proposed Standard) 2486, Internet		Request for Comments (Proposed Standard) 2486, Internet
	Engineering Task Force, December 1999.		Engineering Task Force, January 1999.
	[2] C. Perkins. IP Mobility Support. Request for Comments		[2] C. Perkins. IP Mobility Support. Request for Comments
	(Proposed Standard) 2002, Internet Engineering Task Force,		(Proposed Standard) 2002, Internet Engineering Task Force,
	October 1996.		October 1996.
	[3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent		[3] P. Calhoun and C. E. Perkins. Mobile IP Foreign Agent
	Challenge/Response Extension. Request for Comments (Proposed		Challenge/Response Extension. Request for Comments (Proposed
	Standard) 3012, Internet Engineering Task Force, December 2000.		Standard) 3012, Internet Engineering Task Force, January 2000.
	[4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing		[4] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
	for Message Authentication. Request for Comments		for Message Authentication. Request for Comments
	(Informational) 2104, Internet Engineering Task Force,		(Informational) 2104, Internet Engineering Task Force,
	February 1997.		February 1997.
	[5] P. Calhoun and C. E. Perkins. AAA Registration Keys for		[5] P. Calhoun and C. E. Perkins. AAA Registration Keys for
	Mobile IP Internet Draft, Internet Engineering Task Force.		Mobile IP Internet Draft, Internet Engineering Task Force.
	draft-ietf-mobileip-aaa-key-06.txt (work in progress)		draft-ietf-mobileip-aaa-key-06.txt (work in progress)
	December 2001.		January 2001.
	[6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing		[6] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing
	for Message Authentication. Request for Comments		for Message Authentication. Request for Comments
	(Informational) 2104, Internet Engineering Task Force,		(Informational) 2104, Internet Engineering Task Force,
	February 1997.		February 1997.
	[7] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote		[7] C. Rigney, A. Rubens, W. Simpson, and S. Willens. Remote
	Authentication Dial In User Service (RADIUS). Request for		Authentication Dial In User Service (RADIUS). Request for
	Comments (Proposed Standard) 2865, Internet Engineering Task		Comments (Proposed Standard) 2865, Internet Engineering Task
	Force, June 2000.		Force, June 2000.
	[8] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER		[8] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER
	Base Protocol (work in progress). Internet Draft, Internet		Base Protocol (work in progress). Internet Draft, Internet
	Engineering Task Force.		Engineering Task Force.
	draft-ietf-aaa-diameter-03.txt, May 2001.		draft-ietf-aaa-diameter-03.txt, May 2001.
	[9] P. Calhoun and C. E. Perkins. Mobile IP Network Access		[9] P. Calhoun and C. E. Perkins. Mobile IP Network Access
	Identifier Extension for IPv4. Request for Comments		Identifier Extension for IPv4. Request for Comments
	(Proposed Standard) 2794, Internet Engineering Task		(Proposed Standard) 2794, Internet Engineering Task
	Force, March 2000		Force, March 2000
	[10] P. Calhoun and C. E. Perkins. Diamter Mobile IP Extensions		[10] P. Calhoun and C. E. Perkins. Diamter Mobile IP Extensions
	Internet Draft, Internet Engineering Task Force.		Internet Draft, Internet Engineering Task Force.
	draft-ietf-aaa-diameter-mobileip-01.txt		draft-ietf-aaa-diameter-mobileip-01.txt
	Addresses		Addresses
	Questions about this memo can be directed to the authors:		Questions about this memo can be directed to the authors:
	JUNHYUK SONG DongKie Leigh		JUNHYUK SONG DongKie Leigh
	SAMSUNG ELECTRONICS. SK TELECOM		SAMSUNG ELECTRONICS. SK TELECOM
	Mobile Development Team Core Network Development Team		Mobile Development Team Core Network Development Team
	Network Systems Division Network R&D Center		Network Systems Division Network R&D Center
	Phone: +82-31-779-6822 Phone +82-2-829-4640		Phone: +82-31-779-6822 Phone +82-2-829-4640
	Email: santajun@lycos.co.kr Email: galahad@netsgo.com		Email: santajun@lycos.co.kr Email: galahad@netsgo.com
	FAX: +82-31-7798769 FAX:+82-2-829-4612		FAX: +82-31-7798769 FAX:+82-2-829-4612
	Raymond Hsu CHAE YONG CHONG		Raymond Hsu CHAE YONG CHONG
	Qualcomm Inc. SAMSUNG ELECTRONICS.		Qualcomm Inc. SAMSUNG ELECTRONICS.
	Corporate R&D Mobile Development Team		Corporate R&D Mobile Development Team
	Phone: 1-858-651-3623 Network Systems Division		Phone: 1-858-651-3623 Network Systems Division
	Email: rhsu@qualcomm.com Phone: +82-31-779-6822		Email: rhsu@qualcomm.com Phone: +82-31-779-6822
	FAX: 1-858-658-5006 Email:cychong@samsung.com		FAX: 1-858-658-5006 Email:cychong@samsung.com
			Emfro ZuYong Kim
			SAMSUNG ELECTRONICS.
			Mobile Development Team
			Phone: +82-31-779-6764
			emfro@samsung.co.kr
End of changes. 54 change blocks.
	160 lines changed or deleted		305 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/