RFC 4793
The EAP Protected One-Time Password Protocol (EAP-POTP)
Pages: 82
Informational
Informational
Part 1 of 3 – Pages 1 to 20
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).
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
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
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
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
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.
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.
* 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.
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.
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
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
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.
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.
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
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
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.
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
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.
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.
Value
The value of the TLV.
(page 20 continued on part 2)