    Network Working Group                                          T. Clancy
    Request for Comments: 5433                                           LTS
    Category: Standards Track                                  H. Tschofenig
                                                      Nokia Siemens Networks
                                                               February 2009

                     Extensible Authentication Protocol -
                  Generalized Pre-Shared Key (EAP-GPSK) Method

    Status of This Memo

       This document specifies an Internet standards track protocol for the
       Internet community, and requests discussion and suggestions for
       improvements.  Please refer to the current edition of the "Internet
       Official Protocol Standards" (STD 1) for the standardization state
       and status of this protocol.  Distribution of this memo is unlimited.

    Copyright Notice

       Copyright (c) 2009 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents in effect on the date of
       publication of this document (http://trustee.ietf.org/license-info).
       Please review these documents carefully, as they describe your rights
       and restrictions with respect to this document.

    Abstract

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

    Clancy & Tschofenig         Standards Track                     [Page 1]

    RFC 5433                        EAP-GPSK                   February 2009

    Table of Contents

       1. Introduction ....................................................3
       2. Terminology .....................................................4
       3. Overview ........................................................6
       4. Key Derivation ..................................................8
       5. Key Management .................................................11
       6. Ciphersuites ...................................................11
       7. Generalized Key Derivation Function (GKDF) .....................12
       8. Ciphersuites Processing Rules ..................................13
          8.1. Ciphersuite #1 ............................................13
               8.1.1. Encryption .........................................13
               8.1.2. Integrity ..........................................13
          8.2. Ciphersuite #2 ............................................14
               8.2.1. Encryption .........................................14
               8.2.2. Integrity ..........................................14
       9. Packet Formats .................................................15
          9.1. Header Format .............................................15
          9.2. Ciphersuite Formatting ....................................16
          9.3. Payload Formatting ........................................16
          9.4. Protected Data ............................................21
       10. Packet Processing Rules .......................................24
       11. Example Message Exchanges .....................................25
       12. Security Considerations .......................................28
          12.1. Security Claims ..........................................28
          12.2. Mutual Authentication ....................................29
          12.3. Protected Result Indications .............................29
          12.4. Integrity Protection .....................................29
          12.5. Replay Protection ........................................30
          12.6. Reflection Attacks .......................................30
          12.7. Dictionary Attacks .......................................30
          12.8. Key Derivation and Key Strength ..........................31
          12.9. Denial-of-Service Resistance .............................31
          12.10. Session Independence ....................................32
          12.11. Compromise of the PSK ...................................32
          12.12. Fragmentation ...........................................32
          12.13. Channel Binding .........................................32
          12.14. Fast Reconnect ..........................................33
          12.15. Identity Protection .....................................33
          12.16. Protected Ciphersuite Negotiation .......................33
          12.17. Confidentiality .........................................34
          12.18. Cryptographic Binding ...................................34
       13. IANA Considerations ...........................................34
       14. Contributors ..................................................35
       15. Acknowledgments ...............................................36
       16. References ....................................................37
          16.1. Normative References .....................................37
          16.2. Informative References ...................................38

    Clancy & Tschofenig         Standards Track                     [Page 2]

    RFC 5433                        EAP-GPSK                   February 2009

    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.

       EAP-GPSK addresses a large number of design goals with the intention
       of being applicable in a broad range of usage scenarios.

       The main design goals of EAP-GPSK are:

       Simplicity:

          EAP-GPSK should be easy to implement.

       Security Model:

          EAP-GPSK has been designed in a threat model where the attacker
          has full control over the communication channel.  This EAP threat
          model 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 of 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.  Additionally, it seeks to minimize the
          number of round trips.

       Flexibility:

          EAP-GPSK offers cryptographic flexibility.  At the beginning, the
          EAP server proposes a list of ciphersuites.  The client then
          selects one.  The current version of EAP-GPSK includes 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.

    Clancy & Tschofenig         Standards Track                     [Page 3]

    RFC 5433                        EAP-GPSK                   February 2009

    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:

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

       CSuite_Sel:  Ciphersuite selected by the peer (6 octets).

       ID_Peer:  Peer Network Access Identifier (NAI) [RFC4282].

       ID_Server:  Server identity as an opaque blob.

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

       ML:  Integer representing the length of the Message Authentication
          Code (MAC) output, in octets, of the selected ciphersuite
          CSuite_Sel.

       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).
          PL MUST be larger than or equal to KS.

       RAND_Peer:  Random integer generated by the peer (32 octets).

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

    Clancy & Tschofenig         Standards Track                     [Page 4]

    RFC 5433                        EAP-GPSK                   February 2009

       Operations:

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

       A**B:  Integer exponentiation.

       truncate(A,B):  Returns the first B octets of A.

       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).

       X[A..B]:  Notation representing octets A through B of octet array X
          where the first octet of the array has index zero.

       The following abbreviations are used for the keying material:

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

       MK:    A session-specific Master Key between the peer and EAP server
              from which all other EAP method session keys are derived (KS
              octets).

       MSK:   Master Session Key exported by the EAP method (64 octets).

       PK:    Session key generated from the MK and used during protocol
              exchange to encrypt protected data (KS octets).

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

       SK:    Session key generated from the MK and used during protocol
              exchange to demonstrate knowledge of the PSK (KS octets).

    Clancy & Tschofenig         Standards Track                     [Page 5]

    RFC 5433                        EAP-GPSK                   February 2009

    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, e.g., IEEE 802.1X as utilized by IEEE 802.11 [80211].

       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 the EAP peer ("Peer")
       and EAP server ("Server") based on a pre-shared key (PSK).  The
       protocol consists of the message exchanges (GPSK-1, ..., GPSK-4) in
       which both sides exchange nonces and their identities, and 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.  Two further
       messages, namely GPSK-Fail and GPSK-Protected-Fail, are used to deal
       with error situations.

       A successful protocol exchange is shown in Figure 1.

    Clancy & Tschofenig         Standards Track                     [Page 6]

    RFC 5433                        EAP-GPSK                   February 2009

       +--------+                                     +--------+
       |        |                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                |        |
       |        |<------------------------------------|        |
       +--------+                                     +--------+

                    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_Peer, ID_Server, RAND_Peer, RAND_Server, CSuite_List,
          CSuite_Sel, [ ENC_PK(PD_Payload_Block) ] )

       GPSK-3:

          SEC_SK(RAND_Peer, RAND_Server, ID_Server, CSuite_Sel, [
          ENC_PK(PD_Payload_Block) ] )

       GPSK-4:

          SEC_SK( [ ENC_PK(PD_Payload_Block) ] )

    Clancy & Tschofenig         Standards Track                     [Page 7]

    RFC 5433                        EAP-GPSK                   February 2009

       The EAP server begins EAP-GPSK by selecting a random number
       RAND_Server and 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 of 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_Peer and a random number
       RAND_Peer.  Furthermore, it repeats the received parameters of the
       GPSK-1 message (ID_Server, RAND_Server, CSuite_List) and the selected
       ciphersuite.  It computes a Message Authentication Code over all the
       transmitted parameters.

       The EAP server verifies the received Message Authentication Code and
       the consistency of the identities, nonces, and ciphersuite parameters
       transmitted in GPSK-1.  In case of successful verification, the EAP
       server computes a Message Authentication Code over the session
       parameter and returns it to the peer (within GPSK-3).  Within GPSK-2
       and GPSK-3, the EAP peer and EAP server have the possibility to
       exchange encrypted protected data parameters.

       The peer verifies the received Message Authentication Code and the
       consistency of the identities, nonces, and ciphersuite parameters
       transmitted in GPSK-2.  If the verification is successful, GPSK-4 is
       prepared.  This message can optionally contain the peer's protected
       data parameters.

       Upon receipt of GPSK-4, the server processes any included
       PD_Payload_Block.  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 [RFC5247].  Note that this section provides an abstract
       description for the key derivation procedure that needs to be
       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 are variable.  While it is possible to use a
       password or passphrase, doing so is NOT RECOMMENDED as EAP-GPSK is
       vulnerable to dictionary attacks.

    Clancy & Tschofenig         Standards Track                     [Page 8]

    RFC 5433                        EAP-GPSK                   February 2009

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

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

       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 octets starting with octet A and
          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_Peer || ID_Peer || RAND_Server || ID_Server

       o  MK = KDF-KS(PSK[0..KS-1], PL || PSK || CSuite_Sel ||
          inputString)[0..KS-1]

       o  MSK = KDF-{128+2*KS}(MK, inputString)[0..63]

       o  EMSK = KDF-{128+2*KS}(MK, inputString)[64..127]

       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
          an encrypting ciphersuite)

       The value for PL (the length of the PSK in octets) is encoded as a
       2-octet integer in network byte order.  Recall that KS is the length
       of the ciphersuite input key size in octets.

       Additionally, the EAP keying framework [RFC5247] requires the
       definition of a Method-ID, Session-ID, Peer-ID, and Server-ID.  These
       values are defined as:

       o  Method-ID = KDF-16(PSK[0..KS-1], "Method ID" || EAP_Method_Type ||
          CSuite_Sel || inputString)[0..15]

    Clancy & Tschofenig         Standards Track                     [Page 9]

    RFC 5433                        EAP-GPSK                   February 2009

       o  Session-ID = EAP_Method_Type || Method_ID

       o  Peer-ID = ID_Peer

       o  Server-ID = ID_Server

       EAP_Method_Type refers to the 1-octet, IANA-allocated EAP Type code
       value.

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

       +-------------+     +-------------------------------+
       |   PL-octet  |     | RAND_Peer || ID_Peer ||       |
       |     PSK     |     | RAND_Server || ID_Server      |
       +-------------+     +-------------------------------+
              |                            |            |
              |     +------------+         |            |
              |     | CSuite_Sel |         |            |
              |     +------------+         |            |
              |           |                |            |
              v           v                v            |
       +--------------------------------------------+   |
       |                    KDF                     |   |
       +--------------------------------------------+   |
                                 |                      |
                                 v                      |
                          +-------------+               |
                          |   KS-octet  |               |
                          |     MK      |               |
                          +-------------+               |
                                 |                      |
                                 v                      v
       +---------------------------------------------------+
       |                      KDF                          |
       +---------------------------------------------------+
            |             |             |            |
            v             v             v            v
       +---------+   +---------+  +----------+  +----------+
       | 64-octet|   | 64-octet|  | KS-octet |  | KS-octet |
       |   MSK   |   |  EMSK   |  |    SK    |  |   PK     |
       +---------+   +---------+  +----------+  +----------+

                         Figure 2: EAP-GPSK Key Derivation

    Clancy & Tschofenig         Standards Track                    [Page 10]

    RFC 5433                        EAP-GPSK                   February 2009

    5.  Key Management

       In order to be interoperable, PSKs must be entered in the same way on
       both the peer and server.  The management interface for entering PSKs
       MUST support entering PSKs up to 64 octets in length as ASCII strings
       and in hexadecimal encoding.

       Additionally, the ID_Peer and ID_Server MUST be provisioned with the
       PSK.  Validation of these values is by an octet-wise comparison.  The
       management interface SHOULD support entering non-ASCII octets for the
       ID_Peer and ID_Server up to 254 octets in length.  For more
       information, the reader is advised to read Section 2.4 of RFC 4282
       [RFC4282].

    6.  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 four octets are the
       vendor-specific enterprise number that contains the IANA-assigned
       "SMI Network Management Private Enterprise Codes" value (see
       [ENTNUM]), encoded in network byte order.  The last two octets are
       vendor assigned for the specific ciphersuite.  A vendor code of
       0x00000000 indicates ciphersuites standardized by the IETF in an
       IANA-maintained registry.

       The following ciphersuites are specified in this document (recall
       that KS is the length of the ciphersuite input key length in octets,
       and ML is the length of the MAC output in octets):

       +-----------+----+-------------+----+--------------+----------------+
       | CSuite/   | KS | Encryption  | ML | Integrity /  | Key Derivation |
       | Specifier |    |             |    | KDF MAC      | Function       |
       +-----------+----+-------------+----+--------------+----------------+
       | 0x0001    | 16 | AES-CBC-128 | 16 | AES-CMAC-128 | GKDF           |
       +-----------+----+-------------+----+--------------+----------------+
       | 0x0002    | 32 | NULL        | 32 | HMAC-SHA256  | GKDF           |
       +-----------+----+-------------+----+--------------+----------------+

                              Figure 3: Ciphersuites

    Clancy & Tschofenig         Standards Track                    [Page 11]

    RFC 5433                        EAP-GPSK                   February 2009

       Ciphersuite 1, which is based on the Advanced Encryption Standard
       (AES) as a cryptographic primitive, MUST be implemented.  This
       document specifies also a second ciphersuite, which MAY be
       implemented.  Both ciphersuites defined in this document make use of
       the Generalized Key Derivation Function (GKDF), as defined in
       Section 7.  The following aspects need to be considered to ensure
       that the PSK that is used as input to the GKDF is sufficiently long:

       1.  The PSK used with ciphersuite 1 MUST be 128 bits in length.  Keys
           longer than 128 bits will be truncated.

       2.  The PSK used with ciphersuite 2 MUST be 256 bits in length.  Keys
           longer than 256 bits will be truncated.

       3.  It is RECOMMENDED that 256 bit keys be provisioned in all cases
           to provide enough entropy for all current and many possible
           future ciphersuites.

       Ciphersuites defined in the future that make use of the GKDF need to
       specify a minimum PSK size (as is done with the ciphersuites listed
       in this document).

    7.  Generalized Key Derivation Function (GKDF)

       Each ciphersuite needs to specify a key derivation function.  The
       ciphersuites defined in this document make use of the Generalized Key
       Derivation Function (GKDF) that utilizes the MAC function defined in
       the ciphersuite.  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.

       GKDF has the following structure:

       GKDF-X(Y, Z)

       X  length, in octets, of the desired output

       Y  secret key

       Z  inputString

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

    Clancy & Tschofenig         Standards Track                    [Page 12]

    RFC 5433                        EAP-GPSK                   February 2009

         result = "";

         for i = 1 to n {
           result = result || MAC_Y (i || Z);
         }

         return truncate(result, X)
       }

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

    8.  Ciphersuites Processing Rules

    8.1.  Ciphersuite #1

    8.1.1.  Encryption

       With this ciphersuite, all cryptography is built around a single
       cryptographic primitive, AES-128 ([AES]).  Within the protected data
       frames, AES-128 is used in the Cipher Block Chaining (CBC) mode of
       operation (see [CBC]).  This EAP method uses encryption in a single
       payload, in the protected data payload (see Section 9.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.

    8.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-CMAC-128(SK, Input) denotes
       the MAC of Input under the key SK where Input refers to the following
       content:

       o  Parameter within SEC_SK(Parameter) in message GPSK-2

       o  Parameter within SEC_SK(Parameter) in message GPSK-3

       o  Parameter within SEC_SK(Parameter) in message GPSK-4

    Clancy & Tschofenig         Standards Track                    [Page 13]

    RFC 5433                        EAP-GPSK                   February 2009

    8.2.  Ciphersuite #2

    8.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 block is not encrypted.  Therefore, this mode MUST NOT be used
       if confidential information appears inside the protected data block.

    8.2.2.  Integrity

       Ciphersuite 2 uses the keyed MAC function HMAC, with the SHA256 hash
       algorithm (see [RFC4634]).

       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  Parameter within SEC_SK(Parameter) in message GPSK-2

       o  Parameter within SEC_SK(Parameter) in message GPSK-3

       o  Parameter within SEC_SK(Parameter) in message GPSK-4

    Clancy & Tschofenig         Standards Track                    [Page 14]

    RFC 5433                        EAP-GPSK                   February 2009

    9.  Packet Formats

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

    9.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 4: EAP-GPSK Header

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

       The OP-Code field is one of 6 values:

       o  0x00 : Reserved

       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

       All other values of this OP-Code field are available via IANA
       registration.

    Clancy & Tschofenig         Standards Track                    [Page 15]

    RFC 5433                        EAP-GPSK                   February 2009

    9.2.  Ciphersuite Formatting

       Ciphersuites are encoded as 6-octet arrays.  The first four octets
       indicate the CSuite/Vendor field.  For vendor-specific ciphersuites,
       this represents the vendor enterprise number and contains the IANA-
       assigned "SMI Network Management Private Enterprise Codes" value (see
       [ENTNUM]), encoded in network byte order.  The last two octets
       indicate the CSuite/Specifier field, which identifies the particular
       ciphersuite.  The 4-octet CSuite/Vendor value 0x00000000 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 = 0x00000000 or enterprise number         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      CSuite/Specifier         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 5: Ciphersuite Formatting

       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.

    9.3.  Payload Formatting

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

    Clancy & Tschofenig         Standards Track                    [Page 16]

    RFC 5433                        EAP-GPSK                   February 2009

       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 6: GPSK-1 Payload

    Clancy & Tschofenig         Standards Track                    [Page 17]

    RFC 5433                        EAP-GPSK                   February 2009

       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_Peer)        |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       ...                         ID_Peer                         ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       length(ID_Server)       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       ...                         ID_Server                         ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                     32-octet RAND_Peer                    ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                    32-octet RAND_Server                   ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      length(CSuite_List)      |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       ...                        CSuite_List                        ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           CSuite_Sel                          |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |   length(PD_Payload_Block)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                 optional PD_Payload_Block                 ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                   ML-octet payload MAC                    ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 7: GPSK-2 Payload

    Clancy & Tschofenig         Standards Track                    [Page 18]

    RFC 5433                        EAP-GPSK                   February 2009

       If the optional protected data payload is not included, then
       length(PD_Payload_Block)=0 and the PD payload is excluded.  The
       payload MAC covers the entire packet, from the ID_Peer length through
       the optional PD_Payload_Block.

       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_Peer                   ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                    32-octet RAND_Server                   ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       length(ID_Server)       |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       ...                         ID_Server                         ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                           CSuite_Sel                          |
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                               |   length(PD_Payload_Block)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                 optional PD_Payload_Block                 ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                   ML-octet payload MAC                    ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 8: GPSK-3 Payload

       If the optional protected data payload is not included, then
       length(PD_Payload_Block)=0 and the PD payload is excluded.  The
       payload MAC covers the entire packet, from the RAND_Peer through the
       optional PD_Payload_Block.

    Clancy & Tschofenig         Standards Track                    [Page 19]

    RFC 5433                        EAP-GPSK                   February 2009

       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_Block)    |                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
       |                                                               |
       ...                 optional PD_Payload_Block                 ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                   ML-octet payload MAC                    ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 9: GPSK-4 Payload

       If the optional protected data payload is not included, then
       length(PD_Payload_Block)=0 and the PD payload is excluded.  The MAC
       MUST always be included, regardless of the presence of
       PD_Payload_Block.  The payload MAC covers the entire packet, from the
       PD_Payload_Block length through the optional 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 10: GPSK-Fail Payload

    Clancy & Tschofenig         Standards Track                    [Page 20]

    RFC 5433                        EAP-GPSK                   February 2009

       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                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                   ML-octet payload MAC                    ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 11: GPSK-Protected-Fail Payload

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

       o  0x00000000 : Reserved

       o  0x00000001 : PSK Not Found

       o  0x00000002 : Authentication Failure

       o  0x00000003 : Authorization Failure

       All other values of this field are available via IANA registration.

       "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.

    9.4.  Protected Data

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

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

       Type values are encoded as a 6-octet string and represented by a
       4-octet vendor and a 2-octet specifier field.  The vendor field
       indicates the type as either standards-specified or vendor-specific.

    Clancy & Tschofenig         Standards Track                    [Page 21]

    RFC 5433                        EAP-GPSK                   February 2009

       If these four octets are 0x00000000, then the value is standards-
       specified, and any other value represents a vendor-specific
       enterprise number.

       The specifier field indicates the actual type.  For vendor field
       0x00000000, 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, 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        |         PData/Length          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                        PData/Value                        ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12: Protected Data Payload (PD_Payload) Formatting

       These PD_Payloads are concatenated together to form a
       PD_Payload_Block.  If the CSuite_Sel includes support for encryption,
       then the PD_Payload_Block includes fields specifying an
       Initialization Vector (IV) and the necessary padding.  This can be
       depicted as follows:

    Clancy & Tschofenig         Standards Track                    [Page 22]

    RFC 5433                        EAP-GPSK                   February 2009

       --- 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   IV Length   |                                               |
       +-+-+-+-+-+-+-+-+      Initialization Vector                    +
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                        PD_Payload                         ...
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       ...                 optional PD_Payload, etc                  ...
       |                                                               |
       +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |               |             Padding (0-255 octets)            |
       +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
       |                                               |  Pad Length   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 13: Protected Data Block (PD_Payload_Block)
                       Formatting if Encryption is Supported

       The Initialization Vector is a randomly chosen value whose length is
       equal to the specified IV Length.  The required length is defined by
       the ciphersuite.  Recipients MUST accept any value.  Senders SHOULD
       either pick this value pseudo-randomly and independently for each
       message or use the final ciphertext block of the previous message
       sent.  Senders MUST NOT use the same value for each message, use a
       sequence of values with low hamming distance (e.g., a sequence
       number), or use ciphertext from a received message.  IVs should be
       selected per the security requirements of the underlying cipher.  If
       the data is not being encrypted, then the IV Length MUST be 0.  If
       the ciphersuite does not require an IV, or has a self-contained way
       of communicating the IV, then the IV Length field MUST be 0.  In
       these cases, the ciphersuite definition defines how the IV is
       encapsulated in the PD_Payload.

       The concatenation of PD_Payloads along with the padding and padding
       length are all encrypted using the 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 sender.  For
       block-based cipher modes, the padding MUST have a length that makes
       the combination of the concatenation of PD_Payloads, the Padding, and
       the Pad Length to be a multiple of the encryption block size.  If the

    Clancy & Tschofenig         Standards Track                    [Page 23]

    RFC 5433                        EAP-GPSK                   February 2009

       underlying ciphersuite does not require padding (e.g., a stream-based
       cipher mode) or no encryption is being used, then the padding length
       MUST still be present and be 0.

       The Pad Length field is the length of the Padding field.  The sender
       SHOULD set the Pad Length to the minimum value that makes the
       combination of the PD_Payloads, the Padding, and the Pad Length a
       multiple of the block size (in the case of block-based cipher modes),
       but the recipient MUST accept any length that results in proper
       alignment.  This field is encrypted with the negotiated cipher.

       If the negotiated ciphersuite does not support encryption, then the
       IV field MUST be of length 0 and the padding field MUST be of length
       0.  The IV length and padding length fields MUST still be present,
       and contain the value 0.  The rationale for still requiring the
       length fields is to allow for modular implementations where the
       crypto processing is independent of the payload processing.  This is
       depicted in the following figure.

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

                Figure 14: Protected Data Block (PD_Payload_Block)
                           Formatting Without Encryption

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

       o  0x0000 : Reserved

       All other values of this field are available via IANA registration.

    10.  Packet Processing Rules

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

    Clancy & Tschofenig         Standards Track                    [Page 24]

    RFC 5433                        EAP-GPSK                   February 2009

       Any EAP-GPSK packet that cannot be parsed by the EAP peer or the EAP
       server MUST be silently discarded.  An EAP peer or EAP server
       receiving any unexpected packet (e.g., an EAP peer 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 peer.  If the EAP peer has no ciphersuites in
       common with the server or decides the ID_Server is that of an
       Authentication, Authorization, and Accounting (AAA) server to which
       it does not wish to authenticate, the EAP peer MUST respond with an
       EAP-NAK.

       For GPSK-2, if the ID_Peer 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.  If the
       MAC validation fails, the server MUST transmit a GPSK-Fail message
       specifying "Authentication Failure".  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 peer 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 peer 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 peer MUST silently discard messages where the
       RAND_Peer, ID_Server, or the CSuite_Sel fields do not match those
       transmitted in GPSK-2.  An EAP peer MUST silently discard any packet
       whose MAC fails.

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

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

    11.  Example Message Exchanges

       This section shows a couple of example message flows.

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

    Clancy & Tschofenig         Standards Track                    [Page 25]

    RFC 5433                        EAP-GPSK                   February 2009

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

                    Figure 15: 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-Fail               |        |
       |        | (PSK Not Found or Authentication    |        |
       |        | Failure)                            |        |
       |        |<------------------------------------|        |
       |        |                                     |        |
       |        | EAP-Response/GPSK-Fail              |        |
       |        | (PSK Not Found or Authentication    |        |
       |        | Failure)                            |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        |          EAP-Failure                |        |
       |        |<------------------------------------|        |
       +--------+                                     +--------+

             Figure 16: EAP-GPSK: Unsuccessful Exchange (Unknown User)

    Clancy & Tschofenig         Standards Track                    [Page 26]

    RFC 5433                        EAP-GPSK                   February 2009

       +--------+                                     +--------+
       |        |                EAP-Request/Identity |        |
       |  EAP   |<------------------------------------|  EAP   |
       |  peer  |                                     | server |
       |        | EAP-Response/Identity               |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        |                  EAP-Request/GPSK-1 |        |
       |        |<------------------------------------|        |
       |        |                                     |        |
       |        | EAP-Response/GPSK-2                 |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        | EAP-Request/GPSK-Fail               |        |
       |        | (Authentication Failure)            |        |
       |        |<------------------------------------|        |
       |        |                                     |        |
       |        | EAP-Response/GPSK-Fail              |        |
       |        | (Authentication Failure)            |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        |          EAP-Failure                |        |
       |        |<------------------------------------|        |
       +--------+                                     +--------+

        Figure 17: EAP-GPSK: Unsuccessful Exchange (Invalid MAC in GPSK-2)

    Clancy & Tschofenig         Standards Track                    [Page 27]

    RFC 5433                        EAP-GPSK                   February 2009

       +--------+                                     +--------+
       |        |                EAP-Request/Identity |        |
       |  EAP   |<------------------------------------|  EAP   |
       |  peer  |                                     | server |
       |        | EAP-Response/Identity               |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        |                  EAP-Request/GPSK-1 |        |
       |        |<------------------------------------|        |
       |        |                                     |        |
       |        | EAP-Response/GPSK-2                 |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        | EAP-Request/                        |        |
       |        | GPSK-Protected-Fail                 |        |
       |        | (Authorization Failure)             |        |
       |        |<------------------------------------|        |
       |        |                                     |        |
       |        | EAP-Request/                        |        |
       |        | GPSK-Protected-Fail                 |        |
       |        | (Authorization Failure)             |        |
       |        |------------------------------------>|        |
       |        |                                     |        |
       |        |          EAP-Failure                |        |
       |        |<------------------------------------|        |
       +--------+                                     +--------+

        Figure 18: EAP-GPSK: Unsuccessful Exchange (Authorization Failure)

    12.  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].

    12.1.  Security Claims

       Authentication mechanism:  Shared Keys
       Ciphersuite negotiation:  Yes (Section 12.16)
       Mutual authentication:  Yes (Section 12.2)
       Integrity protection:  Yes (Section 12.4)
       Replay protection:  Yes (Section 12.5)
       Confidentiality:  No (Section 12.17, Section 12.15)
       Key derivation:  Yes (Section 12.8)
       Key strength:  Varies (Section 12.8)

    Clancy & Tschofenig         Standards Track                    [Page 28]

    RFC 5433                        EAP-GPSK                   February 2009

       Dictionary attack protection:  No (Section 12.7)
       Fast reconnect:  No (Section 12.14)
       Cryptographic binding:  N/A (Section 12.18)
       Session independence:  Yes (Section 12.10)
       Fragmentation:  No (Section 12.12)
       Channel binding:  Extensible (Section 12.13)

    12.2.  Mutual Authentication

       EAP-GPSK provides mutual authentication.

       The server believes that the peer is authentic when it successfully
       verifies the MAC in the GPSK-2 message; the peer believes that the
       server is authentic when it successfully verifies the MAC it receives
       with the GPSK-3 message.

       The key used for mutual authentication is derived based on the long-
       term secret PSK, nonces contributed by both parties, and other
       parameters.  The long-term secret PSK has to provide sufficient
       entropy and, therefore, sufficient strength.  The nonces (RAND_Peer
       and RAND_Server) need to be fresh and unique for every session.  In
       this way, EAP-GPSK is not different than other authentication
       protocols based on pre-shared keys.

    12.3.  Protected Result Indications

       EAP-GPSK supports protected result indications via the GPSK-
       Protected-Fail message.  This allows a server to provide additional
       information to the peer as to why the session failed, and to do so in
       an authenticated way (if possible).  In particular, the server can
       indicate the lack of PSK (account not present), failed authentication
       (PSK incorrect), or authorization failure (account disabled or
       unauthorized).  Only the third message could be integrity protected.

       It should be noted that these options make debugging network and
       account errors easier, but they also leak information about accounts
       to attackers.  An attacker can determine if a particular ID_Peer is a
       valid user on the network or not.  Thus, implementers should use care
       in enabling this particular option on their servers.  If they are in
       an environment where such attacks are of concern, then protected
       result indication capabilities should be disabled.

    12.4.  Integrity Protection

       EAP-GPSK provides integrity protection based on the ciphersuites
       suggested in this document.  Integrity protection is a minimum
       feature every ciphersuite must provide.

    Clancy & Tschofenig         Standards Track                    [Page 29]

    RFC 5433                        EAP-GPSK                   February 2009

    12.5.  Replay Protection

       EAP-GPSK provides replay protection of its mutual authentication part
       thanks to the use of random numbers RAND_Server and RAND_Peer.  Since
       RAND_Server is 32 octets long, one expects to have to record 2**64
       (i.e., approximately 1.84*10**19) EAP-GPSK successful authentications
       before a protocol run can be replayed.  Hence, EAP-GPSK provides
       replay protection of its mutual authentication part as long as
       RAND_Server and RAND_Peer are chosen at random; randomness is
       critical for replay protection.  RFC 4086 [RFC4086] describes
       techniques for producing random quantities.

    12.6.  Reflection Attacks

       Reflection attacks occur in bi-directional, challenge-response,
       mutual authentication protocols where an attacker, upon being issued
       a challenge by an authenticator, responds by issuing the same
       challenge back to the authenticator, obtaining the response, and then
       "reflecting" that same response to the original challenge.

       EAP-GPSK provides protection against reflection attacks because the
       message formats for the challenges differ.  The protocol does not
       consist of two independent authentications, but rather the
       authentications are tightly coupled.

       Also note that EAP-GPSK does not provide MAC protection of the OP-
       Code field, but again since each message is constructed differently,
       it would not be possible to change the OP-Code of a valid message and
       still have it be parseable and accepted by the recipient.

    12.7.  Dictionary Attacks

       EAP-GPSK relies on a long-term shared secret (PSK) that SHOULD be
       based on at least 16 octets of entropy to be fully secure.  The EAP-
       GPSK protocol makes no special provisions to ensure keys based on
       passwords are used securely.  Users who use passwords as the basis of
       their PSK are not protected against dictionary attacks.  Derivation
       of the long-term shared secret from a password is strongly
       discouraged.

       The success of a dictionary attack against EAP-GPSK depends on the
       strength of the long-term shared secret (PSK) it uses.  The PSK used
       by EAP-GPSK SHOULD be drawn from a pool of secrets that is at least
       2^128 bits large and whose distribution is uniformly random.  Note
       that this does not imply resistance to dictionary attacks -- only
       that the probability of success in such an attack is acceptably
       remote.

    Clancy & Tschofenig         Standards Track                    [Page 30]

    RFC 5433                        EAP-GPSK                   February 2009

    12.8.  Key Derivation and Key Strength

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

       Keys used within EAP-GPSK are all based on the security of the
       originating PSK.  PSKs SHOULD have at least 16 octets of entropy.
       Independent of the protocol exchange (i.e., without knowing RAND_Peer
       and RAND_Server), the keys have been derived with sufficient input
       entropy to make them as secure as the underlying KDF output key
       length.

    12.9.  Denial-of-Service Resistance

       There are three forms of denial-of-service (DoS) attacks relevant for
       this document, namely (1) attacks that lead to a vast amount of state
       being allocated, (2) attacks that attempt to prevent communication
       between the peer and server, and (3) attacks against computational
       resources.

       In an EAP-GPSK conversation the server has to maintain state, namely
       the 32-octet RAND_Server, when transmitting the GPSK-1 message to the
       peer.  An adversary could therefore flood a server with a large
       number of EAP-GPSK communication attempts.  An EAP server may
       therefore ensure that an established state times out after a
       relatively short period of time when no further messages are
       received.  This enables a sort of garbage collection.

       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
       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-compute the keying material.  Thus, if a client chooses to
       implement this client-side DoS protection mechanism, it may manage
       RAND_Peer and CSuite_Sel on a per-server basis for servers it knows,
       instead of on a per-message basis.

       Attacks that disrupt communication between the peer and server are
       mitigated by silently discarding messages with invalid MACs.  Attacks
       against computational resources are mitigated by having very light-
       weight cryptographic operations required during each protocol round.

       The security considerations of EAP itself, see Sections 5.2 and 7 of
       RFC 3748 [RFC3748], are also applicable to this specification (e.g.,
       for example concerning EAP-based notifications).

    Clancy & Tschofenig         Standards Track                    [Page 31]

    RFC 5433                        EAP-GPSK                   February 2009

    12.10.  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_Peer and RAND_Server are random is central
       for the security of EAP-GPSK in general and session independence in
       particular.

    12.11.  Compromise 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, the choice of which 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 (e.g., those with
       different ID_Peer values) 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.

    12.12.  Fragmentation

       EAP-GPSK does not support fragmentation and reassembly since the
       message size is relatively small.  However, it should be noted that
       this impacts the length of protected data payloads that can be
       attached to messages.  Also, if the EAP frame is larger than the MTU
       of the underlying transport, and that transport does not support
       fragmentation, the frame will most likely not be transported.
       Consequently, implementers and deployers should take care to ensure
       EAP-GPSK frames are short enough to work properly on the target
       underlying transport mechanism.

    12.13.  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.

    Clancy & Tschofenig         Standards Track                    [Page 32]

    RFC 5433                        EAP-GPSK                   February 2009

    12.14.  Fast Reconnect

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

    12.15.  Identity Protection

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

    12.16.  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 peer in the subsequent message.

       Note, however, that the GPSK-2 message may optionally contain a
       payload, ENC_PK(PD_Payload_Block), protected with an algorithm based
       on a selected ciphersuite before the ciphersuite list has actually
       been authenticated.  In the classical downgrading attack, an
       adversary would choose a ciphersuite that is so weak that it can be
       broken in real time or would attempt to disable cryptographic
       protection altogether.  The latter is not possible since any
       ciphersuite defined for EAP-GPSK must at least provide authentication
       and integrity protection.  Confidentiality protection is optional.
       When, at some time in the future, a ciphersuite contains algorithms
       that can be broken in real-time, then a policy on peers and the
       server needs to indicate that such a ciphersuite must not be selected
       by any of parties.

       Furthermore, an adversary may modify the selection of the ciphersuite
       for the client to select a ciphersuite that does not provide
       confidentiality protection.  As a result, this would cause the
       content of PD_Payload_Block to be transmitted in cleartext.  When
       protocol designers extend EAP-GPSK to carry information in the
       PD_Payload_Block of the GPSK-2 message, then it must be indicated
       whether confidentiality protection is mandatory.  In case such an
       extension requires a ciphersuite with confidentiality protection,
       then the policy at the peer must be to not transmit information of
       that extension in the PD_Payload_Block of the GPSK-2 message.  The
       peer may, if possible, delay the transmission of this information
       element to the GPSK-4 message where the ciphersuite negotiation has
       been confirmed already.  In general, when a ciphersuite is selected
       that does not provide confidentiality protection, then information
       that demands confidentiality protection must not be included in any
       of the PD_Payload_Block objects.

    Clancy & Tschofenig         Standards Track                    [Page 33]

    RFC 5433                        EAP-GPSK                   February 2009

    12.17.  Confidentiality

       Although EAP-GPSK provides confidentiality in its protected data
       payloads, it cannot claim to do so, per Section 7.2.1 of [RFC3748],
       since it does not support identity protection.

    12.18.  Cryptographic Binding

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

    13.  IANA Considerations

       IANA has allocated a new EAP Type for EAP-GPSK (51).

       IANA has created a new registry for ciphersuites, protected data
       types, failure codes, and op-codes.  IANA has added the specified
       ciphersuites, protected data types, failure codes, and op-codes to
       these registries as defined below.  Values defining ciphersuites
       (block-based or hash-based), protected data payloads, failure codes,
       and op-codes can be added or modified per IETF Review [RFC5226].

       Figure 3 represents the initial contents of the "EAP-GPSK
       Ciphersuites" registry.  The CSuite/Specifier field is 16 bits long.
       All other values are available via IANA registration.  Each
       ciphersuite needs to provide processing rules and needs to specify
       how the following algorithms are instantiated: encryption, integrity,
       key derivation, and key length.

       The following are the initial contents of the "EAP-GPSK Protected
       Data Payloads" registry:

       o  0x0000 : Reserved

       The PData/Specifier field is 16 bits long, and all other values are
       available via IANA registration.  Each extension needs to indicate
       whether confidentiality protection for transmission between the EAP
       peer and the EAP server is mandatory.

       The following are the initial contents of the "EAP-GPSK Failure
       Codes" registry:

       o  0x00000000 : Reserved

       o  0x00000001 : PSK Not Found

       o  0x00000002 : Authentication Failure

    Clancy & Tschofenig         Standards Track                    [Page 34]

    RFC 5433                        EAP-GPSK                   February 2009

       o  0x00000003 : Authorization Failure

       The Failure-Code field is 32 bits long, and all other values are
       available via IANA registration.

       The following are the initial contents of the "EAP-GPSK OP Codes"
       registry:

       o  0x00 : Reserved

       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

       The OP-Code field is 8 bits long, and all other values are available
       via IANA registration.

    14.  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

    Clancy & Tschofenig         Standards Track                    [Page 35]

    RFC 5433                        EAP-GPSK                   February 2009

       o  Hannes Tschofenig

       o  Jesse Walker

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

    15.  Acknowledgments

       We would like to thank:

       o  Jouni Malinen and Bernard Aboba for their early comments on the
          document in June 2006.  Jouni Malinen developed the first
          prototype implementation.

       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 review (sent to the EMU
          mailing list on 12 July 2006).

       o  Based on a review requested from NIST, Quynh Dang suggested
          changes to the GKDF function (December 2006).

       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.

       o  Bernard Aboba and Jouni Malinen for their review in February 2007.

       o  Vidya Narayanan for her review in March 2007.

       o  Pasi Eronen for his IESG review in March and July 2008.

       o  Dan Harkins for his review in June 2008.

       o  Joe Salowey, the EMU working group chair, provided a document
          review in April 2007.  Jouni Malinen also reviewed the document
          during the same month.

       o  We would like to thank Paul Rowe, Arnab Roy, Prof. Andre Scedrov,
          and Prof. John C. Mitchell for their analysis of EAP-GPSK, for
          their input to the key derivation function, and for pointing us to
          a client-side DoS attack and to a downgrading attack.  Based on
          their input, the key derivation function has been modified and the
          text in the security considerations section has been updated.

    Clancy & Tschofenig         Standards Track                    [Page 36]

    RFC 5433                        EAP-GPSK                   February 2009

       o  Finally, we would like to thank our working group chair, Joe
          Salowey, for his support and for the time he spent discussing open
          issues with us.

    16.  References

    16.1.  Normative References

       [AES]      National Institute of Standards and Technology,
                  "Specification for the Advanced Encryption Standard
                  (AES)", Federal Information Processing Standards
                  (FIPS) 197, November 2001.

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

       [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.

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

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

       [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
                  Network Access Identifier", RFC 4282, December 2005.

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

       [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
                  IANA Considerations Section in RFCs", BCP 26, RFC 5226,
                  May 2008.

       [RFC5247]  Aboba, B., Simon, D., and P. Eronen, "Extensible
                  Authentication Protocol (EAP) Key Management Framework",
                  RFC 5247, August 2008.

    Clancy & Tschofenig         Standards Track                    [Page 37]

    RFC 5433                        EAP-GPSK                   February 2009

    16.2.  Informative References

       [80211]    "Information technology - Telecommunications and
                  Information Exchange Between Systems - Local and
                  Metropolitan Area Networks - Specific Requirements - Part
                  11: Wireless LAN Medium Access Control (MAC) and Physical
                  Layer (PHY) Specifications", IEEE Standard 802.11-2007,
                  March 2007.

       [ENTNUM]   IANA, "SMI Network Management Private Enterprise Codes",
                  Private Enterprise Numbers, <http://www.iana.org>.

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

       [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
                  Requirements for Security", BCP 106, RFC 4086, June 2005.

    Authors' Addresses

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

       EMail: clancy@ltsnet.net

       Hannes Tschofenig
       Nokia Siemens Networks
       Linnoitustie 6
       Espoo  02600
       Finland

       EMail: Hannes.Tschofenig@gmx.net

    Clancy & Tschofenig         Standards Track                    [Page 38]