draft-ietf-emu-eap-gpsk-11.txt   draft-ietf-emu-eap-gpsk-12.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: January 30, 2009 Nokia Siemens Networks Expires: April 4, 2009 Nokia Siemens Networks
July 29, 2008 October 1, 2008
EAP Generalized Pre-Shared Key (EAP-GPSK) Method EAP Generalized Pre-Shared Key (EAP-GPSK) Method
draft-ietf-emu-eap-gpsk-11 draft-ietf-emu-eap-gpsk-12
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 January 30, 2009. This Internet-Draft will expire on April 4, 2009.
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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . 14 8.1.1. Encryption . . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . 16 9.2. Ciphersuite Formatting . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . 32 12.10. Session Independence . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . . 33
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
skipping to change at page 5, line 31 skipping to change at page 5, line 31
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 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.
ML: Integer representing the length of the MAC output, in octets, of
the selected ciphersuite CSuite_Sel.
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. 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)
skipping to change at page 9, line 48 skipping to change at page 10, line 27
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 The value for PL is encoded as a 2-octet integer in network byte
input length is equal to the MAC output length. This is generally order.
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. The value for PL is encoded as a 2-octet integer in
network byte order.
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
skipping to change at page 12, line 24 skipping to change at page 12, line 24
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 | ML | Integrity / | Key Derivation |
| Specifier | | | KDF MAC | Function | | Specifier | | | | KDF MAC | Function |
+------------+----+-------------+--------------+----------------+ +------------+----+-------------+----+--------------+----------------+
| 0x00000001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF | | 0x00000001 | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF |
+------------+----+-------------+--------------+----------------+ +------------+----+-------------+----+--------------+----------------+
| 0x00000002 | 32 | NULL | HMAC-SHA256 | GKDF | | 0x00000002 | 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 13, line 26 skipping to change at page 13, line 26
GKDF has the following structure: GKDF has the following structure:
GKDF-X(Y, Z) GKDF-X(Y, Z)
X length, in octets, of the desired output X length, in octets, of the desired output
Y secret key Y secret key
Z inputString Z inputString
GKDF-X (Y, Z) GKDF-X (Y, Z)
{ {
n = ceiling integer of ( X / KS ); n = ceiling integer of ( X / ML );
/* determine number of output blocks */ /* determine number of output blocks */
M_0 = "";
result = ""; result = "";
for i = 1 to n { for i = 1 to n {
M_i = MAC_Y (i || Z); result = result || MAC_Y (i || Z);
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.
8. Ciphersuites Processing Rules 8. Ciphersuites Processing Rules
skipping to change at page 18, line 44 skipping to change at page 18, line 44
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... ML-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 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_Peer 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.
skipping to change at page 19, line 35 skipping to change at page 19, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSuite_Sel | | CSuite_Sel |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | length(PD_Payload_Block) | | | length(PD_Payload_Block) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... ML-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: 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.
skipping to change at page 20, line 16 skipping to change at page 20, line 16
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) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | |
... optional PD_Payload_Block ... ... optional PD_Payload_Block ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... KS-octet payload MAC ... ... ML-octet payload MAC ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: 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.
skipping to change at page 21, line 12 skipping to change at page 21, line 12
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 ... ... 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 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 31, line 37 skipping to change at page 31, line 37
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 needs to do is message. To prevent a replay attack, all the client needs to do is
to ensure that the value of RAND_Peer is consistent between GPSK-2 to ensure that the value of RAND_Peer is consistent between GPSK-2
and 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, if a client chooses to implement compute the keying material. Thus, if a client chooses to implement
this client-side DoS protection mechanism it only needs to maintain this client-side DoS protection mechanism it only needs to maintain
minimal state (RAND_Peer) between GPSK-2 and GPSK-3. Otherwise, minimal state (RAND_Peer) between GPSK-2 and GPSK-3.
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).
 End of changes. 20 change blocks. 
36 lines changed or deleted 30 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/