draft-ietf-emu-eap-gpsk-06.txt   draft-ietf-emu-eap-gpsk-07.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: January 7, 2008 Nokia Siemens Networks Expires: May 22, 2008 Nokia Siemens Networks
July 6, 2007 November 19, 2007
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-ietf-emu-eap-gpsk-06 draft-ietf-emu-eap-gpsk-07
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 January 7, 2008. This Internet-Draft will expire on May 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This Internet Draft defines an Extensible Authentication Protocol This Internet Draft defines an Extensible Authentication Protocol
method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method
is a lightweight shared-key authentication protocol supporting mutual is a lightweight shared-key authentication protocol supporting mutual
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 6. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 12
6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12
6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13
6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12
7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12
7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 7.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 7.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20 7.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13
7.4.1. Protected Results Indication . . . . . . . . . . . . . 23 7.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13
7.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
7.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
7.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23 8. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15
8.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
8.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20
8.4.1. Protected Results Indication . . . . . . . . . . . . . 23
9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24 9. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24
10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27
10.2. Protected Result Indications . . . . . . . . . . . . . . 28
10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28
10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28
10.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 28
10.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 28
10.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 28
10.8. Denial of Service Resistance . . . . . . . . . . . . . . 28
10.9. Session Independence . . . . . . . . . . . . . . . . . . 29
10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 29
10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30
10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30
10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30
10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30
10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30
10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27
11.2. Protected Result Indications . . . . . . . . . . . . . . 28
11.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28
11.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28
11.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 28
11.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 28
11.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 29
11.8. Denial of Service Resistance . . . . . . . . . . . . . . 29
11.9. Session Independence . . . . . . . . . . . . . . . . . . 29
11.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 30
11.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30
11.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
11.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30
11.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30
11.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30
11.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
11.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 31
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 35 15.1. Normative References . . . . . . . . . . . . . . . . . . 34
15.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
generalized pre-shared key authentication technique. Mutual generalized pre-shared key authentication technique. Mutual
authentication is achieved through a nonce-based exchange that is authentication is achieved through a nonce-based exchange that is
secured by a pre-shared key. secured by a pre-shared key.
EAP-GPSK addresses a large number of design goals with the intention EAP-GPSK addresses a large number of design goals with the intention
of being applicable in a broad range of usage scenarios. of being applicable in a broad range of usage scenarios.
skipping to change at page 4, line 40 skipping to change at page 4, line 40
relies of symmetric cryptography. The restriction on symmetric relies of symmetric cryptography. The restriction on symmetric
cryptographic computations allows for low computational overhead. cryptographic computations allows for low computational overhead.
Hence, EAP-GPSK is lightweight and well suited for any type of Hence, EAP-GPSK is lightweight and well suited for any type of
device, especially those with processing power, memory and battery device, especially those with processing power, memory and battery
constraints. Additionally it seeks to minimize the number of constraints. Additionally it seeks to minimize the number of
round trips. round trips.
Flexibility: Flexibility:
EAP-GPSK offers cryptographic flexibility. At the beginning, the EAP-GPSK offers cryptographic flexibility. At the beginning, the
EAP server selects a set of cryptographic algorithms and key EAP server proposes a list of ciphersuites. The client then
sizes, a so called ciphersuite. The current version of EAP-GPSK selects one. The current version of EAP-GPSK comprises two
comprises two ciphersuites, but additional ones can be easily ciphersuites, but additional ones can be easily added.
added.
Extensibility: Extensibility:
The design of EAP-GPSK allows to securely exchange information The design of EAP-GPSK allows to securely exchange information
between the EAP peer and the EAP server using protected data between the EAP peer and the EAP server using protected data
fields. These fields might, for example, be used to exchange fields. These fields might, for example, be used to exchange
channel binding information or to provide support for identity channel binding information or to provide support for identity
confidentiality. confidentiality.
2. Terminology 2. Terminology
skipping to change at page 8, line 16 skipping to change at page 8, line 16
ID_Server, RAND_Server, CSuite_List ID_Server, RAND_Server, CSuite_List
GPSK-2: GPSK-2:
SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List, SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List,
CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
GPSK-3: GPSK-3:
SEC_SK(RAND_Peer, RAND_Server, CSuite_Sel, [ SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [
ENC_PK(PD_Payload_Block) ] ) ENC_PK(PD_Payload_Block) ] )
GPSK-4: GPSK-4:
SEC_SK( [ ENC_PK(PD_Payload_Block) ] ) SEC_SK( [ ENC_PK(PD_Payload_Block) ] )
The EAP server begins EAP-GPSK by selecting a random number The EAP server begins EAP-GPSK by selecting a random number
RAND_Server and by encoding the supported ciphersuites into RAND_Server and by encoding the supported ciphersuites into
CSuite_List. A ciphersuite consists of an encryption algorithm, a CSuite_List. A ciphersuite consists of an encryption algorithm, a
key derivation function and a message authentication code. key derivation function and a message authentication code.
skipping to change at page 11, line 35 skipping to change at page 11, line 35
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
Figure 3: Ciphersuites Figure 3: Ciphersuites
Ciphersuite 1, which is based on AES as a cryptographic primitive, is Ciphersuite 1, which is based on AES as a cryptographic primitive, is
mandatory to implement. This document specifies also a second mandatory to implement. This document specifies also a second
ciphersuite, but its support is optional. ciphersuite, but its support is optional. Both ciphersuites defined
in this document make use of the GKDF, as defined in Section 6. The
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
longer it needs to be truncated):
1. The PSK used with ciphersuite 1 MUST be 128 bits in length or
longer.
2. The PSK used with ciphersuite 2 MUST be 256 bits in length or
longer.
3. It is RECOMMENDED that 256 bit keys be provisioned in all cases
to provide enough entropy for all current and many possible
future ciphersuites.
Ciphersuites defined in the future that make use of the GKDF need to
specify a minimum PSK size (as it is done with the ciphersuites
listed in this document).
6. Generalized Key Derivation Function (GKDF)
Each ciphersuite needs to specify a key derivation function. The Each ciphersuite needs to specify a key derivation function. The
ciphersuites defined in this document make use of the Generalized Key ciphersuites defined in this document make use of the Generalized Key
Distribution Function (GKDF) which utilizes the MAC function defined Derivation Function (GKDF) that utilizes the MAC function defined in
in the ciphersuite. Future ciphersuites can use any other formally the ciphersuite. Future ciphersuites can use any other formally
specified KDF that takes as arguments a key and a seed value, and specified KDF that takes as arguments a key and a seed value, and
produces at least 128+2*KS octets of output. produces at least 128+2*KS octets of output.
GKDF has the following structure: GKDF has the following structure:
GKDF-X(Y, Z) GKDF-X(Y, Z)
X length, in octets, of the desired output X length, in octets, of the desired output
Y secret key Y secret key
Z inputString Z inputString
GKDF-X (Y, Z) GKDF-X (Y, Z)
{ {
n = ceiling integer of ( X / KS ); n = ceiling integer of ( X / KS );
/* determine number of output blocks */ /* determine number of output blocks */
M_0 = ""; M_0 = "";
skipping to change at page 12, line 27 skipping to change at page 12, line 41
M_i = MAC_Y (i || Z); M_i = MAC_Y (i || Z);
result = result || M_i; result = result || M_i;
} }
return truncate(result, X) return truncate(result, X)
} }
Note that the variable 'i' in M_i is represented as a 2-octet value Note that the variable 'i' in M_i is represented as a 2-octet value
in network byte order. in network byte order.
6. Ciphersuites Processing Rules 7. Ciphersuites Processing Rules
6.1. Ciphersuite #1 7.1. Ciphersuite #1
6.1.1. Encryption 7.1.1. Encryption
With this ciphersuite all cryptography is built around a single With this ciphersuite all cryptography is built around a single
cryptographic primitive, AES-128 ([AES]). Within the protected data cryptographic primitive, AES-128 ([AES]). Within the protected data
frames, AES-128 is used in Cipher Block Chaining (CBC) mode of frames, AES-128 is used in Cipher Block Chaining (CBC) mode of
operation (see [CBC]). This EAP method uses encryption in a single operation (see [CBC]). This EAP method uses encryption in a single
payload, in the protected data payload (see Section 7.4). payload, in the protected data payload (see Section 8.4).
In a nutshell, the CBC mode proceeds as follows. The IV is XORed In a nutshell, the CBC mode proceeds as follows. The IV is XORed
with the first plaintext block before it is encrypted. Then for with the first plaintext block before it is encrypted. Then for
successive blocks, the previous ciphertext block is XORed with the successive blocks, the previous ciphertext block is XORed with the
current plaintext, before it is encrypted. current plaintext, before it is encrypted.
6.1.2. Integrity 7.1.2. Integrity
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is
recommended by NIST. Among its advantages, CMAC is capable to work recommended by NIST. Among its advantages, CMAC is capable to work
with messages of arbitrary length. A detailed description of CMAC with messages of arbitrary length. A detailed description of CMAC
can be found in [CMAC]. can be found in [CMAC].
The following instantiation is used: AES-CMAC-128(SK, Input) denotes The following instantiation is used: AES-CMAC-128(SK, Input) denotes
the MAC of Input under the key SK. the MAC of Input under the key SK.
where Input refers to the following content: where Input refers to the following content:
o Value of SEC_SK(Value) in message GPSK-2 o Value of SEC_SK(Value) in message GPSK-2
o Value of SEC_SK(Value) in message GPSK-3 o Value of SEC_SK(Value) in message GPSK-3
o Value of SEC_SK(Value) in message GPSK-4 o Value of SEC_SK(Value) in message GPSK-4
6.1.3. Key Derivation 7.1.3. Key Derivation
This ciphersuite instantiates the KDF in the following way: This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
zero = 0x00 || 0x00 || ... || 0x00 (16 times) MK = GKDF-16 (PSK[0..127], PL || PSK || CSuite_Sel || inputString)
MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-160 (MK, inputString)[0..63] MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-160 (MK, inputString)[64..127] EMSK = GKDF-160 (MK, inputString)[64..127]
SK = GKDF-160 (MK, inputString)[128..143] SK = GKDF-160 (MK, inputString)[128..143]
PK = GKDF-160 (MK, inputString)[144..159] PK = GKDF-160 (MK, inputString)[144..159]
Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString) CSuite_Sel || inputString)
6.2. Ciphersuite #2 7.2. Ciphersuite #2
6.2.1. Encryption 7.2.1. Encryption
Ciphersuite 2 does not include an algorithm for encryption. With a Ciphersuite 2 does not include an algorithm for encryption. With a
NULL encryption algorithm, encryption is defined as: NULL encryption algorithm, encryption is defined as:
E_X(Y) = Y E_X(Y) = Y
When using this ciphersuite, the data exchanged inside the protected When using this ciphersuite, the data exchanged inside the protected
data block is not encrypted. Therefore this mode MUST NOT be used if data block is not encrypted. Therefore this mode MUST NOT be used if
confidential information appears inside the protected data block. confidential information appears inside the protected data block.
6.2.2. Integrity 7.2.2. Integrity
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash
algorithm (see [RFC4634]). algorithm (see [RFC4634]).
For integrity protection the following instantiation is used: For integrity protection the following instantiation is used:
HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK
where Input refers to the following content: where Input refers to the following content:
o Value of SEC_SK(Value) in message GPSK-2 o Value of SEC_SK(Value) in message GPSK-2
o Value of SEC_SK(Value) in message GPSK-3 o Value of SEC_SK(Value) in message GPSK-3
o Value of SEC_SK(Value) in message GPSK-4 o Value of SEC_SK(Value) in message GPSK-4
6.2.3. Key Derivation 7.2.3. Key Derivation
This ciphersuite instantiates the KDF in the following way: This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
zero = 0x00 || 0x00 || ... || 0x00 (32 times) MK = GKDF-32 (PSK[0..255], PL || PSK || CSuite_Sel || inputString)
MK = GKDF-32 (zero, PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-160 (MK, inputString)[0..63] MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-160 (MK, inputString)[64..127] EMSK = GKDF-160 (MK, inputString)[64..127]
SK = GKDF-160 (MK, inputString)[128..159] SK = GKDF-160 (MK, inputString)[128..159]
Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString) CSuite_Sel || inputString)
7. Packet Formats 8. Packet Formats
This section defines the packet format of the EAP-GPSK messages. This section defines the packet format of the EAP-GPSK messages.
7.1. Header Format 8.1. Header Format
The EAP-GPSK header has the following structure: The EAP-GPSK header has the following structure:
--- bit offset ---> --- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | | | Type | OP-Code | |
skipping to change at page 15, line 35 skipping to change at page 15, line 39
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.
7.2. Ciphersuite Formatting 8.2. Ciphersuite Formatting
Ciphersuites are encoded as 6-octet arrays. The first four octets Ciphersuites are encoded as 6-octet arrays. The first four octets
indicate the CSuite/Vendor field. For vendor-specific ciphersuites, indicate the CSuite/Vendor field. For vendor-specific ciphersuites,
this represents the vendor Object Identifier (OID) contains the IANA this represents the vendor Object Identifier (OID) contains the IANA
assigned "SMI Network Management Private Enterprise Codes" value (see assigned "SMI Network Management Private Enterprise Codes" value (see
[RFC3232]), encoded in network byte order. The last two octets [RFC3232]), encoded in network byte order. The last two octets
indicate the CSuite/Specifier field, which identifies the particular indicate the CSuite/Specifier field, which identifies the particular
ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates
ciphersuites allocated by the IETF. ciphersuites allocated by the IETF.
skipping to change at page 16, line 22 skipping to change at page 16, line 22
Figure 6 Figure 6
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and
CSuite/Specifier pair. CSuite/Specifier pair.
CSuite_List is a variable-length octet array of ciphersuites. It is CSuite_List is a variable-length octet array of ciphersuites. It is
encoded by concatenating encoded ciphersuite values. Its length in encoded by concatenating encoded ciphersuite values. Its length in
octets MUST be a multiple of 6. octets MUST be a multiple of 6.
7.3. Payload Formatting 8.3. Payload Formatting
Payload formatting is based on the protocol exchange description in Payload formatting is based on the protocol exchange description in
Section 3. Section 3.
The GPSK-1 payload format is defined as follows: The GPSK-1 payload format is defined as follows:
--- bit offset ---> --- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 21 skipping to change at page 18, line 21
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Peer ... ... 32-octet RAND_Peer ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Server ... ... 32-octet RAND_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
... ID_Server ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
skipping to change at page 20, line 19 skipping to change at page 20, line 19
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization 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.
7.4. Protected Data 8.4. Protected Data
The protected data blocks are a generic mechanism for the peer and The protected data blocks are a generic mechanism for the peer and
server to securely exchange data. If the specified ciphersuite has a server to securely exchange data. If the specified ciphersuite has a
NULL encryption primitive, then this channel only offers NULL encryption primitive, then this channel only offers
authenticity, and not confidentiality. authenticity, and not confidentiality.
These payloads are encoded as the concatenation of type-length-value These payloads are encoded as the concatenation of type-length-value
(TLV) triples called PD_Payloads. (TLV) triples called PD_Payloads.
Type values are encoded as a 6-octet string and represented by a Type values are encoded as a 6-octet string and represented by a
4-octet vendor and 2-octet specifier field. The vendor field 4-octet vendor and 2-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If these three octets are 0x00000000, then the value is standards- If these four octets are 0x00000000, then the value is standards-
specified, and any other value represents a vendor-specific Object specified, and any other value represents a vendor-specific Object
Identifier (OID). Identifier (OID).
The specifier field indicates the actual type. For vendor field The specifier field indicates the actual type. For vendor field
0x00000000, the specifier field is maintained by IANA. For any other 0x00000000, the specifier field is maintained by IANA. For any other
vendor field, the specifier field is maintained by the vendor. vendor field, the specifier field is maintained by the vendor.
Length fields are specified as 2-octet integers in network byte Length fields are specified as 2-octet integers in network byte
order, and reflect only the length of the value, and do not include order, and reflect only the length of the value, and do not include
the length of the type and length fields. the length of the type and length fields.
skipping to change at page 23, line 9 skipping to change at page 23, line 9
Protected Data Block (PD_Payload_Block) Formatting Without Encryption Protected Data Block (PD_Payload_Block) Formatting Without Encryption
For PData/Vendor field 0x000000, the following PData/Specifier fields For PData/Vendor field 0x000000, the following PData/Specifier fields
are defined: are defined:
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication o 0x000001 : Protected Results Indication
All other values of this field are available via IANA registration. All other values of this field are available via IANA registration.
7.4.1. Protected Results Indication 8.4.1. Protected Results Indication
Based on the PData/Specifier allocation the following 8-bit payload Based on the PData/Specifier allocation the following 8-bit payload
is specified to be placed in the PD_Payload Value to provide the is specified to be placed in the PD_Payload Value to provide the
functionality of protected results indication. functionality of protected results indication.
0 0
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|I|R|R|R|R|R|R|R| |I|R|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 23, line 31 skipping to change at page 23, line 31
I: Result Indicator I: Result Indicator
The bits have the following meaning: The bits have the following meaning:
(0): Success (0): Success
(1): Failure (1): Failure
R: Reserved R: Reserved
These bits are used for padding. These bits are used for padding.
The 8 bits of protected results indication functionality MUST only be The 8 bits of protected results indication functionality, which does
sent in GPSK-3 from the EAP server to the EAP peer. not require confidentiality protection, MUST only be sent in GPSK-3
from the EAP server to the EAP peer.
8. Packet Processing Rules 9. Packet Processing Rules
This section defines how the EAP peer and EAP server MUST behave when This section defines how the EAP peer and EAP server MUST behave when
received packet is deemed invalid. received packet is deemed invalid.
Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP
server MUST be silently discarded. An EAP peer or EAP server server MUST be silently discarded. An EAP peer or EAP server
receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3
before receiving GPSK-1 or before transmitting GPSK-2) MUST silently before receiving GPSK-1 or before transmitting GPSK-2) MUST silently
discard the packet. discard the packet.
skipping to change at page 24, line 38 skipping to change at page 24, line 39
RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those
transmitted in GPSK-2. An EAP peer MUST silently discard any packet transmitted in GPSK-2. An EAP peer MUST silently discard any packet
whose MAC fails. 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.
9. Example Message Exchanges 10. Example Message Exchanges
This section shows a couple of example message flows. This section shows a couple of example message flows.
A successful EAP-GPSK message exchange is shown in Figure 1. A successful EAP-GPSK message exchange is shown in Figure 1.
+--------+ +--------+ +--------+ +--------+
| | EAP-Request/Identity | | | | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP | | EAP |<------------------------------------| EAP |
| peer | | server | | peer | | server |
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
skipping to change at page 27, line 33 skipping to change at page 27, line 33
| | GPSK-Protected-Fail | | | | GPSK-Protected-Fail | |
| | (Authorization Failure) | | | | (Authorization Failure) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Authorization failure) EAP-GPSK: Unsuccessful Exchange (Authorization failure)
10. Security Considerations 11. Security Considerations
[RFC3748] highlights several attacks that are possible against EAP [RFC3748] highlights several attacks that are possible against EAP
since EAP itself does not provide any security. since EAP itself does not provide any security.
This section discusses the claimed security properties of EAP-GPSK as This section discusses the claimed security properties of EAP-GPSK as
well as vulnerabilities and security recommendations in the threat well as vulnerabilities and security recommendations in the threat
model of [RFC3748]. model of [RFC3748].
10.1. Mutual Authentication 11.1. Mutual Authentication
EAP-GPSK provides mutual authentication. EAP-GPSK provides mutual authentication.
The server believes that the peer is authentic because it can The server believes that the peer is authentic when it successfully
calculate a valid MAC and the peer believes that the server is verifies the MAC in the GPSK-2 message and the peer believes that the
authentic because it can calculate another valid MAC. server is authentic when it successfully verifies the MAC it receives
with the GPSK-3 message.
The key used for mutual authentication is computed again based on the The key used for mutual authentication is derived based on the long-
long-term secret PSK that has to provide sufficient entropy and term secret PSK, nonces contributed by both parties and other
therefore sufficient strength. In this way EAP-GPSK is not different parameters. The long-term secret PSK has to provide sufficient
than other authentication protocols based on pre-shared keys. entropy and therefore sufficient strength. The nonces (RAND_Peer and
RAND_Server) need to be fresh and unique for every session. In this
way EAP-GPSK is not different than other authentication protocols
based on pre-shared keys.
10.2. Protected Result Indications 11.2. Protected Result Indications
EAP-GPSK offers the capability to exchange protected result EAP-GPSK offers the capability to exchange protected result
indications using the protected data payloads. indications using the protected data payloads.
10.3. Integrity Protection 11.3. Integrity Protection
EAP-GPSK provides integrity protection based on the ciphersuites EAP-GPSK provides integrity protection based on the ciphersuites
suggested in this document. suggested in this document. Integrity protection is a minimum
feature every ciphersuite must provide.
10.4. Replay Protection 11.4. Replay Protection
EAP-GPSK provides replay protection of its mutual authentication part EAP-GPSK provides replay protection of its mutual authentication part
thanks to the use of random numbers RAND_Server and RAND_Peer. Since thanks to the use of random numbers RAND_Server and RAND_Peer. Since
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. critical for replay protection. RFC 4086 [RFC4086] describes
techniques for producing random quantities.
10.5. Reflection attacks 11.5. Reflection attacks
EAP-GPSK provides protection against reflection attacks in case of an EAP-GPSK provides protection against reflection attacks in case of an
extended authentication because the messages are constructed in a extended authentication because the messages are constructed in a
different fashion. different fashion.
10.6. Dictionary Attacks 11.6. Dictionary Attacks
EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based
on at least 16 octets of entropy to guarantee security against on at least 16 octets of entropy to guarantee security against
dictionary attacks. Users who use passwords are not guaranteed dictionary attacks. Users who use passwords are not guaranteed
security against dictionary attacks. Derivation of the long-term protection against dictionary attacks. Derivation of the long-term
shared secret from a password is strongly discouraged. shared secret from a password is strongly discouraged.
10.7. Key Derivation 11.7. Key Derivation
EAP-GPSK supports key derivation as shown in Section 4. EAP-GPSK supports key derivation as shown in Section 4.
10.8. Denial of Service Resistance 11.8. Denial of Service Resistance
Denial of Service (DoS) resistance has not been a design goal for
EAP-GPSK.
It is however believed that EAP-GPSK does not provide any obvious and There are two forms of denial of service attacks relevant for this
avoidable venue for such attacks. document, namely attacks that lead to vast amount of state being
allocated and attacks against the computational resources. The
latter onces are less problematic for EAP-GPSK since all computations
are lightweight. We will consider the former one in more detail
below.
It is worth noting that the server has to maintain some state when it In an EAP-GPSK conversation the server has to maintain state, namely
engages in an EAP-GPSK conversation, namely to generate and to the 32-octet RAND_Server, when transmitting the GPSK-1 message to the
remember the 32-octet RAND_Server. This should however not lead to peer. An adversary could therefore flood a server with a large
resource exhaustion as this state and the associated computation are number of EAP-GPSK communication attempts. An EAP server may
fairly lightweight. therefore ensure that established state times out after a relatively
short period of time when no further messages are received. This
enables a sort of garbage collection.
It is recommended that EAP-GPSK does not allow EAP notifications to The client would have to potentially keep state information after
be interleaved in its dialog to prevent potential DoS attacks. receiving the GPSK-1 message. Section 4.2 of [HM2004] describes a
Indeed, since EAP Notifications are not integrity protected, they can short of client-side denial of service attack and illustrates three
easily be spoofed by an attacker. Such an attacker could force a possible solutions to avoid having the client to keep state when
peer that allows EAP Notifications to engage in a discussion which receiving the first message. When the client receives the GPSK-3
would delay his authentication or result in the peer taking message then it needs to derive keying material based on the
unexpected actions (e.g., in case a notification is used to prompt following information: RAND_Peer, ID_Peer, RAND_Server, ID_Server,
the peer to do some "bad" action). RAND_Peer, RAND_Server. Hence, GPSK-3 includes all necessary
parameters to allow the client to (a) avoid allocating state
information with the arrival of GPSK-1 and (b) to enable deriving the
keying material.
It is up to the implementation of EAP-GPSK or to the peer and the The security considerations of EAP itself, see Section 5.2 and
server to specify the maximum number of failed cryptographic checks Section 7 of RFC 3748 [RFC3748], are also applicable to this
that are allowed. specification (e.g., for example concerning EAP-based notifications).
10.9. Session Independence 11.9. Session Independence
Thanks to its key derivation mechanisms, EAP-GPSK provides session Thanks to its key derivation mechanisms, EAP-GPSK provides session
independence: passive attacks (such as capture of the EAP independence: passive attacks (such as capture of the EAP
conversation) or active attacks (including compromise of the MSK or conversation) or active attacks (including compromise of the MSK or
EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.
The assumption that RAND_Peer and RAND_Server are random is central The assumption that RAND_Peer and RAND_Server are random is central
for the security of EAP-GPSK in general and session independence in for the security of EAP-GPSK in general and session independence in
particular. particular.
10.10. Exposition of the PSK 11.10. Exposition of the PSK
EAP-GPSK does not provide perfect forward secrecy. Compromise of the EAP-GPSK does not provide perfect forward secrecy. Compromise of the
PSK leads to compromise of recorded past sessions. PSK leads to compromise of recorded past sessions.
Compromise of the PSK enables the attacker to impersonate the peer Compromise of the PSK enables the attacker to impersonate the peer
and the server and it allows the adversary to compromise future and the server and it allows the adversary to compromise future
sessions. sessions.
EAP-GPSK provides no protection against a legitimate peer sharing its EAP-GPSK provides no protection against a legitimate peer sharing its
PSK with a third party. Such protection may be provided by PSK with a third party. Such protection may be provided by
appropriate repositories for the PSK, which choice is outside the appropriate repositories for the PSK, which choice is outside the
scope of this document. The PSK used by EAP-GPSK must only be shared scope of this document. The PSK used by EAP-GPSK must only be shared
between two parties: the peer and the server. In particular, this between two parties: the peer and the server. In particular, this
PSK must not be shared by a group of peers communicating with the PSK must not be shared by a group of peers communicating with the
same server. same server.
The PSK used by EAP-GPSK must be cryptographically separated from The PSK used by EAP-GPSK must be cryptographically separated from
keys used by other protocols, otherwise the security of EAP-GPSK may keys used by other protocols, otherwise the security of EAP-GPSK may
be compromised. be compromised.
10.11. Fragmentation 11.11. Fragmentation
EAP-GPSK does not support fragmentation and reassembly since the EAP-GPSK does not support fragmentation and reassembly since the
message size is small. message size is relatively small.
10.12. Channel Binding 11.12. Channel Binding
This document enables the ability to exchange channel binding This document enables the ability to exchange channel binding
information. It does not, however, define the encoding of channel information. It does not, however, define the encoding of channel
binding information in the document. binding information in the document.
10.13. Fast Reconnect 11.13. Fast Reconnect
EAP-GPSK does not provide the fast reconnect capability since this EAP-GPSK does not provide the fast reconnect capability since this
method is already at (or close to) the lower limit of the number of method is already at (or close to) the lower limit of the number of
roundtrips and the cryptographic operations. roundtrips and the cryptographic operations.
10.14. Identity Protection 11.14. Identity Protection
Identity protection is not specified in this document. Extensions Identity protection is not specified in this document. Extensions
can be defined that enhance this protocol to provide this feature. can be defined that enhance this protocol to provide this feature.
10.15. Protected Ciphersuite Negotiation 11.15. Protected Ciphersuite Negotiation
EAP-GPSK provides protected ciphersuite negotiation via the EAP-GPSK provides protected ciphersuite negotiation via the
indication of available ciphersuites by the server in the first indication of available ciphersuites by the server in the first
message and a confirmation by the peer in the subsequent message. message and a confirmation by the peer in the subsequent message.
10.16. Confidentiality Note, however, that the GPSK-2 message may optionally contain a
payload, ENC_PK(PD_Payload_Block), protected with an algorithm based
on a selected ciphersuite before the ciphersuite list has actually
been authenticated. In the classical downgrading attack an adversary
would chose a ciphersuite that it weak enough to that it could break
it in real-time or to turn security off. The latter is not possible
since any ciphersuite defined for EAP-GPSK must at least provide
authentication and integrity protection. Confidentity protection is
optional. When, some time in the future, a ciphersuite contains
algorithms that can be broken in real-time then a policy on peers and
the server needs to indicate that such a ciphersuite must not be
selected by any of parties.
Furthermore, an adversay may modify the selection of the ciphersuite
to for the client to select a ciphersuite that does not provide
confidentity protection. As a result this would cause the content of
PD_Payload_Block to be transmitted in cleartext. When protocol
designers extend EAP-GPSK to carry information in the
PD_Payload_Block of the GPSK-2 message then it must be indicated
whether confidentiality protection is mandatory. In case such an
extension requires a ciphersuite with confidentiality protection then
the policy at the peer must not transmit information of that
extension in the PD_Payload_Block of the GPSK-2 message. The peer
may, if possible, delay the transmission of this information element
to the GPSK-4 message where the ciphersuite negotiation has been
confirmed already. In general, when a ciphersuite is selected that
does not provide confidentiality protection then information that
demands confidentility protection must not be included in any of the
PD_Payload_Block objects.
11.16. Confidentiality
Although EAP-GPSK provides confidentiality in its protected data Although EAP-GPSK provides confidentiality in its protected data
payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748]. payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748].
10.17. Cryptographic Binding 11.17. Cryptographic Binding
Since EAP-GPSK does not tunnel another EAP method, it does not Since EAP-GPSK does not tunnel another EAP method, it does not
implement cryptographic binding. implement cryptographic binding.
11. IANA Considerations 12. IANA Considerations
This document requires IANA to allocate a new EAP Type for EAP-GPSK. This document requires IANA to allocate a new EAP Type for EAP-GPSK.
This document requires IANA to create a new registry for This document requires IANA to create a new registry for
ciphersuites, protected data types, failure codes and op-codes. IANA ciphersuites, protected data types, failure codes and op-codes. IANA
is furthermore instructed to add the specified ciphersuites, is furthermore instructed to add the specified ciphersuites,
protected data types, failure codes and op-codes to these registries protected data types, failure codes and op-codes to these registries
as defined in this document. Values can be added or modified with as defined in this document. Values can be added or modified with
informational RFCs defining either block-based or hash-based informational RFCs defining either block-based or hash-based
ciphersuites, protected data payloads, failure codes and op-codes. ciphersuites, protected data payloads, failure codes and op-codes.
skipping to change at page 31, line 25 skipping to change at page 32, line 23
setup. The CSuite/Specifier field is 16 bits long. All other values setup. The CSuite/Specifier field is 16 bits long. All other values
are available via IANA registration. are available via IANA registration.
The following is the initial protected data PData/Specifier registry The following is the initial protected data PData/Specifier registry
setup: setup:
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication o 0x000001 : Protected Results Indication
The PData/Specifier field is 24 bits long and all other values are The PData/Specifier field is 24 bits long and all other values are
available via IANA registration. available via IANA registration. Each extension needs to indicate
whether confidentiality protection for transmission between the EAP
The following layout represents the initial Failure-Code registry peer and the EAP server is mandatory. The following layout
setup: represents the initial Failure-Code registry setup:
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization 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:
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.
12. Contributors 13. Contributors
This work is a joint effort of the EAP Method Update (EMU) design This work is a joint effort of the EAP Method Update (EMU) design
team of the EMU Working Group that was created to develop a mechanism team of the EMU Working Group that was created to develop a mechanism
based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC
4017 [RFC4017] requirements. The design team members (in 4017 [RFC4017] requirements. The design team members (in
alphabetical order) were: alphabetical order) were:
o Jari Arkko o Jari Arkko
o Mohamad Badra o Mohamad Badra
o Uri Blumenthal o Uri Blumenthal
skipping to change at page 32, line 27 skipping to change at page 33, line 21
o Lakshminath Dondeti o Lakshminath Dondeti
o David McGrew o David McGrew
o Joe Salowey o Joe Salowey
o Sharma Suman o Sharma Suman
o Hannes Tschofenig o Hannes Tschofenig
o Jesse Walker o Jesse Walker
Finally, we would like to thank Thomas Otto for his draft reviews, Finally, we would like to thank Thomas Otto for his draft reviews,
feedback and text contributions. feedback and text contributions.
13. Acknowledgments 14. Acknowledgments
We would like to thank We would like to thank
o Jouni Malinen and Bernard Aboba for their early draft comments in o Jouni Malinen and Bernard Aboba for their early draft comments in
June 2006. Jouni Malinen developed the first prototype June 2006. Jouni Malinen developed the first prototype
implementation. It can be found at: implementation. It can be found at:
http://hostap.epitest.fi/releases/snapshots/ http://hostap.epitest.fi/releases/snapshots/
o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela
Vanderveen and Ray Bell for their input to the ciphersuite Vanderveen and Ray Bell for their input to the ciphersuite
discussions between July and August 2006. discussions between July and August 2006.
skipping to change at page 33, line 4 skipping to change at page 33, line 45
to the GKDF function (December 2006). to the GKDF function (December 2006).
o Jouni Malinen and Victor Fajardo for their review in January 2007. o Jouni Malinen and Victor Fajardo for their review in January 2007.
o Jouni Malinen for his suggestions regarding the examples and the o Jouni Malinen for his suggestions regarding the examples and the
key derivation function in February 2007. key derivation function in February 2007.
o Bernard Aboba and Jouni Malinen for their review in February 2007. o Bernard Aboba and Jouni Malinen for their review in February 2007.
o Vidya Narayanan for her review in March 2007. o Vidya Narayanan for her review in March 2007.
o o
o Joe Salowey, the EMU working group chair, provided a document o Joe Salowey, the EMU working group chair, provided a document
review in April 2007. Jouni Malinen also reviewed the document review in April 2007. Jouni Malinen also reviewed the document
during the same month. during the same month.
o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov
and Prof. John C. Mitchell for their analysis of EAP-GPSK and for
pointing us to a client-side DoS attack, a downgrading attack and
their input to the key derivation function. Based on their input
the key derivation function has been modified and the text in the
security consideration section has been updated.
14. References o Finally, we would like to thank our working group chair, Joe
Salowey, for his support and for the time he spend on discussing
open issues with us.
14.1. Normative References 15. References
15.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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
14.2. Informative References 15.2. Informative References
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., Simon, D., and P. Eronen, "Extensible
Management Framework", draft-ietf-eap-keying-18 (work in Authentication Protocol (EAP) Key Management Framework",
progress), February 2007. draft-ietf-eap-keying-22 (work in progress),
November 2007.
[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.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (SHA and HMAC-SHA)", RFC 4634, July 2006.
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
skipping to change at page 34, line 5 skipping to change at page 35, line 8
(SP) 800-38B, May 2005. (SP) 800-38B, May 2005.
[CBC] National Institute of Standards and Technology, [CBC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Encryption. "Recommendation for Block Cipher Modes of Encryption.
Methods and Techniques.", Special Publication (SP) 800- Methods and Techniques.", Special Publication (SP) 800-
38A, December 2001. 38A, December 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[HM2004] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way
Handshake)", Proceedings of the Third ACM International
Workshop on Wireless Security (WiSe'04), Philadelphia,
PA pages 43-50, October 2004.
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
 End of changes. 80 change blocks. 
148 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/