draft-arkko-eap-aka-kdf-09.txt		draft-arkko-eap-aka-kdf.txt
	Network Working Group J. Arkko		Network Working Group J. Arkko
	Internet-Draft V. Lehtovirta		Internet-Draft V. Lehtovirta
	Updates: 4187 (if approved) Ericsson		Updates: 4187 (if approved) Ericsson
	Intended status: Informational P. Eronen		Intended status: Informational P. Eronen
	Expires: April 27, 2009 Nokia		Expires: May 22, 2009 Nokia
	October 24, 2008		November 18, 2008
	Improved Extensible Authentication Protocol Method for 3rd Generation		Improved Extensible Authentication Protocol Method for 3rd Generation
	Authentication and Key Agreement (EAP-AKA')		Authentication and Key Agreement (EAP-AKA')
	draft-arkko-eap-aka-kdf-09		draft-arkko-eap-aka-kdf-10
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 April 27, 2009.		This Internet-Draft will expire on May 22, 2009.
	Abstract		Abstract
	This specification defines a new EAP method, EAP-AKA', a small		This specification defines a new EAP method, EAP-AKA', a small
	revision of the EAP-AKA method. The change is a new key derivation		revision of the EAP-AKA method. The change is a new key derivation
	function that binds the keys derived within the method to the name of		function that binds the keys derived within the method to the name of
	the access network. The new key derivation mechanism has been		the access network. The new key derivation mechanism has been
	defined in the 3rd Generation Partnership Project (3GPP). This		defined in the 3rd Generation Partnership Project (3GPP). This
	specification allows its use in EAP in an interoperable manner. In		specification allows its use in EAP in an interoperable manner. In
	addition, EAP-AKA' employs SHA-256 instead of SHA-1.		addition, EAP-AKA' employs SHA-256 instead of SHA-1.
	skipping to change at page 5, line 6		skipping to change at page 5, line 12
	messages, along with the definition of attributes AT_RAND, AT_AUTN,		messages, along with the definition of attributes AT_RAND, AT_AUTN,
	AT_MAC, and AT_RES can be found in [RFC4187].		AT_MAC, and AT_RES can be found in [RFC4187].
	Peer Server		Peer Server
	| EAP-Request/Identity |		| EAP-Request/Identity |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	| |		| |
	| EAP-Response/Identity |		| EAP-Response/Identity |
	| (Includes user's Network Access Identifier, NAI) |		| (Includes user's Network Access Identifier, NAI) |
	|------------------------------------------------------>|		|------------------------------------------------------>|
	| +----------------------------------+		| +-------------------------------------------------+
	| | Server determines the network |		| | Server determines the network name and ensures |
	| | name and ensures that the given |		| | that the given access network is authorized to |
	| | access network is authorized to |		| | use the claimed name. The server then runs the |
	| | use the claimed name. The server |		| | AKA' algorithms generating RAND and AUTN, |
	| | then runs the AKA' algorithms |		| | derives session keys from CK' and IK'. RAND and |
	| | generating RAND and AUTN, |		| | AUTN are sent as AT_RAND and AT_AUTN attributes,|
	| | derives session keys from CK' |		| | whereas the network name is transported in the |
	| | and IK'. RAND and AUTN are sent |		| | AT_KDF_INPUT attribute. AT_KDF signals the used |
	| | as AT_RAND and AT_AUTN |		| | key derivation function. The session keys are |
	| | attributes, whereas the network |		| | used in creating the AT_MAC attribute. |
	| | name is transported in the |		| +-------------------------------------------------+
	| | AT_KDF_INPUT attribute. AT_KDF |
	| | signals the used key derivation |
	| | function. The session keys are |
	| | used in creating the AT_MAC |
	| | attribute. |
	| +----------------------------------+
	| EAP-Request/AKA'-Challenge |		| EAP-Request/AKA'-Challenge |
	| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)|		| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)|
	|<------------------------------------------------------|		|<------------------------------------------------------|
	+--------------------------------------------------+ |		+-----------------------------------------------------+ |
	| The peer determines what the network name should | |		| The peer determines what the network name should be,| |
	| be, based on, e.g., what access technology it | |		| based on, e.g., what access technology it is using.| |
	| is using. The peer also retrieves the network | |		| The peer also retrieves the network name sent by | |
	| name sent by the network from the AT_KDF_INPUT | |		| the network from the AT_KDF_INPUT attribute. The | |
	| attribute. The two names are compared for | |		| two names are compared for discrepancies, and if | |
	| discrepancies, and if necessary, the | |		| necessary, the authentication is aborted. Otherwise,| |
	| authentication is aborted. Otherwise, the | |		| the network name from AT_KDF_INPUT attribute is | |
	| network name from AT_KDF_INPUT attribute is used | |		| used in running the AKA' algorithms, verifying AUTN | |
	| in running the AKA' algorithms, verifying AUTN | |
	| from AT_AUTN and MAC from AT_MAC attributes. The | |		| from AT_AUTN and MAC from AT_MAC attributes. The | |
	| peer then generates RES. The peer also derives | |		| peer then generates RES. The peer also derives | |
	| session keys from CK'/IK'. The AT_RES and AT_MAC | |		| session keys from CK'/IK'. The AT_RES and AT_MAC | |
	| attributes are constructed. | |		| attributes are constructed. | |
	+--------------------------------------------------+ |		+-----------------------------------------------------+ |
	| EAP-Response/AKA'-Challenge |		| EAP-Response/AKA'-Challenge |
	| (AT_RES, AT_MAC) |		| (AT_RES, AT_MAC) |
	|------------------------------------------------------>|		|------------------------------------------------------>|
	| +--------------------------------+		| +-------------------------------------------------+
	| | Server checks the RES and MAC |		| | Server checks the RES and MAC values received |
	| | values received in AT_RES and |		| | in AT_RES and AT_MAC, respectively. Success |
	| | AT_MAC, respectively. Success |		| | requires both to be found correct. |
	| | requires both to be found |		| +-------------------------------------------------+
	| | correct. |
	| +--------------------------------+
	| EAP-Success |		| EAP-Success |
	|<------------------------------------------------------|		|<------------------------------------------------------|
	Figure 1: EAP-AKA' Authentication Process		Figure 1: EAP-AKA' Authentication Process
	3.1. AT_KDF_INPUT		3.1. AT_KDF_INPUT
	The format of the AT_KDF_INPUT attribute is shown below.		The format of the AT_KDF_INPUT attribute is shown below.
	0 1 2 3		0 1 2 3
	skipping to change at page 12, line 36		skipping to change at page 12, line 32
	T2 = HMAC-SHA-256 (K, T1 | S | 0x02)		T2 = HMAC-SHA-256 (K, T1 | S | 0x02)
	T3 = HMAC-SHA-256 (K, T2 | S | 0x03)		T3 = HMAC-SHA-256 (K, T2 | S | 0x03)
	T4 = HMAC-SHA-256 (K, T3 | S | 0x04)		T4 = HMAC-SHA-256 (K, T3 | S | 0x04)
	...		...
	PRF' produces as many bits of output as is needed. HMAC-SHA-256 is		PRF' produces as many bits of output as is needed. HMAC-SHA-256 is
	the application of HMAC [RFC2104] to SHA-256.		the application of HMAC [RFC2104] to SHA-256.
	3.4.2. AT_MAC		3.4.2. AT_MAC
	The AT_MAC attribute is changed as follows. The MAC algorithm is		When used within EAP-AKA', the AT_MAC attribute is changed as
	HMAC-SHA-256-128, a keyed hash value. The HMAC-SHA-256-128 value is		follows. The MAC algorithm is HMAC-SHA-256-128, a keyed hash value.
	obtained from the 32-byte HMAC-SHA-256 value by truncating the output		The HMAC-SHA-256-128 value is obtained from the 32-byte HMAC-SHA-256
	to the first 16 bytes. Hence, the length of the MAC is 16 bytes.		value by truncating the output to the first 16 bytes. Hence, the
			length of the MAC is 16 bytes.
	Otherwise the use of AT_MAC in EAP-AKA' follows Section 10.15 of		Otherwise the use of AT_MAC in EAP-AKA' follows Section 10.15 of
	[RFC4187].		[RFC4187].
	3.4.3. AT_CHECKCODE		3.4.3. AT_CHECKCODE
	The AT_CHECKCODE attribute is changed as follows. First, a 32 byte		When used within EAP-AKA', the AT_CHECKCODE attribute is changed as
	value is needed to accommodate a 256 bit hash output:		follows. First, a 32 byte value is needed to accommodate a 256 bit
			hash output:
	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
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| AT_CHECKCODE | Length | Reserved |		| AT_CHECKCODE | Length | Reserved |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| Checkcode (0 or 32 bytes) |		| Checkcode (0 or 32 bytes) |
	| |		| |
	| |		| |
	skipping to change at page 19, line 26		skipping to change at page 19, line 26
	Value Description Reference		Value Description Reference
	--------- ---------------------- ---------------		--------- ---------------------- ---------------
	0 Reserved		0 Reserved
	1 EAP-AKA' with CK'/IK' [this document]		1 EAP-AKA' with CK'/IK' [this document]
	2-65535 Unassigned		2-65535 Unassigned
	7. Acknowledgments		7. Acknowledgments
	The authors would like to thank Guenther Horn, Joe Salowey, Mats		The authors would like to thank Guenther Horn, Joe Salowey, Mats
	Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad		Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad
	Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Brian		Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni
	Weis, Russ Housley, and Alfred Hoenes for their in-depth reviews and		Malinen, Brian Weis, Russ Housley, and Alfred Hoenes for their in-
	interesting discussions in this problem space.		depth reviews and interesting discussions in this problem space.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-		[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
	Hashing for Message Authentication", RFC 2104,		Hashing for Message Authentication", RFC 2104,
End of changes. 10 change blocks.
	49 lines changed or deleted		42 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/