Network Working Group M. Nystr÷m
Internet-Draft RSA Security
Expires: August 18, 2005 February 14, 2005
The Protected One-Time Password Protocol (EAP-POTP)
draft-nystrom-eap-potp-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes a general EAP method suitable for use with
One-Time Password (OTP) tokens, in particular 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
IKEv2.
Nystr÷m Expires August 18, 2005 [Page 1]
Internet-Draft EAP-POTP February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Rationale behind the design . . . . . . . . . . . . . . . 4
2. Conventions used in this document . . . . . . . . . . . . . 6
3. Authentication model . . . . . . . . . . . . . . . . . . . . 7
4. Description of the EAP-POTP method . . . . . . . . . . . . . 8
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2 Version negotiation . . . . . . . . . . . . . . . . . . . 10
4.3 Session resumption . . . . . . . . . . . . . . . . . . . . 11
4.4 Key derivation . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Error handling . . . . . . . . . . . . . . . . . . . . . . 13
4.6 Slowing down attackers . . . . . . . . . . . . . . . . . . 13
4.7 EAP-POTP packet format . . . . . . . . . . . . . . . . . . 14
4.8 EAP-POTP TLV objects . . . . . . . . . . . . . . . . . . . 17
4.8.1 Version TLV . . . . . . . . . . . . . . . . . . . . . 17
4.8.2 Server-Info TLV . . . . . . . . . . . . . . . . . . . 18
4.8.3 OTP TLV . . . . . . . . . . . . . . . . . . . . . . . 20
4.8.4 NAK TLV . . . . . . . . . . . . . . . . . . . . . . . 28
4.8.5 New PIN TLV . . . . . . . . . . . . . . . . . . . . . 30
4.8.6 Confirm TLV . . . . . . . . . . . . . . . . . . . . . 32
4.8.7 Vendor-Specific TLV . . . . . . . . . . . . . . . . . 35
4.8.8 Resume TLV . . . . . . . . . . . . . . . . . . . . . . 37
4.8.9 User Identifier TLV . . . . . . . . . . . . . . . . . 38
4.8.10 Token Serial Number TLV . . . . . . . . . . . . . . 39
4.8.11 Time Stamp TLV . . . . . . . . . . . . . . . . . . . 40
4.8.12 Counter TLV . . . . . . . . . . . . . . . . . . . . 41
5. Profile of EAP-POTP for RSA SecurID . . . . . . . . . . . . 43
6. Security considerations . . . . . . . . . . . . . . . . . . 44
6.1 Security claims . . . . . . . . . . . . . . . . . . . . . 44
6.2 Passive and active attacks . . . . . . . . . . . . . . . . 44
6.3 Denial of service attacks . . . . . . . . . . . . . . . . 46
6.4 The use of pepper . . . . . . . . . . . . . . . . . . . . 46
6.5 The race attack . . . . . . . . . . . . . . . . . . . . . 46
7. IANA considerations . . . . . . . . . . . . . . . . . . . . 48
8. Intellectual property considerations . . . . . . . . . . . . 49
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 50
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
10.1 Normative references . . . . . . . . . . . . . . . . . . 51
10.2 Informative references . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . 52
A. Examples of EAP-POTP exchanges . . . . . . . . . . . . . . . 53
A.1 Basic mode, unilateral authentication . . . . . . . . . . 53
A.2 Mutual authentication without session resumption . . . . . 53
A.3 Mutual authentication with transfer of pepper . . . . . . 55
A.4 Failed mutual authentication . . . . . . . . . . . . . . . 56
Nystr÷m Expires August 18, 2005 [Page 2]
Internet-Draft EAP-POTP February 2005
A.5 Session resumption . . . . . . . . . . . . . . . . . . . . 58
A.6 Failed session resumption . . . . . . . . . . . . . . . . 59
A.7 Mutual authentication, and new PIN requested. . . . . . . 61
A.8 Use of next tokencode mode . . . . . . . . . . . . . . . . 63
B. Use of the MPPE-Send/Receive-Key RADIUS attributes . . . . . 65
B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 65
B.2 MPPE key attribute population . . . . . . . . . . . . . . 65
Intellectual Property and Copyright Statements . . . . . . . 66
Nystr÷m Expires August 18, 2005 [Page 3]
Internet-Draft EAP-POTP February 2005
1. Introduction
1.1 Scope
This document describes an EAP method suitable for use with One-Time
Password (OTP) tokens, in particular tokens 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 [9], IEEE 802.1X
[10] and IKEv2 [11].
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. Increasingly,
these tokens work in a connected fashion, enabling programmatic
retrieval of their OTP values. This document describes an EAP method
intended to meet the needs of organizations wishing to use these
connected OTP tokens in an interoperable and programmatic manner to
authenticate users over EAP. The method is designed to be
independent of particular OTP algorithms.
The basic variant of this method provides client authentication only.
A more advanced variant provides mutual authentication, integrity
protection of the exchange, protection against eavesdroppers, and
establishment of authenticated keying material. The advanced variant
also allows for fast session resumption.
While this document also includes a profile of the general method for
the RSA SecurID(R) mechanism, it is described in terms of general
constructions. It is therefore intended that the document will serve
as a framework for use also by other OTP algorithms.
Note 1: The RSA SecurID product is a hardware token card (or software
emulation thereof) produced by RSA Security Inc., which is used for
end-user authentication.
Note 2: The term "OTP" as used herein shall not be confused with the
EAP OTP method defined in [1].
1.3 Rationale behind the design
One advantage of defining a new, general, EAP method for OTP token
technology is that the protocol syntax becomes well defined. This
makes it easier to programmatically use the EAP method in the peer
Nystr÷m Expires August 18, 2005 [Page 4]
Internet-Draft EAP-POTP February 2005
and the authenticator. This is unlike, e.g., the Generic Token Card
(GTC) method, which uses text strings, intended to be interpreted and
acted upon by humans. The advantage of using a GTC profile for a
particular OTP technology would be that of reduced deployment costs,
assuming that existing EAP clients implement GTC because it is
required by the EAP specification. However, investigations (e.g.
[12]) have shown that EAP implementations in general do not support
GTC. Hence, the costs of introducing a new EAP method for a
particular technology and an profile of GTC for that technology are
roughly the same. Thus our decision was based on the technical
argument that a new general EAP method for OTP token technology makes
for a cleaner design and easier implementation. Furthermore, the
method presented herein 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 range of specific OTP algorithms, even though this document
also provides a profile of EAP-POTP for RSA SecurID tokens.
Nystr÷m Expires August 18, 2005 [Page 5]
Internet-Draft EAP-POTP February 2005
2. Conventions used in this document
The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "RECOMMENDED",
and "MAY", in this document are to be interpreted as described in RFC
2119 [2].
Nystr÷m Expires August 18, 2005 [Page 6]
Internet-Draft EAP-POTP February 2005
3. Authentication model
The EAP-POTP method provides two-factor based 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.
Even though the authenticator in practice may function as a client
with respect to the backend authentication server, relaying
authentication credentials et cetera as needed, both servers are,
unless explicitly mentioned, collectively denoted as "the EAP server"
here. When no backend authentication server is used, the
authenticator will be the EAP server. When the authenticator
operates in pass-through mode, the EAP server is located on the
backend authentication server. The protocol used between the
authenticator and the backend authentication server is outside the
scope of this document, although RADIUS [13] 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", and a personal identification number (PIN), which are 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. The term "two-factor authentication"
stems from the fact that a user needs not only physical access to the
token but also knowledge about the PIN in order to perform an
authentication.
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.
Nystr÷m Expires August 18, 2005 [Page 7]
Internet-Draft EAP-POTP February 2005
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. In the case of using RSA SecurID tokens within EAP-POTP,
the EAP method SHALL be 32.
A typical EAP-POTP authentication is performed as follows (Appendix A
provides more detailed examples):
a. The optional EAP Identity Request/Response is exchanged, as per
RFC 3748 [1]. An identity provided here alleviates the need for
a "User Identifier" or a "Token Serial Number" 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 protocol 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 may also
include a Server-Info TLV in the request, 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-Nak message if it does not support
a version of this protocol that is also supported by the server,
as indicated in the server's Version TLV.
If the peer supports a version of this protocol 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. 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 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
Nystr÷m Expires August 18, 2005 [Page 8]
Internet-Draft EAP-POTP February 2005
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). 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 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-Nak message 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, and 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 either
* 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 session
resumption, or otherwise send an EAP-Success message to the
peer), or
Nystr÷m Expires August 18, 2005 [Page 9]
Internet-Draft EAP-POTP February 2005
* 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 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 the user needs to update the OTP PIN, it will send
a New PIN TLV at which point the handshake is back at step c)
above (save for the version negotiation). Otherwise it will send
an EAP-Success method to the peer to indicate successful protocol
completion. At this point the parties shall have calculated a
master session key as described in Section 4.4.
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 which
is empty (i.e. does not contain any TLVs), then it shall respond
with an EAP-Failure and terminate the handshake.
As implied by the description, steps c) and d) 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, peforms 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).
Note: The RSA SecurID term for the OTP is "PASSCODE" when the OTP
includes a user PIN. Without a user PIN, the RSA SecurID term for
the OTP is "tokencode".
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 0. Version negotiation proceeds as follows:
Nystr÷m Expires August 18, 2005 [Page 10]
Internet-Draft EAP-POTP February 2005
a. In the first EAP-Request of type POTP-X, the EAP server MUST send
a Version TLV in which it sets the "Highest supported" version
field to its highest supported version number, and the "Lowest
supported" version field to its lowest supported version number.
The EAP server MAY include other TLV triplets as described below
and 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, and containing a
Version TLV with the "Highest supported" version 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.
c. The EAP peer MUST respond with an EAP-Nak if the EAP peer 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.
d. 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 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
Nystr÷m Expires August 18, 2005 [Page 11]
Internet-Draft EAP-POTP February 2005
server, the EAP server MAY send a Server-Info TLV containing a server
identifier in its initial EAP-Request of type POTP-X. The identifier
may then be used by the peer for lookup purposes.
It is left to the peer whether to attempt to continue a previous
session, thus shortening the negotiation, or not. 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 whether to choose a new
session.
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, and, if successful, respond only with a request
containing a Confirm TLV. If the Confirm TLV authenticates the
authentication 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 server, the peer
responds with an empty EAP-Response of type POTP-X.
If the authentication of the peer fails, the EAP server MAY 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.
Sessions MUST NOT be maintained longer than the security of the
exchange which created the session permits. E.g. if it is estimated
that an attacker will be successful in brute-force searching for the
OTP in 10 hours, then EAP-POTP session lifetimes must be less than
this value.
4.4 Key derivation
The EAP-POTP method described herein makes use of a key derivation
function denoted "PBKDF2-SHA256". PBKDF2 is described in [3],
Section 5.2. For use with this method, the PBKDF2 PRF SHALL be set
to HMAC-SHA256, hence the suffix "-SHA256". HMAC is defined in [4]
and SHA-256 is defined in [5]. HMAC-SHA256 is the HMAC construct
from [4] with SHA-256 as the hash function H.
The output from PBKDF2-SHA256 as described here will consist of four
keys:
Nystr÷m Expires August 18, 2005 [Page 12]
Internet-Draft EAP-POTP February 2005
o K_MAC, a MAC key used for mutual authentication,
o K_ENC, an encryption key used to protect certain data during the
authentication,
o MSK, a Master Session Key as defined in [1], and
o EMSK, an Extended Master Session Key, also as defined in [1].
K_MAC and K_ENC SHALL be 16 octets long, and MSK and EMSK SHALL each
be 64 octets long, in conformance with [1]. The "dkLen" parameter
from Section 5.2 of [3] shall therefore be set to 160 (the combined
length of K_MAC, K_ENC, MSK, and EMSK).
The MSK may be used as an ISK_i, for some i, as described in Section
2.5 of [14]. It may also be used as an AAA-Key (see [15]) when
setting up security associations between peers, or as a starting
point for derivation of MPPE [16] keys (see Appendix B).
As described in [1], EMSK is reserved for future use.
4.5 Error handling
EAP does not allow for the sending of an EAP-Nak message 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 cannot continue an EAP-POTP session either due
to the server not being able to authenticate itself or due to some
other reason (e.g. user aborting after a New PIN request), 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.
4.6 Slowing down attackers
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 a 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 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:
Nystr÷m Expires August 18, 2005 [Page 13]
Internet-Draft EAP-POTP February 2005
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.8.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.
c. If the peer does not support the use of pepper then a pepper will
not be used in the response computation.
d. 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 which 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.7 EAP-POTP packet format
A summary of the EAP-POTP packet format is shown below. The fields
are transmitted from left to right.
Nystr÷m Expires August 18, 2005 [Page 14]
Internet-Draft EAP-POTP February 2005
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 one 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 two 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. For
RSA SecurID, the type SHALL be 32.
Reserved
This octet is reserved for future use. It SHALL be set to zero
for this version of the protocol.
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
PEAP [14], 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 ...
Nystr÷m Expires August 18, 2005 [Page 15]
Internet-Draft EAP-POTP February 2005
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
1 - Mandatory TLV
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;
and all the other TLVs in the message MUST be ignored. If an
EAP peer or server finds an unsupported TLV which 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.
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 Serial Number
11 - Time Stamp
12 - Counter
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.
Nystr÷m Expires August 18, 2005 [Page 16]
Internet-Draft EAP-POTP February 2005
Length
The length of the Value field in octets.
Value
The value of the TLV.
4.8 EAP-POTP TLV objects
4.8.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. It MUST NOT be present in any subsequent
EAP-Request in the session. 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.
TLV Type
1
Length
3 in EAP-Requests, 2 in EAP-Responses
Reserved
Nystr÷m Expires August 18, 2005 [Page 17]
Internet-Draft EAP-POTP February 2005
Reserved for future use. This octet MUST be set to zero for this
version.
Highest
This field SHALL be interpreted as an unsigned integer in network
byte order 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 SHALL be interpreted as an unsigned integer in network
byte order 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-Nak message if the
peer's highest supported version is lower than the value of this
field.
This document defines version 0 of the protocol. EAP-Servers shall
therefore set the Highest as well as the Lowest field to 0. Peers
shall set the Highest field to 0.
4.8.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 MAY be present in the initial EAP-Request of type POTP-X
from the EAP server, which also carries an OTP TLV. It MUST NOT be
present if the server does not support session resumption. It MUST
NOT be present in any other EAP-Requests of type POTP-X or in any
EAP-Response packets. This TLV type MUST be supported by all peers
conforming to this specification.
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 Id. | Nonce ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Nystr÷m Expires August 18, 2005 [Page 18]
Internet-Draft EAP-POTP February 2005
| Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version.
TLV Type
2
Length
29
Reserved
Reserved for future use. All 7 bits MUST be set to zero for this
version of this protocol.
N
The N bit signals that the peer MUST NOT attempt to resume any
session it has stored associated with this server.
Session Identifier
A 4 octets long 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 octets long nonce chosen by the server. During session
resumption, this nonce is used to calculate new K_ENC, K_MAC, MSK,
and EMSK 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
Nystr÷m Expires August 18, 2005 [Page 19]
Internet-Draft EAP-POTP February 2005
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 encoded string of printable characters (without
any terminating NULL character).
4.8.3 OTP TLV
Presence of this TLV in a request indicates that the response SHALL
include a (possibly protected) OTP. The EAP server MAY provide a
challenge to the peer as described below. When present in a
response, this TLV carries a (possibly protected) OTP generated by
the user's OTP token.
This TLV type MUST be supported by all peers and EAP servers
conforming to this specification. The OTP TLV MUST NOT be present in
an EAP-Request of type POTP-X which contains a New PIN TLV. Further,
the OTP TLV MUST NOT be present in an EAP-Response of type POTP-X
which contains a Resume TLV. The OTP TLV also MUST NOT be present in
an EAP-Response of type POTP-X if the New PIN TLV was present in the
EAP-Request which triggered the response. The OTP TLV is defined as
follows:
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 |P|C|N|T|E|R| 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.
Nystr÷m Expires August 18, 2005 [Page 20]
Internet-Draft EAP-POTP February 2005
TLV Type
3
Length
7 + length of Authentication Data field
Reserved
Reserved for future use. All eleven bits SHALL be set to zero (0)
for this version.
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 a NAK-TLV.
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 which triggered the response contained an OTP TLV with
the P bit set.
In an 802.1x WLAN environment, the P bit MUST be set, or,
alternatively, the EAP-POTP method MUST be carried out inside an
authenticated tunnel such as those provided by [14] or [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 a NAK TLV in its response.
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
Nystr÷m Expires August 18, 2005 [Page 21]
Internet-Draft EAP-POTP February 2005
which triggered the response contained an OTP TLV with the C bit
set and a challenge. This applies even if the OTP token was not
capable of including a provided challenge in the OTP calculation.
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 RSA SecurID this means the next
time slot. For an event-based token, it could be an OTP
calculated based on the next counter value, if 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. 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 which triggered the
response contained an OTP TLV with the N bit set.
T
The following applies when the EAP method type is RSA SecurID
(32). Other OTP algorithms may define other usages of this bit.
In an EAP-Request, the T bit, when set, indicates that the OTP to
calculate MUST NOT include a user PIN. This bit will usually not
be set in initial EAP-Request messages, but may be set in
subsequent ones. This bit will normally be set together with the
N bit, to request the next RSA SecurID tokencode.
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 which triggered
the response contained an OTP TLV with the T bit set.
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
Nystr÷m Expires August 18, 2005 [Page 22]
Internet-Draft EAP-POTP February 2005
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.
In an EAP-Response, the E bit indicates that the response has been
calculated using a newly generated pepper.
R
In an EAP-Request, the R bit ("Repeat"), when set, indicates that
the peer SHOULD calculate its response based on the same OTP value
as used for the preceeding response. The use case for setting
this bit is when the EAP server has received an OTP TLV from the
peer protected with a pepper which the server no longer is in
possession of. 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.
In an EAP-Response, the R bit is never set.
Pepper Length
This octet SHALL be present if and only if the P bit is set. When
present, it SHALL be interpreted as an unsigned integer between
0..255 (inclusive) in network-byte order. 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 this
octet 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.
Iteration Count
These four octets SHALL be present if and only if the P bit is
set. When present, they SHALL be interpreted as a positive,
4-octets long, 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
Nystr÷m Expires August 18, 2005 [Page 23]
Internet-Draft EAP-POTP February 2005
parameters (subject to reason - active attackers could otherwise
mount simple DoS attacks against peers, e.g. by providing
unreasonably high values for the iteration count). Note that the
server-provided parameters only applies 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 EAP-Nak message.
Authentication Data
EAP-Request: In an EAP-Request, the Authentication Data, when
present, contains an optional "challenge".
The challenge is an optional octet string that SHOULD be uniquely
generated for each request it is present in (i.e. it is a
"nonce"), and SHOULD be 8 octets or longer when present. To avoid
fragmentation (i.e. EAP messages longer than the minimum EAP MTU
size), the challenge MUST NOT be longer than 256 octets (see [1]).
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 to accept a provided OTP value or not.
EAP-Response: The following applies to the Authentication Data field
in an EAP-Response:
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 = PBKDF2-SHA256(otp, salt | pepper |
auth_addr, iteration_count, key_length)
where
"|" denotes concatenation,
"otp" is the already computed and UTF-8 encoded OTP (without any
terminating NULL character),
"salt" is a nonce 16 octets long,
"pepper" is an optional nonce (at most 256 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,
Nystr÷m Expires August 18, 2005 [Page 24]
Internet-Draft EAP-POTP February 2005
"auth_addr" is an address identifier (at most 32 octets long) for
the authenticator (i.e. the network access server, not the
backend authentication server, if there is one) as seen by the
peer 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 client'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 at least 1000 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. For this version of this method, key_length SHALL be
160.
The "pepper" values are only included in PBKDF2 calculations and
are never sent in the clear 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 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 four,
the pepper value will be padded to the left with four '0' bits to
form an octet before being used in the PBKDF2 calculation.
When pepper is used, it is RECOMMENDED that the combined entropy
of "otp" and "pepper" is at least 128 bits, but note that the
iteration count in PBKDF2 also has an impact on the likelihood of
a successful brute-force OTP attack, as does the lifetime of the
OTP itself.
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.
A server may earlier have transferred a pepper value to the peer
in a Confirm TLV (see below). When this is the case, and the peer
still have 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
Nystr÷m Expires August 18, 2005 [Page 25]
Internet-Draft EAP-POTP February 2005
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_address component:
* For dial-up, "auth_addr" SHALL be the phone number called by
the peer. The phone number shall be specified in the form of a
URL conformant with RFC 2806 ([6]), e.g. "tel:+1234567890".
Processing of received phone numbers SHALL be conformant with
RFC 2806.
* For use with IEEE 802.1X, "auth_addr" SHALL be the MAC address
of the authenticator in binary format (6 octets long).
* For IP-based EAP, "auth_addr" SHALL be the IPv4 or IPv6 address
of the authenticator in binary format (4 respectively 16 octets
long). As an example, the IPv4 address "10.129.13.15" would be
represented as (in hex) 0A 81 0D 0F, whereas the IPv6 address
"0A0A:0B0B:0C0C:0D0D:0E0E:0F0F:1010:1111" would be represented
as (in hex) 0A 0A 0B 0B 0C 0C 0D 0D 0E 0E 0F 0F 10 10 11 11.
Note: Use of the authenticator's identifying address 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 the security considerations
section).
As an example, when otp = "12345678", salt =
0x54434534543445435465768789099880, pepper is not used, auth_addr
= "10.129.13.1", iteration_count = 2000, and key_length = 160, the
input to the PBKDF2-SHA256 calculation will be (first two
parameters in hex, line wrap for readability):
(3132333435363738, 54434534543445435465768789099880 | 0a810d01,
2000, 160)
K_MAC is the first 16 octets of the output from PBKDF2-SHA256,
K_ENC the next 16 octets, MSK the following 64 octets and EMSK the
final 64 octets. Using K_MAC, the peer calculates:
mac = HMAC-SHA256(K_MAC, msg_hash)
where
"msg_hash" is the SHA-256 hash of all previous EAP messages of
type POTP-X in this exchange as sent and received by the peer and
in chronological order (it will typically be the hash of just one
message, the EAP server's initial EAP-Request of type POTP-X
Nystr÷m Expires August 18, 2005 [Page 26]
Internet-Draft EAP-POTP February 2005
containing the OTP TLV which triggered this response).
Re-transmissions are not included in this set of messages. User
identifier TLVs MUST NOT be included in the hash (this is to allow
for a back-end service which does not know about individual user
names), i.e. any such TLV is removed from the message which it
appeared in before the message is hashed (the hash shall still be
made using the message's original EAP headers and length values -
this needs to be taken into account if an intermediate replaces
the user identifier with some other value).
Note: To save on storage space, each EAP entity may hash messages
as they are sent and received. This reduces the amount of state
needed for this purpose to the state required for SHA-256.
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_addr" value in
octets, followed by the actual "auth_addr" value in binary form,
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 four octets long.
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_addr in octets) + (4, for pepper
identifier, when present) octets long.
Continuing the previous example, the Authentication Data field
will be populated with (in hex, line wrap for readability):
< 16 octets of mac > | 54434534543445435465768789099880 | 04 |
0a810d01
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-SHA256 computation or the
keys K_MAC, K_ENC, 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 SHA-256 hash 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
Nystr÷m Expires August 18, 2005 [Page 27]
Internet-Draft EAP-POTP February 2005
K_MAC' | K_ENC' | MSK' | EMSK' = PBKDF2-SHA256(otp', salt |
pepper' | auth_addr, iteration_count, 160)
for each possible OTP value otp', and each possible pepper value
pepper' and the provided values for salt, authenticator address,
and iteration count. If the given pepper length is not a multiple
of eight, each tested pepper value will be padded to the left to
the nearest multiple of eight, in the same manner as was done by
the peer. If the server already shared 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, and the server
does not support pepper searching.
For each K_MAC', the EAP server computes
mac' = HMAC-SHA256(K_MAC', msg_hash')
where msg_hash' is the EAP server's SHA-256 hash of the same
messages as the peer calculated its message hash msg_hash on, 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 address is acceptable, then the peer is
authenticated. Note that the EAP server may accept more than one
OTP value at a given time, e.g. due to clock drift in the token.
See Section 4.4 for details on PBKDF2-SHA256 and HMAC-SHA256.
If the authentication was successful, the authentication server
then attempts to authenticate itself to the peer by use of the
Confirm TLV (see below).
When the P bit is not set, the peer SHALL directly place the UTF-8
encoded OTP in the Authentication Data field, without any
terminating NULL character. In this case, the EAP server MUST NOT
send a Confirm TLV upon successful authentication of the peer
(instead, it sends an EAP-Success message).
4.8.4 NAK TLV
Presence of this TLV indicates that the peer did not support or
accept 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 is sent by peers and MUST be supported by all EAP servers
Nystr÷m Expires August 18, 2005 [Page 28]
Internet-Draft EAP-POTP February 2005
conforming to this specification. Receipt of a NAK TLV would
normally cause an authentication to fail, and the EAP server to send
an EAP-Failure message to the peer.
Note: The definition of the NAK TLV herein matches the definition
made in [14], 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.
TLV Type
4
Length
>= 6
Vendor-Id
The Vendor-Id field is four 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 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
Nystr÷m Expires August 18, 2005 [Page 29]
Internet-Draft EAP-POTP February 2005
The type of the unsupported TLV. The TLV MUST have been included
in the most recently received EAP message.
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.8.5 New PIN TLV
Presence of this TLV in a request indicates that the response SHALL
include a new user PIN. The EAP server MAY provide a new PIN as
described below. When present in a response, the New PIN TLV carries
a suggested new user PIN. This TLV may be used by an EAP server when
policy dictates that the peer (user) needs to change the OTP PIN. It
MUST NOT be sent unless the peer has been authenticated. Further, if
the peer was authenticated through the use of an OTP TLV with the P
bit set, then any provided PIN from the EAP server, and the PIN sent
from the peer, MUST be encrypted with the derived K_ENC key. The New
PIN TLV MUST be sent by a peer if and only if the EAP-Request which
triggered the response contained a New PIN TLV, and it was valid for
the EAP server to send such a TLV, as described.
This TLV type MAY be supported by peers and EAP servers conforming to
this specification. Profiles will need to specify whether it is
mandatory or not.
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
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version.
Nystr÷m Expires August 18, 2005 [Page 30]
Internet-Draft EAP-POTP February 2005
TLV Type
5
Length
>=2 (the PIN may or may not be present.)
Reserved
Reserved for future use. All six bits SHALL be set to zero for
this version.
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 a NAK-TLV 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
The A bit, when set in an EAP-Request, indicates that the PIN is
alphanumeric, i.e. alphanumeric characters are allowed. The A
bit carries no meaning, and SHALL be set to zero, in an EAP
Response.
PIN Length
This field shall be interpreted as an unsigned integer in network
byte order representing the length of the provided PIN (this
implies that the maximum length of a PIN will be 255 octets).
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 [7] encoded printable
characters without a terminating NULL character. A provided PIN
MUST be encrypted whenever a K_ENC has been calculated in the
session, i.e. when the handshake executes in protected mode. The
Nystr÷m Expires August 18, 2005 [Page 31]
Internet-Draft EAP-POTP February 2005
encryption algorithm SHALL be AES [8] in CBC mode. A random, 16
byte IV SHALL in this case be used and SHALL constitute the first
16 octets of the PIN field.
In an EAP-Response, the PIN value SHALL consist of a (possibly
encrypted, see below) UTF-8 encoded string of printable
characters. It MUST NOT be NULL-terminated. The PIN value MUST
be encrypted whenever a K_ENC has been calculated in the session,
i.e. when the handshake executes in protected mode. As for the
PIN field in the request, the encryption algorithm SHALL be AES in
CBC mode with a random, 16 byte IV, and the IV SHALL in this case
constitute the first 16 octets of the PIN field. 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 whether the Q
bit was set or not in the request which triggered the response.
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 either a message indicating the failure of
the authentication using EAP-Notification or a repeated request
for a new PIN as described above if the EAP server for some reason
does not accept the received PIN. 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.
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. This
implies that the maximal length for a new PIN is 255 bytes.
4.8.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. The Confirm TLV MUST NOT appear together with
any other TLV in an EAP-Request message of type POTP-X and MUST NOT
Nystr÷m Expires August 18, 2005 [Page 32]
Internet-Draft EAP-POTP February 2005
be sent unless the peer has been authenticated through an OTP TLV
with the P bit set. Presence of this TLV in a response indicates
that the peer successfully authenticated the authentication server.
The Confirm TLV MUST be sent in an EAP-Response if and only if the
EAP server has been authenticated. If the peer was not able to
authenticate the server, then it MUST send an empty (i.e. no TLVs)
EAP-Response of type POTP-X.
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted Pepper ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version.
TLV Type
6
Length
17 or 37 in requests, 1 in responses.
Reserved
Reserved for future use. These seven bits SHALL be set to zero
(0) for this version.
Nystr÷m Expires August 18, 2005 [Page 33]
Internet-Draft EAP-POTP February 2005
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, and MUST NOT be set in
EAP-Responses.
Note: An EAP-Response containing a Confirm TLV will normally be
followed by an EAP-Success message from the EAP server concluding
the handshake. It MAY however be followed by another EAP-Request
from the EAP server, containing e.g. a New PIN TLV. Therefore,
peers MUST NOT assume that the only EAP messages following an
EAP-Response of type OTP-X containing a Confirm TLV are
EAP-Success and EAP-Failure. 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.8.3):
mac_a = HMAC-SHA256(K_MAC', msg_hash2)
where
"K_MAC'" has been calculated as described in Section 4.8.3
above, and
"msg_hash2" is the SHA-256 hash of the OTP TLV of the latest
EAP-Response of type POTP-X received from the peer (the one
which triggered this request), not including any User
Identifier TLV.
Given a saved or recomputed value for K_MAC, the peer
authenticates the EAP server by computing
mac'' = HMAC-SHA256(K_MAC, msg_hash2')
where msg_hash2' is the peer's SHA-256 hash of the same
EAP-Request as the authentication server calculated it's
message hash msg_hash2 on, but this time as it was sent by the
peer (and again excluding any User Identifier TLV). 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 authentication server is authenticated.
Nystr÷m Expires August 18, 2005 [Page 34]
Internet-Draft EAP-POTP February 2005
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, four octets
long, field identifies a pepper generated by the server.
This field SHALL NOT be present in EAP-Responses of this version.
Encrypted Pepper
When present in an EAP-Request, this will be a uniformly
distributed and randomly chosen sixteen octets long pepper
generated by the EAP server and encrypted with AES in CBC mode
using the peer's salt value as IV and K_ENC as the encryption key.
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-Responses of this version.
When a new pepper was 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.
4.8.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 the 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, and 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
Nystr÷m Expires August 18, 2005 [Page 35]
Internet-Draft EAP-POTP February 2005
co-existence 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.
Note: This TLV type has the same definition and TLV type number as
the Vendor-Specific TLV in [14], 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.
TLV Type
7
Length
>=4
Vendor-ID
The Vendor-Id field is four octets long. 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. The Vendor-Id 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.
Vendor TLVs
Nystr÷m Expires August 18, 2005 [Page 36]
Internet-Draft EAP-POTP February 2005
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.
4.8.8 Resume TLV
The Resume TLV MAY be sent by a peer to an authentication server to
attempt session resumption. This message MUST only be sent in
response to an initial EAP-Request of type OTP-X containing a
ServerInfo 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 | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version.
TLV Type
8
Length
41
Reserved
Reserved for future use. This octet SHALL be set to zero (0) for
this version.
Session Identifier
Nystr÷m Expires August 18, 2005 [Page 37]
Internet-Draft EAP-POTP February 2005
A 4 octets long 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 session is
found, the peer generates a random 16 octets long nonce,
"c_nonce", and calculates:
K_MAC | K_ENC | MSK | EMSK = PBKDF2-SHA256(MSK_cur, c_nonce |
s_nonce, iteration_count, 160)
with notation as for the OTP TLV above, c_nonce being the
generated 16 octet long nonce, s_nonce the server nonce from the
Server-Info TLV, iteration_count as determined by local policy but
MUST be at least 1000, and MSK_cur being the current MSK for the
session.
The peer then calculates:
MAC = HMAC-SHA256(K_MAC, msg_hash)
where
"msg_hash" is the SHA-256 hash of the EAP server's initial
EAP-Request of type POTP-X containing the ServerInfo TLV which
allowed session resumption.
The peer then places the first 16 octets of the MAC 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 = 2000, the
Authentication Data field will be populated with (in hex, line
wrap for readability):
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 000007d0
4.8.9 User Identifier TLV
The optional 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 Serial Number
TLVs MUST 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). Use
of the User Identifier TLV and/or the Token Serial Number TLV is
Nystr÷m Expires August 18, 2005 [Page 38]
Internet-Draft EAP-POTP February 2005
RECOMMENDED even when an EAP-Response of type Identity (1) has been
sent earlier. If a peer sends both a User Identifier TLV and a Token
Serial Number TLV then the EAP server shall interpret the Token
Serial Number TLV as specifying a particular token for the given
user. The EAP server MUST respond with an EAP-Failure if it cannot
find a token 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
MAY be present in any response.
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.
TLV Type
9
Length
>=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 long.
4.8.10 Token Serial Number TLV
The optional Token Serial Number TLV carries an identifier for the
token used to generate the OTP.
At least one of the User Identifier TLV and the Token Serial Number
Nystr÷m Expires August 18, 2005 [Page 39]
Internet-Draft EAP-POTP February 2005
TLVs MUST 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). Use
of the User Identifier TLV and/or the Token Serial Number TLV is
RECOMMENDED even when an EAP-Response of type Identity (1) has been
sent earlier. If a peer sends both a User Identifier TLV and a Token
Serial Number TLV then the EAP server shall interpret the Token
Serial Number TLV as specifying a particular token for the given
user. The EAP server MUST respond with an EAP-Failure if it cannot
find a token for the provided serial number.
This TLV type MUST be supported by all EAP servers conforming to this
specification. The Token Serial Number TLV is sent by peers and MAY
be present in any response.
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 Serial Number ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version.
TLV Type
10
Length
>=1
Token Serial Number
The token serial number encoded in UTF-8 and without any
terminating NULL character.
4.8.11 Time Stamp TLV
The optional Time Stamp TLV carries the current token time as
Nystr÷m Expires August 18, 2005 [Page 40]
Internet-Draft EAP-POTP February 2005
reported by the token to the peer. In particular, when present in an
EAP Response which also carries an OTP TLV, the Time Stamp TLV SHALL
reflect the time (again as reported by the token) at which the OTP
was calculated. The Time Stamp TLV MAY be used by EAP servers to
simplify synchronizations.
EAP servers 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 MAY be present in any response.
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.
TLV Type
11
Length
>= 20 (depending on precision)
Time Stamp
The time at which the response was generated in the form of 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.8.12 Counter TLV
The optional Counter TLV carries the current token counter, when
applicable, as reported by the token to the peer. In particular,
Nystr÷m Expires August 18, 2005 [Page 41]
Internet-Draft EAP-POTP February 2005
when present in an EAP Response which also carries an OTP TLV, the
Counter TLV SHALL reflect the counter value (again as reported by the
token) which was used at the OTP calculation. The Counter TLV MAY be
used by EAP servers to simplify synchronizations.
EAP servers 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 MAY be present in any response.
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.
TLV Type
12
Length
>= 20 (depending on precision)
Counter
The counter value which was current when the response was
generated in the form of a UTF-8 encoded string (without any
terminating NULL character).
Nystr÷m Expires August 18, 2005 [Page 42]
Internet-Draft EAP-POTP February 2005
5. Profile of EAP-POTP for RSA SecurID
Besides the following requirements, the requirements on peers and EAP
Servers implementing the SecurID profile of EAP-POTP SHALL conform to
all basic EAP-POTP normative requirements in this document:
o The EAP method type identifier SHALL be 32,
o the Counter TLV SHALL NOT be used,
o the Time Stamp TLV MUST be supported,
o the Resume TLV MUST be supported,
o the New PIN TLV MUST be supported, and
o the use of the N bit in the OTP TLV SHALL be as described in
Section 4.8.3 above.
Nystr÷m Expires August 18, 2005 [Page 43]
Internet-Draft EAP-POTP February 2005
6. Security considerations
6.1 Security claims
In conformance with RFC 3748 [1], the following security claims are
made for the EAP-POTP method:
Auth. mechanism: Generic OTP
Ciphersuite negotiation: No
Mutual authentication: Yes (No in basic variant)
Integrity protection: Yes (No in basic variant)
Replay protection: Yes (see below)
Confidentiality: Only of OTP and new PIN values in P mode
Key derivation: Yes (No in basic variant)
Key strength: Depends on size of OTP value, strength of
underlying shared secret, strength and
characteristics of OTP algorithm, pepper
length, iteration count, and whether the
method is used within a tunnel such as
PEAP.
Dictionary attack prot.: N/A
Fast reconnect: Yes (No in basic variant)
Crypt. binding: N/A
Session independence: Yes
Fragmentation: N/A
Channel binding: Yes (No in basic variant)
Acknowledged S/F: Yes
State Synchronization: Yes (No in basic variant)
6.2 Passive and active attacks
In its basic variant (i.e. when the protection of OTPs and mutual
authentication is not used), this EAP method only provides protection
against passive eavesdropping attacks. It does not provide session
privacy, session integrity, server authentication or protection from
active attacks. In particular, man-in-the-middle attacks, where an
attacker acts as an authenticator in order to acquire a valid OTP are
possible.
Similarly, the basic variant of this EAP method does not protect
against session hijacking taking place after authentication. Nor
does it in itself protect against replay attacks, where the attacker
gains access by replaying a previous, valid request, but see also the
next subsection. When PIN codes are transmitted, they are sent
without protection and are also subject to replay attacks.
In order to protect against these attacks, the peer MUST only use the
Nystr÷m Expires August 18, 2005 [Page 44]
Internet-Draft EAP-POTP February 2005
basic variant of this method over a server-authenticated and (when
PIN codes are exchanged) confidentiality-protected connection. This
can be achieved via use of, e.g., PEAP [14] or EAP-TTLS [17].
When the OTP protection variant is used however, the EAP method
provides privacy for OTPs and new PINs, mutual authentication, and
protection against replay attacks. It also provides protection
against man-in-the-middle attacks, not due to the infeasibility for a
man-in-the-middle to solve for a valid OTP given an OTP TLV, but due
to the computational expense of finding the OTP in the limited time
period during which it is valid (this is mainly true for tokens
including the current time in their OTP calculations). It should be
noted, however, that a retrieved OTP, even if "old" and invalid,
still may divulge some information about the user's PIN. Clearly
this is also true for the basic variant. Implementations of this EAP
method are therefore RECOMMENDED to ensure regular user PIN changes,
regardless of whether the protected variant or the basic variant is
employed. It should also be noted, that while it is possible for a
rogue access point e.g. to clone MAC addresses, and hence mount a
man-in-the-middle attack, such an access point will not be able to
calculate the session keys MSK and EMSK. This demonstrates the
importance of using the derived key material to protect a subsequent
session.
The OTP protection variant also protects against session hijacking,
if the derived session key is used (directly or indirectly) to
protect a subsequent session. For these reasons, use of the OTP
protection variant is RECOMMENDED.
It should be noted that not even the OTP protection variant provides
privacy for user names and/or token serial numbers however. If
privacy for these parameters are required, the EAP-POTP method must
be used within a secure tunnel such as those provided by PEAP or
TTLS.
Authentication server implementations MUST protect against replay
attacks, since an attacker could otherwise gain access by replaying a
previous, valid request.
For time based OTPs, one method to protect against replay attacks is
to have the authentication server make a note of the latest
authentication time used by the peer (whether sent explicitly by the
peer or inferred). A later attempt to authenticate at or before that
time will not be permitted. Likewise, if an unusual amount of clock
drift in the token is detected, the authentication server SHOULD ask
for a new OTP based on the next time interval for the token.
For challenge-response based OTPs, a server may use a similar
Nystr÷m Expires August 18, 2005 [Page 45]
Internet-Draft EAP-POTP February 2005
technique by encoding the current time in the issued challenge.
6.3 Denial of service attacks
An active attacker may replace the iteration count value in OTP TLVs
sent by the peer to slow down an authentication server.
Authentication servers SHOULD protect against this, e.g. by
disregarding OTP TLVs with an iteration count value higher than some
pre- or dynamically- (depending on load) set number.
6.4 The use of pepper
As described in Section 4.6, the use of pepper will slow down an
attacker's search for a matching OTP. The ability to transfer a
pepper value in encrypted form from the EAP server to the peer means
that, even though there may be an initial computational cost for the
EAP server to authenticate the peer, subsequent authentications will
be efficient, while at the same time more secure, since a pre-shared,
128 bits long, pepper value will not be easily found by an attacker.
An attacker observing an EAP-Request containing an OTP TLV calculated
using a pepper chosen by the peer may however, depending on available
resources, be able to successfully attack that particular EAP-POTP
session, since it most likely will be based on a relatively short
pepper value or only an iteration count. Once the correct OTP has
been found, eavesdropping on the EAP server's Confirm TLV will
potentially give the attacker access to the longer, server-provided
pepper for the remaining lifetime of that pepper value. For this
reason, initial exchanges with EAP servers SHOULD occur in a secure
environment (e.g. in a PEAP tunnel), and if not, the iteration count
MUST be significantly higher than for messages where a pre-shared
pepper is used. The lifetime of the shared pepper must also be
calculated with this in mind. Finally, the pepper value MUST be
securely stored by the peer and the EAP server, associated with the
user.
6.5 The race attack
In the case of fragmentation of EAP messages, it is possible (in the
basic variant of this method) for an attacker to listen to most of an
OTP, guess the remainder, and then race the legitimate user to
complete the authentication. Conforming backend authentication
server implementations MUST protect against this race condition. One
defense against this attack is outlined below and borrowed from [19];
implementations MAY use this approach or MAY select an alternative
defense. Note that the described defense relies on the user
providing the identity in response to an initial Identity
EAP-Request.
Nystr÷m Expires August 18, 2005 [Page 46]
Internet-Draft EAP-POTP February 2005
One possible defense is to prevent a user from starting multiple
simultaneous authentication sessions. This means that once the
legitimate user has initiated authentication, an attacker would be
blocked until the first authentication process has completed. In
this approach, a timeout is necessary to thwart a denial of service
attack.
Nystr÷m Expires August 18, 2005 [Page 47]
Internet-Draft EAP-POTP February 2005
7. IANA considerations
This document is a description of a general EAP method for OTP
tokens. It also defines EAP method 32 as a profile of the general
method. It has no actions for IANA.
Nystr÷m Expires August 18, 2005 [Page 48]
Internet-Draft EAP-POTP February 2005
8. Intellectual property considerations
RSA Security does not make any claims on the general constructions
described in this document. The RSA SecurID technology is covered by
a number of US patents (and foreign counterparts), in particular US
patent nos. 4,720,860, 4,856,062, 4,885,778, 5,097,505, 5,168,520,
and 5,657,388. Additional patents are pending.
RSA, RSA Security and SecurID are either registered trademarks or
trademarks of RSA Security Inc. in the United States and/or other
countries. The names of other products and services mentioned may be
the trademarks of their respective owners.
Nystr÷m Expires August 18, 2005 [Page 49]
Internet-Draft EAP-POTP February 2005
9. Acknowledgments
This document was improved by comments from, and discussion with, a
number of RSA Security employees. Simon Josefsson drafted the
initial versions of an RSA SecurID EAP method while working for RSA
Laboratories. The inspiration for the TLV-type of information
exchange comes from PEAPv2. Special thanks to Oliver Tavakoli of
Funk Software who has provided numerous useful comments and
suggestions.
Nystr÷m Expires August 18, 2005 [Page 50]
Internet-Draft EAP-POTP February 2005
10. References
10.1 Normative references
[1] Blunk, L., Vollbrecht, J., Aboba, B., Carlson, J. and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] RSA Laboratories, "Password-Based Cryptography Standard",
PKCS #5 v2.0, March 1999.
[4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5] National Institute of Standards and Technology, "Secure Hash
Standard", FIPS 180-2, February 2004.
[6] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
[8] National Institute of Standards and Technology, "Specification
for the Advanced Encryption Standard (AES)", FIPS 197, November
2001.
10.2 Informative references
[9] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)",
RFC 1661, July 1994.
[10] The Institute of Electrical and Electronics Engineers, Inc.,
"IEEE Standard for Local and metropolitan area networks --
Port-Based Network Access Control", IEEE 802.1X-2001, July
2001.
[11] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol",
Work in progress draft-ietf-ipsec-ikev2-17.txt, September 2004.
[12] Aboba, B., "Presentation to PPP Extensions WG at 52:th IETF
meeting in Salt Lake City", December 2001.
[13] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Dial In User Service (RADIUS)", RFC 2865, June 2000.
Nystr÷m Expires August 18, 2005 [Page 51]
Internet-Draft EAP-POTP February 2005
[14] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H. and S.
Josefsson, "Protected EAP Protocol (PEAP) Version 2", Work in
progress draft-josefsson-pppext-eap-tls-eap-10.txt, October
2004.
[15] Aboba, B., Simon, D., Arkko, J., Eronen, P. and H. Levkowetz,
Ed., "EAP Key Management Framework", Work in
progress draft-ietf-eap-keying-04.txt, November 2004.
[16] Pall, G. and G. Zorn, "Microsoft Point-To-Point Encryption
(MPPE) Protocol", RFC 3078, March 2001.
[17] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication
Protocol (EAP-TTLS)", Work in
progress draft-ietf-pppext-eap-ttls-05.txt, July 2004.
[18] Internet Assigned Numbers Authority, "Private Enterprise
Numbers", January 2005.
[19] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time
Password System", RFC 2289, February 1998.
[20] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2548, March 1999.
[21] American National Standards Institute, "Information Systems -
Coded Character Sets - 7-Bit American National Standard Code
for Information Interchange (7-Bit ASCII)", ANSI X3.4, January
1998.
[22] Zorn, G., "Deriving Keys for use with Microsoft Point-to-Point
Encryption (MPPE)", RFC 3079, March 2001.
Author's Address
Magnus Nystr÷m
RSA Security
Email: magnus@rsasecurity.com
Nystr÷m Expires August 18, 2005 [Page 52]
Internet-Draft EAP-POTP February 2005
Appendix A. Examples of EAP-POTP exchanges
In the examples, "V1","V2","V3", etc. stand for arbitrary values of
the correct type.
A.1 Basic mode, unilateral authentication
This mode should only be used within a secured tunnel. The peer
identifies itself with a User Identifier TLV.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=0,C=0,N=0,T=0,E=0,R=0
Authentication Data=V1
User Identifier TLV:
User Identifier=V2
<- EAP-Success
A.2 Mutual authentication without session resumption
In this case, the peer uses the token serial number in addition to
the user identifier. The initial EAP-Identity exchange may also
provide user information, or may be restricted to only general domain
Nystr÷m Expires August 18, 2005 [Page 53]
Internet-Draft EAP-POTP February 2005
information. Pepper is not used, but will be used in a subsequent
session since the server provides the peer with an encrypted pepper
in its Confirm TLV.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
Server-Info TLV:
N=0
Session Identifier=V1
Server Identifier=V2
Nonce=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=0
Iteration Count=V4
Authentication Data=V5
User Identifier TLV:
User Identifier=V6
Token Serial Number TLV:
Token Serial Number=V7
<- EAP-Request
Nystr÷m Expires August 18, 2005 [Page 54]
Internet-Draft EAP-POTP February 2005
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V8
Pepper Identifier=V9
Encrypted Pepper=V10
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
A.3 Mutual authentication with transfer of pepper
The difference between this example and the previous one is that the
peer makes use of an existing pepper in the PBKDF2 computation. The
EAP server provides a new pepper to the peer in the Confirm TLV.
Note that the peer had not been able to use a pepper in the response
calculation unless it had found the existing pepper, since the server
specified a maximum (new) pepper length of zero.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
Server-Info TLV:
N=0
Session Identifier=V1
Server Identifier=V2
Nonce=V3
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Nystr÷m Expires August 18, 2005 [Page 55]
Internet-Draft EAP-POTP February 2005
Pepper Length=0
Iteration Count=V4
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V5
Iteration Count=V6
Authentication Data=V7
(includes a pepper identifier)
User Identifier TLV:
User Identifier=V8
Token Serial Number TLV:
Token Serial Number=V9
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V10
Pepper Identifier=V11
Encrypted Pepper=V12
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
A.4 Failed mutual authentication
This example differs from the previous one in that the peer is not
able to authenticate the server. It therefore sends an empty
EAP-Response of type POTP-X, which the EAP server acknowledges by
responding with an EAP-Failure. Pepper is not used.
Peer EAP server
Nystr÷m Expires August 18, 2005 [Page 56]
Internet-Draft EAP-POTP February 2005
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Authentication Data=V6
User Identifier TLV:
User Identifier=V7
Token Serial Number TLV:
Token Serial Number=V8
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V9
Nystr÷m Expires August 18, 2005 [Page 57]
Internet-Draft EAP-POTP February 2005
EAP-Response ->
Type=OTP-X
(no data)
<- EAP-Failure
A.5 Session resumption
This example illustrates a successful session resumption.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
Resume TLV:
Session Identifier=V6 (indicating earlier session)
Authentication Data=V7
<- EAP-Request
Nystr÷m Expires August 18, 2005 [Page 58]
Internet-Draft EAP-POTP February 2005
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V8
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
A.6 Failed session resumption
This example illustrates a failed session resumption, followed by a
complete mutual authentication. The user is identified through the
User Identifier TLV. The client is able to re-use an older pepper.
The server sends a new pepper for subsequent use in its Confirm TLV.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response ->
Nystr÷m Expires August 18, 2005 [Page 59]
Internet-Draft EAP-POTP February 2005
Type=OTP-X
Version TLV:
Highest=0
Resume TLV:
Session Identifier=V6 (indicating earlier session)
Authentication Data=V7
<- EAP-Request
Type=OTP-X
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V8
Iteration Count=V9
Server-Info TLV:
N=1 (no resumption)
Session Identifier=V3
Server Identifier=V4
Nonce=V10
EAP-Response ->
Type=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V11
Iteration Count=V12
Authentication Data=V13 (with pepper identifier)
User Identifier TLV:
User Identifier=V14
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V15
Pepper Identifier=V16
Encrypted Pepper=V17
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
Nystr÷m Expires August 18, 2005 [Page 60]
Internet-Draft EAP-POTP February 2005
<- EAP-Success
A.7 Mutual authentication, and new PIN requested.
In this example, the user is also requested to select a new PIN. The
new PIN is allowed to be alphanumeric, and must be at least 6
characters long. The user selects another PIN than the one suggested
by the server. The token is identified through the token serial
number.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8 (with pepper identifier)
Nystr÷m Expires August 18, 2005 [Page 61]
Internet-Draft EAP-POTP February 2005
User Identifier TLV:
User Identifier=V9
Token Serial Number TLV:
Token Serial Number=V10
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=1
Authentication Data=V11
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Request
Type=OTP-X
New PIN TLV:
Q=0,A=1
PIN=V12 (encrypted),
Min. PIN Length=6
EAP-Response ->
Type=OTP-X
New PIN TLV:
Q=0,A=0
PIN=V13 (encrypted)
<- EAP-Request
Type=OTP-X
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
EAP-Response ->
Type=OTP-X
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Nystr÷m Expires August 18, 2005 [Page 62]
Internet-Draft EAP-POTP February 2005
Iteration Count=V7
Authentication Data=V14
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V15
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
A.8 Use of next tokencode mode
In this example, the peer is requested to provide a second tokencode
to the EAP server.
Peer EAP server
<- EAP-Request
Type=Identity
EAP-Response ->
Type=Identity
<- EAP-Request
Type=OTP-X
Version TLV:
Highest=0,Lowest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V1
Iteration Count=V2
Server-Info TLV:
N=0
Session Identifier=V3
Server Identifier=V4
Nonce=V5
Nystr÷m Expires August 18, 2005 [Page 63]
Internet-Draft EAP-POTP February 2005
EAP-Response ->
Type=OTP-X
Version TLV:
Highest=0
OTP TLV:
P=1,C=0,N=0,T=0,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V8
User Identifier TLV:
User Identifier=V9
<- EAP-Request
Type=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V1
Iteration Count=V2
EAP-Response ->
Type=OTP-X
OTP TLV:
P=1,C=0,N=1,T=1,E=0,R=0
Pepper Length=V6
Iteration Count=V7
Authentication Data=V10
<- EAP-Request
Type=OTP-X
Confirm TLV:
C=0
Authentication Data=V11
EAP-Response ->
Type=OTP-X
Confirm TLV:
(no data)
<- EAP-Success
Nystr÷m Expires August 18, 2005 [Page 64]
Internet-Draft EAP-POTP February 2005
Appendix B. Use of the MPPE-Send/Receive-Key RADIUS attributes
B.1 Introduction
This session describes how to populate the MPPE-Send-Key and the
MPPE-Receive-Key RADIUS attributes defined in [20] using an MSK
established in EAP-POTP.
B.2 MPPE key attribute population
Once the EAP-POTP MSK has been generated, it is used as follows to
populate the MPPE-Send-Key and the MPPE-Receive-Key attributes:
Use the initial 32 octets of the MSK as the value for the "Key"
sub-fieldin the plaintext "String" field of the MPPE-Send-Key
attribute, and use the final 32 octets of the MSK as the "Key"
sub-field in the plaintext "String" field of the MPPE-Receive-Key
attribute (Note: "Send" and "Receive" here refers to the
Authenticator, for the peer they are reversed).
Nystr÷m Expires August 18, 2005 [Page 65]
Internet-Draft EAP-POTP February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Nystr÷m Expires August 18, 2005 [Page 66]
