< draft-ietf-emu-eap-gpsk-16.txt		draft-ietf-emu-eap-gpsk-17.txt >
	EMU Working Group T. Clancy		EMU Working Group T. Clancy
	Internet-Draft LTS		Internet-Draft LTS
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: May 1, 2009 Nokia Siemens Networks		Expires: May 23, 2009 Nokia Siemens Networks
	October 28, 2008		November 19, 2008
	EAP Generalized Pre-Shared Key (EAP-GPSK) Method		EAP Generalized Pre-Shared Key (EAP-GPSK) Method
	draft-ietf-emu-eap-gpsk-16		draft-ietf-emu-eap-gpsk-17
	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 35 ¶		skipping to change at page 1, line 35 ¶
	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 May 1, 2009.		This Internet-Draft will expire on May 23, 2009.
	Abstract		Abstract
	This Internet Draft defines an Extensible Authentication Protocol		This Internet Draft defines an Extensible Authentication Protocol
	(EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This		(EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This
	method is a lightweight shared-key authentication protocol supporting		method is a lightweight shared-key authentication protocol supporting
	mutual authentication and key derivation.		mutual authentication and key derivation.
	Table of Contents		Table of Contents
	skipping to change at page 2, line 23 ¶		skipping to change at page 2, line 23 ¶
	4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11
	6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13		7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13
	8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13		8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13
	8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13		8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13
	8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13		8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
	8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14		8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
	8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14		8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14
	8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14		8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
	8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14		8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
	9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15		9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15		9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
	9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15		9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16
	9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16		9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
	9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21		9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21
	10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24		10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24
	11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25		11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 28		12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
	12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 28		12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 28
	12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29		12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29
	12.3. Protected Result Indications . . . . . . . . . . . . . . 29		12.3. Protected Result Indications . . . . . . . . . . . . . . 29
	12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30		12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30
	12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30		12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
	12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30		12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30
	12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30		12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30
	12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31		12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31
	12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31		12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31
	12.10. Session Independence . . . . . . . . . . . . . . . . . . 31		12.10. Session Independence . . . . . . . . . . . . . . . . . . 32
	12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32		12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32
	12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32		12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32
	12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32		12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
	12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 33		12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 33
	12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33		12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33
	12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33		12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33
	12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34		12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34
	12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34		12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34
	13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34		13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	A || B: Concatenation of octet strings A and B		A || B: Concatenation of octet strings A and B
	A**B: Integer exponentiation		A**B: Integer exponentiation
	truncate(A,B): Returns the first B octets of A		truncate(A,B): Returns the first B octets of A
	ENC_X(Y): Encryption of message Y with a symmetric key X, using a		ENC_X(Y): Encryption of message Y with a symmetric key X, using a
	defined block cipher		defined block cipher
	KDF_X(Y): Key Derivation Function that generates an arbitrary number		KDF-X(Y): Key Derivation Function that generates an arbitrary number
	of octets of output using secret X and seed Y		of octets of output using secret X and seed Y
	length(X): Function that returns the length of input X in octets,		length(X): Function that returns the length of input X in octets,
	encoded as a 2-octet integer in network byte order		encoded as a 2-octet integer in network byte order
	MAC_X(Y): Keyed message authentication code computed over Y with		MAC_X(Y): Keyed message authentication code computed over Y with
	symmetric key X		symmetric key X
	SEC_X(Y): SEC is a function that provides integrity protection based		SEC_X(Y): SEC is a function that provides integrity protection based
	on the chosen ciphersuite. The function SEC uses the algorithm		on the chosen ciphersuite. The function SEC uses the algorithm
	defined by the selected ciphersuite and applies it to the message		defined by the selected ciphersuite and applies it to the message
	content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y).		content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y).
	X[A..B]: Notation representing octets A through B of octet array X		X[A..B]: Notation representing octets A through B of octet array X
			where the first octet of the array has index zero
	The following abbreviations are used for the keying material:		The following abbreviations are used for the keying material:
	EMSK: Extended Master Session Key is exported by the EAP method (64		EMSK: Extended Master Session Key is exported by the EAP method (64
	octets)		octets)
	MK: Master Key between the peer and EAP server from which all other		MK: A session-specific Master Key between the peer and EAP server
	EAP method session keys are derived (KS octets)		from which all other EAP method session keys are derived (KS
			octets)
	MSK: Master Session Key exported by the EAP method (64 octets)		MSK: Master Session Key exported by the EAP method (64 octets)
	PK: Session key generated from the MK and used during protocol		PK: Session key generated from the MK and used during protocol
	exchange to encrypt protected data (KS octets)		exchange to encrypt protected data (KS octets)
	PSK: Long-term key shared between the peer and the server (PL		PSK: Long-term key shared between the peer and the server (PL
	octets)		octets)
	SK: Session key generated from the MK and used during protocol		SK: Session key generated from the MK and used during protocol
	exchange to demonstrate knowledge of the PSK (KS octets)		exchange to demonstrate knowledge of the PSK (KS octets)
	3. Overview		3. Overview
	The EAP framework (see Section 1.3 of [RFC3748]) defines three basic		The EAP framework (see Section 1.3 of [RFC3748]) defines three basic
	steps that occur during the execution of an EAP conversation between		steps that occur during the execution of an EAP conversation between
	the EAP peer, the Authenticator and the EAP server.		the EAP peer, the Authenticator and the EAP server.
	1. The first phase, discovery, is handled by the underlying protocol		1. The first phase, discovery, is handled by the underlying
	(e.g. IEEE 802.1X as utilized by IEEE 802.11i).		protocol, e.g. IEEE 802.1X as utilized by IEEE 802.11 [80211].
	2. The EAP authentication phase with EAP-GPSK is defined in this		2. The EAP authentication phase with EAP-GPSK is defined in this
	document.		document.
	3. The secure association distribution and secure association phases		3. The secure association distribution and secure association phases
	are handled differently depending on the underlying protocol.		are handled differently depending on the underlying protocol.
	EAP-GPSK performs mutual authentication between EAP peer ("Peer") and		EAP-GPSK performs mutual authentication between EAP peer ("Peer") and
	EAP server ("Server") based on a pre-shared key (PSK). The protocol		EAP server ("Server") based on a pre-shared key (PSK). The protocol
	consists of the message exchanges (GPSK-1, ..., GPSK-4), in which		consists of the message exchanges (GPSK-1, ..., GPSK-4), in which
	both sides exchange nonces and their identities, compute and exchange		both sides exchange nonces and their identities, compute and exchange
	a Message Authentication Code (MAC) over the previously exchanged		a Message Authentication Code (MAC) over the previously exchanged
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 19 ¶
	The decision which ciphersuite to offer and which ciphersuite to pick		The decision which ciphersuite to offer and which ciphersuite to pick
	is policy- and implementation-dependent and therefore outside the		is policy- and implementation-dependent and therefore outside the
	scope of this document.		scope of this document.
	In GPSK-2, the peer sends its identity ID_Peer and a random number		In GPSK-2, the peer sends its identity ID_Peer and a random number
	RAND_Peer. Furthermore, it repeats the received parameters of the		RAND_Peer. Furthermore, it repeats the received parameters of the
	GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected		GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected
	ciphersuite. It computes a Message Authentication Code over all the		ciphersuite. It computes a Message Authentication Code over all the
	transmitted parameters.		transmitted parameters.
	The EAP server verifies the received Message Authentication Code. In		The EAP server verifies the received Message Authentication Code, and
	case of successful verification, the EAP server computes a Message		consistency of the identities, nonces, and ciphersuite parameters
	Authentication Code over the session parameter and returns it to the		transmitted in GPSK-1. In case of successful verification, the EAP
	peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server		server computes a Message Authentication Code over the session
	have the possibility to exchange encrypted protected data parameters.		parameter and returns it to the peer (within GPSK-3). Within GPSK-2
			and GPSK-3, peer and EAP server have the possibility to exchange
			encrypted protected data parameters.
	The peer verifies the received Message Authentication Code. If the		The peer verifies the received Message Authentication Code, and
	verification is successful, GPSK-4 is prepared. This message can		consistency of the identities, nonces, and ciphersuite parameters
	optionally contain the peer's protected data parameters.		transmitted in GPSK-2. If the verification is successful, GPSK-4 is
			prepared. This message can optionally contain the peer's protected
			data parameters.
	Upon receipt of GPSK-4, the server processes any included		Upon receipt of GPSK-4, the server processes any included
	PD_Payload_Block. Then, the EAP server sends an EAP Success message		PD_Payload_Block. Then, the EAP server sends an EAP Success message
	to indicate the successful outcome of the authentication.		to indicate the successful outcome of the authentication.
	4. Key Derivation		4. Key Derivation
	EAP-GPSK provides key derivation in compliance to the requirements of		EAP-GPSK provides key derivation in compliance to the requirements of
	[RFC3748] and [RFC5247]. Note that this section provides an abstract		[RFC3748] and [RFC5247]. Note that this section provides an abstract
	description for the key derivation procedure that needs to be		description for the key derivation procedure that needs to be
	instantiated with a specific ciphersuite.		instantiated with a specific ciphersuite.
	The long-term credential shared between EAP peer and EAP server		The long-term credential shared between EAP peer and EAP server
	SHOULD be a strong pre-shared key PSK of at least 16 octets, though		SHOULD be a strong pre-shared key PSK of at least 16 octets, though
	its length and entropy is variable. While it is possible to use a		its length and entropy is variable. While it is possible to use a
	password or passphrase, doing so is NOT RECOMMENDED as it would make		password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is
	EAP-GPSK vulnerable to dictionary attacks.		vulnerable to dictionary attacks.
	During an EAP-GPSK authentication, a Master Key MK, a Session Key SK		During an EAP-GPSK authentication, a Master Key MK, a Session Key SK
	and a Protected Data Encryption Key PK (if using an encrypting		and a Protected Data Encryption Key PK (if using an encrypting
	ciphersuite) are derived using the ciphersuite-specified KDF and data		ciphersuite) are derived using the ciphersuite-specified KDF and data
	exchanged during the execution of the protocol, namely 'RAND_Peer ||		exchanged during the execution of the protocol, namely 'RAND_Peer ||
	ID_Peer || RAND_Server || ID_Server' referred as inputString as its		ID_Peer || RAND_Server || ID_Server' referred as inputString as its
	short-hand form.		short-hand form.
	In case of successful completion, EAP-GPSK derives and exports an MSK		In case of successful completion, EAP-GPSK derives and exports an MSK
	and EMSK both in length of 64 octets.		and EMSK both in length of 64 octets.
	skipping to change at page 10, line 27 ¶		skipping to change at page 10, line 32 ¶
	o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server		o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
	o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel ||		o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel ||
	inputString)[0..KS-1]		inputString)[0..KS-1]
	o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]		o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
	o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]		o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
	o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]		o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
	o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using		o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using
	an encrypting ciphersuite)		an encrypting ciphersuite)
	The value for PL is encoded as a 2-octet integer in network byte		The value for PL (the length of the PSK in octets) is encoded as a
	order.		2-octet integer in network byte order. Recall that KS is the length
			of the ciphersuite input key size in octets.
	Additionally, the EAP keying framework [RFC5247] requires the		Additionally, the EAP keying framework [RFC5247] requires the
	definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These		definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These
	values are defined as:		values are defined as:
	o zero = 0x00 || 0x00 || ... || 0x00 (KS times)		o Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type ||
	o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type ||
	CSuite_Sel || inputString)[0..15]		CSuite_Sel || inputString)[0..15]
	o Session-ID = Type_Code || Method_ID		o Session-ID = EAP_Method_Type || Method_ID
	o Peer-ID = ID_Peer		o Peer-ID = ID_Peer
	o Server-ID = ID_Server		o Server-ID = ID_Server
	EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code		EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code
	value.		value.
	Figure 2 depicts the key derivation procedure of EAP-GPSK.		Figure 2 depicts the key derivation procedure of EAP-GPSK.
	+-------------+ +-------------------------------+		+-------------+ +-------------------------------+
	| PL-octet | | RAND_Peer || ID_Peer || |		| PL-octet | | RAND_Peer || ID_Peer || |
	skipping to change at page 12, line 22 ¶		skipping to change at page 12, line 22 ¶
	Specifier column in Figure 3 uniquely identifies a ciphersuite.		Specifier column in Figure 3 uniquely identifies a ciphersuite.
	For a vendor-specific ciphersuite the first four octets are the		For a vendor-specific ciphersuite the first four octets are the
	vendor-specific enterprise number contains the IANA assigned "SMI		vendor-specific enterprise number contains the IANA assigned "SMI
	Network Management Private Enterprise Codes" value (see [ENTNUM]),		Network Management Private Enterprise Codes" value (see [ENTNUM]),
	encoded in network byte order. The last two octets are vendor		encoded in network byte order. The last two octets are vendor
	assigned for the specific ciphersuite. A vendor code of 0x00000000		assigned for the specific ciphersuite. A vendor code of 0x00000000
	indicates ciphersuites standardized by IETF in an IANA-maintained		indicates ciphersuites standardized by IETF in an IANA-maintained
	registry.		registry.
	The following ciphersuites are specified in this document:		The following ciphersuites are specified in this document (recall
			that KS is the length of the ciphersuite input key length in octets,
			and ML is the length of the MAC output in octets):
	+------------+----+-------------+----+--------------+----------------+		+-----------+----+-------------+----+--------------+----------------+
	| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |		| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
	| Specifier | | | | KDF MAC | Function |		| Specifier | | | | KDF MAC | Function |
	+------------+----+-------------+----+--------------+----------------+		+-----------+----+-------------+----+--------------+----------------+
	| 0x00000001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |		| 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
	+------------+----+-------------+----+--------------+----------------+		+-----------+----+-------------+----+--------------+----------------+
	| 0x00000002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |		| 0x0002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF |
	+------------+----+-------------+----+--------------+----------------+		+-----------+----+-------------+----+--------------+----------------+
	Figure 3: Ciphersuites		Figure 3: Ciphersuites
	Ciphersuite 1, which is based on AES as a cryptographic primitive,		Ciphersuite 1, which is based on AES as a cryptographic primitive,
	MUST be implemented. This document specifies also a second		MUST be implemented. This document specifies also a second
	ciphersuite, which MAY be implemented. Both ciphersuites defined in		ciphersuite, which MAY be implemented. Both ciphersuites defined in
	this document make use of the GKDF, as defined in Section 7. The		this document make use of the GKDF, as defined in Section 7. The
	following aspects need to be considered to ensure that the PSK that		following aspects need to be considered to ensure that the PSK that
	is used as input to the GKDF is sufficiently long (in case it is		is used as input to the GKDF is sufficiently long (in case it is
	longer it needs to be truncated):		longer it needs to be truncated):
	skipping to change at page 15, line 38 ¶		skipping to change at page 15, line 41 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4		Figure 4
	The Code, Identifier, Length, and Type fields are all part of the EAP		The Code, Identifier, Length, and Type fields are all part of the EAP
	header, and defined in [RFC3748]. The Type field in the EAP header		header, and defined in [RFC3748]. The Type field in the EAP header
	MUST be the value allocated by IANA for EAP-GPSK.		MUST be the value allocated by IANA for EAP-GPSK.
	The OP-Code field is one of four values:		The OP-Code field is one of four values:
			o 0x00 : Reserved
	o 0x01 : GPSK-1		o 0x01 : GPSK-1
	o 0x02 : GPSK-2		o 0x02 : GPSK-2
	o 0x03 : GPSK-3		o 0x03 : GPSK-3
	o 0x04 : GPSK-4		o 0x04 : GPSK-4
	o 0x05 : GPSK-Fail		o 0x05 : GPSK-Fail
	o 0x06 : GPSK-Protected-Fail		o 0x06 : GPSK-Protected-Fail
	All other values of this OP-Code field are available via IANA		All other values of this OP-Code field are available via IANA
	registration.		registration.
	skipping to change at page 21, line 20 ¶		skipping to change at page 21, line 20 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	... ML-octet payload MAC ...		... ML-octet payload MAC ...
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: GPSK-Protected-Fail Payload		Figure 11: GPSK-Protected-Fail Payload
	The Failure-Code field is one of three values, but can be extended:		The Failure-Code field is one of three values, but can be extended:
	o 0x00000001: PSK Not Found		o 0x00000000 : Reserved
	o 0x00000002: Authentication Failure		o 0x00000001 : PSK Not Found
	o 0x00000003: Authorization Failure		o 0x00000002 : Authentication Failure
			o 0x00000003 : Authorization Failure
	All other values of this field are available via IANA registration.		All other values of this field are available via IANA registration.
	"PSK Not Found" indicates a key for a particular user could not be		"PSK Not Found" indicates a key for a particular user could not be
	located, making authentication impossible. "Authentication Failure"		located, making authentication impossible. "Authentication Failure"
	indicates a MAC failure due to a PSK mismatch. "Authorization		indicates a MAC failure due to a PSK mismatch. "Authorization
	Failure" indicates that while the PSK being used is correct, the user		Failure" indicates that while the PSK being used is correct, the user
	is not authorized to connect.		is not authorized to connect.
	9.4. Protected Data		9.4. Protected Data
	skipping to change at page 25, line 13 ¶		skipping to change at page 25, line 13 ¶
	Failure" and discard the received packet.		Failure" and discard the received packet.
	A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in		A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in
	response to a GPSK-2 message MUST replay the received GPSK-Fail /		response to a GPSK-2 message MUST replay the received GPSK-Fail /
	GPSK-Protected-Fail message. Then, the EAP server returns an EAP-		GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
	Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message		Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
	to correctly finish the EAP conversation. If MAC validation on a		to correctly finish the EAP conversation. If MAC validation on a
	GPSK-Protected-Fail packet fails, then the received packet MUST be		GPSK-Protected-Fail packet fails, then the received packet MUST be
	silently discarded.		silently discarded.
	For GPSK-3, a peer MUST silently discard messages where the RAND_Peer		For GPSK-3, a peer MUST silently discard messages where the
	or the CSuite_Sel fields do not match those transmitted in GPSK-2.		RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those
	An EAP peer MUST silently discard any packet whose MAC fails.		transmitted in GPSK-2. An EAP peer MUST silently discard any packet
			whose MAC fails.
	For GPSK-4, a server MUST silently discard any packet whose MAC fails		For GPSK-4, a server MUST silently discard any packet whose MAC fails
	validation.		validation.
	If a decryption failure of a protected payload is detected, the		If a decryption failure of a protected payload is detected, the
	recipient MUST silently discard the GPSK packet.		recipient MUST silently discard the GPSK packet.
	11. Example Message Exchanges		11. Example Message Exchanges
	This section shows a couple of example message flows.		This section shows a couple of example message flows.
	skipping to change at page 30, line 25 ¶		skipping to change at page 30, line 25 ¶
	RAND_Server is 32 octets long, one expects to have to record 2**64		RAND_Server is 32 octets long, one expects to have to record 2**64
	(i.e., approximately 1.84*10**19) EAP-GPSK successful authentication		(i.e., approximately 1.84*10**19) EAP-GPSK successful authentication
	before an protocol run can be replayed. Hence, EAP-GPSK provides		before an protocol run can be replayed. Hence, EAP-GPSK provides
	replay protection of its mutual authentication part as long as		replay protection of its mutual authentication part as long as
	RAND_Server and RAND_Peer are chosen at random, randomness is		RAND_Server and RAND_Peer are chosen at random, randomness is
	critical for replay protection. RFC 4086 [RFC4086] describes		critical for replay protection. RFC 4086 [RFC4086] describes
	techniques for producing random quantities.		techniques for producing random quantities.
	12.6. Reflection attacks		12.6. Reflection attacks
	EAP-GPSK provides protection against reflection attacks in case of an		Reflection attacks occur in bi-directional, challenge-response,
	extended authentication because the messages are constructed in a		mutual authentication protocols where an attacker, upon being issued
	different fashion.		a challenge by an authenticator responds by issuing the same
			challenge back to the authenticator, obtaining the response, and then
			"reflecting" that same response to the original challenge.
			EAP-GPSK provides protection against reflection attacks because the
			message formats for the challenges differ. The protocol does not
			consist of two independent authentications, but rather the
			authentications are tightly coupled.
	Also note that EAP-GPSK does not provide MAC protection of the OP-		Also note that EAP-GPSK does not provide MAC protection of the OP-
	Code field, but again since each message is constructed differently,		Code field, but again since each message is constructed differently,
	it would not be possible to change the OP-Code of a valid message and		it would not be possible to change the OP-Code of a valid message and
	still have it be parseable and accepted by the recipient.		still have it be parseable and accepted by the recipient.
	12.7. Dictionary Attacks		12.7. Dictionary Attacks
	EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be		EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be
	based on at least 16 octets of entropy to be fully secure. The EAP-		based on at least 16 octets of entropy to be fully secure. The EAP-
	skipping to change at page 34, line 49 ¶		skipping to change at page 34, line 49 ¶
	o 0x0000 : Reserved		o 0x0000 : Reserved
	The PData/Specifier field is 16 bits long and all other values are		The PData/Specifier field is 16 bits long and all other values are
	available via IANA registration. Each extension needs to indicate		available via IANA registration. Each extension needs to indicate
	whether confidentiality protection for transmission between the EAP		whether confidentiality protection for transmission between the EAP
	peer and the EAP server is mandatory.		peer and the EAP server is mandatory.
	The following layout represents the initial Failure-Code registry		The following layout represents the initial Failure-Code registry
	setup, which should be named "EAP-GPSK Failure Codes":		setup, which should be named "EAP-GPSK Failure Codes":
	o 0x00000001: PSK Not Found		o 0x00000000 : Reserved
	o 0x00000002: Authentication Failure		o 0x00000001 : PSK Not Found
	o 0x00000003: Authorization Failure		o 0x00000002 : Authentication Failure
			o 0x00000003 : Authorization Failure
	The Failure-Code field is 32 bits long and all other values are		The Failure-Code field is 32 bits long and all other values are
	available via IANA registration.		available via IANA registration.
	The following layout represents the initial OP-Code registry setup,		The following layout represents the initial OP-Code registry setup,
	which should be named "EAP-GPSK OP Codes":		which should be named "EAP-GPSK OP Codes":
			o 0x00 : Reserved
	o 0x01 : GPSK-1		o 0x01 : GPSK-1
	o 0x02 : GPSK-2		o 0x02 : GPSK-2
	o 0x03 : GPSK-3		o 0x03 : GPSK-3
	o 0x04 : GPSK-4		o 0x04 : GPSK-4
	o 0x05 : GPSK-Fail		o 0x05 : GPSK-Fail
	o 0x06 : GPSK-Protected-Fail		o 0x06 : GPSK-Protected-Fail
	The OP-Code field is 8 bits long and all other values are available		The OP-Code field is 8 bits long and all other values are available
	via IANA registration.		via IANA registration.
	skipping to change at page 37, line 40 ¶		skipping to change at page 37, line 40 ¶
	[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible		[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
	Authentication Protocol (EAP) Method Requirements for		Authentication Protocol (EAP) Method Requirements for
	Wireless LANs", RFC 4017, March 2005.		Wireless LANs", RFC 4017, March 2005.
	[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness		[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
	Requirements for Security", BCP 106, RFC 4086, June 2005.		Requirements for Security", BCP 106, RFC 4086, June 2005.
	[ENTNUM] IANA, "SMI Network Management Private Enterprise Codes",		[ENTNUM] IANA, "SMI Network Management Private Enterprise Codes",
	IANA Assignments enterprise-numbers.		IANA Assignments enterprise-numbers.
			[80211] "Information technology - Telecommunications and
			Information Exchange Between Systems - Local and
			Metropolitan Area Networks - Specific Requirements - Part
			11: Wireless LAN Medium Access Control (MAC) and Physical
			Layer (PHY) Specifications", IEEE Standard 802.11-2007,
			March 2007.
	Authors' Addresses		Authors' Addresses
	T. Charles Clancy		T. Charles Clancy
	DoD Laboratory for Telecommunications Sciences		DoD Laboratory for Telecommunications Sciences
	8080 Greenmead Drive		8080 Greenmead Drive
	College Park, MD 20740		College Park, MD 20740
	USA		USA
	Email: clancy@ltsnet.net		Email: clancy@ltsnet.net
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2008).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 28 change blocks.
	50 lines changed or deleted		77 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/