tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4764

 
 
 

The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method

Part 2 of 3, p. 15 to 41
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 15 
3.  Cryptographic Design of EAP-PSK

   EAP-PSK relies on a single cryptographic primitive, a block cipher,
   which is instantiated with AES-128.  AES-128 takes a 16-byte Pre-
   Shared Key and a 16-byte Plain Text block as inputs.  It outputs a
   16-byte Cipher Text block.  For a detailed description of AES-128,
   please refer to [7].

   AES-128 has been chosen because:

   o  It is standardized and implementations are widely available.

Top      Up      ToC       Page 16 
   o  It has been carefully reviewed by the cryptographic community and
      is believed to be secure.

   Other block ciphers could easily be proposed for EAP-PSK, as EAP-PSK
   does not intrinsically depend on AES-128.  The only parameters of
   AES-128 that EAP-PSK depends on are the AES-128 block and key size
   (16 bytes).  For the sake of simplicity, EAP-PSK has, however, been
   chosen to restrict to a single mandatory block cipher and not allow
   the negotiation of other block ciphers.  In the case that AES-128 is
   deprecated for security reasons, EAP-PSK should also be deprecated
   and a cut-and-paste EAP-PSK' should be defined with another block
   cipher.  This EAP-PSK' should not be backward compatible with EAP-PSK
   because of the security issues with AES-128.  EAP-PSK' should
   therefore use a different EAP-Request/Response Type number.  With the
   EAP-Request/Response Type number space structure defined in [3], this
   should not be a problem.  The use of a different EAP-Request/Response
   Type number for EAP-PSK' will prevent this new method from being
   vulnerable to chosen protocol attacks.

   EAP-PSK uses three cryptographic parts:

   o  A key setup to derive AK and KDK from the PSK.

   o  An authenticated key exchange protocol to mutually authenticate
      the communicating parties and derive session keys.

   o  A protected channel protocol for both mutually authenticated
      parties to communicate over.

   Each part is discussed in more detail in the subsequent paragraphs.

3.1.  The Key Setup

   EAP-PSK needs two cryptographically separated 16-byte subkeys for
   mutual authentication and session key derivation.  Indeed, it is a
   rule of thumb in cryptography to use different keys for different
   applications.

   It could have implemented these two subkeys either by specifying a
   32-byte PSK that would then be split in two 16-byte subkeys, or by
   specifying a 16-byte PSK that would then be cryptographically
   expanded to two 16-byte subkeys.

   Because provisioning a 32-byte long-term credential is more
   cumbersome than a 16-byte one, and the strength of the derived
   session keys is 16 bytes either way, the latter option was chosen.

Top      Up      ToC       Page 17 
   Hence, the PSK is only used by EAP-PSK to derive AK and KDK.  This
   derivation should be done only once, immediately after the PSK has
   been provisioned.  As soon as AK and KDK have been derived, the PSK
   should be deleted.  If the PSK is deleted, it should be done so
   securely (see, for instance, [19] for guidance on secure deletion of
   the PSK).

   Derivation of AK and KDK from the PSK is called the key setup:

   o  The input to the key setup is the PSK.

   o  The outputs of the key setup are AK and KDK.

   AK and KDK are derived from the PSK using the modified counter mode
   of operation of AES-128.  The modified counter mode is a length
   increasing function, i.e., it expands one AES-128 input block into a
   longer t-block output, where t>=2.  This mode was chosen for the key
   setup because it had already been chosen for the derivation of the
   session keys (see Section 3.2).

   The details of the derivation of AK and KDK from the PSK are shown in
   Figure 3.

Top      Up      ToC       Page 18 
   +--------------------------+
   |            "0"           |
   |  Input Block (16 bytes)  |
   +--------------------------+
                 |
                 v
        +----------------+
        |                |
        | AES-128(PSK,.) |
        |                |
        +----------------+
                 |
                 |
                 +----------------------------+
                 |                            |
                 v                            v
   +--------+  +---+            +--------+  +---+
   | c1="1" |->|XOR|            | c2="2" |->|XOR|
   |16 bytes|  +---+            |16 bytes|  +---+
   +--------+    |              +--------+    |
                 |                            |
        +----------------+            +----------------+
        |                |            |                |
        | AES-128(PSK,.) |            | AES-128(PSK,.) |
        |                |            |                |
        +----------------+            +----------------+
                 |                            |
                 |                            |
                 v                            v
    +------------------------+    +------------------------+
    |           AK           |    |          KDK           |
    |       (16 bytes)       |    |      (16 bytes)        |
    +------------------------+    +------------------------+

        Figure 3: Derivation of AK and KDK from the PSK in Details

   The input block is "0".  For the sake of simplicity, this input block
   has been chosen constant: it could have been set to a value depending
   on the peer and the server (for instance, the XOR of their respective
   NAIs appropriately truncated or zero-padded), but this did not seem
   to add much security to the scheme, whereas it added complexity.  Any
   16-byte constant could have been chosen, as the security is not
   supposed to depend on the particular value taken by the constant. "0"
   was arbitrarily chosen.

Top      Up      ToC       Page 19 
3.2.  The Authenticated Key Exchange

   The authentication protocol used by EAP-PSK is inspired by AKEP2,
   which is described in [14].

   AKEP2 consists of a one-and-a-half round-trip exchange, as shown in
   Figure 4, which is inspired by Figure 5 of [14].

   Bob                                                       Alice
    |                            RA                            |
    |<---------------------------------------------------------|
    |                                                          |
    |                     [B||A||RA||RB]                       |
    |--------------------------------------------------------->|
    |                                                          |
    |                        [A||RB]                           |
    |<---------------------------------------------------------|

                        Figure 4: Overview of AKEP2

   It is also worth noting that [14] focuses on cryptography and not on
   designing a real-life protocol.  Thus, as noted in subsection "Out-
   Of-Band-Data" of [14], Alice has to send A, its identity, to Bob so
   that Bob may select the appropriate credential for the sequel to the
   conversation.  This leads to a slightly complemented version of AKEP2
   for EAP-PSK as depicted in Figure 5.

   Bob                                                       Alice
    |                         A||RA                            |
    |<---------------------------------------------------------|
    |                                                          |
    |                     [B||A||RA||RB]                       |
    |--------------------------------------------------------->|
    |                                                          |
    |                        [A||RB]                           |
    |<---------------------------------------------------------|

                        Figure 5: Overview of AKEP2

   In AKEP2,

   o  RA and RB are random numbers chosen respectively by Alice and Bob.

   o  A and B are Alice's and Bob's respective identities.  They allow
      Alice and Bob to retrieve the key that they have to use to run an
      authenticated key exchange between each other.  They are also
      included in the protocol for cryptographic reasons.

Top      Up      ToC       Page 20 
   o  The MACs (see Section 1.3 for the notation "[]") are calculated
      using a dedicated key.

   EAP-PSK instantiates this protocol with:

   o  The server as Alice and the peer as Bob.

   o  RA and RB as 16-byte random numbers, using Section 4.1 notations;
      this means RA=RAND_S and RB=RAND_P.

   o  A and B as Alice's and Bob's respective NAIs, using Section 4.1
      notations; this means A=ID_S and B=ID_P.

   o  The MAC algorithm as CMAC with AES-128 using AK and producing a
      tag length of 16 bytes.

   o  The modified counter mode of operation of AES-128 using KDK, to
      derive session keys as a result of this exchange.

   CMAC was chosen as the MAC algorithm because it is capable of
   handling arbitrary length messages, and its design is simple.  It
   also enjoys up-to-date review by the cryptographic community,
   especially using provable security concepts.  It has been recommended
   by the NIST.  For a detailed description of CMAC, please refer to
   [8].

   In AKEP2, the key exchange is "implicit": the session keys are
   derived from RB.  In EAP-PSK, the session keys are thus derived from
   RAND_P by using KDK and the modified counter mode of operation of
   AES-128 described in [5].  This mode was chosen because it is a
   simple key derivation scheme that relies on a block cipher and has a
   proof of its security.  It is a length increasing function, i.e., it
   expands one AES-128 input block into a longer t-block output, where
   t>=2.  The derivation of the session keys is shown in Figure 6.

Top      Up      ToC       Page 21 
   +--------------------------+      +-------------------------------+
   |         RAND_P           |      |              KDK              |
   |  Input Block (16 bytes)  |      | Key Derivation Key (16 bytes) |
   +--------------------------+      +-------------------------------+
               |                                     |
               v                                     v
   +-----------------------------------------------------------------+
   |                                                                 |
   |                         Modified Counter Mode                   |
   |                                                                 |
   +-----------------------------------------------------------------+
          |                     |                         |
          v                     v                         v
   +------------+   +----------------------+   +----------------------+
   |     TEK    |   |          MSK         |   |         EMSK         |
   | (16 bytes) |   |      (64 bytes)      |   |      (64 bytes)      |
   +------------+   +----------------------+   +----------------------+

                 Figure 6: Derivation of the Session Keys

   The input to the derivation of the session keys is RAND_P.

   The outputs of the derivation of the session keys are:

   o  The 16-byte TEK (the first output block).

   o  The 64-byte MSK (the concatenation of the second to fifth output
      blocks).

   o  The 64-byte EMSK (the concatenation of the sixth to ninth output
      blocks).

   The details of the derivation of the session keys are shown in
   Figure 7.

Top      Up      ToC       Page 22 
  +--------------------------+
  |         RAND_P           |
  |  Input Block (16 bytes)  |
  +--------------------------+
                |
                v
       +----------------+
       |                |
       | AES-128(KDK,.) |
       |                |
       +----------------+
                |
                |
                +---------------------+-- - - - - - - - - - --+
                |                     |                       |
                v                     v                       v
  +--------+  +---+     +--------+  +---+       +--------+  +---+
  | c1="1" |->|XOR|     | c2="2" |->|XOR|.......| c9="9" |->|XOR|
  |16 bytes|  +---+     |16 bytes|  +---+       |16 bytes|  +---+
  +--------+    |       +--------+    |         +--------+    |
                |                     |                       |
       +----------------+   +----------------+      +----------------+
       |                |   |                |      |                |
       | AES-128(KDK,.) |   | AES-128(KDK,.) |......| AES-128(KDK,.) |
       |                |   |                |      |                |
       +----------------+   +----------------+      +----------------+
                |                     |                       |
                |                     |                       |
                v                     v                       v
       +-----------------+  +-----------------+     +------------------+
       | Output Block #1 |  | Output Block #2 |     | Output Block #9  |
       |    (16 bytes)   |  |    (16 bytes)   |.....|    (16 bytes)    |
       |      TEK        |  | MSK (block 1/4) |     | EMSK (block 4/4) |
       +-----------------+  +-----------------+     +------------------+

            Figure 7: Derivation of the Session Keys in Details

   The counter values are set respectively to the first t integers (that
   is, ci="i", with i=1 to 9).

   Keying material is sensitive information and should be handled
   accordingly (see Section 8.10 for further discussion).

Top      Up      ToC       Page 23 
3.3.  The Protected Channel

   EAP-PSK provides a protected channel for both parties to communicate
   over, in case of a successful authentication.  This protected channel
   is currently used to exchange protected result indications and may be
   used in the future to implement extensions.

   EAP-PSK uses the EAX mode of operation to provide this protected
   channel.  For a detailed description of EAX, please refer to [4].
   Figure 8 shows how EAX is used to implement EAP-PSK protected
   channel.

   +-----------+ +----------------+ +---------------------+ +----------+
   |  Nonce N  | |    Header H    | | Plain Text Payload  | |   TEK    |
   |  4 bytes  | |    22 bytes    | |  Variable length L  | | 16 bytes |
   +-----------+ +----------------+ +---------------------+ +----------+
         |                 |                   |                 |
         v                 v                   v                 v
   +-------------------------------------------------------------------+
   |                                                                   |
   |                                EAX                                |
   |                                                                   |
   +-------------------------------------------------------------------+
                           |                   |
                           v                   v
                +---------------------+   +----------+
                | Cipher Text Payload |   |   Tag    |
                |  Variable length L  |   | 16 bytes |
                +---------------------+   +----------+

                      Figure 8: The Protected Channel

   This protected channel:

   o  Provides replay protection.

   o  Encrypts and authenticates a Plain Text Payload that becomes an
      Encrypted Payload.  The Plain Text Payload must not exceed 960
      bytes; see Sections 5.3, 5.4, and 8.11.

   o  Only authenticates a Header that is thus sent in clear.

   EAX is instantiated with AES-128 as the underlying block cipher.

   AES-128 is keyed with the TEK.

Top      Up      ToC       Page 24 
   The nonce N is used to provide cryptographic security to the
   encryption and data origin authentication as well as protection
   replay.  Indeed, N is a 4-byte sequence number starting from <0> that
   is monotonically incremented at each EAP-PSK message within one EAP-
   PSK dialog, except retransmissions, of course.

   N was taken to be 4 bytes to avoid 16-byte arithmetic.  Since EAX
   uses a 16-byte nonce, N is padded with 96 zero bits for its high-
   order bits.

   For cryptographic reasons, N is not allowed to wrap around.  In the
   unlikely, yet possible, event of the server sending an EAP-PSK
   message with N set to <2**32-2>, it must not send any further message
   on this protected channel, which would cause to reusing the value 0.
   Either the conversation is finished after the server receives the
   EAP-PSK answer from the peer with N set to <2**32-1> and the server
   proceeds (typically by sending an EAP-Success or Failure), or the
   conversation is not finished and must then be aborted (a new EAP-PSK
   dialog may subsequently be started to try again to authenticate).
   Thus, the maximum number of messages that can be exchanged over the
   same protected channel is 2**32 (which should not be a limitation in
   practice, as this is approximately equal to 4 billion).

   The Header H consists of the first 22 bytes of the EAP Request or
   Response packet (i.e., the EAP Code, Identifier, Length, and Type
   fields followed by the EAP-PSK Flags and RAND_S fields).  Although it
   may appear unorthodox that an upper layer (EAP-PSK) protects some
   information of the lower layer (EAP), this was chosen to comply with
   EAP recommendation (see Section 7.5. of [3]) and seems to be existing
   practice at IETF (see, for instance, [35]).

   The Plain Text Payload is the payload that is to be encrypted and
   integrity protected.  The Cipher Text Payload is the result of the
   encryption of the Plain Text.

   The Tag is a MAC that protects both the Header and the Plain Text
   Payload.  The verification of the Tag must only be done after a
   successful verification of the Nonce for replay protection.  If the
   verification of the Tag succeeds, then the Encrypted Payload is
   decrypted to recover the Plain Text Payload.  If the verification of
   the Tag fails, then no decryption is performed and this MAC failure
   should be logged.  The tag length is chosen to be 16 bytes for EAX
   within EAP-PSK.  This length is considered appropriate by the
   cryptographic community.

Top      Up      ToC       Page 25 
   EAX was mainly chosen because:

   o  It strongly relies on OMAC in its design and OMAC1, a variant of
      OMAC, had already been chosen in EAP-PSK for the authentication
      part (please remember that OMAC1 and CMAC are analogous).

   o  Its design is simple.

   o  It enjoys a security proof.

   o  It is free of any Intellectual Property Rights claims.

4.  EAP-PSK Message Flows

   EAP-PSK may consist of two different types of message flows:

   o  The "standard authentication", which is:

      *  Mandatory to implement.

      *  Fully specified in this document.

      *  The simpler type of message flow, which is expected to be used
         most frequently.

   o  The "extended authentication", which is:

      *  Optional to implement (i.e., there are no mandatory
         extensions).

      *  Partly specified in this document since it depends on
         extensions and none are currently specified, let alone in this
         document.

      *  The type of message flow that should be used when extensions of
         EAP-PSK are needed by more sophisticated usage scenarios and
         are available.

   EAP-PSK introduces the concept of a session to facilitate its
   analysis and provide a cleaner interface to other layers.  A session
   is a particular instance of an EAP-PSK dialog between two parties.
   This session is identified by a session identifier.

   In the first EAP-PSK message, the EAP server asserts its identity.
   Given that the EAP-Request/Identity and EAP-Response/Identity may not
   be assumed to have occurred prior to this sending and that the
   response included in EAP-Response/Identity (if this EAP Identity
   exchange takes place) may not contain the actual NAI the peer shall

Top      Up      ToC       Page 26 
   use with EAP-PSK, this means that an EAP server implementing EAP-PSK
   must use the same EAP server NAI for all EAP-PSK dialogs with any EAP
   peer implementing EAP-PSK.

4.1.  EAP-PSK Standard Authentication

   EAP-PSK standard authentication is comprised of four messages, i.e.,
   two round-trips; see Figure 9.

   peer                                                      server
    |                                    Flags||RAND_S||ID_S   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||RAND_P||MAC_P||ID_P                     |
    |--------------------------------------------------------->|
    |                                                          |
    |                     Flags||RAND_S||MAC_S||PCHANNEL_S_0   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_1                            |
    |--------------------------------------------------------->|
    |                                                          |

                 Figure 9: EAP-PSK Standard Authentication

   o  The first message is sent by the server to the peer to:

      *  Send a 16-byte random challenge (RAND_S).  RAND_S was called RA
         in Section 3.2

      *  State its identity (ID_S).  ID_S was denoted by A in
         Section 3.2.

   o  The second message is sent by the peer to the server to:

      *  Send another 16-byte random challenge (RAND_P).  RAND_P was
         called RB in Section 3.2

      *  State its identity (ID_P).  ID_P was denoted by B in
         Section 3.2.

      *  Authenticate to the server by proving that it is able to
         compute a particular MAC (MAC_P), which is a function of the
         two challenges and AK:
         MAC_P = CMAC-AES-128(AK, ID_P||ID_S||RAND_S||RAND_P)

Top      Up      ToC       Page 27 
   o  The third message is sent by the server to the peer to:

      *  Authenticate to the peer by proving that it is able to compute
         another MAC (MAC_S), which is a function of the peer's
         challenge and AK:
         MAC_S = CMAC-AES-128(AK, ID_S||RAND_P)

      *  Set up the protected channel (P_CHANNEL_S_0) to:

         +  Confirm that it has derived session keys (at least the TEK).

         +  Give a protected result indication of the authentication.

   o  The fourth message is sent by the peer to the server to finish the
      setup of the protected channel (P_CHANNEL_P_1) to:

      *  Confirm that it has derived session keys (at least the TEK).

      *  Give a protected result indication of the authentication.

   The PCHANNEL_S_0 and PCHANNEL_P_1 fields of the third and fourth EAP-
   PSK messages contain a MAC-computed thanks to TEK that protects the
   integrity of the messages.  For a detailed list of the fields of the
   messages that are integrity protected, please refer to Section 3.3.

   All EAP-PSK messages include a sort of header, which is comprised of
   two fields:

   o  Flags, a 1-byte field that is currently only used to number EAP-
      PSK messages.

   o  RAND_S, a 16-byte challenge sent by the server that is used as a
      session identifier.

   This standard message flow could be comprised of only three messages,
   like AKEP2, were it not the request/response nature of EAP that
   prevents the third message to be the last one.  Since the fourth
   message is mandatory, EAP-PSK chose to take advantage of this and set
   up a protected channel.

   The standard message flow also includes a statement by the peer of
   its identity, in addition to the EAP-Response/Identity it may have
   sent.  This behavior follows Section 5.1 of [3], which recommends
   that the EAP-Response/Identity be used primarily for routing purposes
   and selecting which EAP method to use, and therefore that EAP methods
   include a method-specific mechanism for obtaining the identity, so
   that they do not have to rely on the Identity Response.

Top      Up      ToC       Page 28 
   When a party receives an EAP-PSK message, it checks that the message
   is syntactically valid in accordance with the message formats defined
   in Section 5.  If the message is syntactically incorrect, then it is
   silently discarded.  Then it checks the cryptographic validity of
   this message, i.e., it checks the MAC(s) as follows:

   o  If the received message is the first EAP-PSK message, there is no
      MAC to check as none is included in message 1.

   o  If the received message is the second EAP-PSK message, the
      validity of MAC_P is checked.

   o  If the received message is the third EAP-PSK message, the validity
      of MAC_S is checked and then the validity of the Tag included in
      P_CHANNEL_S_0 is checked.  The validity checks must be done in
      this order to avoid unnecessarily deriving TEK, MSK, and EMSK in
      case MAC_S is invalid, meaning that mutual authentication has
      failed.  Indeed, TEK is used to verify the validity of the Tag
      included in P_CHANNEL_S_0.

   o  If the received message is the fourth EAP-PSK message, the
      validity of the Tag included in P_CHANNEL_P_1 is checked.

   If a validity check fails, the message is silently discarded.  There
   can be a counter to track the number of silently discarded messages
   Section 8.8.  If there is an encrypted payload in the message
   (namely, in the PCHANNEL attribute), then the encrypted payload is
   decrypted.  Then, if the decrypted payload is syntactically
   incorrect, the message is silently discarded.

4.2.  EAP-PSK Extended Authentication

   To remain simple and yet be extensible to meet future requirements,
   EAP-PSK provides an extension mechanism within its protected channel:
   the payload of the protected channel may contain an optional
   extension field (EXT).

   Figure 10 presents the message sequence for EAP-PSK extended
   authentication.

   Extended authentication MUST be supported, i.e., any EAP-PSK
   implementation MUST support sending and reception of an EXT attribute
   according to rules of operation described in Section 6.  Yet,
   although support of the EXT field is mandatory, there is no mandatory
   extension type to support.  This means that if a server engages in
   EAP-PSK extended authentication, as only the server can start
   extended authentication per Section 6, a peer will recognize the
   attempt to start extended authentication through its EXT support.  If

Top      Up      ToC       Page 29 
   the peer does not support the particular extension type used by the
   server, the peer will still be able to conclude the EAP-PSK dialog.

   The mandatory support of the EXT field is dictated:

   o  To guarantee a robust behavior in the future where some peers
      might support some extensions and others not.  All peers will thus
      be able to understand that an extended authentication is being
      attempted and indicate whether or not they support the extension
      that is tried.

   o  To ensure that all implementations will indeed be extensible.

   No extension is currently defined.

   At most, one extension may be run within a single EAP-PSK dialog:
   there can neither be sequences of extensions nor interleaved
   extensions.  However, extensions may take a variable number of round-
   trips to complete.

   Only the server can start an extension and, if it does so, it must
   start it in the first payload it sends over the protected channel.

   peer                                                      server
    |                                    Flags||RAND_S||ID_S   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||RAND_P||MAC_P||ID_P                     |
    |--------------------------------------------------------->|
    |                                                          |
    |                Flags||RAND_S||MAC_S||PCHANNEL_S_0(EXT)   |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_1(EXT)                       |
    |--------------------------------------------------------->|
    |                                                          |
    .                                                          .
    .                                                          .
    .                                                          .
    |                       Flags||RAND_S||PCHANNEL_S_2i(EXT)  |
    |<---------------------------------------------------------|
    |                                                          |
    |   Flags||RAND_S||PCHANNEL_P_2i+1(EXT)                    |
    |--------------------------------------------------------->|
    |                                                          |

                Figure 10: EAP-PSK Extended Authentication

Top      Up      ToC       Page 30 
   Please refer to Section 6 for more details on how extended
   authentication works.

   The PCHANNEL_S_2j and PCHANNEL_P_2j+1 fields of the EAP-PSK messages
   (where j varies from 0 to i) contain a MAC-computed thanks to TEK
   that protects the integrity of the messages.  For a detailed list of
   the fields of the messages that are integrity protected, please refer
   to Section 3.3.

   When a party receives an EAP-PSK message, it checks that the message
   is syntactically valid in accordance with the message formats defined
   in Section 5.  If the message is syntactically incorrect, then it is
   silently discarded.  Then it checks the cryptographic validity of
   this message, i.e., it checks the MAC(s) as follows:

   o  If the received message is the first EAP-PSK message, there is no
      MAC to check as none is included in message 1.

   o  If the received message is the second EAP-PSK message, the
      validity of MAC_P is checked.

   o  If the received message is the third EAP-PSK message, the validity
      of MAC_S is checked and then the validity of the Tag included in
      P_CHANNEL_S_0 is checked.  The validity checks must be done in
      this order to avoid unnecessarily deriving TEK, MSK, and EMSK in
      case MAC_S is invalid, meaning that mutual authentication has
      failed.  Indeed, TEK is used to verify the validity of the Tag
      included in P_CHANNEL_S_0.

   o  If the received message is the fourth EAP-PSK message, the
      validity of the Tag included in P_CHANNEL_P_1 is checked.

   o  If the received message is an EAP-PSK message different from the
      first four ones, then validity of the Tag included in P_CHANNEL is
      checked.

   If a validity check fails, the message is silently discarded.  There
   can be a counter to track the number of silently discarded messages
   Section 8.8.  If there is an encrypted payload in the message (namely
   in the PCHANNEL attribute), then the encrypted payload is decrypted.
   Then, if the decrypted payload is syntactically incorrect, the
   message is silently discarded.

Top      Up      ToC       Page 31 
5.  EAP-PSK Message Format

   For the sake of simplicity, EAP-PSK uses a fixed message format.
   There are four different types of EAP-PSK messages:

   o  The first EAP-PSK message, which is sent by the server to the
      peer.

   o  The second EAP-PSK message, which is sent by the peer to the
      server.

   o  The third EAP-PSK message, which is sent by the server to the
      peer.

   o  The fourth EAP-PSK message, which is sent by the peer to the
      server.  This is also the type of message that the peer further
      sends to the server in case of an extended authentication.  This
      is also essentially the type of message that the server further
      sends to the peer in case of an extended authentication: the only
      slight modification that occurs in this last case is the setting
      of the EAP Code to 1 instead of 2 in the other cases.

   For the sake of clarity, the whole EAP packet that encapsulates the
   EAP-PSK message (i.e., the EAP-PSK message plus its EAP headers) is
   depicted in Figures 11, 13, 14, and 18.

Top      Up      ToC       Page 32 
5.1.  EAP-PSK First Message

   The first EAP-PSK message is sent by the server to the peer.  It has
   the format presented in Figure 11.

   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=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type EAP-PSK |     Flags     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             RAND_S                            |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   :                                                               :
   :                              ID_S                             :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 11: EAP-PSK First Message

   Since IANA has allocated EAP method type 47 for EAP-PSK, Type EAP-PSK
   for the first EAP-PSK message as well as any other EAP-PSK message
   MUST be 47.

   The first EAP-PSK message consists of:

   o  A 1-byte Flags field

   o  A 16-byte random number: RAND_S

   o  A variable length field that conveys the server's NAI: ID_S. The
      length of this field is deduced from the EAP length field.  The
      length of this NAI must not exceed 966 bytes.  This restriction
      aims at avoiding fragmentation issues (see Section 8.11).

   The Flags field has the format presented in Figure 12.

Top      Up      ToC       Page 33 
   0
   0 1 2 3 4 5 6 7 8
   +-+-+-+-+-+-+-+-+
   | T | Reserved  |
   +-+-+-+-+-+-+-+-+

                      Figure 12: EAP-PSK Flags Field

   The Flags field is comprised of two subfields:

   o  A 2-bit T subfield, which indicates the type of EAP-PSK message:

      *  T=0 for the first EAP-PSK message presented in Section 5.1.

      *  T=1 for the second EAP-PSK message presented in Section 5.2.

      *  T=2 for the third EAP-PSK message presented in Section 5.3.

      *  T=3 for the fourth EAP-PSK message presented in Section 5.4 and
         the subsequent EAP-PSK messages that may be exchanged during
         extended authentication.

   o  A 6-bit Reserved subfield that is set to zero on transmission and
      ignored on reception.

   The PCHANNEL Nonce field N (see Section 5.3) is used to distinguish
   between the different EAP-PSK messages that may be exchanged during
   extended authentication that all have T set to 3, i.e., the fourth
   EAP-PSK message and possibly the next ones.

Top      Up      ToC       Page 34 
5.2.  EAP-PSK Second Message

   The second EAP-PSK message is sent by the peer to the server.  It has
   the format presented in Figure 13.

   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=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type EAP-PSK |     Flags     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             RAND_S                            |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             RAND_P                            |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   +                                                               +
   |                             MAC_P                             |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   :                              ID_P                             :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 13: EAP-PSK Second Message

Top      Up      ToC       Page 35 
   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that serves as a session identifier

   o  A 16-byte random number: RAND_P

   o  A 16-byte MAC: MAC_P

   o  A variable length field that conveys the peer's NAI: ID_P.  The
      length of this field is deduced from the EAP length field.  The
      length of this NAI must not exceed 966 bytes.  This restriction
      aims at avoiding fragmentation issues (see Section 8.11).

   The Flags field format is presented in Figure 12.

Top      Up      ToC       Page 36 
5.3.  EAP-PSK Third Message

   The third EAP-PSK message is sent by the server to the peer.  It has
   the format presented in Figure 14.

   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=1     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type EAP-PSK |     Flags     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             RAND_S                            |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             MAC_S                             |
   +                                                               +
   |                                                               |
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   :                            PCHANNEL                           :
   :                                                               :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 14: EAP-PSK Third Message

   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that is used as a session identifier

   o  A 16-byte MAC: MAC_S

   o  A variable length field that constitutes the protected channel:
      PCHANNEL

Top      Up      ToC       Page 37 
   The Flags field format is presented in Figure 12.

   If there is no extension, i.e., if the authentication is standard,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see Section 3.3).

   o  A 16-byte Tag (see Section 3.3).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 0.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   R, E, and Reserved are sent encrypted by the protected channel (see
   Section 3.3).

   If there is no extension, PCHANNEL has the format presented in
   Figure 15 (where R, E, and Reserved are presented in the clear for
   the sake of clarity, although in reality they are sent encrypted).

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Nonce                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                              Tag                              |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R |0| Reserved|
   +-+-+-+-+-+-+-+-+

                  Figure 15: The PCHANNEL Field with E=0

   If there is an extension, i.e., if the authentication is extended,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see Section 3.3).

   o  A 16-byte Tag (see Section 3.3).

Top      Up      ToC       Page 38 
   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 1.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   o  A variable length EXT field.

   R, E, Reserved, and EXT are sent encrypted by the protected channel
   (see Section 3.3).

   If there is an extension, PCHANNEL has the format presented in
   Figure 16 where R, E, Reserved and EXT are presented in the clear for
   the sake of clarity, although in reality they are sent encrypted).

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Nonce                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                              Tag                              |
   +                                                               +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | R |1| Reserved|                                               |
   +-+-+-+-+-+-+-+-+                                               +
   :                            EXT                                :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 16: The PCHANNEL Field with E=1

   This EXT field is split in two subfields:

   o  The EXT_Type subfield, which indicates the type of the extension

   o  The EXT_Payload subfield, which consists of the payload of the
      extension.  The EXT_Payload length is derived from the EAP Length
      field.  EXT_Payload must have a bit length that is a multiple of 8
      bits and must not exceed 960 bytes.  The latter restriction aims

Top      Up      ToC       Page 39 
      at avoiding fragmentation issues (see Section 8.11), whereas the
      former comes from the EAP length being specified in bytes.

   The format of the EXT field is presented in Figure 17.

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   EXT_Type    |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   :                           EXT_Payload                         :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 17: The EXT Field

5.4.  EAP-PSK Fourth Message

   The fourth EAP-PSK message is sent by the peer to the server.  It has
   the format presented in Figure 18.

   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=2     |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Type EAP-PSK |     Flags     |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   +                                                               +
   |                             RAND_S                            |
   +                                                               +
   |                                                               |
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   :                                                               :
   :                            PCHANNEL                           :
   :                                                               :
   :                                                               :
   +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 18: EAP-PSK Fourth Message

Top      Up      ToC       Page 40 
   It consists of:

   o  A 1-byte Flags field

   o  The 16-byte random number sent by the server in the first EAP-PSK
      message (RAND_S) that is used as a session identifier

   o  A variable length field that constitutes the protected channel:
      PCHANNEL

   The Flags field format is presented in Figure 12.

   The PCHANNEL field has the following structure, which was already
   described in Section 5.3.

   If there is no extension, i.e., if the authentication is standard,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see Section 3.3).

   o  A 16-byte Tag (see Section 3.3).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 0.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

   R, E, and Reserved are sent encrypted by the protected channel (see
   Section 3.3).

   If there is no extension, PCHANNEL has the format presented in
   Figure 15.

   If there is an extension, i.e., if the authentication is extended,
   the PCHANNEL field consists of:

   o  A 4-byte Nonce N (see Section 3.3).

   o  A 16-byte Tag (see Section 3.3).

   o  A 2-bit result indication flag R.

   o  A 1-bit extension flag E, which is set to 1.

   o  A 5-bit Reserved field, which is set to zero on emission and
      ignored on reception.

Top      Up      ToC       Page 41 
   o  A variable length EXT field.

   R, E, Reserved, and EXT are sent encrypted by the protected channel
   (see Section 3.3).

   If there is an extension, PCHANNEL has the format presented in
   Figure 16.

   This EXT field is split in two subfields:

   o  The EXT_Type subfield, which indicates the type of the extension

   o  The EXT_Payload subfield, which consists of the payload of the
      extension.  The EXT_Payload length is derived from the EAP Length
      field.  EXT_Payload must have a bit length that is a multiple of 8
      bits and must not exceed 960 bytes.  The latter restriction aims
      at avoiding fragmentation issues (see Section 8.11).

   The format of the EXT field is presented in Figure 17.



(page 41 continued on part 3)

Next RFC Part