draft-ietf-emu-eap-gpsk-09.txt   draft-ietf-emu-eap-gpsk-10.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: December 29, 2008 Nokia Siemens Networks Expires: January 6, 2009 Nokia Siemens Networks
June 27, 2008 July 5, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-09 draft-ietf-emu-eap-gpsk-10
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 December 29, 2008. This Internet-Draft will expire on January 6, 2009.
Copyright Notice
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
skipping to change at page 2, line 40 skipping to change at page 2, line 40
9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16 9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 16
9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16 9.3. Payload Formatting . . . . . . . . . . . . . . . . . . . 16
9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21 9.4. Protected Data . . . . . . . . . . . . . . . . . . . . . 21
10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24 10. Packet Processing Rules . . . . . . . . . . . . . . . . . . . 24
11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25 11. Example Message Exchanges . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 29 12.1. Security Claims . . . . . . . . . . . . . . . . . . . . . 28
12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29 12.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 29
12.3. Protected Result Indications . . . . . . . . . . . . . . 29 12.3. Protected Result Indications . . . . . . . . . . . . . . 29
12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30 12.4. Integrity Protection . . . . . . . . . . . . . . . . . . 30
12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 12.5. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30 12.6. Reflection attacks . . . . . . . . . . . . . . . . . . . 30
12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30 12.7. Dictionary Attacks . . . . . . . . . . . . . . . . . . . 30
12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 30 12.8. Key Derivation and Key Strength . . . . . . . . . . . . . 31
12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31 12.9. Denial of Service Resistance . . . . . . . . . . . . . . 31
12.10. Session Independence . . . . . . . . . . . . . . . . . . 31 12.10. Session Independence . . . . . . . . . . . . . . . . . . 32
12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32 12.11. Compromise of the PSK . . . . . . . . . . . . . . . . . . 32
12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32 12.12. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 32
12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32 12.13. Channel Binding . . . . . . . . . . . . . . . . . . . . . 32
12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 32 12.14. Fast Reconnect . . . . . . . . . . . . . . . . . . . . . 33
12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33 12.15. Identity Protection . . . . . . . . . . . . . . . . . . . 33
12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33 12.16. Protected Ciphersuite Negotiation . . . . . . . . . . . . 33
12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 33 12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34
12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34 12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
16.1. Normative References . . . . . . . . . . . . . . . . . . 36 16.1. Normative References . . . . . . . . . . . . . . . . . . 36
16.2. Informative References . . . . . . . . . . . . . . . . . 37 16.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 39
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 36 skipping to change at page 5, line 36
KS: Integer representing the input key size in octets of the KS: Integer representing the input key size in octets of the
selected ciphersuite CSuite_Sel. The key size is one of the selected ciphersuite CSuite_Sel. The key size is one of the
ciphersuite 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).
PL MUST be larger than or equal to KS.
RAND_Peer: Random integer generated by the peer (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
A**B: Integer exponentiation A**B: Integer exponentiation
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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 ("Peer") and EAP-GPSK performs mutual authentication between EAP peer ("Peer") and
EAP server ("Server") based on a pre-shared key (PSK). The protocol EAP server ("Server") based on a pre-shared key (PSK). The protocol
consists of four message exchanges (GPSK-1, ..., GPSK-4), in which consists of the message exchanges (GPSK-1, ..., GPSK-4), in which
both sides exchange nonces and their identities, compute and exchange both sides exchange nonces and their identities, compute and exchange
a Message Authentication Code (MAC) over the previously exchanged a Message Authentication Code (MAC) over the previously exchanged
values, keyed with the pre-shared key. This MAC is considered as values, keyed with the pre-shared key. This MAC is considered as
proof of possession of the pre-shared key. proof of possession of the pre-shared key. Two further messages,
namely GPSK-Fail and GPSK-Protected-Fail are used to deal with error
situations.
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 10, line 18 skipping to change at page 10, line 18
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
EAP_Method_Type refers to the integer value of the IANA allocated EAP EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code
Type code. value.
Figure 2 depicts the key derivation procedure of EAP-GPSK. Figure 2 depicts the key derivation procedure of EAP-GPSK.
+-------------+ +-------------------------------+ +-------------+ +-------------------------------+
| PL-octet | | RAND_Peer || ID_Peer || | | PL-octet | | RAND_Peer || ID_Peer || |
| PSK | | RAND_Server || ID_Server | | PSK | | RAND_Server || ID_Server |
+-------------+ +-------------------------------+ +-------------+ +-------------------------------+
| | | | | |
| +------------+ | | | +------------+ | |
| | CSuite_Sel | | | | | CSuite_Sel | | |
skipping to change at page 11, line 47 skipping to change at page 11, line 47
5. Key Management 5. Key Management
In order to be interoperable, PSKs must be entered in the same way on 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 both the peer and server. The management interface for entering PSKs
MUST support entering PSKs up to 64 octets in length as ASCII strings MUST support entering PSKs up to 64 octets in length as ASCII strings
and in hexadecimal encoding. and in hexadecimal encoding.
Additionally, the ID_Peer and ID_Server MUST be provisioned with the Additionally, the ID_Peer and ID_Server MUST be provisioned with the
PSK. Validation of these values is by a octet-wise comparison. Thus PSK. Validation of these values is by a octet-wise comparison. Thus
the management interface MUST allow entering values for the ID_Peer the management interface SHOULD support non-ASCII to allow entering
and ID_Server as ASCII strings up to 254 octets in length. values for the ID_Peer and ID_Server as ASCII strings up to 254
octets in length. For more information the reader is adviced to read
Section 2.4 of RFC 4282 [RFC4282].
6. Ciphersuites 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 four octets are the For a vendor-specific ciphersuite the first four octets are the
vendor-specific enterprise number contains the IANA assigned "SMI vendor-specific enterprise number contains the IANA assigned "SMI
Network Management Private Enterprise Codes" value (see [ENTNUM]), Network Management Private Enterprise Codes" value (see [ENTNUM]),
encoded in network byte order. The last two octets are vendor encoded in network byte order. The last two octets are vendor
assigned for the specific ciphersuite. A vendor code of 0x00000000 assigned for the specific ciphersuite. A vendor code of 0x00000000
indicates ciphersuites standardized by IETF in an IANA-maintained indicates ciphersuites standardized by IETF in an IANA-maintained
registry. registry.
The following ciphersuites are specified in this document: The following ciphersuites are specified in this document:
+-----------+----+-------------+--------------+----------------+ +------------+----+-------------+--------------+----------------+
| 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 | | 0x00000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF |
+-----------+----+-------------+--------------+----------------+ +------------+----+-------------+--------------+----------------+
| 0x000002 | 32 | NULL | HMAC-SHA256 | GKDF | | 0x00000002 | 32 | NULL | HMAC-SHA256 | GKDF |
+-----------+----+-------------+--------------+----------------+ +------------+----+-------------+--------------+----------------+
Figure 3: Ciphersuites Figure 3: Ciphersuites
Ciphersuite 1, which is based on AES as a cryptographic primitive, Ciphersuite 1, which is based on AES as a cryptographic primitive,
MUST be implemented. This document specifies also a second MUST be implemented. This document specifies also a second
ciphersuite, which MAY be implemented. Both ciphersuites defined in ciphersuite, which MAY be implemented. Both ciphersuites defined in
this document make use of the GKDF, as defined in Section 7. The this document make use of the GKDF, as defined in Section 7. The
following aspects need to be considered to ensure that the PSK that following aspects need to be considered to ensure that the PSK that
is used as input to the GKDF is sufficiently long (in case it is is used as input to the GKDF is sufficiently long (in case it is
longer it needs to be truncated): longer it needs to be truncated):
skipping to change at page 15, line 33 skipping to change at page 15, line 33
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length | | Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | OP-Code | | | Type | OP-Code | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... Payload ... ... Payload ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5 Figure 4
The Code, Identifier, Length, and Type fields are all part of the EAP The Code, Identifier, Length, and Type fields are all part of the EAP
header, and defined in [RFC3748]. The Type field in the EAP header header, and defined in [RFC3748]. The Type field in the EAP header
MUST be the value allocated by IANA for EAP-GPSK. MUST be the value allocated by IANA for EAP-GPSK.
The OP-Code field is one of four values: The OP-Code field is one of four values:
o 0x01 : GPSK-1 o 0x01 : GPSK-1
o 0x02 : GPSK-2 o 0x02 : GPSK-2
o 0x03 : GPSK-3 o 0x03 : GPSK-3
skipping to change at page 16, line 27 skipping to change at page 16, line 27
--- 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 enterprise number | | CSuite/Vendor = 0x00000000 or enterprise number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite/Specifier | | CSuite/Specifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 5
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.
9.3. Payload Formatting 9.3. Payload Formatting
skipping to change at page 17, line 26 skipping to change at page 17, line 26
... 32-octet RAND_Server ... ... 32-octet RAND_Server ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(CSuite_List) | | | length(CSuite_List) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... CSuite_List ... ... CSuite_List ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: GPSK-1 Payload Figure 6: 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_Peer) | | | length(ID_Peer) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
skipping to change at page 18, line 48 skipping to change at page 18, line 48
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: GPSK-2 Payload Figure 7: 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. The length(PD_Payload_Block)=0 and the PD payload is excluded. The
payload MAC covers the entire packet, from the ID_Client length, up payload MAC covers the entire packet, from the ID_Peer length, up
through the optional PD_Payload_Block. 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 39 skipping to change at page 19, line 39
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GPSK-3 Payload Figure 8: 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. The length(PD_Payload_Block)=0 and the PD payload is excluded. The
payload MAC covers the entire packet, from the RAND_Peer, up through payload MAC covers the entire packet, from the RAND_Peer, up through
the optional PD_Payload_Block. 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
skipping to change at page 20, line 20 skipping to change at page 20, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GPSK-4 Payload Figure 9: 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. The payload MAC covers the entire packet, from the PD_Payload_Block. The payload MAC covers the entire packet, from the
PD_Payload_Block length up through the optional PD_Payload_Block. 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: GPSK-Fail Payload Figure 10: GPSK-Fail Payload
The GPSK-Protected-Fail payload format is defined as follows: The GPSK-Protected-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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... KS-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: GPSK-Protected-Fail Payload Figure 11: GPSK-Protected-Fail Payload
The Failure-Code field is one of three values, but can be extended: The Failure-Code field is one of three values, but can be extended:
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
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"
skipping to change at page 22, line 13 skipping to change at page 22, line 13
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:
--- bit offset ---> --- bit offset --->
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PData/Vendor | ... | PData/Vendor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PData/Specifier | PData/Length | PData/Specifier | PData/Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... PData/Value ... ... PData/Value ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protected Data Payload (PD_Payload) Formatting Protected Data Payload (PD_Payload) Formatting
skipping to change at page 24, line 20 skipping to change at page 24, line 20
+-+-+-+-+-+-+-+-+ 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 0x00000000, the following PData/Specifier
are defined: fields are defined:
o 0x000000 : Reserved o 0x0000 : Reserved
All other values of this field are available via IANA registration. All other values of this field are available via IANA registration.
10. Packet Processing Rules 10. 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
skipping to change at page 24, line 46 skipping to change at page 24, line 46
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. If the EAP peer has no ciphersuites in MUST be accepted by the peer. If the EAP peer has no ciphersuites in
common with the server or decides the ID_Server is that of a AAA common with the server or decides the ID_Server is that of a AAA
server to which it does not wish to authenticate, the EAP peer MUST server to which it does not wish to authenticate, the EAP peer MUST
respond with an EAP-NAK. 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. If the "Authentication Failure" GPSK-Fail, depending on its policy. If the
MAC validation fails, the server MUST transmit a GPSK-Fail message MAC validation fails, the server MUST transmit a GPSK-Fail message
specifying "Authentication Failure" and discard the received packet. specifying "Authentication Failure". If the RAND_Server or
If the RAND_Server or CSuite_List field in GPSK-2 does not match the CSuite_List field in GPSK-2 does not match the values in GPSK-1, the
values in GPSK-1, the server MUST silently discard the packet. If server MUST silently discard the packet. If server policy determines
server policy determines the peer is not authorized and the MAC is the peer is not authorized and the MAC is correct, the server MUST
correct, the server MUST transmit a GPSK-Protected-Fail message transmit a GPSK-Protected-Fail message indicating "Authorization
indicating "Authorization Failure" and discard the received packet. Failure" and discard the received packet.
A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in A peer receiving a GPSK-Fail / GPSK-Protected-Fail message in
response to a GPSK-2 message MUST replay the received GPSK-Fail / response to a GPSK-2 message MUST replay the received GPSK-Fail /
GPSK-Protected-Fail message. Then, the EAP server returns an EAP- GPSK-Protected-Fail message. Then, the EAP server returns an EAP-
Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
to correctly finish the EAP conversation. If MAC validation on a to correctly finish the EAP conversation. If MAC validation on a
GPSK-Protected-Fail packet fails, then the received packet MUST be GPSK-Protected-Fail packet fails, then the received packet MUST be
silently discarded. silently discarded.
For GPSK-3, a peer MUST silently discard messages where the For GPSK-3, a peer MUST silently discard messages where the
skipping to change at page 26, line 17 skipping to change at page 26, line 17
| peer | | server | | peer | | server |
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | | | | EAP-Request/GPSK-Fail | |
| | (PSK Not Found or Authentication | | | | (PSK Not Found or Authentication | |
| | Failure)) | | | | Failure) | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 (GPSK-Fail | | | | EAP-Response/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 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 (GPSK-Fail | | | | EAP-Request/GPSK-Fail | |
| | (Authentication Failure)) | | | | (Authentication Failure) | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-4 (GPSK-Fail | | | | EAP-Response/GPSK-Fail | |
| | (Authentication Failure)) | | | | (Authentication Failure) | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Failure | | | | EAP-Failure | |
| |<------------------------------------| | | |<------------------------------------| |
+--------+ +--------+ +--------+ +--------+
EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2) EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
+--------+ +--------+ +--------+ +--------+
| | EAP-Request/Identity | | | | EAP-Request/Identity | |
| EAP |<------------------------------------| EAP | | EAP |<------------------------------------| EAP |
| peer | | server | | peer | | server |
| | EAP-Response/Identity | | | | EAP-Response/Identity | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-1 | | | | EAP-Request/GPSK-1 | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Response/GPSK-2 | | | | EAP-Response/GPSK-2 | |
| |------------------------------------>| | | |------------------------------------>| |
| | | | | | | |
| | EAP-Request/GPSK-3 | | | | EAP-Request/ | |
| | GPSK-Protected-Fail | | | | GPSK-Protected-Fail | |
| | (Authorization Failure) | | | | (Authorization Failure) | |
| |<------------------------------------| | | |<------------------------------------| |
| | | | | | | |
| | EAP-Request/GPSK-4 | | | | EAP-Request/ | |
| | 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)
skipping to change at page 29, line 8 skipping to change at page 28, line 45
[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].
12.1. Security Claims 12.1. Security Claims
Auth. mechanism: Shared Keys Auth. mechanism: Shared Keys
Ciphersuite negotiation: Yes (section 11.15) Ciphersuite negotiation: Yes (Section 12.16)
Mutual authentication: Yes (section 11.1) Mutual authentication: Yes (Section 12.2)
Integrity protection: Yes (section 11.3) Integrity protection: Yes (Section 12.4)
Replay protection: Yes (section 11.4) Replay protection: Yes (Section 12.5)
Confidentiality: No (section 11.14 and 11.16) Confidentiality: No (Section 12.17, Section 12.15)
Key derivation: Yes (section 11.7) Key derivation: Yes (Section 12.8)
Key strength: Varies (section 11.7) Key strength: Varies (Section 12.8)
Dictionary attack prot.: No (section 11.6) Dictionary attack prot.: No (Section 12.7)
Fast reconnect: No (section 11.13) Fast reconnect: No (Section 12.14)
Crypt. binding: N/A (section 11.17) Crypt. binding: N/A (Section 12.18)
Session independence: Yes (section 11.9) Session independence: Yes (Section 12.10)
Fragmentation: No (section 11.11) Fragmentation: No (Section 12.12)
Channel binding: Extensible (section 11.12) Channel binding: Extensible (Section 12.13)
12.2. Mutual Authentication 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.
skipping to change at page 30, line 47 skipping to change at page 30, line 44
12.7. Dictionary Attacks 12.7. Dictionary Attacks
EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be
based on at least 16 octets of entropy to be fully secure. The EAP- based on at least 16 octets of entropy to be fully secure. The EAP-
GPSK protocol makes no special provisions to ensure keys based on GPSK protocol makes no special provisions to ensure keys based on
passwords are used securely. Users who use passwords as the basis of passwords are used securely. Users who use passwords as the basis of
their PSK are not protected against dictionary attacks. Derivation their PSK are not protected against dictionary attacks. Derivation
of the long-term shared secret from a password is strongly of the long-term shared secret from a password is strongly
discouraged. discouraged.
The success of a dictionary attack against EAP-GPSK depends on the
strength of the long-term shared secret (PSK) it uses. The PSK used
by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least
2^128 bits large and whose distribution is uniformly random. Note
that this does not imply resistance to dictionary attack, only that
the probability of success in such an attack is acceptably remote.
12.8. Key Derivation and Key Strength 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.
Keys used within EAP-GPSK are all based on the security of the Keys used within EAP-GPSK are all based on the security of the
originating PSK. PSKs SHOULD have at least 16 octets of entropy. originating PSK. PSKs SHOULD have at least 16 octets of entropy.
Independent of the protocol exchange (i.e. without knowing RAND_Peer Independent of the protocol exchange (i.e. without knowing RAND_Peer
and RAND_Server), the keys have been derived with sufficient input and RAND_Server), the keys have been derived with sufficient input
entropy to make them as secure as the underlying KDF output key entropy to make them as secure as the underlying KDF output key
length. length.
skipping to change at page 31, line 26 skipping to change at page 31, line 32
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 has to keep state information after receiving the GPSK-1 The client has to keep state information after receiving the GPSK-1
message. To prevent a replay attack, all the client need do is message. To prevent a replay attack, all the client needs to do is
ensure that the value of RAND_Peer is consistent between GPSK-2 and to ensure that the value of RAND_Peer is consistent between GPSK-2
GPSK-3. Message GPSK-3 contains all the material required to re- and GPSK-3. Message GPSK-3 contains all the material required to re-
compute the keying material. Thus a client need only maintain compute the keying material. Thus, if a client chooses to implement
minimal state (RAND_Peer) between GPSK-2 and GPSK-3. this client-side DoS protection mechanism it only needs to maintain
minimal state (RAND_Peer) between GPSK-2 and GPSK-3. Otherwise,
storing state information about CSuite_Sel and RAND_Server is
necessary in order to determine whether these values correspond to
the onces previously sent in GPSK-2.
Attacks that disrupt communication between the peer and server are Attacks that disrupt communication between the peer and server are
mitigated by silently discarding messages with invalid MACs. Attacks mitigated by silently discarding messages with invalid MACs. Attacks
against computational resources are mitigated by having very light- against computational resources are mitigated by having very light-
weight cryptographic operations required during each protocol round. 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).
skipping to change at page 34, line 19 skipping to change at page 34, line 25
13. 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 below. Values can be added or modified per IETF CONSENSUS as defined below. Values can be added or modified per IETF CONSENSUS
[RFC2434] defining either block-based or hash-based ciphersuites, [RFC5226] defining either block-based or hash-based ciphersuites,
protected data payloads, failure codes and op-codes. Each protected data payloads, failure codes and op-codes. Each
ciphersuite needs to provide processing rules and needs to specify ciphersuite needs to provide processing rules and needs to specify
how the following algorithms are instantiated: encryption, integrity, how the following algorithms are instantiated: encryption, 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. This registry should be named are available via IANA registration. This registry should be named
"EAP-GPSK Ciphersuites". "EAP-GPSK Ciphersuites".
The following is the initial protected data PData/Specifier registry The following is the initial protected data PData/Specifier registry
setup, which should be named "EAP-GPSK Protected Data Payloads": setup, which should be named "EAP-GPSK Protected Data Payloads":
o 0x000000 : Reserved o 0x0000 : Reserved
The PData/Specifier field is 24 bits long and all other values are The PData/Specifier field is 16 bits long and all other values are
available via IANA registration. Each extension needs to indicate available via IANA registration. Each extension needs to indicate
whether confidentiality protection for transmission between the EAP whether confidentiality protection for transmission between the EAP
peer and the EAP server is mandatory. peer and the EAP server is mandatory.
The following layout represents the initial Failure-Code registry The following layout represents the initial Failure-Code registry
setup, which should be named "EAP-GPSK Failure Codes": setup, which should be named "EAP-GPSK Failure Codes":
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
skipping to change at page 35, line 40 skipping to change at page 36, line 4
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.
15. 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.
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 Bernard Aboba and Jouni Malinen for their review in February 2007.
o Vidya Narayanan for her review in March 2007. o Vidya Narayanan for her review in March 2007.
o Pasi Eronen for his IESG review in March and July 2008.
o Dan Harkins for his review in June 2008.
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.
skipping to change at page 36, line 39 skipping to change at page 36, line 49
[I-D.ietf-eap-keying] [I-D.ietf-eap-keying]
Aboba, B., Simon, D., and P. Eronen, "Extensible Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
draft-ietf-eap-keying-22 (work in progress), draft-ietf-eap-keying-22 (work in progress),
November 2007. 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 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
October 1998. May 2008.
[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.
[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.
skipping to change at page 37, line 44 skipping to change at page 38, line 17
T. Charles Clancy T. Charles Clancy
DoD Laboratory for Telecommunications Sciences DoD Laboratory for Telecommunications Sciences
8080 Greenmead Drive 8080 Greenmead Drive
College Park, MD 20740 College Park, MD 20740
USA USA
Email: clancy@ltsnet.net Email: clancy@ltsnet.net
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Linnoitustie 6
Munich, Bavaria 81739 Espoo 02600
Germany Finland
Email: Hannes.Tschofenig@nsn.com Phone: +358 (50) 4871445
URI: http://www.tschofenig.com Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
skipping to change at page 38, line 44 skipping to change at line 1624
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 49 change blocks. 
87 lines changed or deleted 100 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/