tech-invite   World Map     

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

RFC 4793

Informational
Pages: 82
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~sec-eap

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

Part 1 of 3, p. 1 to 20
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                        M. Nystroem
Request for Comments: 4793                                  RSA Security
Category: Informational                                    February 2007


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

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes a general Extensible Authentication Protocol
   (EAP) method suitable for use with One-Time Password (OTP) tokens,
   and offers particular advantages for tokens with direct electronic
   interfaces to their associated clients.  The method can be used to
   provide unilateral or mutual authentication, and key material, in
   protocols utilizing EAP, such as PPP, IEEE 802.1X, and Internet Key
   Exchange Protocol Version 2 (IKEv2).

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
      1.1. Scope ......................................................4
      1.2. Background .................................................4
      1.3. Rationale behind the Design ................................4
      1.4. Relationship with EAP Methods in RFC 3748 ..................5
   2. Conventions Used in This Document ...............................5
   3. Authentication Model ............................................5
   4. Description of the EAP-POTP Method ..............................6
      4.1. Overview ...................................................6
      4.2. Version Negotiation ........................................9
      4.3. Cryptographic Algorithm Negotiation .......................10
      4.4. Session Resumption ........................................11
      4.5. Key Derivation and Session Identifiers ....................13
      4.6. Error Handling and Result Indications .....................13
      4.7. Use of the EAP Notification Method ........................14
      4.8. Protection against Brute-Force Attacks ....................14
      4.9. MAC Calculations in EAP-POTP ..............................16
           4.9.1. Introduction .......................................16
           4.9.2. MAC Calculation ....................................16
           4.9.3. Message Hash Algorithm .............................16
           4.9.4. Design Rationale ...................................17
           4.9.5. Implementation Considerations ......................17
      4.10. EAP-POTP Packet Format ...................................17
      4.11. EAP-POTP TLV Objects .....................................20
           4.11.1. Version TLV .......................................20
           4.11.2. Server-Info TLV ...................................21
           4.11.3. OTP TLV ...........................................23
           4.11.4. NAK TLV ...........................................33
           4.11.5. New PIN TLV .......................................35
           4.11.6. Confirm TLV .......................................38
           4.11.7. Vendor-Specific TLV ...............................41
           4.11.8. Resume TLV ........................................43
           4.11.9. User Identifier TLV ...............................46
           4.11.10. Token Key Identifier TLV .........................47
           4.11.11. Time Stamp TLV ...................................48
           4.11.12. Counter TLV ......................................49
           4.11.13. Challenge TLV ....................................50
           4.11.14. Keep-Alive TLV ...................................51
           4.11.15. Protected TLV ....................................52
           4.11.16. Crypto Algorithm TLV .............................54
   5. EAP Key Management Framework Considerations ....................57
   6. Security Considerations ........................................57
      6.1. Security Claims ...........................................57
      6.2. Passive and Active Attacks ................................58
      6.3. Denial-of-Service Attacks .................................59
      6.4. The Use of Pepper .........................................59

Top      ToC       Page 3 
      6.5. The Race Attack ...........................................60
   7. IANA Considerations ............................................60
      7.1. General ...................................................60
      7.2. Cryptographic Algorithm Identifier Octets .................61
   8. Intellectual Property Considerations ...........................61
   9. Acknowledgments ................................................61
   10. References ....................................................62
      10.1. Normative References .....................................62
      10.2. Informative References ...................................62
   Appendix A. Profile of EAP-POTP for RSA SecurID ...................64
   Appendix B. Examples of EAP-POTP Exchanges ........................65
      B.1. Basic Mode, Unilateral Authentication .....................65
      B.2. Basic Mode, Session Resumption ............................66
      B.3. Mutual Authentication without Session Resumption ..........67
      B.4. Mutual Authentication with Transfer of Pepper .............69
      B.5. Failed Mutual Authentication ..............................70
      B.6. Session Resumption ........................................71
      B.7. Failed Session Resumption .................................73
      B.8. Mutual Authentication, and New PIN Requested ..............75
      B.9. Use of Next OTP Mode ......................................78
   Appendix C. Use of the MPPE-Send/Receive-Key RADIUS Attributes ....80
      C.1. Introduction ..............................................80
      C.2. MPPE Key Attribute Population .............................80
   Appendix D. Key Strength Considerations ...........................80
      D.1. Introduction ..............................................80
      D.2. Example 1: 6-Digit One-Time Passwords .....................81
      D.3. Example 2: 8-Digit One-Time Passwords .....................81

Top      ToC       Page 4 
1.  Introduction

1.1.  Scope

   This document describes an Extensible Authentication Protocol (EAP)
   [1] method suitable for use with One-Time Password (OTP) tokens, and
   offers particular advantages for tokens that are electronically
   connected to a user's computer, e.g., through a USB interface.  The
   method can be used to provide unilateral or mutual authentication,
   and key material, in protocols utilizing EAP, such as PPP [10], IEEE
   802.1X [11], and IKEv2 [12].

1.2.  Background

   A One-Time Password (OTP) token may be a handheld hardware device, a
   hardware device connected to a personal computer through an
   electronic interface such as USB, or a software module resident on a
   personal computer, which generates one-time passwords that may be
   used to authenticate a user towards some service.  This document
   describes an EAP method intended to meet the needs of organizations
   wishing to use OTP tokens in an interoperable manner to authenticate
   users over EAP.  The method is designed to be independent of
   particular OTP algorithms and to meet the requirements on modern EAP
   methods (see [13]).

   The basic variant of this method provides client authentication only.
   This mode is only to be used within a secured tunnel.  A more
   advanced variant provides mutual authentication, integrity protection
   of the exchange, protection against eavesdroppers, and establishment
   of authenticated keying material.  Both variants allow for fast
   session resumption.

   While this document also includes a profile of the general method for
   the RSA SecurID(TM) mechanism, it is described in terms of general
   constructions.  It is therefore intended that the document will also
   serve as a framework for use with other OTP algorithms.

   Note: The term "OTP" as used herein shall not be confused with the
   EAP OTP method defined in [1].

1.3.  Rationale behind the Design

   EAP-POTP has been designed with the intent that its messages and data
   elements be easily parsed by EAP implementations.  This makes it
   easier to programmatically use the EAP method in the peer and the
   authenticator, reducing the need for user interactions and allowing
   for local generation of user prompts, when needed.  In contrast, the
   Generic Token Card (GTC) method from [1], which uses text strings

Top      ToC       Page 5 
   generated by the EAP server, is intended to be interpreted and acted
   upon by humans.  Furthermore, EAP-POTP allows for mutual
   authentication and establishment of keying material, which GTC does
   not.  To retain the generic nature of GTC, the EAP-POTP method has
   been designed to support a wide range of OTP algorithms, with
   profiling expected for specific such algorithms.  This document
   provides a profile of EAP-POTP for RSA SecurID tokens.

1.4.  Relationship with EAP Methods in RFC 3748

   The EAP OTP method defined in [1], which builds on [14], is an
   example of a particular OTP algorithm and is not related to the EAP
   method defined in this document, other than that a profile of EAP-
   POTP may be created for the OTP algorithm from [14].

   The Generic Token Card EAP method defined in [1] is intended to work
   with a variety of OTP algorithms.  The same is true for EAP-POTP, the
   EAP method defined herein.  Advantages of profiling a particular OTP
   algorithm for use with EAP-POTP, compared to using EAP GTC, are
   described in Section 1.3.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", and "MAY", in this document are to be
   interpreted as described in RFC 2119 [2].

3.  Authentication Model

   The EAP-POTP method provides user authentication as defined below.
   Additionally, it may provide mutual authentication (authenticating
   the EAP server to the EAP client) and establish keying material.

   There are basically three entities in the authentication method
   described here:

   o  A client, or "peer", using EAP terminology, acting on behalf of a
      user possessing an OTP token;

   o  A server, or "authenticator", using EAP terminology, to which the
      user needs to authenticate; and

   o  A backend authentication server, providing an authentication
      service to the authenticator.

   The term "EAP server" is used here with the same meaning as in [1].
   Any protocol used between the authenticator and the backend
   authentication server is outside the scope of this document, although

Top      ToC       Page 6 
   RADIUS [15] is a typical choice.  It is assumed that the EAP client
   and the peer are located on the same host, and hence only the term
   "peer" is used in the following for these entities.

   The EAP-POTP method assumes the use of a shared secret key, or
   "seed", which is known both by the user and the backend
   authentication server.  The secret seed is stored on an OTP token
   that the user possesses, as well as on the authentication server.

   In its most basic variant, the EAP-POTP method provides only one
   Service (namely, user authentication) where the user provides
   information to the authentication server so that the server can
   authenticate the user.  A more advanced variant provides mutual
   authentication, protection against eavesdropping, and establishment
   of authenticated keying material.

4.  Description of the EAP-POTP Method

4.1.  Overview

   Note: Since the EAP-POTP method is general in nature, the term
   "POTP-X" is used below as a placeholder for an EAP method type
   identifier, identifying the use of a particular OTP algorithm with
   EAP-POTP.  As an example, in the case of using RSA SecurID tokens
   within EAP-POTP, the EAP method type shall be 32 (see Appendix A).

   A typical EAP-POTP authentication is performed as follows (Appendix B
   provides more detailed examples):

   a.  The optional EAP Identity Request/Response is exchanged, as per
       RFC 3748 [1].  An identity provided here may alleviate the need
       for a "User Identifier" or a "Token Key Identifier" triplet
       (TLV), defined below, later in the exchange.

   b.  The EAP server sends an EAP-Request of type POTP-X with a Version
       TLV.  The Version TLV indicates the highest and lowest version of
       this method supported by the server.  The EAP server typically
       also includes an OTP TLV in the EAP-Request.  The OTP TLV
       instructs the peer to respond with the current OTP (possibly in
       protected form), and may contain a challenge and some other
       information, like server policies.  The EAP server should also
       include a Server-Info TLV in the request, and must do so if it
       supports session resumption.  The Server-Info TLV identifies the
       authentication server, contains an identifier for this (new)
       session, and may be used by the peer to find an already existing
       session with the EAP server.

Top      ToC       Page 7 
   c.  The peer responds with an EAP-Response of type Nak (3) if it does
       not support POTP-X or if it does not support a version of this
       method that is also supported by the server, as indicated in the
       server's Version TLV.

       If the peer supports a version of this method that is also
       supported by the EAP server, the peer generates an EAP-Response
       of type POTP-X as follows:

       *  First, it generates a Version TLV, which indicates the peer's
          highest supported version within the range of versions offered
          by the server.  This Version TLV will be part of the EAP-
          Response to the EAP server.

       *  Next, if the peer's highest supported version equals that of
          the EAP server, and the EAP server sent a Server-Info TLV, the
          peer checks if it has a saved session with the EAP server.  If
          an existing session with the server is found, and session
          resumption is possible (the Server-Info TLV may explicitly
          disallow it), the peer calculates new session keys (if the
          session is a protected-mode session) and responds with a
          Resume TLV and the Version TLV.

       *  Otherwise, if the peer's highest supported version equals that
          of the EAP server, and the received EAP-Request message
          contains an OTP TLV, the peer requests (possibly through user
          interaction) the OTP token to calculate a one-time password
          based on the information in the received EAP-Request message
          (which could, for example, carry a challenge), the current
          token state (e.g., token time), a shared secret (the "seed"),
          and a user-provided PIN (note that, depending on the OTP token
          type, some of the information in the EAP-Request may not be
          used in the OTP calculation, and the PIN may be optional too).
          If the received OTP TLV has the P bit set (see below), the
          peer then combines the token-provided OTP with other
          information, and provides the combined data to a key
          derivation function.  The key derivation function generates
          several keys, of which one is used to calculate a Message
          Authentication Code (MAC) on the received message, together
          with some other information.  The resulting MAC, together with
          some additional information, is then placed in an OTP TLV
          (with the P bit set) that is sent in a response to the EAP
          server, together with the Version TLV.  If the P bit is not
          set in the received OTP TLV, the peer instead inserts the
          calculated OTP value directly in an OTP TLV, which then is
          sent to the EAP server together with the Version TLV.

Top      ToC       Page 8 
       *  Finally, if the peer's highest supported version differs from
          the server's, or if the server did not provide any TLVs
          besides the Version TLV in its initial request, the peer just
          sends back the generated Version TLV as an EAP-Response to the
          EAP server.

   d.  If the EAP server receives an EAP-Response of type Nak (3), the
       session negotiation failed and the EAP server may try with
       another EAP method.  Otherwise, the EAP server checks the peer's
       supported version.  If the peer did not support the highest
       version supported by the server, the server will send a new EAP-
       Request with TLVs adjusted for that version.  Otherwise, assuming
       the EAP server did send additional TLVs in its initial EAP-
       Request, the EAP server will attempt to authenticate the peer
       based on the response provided in c).  Depending on the result of
       this authentication, the EAP server may do one of the following:

       *  send a new EAP-Request of type POTP-X to the peer indicating
          that session resumption was not possible, and ask for a new
          OTP (this would be the case when the peer responded with a
          Resume TLV, and the session indicated in the Resume TLV was
          not valid),

       *  send a new EAP-Request of type POTP-X to the peer (e.g., to
          ask for the next OTP),

       *  accept the authentication (and send an EAP-Request message
          containing a Confirm TLV to the peer if the received response
          has the P bit set or was a successful attempt at a protected-
          mode session resumption; otherwise, send an EAP-Success
          message to the peer), or

       *  fail the authentication (and send an EAP-Failure message --
          possibly preceded by an EAP-Request message of type
          Notification (2) -- to the peer).

   e.  If the peer receives an EAP-Success or an EAP-Failure message the
       protocol run is finished.  If the peer receives an EAP-Request of
       type Notification, it responds as specified by RFC 3748 [1].  If
       the peer receives an EAP-Request of type POTP-X with a Confirm
       TLV, it attempts to authenticate the EAP server using the
       provided data.  If the authentication is successful, the peer
       responds with an EAP-Response of type POTP-X with a Confirm TLV.
       If it is unsuccessful, the peer responds with an empty EAP-
       Response of type POTP-X.  If the peer receives an EAP-Request of
       type POTP-X containing some other TLVs, it continues as specified
       in c) above (though no version negotiation will take place in
       this case) or as described for those TLVs.

Top      ToC       Page 9 
   f.  When an EAP server, which has sent an EAP-Request of type POTP-X
       with a Confirm TLV, receives an EAP-Response of type POTP-X with
       a Confirm TLV present, it can proceed in one of two ways: If it
       has detected that there is a need to send additional EAP-Requests
       of type POTP-X, it shall enter a "protected state", where, from
       then on, all POTP-X TLVs must be encrypted and integrity-
       protected before being sent (at this point, the parties shall
       have calculated a master session key as described in Section
       4.5).  One reason to continue the POTP-X conversation after
       exchange of the Confirm TLV could be that the user needs to
       update her OTP PIN; hence, the EAP server needs to send a New PIN
       TLV.  At that point, the handshake is back at step c) above
       (except for the version negotiation and the protection of all
       TLVs).  If there is no need to send additional EAP-Request
       packets, the EAP server shall instead send an EAP-Success method
       to the peer to indicate successful protocol completion.  The EAP
       server may not continue the conversation unless it indicates its
       intent to do so in the Confirm TLV.

       An EAP server, which has sent an EAP-Request of type POTP-X with
       a Confirm TLV and receives an EAP-Response of type POTP-X, which
       is empty (i.e., does not contain any TLVs), shall respond with an
       EAP-Failure and terminate the handshake.

   As implied by the description, steps c) through f) may be carried out
   a number of times before completion of the exchange.  One example of
   this is when the authentication server initially requests an OTP,
   accepts the response from the peer, performs an (intermediary)
   Confirm TLV exchange, requests the peer to select a new PIN, and
   finally asks the peer to authenticate with an OTP based on the new
   PIN (which again will be followed with a final Confirm TLV exchange).

4.2.  Version Negotiation

   The EAP-POTP method provides a version negotiation mechanism that
   enables implementations to be backward compatible with previous
   versions of the protocol.  This specification documents the EAP-POTP
   protocol version 1.  Version negotiation proceeds as follows:

   a.  In the first EAP-Request of type POTP-X, the EAP server MUST send
       a Version TLV in which it sets the "Highest" field to its highest
       supported version number, and the "Lowest" field to its lowest
       supported version number.  The EAP server MAY include other TLV
       triplets, as described below, that are compatible with the
       "Highest" supported version number to optimize the number of
       round-trips in the case of a peer supporting the server's
       "Highest" version number.

Top      ToC       Page 10 
   b.  If the peer supports a version of the protocol that falls within
       the range of versions indicated by the EAP server, it MUST
       respond with an EAP-Response of type POTP-X that contains a
       Version TLV with the "Highest" field set to the highest version
       supported by the peer.  The peer MUST also respond to any TLV
       triplets included in the EAP-Request, if it supported the
       "Highest" supported version indicated in the server's Version
       TLV.

       The EAP peer MUST respond with an EAP-Response of type Nak (3) if
       it does not support a version that falls within the range of
       versions indicated by the EAP server.  This will allow the EAP
       server to use another EAP method for peer authentication.

   c.  When the EAP server receives an EAP-Response containing a Version
       TLV from the peer, but the "Highest" supported version field in
       the TLV differs from the "Highest" supported version field sent
       by the EAP server, or when the version is the same as the one
       originally proposed by the EAP server, but the EAP server did not
       include any TLV triplets in the initial request, the EAP server
       sends a new EAP-Request of type POTP-X with the negotiated
       version and TLV triplets as desired and described herein.

   The version negotiation procedure guarantees that the EAP peer and
   server will agree to the highest version supported by both parties.
   If version negotiation fails, use of EAP-POTP will not be possible,
   and another mutually acceptable EAP method will need to be negotiated
   if authentication is to proceed.

   The EAP-POTP version field may be modified in transit by an attacker.
   It is therefore important that EAP entities only accept EAP-POTP
   versions according to an explicit policy.

4.3.  Cryptographic Algorithm Negotiation

   Cryptographic algorithms are negotiated through the use of the Crypto
   Algorithm TLV.  EAP-POTP provides a default digest algorithm
   (SHA-256) [3], a default encryption algorithm (AES-CBC) [4] , and a
   default MAC algorithm (HMAC) [5], and these algorithms MUST be
   supported by all EAP-POTP implementations.  An EAP server that does
   not want to make use of any other algorithms than the default ones
   need not send a Crypto Algorithm TLV.  An EAP server that does want
   to negotiate use of some other algorithms MUST send the Crypto
   Algorithm TLV in the initial EAP-Request of type POTP-X that also
   contains an OTP TLV with the P bit set.  The TLV MUST NOT be present
   in any other EAP-Request in the session. (The two exceptions to this
   are 1) if the client attempted a session resumption that failed and
   therefore did not evaluate a sent Crypto Algorithm TLV, or 2) if the

Top      ToC       Page 11 
   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.  When either of these cases
   apply, the server MUST include the Crypto Algorithm TLV in the first
   EAP-Request that also contains an OTP TLV with the P bit set
   subsequent to the failed session resumption / protocol version
   negotiation.)  In the Crypto Algorithm TLV, the EAP server suggests
   some combination of digest, encryption, and MAC algorithms. (If the
   server only wants to negotiate a particular class of algorithms, then
   suggestions for the other classes need not be present, since the
   default applies.)

   The peer MUST include a Crypto Algorithm TLV in an EAP-Response if
   and only if an EAP-Request of type POTP-X has been received
   containing a Crypto Algorithm TLV, it was legal for that EAP-Request
   to contain a Crypto Algorithm TLV, the peer does not try to resume an
   existing session, and the peer and the EAP server agree on at least
   one algorithm not being the default one.  If the peer does not supply
   a value for a particular class of algorithms in a responding Crypto
   Algorithm TLV, then the default algorithm applies for that class.
   When resuming an existing session (see the next section), there is no
   need for the peer to negotiate since the session already is
   associated with a set of algorithms.  Servers MUST fail a session
   (i.e., send an EAP-Failure) if they receive an EAP-Response TLV
   containing both a Resume TLV and a Crypto Algorithm TLV.

   Clearly, EAP servers and peers MUST NOT suggest any other algorithms
   than the ones their policy allows them to use.  Policies may also
   restrict what combinations of cryptographic algorithms are
   acceptable.

4.4.  Session Resumption

   This method makes use of session identifiers and server identifiers
   to allow for improved efficiency in the case where a peer repeatedly
   attempts to authenticate to an EAP server within a short period of
   time.  This capability is particularly useful for support of wireless
   roaming.

   In order to help the peer find a session associated with the EAP
   server, an EAP server that supports session resumption MUST send a
   Server-Info TLV containing a server identifier in its initial EAP-
   Request of type POTP-X that also contains an OTP TLV.  The identifier
   may then be used by the peer for lookup purposes.

   It is left to the peer whether or not to attempt to continue a
   previous session, thus shortening the negotiation.  Typically, the
   peer's decision will be made based on the time elapsed since the

Top      ToC       Page 12 
   previous authentication attempt to that EAP server.  If the peer
   decides to attempt to resume a session with the EAP server, it sends
   a Resume TLV identifying the chosen session and other contents, as
   described below, to the EAP server.

   Based on the session identifier chosen by the peer, and the time
   elapsed since the previous authentication, the EAP server will decide
   whether to allow the session resumption, or continue with a new
   session.

   o  If the EAP server is willing to resume a previously established
      session, it MUST authenticate the peer based on the contents of
      the Resume TLV.  If the authentication succeeds, the handshake
      will continue in one of two ways:

      *  If the session is a protected-mode session, then the server
         MUST respond with a request containing a Confirm TLV.  If the
         Confirm TLV authenticates the EAP server, then the peer
         responds with an empty Confirm TLV, to which the EAP server
         responds with an EAP-Success message.  If the Confirm TLV does
         not authenticate the EAP server, the peer responds with an
         empty EAP-Response of type POTP-X.

      *  If the session is not a protected-mode session, i.e., it is a
         session created from a basic-mode peer authentication, then the
         server MUST respond with an EAP-Success message.

      If the authentication of the peer fails, the EAP server SHOULD
      send another EAP-Request containing an OTP TLV and a Server-Info
      TLV with the N bit set to indicate that no session resumption is
      possible.  The EAP server MAY also send an EAP-Failure message,
      possibly preceded by an EAP-Request of type Notification (2), in
      which case, the EAP run will terminate.

   o  If the EAP server is not willing or able to resume a previously
      established session, it will respond with another EAP-Request
      containing an OTP TLV and a Server-Info TLV with the N bit set
      (indicating no session resumption).

   Sessions SHOULD NOT be maintained longer than the security of the
   exchange which created the session permits.  For example, if it is
   estimated that an attacker could be successful in brute-force
   searching for the OTP in 24 hours, then EAP-POTP session lifetimes
   should be clearly less than this value.

Top      ToC       Page 13 
4.5.  Key Derivation and Session Identifiers

   The EAP-POTP method described herein makes use of a key derivation
   function denoted "PBKDF2".  PBKDF2 is described in [6], Section 5.2.
   The PBKDF2 PRF SHALL be set to the negotiated MAC algorithm.  The
   default MAC algorithm, which MUST be supported, is HMAC-SHA256.  HMAC
   is defined in [5], and SHA-256 is defined in [3].  HMAC-SHA256 is the
   HMAC construct from [5] with SHA-256 as the hash function H.  The
   output length of HMAC-SHA256, when used as a PRF for PBKDF2, shall be
   32 octets (i.e., the full output length).

   The output from PBKDF2 as described here will consist of five keys
   (see Section 4.11.3 for details on how to calculate these keys):

   o  K_MAC, a MAC key used for mutual authentication and integrity
      protection,

   o  K_ENC, an encryption key used to protect certain data during the
      authentication,

   o  SRK, a session resumption key only used for session resumption
      purposes,

   o  MSK, a Master Session Key, as defined in [1], and

   o  EMSK, an Extended Master Session Key, also as defined in [1].

      For the default algorithms, K_MAC, K_ENC, and SRK SHALL be 16
      octets.  For other cases, the key lengths will be as determined by
      the negotiated algorithms.  The MSK and the EMSK SHALL each be 64
      octets, in conformance with [1].  Therefore, in the case of
      default algorithms, the "dkLen" parameter from Section 5.2 of [6]
      SHALL be set to 176 (the combined length of K_MAC, K_ENC, SRK,
      MSK, and EMSK).

   [1] and [16] define usage of the MSK and the EMSK .  For a particular
   use case, see also Appendix C.

4.6.  Error Handling and Result Indications

   EAP does not allow for the sending of an EAP-Response of type Nak (3)
   within a method after the initial EAP-Request and EAP-Response pair
   of that particular method has been exchanged (see [1], Section 2.1).
   Instead, when a peer is unable to continue an EAP-POTP session, the
   peer MAY respond to an outstanding EAP-Request by sending an empty
   EAP-Response of type POTP-X rather than immediately terminating the
   conversation.  This allows the EAP server to log the cause of the
   error.

Top      ToC       Page 14 
   To ensure that the EAP server receives the empty EAP-Response, the
   peer SHOULD wait for the EAP server to reply before terminating the
   conversation.  The EAP server MUST reply with an EAP-Failure.

   When EAP-POTP is run in protected mode, the exchange of the Confirm
   TLV (Section 4.11.6) serves as a success result indication; when the
   peer receives a Confirm TLV, it knows that the EAP server has
   successfully authenticated it.  Similarly, when the EAP server
   receives the Confirm TLV response from the peer, it knows that the
   peer has authenticated it.  In protected mode, the peer will not
   accept an EAP-Success packet unless it has received and validated a
   Confirm TLV.  The Confirm TLV sent from the EAP server to the peer is
   a "protected result indication" as defined in [1], as it is integrity
   protected and cannot be replayed.  The Confirm TLV sent from the peer
   to the EAP server is, however, not a protected result indication.  An
   empty EAP-POTP response sent from the peer to the EAP server serves
   as a failure result indication.

4.7.  Use of the EAP Notification Method

   Except where explicitly allowed in the following, the EAP
   Notification method MUST NOT be used within an EAP-POTP session.  The
   EAP Notification method MAY be used within an EAP-POTP session in the
   following situations:

   o  The EAP server MAY send an EAP-Request of type Notification (2)
      when it has received an EAP-Response containing an OTP TLV and is
      unable to authenticate the user.  In this case, once the EAP-
      Response of type Notification is received, the EAP server MAY
      retry the authentication and send a new EAP-Request containing an
      OTP TLV, or it MAY fail the session and send an EAP-Failure
      message.

   o  The EAP server MAY send an EAP-Request of type Notification (2)
      when it has received an unacceptable New PIN TLV.  In this case,
      once the EAP-Response of type Notification is received, the EAP
      server MAY retry the PIN update and send a new EAP-Request with a
      New PIN TLV, or it MAY fail the session and send an EAP-Failure
      message.

4.8.  Protection against Brute-Force Attacks

   Since OTPs may be relatively short, it is important to slow down an
   attacker sufficiently so that it is economically unattractive to
   brute-force search for an OTP, given an observed EAP-POTP handshake
   in protected mode.  One way to do this is to do a high number of
   iterated hashes in the PBKDF2 function.  Another is for the client to
   include a value ("pepper") unknown to the attacker in the hash

Top      ToC       Page 15 
   computation.  Whereas a traditional "salt" value normally is sent in
   the clear, this "pepper" value will not be sent in the clear, but may
   instead be transferred to the EAP server in encrypted form.  In
   practice, the procedure is as follows:

   a.  The EAP server indicates in its OTP TLV whether it supports
       pepper searching.  Additionally, it may indicate to the peer that
       a new pepper shall be chosen.

   b.  If the peer supports the use of pepper, the peer checks whether
       it already has established a shared pepper with this server:

       If it does have a pepper stored for this server, and the server
       did not indicate that a new pepper shall be generated, then it
       uses the existing pepper value, as specified in Section 4.11.3
       below, to calculate an OTP TLV response.  In this case, the
       iteration count shall be kept to a minimum, as the security of
       the scheme is provided through the pepper, and efficiency
       otherwise is lost.

       If the peer does not have a pepper stored for this server, but
       the server indicated support for pepper searching, or the server
       indicated that a new pepper shall be generated, then the peer
       generates a random and uniformly distributed pepper of sufficient
       length (the maximum length supported by the server is provided in
       the server's OTP TLV), and includes the new pepper in the PBKDF2
       computation.

       If the peer does not have a pepper stored for this server, and
       the server did not indicate support for pepper searching, then a
       pepper will not be used in the response computation.

       Clearly, if the peer itself does not support the use of pepper,
       then a pepper will not be used in the response computation.

   c.  The EAP server may, in its subsequent Confirm TLV, provide a
       pepper to the peer for later use.  In this case, the pepper will
       be substantially longer than a peer-chosen pepper, and encrypted
       with a key derived from the PBKDF2 computation.

   The above procedure allows for pepper updates to be initiated by
   either side, e.g., based on policy.  Since the pepper can be seen as
   a MAC key, its lifetime should be limited.

   An EAP server that is not capable of storing pepper values for each
   user it is authenticating may still support the use of pepper; the
   cost for this will be the extra computation time to do pepper
   searches.  This cost is still substantially lower than the cost for

Top      ToC       Page 16 
   an attacker, however, since the server already knows the underlying
   OTP.

4.9.  MAC Calculations in EAP-POTP

4.9.1.  Introduction

   In protected mode, EAP-POTP uses MACs for authentication purposes, as
   well as to ensure the integrity of protocol sessions.  This section
   defines how the MACs are calculated and the rationale for the design.

4.9.2.  MAC Calculation

   In protected mode, and when resuming a previous session, rather than
   sending authenticating credentials (such as one-time passwords or
   shared keys) directly, evidence of knowledge of the credentials is
   sent.  This evidence is a MAC on the hash of (certain parts of) EAP-
   POTP messages exchanged so far in a session using a key K_MAC:

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

   where

   "MAC" is the negotiated MAC algorithm, "K_MAC" is a key derived as
   specified in Section 4.5, and "msg_hash(msg_1, msg_2, ..., msg_n)" is
   the message hash defined below of messages msg_1, msg_2, ..., msg_n.

4.9.3.  Message Hash Algorithm

   To compute a message hash for the MAC, given a sequence of EAP
   messages msg_1, msg_2, ..., msg_n, the following operations shall be
   carried out:

   a.  Re-transmitted messages are removed from the sequence of
       messages.

       Note: The resulting sequence of messages must be an alternating
       sequence of EAP Request and EAP Response messages.

   b.  The contents (i.e., starting with the EAP "Type" field and
       excluding the EAP "Code", "Identifier", and "Length" fields) of
       each message, msg_1, msg_2, ..., msg_n, is concatenated together.

   c.  User identifier TLVs MUST NOT be included in the hash (this is to
       allow for a backend service that does not know about individual
       user names), i.e., any such TLV is removed from the message in
       which it appeared.

Top      ToC       Page 17 
   d.  The resulting string is hashed using the negotiated hash
       algorithm.

4.9.4.  Design Rationale

   The reason for excluding the "Identifier" field is that the actual,
   transmitted "Identifier" field is not always known to the EAP method
   layer.  The reason for excluding the "Length" field is to allow the
   possibility for an intermediary to remove or replace a Username TLV
   (e.g., for anonymity or service reasons) before passing a received
   response on to an authentication server.  While this on the surface
   may appear as bad security practice, it may in practice only result
   in denial of service, something which always may be achieved by an
   attacker able to modify messages in transit.  By excluding the "Code"
   field, the hash is simply calculated on applicable sent and received
   message contents.  Excluding the "Code" field is regarded as harmless
   since the hash is to be made on the sequence of POTP-X messages, all
   having alternating (known) Code values, namely 1 (Request) and 2
   (Response).

4.9.5.  Implementation Considerations

   To save on storage space, each EAP entity may partially hash messages
   as they are sent and received (e.g., HashInit(); HashUpdate(message
   1); ...; HashUpdate(message n-1); HashFinal(message n)).  This
   reduces the amount of state needed for this purpose to the internal
   state required for the negotiated hash algorithm.

4.10.  EAP-POTP Packet Format

   A summary of the EAP-POTP packet format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |   Identifier  |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |   Reserved    | TLV-based EAP-POTP message ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Code

      1 - Request

      2 - Response

Top      ToC       Page 18 
   Identifier

      The Identifier field is 1 octet and aids in matching responses
      with requests.  For a more detailed description of this field and
      how to use it, see [1].

   Length

      The Length field is 2 octets and indicates the length of the EAP
      packet including the Code, Identifier, Length, Type, Version,
      Flags, and TLV-based EAP-POTP message fields.

   Type

      Identifies use of a particular OTP algorithm with EAP-POTP.

   Reserved

      This octet is reserved for future use.  It SHALL be set to zero
      for this version.  Recipients SHALL ignore this octet for this
      version of EAP-POTP.

   TLV-based EAP-POTP message

   This field will contain 0, 1, or more Type-Length-Value triplets
   defined as follows (this is similar to the EAP-TLV TLVs defined in
   PEAPv2 [17], and the explanation of the generic fields is 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Value ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   M

      0 - Non-mandatory TLV

      1 - Mandatory TLV

      The TLVs within EAP POTP-X are used to carry parameters between
      the EAP peer and the EAP server.  An EAP peer may not necessarily
      implement all the TLVs supported by an EAP server, and to allow
      for interoperability, a special TLV allows an EAP server to
      discover if a TLV is supported by the EAP peer.

Top      ToC       Page 19 
      The mandatory bit in a TLV indicates that if the peer or server
      does not support the TLV, it MUST send a NAK TLV in response; all
      other TLVs in the message MUST be ignored.  If an EAP peer or
      server finds an unsupported TLV that is marked as non-mandatory
      (i.e., optional), it MUST NOT send a NAK TLV on this ground only.

      The mandatory bit does not imply that the peer or server is
      required to understand the contents of the TLV.  The appropriate
      response to a supported TLV with content that is not understood is
      defined by the specification of the particular 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 the EAP-POTP.

   TLV Type

      The following TLV types are defined for use with EAP-POTP:

       0 - Reserved for future use
       1 - Version
       2 - Server-Info
       3 - OTP
       4 - NAK
       5 - New PIN
       6 - Confirm
       7 - Vendor-Specific
       8 - Resume
       9 - User Identifier
      10 - Token Key Identifier
      11 - Time Stamp
      12 - Counter
      13 - Keep-Alive
      14 - Protected
      15 - Crypto Algorithm
      16 - Challenge

      These TLVs are defined in the following.  With the exception of
      the NAK TLV, a particular TLV type MUST NOT appear more than once
      in a message of type POTP-X.

   Length

      The length of the Value field in octets.

Top      ToC       Page 20 
   Value

      The value of the TLV.



(page 20 continued on part 2)

Next RFC Part