draft-ietf-emu-eap-gpsk-03.txt   draft-ietf-emu-eap-gpsk-04.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: August 10, 2007 Siemens Networks GmbH & Co KG Expires: September 12, 2007 Siemens Networks GmbH & Co KG
February 6, 2007 March 11, 2007
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK)
draft-ietf-emu-eap-gpsk-03.txt draft-ietf-emu-eap-gpsk-04.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 August 10, 2007. This Internet-Draft will expire on September 12, 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
authentication and key derivation. authentication and key derivation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13 6. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12
6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13 6.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12
6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12
6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13 6.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 12
6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14 6.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13
6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14 6.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 13
6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 6.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16 7.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15
7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 17 7.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 7.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 20
7.4.1. Protected Results Indication . . . . . . . . . . . . . 24 7.4.1. Protected Results Indication . . . . . . . . . . . . . 23
8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 8. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 23
9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 9. Example Message Exchanges . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 28 10.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 27
10.2. Protected Result Indications . . . . . . . . . . . . . . 29 10.2. Protected Result Indications . . . . . . . . . . . . . . 28
10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 29 10.3. Integrity Protection . . . . . . . . . . . . . . . . . . 28
10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 29 10.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 28
10.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 29 10.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 28
10.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 29 10.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 28
10.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 29 10.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 28
10.8. Denial of Service Resistance . . . . . . . . . . . . . . 29 10.8. Denial of Service Resistance . . . . . . . . . . . . . . 28
10.9. Session Independence . . . . . . . . . . . . . . . . . . 30 10.9. Session Independence . . . . . . . . . . . . . . . . . . 29
10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 30 10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 29
10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31 10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 30
10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31 10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 30
10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 31 10.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 30
10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 31 10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 30
10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 31 10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 30
10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 31 10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 30
10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 31 10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 30
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
14.1. Normative References . . . . . . . . . . . . . . . . . . 33 14.1. Normative References . . . . . . . . . . . . . . . . . . 32
14.2. Informative References . . . . . . . . . . . . . . . . . 34 14.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 34
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 EAP-GPSK addresses a large number of design goals with the intention
notably of being applicable in a broad range of usage scenarios.
o EAP-PAX [RFC4746]
o EAP-PSK [I-D.bersani-eap-psk]
o EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
o EAP-SAKE [I-D.vanderveen-eap-sake].
Each method has its particular benefits but also its particular
deficiencies. EAP-GPSK is a new EAP method that tries to combine the
most valuable characteristics of each of these methods and therefore
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
Simplicity: Simplicity:
EAP-GPSK should be easy to implement and therefore quickly EAP-GPSK should be easy to implement.
available.
Wide applicability: Security Model:
EAP-GPSK has been designed in a threat model where the attacker EAP-GPSK has been designed in a threat model where the attacker
has full control over the communication channel. This is the EAP has full control over the communication channel. This is the EAP
threat model that is presented in Section 7.1 of [RFC3748]. threat model that is presented in Section 7.1 of [RFC3748].
Efficiency: Efficiency:
EAP-GPSK does not make use of public key cryptography and fully EAP-GPSK does not make use of public key cryptography and fully
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. constraints. Additionally it seeks to minimize the number of
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 selects a set of cryptographic algorithms and key
sizes, a so called ciphersuite. The current version of EAP-GPSK sizes, a so called ciphersuite. The current version of EAP-GPSK
comprises two ciphersuites, but additional ones can be easily comprises two ciphersuites, but additional ones can be easily
added. added.
Extensibility: Extensibility:
skipping to change at page 5, line 30 skipping to change at page 5, line 21
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:
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 peer (6 octets)
ID_Client: Client NAI [RFC4282] ID_Peer: Peer 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: Data carried within the protected data payload
PD_Payload_Block: Block of possibly multiple PD_Payloads carried by PD_Payload_Block: Block of possibly multiple PD_Payloads carried by
a GPSK packet 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_Peer: Random integer generated by the peer (32 octets)
RAND_Server: Random integer generated by the server (32 octets) RAND_Server: Random integer generated by the server (32 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
skipping to change at page 6, line 33 skipping to change at page 6, line 22
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
exchange to encrypt protected data (size defined by ciphersuite)
SK: Session key generated from the MK and used during protocol
exchange to demonstrate knowledge of the PSK (size defined by
ciphersuite)
EMSK: Extended Master Session Key is exported by the EAP method (64 EMSK: Extended Master Session Key is exported by the EAP method (64
octets) octets)
MK: Master Key between the client and EAP server from which all MK: Master Key between the peer and EAP server from which all other
other EAP method session keys are derived (KS octets) EAP method session keys are derived (KS octets)
MSK: Master Session Key exported by the EAP method (64 octets) MSK: Master Session Key exported by the EAP method (64 octets)
MID: Method ID exported by the EAP method according to the EAP PK: Session key generated from the MK and used during protocol
keying framework [I-D.ietf-eap-keying] (16 octets). The EAP exchange to encrypt protected data (KS octets)
Session-Id uniquely identifies an EAP authentication exchange
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 peer and the server (PL
octets) octets)
SK: Session key generated from the MK and used during protocol
exchange to demonstrate knowledge of the PSK (KS octets)
3. Overview 3. Overview
The EAP framework (see Section 1.3 of [RFC3748]) defines three basic The EAP framework (see Section 1.3 of [RFC3748]) defines three basic
steps that occur during the execution of an EAP conversation between steps that occur during the execution of an EAP conversation between
the EAP peer, the Authenticator and the EAP server. the EAP peer, the Authenticator and the EAP server.
1. The first phase, discovery, is handled by the underlying 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") EAP-GPSK performs mutual authentication between EAP peer ("Peer") and
and EAP server ("Server") based on a pre-shared key (PSK). The EAP server ("Server") based on a pre-shared key (PSK). The protocol
protocol consists of four message exchanges (GPSK-1, ..., GPSK-4), in consists of four message exchanges (GPSK-1, ..., GPSK-4), in which
which both sides exchange nonces and their identities, compute and both sides exchange nonces and their identities, compute and exchange
exchange a Message Authentication Code (MAC) over the previously a Message Authentication Code (MAC) over the previously exchanged
exchanged values, keyed with the pre-shared key. This MAC is values, keyed with the pre-shared key. This MAC is considered as
considered as proof of possession of the pre-shared key. proof of possession of the pre-shared key.
A successful protocol exchange is shown in Figure 1. 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 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
skipping to change at page 8, line 34 skipping to change at page 8, line 4
| | EAP-Success | | | | EAP-Success | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
Figure 1: EAP-GPSK: Successful Exchange Figure 1: EAP-GPSK: Successful Exchange
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, SEC_SK(ID_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List,
CSuite_List, CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] ) CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )
GPSK-3 GPSK-3
SEC_SK(RAND_Client, RAND_Server, CSuite_Sel, [ SEC_SK(RAND_Peer, RAND_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.
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
scope of this document. scope of this document.
In GPSK-2, the peer sends its identity ID_Client, a random number In GPSK-2, the peer sends its identity ID_Peer and a random number
RAND_Client. Furthermore, it repeats the received parameters of the RAND_Peer. Furthermore, it repeats the received parameters of the
GPSK-1 message (ID_Server, RAND_Server, CSuite_List), the selected GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected
ciphersuite and computes a Message Authentication Code over all these ciphersuite. It computes a Message Authentication Code over all the
parameters. trasmitted parameters.
The EAP server verifies the received Message Authentication Code. In The EAP server verifies the received Message Authentication Code. In
case of successful verification, the EAP server computes a Message case of successful verification, the EAP server computes a Message
Authentication Code over the session parameter and returns it to the Authentication Code over the session parameter and returns it to the
client (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server
server have the possibility to exchange encrypted protected data have the possibility to exchange encrypted protected data parameters.
parameters.
The peer verifies the received Message Authentication Code. If the The peer verifies the received Message Authentication Code. If the
verification is successful, GPSK-4 is prepared. This message can verification is successful, GPSK-4 is prepared. This message can
optionally contain the client's protected data parameters. optionally contain the peer's protected data parameters.
Upon receipt of GPSK-4, the server assures that the peer has derived Upon receipt of GPSK-4, the server processes any included
session keys SK and PK properly. Then, the EAP server sends an EAP PD_Payload_Block. Then, the EAP server sends an EAP Success message
Success message to indicate the successful outcome of the 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]. Note that this section provides [RFC3748] and [I-D.ietf-eap-keying]. Note that this section provides
an abstract description for the key derivation procedure that needs an abstract description for the key derivation procedure that needs
to instantiated with a specific ciphersuite. to be 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 (if using an encrypting
ciphersuite-specified KDF and data exchanged during the execution of ciphersuite) are derived using the ciphersuite-specified KDF and data
the protocol, namely 'RAND_Client || ID_Client || RAND_Server || exchanged during the execution of the protocol, namely 'RAND_Peer ||
ID_Server' referred as inputString as its short-hand form. ID_Peer || RAND_Server || 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. and EMSK both in length of 64 octets.
The following notation is used: KDF-X(Y, Z)[A..B], whereby The following notation is used: KDF-X(Y, Z)[A..B], whereby
X is the length, in octets, of the desired output, X is the length, in octets, of the desired output,
Y is a secret key, Y is a secret key,
Z is the inputstring, Z is the inputstring,
[A..B] extracts the string of octects starting with octet A [A..B] extracts the string of octects starting with octet A
finishing with octet B from the output of the KDF function. finishing with octet B from the output of the KDF function.
This keying material is derived using the ciphersuite-specified KDF This keying material is derived using the ciphersuite-specified KDF
as follows: as follows:
o inputString = RAND_Client || ID_Client || RAND_Server || ID_Server o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
o MK = KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1] o MK = KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using
o MID = KDF-16(0x00, "Method ID" || EAP_Method_Type || CSuite_Sel || an encrypting ciphersuite)
inputString)[0..15]
Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires
the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID.
These values are defined as:
o Method-ID = KDF-16(0x00, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)[0..15]
o Session-ID = Type_Code || Method_ID
o Peer-ID = ID_Peer
o Server-ID = ID_Server
EAP_Method_Type refers to the integer value of the IANA allocated EAP EAP_Method_Type refers to the integer value of the IANA allocated EAP
Type code. 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_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server | | PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+ +-------------+ +-------------------------------+
| | | | | |
| +------------+ | | | +------------+ | |
| | CSuite_Sel | | | | | CSuite_Sel | | |
| +------------+ | | | +------------+ | |
| | | | | | | |
v v v | v v v |
+--------------------------------------------+ | +--------------------------------------------+ |
| KDF | | | KDF | |
skipping to change at page 12, line 9 skipping to change at page 11, line 19
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 with SHA-1 | | 0x000001 | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF with SHA256 |
+-----------+----+-------------+--------------+----------------------+ +-----------+----+-------------+--------------+----------------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF with SHA256 | | 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
formally specified KDF that takes as arguments a key and a seed formally specified KDF that takes as arguments a key and a seed
value, and produces at least 128+2*KS octets of output. value, and produces at least 128+2*KS octets of output.
If GKDF is invoked by a MAC-based ciphersuite, then the variable
"size" contains the MAC output size in octets. In case of a block
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. Hash-Function hash function provided as part of the ciphersuite
Hash-Function: Hash function provided as part of the ciphersuite
definition. definition.
hashlen the size of hash function output in octets.
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);
skipping to change at page 14, line 13 skipping to change at page 13, line 13
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 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_Peer || ID_Peer || RAND_Server || ID_Server
MK = GKDF-32 (0x00, 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 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel || MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
inputString) inputString)
Hash-Function = SHA-1 (see [RFC3174]) Hash-Function = SHA256 (see [RFC4634])
hashlen = 20 octets (160 bits) hashlen = 32 octets (256 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
When using this ciphersuite, the data exchanged inside the protected When using this ciphersuite, the data exchanged inside the protected
data blocks is not encrypted. Therefore this mode MUST NOT be used data block is not encrypted. Therefore this mode MUST NOT be used if
if confidential information appears inside the protected data blocks. confidential information appears inside the protected data block.
6.2.2. Integrity 6.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. algorithm.
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 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_Peer || ID_Peer || RAND_Server || ID_Server
MK = GKDF-32 (0x00, 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]
MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel || MID = GKDF-16 (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
inputString) inputString)
Hash-Function = SHA256 (see [RFC4634]) Hash-Function = SHA256 (see [RFC4634])
hashlen = 32 octets (256 bits) 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.
skipping to change at page 18, line 9 skipping to change at page 17, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GPSK-1 Payload Figure 7: GPSK-1 Payload
The GPSK-2 payload format is defined as follows: The GPSK-2 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(ID_Client) | | | length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... ID_Client ... ... ID_Peer ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(ID_Server) | | | length(ID_Server) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... ID_Server ... ... ID_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Client ... ... 32-octet RAND_Peer ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Server ... ... 32-octet RAND_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | | | length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... CSuite_List ... ... CSuite_List ...
skipping to change at page 19, line 12 skipping to change at page 18, line 12
If the optional protected data payload is not included, then If the optional protected data payload is not included, then
length(PD_Payload_Block)=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_Peer ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 32-octet RAND_Server ... ... 32-octet RAND_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 21 skipping to change at page 20, line 21
o 0x00000004 through 0xFFFFFFFF : Unallocated o 0x00000004 through 0xFFFFFFFF : Unallocated
"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 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 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) tripples called PD_Payloads. (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.
skipping to change at page 24, line 32 skipping to change at page 23, line 32
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 MUST only be
sent in GPSK-3 from the EAP server to the EAP client. sent in GPSK-3 from the EAP server to the EAP peer.
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 peer and EAP server MUST behave when
when received packet is deemed invalid. received packet is deemed invalid.
Any packet that cannot be parsed by the EAP client or the EAP server Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP
MUST be silently discarded. An EAP client or EAP server receiving server MUST be silently discarded. An EAP peer or EAP server
any unexpected packet (e.g., an EAP client receiving GPSK-3 before receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3
receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard before receiving GPSK-1 or before transmitting GPSK-2) MUST silently
the packet. discard 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. Note that the ciphersuite list MUST be accepted by the peer. Note that the ciphersuite list
provided by the EAP server in CSuite_List MUST always include the provided by the EAP server in CSuite_List MUST always include the
mandatory-to-implement ciphersuite defined in this document. Hence, mandatory-to-implement ciphersuite defined in this document. Hence,
there is always at least one ciphersuite in common between the EAP 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 peer and the EAP server. If the EAP peer decides the ID_Server is
that of a AAA server to which it does not wish to authenticate, the that of a AAA server to which it does not wish to authenticate, the
EAP client should respond with an EAP-Nak. EAP peer 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_Peer 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 Failure" MUST transmit a GPSK-Fail message specifying "Authentication Failure"
and discard the received packet. If the RAND_Server or CSuite_List and discard the received packet. If the RAND_Server or CSuite_List
field in GPSK-2 does not match the values in GPSK-1, the server MUST field in GPSK-2 does not match the values in GPSK-1, the server MUST
silently discard the packet. If server policy determines the client silently discard the packet. If server policy determines the peer is
is not authorized and the MAC is correct, the server MUST transmit a not authorized and the MAC is correct, the server MUST transmit a
GPSK-Protected-Fail message indicating "Authorization Failure" and GPSK-Protected-Fail message indicating "Authorization Failure" and
discard the received packet. discard the received packet.
A client receiving a GPSK-Fail / GPSK-Protected-Fail message in A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in
response to a GPSK-2 message MUST replay the received GPSK-Fail / response to a GPSK-2 message MUST replay the received GPSK-Fail /
GPSK-Protected-Fail message. Then, the EAP server returns an EAP- GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
to correctly finish the EAP conversation. If MAC validation on a to correctly finish the EAP conversation. If MAC validation on a
GPSK-Protected-Fail packet fails, then the received packet MUST be GPSK-Protected-Fail packet fails, then the received packet MUST be
silently discarded. silently discarded.
For GPSK-3, a client MUST silently discard messages where the For GPSK-3, a peer MUST silently discard messages where the
RAND_Client, 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 client MUST silently discard any transmitted in GPSK-2. An EAP peer MUST silently discard any packet
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 9. Example Message Exchanges
This section shows a couple of example message flows. This section shows a couple of example message flows.
skipping to change at page 29, line 21 skipping to change at page 28, line 21
indications using the protected data payloads. indications using the protected data payloads.
10.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.
10.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_Client. thanks to the use of random numbers RAND_Server and RAND_Peer. Since
Since RAND_Server is 32 octets long, one expects to have to record RAND_Server is 32 octets long, one expects to have to record 2**64
2**64 (i.e., approximately 1.84*10**19) EAP-GPSK successful (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication
authentication before an protocol run can be replayed. Hence, EAP- before an protocol run can be replayed. Hence, EAP-GPSK provides
GPSK provides replay protection of its mutual authentication part as replay protection of its mutual authentication part as long as
long as RAND_Server and RAND_Client are chosen at random, randomness RAND_Server and RAND_Peer are chosen at random, randomness is
is critical for replay protection. critical for replay protection.
10.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.
10.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
skipping to change at page 30, line 33 skipping to change at page 29, line 33
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.
10.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_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 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
skipping to change at page 31, line 35 skipping to change at page 30, line 35
10.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.
10.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 peer in the subsequent message.
10.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].
10.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.
skipping to change at page 33, line 32 skipping to change at page 32, line 32
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. 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 Vidya Narayanan for her review in March 2007.
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.
[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.
[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.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[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, August 2006. (SHA and HMAC-SHA)", RFC 4634, August 2006.
14.2. Informative References
[I-D.bersani-eap-psk]
Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a
Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work
in progress), June 2006.
[I-D.otto-emu-eap-tls-psk]
Otto, T. and H. Tschofenig, "The EAP-TLS-PSK
Authentication Protocol", draft-otto-emu-eap-tls-psk-01
(work in progress), October 2006.
[I-D.vanderveen-eap-sake]
Vanderveen, M. and H. Soliman, "Extensible Authentication
Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02
(work in progress), May 2006.
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-17 (work in
progress), January 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
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.
14.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., "Extensible Authentication Protocol (EAP) Key
Management Framework", draft-ietf-eap-keying-18 (work in
progress), February 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
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. 74 change blocks. 
199 lines changed or deleted 165 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/