EMU Working Group                                              T. Clancy
Internet-Draft                                                       LTS
Intended status: Standards Track                           H. Tschofenig
Expires: July 9, August 10, 2007                   Siemens Networks GmbH & Co KG
                                                         January 5,
                                                        February 6, 2007

               EAP Generalized Pre-Shared Key (EAP-GPSK)
                       draft-ietf-emu-eap-gpsk-02
                     draft-ietf-emu-eap-gpsk-03.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   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
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on July 9, August 10, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This Internet Draft defines an Extensible Authentication Protocol
   method called EAP Generalized Pre-Shared Key (EAP-GPSK).  This method
   is a lightweight shared-key authentication protocol supporting mutual
   authentication and key derivation.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  7

   4.  Key Derivation . . . . . . . . . . . . . . . . . . . . . . . .  9

   5.  Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . . 10 11

   6.  Ciphersuites Processing Rules  . . . . . . . . . . . . . . . . 12 13
     6.1.   Ciphersuite #1  . . . . . . . . . . . . . . . . . . . . . . 12 13
       6.1.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . 12 13
       6.1.2.  Integrity  . . . . . . . . . . . . . . . . . . . . . . 12 13
       6.1.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . 13 14
     6.2.   Ciphersuite #2  . . . . . . . . . . . . . . . . . . . . . . 13 14
       6.2.1.  Encryption . . . . . . . . . . . . . . . . . . . . . . 13 14
       6.2.2.  Integrity  . . . . . . . . . . . . . . . . . . . . . . 13 14
       6.2.3.  Key Derivation . . . . . . . . . . . . . . . . . . . . 14 15

   7.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . . 14 15
     7.1.   Header Format . . . . . . . . . . . . . . . . . . . . . . 14 15
     7.2.   Ciphersuite Formatting  . . . . . . . . . . . . . . . . . . 15 16
     7.3.   Payload Formatting  . . . . . . . . . . . . . . . . . . . . 15 17
     7.4.   Protected Data  . . . . . . . . . . . . . . . . . . . . . 21
       7.4.1.  Protected Results Indication . . . 20 . . . . . . . . . . 24

   8.  Packet Processing Rules  . . . . . . . . . . . . . . . . . . . 21 24

   9.  Example Message Exchanges  . . . . . . . . . . . . . . . . . . 25

   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
     9.1. 28
     10.1.  Mutual Authentication . . . . . . . . . . . . . . . . . . 22
     9.2. 28
     10.2.  Protected Result Indications  . . . . . . . . . . . . . . . 22
     9.3. 29
     10.3.  Integrity Protection  . . . . . . . . . . . . . . . . . . . 23
     9.4. 29
     10.4.  Replay Protection . . . . . . . . . . . . . . . . . . . . 23
     9.5. 29
     10.5.  Reflection attacks  . . . . . . . . . . . . . . . . . . . . 23
     9.6. 29
     10.6.  Dictionary Attacks  . . . . . . . . . . . . . . . . . . . . 23
     9.7. 29
     10.7.  Key Derivation  . . . . . . . . . . . . . . . . . . . . . . 23
     9.8. 29
     10.8.  Denial of Service Resistance  . . . . . . . . . . . . . . . 23
     9.9. 29
     10.9.  Session Independence  . . . . . . . . . . . . . . . . . . . 24
     9.10. 30
     10.10. Exposition of the PSK . . . . . . . . . . . . . . . . . . 24
     9.11. 30
     10.11. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 24
     9.12. 31
     10.12. Channel Binding . . . . . . . . . . . . . . . . . . . . . 25
     9.13. 31
     10.13. Fast Reconnect  . . . . . . . . . . . . . . . . . . . . . . 25
     9.14. 31
     10.14. Identity Protection . . . . . . . . . . . . . . . . . . . 25
     9.15. 31
     10.15. Protected Ciphersuite Negotiation . . . . . . . . . . . . 25
     9.16. 31
     10.16. Confidentiality . . . . . . . . . . . . . . . . . . . . . 25
     9.17. 31
     10.17. Cryptographic Binding . . . . . . . . . . . . . . . . . . 25
   10. 31

   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25

   11. 31

   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 26

   12. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 27 32

   13. Open Issues Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . . . 27 33

   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 33
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . . 27 33
     14.2.  Informative References  . . . . . . . . . . . . . . . . . . 27 34

   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 34
   Intellectual Property and Copyright Statements . . . . . . . . . . 30 36

1.  Introduction

   EAP Generalized Pre-Shared Key (EAP-GPSK) is an EAP method defining a
   generalized pre-shared key authentication technique.  Mutual
   authentication is achieved through a nonce-based exchange that is
   secured by a pre-shared key.

   At present, several pre-shared key EAP methods are specified, most
   notably

   o  EAP-PAX [I-D.clancy-eap-pax] [RFC4746]
   o  EAP-PSK [I-D.bersani-eap-psk]
   o  EAP-TLS-PSK [I-D.otto-emu-eap-tls-psk] and
   o  EAP-SAKE [I-D.vanderveen-eap-sake].

   Each method has its particular benefits but also its particular
   deficiencies.  EAP-GPSK is a new EAP method that tries to combine the
   most valuable characteristics of each of these methods and therefore
   attempts to address a broad range of usage scenarios.

   The main design goals of EAP-GPSK are

   Simplicity:

      EAP-GPSK should be easy to implement and therefore quickly
      available.

   Wide applicability:

      EAP-GPSK has been designed in a threat model where the attacker
      has full control over the communication channel.  This is the EAP
      threat model that is presented in Section 7.1 of [RFC3748].

   Efficiency:

      EAP-GPSK does not make use of public key cryptography and fully
      relies of symmetric cryptography.  The restriction on symmetric
      cryptographic computations allows for low computational overhead.
      Hence, EAP-GPSK is lightweight and well suited for any type of
      device, especially those with processing power, memory and battery
      constraints.

   Flexibility:

      EAP-GPSK offers cryptographic flexibility.  At the beginning, the
      EAP server selects a set of cryptographic algorithms and key
      sizes, a so called ciphersuite.  The current version of EAP-GPSK
      comprises two ciphersuites, but additional ones can be easily
      added.

   Extensibility:

      The design of EAP-GPSK allows to securely exchange information
      between the EAP peer and the EAP server using protected data
      fields.  These fields might, for example, be used to exchange
      channel binding information or to provide support for identity
      confidentiality.

2.  Terminology

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

   This section describes the various variables and functions used in
   the EAP-GPSK method.

   Variables:

   PD_Payload_X:  Data carried within the X-th protected data payload

   CSuite_List:  An octet array listing available ciphersuites (variable
      length)

   CSuite_Sel:  Ciphersuite selected by the client (6 octets)

   ID_Client:  Client NAI [RFC2486bis] [RFC4282]

   ID_Server:  Server identity as an opaque blob.

   KS:  Integer representing the key size in octets of the selected
      ciphersuite CSuite_Sel. The key size is one of the ciphersuite
      parameters.

   PD_Payload:  Data carried within the protected data payload

   PD_Payload_Block:  Block of possibly multiple PD_Payloads carried by
      a GPSK packet

   PL:  Integer representing the length of the PSK in octets (2 octets)
   RAND_Client:  Random integer generated by the client (16 (32 octets)

   RAND_Server:  Random integer generated by the server (16 (32 octets)

   Operations:

   A || B:  Concatenation of octet strings A and B

   ENC_X(Y):  Encryption of message Y with a symmetric key X, using a
      defined block cipher

   KDF_X(Y):  Key Derivation Function that generates an arbitrary number
      of octets of output using secret X and seed Y

   length(X):  Function that returns the length of input X in octets,
      encoded as a 2-octet integer in network byte order

   MAC_X(Y):  Keyed message authentication code computed over Y with
      symmetric key X

   SEC_X(Y):  SEC is a function that provides integrity protection based
      on the chosen ciphersuite.  The function SEC uses the algorithm
      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). Y || MAC_X(Y).

   X[A..B]:  Notation representing octets A through B of octet array X

   The following abbreviations are used for the keying material:

   PK:  Session key generated from the MK and used during protocol
      exchange to encrypt protected data (size defined by ciphersuite)

   SK:  Session key generated from the MK and used during protocol
      exchange to demonstrate knowledge of the PSK (size defined by
      ciphersuite)

   EMSK:  Extended Master Session Key is exported by the EAP method (32 (64
      octets)

   MK:  Master Key between the client and EAP server from which all
      other EAP method session keys are derived (KS octets)
   MSK:  Master Session Key exported by the EAP method (32 (64 octets)

   MID:  Method ID exported by the EAP method according to the EAP
      keying framework [I-D.ietf-eap-keying] (16 octets).  The EAP
      Session-Id uniquely identifies an EAP authentication exchange
      between an EAP peer and an EAP server.

   PSK:  Long-term key shared between the client and the server (PL
      octets)

3.  Overview

   The EAP framework (see Section 1.3 of [RFC3748]) defines three basic
   steps that occur during the execution of an EAP conversation between
   the EAP peer, the Authenticator and the EAP server.

   1.  The first phase, discovery, is handled by the underlying
       protocol.
   2.  The EAP authentication phase with EAP-GPSK is defined in this
       document.
   3.  The secure association distribution and secure association phases
       are handled differently depending on the underlying protocol.

   EAP-GPSK performs mutual authentication between EAP peer ("Client")
   and EAP server ("Server") based on a pre-shared key (PSK).  The
   protocol consists of four message exchanges (GPSK-1, ..., GPSK-4), in
   which both sides exchange nonces and their identities, compute and
   exchange a Message Authentication Code (MAC) over the previously
   exchanged values, keyed with the pre-shared key.  This MAC is
   considered as proof of possession of the pre-shared key.

   A successful protocol exchange is shown in Figure 1.

   +--------+                                     +--------+
   |        |                EAP-Request/Identity |        |
   |  EAP   |<------------------------------------|  EAP   |
   |  peer  |                                     | server |
   |        | EAP-Response/Identity               |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-1 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-2                 |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-3 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-4                 |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |          EAP-Success or EAP-Failure                |        |
   |        |<------------------------------------|        |
   +--------+                                     +--------+

   EAP-GPSK performs mutual authentication between EAP peer ("Client")
   and EAP server ("Server") based on a pre-shared key (PSK).  The
   protocol consists of four message exchanges (GPSK-1, ...  GPSK-4), in
   which both sides exchange nonces and their identities, compute and
   exchange a Message Authentication Code (MAC) over the previously
   exchanged values, keyed with the pre-shared key.  This MAC is
   considered as proof of possession of the pre-shared key.

                  Figure 1: EAP-GPSK: Successful Exchange

   The full EAP-GPSK protocol is as follows:
   GPSK-1:

      ID_Server, RAND_Server, CSuite_List

   GPSK-2:

      SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_Sel,
      CSuite_List, [, ENC_PK(PD_Payload_1), ... CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )

   GPSK-3

      SEC_SK(RAND_Client, RAND_Server, CSuite_Sel [,
      ENC_PK(PD_Payload_2), ... CSuite_Sel, [
      ENC_PK(PD_Payload_Block) ] )

   GPSK-4:

      SEC_SK( [ SEC_SK(ENC_PK(PD_Payload_3)), ... ENC_PK(PD_Payload_Block) ] )

   The EAP server begins EAP-GPSK by selecting a random number
   RAND_Server and by encoding the supported ciphersuites into
   CSuite_List.  A ciphersuite consists of an encryption algorithm, a
   key derivation function and a message authentication code.

   In GPSK-1, the EAP server sends its identity ID_Server, a random
   number RAND_Server and a list of supported ciphersuites CSuite_List.
   The decision which ciphersuite to offer and which ciphersuite to pick
   is policy- and implementation-dependent and therefore outside the
   scope of this document.

   In GPSK-2, the peer sends its identity ID_Client, a random number
   RAND_Client.  Furthermore, it repeats the received parameters of the
   GPSK-1 message (ID_Server, RAND_Server, CSuite_List), the selected
   ciphersuite and computes a Message Authentication Code over all these
   parameters.

   The EAP server verifies the received Message Authentication Code.  In
   case of successful verification, the EAP server computes a Message
   Authentication Code over the session parameter and returns it to the
   client (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
   verification is successful, GPSK-4 is prepared.  This message can
   optionally contain the client's protected data parameters.

   Upon receipt of GPSK-4, the server assures that the peer has derived
   session keys SK and PK properly.  Then, the EAP server sends an EAP
   Success message to indicate the successful outcome of the
   authentication.

4.  Key Derivation

   EAP-GPSK provides key derivation in compliance to the requirements of
   [RFC3748] and [I-D.ietf-eap-keying].  Note that this section provides
   an abstract description for the key derivation procedure that needs
   to instantiated with a specific ciphersuite.

   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
   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
   EAP-GPSK vulnerable to dictionary attacks.

   During an EAP-GPSK authentication, a Master Key MK, a Session Key SK
   and a Protected Data Encryption Key PK are derived using the
   ciphersuite-specified KDF and data exchanged during the execution of
   the protocol, namely 'RAND_Client || ID_Client || RAND_Server ||
   ID_Server' referred as inputString as its short-hand form.

   In case of successful completion, EAP-GPSK derives and exports an MSK
   and EMSK both in length of 64 octets.

   The following notation is used: KDF-X(Y, Z)[A..B], whereby
   X  is the length, in octets, of the desired output,
   Y  is a secret key,
   Z  is the inputstring,
   [A..B]  extracts the string of octects starting with octet A
      finishing with octet B from the output of the KDF function.

   This keying material is derived using the ciphersuite-specified KDF
   as follows:

   o  inputString = RAND_Client || ID_Client || RAND_Server || ID_Server
   o  MK = KDF_Zero-String (PL KDF-KS(0x00, PL || PSK || CSuite_Sel || inputString)[0..KS-1]
   o  MSK = KDF_MK (inputString)[0..63] KDF-{128+2*KS}(MK, inputString)[0..63]
   o  EMSK = KDF_MK (inputString)[64..127] KDF-{128+2*KS}(MK, inputString)[64..127]
   o  SK = KDF_MK (inputString)[128..127+KS] KDF-{128+2*KS}(MK, inputString)[128..127+KS]
   o  PK = KDF_MK (inputString)[128+KS..127+2*KS] KDF-{128+2*KS}(MK, inputString)[128+KS..127+2*KS]
   o  MID = KDF_Zero-String ("Method KDF-16(0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
      inputString)[0..15]

   Note that the term 'Zero-String' refers to a sequence of 0x00 values,
   KS octets in length.

   EAP_Method_Type refers to the integer value of the IANA allocated EAP
   Type code.

   Figure 2 depicts the key derivation procedure of EAP-GPSK.

   +-------------+     +-------------------------------+
   |   PL-octet  |     | RAND_Client || ID_Client ||   |
   |     PSK     |     | RAND_Server || ID_Server      |
   +-------------+     +-------------------------------+
          |                            |            |
          |     +------------+         |            |
          |     | CSuite_Sel |         |            |
          |     +------------+         |            |
          |           |                |            |
          v           v                v            |
   +--------------------------------------------+   |
   |                    KDF                     |   |
   +--------------------------------------------+   |
                             |                      |
                             v                      |
                      +-------------+               |
                      |   KS-octet  |               |
                      |     MK      |               |
                      +-------------+               |
                             |                      |
                             v                      v
   +---------------------------------------------------+
   |                      KDF                          |
   +---------------------------------------------------+
        |             |             |            |
        v             v             v            v
   +---------+   +---------+  +----------+  +----------+
   | 32-octet| 64-octet|   | 32-octet| 64-octet|  | KS-octet |  | KS-octet |
   |   MSK   |   |  EMSK   |  |    SK    |  |   PK     |
   +---------+   +---------+  +----------+  +----------+

                     Figure 2: EAP-GPSK Key Derivation

5.  Ciphersuites

   The design of EAP-GPSK allows cryptographic algorithms and key sizes,
   called ciphersuites, to be negotiated during the protocol run.  The
   ability to specify block-based and hash-based ciphersuites is
   offered.  Extensibility is provided with the introduction of new
   ciphersuites; this document specifies an initial set.  The CSuite/
   Specifier column in Figure 3 uniquely identifies a ciphersuite.

   For a vendor-specific ciphersuite the first three octets are the
   vendor-specific OID, and the last three octets are vendor assigned
   for the specific ciphersuite.

   The following ciphersuites are specified in this document:

   +-----------+----+-------------+---------------+--------------------+

  +-----------+----+-------------+--------------+----------------------+
  | CSuite/   | KS | Encryption  | Integrity    | Key Derivation       |
  | Specifier |    |             |              | Function             |
   +-----------+----+-------------+---------------+--------------------+
  +-----------+----+-------------+--------------+----------------------+
  | 0x000001  | 16 | AES-CBC-128 | AES_CMAC_128 | GKDF-128 GKDF with SHA-1      |
   +-----------+----+-------------+---------------+--------------------+
  +-----------+----+-------------+--------------+----------------------+
  | 0x000002  | 32 | NULL        | HMAC-SHA256  | GKDF-256 GKDF with SHA256     |
   +-----------+----+-------------+---------------+--------------------+
  +-----------+----+-------------+--------------+----------------------+

                          Figure 3: Ciphersuites

   Ciphersuite 1, which is based on AES as a cryptographic primitive, is
   mandatory to implement.  This document specifies also a second
   ciphersuite, but its support is optional.

   Each ciphersuite needs to specify a key derivation function.  The
   ciphersuites defined in this document make use of the Generalized Key
   Distribution Function (GKDF).  Future ciphersuites can use any other
   formally specified KDF that takes as arguments a key and a seed
   value, and produces at least 128+2*KS octets of output.

   If GKDF is invoked by a MAC-based ciphersuite, then the variable
   "size" contains the MAC output size in octets.  In case of a block
   cipher-based ciphersuite, "size" contains the block size in octets.

   GKDF has the following structure:

   GKDF-X(Y, Z)

   X  length, in octets, of the desired output
   Y  secret key
   Z  inputstring
   hashlen:  is the size of hash function output in octets.
   Hash-Function:  SHA-1 is required, SHAs are recommended.  Hash function provided as part of the ciphersuite
      definition.

   GKDF-X (Y, Z) {
   n = ceiling integer of ( X / hashlen );
      /* determine number of output blocks */

   M_0 = "";
   result = "";

   for i = 1 to n {
     M_i = Hash-Function (i || y Y || Z);
     result = result || M_i;
   }

   return truncate (result; X) (result)
   }

   Note that the variables variable 'i' and 'X' in M_i are is represented as a 2-octet
   values value
   in network byte order.

6.  Ciphersuites Processing Rules

6.1.  Ciphersuite #1

6.1.1.  Encryption

   With this ciphersuite all cryptography is built around a single
   cryptographic primitive, AES-128.  Within the protected data frames,
   AES-128 is used in CBC Cipher Block Chaining (CBC) mode of operation (see
   [CBC]).  This mode
   requires an Initialization Vector (IV) that has the same size as the
   block size.  For security reasons, EAP method uses encryption in a single payload, in the IV should be randomly
   generated.
   protected data payload (see Section 7.4).

   In a nutshell, the CBC mode proceeds as follows.  The IV is XORed
   with the first plaintext block before it is encrypted.  Then for
   successive blocks, the previous ciphertext block is XORed with the
   current plaintext, before it is encrypted.

6.1.2.  Integrity

   Ciphersuite 1 uses CMAC as Message Authentication Code.  CMAC is
   recommended by NIST.  Among its advantages, CMAC is capable to work
   with messages of arbitrary length.  A detailed description of CMAC
   can be found in [CMAC].

   The following instantiation is used: AES-128-CMAC(SK, Input) denotes
   the MAC of Input under the key SK.

   where Input refers to the following content:

   o  Value of SEC_SK(Value) in message GPSK-2
   o  Value of SEC_SK(Value) in message GPSK-3
   o  Value of SEC_SK(Value) in message GPSK-4

6.1.3.  Key Derivation

   This ciphersuite instantiates the KDF in the following way:

   inputString = RAND_Client || ID_Client || RAND_Server || ID_Server

   MK = GKDF-16 (Zero-String, GKDF-32 (0x00, PL || PSK || CSuite_SEL CSuite_Sel || inputString)

   MSK = GKDF-160 (MK, inputString)[0..63]

   EMSK = GKDF-160 (MK, inputString)[64..127]

   SK = GKDF-160 (MK, inputString)[128..143]

   PK = GKDF-160 (MK, inputString)[144..159]

   MID = GKDF-16 (Zero-String, (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
   inputString)

   Hash-Function = SHA-1 (see [RFC3174])

   hashlen = 20 octets (160 bits)

6.2.  Ciphersuite #2

6.2.1.  Encryption

   Ciphersuite 2 does not include an algorithm for encryption.  With a
   NULL encryption algorithm, encryption is defined as:

   E_X(Y) = Y

   When using this ciphersuite, the data exchanged inside the protected
   data blocks is not encrypted.  Therefore this mode MUST NOT be used
   if confidential information appears inside the protected data blocks.

6.2.2.  Integrity

   Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash
   algorithm.

   For integrity protection the following instantiation is used:

   HMAC-SHA256(SK, Input) denotes the MAC of Input under the key SK
   where Input refers to the following content:

   o  Value of SEC_SK(Value) in message GPSK-2
   o  Value of SEC_SK(Value) in message GPSK-3
   o  Value of SEC_SK(Value) in message GPSK-4

6.2.3.  Key Derivation

   This ciphersuite instantiates the KDF in the following way:

   inputString = RAND_Client || ID_Client || RAND_Server || ID_Server

   MK = GKDF-32 (Zero-String, (0x00, PL || PSK || CSuite_SEL CSuite_Sel || inputString)

   MSK = GKDF-192 (MK, inputString)[0..63]

   EMSK = GKDF-192 (MK, inputString)[64..127]

   SK = GKDF-192 (MK, inputString)[128..159]

   PK = GKDF-192 (MK, inputString)[160..191]

   MID = GKDF-16 (Zero-String, (0x00, "Method ID" || EAP_Method_Type || CSuite_Sel ||
   inputString)

   Hash-Function = SHA256 (see [RFC4634])

   hashlen = 32 octets (256 bits)

7.  Packet Formats

   This section defines the packet format of the EAP-GPSK messages.

7.1.  Header Format

   The EAP-GPSK header has the following structure:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    OP-Code    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                         Payload                           ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 5

   The Code, Identifier, Length, and Type fields are all part of the EAP
   header, and defined in [RFC3748].  IANA has allocated EAP Method Type
   XX for EAP-GPSK, thus the Type field in the EAP header MUST be XX.

   The OP-Code field is one of four values:

   o  0x01 : GPSK-1
   o  0x02 : GPSK-2
   o  0x03 : GPSK-3
   o  0x04 : GPSK-4
   o  0x05 : GPSK-Fail
   o  0x06 : GPSK-Protected-Fail

7.2.  Ciphersuite Formatting

   Ciphersuites are encoded as 6-octet arrays.  The first three octets
   indicate the CSuite/Vendor field.  For vendor-specific ciphersuites,
   this represents the vendor OID.  The last three octets indicate the
   CSuite/Specifier field, which identifies the particular ciphersuite.
   The 3-octet CSuite/Vendor value 0x000000 indicates ciphersuites
   allocated by the IETF.

   Graphically, they are represented as

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        CSuite/Vendor = 0x000000 or OID        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          CSuite / Specifier       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                 Figure 6

   CSuite_Sel is encoded as a 6-octet ciphersuite CSuite/Vendor and
   CSuite/Specifier pair.

   CSuite_List is a variable-length octet array of ciphersuites.  It is
   encoded by concatenating encoded ciphersuite values.  Its length in
   octets MUST be a multiple of 6.

7.3.  Payload Formatting

   Payload formatting is based on the protocol exchange description in
   Section 3.

   The GPSK-1 payload format is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       length(ID_Server)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                         ID_Server                         ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                   32-octet RAND_Server                    ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      length(CSuite_List)      |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                        CSuite_List                        ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 7: GPSK-1 Payload

   The GPSK-2 payload format is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       length(ID_Client)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                         ID_Client                         ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       length(ID_Server)       |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                         ID_Server                         ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                    32-octet RAND_Client                   ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                    32-octet RAND_Server                   ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      length(CSuite_List)      |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                        CSuite_List                        ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           CSuite_Sel                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     length(PD_Payload_1)   length(PD_Payload_Block)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                 optional PD_Payload_1 PD_Payload_Block                 ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                   KS-octet payload MAC                    ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 8: GPSK-2 Payload

   If the optional protected data payload is not included, then
   length(PD_Payload)=0
   length(PD_Payload_Block)=0 and the PD payload is excluded.

   The GPSK-3 payload is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                    32-octet RAND_Client                   ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                    32-octet RAND_Server                   ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           CSuite_Sel                          |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     length(PD_Payload_2)   length(PD_Payload_Block)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                 optional PD_Payload_2 PD_Payload_Block                 ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                   KS-octet payload MAC                    ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 9: GPSK-3 Payload

   If the optional protected data payload is not included, then
   length(PD_Payload)=0
   length(PD_Payload_Block)=0 and the PD payload is excluded.

   The GPSK-4 payload format is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     length(PD_Payload_3)   length(PD_Payload_Block)    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   ...                 optional PD_Payload_3 PD_Payload_Block                 ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                   KS-octet payload MAC                    ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 10: GPSK-4 Payload

   If the optional protected data payload is not included, then
   length(PD_Payload)=0
   length(PD_Payload_Block)=0 and the PD payload is excluded.  The MAC
   MUST always be included, regardless of the presence of PD_Payload_3.
   PD_Payload_Block.

   The GPSK-Fail payload format is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Failure-Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 11: GPSK-Fail Payload

   The GPSK-Protected-Fail payload format is defined as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Failure-Code                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                   KS-octet payload MAC                    ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  Figure 12: GPSK-Protected-Fail Payload

   The Failure-Code field is one of three values, but can be extended:

   o  0x00000001: PSK Not Found
   o  0x00000002: Authentication Failure
   o  0x00000003: Authorization Failure
   o  0x00000004 through 0xFFFFFFFF : Unallocated

   "PSK Not Found" indicates a key for a particular user could not be
   located, making authentication impossible.  "Authentication Failure"
   indicates a MAC failure due to a PSK mismatch.  "Authorization
   Failure" indicates that while the PSK being used is correct, the user
   is not authorized to connect.

7.4.  Protected Data

   The protected data blocks are a generic mechanism for the client and
   server to securely exchange data.  If the specified ciphersuite has a
   NULL encryption primitive, then this channel only offers
   authenticity, and not confidentiality.

   These payloads are encoded as the concatenation of type-length-value
   (TLV) tripples. tripples called PD_Payloads.

   Type values are encoded as a 6-octet string and represented by a
   3-octet vendor and 3-octet specifier field.  The vendor field
   indicates the type as either standards-specified or vendor-specific.
   If these three octets are 0x000000, then the value is standards-
   specified, and any other value represents a vendor-specific OID.

   The specifier field indicates the actual type.  For vendor field
   0x000000, the specifier field is maintained by IANA.  For any other
   vendor field, the specifier field is maintained by the vendor.

   Length fields are specified as 2-octet integers in network byte
   order, and reflect only the length of the value, and do not include
   the length of the type and length fields.

   Graphically, this can be depicted as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   PData/Vendor                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            PData/Specifier        |            Length         PData/Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                      PD_Payload Value                        PData/Value                        ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   For PData/Vendor field 0x000000,

              Protected Data Payload (PD_Payload) Formatting

   These PD_Payloads are concatenated together to form a
   PD_Payload_Block.  The If the following PData/Specifier CSuite_Sel includes support for
   encryption, then the PD_Payload_Block includes fields
   are defined:
   o  0x000000 : Reserved
   o  0x000001 : Protected Results Indication
   o  0x000002 through 0xFFFFFF : Unallocated

8.  Packet Processing Rules

   This section defines how the EAP client specifying an
   initialization vector (IV), and EAP server MUST behave
   when received packet is deemed invalid.

   Any packet that cannot the necessary padding.  This can be parsed by
   depicted as follows:

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Initialization Vector                    |
   ...       (length is block size for encryption algorithm)     ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                        PD_Payload                         ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                 optional PD_Payload, etc                  ...
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Padding (0-255 octets)            |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                               |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Protected Data Block (PD_Payload_Block) Formatting if Encryption
                                 Supported

   The Initialization Vector is a randomly chosen value whose length is
   equal to the EAP client or block length of the EAP server underlying encryption algorithm.

   Recipients MUST be silently discarded.  An EAP client or EAP server receiving accept any unexpected packet (i.e. an EAP client receiving GPSK-3 before
   receving GPSK-1 value.  Senders SHOULD either pick this
   value pseudo-randomly and independently for each message or before transmitting GPSK-2) MUST silently discard
   the packet.

   GPSK-1 contains no MAC protection, so provided it properly parses, it
   MUST be accepted by use the client.  If
   final ciphertext block of the EAP client decides previous message sent.  Senders MUST
   NOT use the
   ID_Server is that same value for each message, use a sequence of values
   with low hamming distance (e.g., a AAA server to which it does not wish to
   authenticate, the EAP client should respond sequence number), or use
   ciphertext from a received message.

   The concatination of PD_Payloads along with an EAP-NACK.

   For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST
   send either a "PSK Not Found" GPSK-Fail message, or an
   "Authentication Failure" GPSK-Fail, depending on its policy, padding and
   discard padding
   length are all encrypted using the received packet. negotiated block cipher.  If no
   block cipher is specified, then these fields are not encrypted.

   The Padding field MAY contain any value chosen by the MAC validation fails, the server sender, and
   MUST transmit have a GPSK-Fail message specifying "Authentication
   Failure". length that makes the combination of the concatination of
   PD_Payloads, the Padding, and discard the received packet.  If Pad Length to be a multiple of the RAND_Server or
   CSuite_List
   encryption block size.

   The Pad Length field in GPSK-2 does not match is the values in GPSK-1, length of the
   server MUST silently discard Padding field.  The sender
   SHOULD set the packet.  If server policy determines Pad Length to the client is not authorized and minimum value that makes the MAC is correct,
   combination of the server MUST
   transmit a GPSK-Protected-Fail message indicating "Authorization
   Failure" PD_Payloads, the Padding, and discard the received packet.

   A client receiving a GPSK-Fail or GPSK-Protected-Fail message in
   response to Pad Length a GPSK-2 message
   multiple of the block size, but the recipient MUST either transmit an EAP-Failure
   message and end accept any length
   that results in proper alignment.  This field is encrypted with the session, or retry transmission of GPSK-2,
   attempting to correct whatever failure occured.
   negotiated cipher.

   If MAC validation on
   a GPSK-Protected-Fail packet fails, the negotiated ciphersuite does not support encryption, then the received packet
   padding field MUST be
   silently discarded.

   For GPSK-3, a client of length zero.  The padding length field MUST silently discard any packet containing
   whose RAND_Client, RAND_Server, or CSuite_Sel fields do match those
   transmitted
   still be present, and contain the value zero.  This is depicted in GPSK-2.  An
   the following figure.

   --- bit offset --->
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                        PD_Payload                         ...
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ...                 optional PD_Payload, etc    +-+-+-+-+-+-+-+-+
   |                                               |      0x00     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Protected Data Block (PD_Payload_Block) Formatting Without Encryption

   For PData/Vendor field 0x000000, the following PData/Specifier fields
   are defined:

   o  0x000000 : Reserved
   o  0x000001 : Protected Results Indication
   o  0x000002 through 0xFFFFFF : Unallocated

7.4.1.  Protected Results Indication

   Based on the PData/Specifier allocation the following 8-bit payload
   is specified to be placed in the PD_Payload Value to provide the
   functionality of protected results indication.

        0
        0 1 2 3 4 5 6 7
       +-+-+-+-+-+-+-+-+
       |I|R|R|R|R|R|R|R|
       +-+-+-+-+-+-+-+-+

        I: Result Indicator

           The bits have the following meaning:

           (0): Success
           (1): Failure

        R: Reserved
           These bits are used for padding.

   The 8 bits of protected results indication functionality MUST only be
   sent in GPSK-3 from the EAP server to the EAP client.

8.  Packet Processing Rules

   This section defines how the EAP client and EAP server MUST behave
   when received packet is deemed invalid.

   Any packet that cannot be parsed by the EAP client or the EAP server
   MUST be silently discarded.  An EAP client or EAP server receiving
   any unexpected packet (e.g., an EAP client receiving GPSK-3 before
   receiving GPSK-1 or before transmitting GPSK-2) MUST silently discard
   the packet.

   GPSK-1 contains no MAC protection, so provided it properly parses, it
   MUST be accepted by the client.  Note that the ciphersuite list
   provided by the EAP server in CSuite_List MUST always include the
   mandatory-to-implement ciphersuite defined in this document.  Hence,
   there is always at least one ciphersuite in common between the EAP
   peer and the EAP server.  If the EAP client decides the ID_Server is
   that of a AAA server to which it does not wish to authenticate, the
   EAP client should respond with an EAP-Nak.

   For GPSK-2, if ID_Client is for an unknown user, the EAP server MUST
   send either a "PSK Not Found" GPSK-Fail message, or an
   "Authentication Failure" GPSK-Fail, depending on its policy, and
   discard the received packet.  If the MAC validation fails, the server
   MUST transmit a GPSK-Fail message specifying "Authentication Failure"
   and discard the received packet.  If the RAND_Server or CSuite_List
   field in GPSK-2 does not match the values in GPSK-1, the server MUST
   silently discard the packet.  If server policy determines the client
   is not authorized and the MAC is correct, the server MUST transmit a
   GPSK-Protected-Fail message indicating "Authorization Failure" and
   discard the received packet.

   A client receiving a GPSK-Fail / GPSK-Protected-Fail message in
   response to a GPSK-2 message MUST replay the received GPSK-Fail /
   GPSK-Protected-Fail message.  Then, the EAP server returns an EAP-
   Failure after receiving the GPSK-Fail / GPSK-Protected-Fail message
   to correctly finish the EAP conversation.  If MAC validation on a
   GPSK-Protected-Fail packet fails, then the received packet MUST be
   silently discarded.

   For GPSK-3, a client MUST silently discard messages where the
   RAND_Client, the RAND_Server, or the CSuite_Sel fields do match those
   transmitted in GPSK-2.  An EAP client MUST silently discard any
   packet whose MAC fails.

   For GPSK-4, a server MUST silently discard any packet whose MAC fails
   validation.

   If a decryption failure of a protected payload is detected, the
   recipient MUST silently discard the GPSK packet.

9.  Example Message Exchanges

   This section shows a couple of example message flows.

   A successful EAP-GPSK message exchange is shown in Figure 1.

   +--------+                                     +--------+
   |        |                EAP-Request/Identity |        |
   |  EAP   |<------------------------------------|  EAP   |
   |  peer  |                                     | server |
   |        | EAP-Response/Identity               |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-1 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/EAP-Nak                |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |          EAP-Failure                |        |
   |        |<------------------------------------|        |
   +--------+                                     +--------+

    EAP-GPSK: Unsuccessful Exchange (Unacceptable AAA server identity;
                                ID_Server)

   +--------+                                     +--------+
   |        |                EAP-Request/Identity |        |
   |  EAP   |<------------------------------------|  EAP   |
   |  peer  |                                     | server |
   |        | EAP-Response/Identity               |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-1 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-2                 |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        | EAP-Request/GPSK-3 (GPSK-Fail       |        |
   |        | (PSK Not Found or AuthenFail)       |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-4 (GPSK-Fail)     |        |
   |        | (PSK Not Found or AuthenFail)       |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |          EAP-Failure                |        |
   |        |<------------------------------------|        |
   +--------+                                     +--------+

              EAP-GPSK: Unsuccessful Exchange (Unknown user)
   +--------+                                     +--------+
   |        |                EAP-Request/Identity |        |
   |  EAP   |<------------------------------------|  EAP   |
   |  peer  |                                     | server |
   |        | EAP-Response/Identity               |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-1 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-2                 |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        | EAP-Request/GPSK-3 (GPSK-Fail       |        |
   |        | (AuthenFail)                        |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-4 (GPSK-Fail)     |        |
   |        | (AuthenFail)                        |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |          EAP-Failure                |        |
   |        |<------------------------------------|        |
   +--------+                                     +--------+

          EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)
   +--------+                                     +--------+
   |        |                EAP-Request/Identity |        |
   |  EAP client MUST silently discard any
   packet whose MAC fails.

   For GPSK-4, a   |<------------------------------------|  EAP   |
   |  peer  |                                     | server MUST silently discard any packet whose MAC fails
   validation.

   If a decryption failure of a protected payload is detected, the
   recipient MUST silently discard the GPSK packet.

9. |
   |        | EAP-Response/Identity               |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |                  EAP-Request/GPSK-1 |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Response/GPSK-2                 |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        | EAP-Request/GPSK-3                  |        |
   |        | GPSK-Protected-Fail                 |        |
   |        | (Authorization Failure)             |        |
   |        |<------------------------------------|        |
   |        |                                     |        |
   |        | EAP-Request/GPSK-4                  |        |
   |        | GPSK-Protected-Fail                 |        |
   |        | (Authorization Failure)             |        |
   |        |------------------------------------>|        |
   |        |                                     |        |
   |        |          EAP-Failure                |        |
   |        |<------------------------------------|        |
   +--------+                                     +--------+

          EAP-GPSK: Unsuccessful Exchange (Authorization failure)

10.  Security Considerations

   [RFC3748] highlights several attacks that are possible against EAP
   since EAP itself does not provide any security.

   This section discusses the claimed security properties of EAP-GPSK as
   well as vulnerabilities and security recommendations in the threat
   model of [RFC3748].

9.1.

10.1.  Mutual Authentication

   EAP-GPSK provides mutual authentication.

   The server believes that the peer is authentic because it can
   calculate a valid MAC and the peer believes that the server is
   authentic because it can calculate another valid MAC.

   The key used for mutual authentication is computed again based on the
   long-term secret PSK that has to provide sufficient entropy and
   therefore sufficient strength.  In this way EAP-GPSK is no different
   than other authentication protocols based on pre-shared keys.

9.2.

10.2.  Protected Result Indications

   EAP-GPSK offers the capability to exchange protected result
   indications using the protected data payloads.

9.3.

10.3.  Integrity Protection

   EAP-GPSK provides integrity protection based on the ciphersuites
   suggested in this document.

9.4.

10.4.  Replay Protection

   EAP-GPSK provides replay protection of its mutual authentication part
   thanks to the use of random numbers RAND_Server and RAND_P. RAND_Client.
   Since RAND_Server is 16 32 octets long, one expects to have to record
   2**64 (i.e., approximately 1.84*10**19) EAP-GPSK successful
   authentication before an protocol run can be replayed.  Hence, EAP-GPSK EAP-
   GPSK provides replay protection of its mutual authentication part as
   long as RAND_Server and RAND_Client are chosen at random, randomness
   is critical for replay protection.

9.5.

10.5.  Reflection attacks

   EAP-GPSK provides protection against reflection attacks in case of an
   extended authentication because the messages are constructed in a
   different fashion.

9.6.

10.6.  Dictionary Attacks

   EAP-GPSK relies on a long-term shared secret (PSK) that MUST be based
   on at least 16 octets of entropy to guarantee security against
   dictionary attacks.  Users who use passwords are not guaranteed
   security against dictionary attacks.  Derivation of the long-term
   shared secret from a password is strongly discouraged.

9.7.

10.7.  Key Derivation

   EAP-GPSK supports key derivation as shown in Section 4.

9.8.

10.8.  Denial of Service Resistance

   Denial of Service (DoS) resistance has not been a design goal for
   EAP-GPSK.

   It is however believed that EAP-GPSK does not provide any obvious and
   avoidable venue for such attacks.

   It is worth noting that the server has to maintain some state when it
   engages in an EAP-GPSK conversation, namely to generate and to
   remember the 16-octet RAND_S. 32-octet RAND_Server.  This should however not lead to
   resource exhaustion as this state and the associated computation are
   fairly lightweight.

   It is recommended that EAP-GPSK does not allow EAP notifications to
   be interleaved in its dialog to prevent potential DoS attacks.
   Indeed, since EAP Notifications are not integrity protected, they can
   easily be spoofed by an attacker.  Such an attacker could force a
   peer that allows EAP Notifications to engage in a discussion which
   would delay his authentication or result in the peer taking
   unexpected actions (e.g., in case a notification is used to prompt
   the peer to do some "bad" action).

   It is up to the implementation of EAP-GPSK or to the peer and the
   server to specify the maximum number of failed cryptographic checks
   that are allowed.

9.9.

10.9.  Session Independence

   Thanks to its key derivation mechanisms, EAP-GPSK provides session
   independence: passive attacks (such as capture of the EAP
   conversation) or active attacks (including compromise of the MSK or
   EMSK) do not enable compromise of subsequent or prior MSKs or EMSKs.
   The assumption that RAND_Client and RAND_Server are random is central
   for the security of EAP-GPSK in general and session independance independence in
   particular.

9.10.

10.10.  Exposition of the PSK

   EAP-GPSK does not provide perfect forward secrecy.  Compromise of the
   PSK leads to compromise of recorded past sessions.

   Compromise of the PSK enables the attacker to impersonate the peer
   and the server and it allows the adversary to compromise future
   sessions.

   EAP-GPSK provides no protection against a legitimate peer sharing its
   PSK with a third party.  Such protection may be provided by
   appropriate repositories for the PSK, which choice is outside the
   scope of this document.  The PSK used by EAP-GPSK must only be shared
   between two parties: the peer and the server.  In particular, this
   PSK must not be shared by a group of peers communicating with the
   same server.

   The PSK used by EAP-GPSK must be cryptographically separated from
   keys used by other protocols, otherwise the security of EAP-GPSK may
   be compromised.

9.11.

10.11.  Fragmentation

   EAP-GPSK does not support fragmentation and reassembly since the
   message size is small.

9.12.

10.12.  Channel Binding

   This document enables the ability to exchange channel binding
   information.  It does not, however, define the encoding of channel
   binding information in the document.

9.13.

10.13.  Fast Reconnect

   EAP-GPSK does not provide the fast reconnect capability since this
   method is already at (or close to) the lower limit of the number of
   roundtrips and the cryptographic operations.

9.14.

10.14.  Identity Protection

   Identity protection is not specified in this document.  Extensions
   can be defined that enhance this protocol to provide this feature.

9.15.

10.15.  Protected Ciphersuite Negotiation

   EAP-GPSK provides protected ciphersuite negotiation via the
   indication of available ciphersuites by the server in the first
   message and a confirmation by the client in the subsequent message.

9.16.

10.16.  Confidentiality

   Although EAP-GPSK provides confidentiality in its protected data
   payloads, it cannot claim to do so as per Section 7.2.1 of [RFC3748].

9.17.

10.17.  Cryptographic Binding

   Since EAP-GPSK does not tunnel another EAP method, it does not
   implement cryptographic binding.

10.

11.  IANA Considerations

   This document requires IANA to allocate a new EAP Type for EAP-GPSK.

   This document requires IANA to create a new registry for
   ciphersuites, protected data types, and failure codes.  IANA is
   furthermore instructed to add the specified ciphersuites, protected
   data types, and failure codes to this registry as defined in this
   document.  Values can be added or modified with informational RFCs
   defining either block-based or hash-based ciphersuites, protected
   data payloads, or failure codes.  Each ciphersuite needs to provide
   processing rules and needs to specify how the following algorithms
   are instantiated: Encryption, Integrity and Key Derivation.
   Additionally, the preferred key size needs to be specified.

   The following layout represents the initial ciphersuite CSuite/
   Specifier registry setup:

   o  0x000000 : Reserved
   o  0x000001 : AES-CBC-128, AES-CMAC-128, GKDF-128
   o  0x000002 : NULL, HMAC-SHA256, GKDF-256
   o  0x000003 through 0xFFFFFF : Unallocated

   The following is the initial protected data PData/Specifier registry
   setup:

   o  0x000000 : Reserved
   o  0x000001 : Protected Results Indication
   o  0x000002 through 0xFFFFFF : Unallocated

   The following layout represents the initial Failure-Code registry
   setup:

   o  0x00000001: PSK Not Found
   o  0x00000002: Authentication Failure
   o  0x00000003: Authorization Failure
   o  0x00000004 through 0xFFFFFFFF : Unallocated

11.

12.  Contributors

   This work is a joint effort of the EAP Method Update (EMU) design
   team of the EMU Working Group that was created to develop a mechanism
   based on strong shared secrets that meets RFC 3748 [RFC3748] and RFC
   4017 [RFC4017] requirements.  The design team members (in
   alphabetical order) were:

   o  Jari Arkko
   o  Mohamad Badra
   o  Uri Blumenthal
   o  Charles Clancy
   o  Lakshminath Dondeti
   o  David McGrew
   o  Joe Salowey
   o  Sharma Suman
   o  Hannes Tschofenig
   o  Jesse Walker

   Finally, we would like to thank Thomas Otto for his draft reviews,
   feedback and text contributions.

12.  Acknowledgment

13.  Acknowledgments

   We would like to thank

   o  Jouni Malinen and Bernard Aboba for their early draft comments in
      June 2006.  Jouni Malinen developed the first prototype
      implementation.  It can be found at:
      http://hostap.epitest.fi/releases/snapshots/
   o  Lakshminath Dondeti, David McGrew, Bernard Aboba, Michaela
      Vanderveen and Ray Bell for their input to the ciphersuite
      discussions between July and August 2006.
   o  Lakshminath Dondeti for his detailed draft review (sent to the EMU
      ML on the 12th July 2006).
   o  Based on a review requested from NIST Quynh Dang suggested changes
      to the GKDF function (December 2006).

13.  Open Issues

   The list of open issues can be found at:
   http://www.tschofenig.com:8080/eap-gpsk/
   o  Jouni Malinen and Victor Fajardo for their review in January 2007.
   o  Jouni Malinen for his suggestions regarding the examples and the
      key derivation function in February 2007.

14.  References

14.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC2486bis]

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier",
              draft-ietf-radext-rfc2486bis-06 (work in progress),
              July 2005.

   [RFC3174]  Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001. 4282, December 2005.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

14.2.  Informative References

   [I-D.clancy-eap-pax]
              Clancy, C.

   [RFC3174]  Eastlake, D. and W. Arbaugh, "EAP Password Authenticated
              Exchange", draft-clancy-eap-pax-11 (work in progress), P. Jones, "US Secure Hash Algorithm 1
              (SHA1)", RFC 3174, September 2001.

   [RFC4634]  Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and HMAC-SHA)", RFC 4634, August 2006.

14.2.  Informative References

   [I-D.bersani-eap-psk]
              Tschofenig, H. and F. Bersani, "The EAP-PSK Protocol: a
              Pre-Shared Key EAP Method", draft-bersani-eap-psk-11 (work
              in progress), June 2006.

   [I-D.otto-emu-eap-tls-psk]
              Otto, T. and H. Tschofenig, "The EAP-TLS-PSK
              Authentication Protocol", draft-otto-emu-eap-tls-psk-01
              (work in progress), October 2006.

   [I-D.vanderveen-eap-sake]
              Vanderveen, M. and H. Soliman, "Extensible Authentication
              Protocol Method for Shared-secret Authentication  and Key
              Establishment (EAP-SAKE)", draft-vanderveen-eap-sake-02
              (work in progress), May 2006.

   [I-D.ietf-eap-keying]
              Aboba, B., "Extensible Authentication Protocol (EAP) Key
              Management Framework", draft-ietf-eap-keying-16 draft-ietf-eap-keying-17 (work in
              progress), January 2007.

   [RFC4017]  Stanley, D., Walker, J., and B. Aboba, "Extensible
              Authentication Protocol (EAP) Method Requirements for
              Wireless LANs", RFC 4017, March 2005.

   [RFC4746]  Clancy, T. and W. Arbaugh, "Extensible Authentication
              Protocol (EAP) Password Authenticated Exchange", RFC 4746,
              November 2006.

   [CMAC]     National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Operation: The
              CMAC Mode for Authentication", Special Publication
              (SP) 800-38B, May 2005.

   [CBC]      National Institute of Standards and Technology,
              "Recommendation for Block Cipher Modes of Encryption.
              Methods and Techniques.", Special Publication (SP) 800-
              38A, December 2001.

Authors' Addresses

   T. Charles Clancy
   DoD Laboratory for Telecommunications Sciences
   8080 Greenmead Drive
   College Park, MD  20740
   USA

   Email: clancy@ltsnet.net

   Hannes Tschofenig
   Siemens Networks GmbH & Co KG
   Otto-Hahn-Ring 6
   Munich, Bavaria  81739
   Germany

   Email: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).