tech-invite   World Map     

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

RFC 4793

 
 
 

The EAP Protected One-Time Password Protocol (EAP-POTP)

Part 2 of 3, p. 20 to 56
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 20 
4.11.  EAP-POTP TLV Objects

4.11.1.  Version TLV

   The Version TLV carries information about the supported EAP-POTP
   method version.

   This TLV MUST be present in the initial EAP-Request of type POTP-X
   from the EAP server and in the initial response of type POTP-X from
   the peer.  It MUST NOT be present in any subsequent EAP-Request or
   EAP-Response in the session.  The Version TLV MUST be supported by
   all peers, and all EAP servers conforming to this specification and
   MUST NOT be responded to with a NAK TLV.  The version negotiation
   procedure is described in detail in Section 4.2.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |    Highest    |    Lowest     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      1

   Length

      3 in EAP-Requests, 2 in EAP-Responses

Top      Up      ToC       Page 21 
   Reserved

      Reserved for future use.  This octet MUST be set to zero for this
      version.  Recipients SHALL ignore this octet for this version of
      EAP-POTP.

   Highest

      This field contains an unsigned integer representing the highest
      protocol version supported by the sender.  If a value provided by
      a peer to an EAP server falls between the server's "Highest" and
      "Lowest" supported version (inclusive), then that value will be
      the negotiated version for the authentication session.

   Lowest

      This field contains an unsigned integer representing the lowest
      version acceptable by the EAP server.  The field MUST be present
      in an EAP-Request.  The field MUST NOT be present in an EAP-
      Response.  A peer SHALL respond to an EAP-Request of type POTP-X
      with an EAP-Response of type Nak (3) if the peer's highest
      supported version is lower than the value of this field.

   This document defines version 1 of the protocol.  Therefore, EAP
   server implementations conforming to this document SHALL set the
   "Highest" field to 1.  Peer implementations conforming to this
   document SHALL set the "Highest" field to 1.

4.11.2.  Server-Info TLV

   The Server-Info TLV carries information about the EAP server and the
   session (when applicable).  It provides one piece in the framework
   for fast session resumption.

   This TLV SHOULD always be present in an EAP-Request of type POTP-X
   that also carries an OTP TLV, as long as the peer has not been
   authenticated, and MUST be present in such a request if the server
   supports session resumption.  It MUST NOT be present in any other
   EAP-Request of type POTP-X or in any EAP-Response packets.  This TLV
   type MUST be supported by all peers conforming to this specification
   and MUST NOT be responded to with a NAK TLV (this is not to say that
   all peers need to support session resumption, only that they cannot
   respond to this TLV with a NAK TLV).

Top      Up      ToC       Page 22 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved  |N|            Session Identifier                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Session Identifier (continued)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sess.Id (cont.)|             Nonce ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Server Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      2

   Length

      25 + length of Server Identifier field

   Reserved

      Reserved for future use.  All 7 bits MUST be set to zero for this
      version.  Recipients SHALL ignore this bit for this version of
      EAP-POTP.

   N

      The N bit signals that the peer MUST NOT attempt to resume any
      session it has stored associated with this server.

Top      Up      ToC       Page 23 
   Session Identifier

      An 8-octet identifier for the session about to be negotiated.
      Note that, in the case of session resumption, this session
      identifier will not be used (the session identifier for the
      resumed session will continue to be used).

   Nonce

      A 16-octet nonce chosen by the server.  During session resumption,
      this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK,
      and EMSK keys as specified below.

   Server Identifier

      An identifier for the authentication server.  The peer MAY use
      this identifier to search for a stored session associated with
      this server, or to associate the session to be negotiated with the
      server.  The value of the identifier SHOULD be chosen so as to
      reduce the risk of collisions with other EAP server identifiers as
      much as possible.  One possibility is to use the DNS name of the
      EAP server.  The identifier MAY also be used by the peer to select
      a suitable key on the OTP token (when there are multiple keys
      available).

      The identifier MUST NOT be longer than 128 octets.  The identifier
      SHALL be a UTF-8 [7] encoded string of printable characters
      (without any terminating NULL character).

4.11.3.  OTP TLV

   In an EAP-Request, the OTP TLV is used to request an OTP (or a value
   derived from an OTP) from the peer.  In an EAP-Response, the OTP TLV
   carries an OTP or a value derived from an OTP.

   This TLV type MUST be supported by all peers and all EAP servers
   conforming to this specification and MUST NOT be responded to with a
   NAK TLV.  The OTP TLV MUST NOT be present in an EAP-Request of type
   POTP-X that contains a New PIN TLV.  Further, the OTP TLV MUST NOT be
   present in an EAP-Response of type POTP-X unless the preceding EAP-
   Request of type POTP-X contained an OTP TLV and it was valid for it
   to do so.  Finally, an OTP TLV MUST NOT be present in an EAP-
   Response of type POTP-X that also contains a Resume TLV.  The OTP TLV
   is defined as follows:

Top      Up      ToC       Page 24 
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved    |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Iteration Count (cont.)            |  Auth. Data   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Authentication Data (cont.) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      3

   Length

      7 + length of Authentication Data field

   Reserved

      Reserved for future use.  All 9 bits SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore these bits for this version
      of EAP-POTP.

   A

      The A bit MUST be set in an EAP-Request if and only if the request
      immediately follows an EAP-Response of type POTP-X containing a
      New PIN TLV (see Section 4.11.5), and the new PIN in the response
      was accepted by the EAP server.  In this case, the A bit signals
      that the EAP-server has accepted the PIN, and that the peer SHALL
      use the newly established PIN when calculating the response (when
      applicable).  The A bit MUST NOT be set if the S bit is set.  If a
      request has both the S bit and the A bit set, the peer SHALL
      regard the request as invalid, and return an empty POTP-X EAP-
      Response message.

Top      Up      ToC       Page 25 
      In an EAP-Response, the A bit, when set, indicates that the OTP
      was calculated with the use of the newly selected user PIN.  The A
      bit MUST be set in a response if and only if the EAP-Request which
      triggered the response contained an OTP TLV with the A bit set.

   P

      In an EAP-Request, the P bit indicates that the OTP in the
      response MUST be protected.  Use of this bit also indicates that
      mutual authentication will take place, as well as generation of
      keying material.  It is RECOMMENDED to always set the P bit.  If a
      peer receives an EAP-Request with an OTP TLV that does not have
      the P bit set, and the peer's policy dictates protected mode, the
      peer MUST respond with an empty POTP-X EAP-Response message.  All
      peers MUST support protected mode.

      In an EAP-Response, this bit indicates that the provided OTP has
      been protected (see below).  The P bit MUST be set in a response
      (and hence the OTP MUST be protected) if and only if the EAP-
      Request that triggered the response contained an OTP TLV with the
      P bit set.

      In an 802.1x EAP over LAN (EAPOL) environment (this includes
      wireless LAN environments), the P bit MUST be set, or,
      alternatively, the EAP-POTP method MUST be carried out inside an
      authenticated tunnel that provides a cryptographic binding with
      inner EAP methods such as the one provided by PEAPv2 [17].

   C

      The C bit carries meaning only when the OTP algorithm in question
      makes use of server challenges.  For other OTP algorithms, the C
      bit SHALL always be set to zero.

      In an EAP-Request, the C bit ("Combine") indicates that the OTP
      SHALL be calculated using both the provided challenge and internal
      state (e.g., current token time).  The OTP SHALL be calculated
      based only on the provided challenge (and the shared secret) if
      the C bit is not set, and a challenge is present.  The returned
      OTP SHALL always be calculated based on the peer's current state
      (and the shared secret) if no challenge is present.  If the C bit
      is set but no challenge is provided, the peer SHALL regard the
      request as invalid, and return an empty POTP-X EAP-Response
      message.

Top      Up      ToC       Page 26 
      In an EAP response, this bit indicates that the provided OTP has
      been calculated using a provided challenge and the token state.
      The C bit MUST be set in a response if and only if the EAP-Request
      that triggered the response contained an OTP TLV with the C bit
      set and a challenge.

   N

      In an EAP-Request, the N bit, when set, indicates that the OTP to
      calculate SHALL be based on the next token "state", and not the
      current one.  As an example, for a time-based token, this means
      the next time slot.  For an event-based token, this could mean the
      next counter value, if counter values are used.  This bit will
      normally not be set in initial EAP-Request messages, but may be
      set in subsequent ones.  Further, the N bit carries no meaning in
      an EAP-Request if a challenge is present and the C bit is not set,
      and SHALL be set to 0, in this case.  If a request that has the N
      bit set also contains a challenge, but does not have the C bit
      set, the peer SHALL regard the request as invalid, and return an
      empty POTP-X EAP-Response message.  Note that setting the N bit in
      an EAP-Request will normally advance the internal state of the
      token.

      In an EAP-Response, the N bit, when set, indicates that the OTP
      was calculated based on the next token "state" (as explained
      above), and not the current one.  The N bit MUST be set in a
      response if and only if the EAP-Request that triggered the
      response contained an OTP TLV with the N bit set.

   T

      The T bit only carries meaning for OTP methods normally
      incorporating a user PIN in the OTP computation.

      In an EAP-Request, the T bit, when set, indicates that the OTP to
      calculate MUST NOT include a user PIN.

      In an EAP-Response, the T bit, when set, indicates that the OTP
      was calculated without the use of a user PIN.  The T bit MUST be
      set in a response if and only if the EAP-Request that triggered
      the response contained an OTP TLV with the T bit set.  Note that
      client policy may prohibit PIN-less calculations; in these cases,
      the client MAY respond with an empty POTP-X EAP response message.

Top      Up      ToC       Page 27 
   E

      In an EAP-Request, the E bit, when set, indicates that the peer
      MUST NOT use any stored pepper value associated with this server
      in the PBKDF2 computation.  Rather, it MUST generate a new pepper
      (if supported by the peer) and/or use the iteration count
      parameter to protect the OTP (if the server's Max Pepper Length is
      0, then the peer MUST rely on the iteration count only to protect
      the OTP).  This bit will usually not be set in initial EAP-Request
      messages, but may be set in subsequent ones, e.g., if the server,
      upon receipt of an OTP TLV with a pepper identifier, detects that
      it does not have a pepper with that identifier in storage.  This
      bit carries no meaning, and MUST be set to zero, when the P bit is
      not set.  If a request has the E bit set but not the P bit, a peer
      SHALL regard the request as invalid, and return an empty POTP-X
      EAP-Response message.

      In an EAP-Response, the E bit indicates that the response has been
      calculated without use of any stored pepper value.

   S

      In an EAP-Request, the S bit ("Same"), when set, indicates that
      the peer SHOULD calculate its response based on the same OTP value
      as was used for the preceding response.  This bit MAY be set when
      the EAP server has received an OTP TLV from the peer protected
      with a pepper, of which the server is no longer in possession.
      Since the server has not attempted validation of the provided
      data, there is no need for the EAP peer to retrieve a new OTP
      value.  This bit carries no meaning, and MUST be set to zero, when
      the E bit is not set.  A peer SHALL regard a request where the S
      bit is set, but not the E bit, as invalid, and return an empty
      POTP-X EAP-Response message.  Further, the S bit MUST NOT be set
      when the A bit also is set; see above.

      In an EAP-Response, the S bit is never set.

   Pepper Length

      This octet SHALL be present if and only if the P bit is set.  When
      present, it contains an unsigned integer, having a value between 0
      and 255 (inclusive).  In an EAP-Request, the integer represents
      the maximum length (in bits) of a client-generated pepper the
      server is prepared to search for.  Peers MUST NOT generate peppers
      longer than this value.  If the value is set to zero, it means the
      peer MUST NOT generate a pepper for the PBKDF2 calculation.  In an
      EAP-Response, it indicates the length of the used pepper.

Top      Up      ToC       Page 28 
   Iteration Count

      These 4 octets SHALL be present if and only if the P bit is set.
      When present, they contain an unsigned, 4-octet integer in network
      byte order.  In an EAP-Request, the integer represents the maximum
      iteration count the peer may use in the PBKDF2 computation.  Peers
      MUST NOT use iteration counts higher than this value.  In an EAP-
      Response, it indicates the actual iteration count used.

   Note regarding the Pepper Length and Iteration Count parameters: A
   peer MUST compare these policy parameters provided by the EAP server
   with local policy and MUST NOT continue the handshake if use of the
   EAP server's suggested parameters would result in a lower security
   than the client's acceptable policy.  If the security given by the
   EAP server's provided policy parameters surpasses the security level
   given by the peer's local policy, the client SHOULD use the server's
   parameters (subject to reason - active attackers could otherwise
   mount simple denial-of-service attacks against peers or servers,
   e.g., by providing unreasonably high values for the iteration count).
   Note that the server-provided parameters only apply to the case where
   the peer cannot use or does not have a previously provided server-
   provided pepper.  If a peer cannot continue the handshake due to the
   server's policy being unacceptable, it MUST return an empty POTP-X
   EAP-Response message.

   Authentication Data

   EAP-Request:  In an EAP-Request, the Authentication Data field, when
      present, contains an optional "challenge".  The challenge is an
      octet string that SHOULD be uniquely generated for each request in
      which it is present (i.e., it is a "nonce"), and SHOULD be 8
      octets or longer.  To avoid fragmentation (i.e., EAP messages
      longer than the minimum EAP MTU size; see [1]), the challenge MUST
      NOT be longer than 64 octets.  When the challenge is not present,
      the OTP will be calculated on the current token state only.  The
      peer MAY ignore a provided challenge if and only if the OTP token
      the peer is interacting with is not capable of including a
      challenge in the OTP calculation.  In this case, EAP server
      policies will determine whether or not to accept a provided OTP
      value.

   EAP-Response: The following applies to the Authentication Data field
      in an EAP-Response:

      *  When the P bit is not set, the peer SHALL directly place the
         OTP value calculated by the token in the Authentication Data
         field.  In this case, the EAP server MUST NOT send a Confirm

Top      Up      ToC       Page 29 
         TLV upon successful authentication of the peer (instead, it
         sends an EAP-Success message).

      *  When the P bit is set, the peer SHALL populate this field as
         follows.  After the token has calculated the OTP value, the
         peer SHALL compute:

            K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper
            | auth_id, iteration_count, key_length)

            where

            "|" denotes concatenation,

            "otp" is the already computed OTP value,

            "salt" is a 16-octet nonce,

            "pepper" is an optional nonce (at most, 255 bits long, and,
            if necessary, padded to be a multiple of 8 bits long; see
            below) included to complicate the task of finding a matching
            "otp" value for an attacker,

            "auth_id" is an identifier (at most, 255 octets in length)
            for the authenticator (i.e., the network access server) as
            reported by lower layers and as specified below,

            "iteration_count" is an iteration count chosen such that the
            computation time on the peer is acceptable (based on the
            server's indicated policy and the peer's local policy),
            while an attacker, having observed the response and
            initiating a search for a matching OTP, will be sufficiently
            slowed down.  The "iteration_count" value MUST be chosen to
            provide a suitable level of protection (e.g., at least
            100,000) unless a server-provided pepper is being used, in
            which case, it SHOULD be 1.

            "key_length" is the combined length of the desired key
            material, in octets.  When the default algorithms are used,
            key_length is 176.

            The "pepper" values are only included in PBKDF2 calculations
            and are never sent to EAP servers (though the peers do send
            their length, in bits).  The purpose of the pepper values
            are, as mentioned above, to slow down an attacker's search
            for a matching OTP, while not slowing down the peer (which
            iterated hashes do).  If the pepper has been generated by
            the peer, and the chosen pepper length in bits is not a

Top      Up      ToC       Page 30 
            multiple of 8, then the pepper value SHALL be padded to the
            left, with '0' bits to the nearest multiple of 8 before
            being used in the PBKDF2 calculation.  This is to ensure the
            input to the calculation consists only of whole octets.  As
            an example, if the chosen pepper length is 4, the pepper
            value will be padded to the left, with 4 '0' bits to form an
            octet before being used in the PBKDF2 calculation.

            When pepper is used, it is RECOMMENDED that the length of
            the pepper and the iteration count are chosen in such a way
            that it is computationally infeasible/unattractive for an
            attacker to brute-force search for the given OTP within the
            lifetime of that OTP.

            As mentioned previously, a peer MUST NOT include a newly
            generated pepper value in the PBKDF2 computation if the
            server did not indicate its support for pepper searching in
            this session.  If the server did not indicate support for
            pepper searching, then the PBKDF2 computation MUST be
            carried out with a sufficiently higher number of iterations
            so as to compensate for the lack of pepper (see further
            Appendix D).

            A server may, in an earlier session, have transferred a
            pepper value to the peer in a Confirm TLV (see below).  When
            this is the case, and the peer still has that pepper value
            stored for this server, the peer MUST NOT generate a new
            pepper but MUST, instead, use this transferred pepper value
            in the PBKDF2 calculations.  The only exception to this is
            when a local policy (e.g., timer) dictates that the peer
            must switch to a new pepper (and the server indicated
            support for pepper searching).

            The following applies to the auth_id component:

            -  For dial-up, "auth_id" SHALL be either the empty string
               or the phone number called by the peer.  The phone number
               SHALL be specified in the form of a URL conformant with
               RFC 3966 [8], e.g., "tel:+16175550101".  Processing of
               received phone numbers SHALL be conformant with RFC 3966
               (this assumes that "tel" URIs will be shorter than 256
               octets, which would normally be the case).

            -  For use with IEEE 802.1X, "auth_id" SHALL be either the
               empty string or the MAC address of the authenticator in
               canonical binary format (6 octets).

Top      Up      ToC       Page 31 
            -  For IP-based EAP, "auth_id" SHALL be either the empty
               string or the IPv4 or IPv6 address of the authenticator
               as seen by the peer and in binary format (4 or 16 octets,
               respectively).  As an example, the IPv4 address
               "192.0.2.5" would be represented as (in hex) C0 00 02 05,
               whereas the IPv6 address "2001:DB8::101" would be
               represented as (in hex) 20 01 0D B8 00 00 00 00 00 00 00
               00 00 00 01 01.

            Note: Use of the authenticator's identifying information
            within the computation aids in protection against man-in-
            the-middle attacks, where a rogue authenticator seeks to
            intercept and forward the Authentication Data in order to
            impersonate the peer at a legitimate authenticator (but see
            also the discussion around spoofed authenticator addresses
            in Section 6).  For these reasons, a peer SHOULD NOT set the
            auth_id component to the empty string unless it is unable to
            learn the identifying information of the authenticator.  In
            these cases, the EAP server's policy will determine whether
            or not the session may continue.

            As an example, when otp = "12345678", salt =
            0x54434534543445435465768789099880, pepper is not used,
            auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and
            key_length = 176 (decimal), the input to the PBKDF2
            calculation will be (first two parameters in hex, line wrap
            for readability):

            (3132333435363738, 54434534543445435465768789099880 |
            c0000205, 2000, 176)

            As described, when the default algorithms are used, K_MAC is
            the first 16 octets of the output from PBKDF2, K_ENC the
            next 16 octets, MSK the following 64 octets, EMSK the next
            64 octets, and SRK the final 16 octets.  Using K_MAC, the
            peer calculates:

            mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))

            as specified in Section 4.9 and where msg_1, msg_2, ...,
            msg_n is a sequence of all EAP messages of type POTP-X
            exchanged so far in this session, as sent and received by
            the peer (for the peer's initial MAC, it will typically be
            just one message: the EAP server's initial EAP-Request of
            type POTP-X).

Top      Up      ToC       Page 32 
            The peer then places the first 16 octets of "mac" in the
            Authentication Data field, followed by the "salt" value,
            followed by one octet representing the length of the
            "auth_id" value in octets, followed by the actual "auth_id"
            value in binary form, and optionally followed by a pepper
            identifier (only when the peer made use of a pepper value
            previously provided by the EAP server).  Pepper identifiers,
            when present, are always 4 octets.  All variables SHALL be
            present in the form they were input to the PBKDF2 algorithm.
            This will result in the Authentication Data field being 33 +
            (length of auth_id in octets) + (4, for pepper identifier,
            when present) octets in length.

            Continuing the previous example, the Authentication Data
            field will be populated with (in hex, line wrap for
            readability):

            < 16 octets of mac > | 54434534543445435465768789099880 |
            04 | c0000205

            Note: Since in this case (i.e., when the P bit is set)
            successful authentication of the peer by the EAP server will
            be followed by the transmission of an EAP-Request of type
            POTP-X containing a Confirm TLV for mutual authentication,
            the peer MUST save either all the input parameters to the
            PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and
            EMSK (recommended, since they will be used later).  This is
            because the peer cannot be guaranteed to be able to generate
            the same OTP value again.  For the same reason (the Confirm-
            TLV from the EAP server), the peer MUST also store either
            the hash of the contents of the sent EAP-Response or the
            EAP-Response itself (but see the note above about not
            including any User Identifier TLVs in the hash computation).

            Given a set of possible OTP values, the authentication
            server verifies an authentication request from the peer by
            computing

            K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp',
              salt | pepper' | auth_id, iteration_count, key_length)

            for each possible OTP value otp' and each possible pepper
            value pepper' , and the provided values for salt,
            authenticator identity, and iteration count, as well as the
            applicable key length (default: 176).  Note: Doing the
            computation for each possible pepper value implements the
            pepper search mentioned elsewhere in this document.  Note
            also that the EAP server may accept more than one OTP value

Top      Up      ToC       Page 33 
            at a given time, e.g., due to clock drift in the token.  If
            the given pepper length is not a multiple of 8, each tested
            pepper value will be padded to the left to the nearest
            multiple of 8, in the same manner as was done by the peer.
            If the server already shares a secret pepper value with this
            peer, then obviously there will only be one possible pepper
            value, and the server will find it based on the
            pepper_identifier provided by the peer.  The server SHALL
            send a new EAP-Request of type POTP-X with an OTP TLV with
            the E bit set if the peer provided a pepper identifier
            unknown to the server.

            For each K_MAC', the EAP server computes

            mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))

            where MAC is the negotiated MAC algorithm, msg_hash is the
            message hash algorithm defined in Section 4.9, and msg_1',
            msg_2', ... msg_n' are the same messages on which the peer
            calculated its message hash, but this time, as sent and
            received by the EAP server.  If the first 16 octets of mac'
            matches the first 16 octets in the Authentication Data field
            of the EAP-Response in question, and the provided
            authenticator identity is acceptable (e.g., matches the EAP
            server's view of the authenticator's identity), then the
            peer is authenticated.

            If the authentication is successful, the authentication
            server then attempts to authenticate itself to the peer by
            use of the Confirm TLV (see below).  If the authentication
            fails, the EAP server MAY send another EAP-Request of type
            POTP-X containing an OTP TLV to the peer, or it MAY send an
            EAP-Failure message (in both cases, possibly preceded by an
            EAP-Request of type Notification).

4.11.4.  NAK TLV

   Presence of this TLV indicates that the peer did not support a
   received TLV with the M bit set.  This TLV may occur 0, 1, or more
   times in an EAP-Response of type POTP-X.  Each occurrence flags the
   non-support of a particular received TLV.

   The NAK TLV MUST be supported by all peers and all EAP servers
   conforming to this specification and MUST NOT be responded to with a
   NAK TLV.  Receipt of a NAK TLV by an EAP server MAY cause an
   authentication to fail, and the EAP server to send an EAP-Failure
   message to the peer.

Top      Up      ToC       Page 34 
   Note: The definition of the NAK TLV herein matches the definition
   made in [17], and has the same type number.  Field descriptions are
   copied from that document, with some minor modifications.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            NAK-Type           |           TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      4

   Length

      6 + cumulative total length of embedded TLVs

   Vendor-Id

      The Vendor-Id field is 4 octets, and contains the Vendor-Id of the
      TLV that was not supported.  The high-order octet is 0 and the
      low-order 3 octets are the Structure of Management Information
      (SMI) Network Management Private Enterprise Code of the Vendor in
      network byte order.  The Vendor-Id field MUST be zero for TLVs
      that are not Vendor-Specific TLVs.  For Vendor-Specific TLVs, the
      Vendor-ID MUST be set to the SMI code.

   NAK-Type

   The type of the unsupported TLV.  The TLV MUST have been included in
   the most recently received EAP message.

Top      Up      ToC       Page 35 
   TLVs

   This field contains a list of TLVs, each of which MUST NOT have the
   mandatory bit set.  These optional TLVs can be used in the future to
   communicate why the offending TLV was determined to be unsupported.

4.11.5.  New PIN TLV

   In an EAP-Request, the New PIN TLV is used to request a new user PIN
   from the peer.  The EAP server MAY provide a new PIN, as described
   below.  In an EAP-Response, the New PIN TLV carries a chosen new user
   PIN.  This TLV may be used by an EAP server when policy dictates that
   the peer (user) needs to change a PIN associated with the OTP Token.

   This TLV type SHOULD be supported by peers and EAP servers conforming
   to this specification.  The New PIN TLV MUST NOT be sent by an EAP
   server unless the peer has been authenticated.  If the peer was
   authenticated in protected mode, then the New PIN TLV MUST NOT be
   present in an EAP-Request until after the exchange of the Confirm TLV
   (i.e., until after mutual authentication has occurred and keys are in
   place to protect the TLV).  The New PIN TLV MUST be sent by a peer if
   and only if the EAP-Request that triggered the response contained a
   New PIN TLV, it was valid for the EAP server to send such a TLV in
   that request, and the TLV is supported by the peer.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Reserved  |Q|A|  PIN Length   |             PIN ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Min. PIN Length|Max. PIN Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      5

Top      Up      ToC       Page 36 
   Length

      2 + length of the PIN field (as specified in the PIN Length field)
        + (0, 1, or 2)

      Note: The final term above is
      -  0 if none of the optional Min. / Max. PIN Length fields is
           present in the TLV,
      -  1 if only the Min. PIN Length field is present in the TLV,
      -  2 if both of these optional fields are present in the TLV.

   Reserved

      Reserved for future use.  All six bits SHALL be set to zero for
      this version.  Recipients SHALL ignore these bits for this version
      of EAP-POTP.

   Q

      The Q bit, when set in an EAP-Request, indicates that an
      accompanying PIN is required, i.e., the peer (user) is not free to
      choose another PIN.  When the Q bit is set, there MUST be an
      accompanying PIN and the provided PIN MUST be used in subsequent
      OTP generations.  A peer SHALL respond with an empty POTP-X EAP-
      Response message if the Q bit is set but there is not any
      accompanying PIN.  When the Q bit is not set, any provided PIN is
      suggested only, and the peer is free to choose another PIN,
      subject to local policy.

      The Q bit carries no meaning, and SHALL be set to zero, in an EAP-
      Response.

   A

      This bit allows methods that distinguish between two different PIN
      types (e.g., decimal vs. alphanumeric) to designate whether the
      augmented set is to be used (when set) or not (when not set).  The
      A bit carries no meaning, and SHALL be set to zero, in an EAP-
      Response.

   PIN Length

      This field contains an unsigned integer representing the length of
      the provided PIN (this implies that the maximum length of a PIN
      will be 255 octets).

Top      Up      ToC       Page 37 
   PIN

      In an EAP-Request, subject to the setting of the Q bit, the PIN
      field MAY be empty.  If empty, the peer (user) will need to choose
      a PIN subject to local and (any) provided policy.  When the PIN
      field is not empty, it MUST consist of UTF-8 encoded printable
      characters without a terminating NULL character.

      In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded
      string of printable characters without a terminating NULL
      character.

      The peer accepts a PIN suggested by the EAP server by replying
      with the same PIN, but MAY replace it with another one, depending
      on the server's setting of the Q bit.  The length of the PIN is
      application-dependent, as are any other requirements for the PIN,
      e.g., allowed characters.  The peer MUST be prepared to receive a
      repeated request for a new PIN, as described above, if the EAP
      server, for some reason does not accept the received PIN.  Such a
      request MAY be preceded by an EAP-Request of type Notification (2)
      providing information to the user about the reason for the
      rejection.  Mechanisms for transferring knowledge about PIN
      requirements from the EAP server to the peer (beyond those
      specified for this TLV, such as maximal and minimal PIN length)
      are outside the scope of this document.  However, some information
      MAY be provided in notification messages transferred from the EAP
      server to the peer, as per above.

   Min. PIN Length

      This field MAY be present in an EAP-Request.  This field MUST NOT
      be present in an EAP-Response.  It SHALL be interpreted as an
      unsigned integer in network byte order representing the minimum
      length allowed for a new PIN.

   Max. PIN Length

      This field MUST NOT be present in an EAP-Request unless the Min.
      PIN Length field is present, in which case it MAY be present.  The
      field MUST NOT be present in an EAP-Response.  It SHALL be
      interpreted as an unsigned integer in network byte order
      representing the maximum length allowed for a new PIN.  The value
      of this field, when present, MUST be equal to, or larger than, the
      value of the Min. PIN Length field.

Top      Up      ToC       Page 38 
4.11.6.  Confirm TLV

   Presence of this TLV in a request indicates that the EAP server has
   successfully authenticated the peer and now attempts to authenticate
   itself to the peer.  Presence of this TLV in a response indicates
   that the peer successfully authenticated the EAP server, and that
   calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become
   available for use.

   The Confirm TLV MUST NOT appear together with any other TLV in an
   EAP-Request message of type POTP-X and MUST NOT be sent unless the
   peer has been authenticated through an OTP TLV with the P bit set or
   through a Resume TLV for which the underlying session was established
   in protected mode.  The Confirm TLV MUST be present in an EAP-
   Response if and only if the request that triggered the response
   contained a Confirm TLV, it was legal for it to do so, and the
   Confirm TLV authenticated the EAP server to the peer.  If the peer
   was not able to authenticate the server, then it MUST send an empty
   (i.e., no TLVs present) EAP-Response of type POTP-X.

   An EAP server MUST send an EAP-Success message after receiving an
   EAP-Response of type POTP-X containing a valid Confirm TLV, sent in
   response to an EAP-Request containing a Confirm TLV where the C bit
   was not set.  A peer MUST NOT accept an EAP-Success message when it
   has sent an OTP TLV with the P bit set unless it has received an
   acceptable Confirm TLV from the EAP server.

   This TLV type MUST be supported by all peers and EAP servers
   conforming to this specification and MUST NOT be responded to with a
   NAK TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved  |C|       Authentication Data ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Pepper Identifier                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              IV ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Encrypted Pepper ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

Top      Up      ToC       Page 39 
   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      6

   Length

      17 or 37 + length of IV in requests, 1 in responses.

   Reserved

      Reserved for future use.  These 7 bits SHALL be set to zero (0)
      for this version.  Recipients SHALL ignore these bits for this
      version of EAP-POTP.

   C

      The C bit, when set in an EAP-Request, indicates that the EAP
      server intends to send more EAP-Requests of type POTP-X in this
      session, after receipt of a Confirm TLV from the peer.

      The C bit carries no meaning in EAP-Responses, and MUST NOT be set
      within them.

      Note: An EAP-Response containing a Confirm TLV, sent in response
      to an EAP-Request containing a Confirm TLV that did not have the C
      bit set, MUST be followed by an EAP-Success message from the EAP
      server concluding the handshake.  However, when the C bit was set
      in an EAP-Request, the EAP server MAY send another EAP-Request
      (containing, for example, a New PIN TLV wrapped in a Protected
      TLV) rather than an EAP-Success message.  Therefore, peers MUST
      NOT assume that the only EAP message following an EAP-Response of
      type POTP-X containing a Confirm TLV is EAP-Success.  The C bit
      gives EAP servers a way to indicate their intent to follow the
      Confirm TLV with more requests, and allows the peer's state
      machine to adapt to this.

   Authentication Data

   EAP-Request:

         In a request, this field consists of the first 16 octets of
         (see also Section 4.11.3):

Top      Up      ToC       Page 40 
         mac_a = MAC(K_MAC', msg_hash(trig_msg))

         where

         MAC is the negotiated MAC algorithm,

         "K_MAC'" has been calculated as described in Section 4.11.3 or
         (in the case of session resumption) Section 4.11.8, and

         "msg_hash" is the message hash algorithm defined in Section
         4.9, and "trig_msg" the latest EAP-Response of type POTP-X
         received from the peer (the one which triggered this request).

         Given a saved or recomputed value for K_MAC, the peer
         authenticates the EAP server by computing

         mac'' = MAC(K_MAC, msg_hash(trig_msg'))

         where "msg_hash(trig_msg')" is the peer's hash of the EAP-
         Response message that it sent to the server (and that the
         server calculated its message hash on).  If the first 16 octets
         of mac'' matches the first 16 octets in the Authentication Data
         field of the EAP-Request in question, then the EAP server is
         authenticated.

   EAP-Response:

         Not used in this version, and SHALL NOT be present in EAP-
         Responses.

   Pepper Identifier

      In an EAP-Request, the truncated MAC MAY optionally be followed by
      an encrypted pepper and its identifier.  This initial, 4-octet
      field identifies a pepper generated by the server.

      For this version of EAP-POTP, this field SHALL NOT be present in
      EAP-Responses.

   IV (Initialization Vector)

      An initialization vector for the encryption.  The length of the
      vector is dependent on the negotiated encryption algorithm.  For
      example, for AES-CBC, it SHALL be 16 octets.  The IV is only
      present if a pepper is present, and the negotiated encryption
      algorithm makes use of an IV.  This field SHALL NOT be present in
      EAP-Response messages for this version of EAP-POTP.

Top      Up      ToC       Page 41 
   Encrypted Pepper

      When present in an EAP-Request, this will be a uniformly
      distributed and randomly chosen 16-octet pepper generated by the
      EAP server and encrypted with the negotiated encryption algorithm,
      using K_ENC as the encryption key and possibly (depending on the
      encryption algorithm) using an IV (stored in the IV field).  This
      field MUST be present if and only if the Pepper Identifier field
      is present.

      EAP servers are RECOMMENDED to include a freshly generated
      encrypted pepper (and a corresponding Pepper Identifier) in every
      Confirm TLV.

      This field SHALL NOT be present in EAP-Response messages for this
      version of EAP-POTP.

   When a new pepper is generated by the server and transferred in
   encrypted form to the peer, then this new pepper value will be stored
   in the EAP server upon receipt of the Confirm TLV from the peer, and
   SHOULD be stored with its identifier and associated with the EAP
   server and the current user in the peer upon receipt of the EAP-
   Success message.  If the peer already had a pepper stored for the EAP
   server, it SHALL replace it with the newly received one.

4.11.7.  Vendor-Specific TLV

   The Vendor-Specific TLV is available to allow vendors to support
   their own extended attributes not suitable for general usage.  A
   Vendor-Specific TLV can contain one or more inner TLVs, referred to
   as Vendor TLVs.  The TLV-type of a Vendor TLV will be defined by the
   vendor.  All the Vendor TLVs inside a single Vendor-Specific TLV
   SHALL belong to the same vendor.

   This TLV type MAY be sent by EAP servers, as well as by peers, and
   MUST be supported by all entities conforming to this specification.
   Conforming implementations may not support specific Vendor TLVs
   inside a Vendor-Specific TLV, however.  They MAY, in this case,
   respond to the Vendor TLVs with a NAK TLV containing the appropriate
   Vendor-ID and Vendor TLV type.

   The presence of a Vendor-Specific TLV in an EAP-Request or EAP-
   Response of type POTP-X MUST NOT violate any existing rules for
   coexistence of TLVs in such requests or responses.  If it does, then
   it will result in an EAP-Failure (when the peer made the violation)
   or an empty EAP-POTP response (when the EAP-server made the
   violation).  It is left to the definition of specific Vendor-Specific
   TLVs to further constrain when they are allowed to appear.  In

Top      Up      ToC       Page 42 
   particular, EAP-POTP implementations may have policies that
   completely disallow use of the Vendor-Specific TLV before protected
   mode mutual authentication has occurred (since the Protected TLV,
   Section 4.11.15, then can be used to protect all TLVs).

   Note: This TLV type has the same definition and TLV type number as
   the Vendor-Specific TLV in [17], and the description of it is largely
   borrowed from that document.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Vendor-Id                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Vendor TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      7

   Length

      4 + cumulative total length of inner Vendor TLVs

   Vendor-ID

      The Vendor-Id field is 4 octets.  The high-order octet SHALL be
      set to 0, and the low-order 3 octets SHALL be set to the SMI
      Network Management Private Enterprise Code (see [18]) of the
      Vendor in network byte order.

Top      Up      ToC       Page 43 
   Vendor TLVs

      This field shall contain vendor-specific TLVs, in a format defined
      by the vendor.  To avoid fragmentation (i.e., EAP messages longer
      than the minimum EAP MTU size), the field SHOULD NOT be longer
      than 256 octets.

   To ensure interoperability when an EAP entity (peer or server) from
   vendor A sends a vendor-specific TLV that is not understood by the
   recipient EAP entity from vendor B, the vendor A entity SHALL, upon
   receipt of the NAK TLV from the recipient, refrain from usage of the
   vendor-specific TLV in question for the rest of the handshake, and
   MUST NOT fail the session due to the receipt of the NAK TLV for the
   Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had
   not been sent).  Additionally, all implementations conformant with
   this document SHOULD allow use of vendor-specific extensions to be
   turned off via configuration.

4.11.8.  Resume TLV

   The Resume TLV MAY be sent by a peer to an authentication server to
   attempt session resumption.

   This TLV type MUST only be sent in response to an EAP-Request of type
   POTP-X containing a Server-Info TLV allowing session resumption.  The
   Resume TLV MUST be supported by all EAP servers that send a Server-
   Info TLV allowing session resumption.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |               Session Identifier              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Session Identifier (continued)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sess.Id (cont.)|             Authentication Data               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Authentication Data (cont.) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 - Non-mandatory TLV

Top      Up      ToC       Page 44 
   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      8

   Length

      45

   Reserved

      Reserved for future use.  This octet SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this octet for this version
      of EAP-POTP.

   Session Identifier

      An 8-octet identifier for the session the peer is trying to
      resume.

   Authentication Data

      Upon receipt of the Server-Info TLV, and if the N bit is not set,
      the peer searches for any stored sessions associated with the
      server identified by the Server Name field.  If a stored session
      is found, the peer generates a random, 16-octet nonce, "c_nonce",
      and calculates:

      K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce |
      s_nonce, iteration_count, key_length)

      where

      "|" denotes concatenation,

      "base_key" is either the current SRK for the session (if the
      session was created in protected mode) or the OTP used when the
      session was created (if the session was created in basic mode),

      "c_nonce" is the generated 16-octet nonce,

      "s_nonce" is the server nonce from the Server-Info TLV,

Top      Up      ToC       Page 45 
      "iteration_count" is the iteration count as determined by local
      policy, and

      "key_length" is the combined length of the desired key material,
      in octets.  When the default algorithms are used, key_length is
      176.

      The iteration count need only be 1 (one) when resuming a session
      established in protected mode, but MUST be chosen to provide a
      suitable level of protection when resuming a session established
      in basic mode (see also Section 4.11.3).

      Note: Session resumption for basic mode MUST only be carried out
      in a server-authenticated and protected tunnel that also provides
      a cryptographic binding for inner EAP methods.

      The peer then calculates:

      mac = MAC(K_MAC, msg_hash(resume_req))

      where

      "MAC" is the negotiated MAC algorithm, and

      "msg_hash(resume_req) is the message hash algorithm defined in
      Section 4.9 applied on resume_req, the EAP server's EAP-Request of
      type POTP-X containing the Server-Info TLV that allowed session
      resumption.

      The peer then places the first 16 octets of the MAC value,
      followed by the c_nonce value, followed by the iteration count
      value (as a 4-byte unsigned integer in network byte order), in the
      Authentication Data field.  As an example, when c_nonce =
      0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the
      Authentication Data field will be populated with (in hex):

      < 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001

      The server authenticates the peer by performing the corresponding
      calculations.  If the authentication is successful, the server
      MUST send an EAP-Request of type POTP-X containing a Confirm TLV
      to the peer.  If the authentication fails, the server MUST either
      send an EAP-Request of type POTP-X containing an OTP TLV and a
      Server-Info TLV, where the Server-Info TLV indicates that session
      resumption is not possible, or send an EAP-Failure.

Top      Up      ToC       Page 46 
      When resuming in basic mode, all calculated keys SHALL be
      discarded after the MAC has been calculated and verified.  When
      resuming in protected mode, the new SRK will replace the stored
      SRK, and the new MSK and EMSK will be exported upon successful
      completion of the method.

4.11.9.  User Identifier TLV

   The User Identifier TLV carries an identifier, typically the
   username, for the holder of the OTP token used to generate the OTP.

   At least one of the User Identifier TLV and the Token Key Identifier
   TLV SHOULD be present in the session's first EAP-Response of type
   POTP-X that also carries an OTP TLV unless a suitable identity has
   been provided in a preceding EAP-Response of type Identity (1) or is
   determined by some other means (see [1], Section 2).  Use of the User
   Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED
   even when an EAP-Response of type Identity (1) has been sent.  If a
   peer sends both a User Identifier TLV and a Token Key Identifier TLV,
   then the EAP server SHALL interpret the Token Key Identifier TLV as
   specifying a particular token key for the given user.  The EAP server
   MUST respond with an EAP-Failure if it cannot find a token key for
   the provided user.

   This TLV type is sent by peers and MUST be supported by all EAP
   servers conforming to this specification.  The User Identifier TLV
   MUST NOT be present in a response that does not also carry an OTP
   TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       User Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

Top      Up      ToC       Page 47 
   TLV Type

      9

   Length

      Length of User Identifier, >= 1

   User Identifier

      The value SHALL be an UTF-8 encoded string representing the holder
      of the token (MUST NOT be NULL-terminated).  The string MUST be
      less than 128 octets in length.

4.11.10.  Token Key Identifier TLV

   The Token Key Identifier TLV carries an identifier for the token key
   used to generate the OTP.

   At least one of the User Identifier TLV and the Token Key Identifier
   TLV SHOULD be present in the session's first EAP-Response of type
   POTP-X, which also carries the OTP TLV unless a suitable identity has
   been provided in a preceding EAP-Response of type Identity (1) or is
   determined by some other means (see [1], Section 2).  Use of the User
   Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED
   even when an EAP-Response of type Identity (1) has been sent.  If a
   peer sends both a User Identifier TLV and a Token Key Identifier TLV,
   then the EAP server SHALL interpret the Token Key Identifier TLV as
   specifying a particular token key for the given user.  The EAP server
   MUST respond with an EAP-Failure if it cannot find a token key
   corresponding to the provided token key identifier.

   This TLV type is sent by peers and MUST be supported by all EAP
   servers conforming to this specification.  The Token Key Identifier
   TLV MUST NOT be present in a response that does not also carry an OTP
   TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Token Key Identifier ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

Top      Up      ToC       Page 48 
   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      10

   Length

      Length of Token Key Identifier, >= 1

   Token Key Identifier

      An identifier for the OTP token key used to generate the OTP.  The
      field MUST be less than 128 octets in length.

4.11.11.  Time Stamp TLV

   The Time Stamp TLV MAY be sent by peers to simplify authentications.
   When present, it carries the time as reported by the OTP Token.

   An EAP server conformant with this specification SHOULD support
   (i.e., recognize) this TLV, but need not be able to process or act on
   it.  An EAP server that does not support this TLV, but receives an
   EAP-Response with the TLV present, MAY ignore the value.  The Time
   Stamp TLV MUST NOT be present in any EAP-Responses of type POTP-X
   other than those that also carries an OTP TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Time Stamp ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 - Non-mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

Top      Up      ToC       Page 49 
   TLV Type

      11

   Length

      Length of Time Stamp field, >= 20 (depending on precision)

   Time Stamp

      The time, as reported by the OTP token, at which the OTP used for
      the accompanying OTP TLV was calculated.  The field SHALL contain
      a UTF-8 encoded value of the XML simple type "dateTime", with time
      zone information and precision down to at least seconds, e.g.,
      "2004-06-16T15:20:02Z".

4.11.12.  Counter TLV

   The Counter TLV MAY be sent by peers to simplify authentications.
   When present, it carries the token counter value, as reported by the
   OTP Token.

   An EAP server conformant with this specification SHOULD support
   (i.e., recognize) this TLV, but need not be able to process or act on
   it.  An EAP server that does not support this TLV, but receives an
   EAP-Response with the TLV present, MAY ignore the value.  The Counter
   TLV MUST NOT be present in any EAP-Responses of type POTP-X other
   than those that also carries an OTP TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Counter ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 - Non-mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

Top      Up      ToC       Page 50 
   TLV Type

      12

   Length

      Length of Counter field, >= 1 (depending on precision)

   Counter

      The counter value, as reported by the OTP token, at which the OTP
      used for the accompanying OTP TLV was calculated.  The counter
      value SHALL be represented as an unsigned integer in network-byte
      order, e.g., a counter value of 1030 may be sent as the 2 octets
      (in hex) 04 06.

4.11.13.  Challenge TLV

   The Challenge TLV carries the challenge used by the token to
   calculate the OTP, as reported by the token to the peer.  The
   Challenge TLV MUST be sent by a peer if and only if the challenge
   otherwise would be unknown to the EAP server (e.g., the token or peer
   modified a received challenge or generated its own challenge).

   An EAP server conformant with this specification SHOULD support
   (i.e., recognize) this TLV, but need not be able to process or act on
   it.  An EAP server that does not support this TLV, but receives an
   EAP-Response with the TLV present, MAY ignore the value.  The
   Challenge TLV MUST NOT be present in any EAP-Responses of type POTP-X
   other than those that also carry an OTP TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Challenge ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 - Non-mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

Top      Up      ToC       Page 51 
   TLV Type

      16

   Length

      Length of Challenge field, >= 1

   Challenge

      The challenge value that was used to calculate the OTP used for
      the accompanying OTP TLV.

4.11.14.  Keep-Alive TLV

   The Keep-Alive is used to avoid EAP-POTP timeouts.

   The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the
   peer has received an EAP-Request containing an OTP TLV or a New PIN
   TLV and is waiting for a response from the user.

   An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP
   server when the server receives an EAP-Response containing a Keep-
   Alive TLV, and the server has an outstanding request that did not
   contain a Keep-Alive TLV.  In this situation, the server does not
   need to re-transmit its latest outstanding request, but, due to the
   synchronous nature of EAP, it needs to send another request.  Re-
   transmission of the latest outstanding request could be confusing for
   the peer since the request would get a new Identifier value.  The
   Keep-Alive TLV MAY also be sent by an EAP server when the server
   detects that its processing time will exceed some locally configured
   threshold and may cause a network timeout.  In this case, the peer
   MUST respond with an EAP-Response containing a Keep-Alive TLV.

   This TLV type MUST be supported by all peers and all EAP servers
   conforming to this specification and MUST NOT be responded to with a
   NAK TLV.  The Keep-Alive TLV MUST NOT be sent in any other situations
   than the ones described above.  The Keep-Alive TLV MUST NOT be sent
   together with any other TLVs defined herein.  Implementations SHOULD
   also follow recommendations made in Section 4.3 of [1].

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Top      Up      ToC       Page 52 
   M

      1 - Mandatory TLV

   R

   Reserved for future use.  This bit SHALL be set to zero (0) for this
   version.  Recipients SHALL ignore this bit for this version of EAP-
   POTP.

   TLV Type

      13

   Length

      0

4.11.15.  Protected TLV

   The Protected TLV SHALL be used to encrypt individual or multiple
   TLVs after successful exchange of the Confirm TLV (i.e., as soon as
   calculated keys have been confirmed).  The Protected TLV therefore
   wraps "ordinary" TLVs.

   This TLV type may be sent by EAP servers as well as by peers and MUST
   be supported by all peers conforming to this specification.  It
   SHOULD be supported by all EAP servers conforming to this
   specification (it need not be supported if a server never will have a
   need to continue a POTP-X conversation after exchange of the Confirm
   TLV).

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Message Authentication Code ... (16 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             IV ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Encrypted TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

Top      Up      ToC       Page 53 
   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

   TLV Type

      14

   Length

      >32

   Message Authentication Code (MAC)

      This field integrity-protects the TLV.  The MAC SHALL be
      calculated over the IV and the Encrypted TLVs field in the
      following manner:

      mac = MAC(K_MAC, iv | encrypted_tlvs)

      where

      MAC is the negotiated MAC algorithm, "iv" is the IV field's value,
      and "encrypted_tlvs" is the value of the Encrypted TLVs field.
      The first 16 octets of the MAC is placed in the Message
      Authentication Code field.

      Recipients MUST verify the MAC.  If the verification fails, the
      conversation SHALL be terminated (i.e., peers send an empty POTP-X
      EAP-Response message, and EAP servers send an EAP-Failure message
      possibly preceded by an EAP-Request of type Notification).

   IV

      An initialization vector for the encryption; see below.  The
      length of the vector is dependent on the negotiated encryption
      algorithm, e.g., for AES-CBC, it shall be 16 octets.  For some
      encryption algorithms, there may not be any initialization vector.
      An IV, when present, shall be randomly chosen and non-predictable.

   Encrypted TLVs

      This field SHALL contain one or more encrypted POTP-X TLVs.  The
      encryption algorithm SHALL be as negotiated; use K_ENC as the
      encryption key, and use the IV field as the initialization vector

Top      Up      ToC       Page 54 
      (when applicable), to encrypt the concatenation of all the TLVs to
      be protected.

4.11.16.  Crypto Algorithm TLV

   The Crypto Algorithm TLV allows for negotiation of cryptographic
   algorithms.  Cryptographic Algorithm negotiation is described in
   detail in Section 4.3.

   This TLV MUST be present in the initial EAP-Request of type POTP-X
   that also carries an OTP TLV indicating protected mode, assuming the
   EAP server wants to negotiate use of any other algorithms than the
   default ones.  It MAY also be present in an EAP-Request of type
   POTP-X that carries an OTP TLV that is sent as a result of a failed
   session resumption (in this case, the peer has not yet responded to
   this TLV), or when the Crypto Algorithm TLV was part of the initial
   message from the EAP server, and the client negotiated another EAP-
   POTP version than the highest one supported by the EAP server.  The
   Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests.
   Further, the Crypto Algorithm TLV MUST NOT be present in an EAP-
   Response of type POTP-X unless the preceding EAP-Request also
   contained it, and it was legal for it to do so.  This TLV MUST be
   supported by all peers and all EAP servers conforming to this
   specification and MUST NOT be responded to with a NAK TLV.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R|          TLV Type         |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |Hash Alg.Length|        Hash Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Encr.Alg.Length|             Encryption Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |MAC Alg. Length|                  MAC Algorithms ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      1 - Mandatory TLV

   R

      Reserved for future use.  This bit SHALL be set to zero (0) for
      this version.  Recipients SHALL ignore this bit for this version
      of EAP-POTP.

Top      Up      ToC       Page 55 
   TLV Type

      15

   Length

      >=4 (at least one class of algorithms and one algorithm for that
      class needs to be present)

   Reserved

      Reserved for future use.  This octet MUST be set to zero for this
      version.  Recipients SHALL ignore this octet for this version of
      EAP-POTP.

   Hash Alg. Length

      The length of the Hash Algorithms field in octets.

   Hash Algorithms

      Each octet pair of this field represents a hash algorithm as
      follows.  An EAP server MAY supply several suggestions for hash
      algorithms.  Each algorithm MUST appear only once.  The algorithms
      SHALL be supplied in order of priority.  Peers MUST supply, at
      most, one algorithm (if none is present, the default applies).
      The defined values are:

        Value
   Octet 1 Octet 2  Hash algorithm
   ------- -------  ----------------------------------
   0x00    0x00     Reserved
   0x00    0x01     SHA-1
   0x00    0x02     SHA-224
   0x00    0x03     SHA-256 (default)
   0x00    0x04     SHA-384
   0x00    0x05     SHA-512
   0x80     -       Vendor-specific (or experimental)

      As indicated, values 0x8000 and higher are for proprietary
      vendor-specific algorithms.  Values in the range 0x0006 - 0x7fff
      are to be assigned through IANA; see Section 7.

   Encr Alg. Length

      The length of the Encryption Algorithms field in octets.

Top      Up      ToC       Page 56 
   Encryption Algorithms

      Each octet pair of this field represents an encryption algorithm
      as follows.  An EAP server MAY supply several suggestions for
      encryption algorithms.  Each algorithm MUST appear only once.  The
      algorithms SHALL be supplied in order of priority.  Peers MUST
      supply, at most, one algorithm (if none is present, the default
      applies).  The defined values are:

        Value
   Octet 1 Octet 2  Encryption algorithm
   ------- -------  ------------------------
   0x00    0x00     Reserved
   0x00    0x01     AES-CBC (default) with 128-bit keys and 16-octet IVs
   0x00    0x02     3DES-CBC with 112-bit keys and 8-octet IVs
   0x80     -       Vendor-specific

      As indicated, values 0x8000 and higher are for vendor-specific
      proprietary algorithms.  Values in the range 0x0003 - 0x7fff are
      to be assigned through IANA; see Section 7.

   MAC Alg. Length

      The length of the MAC Algorithms field in octets.

   MAC Algorithms

      Each octet pair of this field represents a MAC algorithm as
      follows.  An EAP server MAY supply several suggestions for MAC
      algorithms.  Each algorithm MUST appear only once.  The algorithms
      SHALL be supplied in order of priority.  Peers MUST supply, at
      most, one algorithm (if none is present, the default applies).
      The defined values are:

        Value
   Octet 1 Octet 2  MAC algorithm
   ------- -------  -----------------
   0x00    0x00     Reserved
   0x00    0x01     HMAC (default)
   0x80     -       Vendor-specific

      As indicated, values 0x8000 and higher are for vendor-specific
      proprietary algorithms.  Values in the range 0x0002 - 0x7fff are
      to be assigned through IANA; see Section 7.

      When HMAC is negotiated, the hash algorithm used for HMAC SHALL be
      the negotiated hash algorithm.


Next RFC Part