draft-ietf-emu-eap-gpsk-02.txt   draft-ietf-emu-eap-gpsk-03.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: July 9, 2007 Siemens Networks GmbH & Co KG Expires: August 10, 2007 Siemens Networks GmbH & Co KG
January 5, 2007 February 6, 2007
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-ietf-emu-eap-gpsk-02 draft-ietf-emu-eap-gpsk-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 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 July 9, 2007. This Internet-Draft will expire on August 10, 2007.
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 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13
6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12 6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12 6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13 6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . . 13 6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 15
7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . . 15 7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16
7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . . 15 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 17
7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . . 20 7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21
7.4.1. Protected Results Indication . . . . . . . . . . . . . 24
8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 21 8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25
9.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 22
9.2. Protected Result Indications . . . . . . . . . . . . . . . 22
9.3. Integrity Protection . . . . . . . . . . . . . . . . . . . 23
9.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 23
9.5. Reflection attacks . . . . . . . . . . . . . . . . . . . . 23
9.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . . 23
9.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 23
9.8. Denial of Service Resistance . . . . . . . . . . . . . . . 23
9.9. Session Independence . . . . . . . . . . . . . . . . . . . 24
9.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 24
9.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24
9.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 25
9.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . . 25
9.14. Identity Protection . . . . . . . . . . . . . . . . . . . 25
9.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 25
9.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 25
9.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28
10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 28
10.2. Protected Result Indications . . . . . . . . . . . . . . 29
10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 29
10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
10.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 29
10.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 29
10.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 29
10.8. Denial of Service Resistance . . . . . . . . . . . . . . 29
10.9. Session Independence . . . . . . . . . . . . . . . . . . 30
10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 30
10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31
10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31
10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 31
10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 31
10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 31
10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31
10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 31
12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
14.1. Normative References . . . . . . . . . . . . . . . . . . . 27
14.2. Informative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . 33
14.2. Informative References . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
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.
At present, several pre-shared key EAP methods are specified, most At present, several pre-shared key EAP methods are specified, most
notably notably
o EAP-PAX [I-D.clancy-eap-pax] o EAP-PAX [RFC4746]
o EAP-PSK [I-D.bersani-eap-psk] o EAP-PSK [I-D.bersani-eap-psk]
o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
o EAP-SAKE [I-D.vanderveen-eap-sake]. o EAP-SAKE [I-D.vanderveen-eap-sake].
Each method has its particular benefits but also its particular Each method has its particular benefits but also its particular
deficiencies. EAP-GPSK is a new EAP method that tries to combine the deficiencies. EAP-GPSK is a new EAP method that tries to combine the
most valuable characteristics of each of these methods and therefore most valuable characteristics of each of these methods and therefore
attempts to address a broad range of usage scenarios. attempts to address a broad range of usage scenarios.
The main design goals of EAP-GPSK are The main design goals of EAP-GPSK are
skipping to change at page 5, line 27 skipping to change at page 5, line 27
of the specification. These words are often capitalized. The key of the specification. These words are often capitalized. The key
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in [RFC2119]. are to be interpreted as described in [RFC2119].
This section describes the various variables and functions used in This section describes the various variables and functions used in
the EAP-GPSK method. the EAP-GPSK method.
Variables: Variables:
PD_Payload_X: Data carried within the X-th protected data payload
CSuite_List: An octet array listing available ciphersuites (variable CSuite_List: An octet array listing available ciphersuites (variable
length) length)
CSuite_Sel: Ciphersuite selected by the client (6 octets) CSuite_Sel: Ciphersuite selected by the client (6 octets)
ID_Client: Client NAI [RFC2486bis] ID_Client: Client NAI [RFC4282]
ID_Server: Server identity as an opaque blob. ID_Server: Server identity as an opaque blob.
KS: Integer representing the key size in octets of the selected KS: Integer representing the key size in octets of the selected
ciphersuite CSuite_Sel. The key size is one of the ciphersuite ciphersuite CSuite_Sel. The key size is one of the ciphersuite
parameters. parameters.
PD_Payload: Data carried within the protected data payload
PD_Payload_Block: Block of possibly multiple PD_Payloads carried by
a GPSK packet
PL: Integer representing the length of the PSK in octets (2 octets) PL: Integer representing the length of the PSK in octets (2 octets)
RAND_Client: Random integer generated by the client (32 octets)
RAND_Client: Random integer generated by the client (16 octets) RAND_Server: Random integer generated by the server (32 octets)
RAND_Server: Random integer generated by the server (16 octets)
Operations: Operations:
A || B: Concatenation of octet strings A and B A || B: Concatenation of octet strings A and B
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
The following abbreviations are used for the keying material: The following abbreviations are used for the keying material:
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 (size defined by ciphersuite) exchange to encrypt protected data (size defined by ciphersuite)
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 (size defined by exchange to demonstrate knowledge of the PSK (size defined by
ciphersuite) ciphersuite)
EMSK: Extended Master Session Key is exported by the EAP method (32 EMSK: Extended Master Session Key is exported by the EAP method (64
octets) octets)
MK: Master Key between the client and EAP server from which all MK: Master Key between the client and EAP server from which all
other EAP method session keys are derived (KS octets) 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 (32 octets)
MID: Method ID exported by the EAP method according to the EAP MID: Method ID exported by the EAP method according to the EAP
keying framework [I-D.ietf-eap-keying] (16 octets). The EAP keying framework [I-D.ietf-eap-keying] (16 octets). The EAP
Session-Id uniquely identifies an EAP authentication exchange Session-Id uniquely identifies an EAP authentication exchange
between an EAP peer and an EAP server. between an EAP peer and an EAP server.
PSK: Long-term key shared between the client and the server (PL PSK: Long-term key shared between the client and the server (PL
octets) octets)
3. Overview 3. Overview
skipping to change at page 7, line 25 skipping to change at page 7, line 27
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 1. The first phase, discovery, is handled by the underlying
protocol. protocol.
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 ("Client")
and EAP server ("Server") based on a pre-shared key (PSK). The
protocol consists of four message exchanges (GPSK-1, ..., GPSK-4), in
which both sides exchange nonces and their identities, compute and
exchange a Message Authentication Code (MAC) over the previously
exchanged values, keyed with the pre-shared key. This MAC is
considered as proof of possession of the pre-shared key.
A successful protocol 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 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 | | | | EAP-Request/GPSK-3 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 | | | | EAP-Response/GPSK-4 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Success or EAP-Failure | | | | EAP-Success | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK performs mutual authentication between EAP peer ("Client") Figure 1: EAP-GPSK: Successful Exchange
and EAP server ("Server") based on a pre-shared key (PSK). The
protocol consists of four message exchanges (GPSK-1, ... GPSK-4), in
which both sides exchange nonces and their identities, compute and
exchange a Message Authentication Code (MAC) over the previously
exchanged values, keyed with the pre-shared key. This MAC is
considered as proof of possession of the pre-shared key.
The full EAP-GPSK protocol is as follows: The full EAP-GPSK protocol is as follows:
GPSK-1: GPSK-1:
ID_Server, RAND_Server, CSuite_List ID_Server, RAND_Server, CSuite_List
GPSK-2: GPSK-2:
SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_Sel, SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server,
CSuite_List, [, ENC_PK(PD_Payload_1), ... ] ) CSuite_List, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
GPSK-3 GPSK-3
SEC_SK(RAND_Client, RAND_Server, CSuite_Sel [, SEC_SK(RAND_Client, RAND_Server, CSuite_Sel, [
ENC_PK(PD_Payload_2), ... ] ) ENC_PK(PD_Payload_Block) ] )
GPSK-4: GPSK-4:
[ SEC_SK(ENC_PK(PD_Payload_3)), ... ] 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.
In GPSK-1, the EAP server sends its identity ID_Server, a random In GPSK-1, the EAP server sends its identity ID_Server, a random
number RAND_Server and a list of supported ciphersuites CSuite_List. number RAND_Server and a list of supported ciphersuites CSuite_List.
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
skipping to change at page 9, line 19 skipping to change at page 9, line 37
optionally contain the client's protected data parameters. optionally contain the client's protected data parameters.
Upon receipt of GPSK-4, the server assures that the peer has derived Upon receipt of GPSK-4, the server assures that the peer has derived
session keys SK and PK properly. Then, the EAP server sends an EAP session keys SK and PK properly. Then, the EAP server sends an EAP
Success message to indicate the successful outcome of the Success message to indicate the successful outcome of the
authentication. 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 [I-D.ietf-eap-keying]. [RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides
an abstract description for the key derivation procedure that needs
to 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 it would make
EAP-GPSK vulnerable to dictionary attacks. EAP-GPSK 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 are derived using the and a Protected Data Encryption Key PK are derived using the
ciphersuite-specified KDF and data exchanged during the execution of ciphersuite-specified KDF and data exchanged during the execution of
the protocol, namely 'RAND_Client || ID_Client || RAND_Server || the protocol, namely 'RAND_Client || ID_Client || RAND_Server ||
ID_Server' referred as inputString as its short-hand form. ID_Server' referred as inputString as its 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. This keying material is and EMSK both in length of 64 octets.
derived using the ciphersuite-specified KDF as follows:
The following notation is used: KDF-X(Y, Z)[A..B], whereby
X is the length, in octets, of the desired output,
Y is a secret key,
Z is the inputstring,
[A..B] extracts the string of octects starting with octet A
finishing with octet B from the output of the KDF function.
This keying material is derived using the ciphersuite-specified KDF
as follows:
o inputString = RAND_Client || ID_Client || RAND_Server || ID_Server o inputString = RAND_Client || ID_Client || RAND_Server || ID_Server
o MK = KDF_Zero-String (PL || PSK || CSuite_Sel || o MK = KDF-KS(0x00, 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_MK (inputString)[0..63] o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o EMSK = KDF_MK (inputString)[64..127] o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o SK = KDF_MK (inputString)[128..127+KS] o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS]
o PK = KDF_MK (inputString)[128+KS..127+2*KS] o MID = KDF-16(0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
o MID = KDF_Zero-String ("Method ID" || EAP_Method_Type || inputString)[0..15]
CSuite_Sel || inputString)[0..15]
Note that the term 'Zero-String' refers to a sequence of 0x00 values, EAP_Method_Type refers to the integer value of the IANA allocated EAP
KS octets in length. EAP_Method_Type refers to the integer value of Type code.
the IANA allocated EAP Type code.
Figure 2 depicts the key derivation procedure of EAP-GPSK. Figure 2 depicts the key derivation procedure of EAP-GPSK.
+-------------+ +-------------------------------+ +-------------+ +-------------------------------+
| PL-octet | | RAND_Client || ID_Client || | | PL-octet | | RAND_Client || ID_Client || |
| PSK | | RAND_Server || ID_Server | | PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+ +-------------+ +-------------------------------+
| | | | | |
| +------------+ | | | +------------+ | |
| | CSuite_Sel | | | | | CSuite_Sel | | |
skipping to change at page 10, line 34 skipping to change at page 11, line 32
| MK | | | MK | |
+-------------+ | +-------------+ |
| | | |
v v v v
+---------------------------------------------------+ +---------------------------------------------------+
| KDF | | KDF |
+---------------------------------------------------+ +---------------------------------------------------+
| | | | | | | |
v v v v v v v v
+---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+ +----------+
| 32-octet| | 32-octet| | KS-octet | | KS-octet | | 64-octet| | 64-octet| | KS-octet | | KS-octet |
| MSK | | EMSK | | SK | | PK | | MSK | | EMSK | | SK | | PK |
+---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+ +----------+
Figure 2: EAP-GPSK Key Derivation Figure 2: EAP-GPSK Key Derivation
5. Ciphersuites 5. Ciphersuites
The design of EAP-GPSK allows cryptographic algorithms and key sizes, The design of EAP-GPSK allows cryptographic algorithms and key sizes,
called ciphersuites, to be negotiated during the protocol run. The called ciphersuites, to be negotiated during the protocol run. The
ability to specify block-based and hash-based ciphersuites is ability to specify block-based and hash-based ciphersuites is
offered. Extensibility is provided with the introduction of new offered. Extensibility is provided with the introduction of new
ciphersuites; this document specifies an initial set. The CSuite/ ciphersuites; this document specifies an initial set. The CSuite/
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 three octets are the For a vendor-specific ciphersuite the first three octets are the
vendor-specific OID, and the last three octets are vendor assigned vendor-specific OID, and the last three octets are vendor assigned
for the specific ciphersuite. for the specific ciphersuite.
The following ciphersuites are specified in this document: The following ciphersuites are specified in this document:
+-----------+----+-------------+---------------+--------------------+ +-----------+----+-------------+--------------+----------------------+
| CSuite/ | KS | Encryption | Integrity | Key Derivation | | CSuite/ | KS | Encryption | Integrity | Key Derivation |
| Specifier | | | | Function | | Specifier | | | | Function |
+-----------+----+-------------+---------------+--------------------+ +-----------+----+-------------+--------------+----------------------+
| 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF-128 | | 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF with SHA-1 |
+-----------+----+-------------+---------------+--------------------+ +-----------+----+-------------+--------------+----------------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF-256 | | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF with SHA256 |
+-----------+----+-------------+---------------+--------------------+ +-----------+----+-------------+--------------+----------------------+
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.
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). Future ciphersuites can use any other Distribution Function (GKDF). Future ciphersuites can use any other
skipping to change at page 11, line 41 skipping to change at page 12, line 38
cipher-based ciphersuite, "size" contains the block size in octets. cipher-based ciphersuite, "size" contains the block size in octets.
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
hashlen: is the size of hash function output in octets. hashlen: is the size of hash function output in octets.
Hash-Function: SHA-1 is required, SHAs are recommended. Hash-Function: Hash function provided as part of the ciphersuite
definition.
GKDF-X (Y, Z) { GKDF-X (Y, Z) {
n = ceiling integer of ( X / hashlen ); n = ceiling integer of ( X / hashlen );
/* determine number of output blocks */ /* determine number of output blocks */
M_0 = ""; M_0 = "";
result = ""; result = "";
for i = 1 to n { for i = 1 to n {
M_i = Hash-Function (i || y || Z); M_i = Hash-Function (i || Y || Z);
result = result || M_i; result = result || M_i;
} }
return truncate (result; X) return truncate (result)
} }
Note that the variables 'i' and 'X' in M_i are represented as 2-octet Note that the variable 'i' in M_i is represented as a 2-octet value
values in network byte order. in network byte order.
6. Ciphersuites Processing Rules 6. Ciphersuites Processing Rules
6.1. Ciphersuite #1 6.1. Ciphersuite #1
6.1.1. Encryption 6.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. Within the protected data frames, cryptographic primitive, AES-128. Within the protected data frames,
AES-128 is used in CBC mode of operation (see [CBC]). This mode AES-128 is used in Cipher Block Chaining (CBC) mode of operation (see
requires an Initialization Vector (IV) that has the same size as the [CBC]). This EAP method uses encryption in a single payload, in the
block size. For security reasons, the IV should be randomly protected data payload (see Section 7.4).
generated.
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 6.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
skipping to change at page 13, line 17 skipping to change at page 14, line 15
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 6.1.3. Key Derivation
This ciphersuite instantiates the KDF in the following way: This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Client || ID_Client || RAND_Server || ID_Server inputString = RAND_Client || ID_Client || RAND_Server || ID_Server
MK = GKDF-16 (Zero-String, PL || PSK || CSuite_SEL || inputString) MK = GKDF-32 (0x00, 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]
MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
CSuite_Sel || inputString) inputString)
Hash-Function = SHA-1 (see [RFC3174])
hashlen = 20 octets (160 bits)
6.2. Ciphersuite #2 6.2. Ciphersuite #2
6.2.1. Encryption 6.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
skipping to change at page 14, line 15 skipping to change at page 15, line 16
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 6.2.3. Key Derivation
This ciphersuite instantiates the KDF in the following way: This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Client || ID_Client || RAND_Server || ID_Server inputString = RAND_Client || ID_Client || RAND_Server || ID_Server
MK = GKDF-32 (Zero-String, PL || PSK || CSuite_SEL || inputString) MK = GKDF-32 (0x00, PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-192 (MK, inputString)[0..63] MSK = GKDF-192 (MK, inputString)[0..63]
EMSK = GKDF-192 (MK, inputString)[64..127] EMSK = GKDF-192 (MK, inputString)[64..127]
SK = GKDF-192 (MK, inputString)[128..159] SK = GKDF-192 (MK, inputString)[128..159]
PK = GKDF-192 (MK, inputString)[160..191] PK = GKDF-192 (MK, inputString)[160..191]
MID = GKDF-16 (Zero-String, "Method ID" || EAP_Method_Type || MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
CSuite_Sel || inputString) inputString)
Hash-Function = SHA256 (see [RFC4634])
hashlen = 32 octets (256 bits)
7. Packet Formats 7. 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 7.1. Header Format
The EAP-GPSK header has the following structure: The EAP-GPSK header has the following structure:
--- bit offset ---> --- bit offset --->
skipping to change at page 17, line 37 skipping to change at page 18, line 37
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | | | length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... CSuite_List ... ... CSuite_List ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_1) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_1 ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GPSK-2 Payload Figure 8: GPSK-2 Payload
If the optional protected data payload is not included, then If the optional protected data payload is not included, then
length(PD_Payload)=0 and the PD payload is excluded. length(PD_Payload_Block)=0 and the PD payload is excluded.
The GPSK-3 payload is defined as follows: The GPSK-3 payload 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Client ... ... 32-octet RAND_Client ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Server ... ... 32-octet RAND_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_2) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_2 ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GPSK-3 Payload Figure 9: GPSK-3 Payload
If the optional protected data payload is not included, then If the optional protected data payload is not included, then
length(PD_Payload)=0 and the PD payload is excluded. length(PD_Payload_Block)=0 and the PD payload is excluded.
The GPSK-4 payload format is defined as follows: The GPSK-4 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(PD_Payload_3) | | | length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... optional PD_Payload_3 ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GPSK-4 Payload Figure 10: GPSK-4 Payload
If the optional protected data payload is not included, then If the optional protected data payload is not included, then
length(PD_Payload)=0 and the PD payload is excluded. The MAC MUST length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC
always be included, regardless of the presence of PD_Payload_3. MUST always be included, regardless of the presence of
PD_Payload_Block.
The GPSK-Fail payload format is defined as follows: The GPSK-Fail 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failure-Code | | Failure-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 25 skipping to change at page 21, line 27
is not authorized to connect. is not authorized to connect.
7.4. Protected Data 7.4. Protected Data
The protected data blocks are a generic mechanism for the client and The protected data blocks are a generic mechanism for the client 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) tripples. (TLV) tripples 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
3-octet vendor and 3-octet specifier field. The vendor field 3-octet vendor and 3-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 0x000000, then the value is standards- If these three octets are 0x000000, then the value is standards-
specified, and any other value represents a vendor-specific OID. specified, and any other value represents a vendor-specific OID.
The specifier field indicates the actual type. For vendor field The specifier field indicates the actual type. For vendor field
0x000000, the specifier field is maintained by IANA. For any other 0x000000, 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.
skipping to change at page 21, line 11 skipping to change at page 22, line 11
the length of the type and length fields. the length of the type and length fields.
Graphically, this can be depicted as follows: Graphically, this can be depicted 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor | | PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | Length | PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... PD_Payload Value ... ... PData/Value ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Payload (PD_Payload) Formatting
These PD_Payloads are concatenated together to form a
PD_Payload_Block. The If the CSuite_Sel includes support for
encryption, then the PD_Payload_Block includes fields specifying an
initialization vector (IV), and the necessary padding. This can be
depicted as follows:
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
... (length is block size for encryption algorithm) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc ...
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Block (PD_Payload_Block) Formatting if Encryption
Supported
The Initialization Vector is a randomly chosen value whose length is
equal to the block length of the underlying encryption algorithm.
Recipients MUST accept any value. Senders SHOULD either pick this
value pseudo-randomly and independently for each message or use the
final ciphertext block of the previous message sent. Senders MUST
NOT use the same value for each message, use a sequence of values
with low hamming distance (e.g., a sequence number), or use
ciphertext from a received message.
The concatination of PD_Payloads along with the padding and padding
length are all encrypted using the negotiated block cipher. If no
block cipher is specified, then these fields are not encrypted.
The Padding field MAY contain any value chosen by the sender, and
MUST have a length that makes the combination of the concatination of
PD_Payloads, the Padding, and the Pad Length to be a multiple of the
encryption block size.
The Pad Length field is the length of the Padding field. The sender
SHOULD set the Pad Length to the minimum value that makes the
combination of the PD_Payloads, the Padding, and the Pad Length a
multiple of the block size, but the recipient MUST accept any length
that results in proper alignment. This field is encrypted with the
negotiated cipher.
If the negotiated ciphersuite does not support encryption, then the
padding field MUST be of length zero. The padding length field MUST
still be present, and contain the value zero. This is depicted in
the following figure.
--- bit offset --->
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... PD_Payload ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
o 0x000002 through 0xFFFFFF : Unallocated o 0x000002 through 0xFFFFFF : Unallocated
7.4.1. Protected Results Indication
Based on the PData/Specifier allocation the following 8-bit payload
is specified to be placed in the PD_Payload Value to provide the
functionality of protected results indication.
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|I|R|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+
I: Result Indicator
The bits have the following meaning:
(0): Success
(1): Failure
R: Reserved
These bits are used for padding.
The 8 bits of protected results indication functionality MUST only be
sent in GPSK-3 from the EAP server to the EAP client.
8. Packet Processing Rules 8. Packet Processing Rules
This section defines how the EAP client and EAP server MUST behave This section defines how the EAP client and EAP server MUST behave
when received packet is deemed invalid. when received packet is deemed invalid.
Any packet that cannot be parsed by the EAP client or the EAP server Any packet that cannot be parsed by the EAP client or the EAP server
MUST be silently discarded. An EAP client or EAP server receiving MUST be silently discarded. An EAP client or EAP server receiving
any unexpected packet (i.e. an EAP client receiving GPSK-3 before any unexpected packet (e.g., an EAP client receiving GPSK-3 before
receving GPSK-1 or before transmitting GPSK-2) MUST silently discard receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard
the packet. the packet.
GPSK-1 contains no MAC protection, so provided it properly parses, it GPSK-1 contains no MAC protection, so provided it properly parses, it
MUST be accepted by the client. If the EAP client decides the MUST be accepted by the client. Note that the ciphersuite list
ID_Server is that of a AAA server to which it does not wish to provided by the EAP server in CSuite_List MUST always include the
authenticate, the EAP client should respond with an EAP-NACK. mandatory-to-implement ciphersuite defined in this document. Hence,
there is always at least one ciphersuite in common between the EAP
peer and the EAP server. If the EAP client decides the ID_Server is
that of a AAA server to which it does not wish to authenticate, the
EAP client should respond with an EAP-Nak.
For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST
send either a "PSK Not Found" GPSK-Fail message, or an send either a "PSK Not Found" GPSK-Fail message, or an
"Authentication Failure" GPSK-Fail, depending on its policy, and "Authentication Failure" GPSK-Fail, depending on its policy, and
discard the received packet. If the MAC validation fails, the server discard the received packet. If the MAC validation fails, the server
MUST transmit a GPSK-Fail message specifying "Authentication MUST transmit a GPSK-Fail message specifying "Authentication Failure"
Failure". and discard the received packet. If the RAND_Server or and discard the received packet. If the RAND_Server or CSuite_List
CSuite_List field in GPSK-2 does not match the values in GPSK-1, the field in GPSK-2 does not match the values in GPSK-1, the server MUST
server MUST silently discard the packet. If server policy determines silently discard the packet. If server policy determines the client
the client is not authorized and the MAC is correct, the server MUST is not authorized and the MAC is correct, the server MUST transmit a
transmit a GPSK-Protected-Fail message indicating "Authorization GPSK-Protected-Fail message indicating "Authorization Failure" and
Failure" and discard the received packet. discard the received packet.
A client receiving a GPSK-Fail or GPSK-Protected-Fail message in A client receiving a GPSK-Fail / GPSK-Protected-Fail message in
response to a GPSK-2 message MUST either transmit an EAP-Failure response to a GPSK-2 message MUST replay the received GPSK-Fail /
message and end the session, or retry transmission of GPSK-2, GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
attempting to correct whatever failure occured. If MAC validation on Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
a GPSK-Protected-Fail packet fails, then the received packet MUST be to correctly finish the EAP conversation. If MAC validation on a
GPSK-Protected-Fail packet fails, then the received packet MUST be
silently discarded. silently discarded.
For GPSK-3, a client MUST silently discard any packet containing For GPSK-3, a client MUST silently discard messages where the
whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those RAND_Client, the RAND_Server, or the CSuite_Sel fields do match those
transmitted in GPSK-2. An EAP client MUST silently discard any transmitted in GPSK-2. An EAP client MUST silently discard any
packet whose MAC fails. 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.
9. Security Considerations 9. Example Message Exchanges
This section shows a couple of example message flows.
A successful EAP-GPSK message exchange is shown in Figure 1.
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/EAP-Nak | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity;
ID_Server)
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | |
| | (PSK Not Found or AuthenFail) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 (GPSK-Fail) | |
| | (PSK Not Found or AuthenFail) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Unknown user)
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | |
| | (AuthenFail) | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-4 (GPSK-Fail) | |
| | (AuthenFail) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
+--------+ +--------+
| | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP |
| peer | | server |
| | EAP-Response/Identity | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-1 | |
| |<------------------------------------| |
| | | |
| | EAP-Response/GPSK-2 | |
| |------------------------------------>| |
| | | |
| | EAP-Request/GPSK-3 | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |<------------------------------------| |
| | | |
| | EAP-Request/GPSK-4 | |
| | GPSK-Protected-Fail | |
| | (Authorization Failure) | |
| |------------------------------------>| |
| | | |
| | EAP-Failure | |
| |<------------------------------------| |
+--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Authorization failure)
10. 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].
9.1. Mutual Authentication 10.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 because it can
calculate a valid MAC and the peer believes that the server is calculate a valid MAC and the peer believes that the server is
authentic because it can calculate another valid MAC. authentic because it can calculate another valid MAC.
The key used for mutual authentication is computed again based on the The key used for mutual authentication is computed again based on the
long-term secret PSK that has to provide sufficient entropy and long-term secret PSK that has to provide sufficient entropy and
therefore sufficient strength. In this way EAP-GPSK is no different therefore sufficient strength. In this way EAP-GPSK is no different
than other authentication protocols based on pre-shared keys. than other authentication protocols based on pre-shared keys.
9.2. Protected Result Indications 10.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.
9.3. Integrity Protection 10.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.
9.4. Replay Protection 10.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_P. Since thanks to the use of random numbers RAND_Server and RAND_Client.
RAND_Server is 16 octets long, one expects to have to record 2**64 Since RAND_Server is 32 octets long, one expects to have to record
(i.e., approximately 1.84*10**19) EAP-GPSK successful authentication 2**64 (i.e., approximately 1.84*10**19) EAP-GPSK successful
before an protocol run can be replayed. Hence, EAP-GPSK provides authentication before an protocol run can be replayed. Hence, EAP-
replay protection of its mutual authentication part as long as GPSK provides replay protection of its mutual authentication part as
RAND_Server and RAND_Client are chosen at random, randomness is long as RAND_Server and RAND_Client are chosen at random, randomness
critical for replay protection. is critical for replay protection.
9.5. Reflection attacks 10.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.
9.6. Dictionary Attacks 10.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 security against dictionary attacks. Derivation of the long-term
shared secret from a password is strongly discouraged. shared secret from a password is strongly discouraged.
9.7. Key Derivation 10.7. Key Derivation
EAP-GPSK supports key derivation as shown in Section 4. EAP-GPSK supports key derivation as shown in Section 4.
9.8. Denial of Service Resistance 10.8. Denial of Service Resistance
Denial of Service (DoS) resistance has not been a design goal for Denial of Service (DoS) resistance has not been a design goal for
EAP-GPSK. EAP-GPSK.
It is however believed that EAP-GPSK does not provide any obvious and It is however believed that EAP-GPSK does not provide any obvious and
avoidable venue for such attacks. avoidable venue for such attacks.
It is worth noting that the server has to maintain some state when it It is worth noting that the server has to maintain some state when it
engages in an EAP-GPSK conversation, namely to generate and to engages in an EAP-GPSK conversation, namely to generate and to
remember the 16-octet RAND_S. This should however not lead to remember the 32-octet RAND_Server. This should however not lead to
resource exhaustion as this state and the associated computation are resource exhaustion as this state and the associated computation are
fairly lightweight. fairly lightweight.
It is recommended that EAP-GPSK does not allow EAP notifications to It is recommended that EAP-GPSK does not allow EAP notifications to
be interleaved in its dialog to prevent potential DoS attacks. be interleaved in its dialog to prevent potential DoS attacks.
Indeed, since EAP Notifications are not integrity protected, they can Indeed, since EAP Notifications are not integrity protected, they can
easily be spoofed by an attacker. Such an attacker could force a easily be spoofed by an attacker. Such an attacker could force a
peer that allows EAP Notifications to engage in a discussion which peer that allows EAP Notifications to engage in a discussion which
would delay his authentication or result in the peer taking would delay his authentication or result in the peer taking
unexpected actions (e.g., in case a notification is used to prompt unexpected actions (e.g., in case a notification is used to prompt
the peer to do some "bad" action). the peer to do some "bad" action).
It is up to the implementation of EAP-GPSK or to the peer and the It is up to the implementation of EAP-GPSK or to the peer and the
server to specify the maximum number of failed cryptographic checks server to specify the maximum number of failed cryptographic checks
that are allowed. that are allowed.
9.9. Session Independence 10.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_Client and RAND_Server are random is central The assumption that RAND_Client and RAND_Server are random is central
for the security of EAP-GPSK in general and session independance in for the security of EAP-GPSK in general and session independence in
particular. particular.
9.10. Exposition of the PSK 10.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.
9.11. Fragmentation 10.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 small.
9.12. Channel Binding 10.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.
9.13. Fast Reconnect 10.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.
9.14. Identity Protection 10.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.
9.15. Protected Ciphersuite Negotiation 10.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 client in the subsequent message. message and a confirmation by the client in the subsequent message.
9.16. Confidentiality 10.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].
9.17. Cryptographic Binding 10.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.
10. IANA Considerations 11. 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, and failure codes. IANA is ciphersuites, protected data types, and failure codes. IANA is
furthermore instructed to add the specified ciphersuites, protected furthermore instructed to add the specified ciphersuites, protected
data types, and failure codes to this registry as defined in this data types, and failure codes to this registry as defined in this
document. Values can be added or modified with informational RFCs document. Values can be added or modified with informational RFCs
defining either block-based or hash-based ciphersuites, protected defining either block-based or hash-based ciphersuites, protected
data payloads, or failure codes. Each ciphersuite needs to provide data payloads, or failure codes. Each ciphersuite needs to provide
skipping to change at page 26, line 28 skipping to change at page 32, line 37
o 0x000002 through 0xFFFFFF : Unallocated o 0x000002 through 0xFFFFFF : Unallocated
The following layout represents the initial Failure-Code registry The following layout represents the initial Failure-Code registry
setup: 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
o 0x00000004 through 0xFFFFFFFF : Unallocated o 0x00000004 through 0xFFFFFFFF : Unallocated
11. Contributors 12. 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 27, line 5 skipping to change at page 33, line 14
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.
12. Acknowledgment 13. 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.
o Lakshminath Dondeti for his detailed draft review (sent to the EMU o Lakshminath Dondeti for his detailed draft review (sent to the EMU
ML on the 12th July 2006). ML on the 12th July 2006).
o Based on a review requested from NIST Quynh Dang suggested changes o Based on a review requested from NIST Quynh Dang suggested changes
to the GKDF function (December 2006). to the GKDF function (December 2006).
o Jouni Malinen and Victor Fajardo for their review in January 2007.
13. Open Issues o Jouni Malinen for his suggestions regarding the examples and the
key derivation function in February 2007.
The list of open issues can be found at:
http://www.tschofenig.com:8080/eap-gpsk/
14. References 14. References
14.1. Normative References 14.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", March 1997. Requirement Levels", March 1997.
[RFC2486bis] [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
Network Access Identifier",
draft-ietf-radext-rfc2486bis-06 (work in progress),
July 2005.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[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.
14.2. Informative References [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[I-D.clancy-eap-pax] [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
Clancy, C. and W. Arbaugh, "EAP Password Authenticated (SHA and HMAC-SHA)", RFC 4634, August 2006.
Exchange", draft-clancy-eap-pax-11 (work in progress),
September 2006. 14.2. Informative References
[I-D.bersani-eap-psk] [I-D.bersani-eap-psk]
Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work
in progress), June 2006. in progress), June 2006.
[I-D.otto-emu-eap-tls-psk] [I-D.otto-emu-eap-tls-psk]
Otto, T. and H. Tschofenig, "The EAP-TLS-PSK Otto, T. and H. Tschofenig, "The EAP-TLS-PSK
Authentication Protocol", draft-otto-emu-eap-tls-psk-01 Authentication Protocol", draft-otto-emu-eap-tls-psk-01
(work in progress), October 2006. (work in progress), October 2006.
[I-D.vanderveen-eap-sake] [I-D.vanderveen-eap-sake]
Vanderveen, M. and H. Soliman, "Extensible Authentication Vanderveen, M. and H. Soliman, "Extensible Authentication
Protocol Method for Shared-secret Authentication and Key Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02 Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02
(work in progress), May 2006. (work in progress), May 2006.
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-16 (work in Management Framework", draft-ietf-eap-keying-17 (work in
progress), January 2007. progress), January 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.
[RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication
Protocol (EAP) Password Authenticated Exchange", RFC 4746,
November 2006.
[CMAC] National Institute of Standards and Technology, [CMAC] National Institute of Standards and Technology,
"Recommendation for Block Cipher Modes of Operation: The "Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication", Special Publication CMAC Mode for Authentication", Special Publication
(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.
 End of changes. 95 change blocks. 
186 lines changed or deleted 426 lines changed or added

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