draft-ietf-emu-eap-gpsk-08.txt   draft-ietf-emu-eap-gpsk-09.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: June 6, 2008 Nokia Siemens Networks Expires: December 29, 2008 Nokia Siemens Networks
December 4, 2007 June 27, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-08 draft-ietf-emu-eap-gpsk-09
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 June 6, 2008. This Internet-Draft will expire on December 29, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 12 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 12 7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13
7.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 12
7.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 12
7.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 13
7.1.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 13
7.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
7.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
7.2.3. Key Derivation . . . . . . . . . . . . . . . . . . . . 14
8. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13
8.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13
8.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
8.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
8.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14
8.4.1. Protected Results Indication . . . . . . . . . . . . . 24 8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
9. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16
9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21
10. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25
11.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 28
11.2. Protected Result Indications . . . . . . . . . . . . . . 29
11.3. Integrity Protection . . . . . . . . . . . . . . . . . . 29
11.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 29
11.5. Reflection attacks . . . . . . . . . . . . . . . . . . . 29
11.6. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 29
11.7. Key Derivation . . . . . . . . . . . . . . . . . . . . . 30
11.8. Denial of Service Resistance . . . . . . . . . . . . . . 30
11.9. Session Independence . . . . . . . . . . . . . . . . . . 30
11.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 31
11.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 31
11.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 31
11.13. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 31
11.14. Identity Protection . . . . . . . . . . . . . . . . . . . 31
11.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 31
11.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 32
11.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 29
12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29
12.3. Protected Result Indications . . . . . . . . . . . . . . 29
12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30
12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30
12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30
12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 30
12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31
12.10. Session Independence . . . . . . . . . . . . . . . . . . 31
12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32
12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32
12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 32
12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33
12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33
12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33
12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
15.1. Normative References . . . . . . . . . . . . . . . . . . 35
15.2. Informative References . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 37 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
generalized pre-shared key authentication technique. Mutual generalized pre-shared key authentication technique. Mutual
authentication is achieved through a nonce-based exchange that is authentication is achieved through a nonce-based exchange that is
secured by a pre-shared key. secured by a pre-shared key.
EAP-GPSK addresses a large number of design goals with the intention EAP-GPSK addresses a large number of design goals with the intention
of being applicable in a broad range of usage scenarios. of being applicable in a broad range of usage scenarios.
skipping to change at page 5, line 27 skipping to change at page 5, line 27
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 peer (6 octets) CSuite_Sel: Ciphersuite selected by the peer (6 octets)
ID_Peer: Peer 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 input key size in octets of the
ciphersuite CSuite_Sel. The key size is one of the ciphersuite selected ciphersuite CSuite_Sel. The key size is one of the
parameters. ciphersuite 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_Peer: Random integer generated by the peer (32 octets) RAND_Peer: Random integer generated by the peer (32 octets)
skipping to change at page 9, line 48 skipping to change at page 9, line 48
o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server o inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel || o MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel ||
inputString)[0..KS-1] inputString)[0..KS-1]
o MSK = KDF-{128+2*KS}(MK, inputString)[0..63] o MSK = KDF-{128+2*KS}(MK, inputString)[0..63]
o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127] o EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]
o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS] o SK = KDF-{128+2*KS}(MK, inputString)[128..127+KS]
o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using o PK = KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS] (if using
an encrypting ciphersuite) an encrypting ciphersuite)
From this it should be noted that EAP-GSPK assumes the cipher key
input length is equal to the MAC output length. This is generally
true of many ciphersuites, but would prevent the definition of a
ciphersuite that used a one input key length and a different output
MAC length.
Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires Additionally, the EAP keying framework [I-D.ietf-eap-keying] requires
the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. the definition of a Method-ID, Session-ID, Peer-ID, and Server-ID.
These values are defined as: These values are defined as:
o zero = 0x00 || 0x00 || ... || 0x00 (KS times) o zero = 0x00 || 0x00 || ... || 0x00 (KS times)
o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type || o Method-ID = KDF-16(zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)[0..15] CSuite_Sel || inputString)[0..15]
o Session-ID = Type_Code || Method_ID o Session-ID = Type_Code || Method_ID
o Peer-ID = ID_Peer o Peer-ID = ID_Peer
o Server-ID = ID_Server o Server-ID = ID_Server
skipping to change at page 11, line 5 skipping to change at page 11, line 38
+---------------------------------------------------+ +---------------------------------------------------+
| | | | | | | |
v v v v v v v v
+---------+ +---------+ +----------+ +----------+ +---------+ +---------+ +----------+ +----------+
| 64-octet| | 64-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. Key Management
In order to be interoperable, PSKs must be entered in the same way on
both the peer and server. The management interface for entering PSKs
MUST support entering PSKs up to 64 octets in length as ASCII strings
and in hexadecimal encoding.
Additionally, the ID_Peer and ID_Server MUST be provisioned with the
PSK. Validation of these values is by a octet-wise comparison. Thus
the management interface MUST allow entering values for the ID_Peer
and ID_Server as ASCII strings up to 254 octets in length.
6. 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 four octets are the
vendor-specific Object Identifier (OID) contains the IANA assigned vendor-specific enterprise number contains the IANA assigned "SMI
"SMI Network Management Private Enterprise Codes" value (see Network Management Private Enterprise Codes" value (see [ENTNUM]),
[RFC3232]), encoded in network byte order. The last three octets are encoded in network byte order. The last two octets are vendor
vendor assigned for the specific ciphersuite. assigned for the specific ciphersuite. A vendor code of 0x00000000
indicates ciphersuites standardized by IETF in an IANA-maintained
registry.
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 | | | KDF MAC | Function | | Specifier | | | KDF MAC | Function |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | | 0x000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | | 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF |
+-----------+----+-------------+--------------+----------------+ +-----------+----+-------------+--------------+----------------+
Figure 3: Ciphersuites Figure 3: Ciphersuites
Ciphersuite 1, which is based on AES as a cryptographic primitive, is Ciphersuite 1, which is based on AES as a cryptographic primitive,
mandatory to implement. This document specifies also a second MUST be implemented. This document specifies also a second
ciphersuite, but its support is optional. Both ciphersuites defined ciphersuite, which MAY be implemented. Both ciphersuites defined in
in this document make use of the GKDF, as defined in Section 6. The this document make use of the GKDF, as defined in Section 7. The
following aspects need to be considered to ensure that the PSK that following aspects need to be considered to ensure that the PSK that
is used as input to the GKDF is sufficiently long (in case it is is used as input to the GKDF is sufficiently long (in case it is
longer it needs to be truncated): longer it needs to be truncated):
1. The PSK used with ciphersuite 1 MUST be 128 bits in length or 1. The PSK used with ciphersuite 1 MUST be 128 bits in length or
longer. longer.
2. The PSK used with ciphersuite 2 MUST be 256 bits in length or 2. The PSK used with ciphersuite 2 MUST be 256 bits in length or
longer. longer.
3. It is RECOMMENDED that 256 bit keys be provisioned in all cases 3. It is RECOMMENDED that 256 bit keys be provisioned in all cases
to provide enough entropy for all current and many possible to provide enough entropy for all current and many possible
future ciphersuites. future ciphersuites.
Ciphersuites defined in the future that make use of the GKDF need to Ciphersuites defined in the future that make use of the GKDF need to
specify a minimum PSK size (as it is done with the ciphersuites specify a minimum PSK size (as it is done with the ciphersuites
listed in this document). listed in this document).
6. Generalized Key Derivation Function (GKDF) 7. Generalized Key Derivation Function (GKDF)
Each ciphersuite needs to specify a key derivation function. The Each ciphersuite needs to specify a key derivation function. The
ciphersuites defined in this document make use of the Generalized Key ciphersuites defined in this document make use of the Generalized Key
Derivation Function (GKDF) that utilizes the MAC function defined in Derivation Function (GKDF) that utilizes the MAC function defined in
the ciphersuite. Future ciphersuites can use any other formally the ciphersuite. Future ciphersuites can use any other formally
specified KDF that takes as arguments a key and a seed value, and specified KDF that takes as arguments a key and a seed value, and
produces at least 128+2*KS octets of output. produces at least 128+2*KS octets of output.
GKDF has the following structure: GKDF has the following structure:
skipping to change at page 12, line 41 skipping to change at page 13, line 43
M_i = MAC_Y (i || Z); M_i = MAC_Y (i || Z);
result = result || M_i; result = result || M_i;
} }
return truncate(result, X) return truncate(result, X)
} }
Note that the variable 'i' in M_i is represented as a 2-octet value Note that the variable 'i' in M_i is represented as a 2-octet value
in network byte order. in network byte order.
7. Ciphersuites Processing Rules 8. Ciphersuites Processing Rules
7.1. Ciphersuite #1 8.1. Ciphersuite #1
7.1.1. Encryption 8.1.1. Encryption
With this ciphersuite all cryptography is built around a single With this ciphersuite all cryptography is built around a single
cryptographic primitive, AES-128 ([AES]). Within the protected data cryptographic primitive, AES-128 ([AES]). Within the protected data
frames, AES-128 is used in Cipher Block Chaining (CBC) mode of frames, AES-128 is used in Cipher Block Chaining (CBC) mode of
operation (see [CBC]). This EAP method uses encryption in a single operation (see [CBC]). This EAP method uses encryption in a single
payload, in the protected data payload (see Section 8.4). payload, in the protected data payload (see Section 9.4).
In a nutshell, the CBC mode proceeds as follows. The IV is XORed In a nutshell, the CBC mode proceeds as follows. The IV is XORed
with the first plaintext block before it is encrypted. Then for with the first plaintext block before it is encrypted. Then for
successive blocks, the previous ciphertext block is XORed with the successive blocks, the previous ciphertext block is XORed with the
current plaintext, before it is encrypted. current plaintext, before it is encrypted.
7.1.2. Integrity 8.1.2. Integrity
Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is Ciphersuite 1 uses CMAC as Message Authentication Code. CMAC is
recommended by NIST. Among its advantages, CMAC is capable to work recommended by NIST. Among its advantages, CMAC is capable to work
with messages of arbitrary length. A detailed description of CMAC with messages of arbitrary length. A detailed description of CMAC
can be found in [CMAC]. can be found in [CMAC].
The following instantiation is used: AES-CMAC-128(SK, Input) denotes The following instantiation is used: AES-CMAC-128(SK, Input) denotes
the MAC of Input under the key SK. the MAC of Input under the key SK where Input refers to the following
content:
where Input refers to the following content:
o Value of SEC_SK(Value) in message GPSK-2
o Value of SEC_SK(Value) in message GPSK-3
o Value of SEC_SK(Value) in message GPSK-4
7.1.3. Key Derivation
This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
MK = GKDF-16 (PSK[0..15], PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-160 (MK, inputString)[64..127]
SK = GKDF-160 (MK, inputString)[128..143]
PK = GKDF-160 (MK, inputString)[144..159]
zero = 0x00 || 0x00 || ... || 0x00 (16 times)
Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type || o Parameter within SEC_SK(Parameter) in message GPSK-2
CSuite_Sel || inputString) o Parameter within SEC_SK(Parameter) in message GPSK-3
o Parameter within SEC_SK(Parameter) in message GPSK-4
7.2. Ciphersuite #2 8.2. Ciphersuite #2
7.2.1. Encryption 8.2.1. Encryption
Ciphersuite 2 does not include an algorithm for encryption. With a Ciphersuite 2 does not include an algorithm for encryption. With a
NULL encryption algorithm, encryption is defined as: NULL encryption algorithm, encryption is defined as:
E_X(Y) = Y E_X(Y) = Y
When using this ciphersuite, the data exchanged inside the protected When using this ciphersuite, the data exchanged inside the protected
data block is not encrypted. Therefore this mode MUST NOT be used if data block is not encrypted. Therefore this mode MUST NOT be used if
confidential information appears inside the protected data block. confidential information appears inside the protected data block.
7.2.2. Integrity 8.2.2. Integrity
Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash
algorithm (see [RFC4634]). algorithm (see [RFC4634]).
For integrity protection the following instantiation is used: For integrity protection the following instantiation is used:
HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK
where Input refers to the following content: where Input refers to the following content:
o Value of SEC_SK(Value) in message GPSK-2 o Parameter within SEC_SK(Parameter) in message GPSK-2
o Value of SEC_SK(Value) in message GPSK-3 o Parameter within SEC_SK(Parameter) in message GPSK-3
o Value of SEC_SK(Value) in message GPSK-4 o Parameter within SEC_SK(Parameter) in message GPSK-4
7.2.3. Key Derivation
This ciphersuite instantiates the KDF in the following way:
inputString = RAND_Peer || ID_Peer || RAND_Server || ID_Server
MK = GKDF-32 (PSK[0..31], PL || PSK || CSuite_Sel || inputString)
MSK = GKDF-160 (MK, inputString)[0..63]
EMSK = GKDF-160 (MK, inputString)[64..127]
SK = GKDF-160 (MK, inputString)[128..159]
zero = 0x00 || 0x00 || ... || 0x00 (32 times)
Method-ID = GKDF-16 (zero, "Method ID" || EAP_Method_Type ||
CSuite_Sel || inputString)
8. Packet Formats 9. Packet Formats
This section defines the packet format of the EAP-GPSK messages. This section defines the packet format of the EAP-GPSK messages.
8.1. Header Format 9.1. Header Format
The EAP-GPSK header has the following structure: The EAP-GPSK header has the following structure:
--- bit offset ---> --- bit offset --->
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | | | Type | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... Payload ... ... Payload ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 5
The Code, Identifier, Length, and Type fields are all part of the EAP The Code, Identifier, Length, and Type fields are all part of the EAP
header, and defined in [RFC3748]. IANA has allocated EAP Method Type header, and defined in [RFC3748]. The Type field in the EAP header
XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX. MUST be the value allocated by IANA for EAP-GPSK.
The OP-Code field is one of four values: The OP-Code field is one of four values:
o 0x01 : GPSK-1 o 0x01 : GPSK-1
o 0x02 : GPSK-2 o 0x02 : GPSK-2
o 0x03 : GPSK-3 o 0x03 : GPSK-3
o 0x04 : GPSK-4 o 0x04 : GPSK-4
o 0x05 : GPSK-Fail o 0x05 : GPSK-Fail
o 0x06 : GPSK-Protected-Fail o 0x06 : GPSK-Protected-Fail
All other values of this OP-Code field are available via IANA All other values of this OP-Code field are available via IANA
registration. registration.
8.2. Ciphersuite Formatting 9.2. Ciphersuite Formatting
Ciphersuites are encoded as 6-octet arrays. The first four octets Ciphersuites are encoded as 6-octet arrays. The first four octets
indicate the CSuite/Vendor field. For vendor-specific ciphersuites, indicate the CSuite/Vendor field. For vendor-specific ciphersuites,
this represents the vendor Object Identifier (OID) contains the IANA this represents the vendor enterprise number and contains the IANA
assigned "SMI Network Management Private Enterprise Codes" value (see assigned "SMI Network Management Private Enterprise Codes" value (see
[RFC3232]), encoded in network byte order. The last two octets [ENTNUM]), encoded in network byte order. The last two octets
indicate the CSuite/Specifier field, which identifies the particular indicate the CSuite/Specifier field, which identifies the particular
ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates ciphersuite. The 4-octet CSuite/Vendor value 0x00000000 indicates
ciphersuites allocated by the IETF. ciphersuites allocated by the IETF.
Graphically, they are represented as Graphically, they are represented as
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Vendor = 0x00000000 or OID | | CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier | | CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 6
CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and
CSuite/Specifier pair. CSuite/Specifier pair.
CSuite_List is a variable-length octet array of ciphersuites. It is CSuite_List is a variable-length octet array of ciphersuites. It is
encoded by concatenating encoded ciphersuite values. Its length in encoded by concatenating encoded ciphersuite values. Its length in
octets MUST be a multiple of 6. octets MUST be a multiple of 6.
8.3. Payload Formatting 9.3. Payload Formatting
Payload formatting is based on the protocol exchange description in Payload formatting is based on the protocol exchange description in
Section 3. Section 3.
The GPSK-1 payload format is defined as follows: The GPSK-1 payload format is defined as follows:
--- bit offset ---> --- bit offset --->
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 51 skipping to change at page 18, line 51
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 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_Block)=0 and the PD payload is excluded. length(PD_Payload_Block)=0 and the PD payload is excluded. The
payload MAC covers the entire packet, from the ID_Client length, up
through the optional PD_Payload_Block.
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_Peer ... ... 32-octet RAND_Peer ...
| | | |
skipping to change at page 19, line 41 skipping to change at page 19, line 42
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... 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_Block)=0 and the PD payload is excluded. length(PD_Payload_Block)=0 and the PD payload is excluded. The
payload MAC covers the entire packet, from the RAND_Peer, up through
the optional PD_Payload_Block.
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_Block) | | | length(PD_Payload_Block) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
skipping to change at page 20, line 25 skipping to change at page 20, line 25
| | | |
... 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_Block)=0 and the PD payload is excluded. The MAC length(PD_Payload_Block)=0 and the PD payload is excluded. The MAC
MUST always be included, regardless of the presence of MUST always be included, regardless of the presence of
PD_Payload_Block. PD_Payload_Block. The payload MAC covers the entire packet, from the
PD_Payload_Block length up through the optional 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 21, line 19 skipping to change at page 21, line 31
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
All other values of this field are available via IANA registration. All other values of this field are available via IANA registration.
"PSK Not Found" indicates a key for a particular user could not be "PSK Not Found" indicates a key for a particular user could not be
located, making authentication impossible. "Authentication Failure" located, making authentication impossible. "Authentication Failure"
indicates a MAC failure due to a PSK mismatch. "Authorization indicates a MAC failure due to a PSK mismatch. "Authorization
Failure" indicates that while the PSK being used is correct, the user Failure" indicates that while the PSK being used is correct, the user
is not authorized to connect. is not authorized to connect.
8.4. Protected Data 9.4. Protected Data
The protected data blocks are a generic mechanism for the peer and The protected data blocks are a generic mechanism for the peer and
server to securely exchange data. If the specified ciphersuite has a server to securely exchange data. If the specified ciphersuite has a
NULL encryption primitive, then this channel only offers NULL encryption primitive, then this channel only offers
authenticity, and not confidentiality. authenticity, and not confidentiality.
These payloads are encoded as the concatenation of type-length-value These payloads are encoded as the concatenation of type-length-value
(TLV) triples called PD_Payloads. (TLV) triples called PD_Payloads.
Type values are encoded as a 6-octet string and represented by a Type values are encoded as a 6-octet string and represented by a
4-octet vendor and 2-octet specifier field. The vendor field 4-octet vendor and 2-octet specifier field. The vendor field
indicates the type as either standards-specified or vendor-specific. indicates the type as either standards-specified or vendor-specific.
If these four octets are 0x00000000, then the value is standards- If these four octets are 0x00000000, then the value is standards-
specified, and any other value represents a vendor-specific Object specified, and any other value represents a vendor-specific
Identifier (OID). enterprise number.
The specifier field indicates the actual type. For vendor field The specifier field indicates the actual type. For vendor field
0x00000000, the specifier field is maintained by IANA. For any other 0x00000000, the specifier field is maintained by IANA. For any other
vendor field, the specifier field is maintained by the vendor. vendor field, the specifier field is maintained by the vendor.
Length fields are specified as 2-octet integers in network byte Length fields are specified as 2-octet integers in network byte
order, and reflect only the length of the value, and do not include order, and reflect only the length of the value, and do not include
the length of the type and length fields. the length of the type and length fields.
Graphically, this can be depicted as follows: Graphically, this can be depicted as follows:
skipping to change at page 22, line 30 skipping to change at page 22, line 34
These PD_Payloads are concatenated together to form a These PD_Payloads are concatenated together to form a
PD_Payload_Block. The If the CSuite_Sel includes support for PD_Payload_Block. The If the CSuite_Sel includes support for
encryption, then the PD_Payload_Block includes fields specifying an encryption, then the PD_Payload_Block includes fields specifying an
initialization vector (IV), and the necessary padding. This can be initialization vector (IV), and the necessary padding. This can be
depicted as follows: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector | | IV Length | |
... (length is block size for encryption algorithm) ... +-+-+-+-+-+-+-+-+ Initialization Vector +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... PD_Payload ... ... PD_Payload ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload, etc ... ... optional PD_Payload, etc ...
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 22, line 46 skipping to change at page 23, line 4
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload, etc ... ... optional PD_Payload, etc ...
| | | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) | | | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length | | | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Block (PD_Payload_Block) Formatting if Encryption Protected Data Block (PD_Payload_Block) Formatting if Encryption
Supported Supported
The Initialization Vector is a randomly chosen value whose length is The Initialization Vector is a randomly chosen value whose length is
equal to the block length of the underlying encryption algorithm. equal to the specified IV Length. The required length is defined by
the ciphersuite. Recipients MUST accept any value. Senders SHOULD
Recipients MUST accept any value. Senders SHOULD either pick this either pick this value pseudo-randomly and independently for each
value pseudo-randomly and independently for each message or use the message or use the final ciphertext block of the previous message
final ciphertext block of the previous message sent. Senders MUST sent. Senders MUST NOT use the same value for each message, use a
NOT use the same value for each message, use a sequence of values sequence of values with low hamming distance (e.g., a sequence
with low hamming distance (e.g., a sequence number), or use number), or use ciphertext from a received message. IVs should be
ciphertext from a received message. selected per the security requirements of the underlying cipher. If
the data is not being encrypted, then the IV Length MUST be 0. If
the ciphersuite does not require an IV, or has a self-contained way
of communicating the IV, then the IV Length field MUST be 0. In
these cases the ciphersuite definition defines how the IV is
encapsulated in the PD_Payload.
The concatenation of PD_Payloads along with the padding and padding The concatenation of PD_Payloads along with the padding and padding
length are all encrypted using the negotiated block cipher. If no length are all encrypted using the negotiated block cipher. If no
block cipher is specified, then these fields are not encrypted. block cipher is specified, then these fields are not encrypted.
The Padding field MAY contain any value chosen by the sender, and The Padding field MAY contain any value chosen by the sender. For
MUST have a length that makes the combination of the concatenation of block-based cipher modes, the padding MUST have a length that makes
PD_Payloads, the Padding, and the Pad Length to be a multiple of the the combination of the concatenation of PD_Payloads, the Padding, and
encryption block size. the Pad Length to be a multiple of the encryption block size. If the
underlying ciphersuite does not require padding (e.g. a stream-based
cipher mode) or no encryption is being used, then the padding length
MUST still be present and be zero.
The Pad Length field is the length of the Padding field. The sender 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 SHOULD set the Pad Length to the minimum value that makes the
combination of the PD_Payloads, the Padding, and the Pad Length a combination of the PD_Payloads, the Padding, and the Pad Length a
multiple of the block size, but the recipient MUST accept any length multiple of the block size (in the case of block-based cipher modes),
that results in proper alignment. This field is encrypted with the but the recipient MUST accept any length that results in proper
negotiated cipher. alignment. This field is encrypted with the negotiated cipher.
If the negotiated ciphersuite does not support encryption, then the If the negotiated ciphersuite does not support encryption, then the
padding field MUST be of length zero. The padding length field MUST IV field MUST be of length zero and padding field MUST be of length
still be present, and contain the value zero. This is depicted in zero. The IV length and padding length fields MUST still be present,
the following figure. and contain the value zero. The rationale for still requiring the
length fields is to allow for modular implementations where the
crypto processing is independent of the payload processing. This is
depicted in the following figure.
--- 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | 0x00 | |
... PD_Payload ... +-+-+-+-+-+-+-+-+ PD_Payload ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 | | | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Block (PD_Payload_Block) Formatting Without Encryption Protected Data Block (PD_Payload_Block) Formatting Without Encryption
For PData/Vendor field 0x000000, the following PData/Specifier fields For PData/Vendor field 0x000000, the following PData/Specifier fields
skipping to change at page 24, line 4 skipping to change at page 24, line 22
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload, etc +-+-+-+-+-+-+-+-+ ... optional PD_Payload, etc +-+-+-+-+-+-+-+-+
| | 0x00 | | | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Block (PD_Payload_Block) Formatting Without Encryption Protected Data Block (PD_Payload_Block) Formatting Without Encryption
For PData/Vendor field 0x000000, the following PData/Specifier fields For PData/Vendor field 0x000000, the following PData/Specifier fields
are defined: are defined:
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication
All other values of this field are available via IANA registration. All other values of this field are available via IANA registration.
8.4.1. Protected Results Indication 10. Packet Processing Rules
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, which does
not require confidentiality protection, MUST only be sent in GPSK-3
from the EAP server to the EAP peer.
9. Packet Processing Rules
This section defines how the EAP peer and EAP server MUST behave when This section defines how the EAP peer and EAP server MUST behave when
received packet is deemed invalid. received packet is deemed invalid.
Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP
server MUST be silently discarded. An EAP peer or EAP server server MUST be silently discarded. An EAP peer or EAP server
receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3 receiving any unexpected packet (e.g., an EAP peer receiving GPSK-3
before receiving GPSK-1 or before transmitting GPSK-2) MUST silently before receiving GPSK-1 or before transmitting GPSK-2) MUST silently
discard the packet. discard the packet.
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 peer. Note that the ciphersuite list MUST be accepted by the peer. If the EAP peer has no ciphersuites in
provided by the EAP server in CSuite_List MUST always include the common with the server or decides the ID_Server is that of a AAA
mandatory-to-implement ciphersuite defined in this document. Hence, server to which it does not wish to authenticate, the EAP peer MUST
there is always at least one ciphersuite in common between the EAP respond with an EAP-NAK.
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
EAP peer should respond with an EAP-NAK.
For GPSK-2, if ID_Peer 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. If the
discard the received packet. If the MAC validation fails, the server MAC validation fails, the server MUST transmit a GPSK-Fail message
MUST transmit a GPSK-Fail message specifying "Authentication Failure" specifying "Authentication Failure" and discard the received packet.
and discard the received packet. If the RAND_Server or CSuite_List If the RAND_Server or CSuite_List field in GPSK-2 does not match the
field in GPSK-2 does not match the values in GPSK-1, the server MUST values in GPSK-1, the server MUST silently discard the packet. If
silently discard the packet. If server policy determines the peer is server policy determines the peer is not authorized and the MAC is
not authorized and the MAC is correct, the server MUST transmit a correct, the server MUST transmit a GPSK-Protected-Fail message
GPSK-Protected-Fail message indicating "Authorization Failure" and indicating "Authorization Failure" and discard the received packet.
discard the received packet.
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in
response to a GPSK-2 message MUST replay the received GPSK-Fail / response to a GPSK-2 message MUST replay the received GPSK-Fail /
GPSK-Protected-Fail message. Then, the EAP server returns an EAP- GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
to correctly finish the EAP conversation. If MAC validation on a to correctly finish the EAP conversation. If MAC validation on a
GPSK-Protected-Fail packet fails, then the received packet MUST be GPSK-Protected-Fail packet fails, then the received packet MUST be
silently discarded. silently discarded.
For GPSK-3, a peer MUST silently discard messages where the For GPSK-3, a peer MUST silently discard messages where the
RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those RAND_Peer, the RAND_Server, or the CSuite_Sel fields do match those
transmitted in GPSK-2. An EAP peer MUST silently discard any packet transmitted in GPSK-2. An EAP peer MUST silently discard any packet
whose MAC fails. whose MAC fails.
For GPSK-4, a server MUST silently discard any packet whose MAC fails For GPSK-4, a server MUST silently discard any packet whose MAC fails
validation. validation.
If a decryption failure of a protected payload is detected, the If a decryption failure of a protected payload is detected, the
recipient MUST silently discard the GPSK packet. recipient MUST silently discard the GPSK packet.
10. Example Message Exchanges 11. Example Message Exchanges
This section shows a couple of example message flows. This section shows a couple of example message flows.
A successful EAP-GPSK message exchange is shown in Figure 1. A successful EAP-GPSK message exchange is shown in Figure 1.
+--------+ +--------+ +--------+ +--------+
| | EAP-Request/Identity | | | | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP | | EAP |<------------------------------------| EAP |
| peer | | server | | peer | | server |
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
skipping to change at page 27, line 4 skipping to change at page 26, line 30
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 (GPSK-Fail | | | | EAP-Response/GPSK-4 (GPSK-Fail | |
| | (PSK Not Found or Authentication | | | | (PSK Not Found or Authentication | |
| | Failure)) | | | | Failure)) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Unknown user)
EAP-GPSK: Unsuccessful Exchange (Unknown user)
+--------+ +--------+ +--------+ +--------+
| | 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 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
skipping to change at page 28, line 33 skipping to change at page 28, line 33
| | GPSK-Protected-Fail | | | | GPSK-Protected-Fail | |
| | (Authorization Failure) | | | | (Authorization Failure) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Authorization failure) EAP-GPSK: Unsuccessful Exchange (Authorization failure)
11. Security Considerations 12. 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].
11.1. Mutual Authentication 12.1. Security Claims
Auth. mechanism: Shared Keys
Ciphersuite negotiation: Yes (section 11.15)
Mutual authentication: Yes (section 11.1)
Integrity protection: Yes (section 11.3)
Replay protection: Yes (section 11.4)
Confidentiality: No (section 11.14 and 11.16)
Key derivation: Yes (section 11.7)
Key strength: Varies (section 11.7)
Dictionary attack prot.: No (section 11.6)
Fast reconnect: No (section 11.13)
Crypt. binding: N/A (section 11.17)
Session independence: Yes (section 11.9)
Fragmentation: No (section 11.11)
Channel binding: Extensible (section 11.12)
12.2. Mutual Authentication
EAP-GPSK provides mutual authentication. EAP-GPSK provides mutual authentication.
The server believes that the peer is authentic when it successfully The server believes that the peer is authentic when it successfully
verifies the MAC in the GPSK-2 message and the peer believes that the verifies the MAC in the GPSK-2 message and the peer believes that the
server is authentic when it successfully verifies the MAC it receives server is authentic when it successfully verifies the MAC it receives
with the GPSK-3 message. with the GPSK-3 message.
The key used for mutual authentication is derived based on the long- The key used for mutual authentication is derived based on the long-
term secret PSK, nonces contributed by both parties and other term secret PSK, nonces contributed by both parties and other
parameters. The long-term secret PSK has to provide sufficient parameters. The long-term secret PSK has to provide sufficient
entropy and therefore sufficient strength. The nonces (RAND_Peer and entropy and therefore sufficient strength. The nonces (RAND_Peer and
RAND_Server) need to be fresh and unique for every session. In this RAND_Server) need to be fresh and unique for every session. In this
way EAP-GPSK is not different than other authentication protocols way EAP-GPSK is not different than other authentication protocols
based on pre-shared keys. based on pre-shared keys.
11.2. Protected Result Indications 12.3. Protected Result Indications
EAP-GPSK offers the capability to exchange protected result EAP-GPSK supports protected results indication via the GPSK-
indications using the protected data payloads. Protected-Fail message. This allows a server to provide additional
information to the peer as to why the session failed, and do so in an
authenticated way (if possible). In particular, the server can
indicate the lack of PSK (account not present), failed authentication
(PSK incorrect), or authorization failure (account disabled or
unauthorized). Only the third message could be integrity protected.
11.3. Integrity Protection It should be noted that these options make debugging network and
account errors easier, but also leak information about accounts to
attackers. An attacker can determine if a particular ID_Peer is a
valid user on the network, or not. Thus implementers should use care
in enabling this particular option on their servers. If they are in
an environment where such attacks are of concern, then protected
result indication capabilities should be disabled.
12.4. Integrity Protection
EAP-GPSK provides integrity protection based on the ciphersuites EAP-GPSK provides integrity protection based on the ciphersuites
suggested in this document. Integrity protection is a minimum suggested in this document. Integrity protection is a minimum
feature every ciphersuite must provide. feature every ciphersuite must provide.
11.4. Replay Protection 12.5. Replay Protection
EAP-GPSK provides replay protection of its mutual authentication part EAP-GPSK provides replay protection of its mutual authentication part
thanks to the use of random numbers RAND_Server and RAND_Peer. Since thanks to the use of random numbers RAND_Server and RAND_Peer. Since
RAND_Server is 32 octets long, one expects to have to record 2**64 RAND_Server is 32 octets long, one expects to have to record 2**64
(i.e., approximately 1.84*10**19) EAP-GPSK successful authentication (i.e., approximately 1.84*10**19) EAP-GPSK successful authentication
before an protocol run can be replayed. Hence, EAP-GPSK provides before an protocol run can be replayed. Hence, EAP-GPSK provides
replay protection of its mutual authentication part as long as replay protection of its mutual authentication part as long as
RAND_Server and RAND_Peer are chosen at random, randomness is RAND_Server and RAND_Peer are chosen at random, randomness is
critical for replay protection. RFC 4086 [RFC4086] describes critical for replay protection. RFC 4086 [RFC4086] describes
techniques for producing random quantities. techniques for producing random quantities.
11.5. Reflection attacks 12.6. 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.
11.6. Dictionary Attacks Also note that EAP-GPSK does not provide MAC protection of the OP-
Code field, but again since each message is constructed differently,
it would not be possible to change the OP-Code of a valid message and
still have it be parseable and accepted by the recipient.
EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based 12.7. Dictionary Attacks
on at least 16 octets of entropy to guarantee security against
dictionary attacks. Users who use passwords are not guaranteed
protection against dictionary attacks. Derivation of the long-term
shared secret from a password is strongly discouraged.
11.7. Key Derivation EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be
based on at least 16 octets of entropy to be fully secure. The EAP-
GPSK protocol makes no special provisions to ensure keys based on
passwords are used securely. Users who use passwords as the basis of
their PSK are not protected against dictionary attacks. Derivation
of the long-term shared secret from a password is strongly
discouraged.
12.8. Key Derivation and Key Strength
EAP-GPSK supports key derivation as shown in Section 4. EAP-GPSK supports key derivation as shown in Section 4.
11.8. Denial of Service Resistance Keys used within EAP-GPSK are all based on the security of the
originating PSK. PSKs SHOULD have at least 16 octets of entropy.
Independent of the protocol exchange (i.e. without knowing RAND_Peer
and RAND_Server), the keys have been derived with sufficient input
entropy to make them as secure as the underlying KDF output key
length.
There are two forms of denial of service attacks relevant for this 12.9. Denial of Service Resistance
document, namely attacks that lead to vast amount of state being
allocated and attacks against the computational resources. The There are three forms of denial of service attacks relevant for this
latter onces are less problematic for EAP-GPSK since all computations document, namely (1) attacks that lead to vast amount of state being
are lightweight. We will consider the former one in more detail allocated, (2) attacks that attempt to prevent communication between
below. the peer and server, and (3) attacks against computational resources.
In an EAP-GPSK conversation the server has to maintain state, namely In an EAP-GPSK conversation the server has to maintain state, namely
the 32-octet RAND_Server, when transmitting the GPSK-1 message to the the 32-octet RAND_Server, when transmitting the GPSK-1 message to the
peer. An adversary could therefore flood a server with a large peer. An adversary could therefore flood a server with a large
number of EAP-GPSK communication attempts. An EAP server may number of EAP-GPSK communication attempts. An EAP server may
therefore ensure that established state times out after a relatively therefore ensure that established state times out after a relatively
short period of time when no further messages are received. This short period of time when no further messages are received. This
enables a sort of garbage collection. enables a sort of garbage collection.
The client would have to potentially keep state information after The client has to keep state information after receiving the GPSK-1
receiving the GPSK-1 message. Section 4.2 of [HM2004] describes a message. To prevent a replay attack, all the client need do is
short of client-side denial of service attack and illustrates three ensure that the value of RAND_Peer is consistent between GPSK-2 and
possible solutions to avoid having the client to keep state when GPSK-3. Message GPSK-3 contains all the material required to re-
receiving the first message. When the client receives the GPSK-3 compute the keying material. Thus a client need only maintain
message then it needs to derive keying material based on the minimal state (RAND_Peer) between GPSK-2 and GPSK-3.
following information: RAND_Peer, ID_Peer, RAND_Server, ID_Server,
RAND_Peer, RAND_Server. Hence, GPSK-3 includes all necessary Attacks that disrupt communication between the peer and server are
parameters to allow the client to (a) avoid allocating state mitigated by silently discarding messages with invalid MACs. Attacks
information with the arrival of GPSK-1 and (b) to enable deriving the against computational resources are mitigated by having very light-
keying material. weight cryptographic operations required during each protocol round.
The security considerations of EAP itself, see Section 5.2 and The security considerations of EAP itself, see Section 5.2 and
Section 7 of RFC 3748 [RFC3748], are also applicable to this Section 7 of RFC 3748 [RFC3748], are also applicable to this
specification (e.g., for example concerning EAP-based notifications). specification (e.g., for example concerning EAP-based notifications).
11.9. Session Independence 12.10. Session Independence
Thanks to its key derivation mechanisms, EAP-GPSK provides session Thanks to its key derivation mechanisms, EAP-GPSK provides session
independence: passive attacks (such as capture of the EAP independence: passive attacks (such as capture of the EAP
conversation) or active attacks (including compromise of the MSK or conversation) or active attacks (including compromise of the MSK or
EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs. EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.
The assumption that RAND_Peer and RAND_Server are random is central The assumption that RAND_Peer and RAND_Server are random is central
for the security of EAP-GPSK in general and session independence in for the security of EAP-GPSK in general and session independence in
particular. particular.
11.10. Exposition of the PSK 12.11. Compromise 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 (e.g. those with different
same server. ID_Peer values) communicating with the 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.
11.11. Fragmentation 12.12. Fragmentation
EAP-GPSK does not support fragmentation and reassembly since the EAP-GPSK does not support fragmentation and reassembly since the
message size is relatively small. message size is relatively small. However it should be noted that
this impacts the length of protected data payloads that can be
attached to messages. Also if the EAP frame is larger than the MTU
of the underlying transport, and that transport does not support
fragmentation, the frame will most likely not be transported.
Consequently implementors and deployers should take care to ensure
EAP-GPSK frames are short enough to work properly on the target
underlying transport mechanism.
11.12. Channel Binding 12.13. 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.
11.13. Fast Reconnect 12.14. 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.
11.14. Identity Protection 12.15. 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.
11.15. Protected Ciphersuite Negotiation 12.16. Protected Ciphersuite Negotiation
EAP-GPSK provides protected ciphersuite negotiation via the EAP-GPSK provides protected ciphersuite negotiation via the
indication of available ciphersuites by the server in the first indication of available ciphersuites by the server in the first
message and a confirmation by the peer in the subsequent message. message and a confirmation by the peer in the subsequent message.
Note, however, that the GPSK-2 message may optionally contain a Note, however, that the GPSK-2 message may optionally contain a
payload, ENC_PK(PD_Payload_Block), protected with an algorithm based payload, ENC_PK(PD_Payload_Block), protected with an algorithm based
on a selected ciphersuite before the ciphersuite list has actually on a selected ciphersuite before the ciphersuite list has actually
been authenticated. In the classical downgrading attack an adversary been authenticated. In the classical downgrading attack an adversary
would chose a ciphersuite that it weak enough to that it could break would chose a ciphersuite that it weak enough to that it could break
it in real-time or to turn security off. The latter is not possible it in real-time or to turn security off. The latter is not possible
since any ciphersuite defined for EAP-GPSK must at least provide since any ciphersuite defined for EAP-GPSK must at least provide
authentication and integrity protection. Confidentity protection is authentication and integrity protection. Confidentiality protection
optional. When, some time in the future, a ciphersuite contains is optional. When, some time in the future, a ciphersuite contains
algorithms that can be broken in real-time then a policy on peers and algorithms that can be broken in real-time then a policy on peers and
the server needs to indicate that such a ciphersuite must not be the server needs to indicate that such a ciphersuite must not be
selected by any of parties. selected by any of parties.
Furthermore, an adversay may modify the selection of the ciphersuite Furthermore, an adversary may modify the selection of the ciphersuite
to for the client to select a ciphersuite that does not provide to for the client to select a ciphersuite that does not provide
confidentity protection. As a result this would cause the content of confidentiality protection. As a result this would cause the content
PD_Payload_Block to be transmitted in cleartext. When protocol of PD_Payload_Block to be transmitted in cleartext. When protocol
designers extend EAP-GPSK to carry information in the designers extend EAP-GPSK to carry information in the
PD_Payload_Block of the GPSK-2 message then it must be indicated PD_Payload_Block of the GPSK-2 message then it must be indicated
whether confidentiality protection is mandatory. In case such an whether confidentiality protection is mandatory. In case such an
extension requires a ciphersuite with confidentiality protection then extension requires a ciphersuite with confidentiality protection then
the policy at the peer must not transmit information of that the policy at the peer must not transmit information of that
extension in the PD_Payload_Block of the GPSK-2 message. The peer extension in the PD_Payload_Block of the GPSK-2 message. The peer
may, if possible, delay the transmission of this information element may, if possible, delay the transmission of this information element
to the GPSK-4 message where the ciphersuite negotiation has been to the GPSK-4 message where the ciphersuite negotiation has been
confirmed already. In general, when a ciphersuite is selected that confirmed already. In general, when a ciphersuite is selected that
does not provide confidentiality protection then information that does not provide confidentiality protection then information that
demands confidentility protection must not be included in any of the demands confidentiality protection must not be included in any of the
PD_Payload_Block objects. PD_Payload_Block objects.
11.16. Confidentiality 12.17. 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]
since it does not support identity protection.
11.17. Cryptographic Binding 12.18. 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.
12. IANA Considerations 13. IANA Considerations
This document requires IANA to allocate a new EAP Type for EAP-GPSK. This document requires IANA to allocate a new EAP Type for EAP-GPSK.
This document requires IANA to create a new registry for This document requires IANA to create a new registry for
ciphersuites, protected data types, failure codes and op-codes. IANA ciphersuites, protected data types, failure codes and op-codes. IANA
is furthermore instructed to add the specified ciphersuites, is furthermore instructed to add the specified ciphersuites,
protected data types, failure codes and op-codes to these registries protected data types, failure codes and op-codes to these registries
as defined in this document. Values can be added or modified with as defined below. Values can be added or modified per IETF CONSENSUS
informational RFCs defining either block-based or hash-based [RFC2434] defining either block-based or hash-based ciphersuites,
ciphersuites, protected data payloads, failure codes and op-codes. protected data payloads, failure codes and op-codes. Each
Each ciphersuite needs to provide processing rules and needs to ciphersuite needs to provide processing rules and needs to specify
specify how the following algorithms are instantiated: encryption, how the following algorithms are instantiated: encryption, integrity,
integrity, key derivation and key length. key derivation and key length.
Figure 3 represents the initial ciphersuite CSuite/Specifier registry Figure 3 represents the initial ciphersuite CSuite/Specifier registry
setup. The CSuite/Specifier field is 16 bits long. All other values setup. The CSuite/Specifier field is 16 bits long. All other values
are available via IANA registration. are available via IANA registration. This registry should be named
"EAP-GPSK Ciphersuites".
The following is the initial protected data PData/Specifier registry The following is the initial protected data PData/Specifier registry
setup: setup, which should be named "EAP-GPSK Protected Data Payloads":
o 0x000000 : Reserved o 0x000000 : Reserved
o 0x000001 : Protected Results Indication
The PData/Specifier field is 24 bits long and all other values are The PData/Specifier field is 24 bits long and all other values are
available via IANA registration. Each extension needs to indicate available via IANA registration. Each extension needs to indicate
whether confidentiality protection for transmission between the EAP whether confidentiality protection for transmission between the EAP
peer and the EAP server is mandatory. The following layout peer and the EAP server is mandatory.
represents the initial Failure-Code registry setup:
The following layout represents the initial Failure-Code registry
setup, which should be named "EAP-GPSK Failure Codes":
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
The Failure-Code field is 32 bits long and all other values are The Failure-Code field is 32 bits long and all other values are
available via IANA registration. The following layout represents the available via IANA registration.
initial OP-Code registry setup:
The following layout represents the initial OP-Code registry setup,
which should be named "EAP-GPSK OP Codes":
o 0x01 : GPSK-1 o 0x01 : GPSK-1
o 0x02 : GPSK-2 o 0x02 : GPSK-2
o 0x03 : GPSK-3 o 0x03 : GPSK-3
o 0x04 : GPSK-4 o 0x04 : GPSK-4
o 0x05 : GPSK-Fail o 0x05 : GPSK-Fail
o 0x06 : GPSK-Protected-Fail o 0x06 : GPSK-Protected-Fail
The OP-Code field is 8 bits long and all other values are available The OP-Code field is 8 bits long and all other values are available
via IANA registration. via IANA registration.
13. Contributors 14. 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 34, line 21 skipping to change at page 35, line 37
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.
14. Acknowledgments 15. Acknowledgments
We would like to thank We would like to thank
o Jouni Malinen and Bernard Aboba for their early draft comments in o Jouni Malinen and Bernard Aboba for their early draft comments in
June 2006. Jouni Malinen developed the first prototype June 2006. Jouni Malinen developed the first prototype
implementation. It can be found at: implementation. It can be found at:
http://hostap.epitest.fi/releases/snapshots/ http://hostap.epitest.fi/releases/snapshots/
o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela o Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela
Vanderveen and Ray Bell for their input to the ciphersuite Vanderveen and Ray Bell for their input to the ciphersuite
discussions between July and August 2006. discussions between July and August 2006.
skipping to change at page 35, line 4 skipping to change at page 36, line 22
o o
o Joe Salowey, the EMU working group chair, provided a document o Joe Salowey, the EMU working group chair, provided a document
review in April 2007. Jouni Malinen also reviewed the document review in April 2007. Jouni Malinen also reviewed the document
during the same month. during the same month.
o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov o We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov
and Prof. John C. Mitchell for their analysis of EAP-GPSK and for and Prof. John C. Mitchell for their analysis of EAP-GPSK and for
pointing us to a client-side DoS attack, a downgrading attack and pointing us to a client-side DoS attack, a downgrading attack and
their input to the key derivation function. Based on their input their input to the key derivation function. Based on their input
the key derivation function has been modified and the text in the the key derivation function has been modified and the text in the
security consideration section has been updated. security consideration section has been updated.
o Finally, we would like to thank our working group chair, Joe o Finally, we would like to thank our working group chair, Joe
Salowey, for his support and for the time he spend on discussing Salowey, for his support and for the time he spend on discussing
open issues with us. open issues with us.
15. References 16. References
15.1. Normative References 16.1. Normative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", Levkowetz, "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004. RFC 3748, June 2004.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005. Network Access Identifier", RFC 4282, December 2005.
15.2. Informative References
[I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress),
November 2007.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (SHA and HMAC-SHA)", RFC 4634, July 2006.
[AES] National Institute of Standards and Technology, [AES] National Institute of Standards and Technology,
"Specification for the Advanced Encryption Standard "Specification for the Advanced Encryption Standard
(AES)", Federal Information Processing Standards (AES)", Federal Information Processing Standards
(FIPS) 197, November 2001. (FIPS) 197, November 2001.
[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.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 16.2. Informative References
an On-line Database", RFC 3232, January 2002.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[HM2004] He, C. and J. Mitchell, "Analysis of the 802.11i 4-Way [ENTNUM] IANA, "SMI Network Management Private Enterprise Codes",
Handshake)", Proceedings of the Third ACM International IANA Assignments enterprise-numbers.
Workshop on Wireless Security (WiSe'04), Philadelphia,
PA pages 43-50, October 2004.
Authors' Addresses Authors' Addresses
T. Charles Clancy T. Charles Clancy
DoD Laboratory for Telecommunications Sciences DoD Laboratory for Telecommunications Sciences
8080 Greenmead Drive 8080 Greenmead Drive
College Park, MD 20740 College Park, MD 20740
USA USA
Email: clancy@ltsnet.net Email: clancy@ltsnet.net
skipping to change at page 37, line 7 skipping to change at page 38, line 7
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 108 change blocks. 
297 lines changed or deleted 312 lines changed or added

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