draft-ietf-emu-eap-gpsk-16.txt   draft-ietf-emu-eap-gpsk-17.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: May 1, 2009 Nokia Siemens Networks Expires: May 23, 2009 Nokia Siemens Networks
October 28, 2008 November 19, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-16 draft-ietf-emu-eap-gpsk-17
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 May 1, 2009. This Internet-Draft will expire on May 23, 2009.
Abstract Abstract
This Internet Draft defines an Extensible Authentication Protocol This Internet Draft defines an Extensible Authentication Protocol
(EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This (EAP) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This
method is a lightweight shared-key authentication protocol supporting method is a lightweight shared-key authentication protocol supporting
mutual authentication and key derivation. mutual authentication and key derivation.
Table of Contents Table of Contents
skipping to change at page 2, line 23 skipping to change at page 2, line 23
4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Key Management . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13 7. Generalized Key Derivation Function (GKDF) . . . . . . . . . . 13
8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13 8. Ciphersuites Processing Rules . . . . . . . . . . . . . . . . 13
8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13 8.1. Ciphersuite #1 . . . . . . . . . . . . . . . . . . . . . 13
8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13 8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 8.1.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14 8.2. Ciphersuite #2 . . . . . . . . . . . . . . . . . . . . . 14
8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14 8.2.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 14
8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14 8.2.2. Integrity . . . . . . . . . . . . . . . . . . . . . . 14
9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Header Format . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 28 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 . . . . . . . . . . . . . 31 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 . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . . . 34 12.17. Confidentiality . . . . . . . . . . . . . . . . . . . . . 34
12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34 12.18. Cryptographic Binding . . . . . . . . . . . . . . . . . . 34
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
skipping to change at page 6, line 14 skipping to change at page 6, line 14
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
truncate(A,B): Returns the first B octets of A truncate(A,B): Returns the first B octets of A
ENC_X(Y): Encryption of message Y with a symmetric key X, using a ENC_X(Y): Encryption of message Y with a symmetric key X, using a
defined block cipher defined block cipher
KDF_X(Y): Key Derivation Function that generates an arbitrary number KDF-X(Y): Key Derivation Function that generates an arbitrary number
of octets of output using secret X and seed Y of octets of output using secret X and seed Y
length(X): Function that returns the length of input X in octets, length(X): Function that returns the length of input X in octets,
encoded as a 2-octet integer in network byte order encoded as a 2-octet integer in network byte order
MAC_X(Y): Keyed message authentication code computed over Y with MAC_X(Y): Keyed message authentication code computed over Y with
symmetric key X symmetric key X
SEC_X(Y): SEC is a function that provides integrity protection based SEC_X(Y): SEC is a function that provides integrity protection based
on the chosen ciphersuite. The function SEC uses the algorithm on the chosen ciphersuite. The function SEC uses the algorithm
defined by the selected ciphersuite and applies it to the message defined by the selected ciphersuite and applies it to the message
content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y). content Y with key X. In short, SEC_X(Y) = Y || MAC_X(Y).
X[A..B]: Notation representing octets A through B of octet array X X[A..B]: Notation representing octets A through B of octet array X
where the first octet of the array has index zero
The following abbreviations are used for the keying material: The following abbreviations are used for the keying material:
EMSK: Extended Master Session Key is exported by the EAP method (64 EMSK: Extended Master Session Key is exported by the EAP method (64
octets) octets)
MK: Master Key between the peer and EAP server from which all other MK: A session-specific Master Key between the peer and EAP server
EAP method session keys are derived (KS octets) from which all other EAP method session keys are derived (KS
octets)
MSK: Master Session Key exported by the EAP method (64 octets) MSK: Master Session Key exported by the EAP method (64 octets)
PK: Session key generated from the MK and used during protocol PK: Session key generated from the MK and used during protocol
exchange to encrypt protected data (KS octets) exchange to encrypt protected data (KS octets)
PSK: Long-term key shared between the peer and the server (PL PSK: Long-term key shared between the peer and the server (PL
octets) octets)
SK: Session key generated from the MK and used during protocol SK: Session key generated from the MK and used during protocol
exchange to demonstrate knowledge of the PSK (KS octets) exchange to demonstrate knowledge of the PSK (KS octets)
3. Overview 3. Overview
The EAP framework (see Section 1.3 of [RFC3748]) defines three basic The EAP framework (see Section 1.3 of [RFC3748]) defines three basic
steps that occur during the execution of an EAP conversation between steps that occur during the execution of an EAP conversation between
the EAP peer, the Authenticator and the EAP server. the EAP peer, the Authenticator and the EAP server.
1. The first phase, discovery, is handled by the underlying protocol 1. The first phase, discovery, is handled by the underlying
(e.g. IEEE 802.1X as utilized by IEEE 802.11i). protocol, e.g. IEEE 802.1X as utilized by IEEE 802.11 [80211].
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 the 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
skipping to change at page 9, line 18 skipping to change at page 9, line 19
The decision which ciphersuite to offer and which ciphersuite to pick The decision which ciphersuite to offer and which ciphersuite to pick
is policy- and implementation-dependent and therefore outside the is policy- and implementation-dependent and therefore outside the
scope of this document. scope of this document.
In GPSK-2, the peer sends its identity ID_Peer and a random number In GPSK-2, the peer sends its identity ID_Peer and a random number
RAND_Peer. Furthermore, it repeats the received parameters of the RAND_Peer. Furthermore, it repeats the received parameters of the
GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected
ciphersuite. It computes a Message Authentication Code over all the ciphersuite. It computes a Message Authentication Code over all the
transmitted parameters. transmitted parameters.
The EAP server verifies the received Message Authentication Code. In The EAP server verifies the received Message Authentication Code, and
case of successful verification, the EAP server computes a Message consistency of the identities, nonces, and ciphersuite parameters
Authentication Code over the session parameter and returns it to the transmitted in GPSK-1. In case of successful verification, the EAP
peer (within GPSK-3). Within GPSK-2 and GPSK-3, peer and EAP server server computes a Message Authentication Code over the session
have the possibility to exchange encrypted protected data parameters. parameter and returns it to the peer (within GPSK-3). Within GPSK-2
and GPSK-3, peer and EAP server have the possibility to exchange
encrypted protected data parameters.
The peer verifies the received Message Authentication Code. If the The peer verifies the received Message Authentication Code, and
verification is successful, GPSK-4 is prepared. This message can consistency of the identities, nonces, and ciphersuite parameters
optionally contain the peer's protected data parameters. transmitted in GPSK-2. If the verification is successful, GPSK-4 is
prepared. This message can optionally contain the peer's protected
data parameters.
Upon receipt of GPSK-4, the server processes any included Upon receipt of GPSK-4, the server processes any included
PD_Payload_Block. Then, the EAP server sends an EAP Success message PD_Payload_Block. Then, the EAP server sends an EAP Success message
to indicate the successful outcome of the authentication. to indicate the successful outcome of the authentication.
4. Key Derivation 4. Key Derivation
EAP-GPSK provides key derivation in compliance to the requirements of EAP-GPSK provides key derivation in compliance to the requirements of
[RFC3748] and [RFC5247]. Note that this section provides an abstract [RFC3748] and [RFC5247]. Note that this section provides an abstract
description for the key derivation procedure that needs to be description for the key derivation procedure that needs to be
instantiated with a specific ciphersuite. instantiated with a specific ciphersuite.
The long-term credential shared between EAP peer and EAP server The long-term credential shared between EAP peer and EAP server
SHOULD be a strong pre-shared key PSK of at least 16 octets, though SHOULD be a strong pre-shared key PSK of at least 16 octets, though
its length and entropy is variable. While it is possible to use a its length and entropy is variable. While it is possible to use a
password or passphrase, doing so is NOT RECOMMENDED as it would make password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is
EAP-GPSK vulnerable to dictionary attacks. vulnerable to dictionary attacks.
During an EAP-GPSK authentication, a Master Key MK, a Session Key SK During an EAP-GPSK authentication, a Master Key MK, a Session Key SK
and a Protected Data Encryption Key PK (if using an encrypting and a Protected Data Encryption Key PK (if using an encrypting
ciphersuite) are derived using the ciphersuite-specified KDF and data ciphersuite) are derived using the ciphersuite-specified KDF and data
exchanged during the execution of the protocol, namely 'RAND_Peer || exchanged during the execution of the protocol, namely 'RAND_Peer ||
ID_Peer || RAND_Server || ID_Server' referred as inputString as its ID_Peer || RAND_Server || ID_Server' referred as inputString as its
short-hand form. short-hand form.
In case of successful completion, EAP-GPSK derives and exports an MSK In case of successful completion, EAP-GPSK derives and exports an MSK
and EMSK both in length of 64 octets. and EMSK both in length of 64 octets.
skipping to change at page 10, line 27 skipping to change at page 10, line 32
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)
The value for PL is encoded as a 2-octet integer in network byte The value for PL (the length of the PSK in octets) is encoded as a
order. 2-octet integer in network byte order. Recall that KS is the length
of the ciphersuite input key size in octets.
Additionally, the EAP keying framework [RFC5247] requires the Additionally, the EAP keying framework [RFC5247] requires the
definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These definition of a Method-ID, Session-ID, Peer-ID, and Server-ID. These
values are defined as: values are defined as:
o zero = 0x00 || 0x00 || ... || 0x00 (KS times) o Method-ID = KDF-16(PSK[0..KS-1], "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 = EAP_Method_Type || 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 1-octet IANA allocated EAP Type code EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code
value. 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 || |
skipping to change at page 12, line 22 skipping to change at page 12, line 22
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 (recall
that KS is the length of the ciphersuite input key length in octets,
and ML is the length of the MAC output in octets):
+------------+----+-------------+----+--------------+----------------+ +-----------+----+-------------+----+--------------+----------------+
| CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation | | CSuite/ | KS | Encryption | ML | Integrity / | Key Derivation |
| Specifier | | | | KDF MAC | Function | | Specifier | | | | KDF MAC | Function |
+------------+----+-------------+----+--------------+----------------+ +-----------+----+-------------+----+--------------+----------------+
| 0x00000001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF | | 0x0001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+------------+----+-------------+----+--------------+----------------+ +-----------+----+-------------+----+--------------+----------------+
| 0x00000002 | 32 | NULL | 32 | HMAC-SHA256 | GKDF | | 0x0002 | 32 | NULL | 32 | 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 38 skipping to change at page 15, line 41
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4 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 0x00 : Reserved
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.
skipping to change at page 21, line 20 skipping to change at page 21, line 20
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... ML-octet payload MAC ... ... ML-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: 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 0x00000000 : Reserved
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"
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.
9.4. Protected Data 9.4. Protected Data
skipping to change at page 25, line 13 skipping to change at page 25, line 13
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 RAND_Peer For GPSK-3, a peer MUST silently discard messages where the
or the CSuite_Sel fields do not match those transmitted in GPSK-2. RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those
An EAP peer MUST silently discard any packet whose MAC fails. transmitted in GPSK-2. An EAP peer MUST silently discard any packet
whose MAC fails.
For GPSK-4, a server MUST silently discard any packet whose MAC fails For GPSK-4, a server MUST silently discard any packet whose MAC fails
validation. validation.
If a decryption failure of a protected payload is detected, the If a decryption failure of a protected payload is detected, the
recipient MUST silently discard the GPSK packet. recipient MUST silently discard the GPSK packet.
11. 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.
skipping to change at page 30, line 25 skipping to change at page 30, line 25
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.
12.6. Reflection attacks 12.6. Reflection attacks
EAP-GPSK provides protection against reflection attacks in case of an Reflection attacks occur in bi-directional, challenge-response,
extended authentication because the messages are constructed in a mutual authentication protocols where an attacker, upon being issued
different fashion. a challenge by an authenticator responds by issuing the same
challenge back to the authenticator, obtaining the response, and then
"reflecting" that same response to the original challenge.
EAP-GPSK provides protection against reflection attacks because the
message formats for the challenges differ. The protocol does not
consist of two independent authentications, but rather the
authentications are tightly coupled.
Also note that EAP-GPSK does not provide MAC protection of the OP- Also note that EAP-GPSK does not provide MAC protection of the OP-
Code field, but again since each message is constructed differently, 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 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. still have it be parseable and accepted by the recipient.
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-
skipping to change at page 34, line 49 skipping to change at page 34, line 49
o 0x0000 : Reserved o 0x0000 : Reserved
The PData/Specifier field is 16 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 0x00000000 : Reserved
o 0x00000001: PSK Not Found o 0x00000001: PSK Not Found
o 0x00000002: Authentication Failure o 0x00000002: Authentication Failure
o 0x00000003: Authorization Failure o 0x00000003: Authorization Failure
The Failure-Code field is 32 bits long and all other values are The Failure-Code field is 32 bits long and all other values are
available via IANA registration. available via IANA registration.
The following layout represents the initial OP-Code registry setup, The following layout represents the initial OP-Code registry setup,
which should be named "EAP-GPSK OP Codes": which should be named "EAP-GPSK OP Codes":
o 0x00 : Reserved
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.
skipping to change at page 37, line 40 skipping to change at page 37, line 40
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[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.
[ENTNUM] IANA, "SMI Network Management Private Enterprise Codes", [ENTNUM] IANA, "SMI Network Management Private Enterprise Codes",
IANA Assignments enterprise-numbers. IANA Assignments enterprise-numbers.
[80211] "Information technology - Telecommunications and
Information Exchange Between Systems - Local and
Metropolitan Area Networks - Specific Requirements - Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications", IEEE Standard 802.11-2007,
March 2007.
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
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net 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
 End of changes. 31 change blocks. 
43 lines changed or deleted 69 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/