RFC 4793
The EAP Protected One-Time Password Protocol (EAP-POTP)
Pages: 82
Informational
Informational
Part 2 of 3 – Pages 20 to 56
4.11. EAP-POTP TLV Objects
4.11.1. Version TLV
The Version TLV carries information about the supported EAP-POTP method version. This TLV MUST be present in the initial EAP-Request of type POTP-X from the EAP server and in the initial response of type POTP-X from the peer. It MUST NOT be present in any subsequent EAP-Request or EAP-Response in the session. The Version TLV MUST be supported by all peers, and all EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. The version negotiation procedure is described in detail in Section 4.2. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Highest | Lowest | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP. TLV Type 1 Length 3 in EAP-Requests, 2 in EAP-Responses
Reserved
Reserved for future use. This octet MUST be set to zero for this
version. Recipients SHALL ignore this octet for this version of
EAP-POTP.
Highest
This field contains an unsigned integer representing the highest
protocol version supported by the sender. If a value provided by
a peer to an EAP server falls between the server's "Highest" and
"Lowest" supported version (inclusive), then that value will be
the negotiated version for the authentication session.
Lowest
This field contains an unsigned integer representing the lowest
version acceptable by the EAP server. The field MUST be present
in an EAP-Request. The field MUST NOT be present in an EAP-
Response. A peer SHALL respond to an EAP-Request of type POTP-X
with an EAP-Response of type Nak (3) if the peer's highest
supported version is lower than the value of this field.
This document defines version 1 of the protocol. Therefore, EAP
server implementations conforming to this document SHALL set the
"Highest" field to 1. Peer implementations conforming to this
document SHALL set the "Highest" field to 1.
4.11.2. Server-Info TLV
The Server-Info TLV carries information about the EAP server and the
session (when applicable). It provides one piece in the framework
for fast session resumption.
This TLV SHOULD always be present in an EAP-Request of type POTP-X
that also carries an OTP TLV, as long as the peer has not been
authenticated, and MUST be present in such a request if the server
supports session resumption. It MUST NOT be present in any other
EAP-Request of type POTP-X or in any EAP-Response packets. This TLV
type MUST be supported by all peers conforming to this specification
and MUST NOT be responded to with a NAK TLV (this is not to say that
all peers need to support session resumption, only that they cannot
respond to this TLV with a NAK TLV).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |N| Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Nonce ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
2
Length
25 + length of Server Identifier field
Reserved
Reserved for future use. All 7 bits MUST be set to zero for this
version. Recipients SHALL ignore this bit for this version of
EAP-POTP.
N
The N bit signals that the peer MUST NOT attempt to resume any
session it has stored associated with this server.
Session Identifier
An 8-octet identifier for the session about to be negotiated.
Note that, in the case of session resumption, this session
identifier will not be used (the session identifier for the
resumed session will continue to be used).
Nonce
A 16-octet nonce chosen by the server. During session resumption,
this nonce is used when calculating new K_ENC, K_MAC, SRK, MSK,
and EMSK keys as specified below.
Server Identifier
An identifier for the authentication server. The peer MAY use
this identifier to search for a stored session associated with
this server, or to associate the session to be negotiated with the
server. The value of the identifier SHOULD be chosen so as to
reduce the risk of collisions with other EAP server identifiers as
much as possible. One possibility is to use the DNS name of the
EAP server. The identifier MAY also be used by the peer to select
a suitable key on the OTP token (when there are multiple keys
available).
The identifier MUST NOT be longer than 128 octets. The identifier
SHALL be a UTF-8 [7] encoded string of printable characters
(without any terminating NULL character).
4.11.3. OTP TLV
In an EAP-Request, the OTP TLV is used to request an OTP (or a value
derived from an OTP) from the peer. In an EAP-Response, the OTP TLV
carries an OTP or a value derived from an OTP.
This TLV type MUST be supported by all peers and all EAP servers
conforming to this specification and MUST NOT be responded to with a
NAK TLV. The OTP TLV MUST NOT be present in an EAP-Request of type
POTP-X that contains a New PIN TLV. Further, the OTP TLV MUST NOT be
present in an EAP-Response of type POTP-X unless the preceding EAP-
Request of type POTP-X contained an OTP TLV and it was valid for it
to do so. Finally, an OTP TLV MUST NOT be present in an EAP-
Response of type POTP-X that also contains a Resume TLV. The OTP TLV
is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |A|P|C|N|T|E|S| Pepper Length |Iteration Count|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Iteration Count (cont.) | Auth. Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
3
Length
7 + length of Authentication Data field
Reserved
Reserved for future use. All 9 bits SHALL be set to zero (0) for
this version. Recipients SHALL ignore these bits for this version
of EAP-POTP.
A
The A bit MUST be set in an EAP-Request if and only if the request
immediately follows an EAP-Response of type POTP-X containing a
New PIN TLV (see Section 4.11.5), and the new PIN in the response
was accepted by the EAP server. In this case, the A bit signals
that the EAP-server has accepted the PIN, and that the peer SHALL
use the newly established PIN when calculating the response (when
applicable). The A bit MUST NOT be set if the S bit is set. If a
request has both the S bit and the A bit set, the peer SHALL
regard the request as invalid, and return an empty POTP-X EAP-
Response message.
In an EAP-Response, the A bit, when set, indicates that the OTP
was calculated with the use of the newly selected user PIN. The A
bit MUST be set in a response if and only if the EAP-Request which
triggered the response contained an OTP TLV with the A bit set.
P
In an EAP-Request, the P bit indicates that the OTP in the
response MUST be protected. Use of this bit also indicates that
mutual authentication will take place, as well as generation of
keying material. It is RECOMMENDED to always set the P bit. If a
peer receives an EAP-Request with an OTP TLV that does not have
the P bit set, and the peer's policy dictates protected mode, the
peer MUST respond with an empty POTP-X EAP-Response message. All
peers MUST support protected mode.
In an EAP-Response, this bit indicates that the provided OTP has
been protected (see below). The P bit MUST be set in a response
(and hence the OTP MUST be protected) if and only if the EAP-
Request that triggered the response contained an OTP TLV with the
P bit set.
In an 802.1x EAP over LAN (EAPOL) environment (this includes
wireless LAN environments), the P bit MUST be set, or,
alternatively, the EAP-POTP method MUST be carried out inside an
authenticated tunnel that provides a cryptographic binding with
inner EAP methods such as the one provided by PEAPv2 [17].
C
The C bit carries meaning only when the OTP algorithm in question
makes use of server challenges. For other OTP algorithms, the C
bit SHALL always be set to zero.
In an EAP-Request, the C bit ("Combine") indicates that the OTP
SHALL be calculated using both the provided challenge and internal
state (e.g., current token time). The OTP SHALL be calculated
based only on the provided challenge (and the shared secret) if
the C bit is not set, and a challenge is present. The returned
OTP SHALL always be calculated based on the peer's current state
(and the shared secret) if no challenge is present. If the C bit
is set but no challenge is provided, the peer SHALL regard the
request as invalid, and return an empty POTP-X EAP-Response
message.
In an EAP response, this bit indicates that the provided OTP has
been calculated using a provided challenge and the token state.
The C bit MUST be set in a response if and only if the EAP-Request
that triggered the response contained an OTP TLV with the C bit
set and a challenge.
N
In an EAP-Request, the N bit, when set, indicates that the OTP to
calculate SHALL be based on the next token "state", and not the
current one. As an example, for a time-based token, this means
the next time slot. For an event-based token, this could mean the
next counter value, if counter values are used. This bit will
normally not be set in initial EAP-Request messages, but may be
set in subsequent ones. Further, the N bit carries no meaning in
an EAP-Request if a challenge is present and the C bit is not set,
and SHALL be set to 0, in this case. If a request that has the N
bit set also contains a challenge, but does not have the C bit
set, the peer SHALL regard the request as invalid, and return an
empty POTP-X EAP-Response message. Note that setting the N bit in
an EAP-Request will normally advance the internal state of the
token.
In an EAP-Response, the N bit, when set, indicates that the OTP
was calculated based on the next token "state" (as explained
above), and not the current one. The N bit MUST be set in a
response if and only if the EAP-Request that triggered the
response contained an OTP TLV with the N bit set.
T
The T bit only carries meaning for OTP methods normally
incorporating a user PIN in the OTP computation.
In an EAP-Request, the T bit, when set, indicates that the OTP to
calculate MUST NOT include a user PIN.
In an EAP-Response, the T bit, when set, indicates that the OTP
was calculated without the use of a user PIN. The T bit MUST be
set in a response if and only if the EAP-Request that triggered
the response contained an OTP TLV with the T bit set. Note that
client policy may prohibit PIN-less calculations; in these cases,
the client MAY respond with an empty POTP-X EAP response message.
E
In an EAP-Request, the E bit, when set, indicates that the peer
MUST NOT use any stored pepper value associated with this server
in the PBKDF2 computation. Rather, it MUST generate a new pepper
(if supported by the peer) and/or use the iteration count
parameter to protect the OTP (if the server's Max Pepper Length is
0, then the peer MUST rely on the iteration count only to protect
the OTP). This bit will usually not be set in initial EAP-Request
messages, but may be set in subsequent ones, e.g., if the server,
upon receipt of an OTP TLV with a pepper identifier, detects that
it does not have a pepper with that identifier in storage. This
bit carries no meaning, and MUST be set to zero, when the P bit is
not set. If a request has the E bit set but not the P bit, a peer
SHALL regard the request as invalid, and return an empty POTP-X
EAP-Response message.
In an EAP-Response, the E bit indicates that the response has been
calculated without use of any stored pepper value.
S
In an EAP-Request, the S bit ("Same"), when set, indicates that
the peer SHOULD calculate its response based on the same OTP value
as was used for the preceding response. This bit MAY be set when
the EAP server has received an OTP TLV from the peer protected
with a pepper, of which the server is no longer in possession.
Since the server has not attempted validation of the provided
data, there is no need for the EAP peer to retrieve a new OTP
value. This bit carries no meaning, and MUST be set to zero, when
the E bit is not set. A peer SHALL regard a request where the S
bit is set, but not the E bit, as invalid, and return an empty
POTP-X EAP-Response message. Further, the S bit MUST NOT be set
when the A bit also is set; see above.
In an EAP-Response, the S bit is never set.
Pepper Length
This octet SHALL be present if and only if the P bit is set. When
present, it contains an unsigned integer, having a value between 0
and 255 (inclusive). In an EAP-Request, the integer represents
the maximum length (in bits) of a client-generated pepper the
server is prepared to search for. Peers MUST NOT generate peppers
longer than this value. If the value is set to zero, it means the
peer MUST NOT generate a pepper for the PBKDF2 calculation. In an
EAP-Response, it indicates the length of the used pepper.
Iteration Count
These 4 octets SHALL be present if and only if the P bit is set.
When present, they contain an unsigned, 4-octet integer in network
byte order. In an EAP-Request, the integer represents the maximum
iteration count the peer may use in the PBKDF2 computation. Peers
MUST NOT use iteration counts higher than this value. In an EAP-
Response, it indicates the actual iteration count used.
Note regarding the Pepper Length and Iteration Count parameters: A
peer MUST compare these policy parameters provided by the EAP server
with local policy and MUST NOT continue the handshake if use of the
EAP server's suggested parameters would result in a lower security
than the client's acceptable policy. If the security given by the
EAP server's provided policy parameters surpasses the security level
given by the peer's local policy, the client SHOULD use the server's
parameters (subject to reason - active attackers could otherwise
mount simple denial-of-service attacks against peers or servers,
e.g., by providing unreasonably high values for the iteration count).
Note that the server-provided parameters only apply to the case where
the peer cannot use or does not have a previously provided server-
provided pepper. If a peer cannot continue the handshake due to the
server's policy being unacceptable, it MUST return an empty POTP-X
EAP-Response message.
Authentication Data
EAP-Request: In an EAP-Request, the Authentication Data field, when
present, contains an optional "challenge". The challenge is an
octet string that SHOULD be uniquely generated for each request in
which it is present (i.e., it is a "nonce"), and SHOULD be 8
octets or longer. To avoid fragmentation (i.e., EAP messages
longer than the minimum EAP MTU size; see [1]), the challenge MUST
NOT be longer than 64 octets. When the challenge is not present,
the OTP will be calculated on the current token state only. The
peer MAY ignore a provided challenge if and only if the OTP token
the peer is interacting with is not capable of including a
challenge in the OTP calculation. In this case, EAP server
policies will determine whether or not to accept a provided OTP
value.
EAP-Response: The following applies to the Authentication Data field
in an EAP-Response:
* When the P bit is not set, the peer SHALL directly place the
OTP value calculated by the token in the Authentication Data
field. In this case, the EAP server MUST NOT send a Confirm
TLV upon successful authentication of the peer (instead, it
sends an EAP-Success message).
* When the P bit is set, the peer SHALL populate this field as
follows. After the token has calculated the OTP value, the
peer SHALL compute:
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(otp, salt | pepper
| auth_id, iteration_count, key_length)
where
"|" denotes concatenation,
"otp" is the already computed OTP value,
"salt" is a 16-octet nonce,
"pepper" is an optional nonce (at most, 255 bits long, and,
if necessary, padded to be a multiple of 8 bits long; see
below) included to complicate the task of finding a matching
"otp" value for an attacker,
"auth_id" is an identifier (at most, 255 octets in length)
for the authenticator (i.e., the network access server) as
reported by lower layers and as specified below,
"iteration_count" is an iteration count chosen such that the
computation time on the peer is acceptable (based on the
server's indicated policy and the peer's local policy),
while an attacker, having observed the response and
initiating a search for a matching OTP, will be sufficiently
slowed down. The "iteration_count" value MUST be chosen to
provide a suitable level of protection (e.g., at least
100,000) unless a server-provided pepper is being used, in
which case, it SHOULD be 1.
"key_length" is the combined length of the desired key
material, in octets. When the default algorithms are used,
key_length is 176.
The "pepper" values are only included in PBKDF2 calculations
and are never sent to EAP servers (though the peers do send
their length, in bits). The purpose of the pepper values
are, as mentioned above, to slow down an attacker's search
for a matching OTP, while not slowing down the peer (which
iterated hashes do). If the pepper has been generated by
the peer, and the chosen pepper length in bits is not a
multiple of 8, then the pepper value SHALL be padded to the
left, with '0' bits to the nearest multiple of 8 before
being used in the PBKDF2 calculation. This is to ensure the
input to the calculation consists only of whole octets. As
an example, if the chosen pepper length is 4, the pepper
value will be padded to the left, with 4 '0' bits to form an
octet before being used in the PBKDF2 calculation.
When pepper is used, it is RECOMMENDED that the length of
the pepper and the iteration count are chosen in such a way
that it is computationally infeasible/unattractive for an
attacker to brute-force search for the given OTP within the
lifetime of that OTP.
As mentioned previously, a peer MUST NOT include a newly
generated pepper value in the PBKDF2 computation if the
server did not indicate its support for pepper searching in
this session. If the server did not indicate support for
pepper searching, then the PBKDF2 computation MUST be
carried out with a sufficiently higher number of iterations
so as to compensate for the lack of pepper (see further
Appendix D).
A server may, in an earlier session, have transferred a
pepper value to the peer in a Confirm TLV (see below). When
this is the case, and the peer still has that pepper value
stored for this server, the peer MUST NOT generate a new
pepper but MUST, instead, use this transferred pepper value
in the PBKDF2 calculations. The only exception to this is
when a local policy (e.g., timer) dictates that the peer
must switch to a new pepper (and the server indicated
support for pepper searching).
The following applies to the auth_id component:
- For dial-up, "auth_id" SHALL be either the empty string
or the phone number called by the peer. The phone number
SHALL be specified in the form of a URL conformant with
RFC 3966 [8], e.g., "tel:+16175550101". Processing of
received phone numbers SHALL be conformant with RFC 3966
(this assumes that "tel" URIs will be shorter than 256
octets, which would normally be the case).
- For use with IEEE 802.1X, "auth_id" SHALL be either the
empty string or the MAC address of the authenticator in
canonical binary format (6 octets).
- For IP-based EAP, "auth_id" SHALL be either the empty
string or the IPv4 or IPv6 address of the authenticator
as seen by the peer and in binary format (4 or 16 octets,
respectively). As an example, the IPv4 address
"192.0.2.5" would be represented as (in hex) C0 00 02 05,
whereas the IPv6 address "2001:DB8::101" would be
represented as (in hex) 20 01 0D B8 00 00 00 00 00 00 00
00 00 00 01 01.
Note: Use of the authenticator's identifying information
within the computation aids in protection against man-in-
the-middle attacks, where a rogue authenticator seeks to
intercept and forward the Authentication Data in order to
impersonate the peer at a legitimate authenticator (but see
also the discussion around spoofed authenticator addresses
in Section 6). For these reasons, a peer SHOULD NOT set the
auth_id component to the empty string unless it is unable to
learn the identifying information of the authenticator. In
these cases, the EAP server's policy will determine whether
or not the session may continue.
As an example, when otp = "12345678", salt =
0x54434534543445435465768789099880, pepper is not used,
auth_id = "192.0.2.5", iteration_count = 2000 (decimal), and
key_length = 176 (decimal), the input to the PBKDF2
calculation will be (first two parameters in hex, line wrap
for readability):
(3132333435363738, 54434534543445435465768789099880 |
c0000205, 2000, 176)
As described, when the default algorithms are used, K_MAC is
the first 16 octets of the output from PBKDF2, K_ENC the
next 16 octets, MSK the following 64 octets, EMSK the next
64 octets, and SRK the final 16 octets. Using K_MAC, the
peer calculates:
mac = MAC(K_MAC, msg_hash(msg_1, msg_2, ..., msg_n))
as specified in Section 4.9 and where msg_1, msg_2, ...,
msg_n is a sequence of all EAP messages of type POTP-X
exchanged so far in this session, as sent and received by
the peer (for the peer's initial MAC, it will typically be
just one message: the EAP server's initial EAP-Request of
type POTP-X).
The peer then places the first 16 octets of "mac" in the
Authentication Data field, followed by the "salt" value,
followed by one octet representing the length of the
"auth_id" value in octets, followed by the actual "auth_id"
value in binary form, and optionally followed by a pepper
identifier (only when the peer made use of a pepper value
previously provided by the EAP server). Pepper identifiers,
when present, are always 4 octets. All variables SHALL be
present in the form they were input to the PBKDF2 algorithm.
This will result in the Authentication Data field being 33 +
(length of auth_id in octets) + (4, for pepper identifier,
when present) octets in length.
Continuing the previous example, the Authentication Data
field will be populated with (in hex, line wrap for
readability):
< 16 octets of mac > | 54434534543445435465768789099880 |
04 | c0000205
Note: Since in this case (i.e., when the P bit is set)
successful authentication of the peer by the EAP server will
be followed by the transmission of an EAP-Request of type
POTP-X containing a Confirm TLV for mutual authentication,
the peer MUST save either all the input parameters to the
PBKDF2 computation or the keys K_MAC, K_ENC, SRK, MSK, and
EMSK (recommended, since they will be used later). This is
because the peer cannot be guaranteed to be able to generate
the same OTP value again. For the same reason (the Confirm-
TLV from the EAP server), the peer MUST also store either
the hash of the contents of the sent EAP-Response or the
EAP-Response itself (but see the note above about not
including any User Identifier TLVs in the hash computation).
Given a set of possible OTP values, the authentication
server verifies an authentication request from the peer by
computing
K_MAC' | K_ENC' | MSK' | EMSK' | SRK' = PBKDF2 (otp',
salt | pepper' | auth_id, iteration_count, key_length)
for each possible OTP value otp' and each possible pepper
value pepper' , and the provided values for salt,
authenticator identity, and iteration count, as well as the
applicable key length (default: 176). Note: Doing the
computation for each possible pepper value implements the
pepper search mentioned elsewhere in this document. Note
also that the EAP server may accept more than one OTP value
at a given time, e.g., due to clock drift in the token. If
the given pepper length is not a multiple of 8, each tested
pepper value will be padded to the left to the nearest
multiple of 8, in the same manner as was done by the peer.
If the server already shares a secret pepper value with this
peer, then obviously there will only be one possible pepper
value, and the server will find it based on the
pepper_identifier provided by the peer. The server SHALL
send a new EAP-Request of type POTP-X with an OTP TLV with
the E bit set if the peer provided a pepper identifier
unknown to the server.
For each K_MAC', the EAP server computes
mac' = MAC(K_MAC', msg_hash(msg_1', msg_2', ..., msg_n'))
where MAC is the negotiated MAC algorithm, msg_hash is the
message hash algorithm defined in Section 4.9, and msg_1',
msg_2', ... msg_n' are the same messages on which the peer
calculated its message hash, but this time, as sent and
received by the EAP server. If the first 16 octets of mac'
matches the first 16 octets in the Authentication Data field
of the EAP-Response in question, and the provided
authenticator identity is acceptable (e.g., matches the EAP
server's view of the authenticator's identity), then the
peer is authenticated.
If the authentication is successful, the authentication
server then attempts to authenticate itself to the peer by
use of the Confirm TLV (see below). If the authentication
fails, the EAP server MAY send another EAP-Request of type
POTP-X containing an OTP TLV to the peer, or it MAY send an
EAP-Failure message (in both cases, possibly preceded by an
EAP-Request of type Notification).
4.11.4. NAK TLV
Presence of this TLV indicates that the peer did not support a
received TLV with the M bit set. This TLV may occur 0, 1, or more
times in an EAP-Response of type POTP-X. Each occurrence flags the
non-support of a particular received TLV.
The NAK TLV MUST be supported by all peers and all EAP servers
conforming to this specification and MUST NOT be responded to with a
NAK TLV. Receipt of a NAK TLV by an EAP server MAY cause an
authentication to fail, and the EAP server to send an EAP-Failure
message to the peer.
Note: The definition of the NAK TLV herein matches the definition made in [17], and has the same type number. Field descriptions are copied from that document, with some minor modifications. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NAK-Type | TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP. TLV Type 4 Length 6 + cumulative total length of embedded TLVs Vendor-Id The Vendor-Id field is 4 octets, and contains the Vendor-Id of the TLV that was not supported. The high-order octet is 0 and the low-order 3 octets are the Structure of Management Information (SMI) Network Management Private Enterprise Code of the Vendor in network byte order. The Vendor-Id field MUST be zero for TLVs that are not Vendor-Specific TLVs. For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code. NAK-Type The type of the unsupported TLV. The TLV MUST have been included in the most recently received EAP message.
TLVs This field contains a list of TLVs, each of which MUST NOT have the mandatory bit set. These optional TLVs can be used in the future to communicate why the offending TLV was determined to be unsupported.4.11.5. New PIN TLV
In an EAP-Request, the New PIN TLV is used to request a new user PIN from the peer. The EAP server MAY provide a new PIN, as described below. In an EAP-Response, the New PIN TLV carries a chosen new user PIN. This TLV may be used by an EAP server when policy dictates that the peer (user) needs to change a PIN associated with the OTP Token. This TLV type SHOULD be supported by peers and EAP servers conforming to this specification. The New PIN TLV MUST NOT be sent by an EAP server unless the peer has been authenticated. If the peer was authenticated in protected mode, then the New PIN TLV MUST NOT be present in an EAP-Request until after the exchange of the Confirm TLV (i.e., until after mutual authentication has occurred and keys are in place to protect the TLV). The New PIN TLV MUST be sent by a peer if and only if the EAP-Request that triggered the response contained a New PIN TLV, it was valid for the EAP server to send such a TLV in that request, and the TLV is supported by the peer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |Q|A| PIN Length | PIN ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Min. PIN Length|Max. PIN Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP. TLV Type 5
Length
2 + length of the PIN field (as specified in the PIN Length field)
+ (0, 1, or 2)
Note: The final term above is
- 0 if none of the optional Min. / Max. PIN Length fields is
present in the TLV,
- 1 if only the Min. PIN Length field is present in the TLV,
- 2 if both of these optional fields are present in the TLV.
Reserved
Reserved for future use. All six bits SHALL be set to zero for
this version. Recipients SHALL ignore these bits for this version
of EAP-POTP.
Q
The Q bit, when set in an EAP-Request, indicates that an
accompanying PIN is required, i.e., the peer (user) is not free to
choose another PIN. When the Q bit is set, there MUST be an
accompanying PIN and the provided PIN MUST be used in subsequent
OTP generations. A peer SHALL respond with an empty POTP-X EAP-
Response message if the Q bit is set but there is not any
accompanying PIN. When the Q bit is not set, any provided PIN is
suggested only, and the peer is free to choose another PIN,
subject to local policy.
The Q bit carries no meaning, and SHALL be set to zero, in an EAP-
Response.
A
This bit allows methods that distinguish between two different PIN
types (e.g., decimal vs. alphanumeric) to designate whether the
augmented set is to be used (when set) or not (when not set). The
A bit carries no meaning, and SHALL be set to zero, in an EAP-
Response.
PIN Length
This field contains an unsigned integer representing the length of
the provided PIN (this implies that the maximum length of a PIN
will be 255 octets).
PIN
In an EAP-Request, subject to the setting of the Q bit, the PIN
field MAY be empty. If empty, the peer (user) will need to choose
a PIN subject to local and (any) provided policy. When the PIN
field is not empty, it MUST consist of UTF-8 encoded printable
characters without a terminating NULL character.
In an EAP-Response, the PIN value SHALL consist of a UTF-8 encoded
string of printable characters without a terminating NULL
character.
The peer accepts a PIN suggested by the EAP server by replying
with the same PIN, but MAY replace it with another one, depending
on the server's setting of the Q bit. The length of the PIN is
application-dependent, as are any other requirements for the PIN,
e.g., allowed characters. The peer MUST be prepared to receive a
repeated request for a new PIN, as described above, if the EAP
server, for some reason does not accept the received PIN. Such a
request MAY be preceded by an EAP-Request of type Notification (2)
providing information to the user about the reason for the
rejection. Mechanisms for transferring knowledge about PIN
requirements from the EAP server to the peer (beyond those
specified for this TLV, such as maximal and minimal PIN length)
are outside the scope of this document. However, some information
MAY be provided in notification messages transferred from the EAP
server to the peer, as per above.
Min. PIN Length
This field MAY be present in an EAP-Request. This field MUST NOT
be present in an EAP-Response. It SHALL be interpreted as an
unsigned integer in network byte order representing the minimum
length allowed for a new PIN.
Max. PIN Length
This field MUST NOT be present in an EAP-Request unless the Min.
PIN Length field is present, in which case it MAY be present. The
field MUST NOT be present in an EAP-Response. It SHALL be
interpreted as an unsigned integer in network byte order
representing the maximum length allowed for a new PIN. The value
of this field, when present, MUST be equal to, or larger than, the
value of the Min. PIN Length field.
4.11.6. Confirm TLV
Presence of this TLV in a request indicates that the EAP server has successfully authenticated the peer and now attempts to authenticate itself to the peer. Presence of this TLV in a response indicates that the peer successfully authenticated the EAP server, and that calculated keys (K_MAC, K_ENC, MSK, EMSK, and SRK) now become available for use. The Confirm TLV MUST NOT appear together with any other TLV in an EAP-Request message of type POTP-X and MUST NOT be sent unless the peer has been authenticated through an OTP TLV with the P bit set or through a Resume TLV for which the underlying session was established in protected mode. The Confirm TLV MUST be present in an EAP- Response if and only if the request that triggered the response contained a Confirm TLV, it was legal for it to do so, and the Confirm TLV authenticated the EAP server to the peer. If the peer was not able to authenticate the server, then it MUST send an empty (i.e., no TLVs present) EAP-Response of type POTP-X. An EAP server MUST send an EAP-Success message after receiving an EAP-Response of type POTP-X containing a valid Confirm TLV, sent in response to an EAP-Request containing a Confirm TLV where the C bit was not set. A peer MUST NOT accept an EAP-Success message when it has sent an OTP TLV with the P bit set unless it has received an acceptable Confirm TLV from the EAP server. This TLV type MUST be supported by all peers and EAP servers conforming to this specification and MUST NOT be responded to with a NAK TLV. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |C| Authentication Data ... (16 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Pepper Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IV ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Encrypted Pepper ... (16 octets) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
6
Length
17 or 37 + length of IV in requests, 1 in responses.
Reserved
Reserved for future use. These 7 bits SHALL be set to zero (0)
for this version. Recipients SHALL ignore these bits for this
version of EAP-POTP.
C
The C bit, when set in an EAP-Request, indicates that the EAP
server intends to send more EAP-Requests of type POTP-X in this
session, after receipt of a Confirm TLV from the peer.
The C bit carries no meaning in EAP-Responses, and MUST NOT be set
within them.
Note: An EAP-Response containing a Confirm TLV, sent in response
to an EAP-Request containing a Confirm TLV that did not have the C
bit set, MUST be followed by an EAP-Success message from the EAP
server concluding the handshake. However, when the C bit was set
in an EAP-Request, the EAP server MAY send another EAP-Request
(containing, for example, a New PIN TLV wrapped in a Protected
TLV) rather than an EAP-Success message. Therefore, peers MUST
NOT assume that the only EAP message following an EAP-Response of
type POTP-X containing a Confirm TLV is EAP-Success. The C bit
gives EAP servers a way to indicate their intent to follow the
Confirm TLV with more requests, and allows the peer's state
machine to adapt to this.
Authentication Data
EAP-Request:
In a request, this field consists of the first 16 octets of
(see also Section 4.11.3):
mac_a = MAC(K_MAC', msg_hash(trig_msg))
where
MAC is the negotiated MAC algorithm,
"K_MAC'" has been calculated as described in Section 4.11.3 or
(in the case of session resumption) Section 4.11.8, and
"msg_hash" is the message hash algorithm defined in Section
4.9, and "trig_msg" the latest EAP-Response of type POTP-X
received from the peer (the one which triggered this request).
Given a saved or recomputed value for K_MAC, the peer
authenticates the EAP server by computing
mac'' = MAC(K_MAC, msg_hash(trig_msg'))
where "msg_hash(trig_msg')" is the peer's hash of the EAP-
Response message that it sent to the server (and that the
server calculated its message hash on). If the first 16 octets
of mac'' matches the first 16 octets in the Authentication Data
field of the EAP-Request in question, then the EAP server is
authenticated.
EAP-Response:
Not used in this version, and SHALL NOT be present in EAP-
Responses.
Pepper Identifier
In an EAP-Request, the truncated MAC MAY optionally be followed by
an encrypted pepper and its identifier. This initial, 4-octet
field identifies a pepper generated by the server.
For this version of EAP-POTP, this field SHALL NOT be present in
EAP-Responses.
IV (Initialization Vector)
An initialization vector for the encryption. The length of the
vector is dependent on the negotiated encryption algorithm. For
example, for AES-CBC, it SHALL be 16 octets. The IV is only
present if a pepper is present, and the negotiated encryption
algorithm makes use of an IV. This field SHALL NOT be present in
EAP-Response messages for this version of EAP-POTP.
Encrypted Pepper
When present in an EAP-Request, this will be a uniformly
distributed and randomly chosen 16-octet pepper generated by the
EAP server and encrypted with the negotiated encryption algorithm,
using K_ENC as the encryption key and possibly (depending on the
encryption algorithm) using an IV (stored in the IV field). This
field MUST be present if and only if the Pepper Identifier field
is present.
EAP servers are RECOMMENDED to include a freshly generated
encrypted pepper (and a corresponding Pepper Identifier) in every
Confirm TLV.
This field SHALL NOT be present in EAP-Response messages for this
version of EAP-POTP.
When a new pepper is generated by the server and transferred in
encrypted form to the peer, then this new pepper value will be stored
in the EAP server upon receipt of the Confirm TLV from the peer, and
SHOULD be stored with its identifier and associated with the EAP
server and the current user in the peer upon receipt of the EAP-
Success message. If the peer already had a pepper stored for the EAP
server, it SHALL replace it with the newly received one.
4.11.7. Vendor-Specific TLV
The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage. A
Vendor-Specific TLV can contain one or more inner TLVs, referred to
as Vendor TLVs. The TLV-type of a Vendor TLV will be defined by the
vendor. All the Vendor TLVs inside a single Vendor-Specific TLV
SHALL belong to the same vendor.
This TLV type MAY be sent by EAP servers, as well as by peers, and
MUST be supported by all entities conforming to this specification.
Conforming implementations may not support specific Vendor TLVs
inside a Vendor-Specific TLV, however. They MAY, in this case,
respond to the Vendor TLVs with a NAK TLV containing the appropriate
Vendor-ID and Vendor TLV type.
The presence of a Vendor-Specific TLV in an EAP-Request or EAP-
Response of type POTP-X MUST NOT violate any existing rules for
coexistence of TLVs in such requests or responses. If it does, then
it will result in an EAP-Failure (when the peer made the violation)
or an empty EAP-POTP response (when the EAP-server made the
violation). It is left to the definition of specific Vendor-Specific
TLVs to further constrain when they are allowed to appear. In
particular, EAP-POTP implementations may have policies that completely disallow use of the Vendor-Specific TLV before protected mode mutual authentication has occurred (since the Protected TLV, Section 4.11.15, then can be used to protect all TLVs). Note: This TLV type has the same definition and TLV type number as the Vendor-Specific TLV in [17], and the description of it is largely borrowed from that document. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|R| TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor TLVs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ M 1 - Mandatory TLV R Reserved for future use. This bit SHALL be set to zero (0) for this version. Recipients SHALL ignore this bit for this version of EAP-POTP. TLV Type 7 Length 4 + cumulative total length of inner Vendor TLVs Vendor-ID The Vendor-Id field is 4 octets. The high-order octet SHALL be set to 0, and the low-order 3 octets SHALL be set to the SMI Network Management Private Enterprise Code (see [18]) of the Vendor in network byte order.
Vendor TLVs
This field shall contain vendor-specific TLVs, in a format defined
by the vendor. To avoid fragmentation (i.e., EAP messages longer
than the minimum EAP MTU size), the field SHOULD NOT be longer
than 256 octets.
To ensure interoperability when an EAP entity (peer or server) from
vendor A sends a vendor-specific TLV that is not understood by the
recipient EAP entity from vendor B, the vendor A entity SHALL, upon
receipt of the NAK TLV from the recipient, refrain from usage of the
vendor-specific TLV in question for the rest of the handshake, and
MUST NOT fail the session due to the receipt of the NAK TLV for the
Vendor TLV (i.e., it SHALL continue as if the vendor-specific TLV had
not been sent). Additionally, all implementations conformant with
this document SHOULD allow use of vendor-specific extensions to be
turned off via configuration.
4.11.8. Resume TLV
The Resume TLV MAY be sent by a peer to an authentication server to
attempt session resumption.
This TLV type MUST only be sent in response to an EAP-Request of type
POTP-X containing a Server-Info TLV allowing session resumption. The
Resume TLV MUST be supported by all EAP servers that send a Server-
Info TLV allowing session resumption.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Session Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Identifier (continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sess.Id (cont.)| Authentication Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Authentication Data (cont.) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
8
Length
45
Reserved
Reserved for future use. This octet SHALL be set to zero (0) for
this version. Recipients SHALL ignore this octet for this version
of EAP-POTP.
Session Identifier
An 8-octet identifier for the session the peer is trying to
resume.
Authentication Data
Upon receipt of the Server-Info TLV, and if the N bit is not set,
the peer searches for any stored sessions associated with the
server identified by the Server Name field. If a stored session
is found, the peer generates a random, 16-octet nonce, "c_nonce",
and calculates:
K_MAC | K_ENC | MSK | EMSK | SRK = PBKDF2(base_key, c_nonce |
s_nonce, iteration_count, key_length)
where
"|" denotes concatenation,
"base_key" is either the current SRK for the session (if the
session was created in protected mode) or the OTP used when the
session was created (if the session was created in basic mode),
"c_nonce" is the generated 16-octet nonce,
"s_nonce" is the server nonce from the Server-Info TLV,
"iteration_count" is the iteration count as determined by local
policy, and
"key_length" is the combined length of the desired key material,
in octets. When the default algorithms are used, key_length is
176.
The iteration count need only be 1 (one) when resuming a session
established in protected mode, but MUST be chosen to provide a
suitable level of protection when resuming a session established
in basic mode (see also Section 4.11.3).
Note: Session resumption for basic mode MUST only be carried out
in a server-authenticated and protected tunnel that also provides
a cryptographic binding for inner EAP methods.
The peer then calculates:
mac = MAC(K_MAC, msg_hash(resume_req))
where
"MAC" is the negotiated MAC algorithm, and
"msg_hash(resume_req) is the message hash algorithm defined in
Section 4.9 applied on resume_req, the EAP server's EAP-Request of
type POTP-X containing the Server-Info TLV that allowed session
resumption.
The peer then places the first 16 octets of the MAC value,
followed by the c_nonce value, followed by the iteration count
value (as a 4-byte unsigned integer in network byte order), in the
Authentication Data field. As an example, when c_nonce =
0x2b3b1b12babdebebfb43bd7bdfbeb8df and iteration_count = 1, the
Authentication Data field will be populated with (in hex):
< 16 octets of mac > | 2b3b1b12babdebebfb43bd7bdfbeb8df | 00000001
The server authenticates the peer by performing the corresponding
calculations. If the authentication is successful, the server
MUST send an EAP-Request of type POTP-X containing a Confirm TLV
to the peer. If the authentication fails, the server MUST either
send an EAP-Request of type POTP-X containing an OTP TLV and a
Server-Info TLV, where the Server-Info TLV indicates that session
resumption is not possible, or send an EAP-Failure.
When resuming in basic mode, all calculated keys SHALL be
discarded after the MAC has been calculated and verified. When
resuming in protected mode, the new SRK will replace the stored
SRK, and the new MSK and EMSK will be exported upon successful
completion of the method.
4.11.9. User Identifier TLV
The User Identifier TLV carries an identifier, typically the
username, for the holder of the OTP token used to generate the OTP.
At least one of the User Identifier TLV and the Token Key Identifier
TLV SHOULD be present in the session's first EAP-Response of type
POTP-X that also carries an OTP TLV unless a suitable identity has
been provided in a preceding EAP-Response of type Identity (1) or is
determined by some other means (see [1], Section 2). Use of the User
Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED
even when an EAP-Response of type Identity (1) has been sent. If a
peer sends both a User Identifier TLV and a Token Key Identifier TLV,
then the EAP server SHALL interpret the Token Key Identifier TLV as
specifying a particular token key for the given user. The EAP server
MUST respond with an EAP-Failure if it cannot find a token key for
the provided user.
This TLV type is sent by peers and MUST be supported by all EAP
servers conforming to this specification. The User Identifier TLV
MUST NOT be present in a response that does not also carry an OTP
TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| User Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
9
Length
Length of User Identifier, >= 1
User Identifier
The value SHALL be an UTF-8 encoded string representing the holder
of the token (MUST NOT be NULL-terminated). The string MUST be
less than 128 octets in length.
4.11.10. Token Key Identifier TLV
The Token Key Identifier TLV carries an identifier for the token key
used to generate the OTP.
At least one of the User Identifier TLV and the Token Key Identifier
TLV SHOULD be present in the session's first EAP-Response of type
POTP-X, which also carries the OTP TLV unless a suitable identity has
been provided in a preceding EAP-Response of type Identity (1) or is
determined by some other means (see [1], Section 2). Use of the User
Identifier TLV and/or the Token Key Identifier TLV is RECOMMENDED
even when an EAP-Response of type Identity (1) has been sent. If a
peer sends both a User Identifier TLV and a Token Key Identifier TLV,
then the EAP server SHALL interpret the Token Key Identifier TLV as
specifying a particular token key for the given user. The EAP server
MUST respond with an EAP-Failure if it cannot find a token key
corresponding to the provided token key identifier.
This TLV type is sent by peers and MUST be supported by all EAP
servers conforming to this specification. The Token Key Identifier
TLV MUST NOT be present in a response that does not also carry an OTP
TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token Key Identifier ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
10
Length
Length of Token Key Identifier, >= 1
Token Key Identifier
An identifier for the OTP token key used to generate the OTP. The
field MUST be less than 128 octets in length.
4.11.11. Time Stamp TLV
The Time Stamp TLV MAY be sent by peers to simplify authentications.
When present, it carries the time as reported by the OTP Token.
An EAP server conformant with this specification SHOULD support
(i.e., recognize) this TLV, but need not be able to process or act on
it. An EAP server that does not support this TLV, but receives an
EAP-Response with the TLV present, MAY ignore the value. The Time
Stamp TLV MUST NOT be present in any EAP-Responses of type POTP-X
other than those that also carries an OTP TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time Stamp ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
11
Length
Length of Time Stamp field, >= 20 (depending on precision)
Time Stamp
The time, as reported by the OTP token, at which the OTP used for
the accompanying OTP TLV was calculated. The field SHALL contain
a UTF-8 encoded value of the XML simple type "dateTime", with time
zone information and precision down to at least seconds, e.g.,
"2004-06-16T15:20:02Z".
4.11.12. Counter TLV
The Counter TLV MAY be sent by peers to simplify authentications.
When present, it carries the token counter value, as reported by the
OTP Token.
An EAP server conformant with this specification SHOULD support
(i.e., recognize) this TLV, but need not be able to process or act on
it. An EAP server that does not support this TLV, but receives an
EAP-Response with the TLV present, MAY ignore the value. The Counter
TLV MUST NOT be present in any EAP-Responses of type POTP-X other
than those that also carries an OTP TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
12
Length
Length of Counter field, >= 1 (depending on precision)
Counter
The counter value, as reported by the OTP token, at which the OTP
used for the accompanying OTP TLV was calculated. The counter
value SHALL be represented as an unsigned integer in network-byte
order, e.g., a counter value of 1030 may be sent as the 2 octets
(in hex) 04 06.
4.11.13. Challenge TLV
The Challenge TLV carries the challenge used by the token to
calculate the OTP, as reported by the token to the peer. The
Challenge TLV MUST be sent by a peer if and only if the challenge
otherwise would be unknown to the EAP server (e.g., the token or peer
modified a received challenge or generated its own challenge).
An EAP server conformant with this specification SHOULD support
(i.e., recognize) this TLV, but need not be able to process or act on
it. An EAP server that does not support this TLV, but receives an
EAP-Response with the TLV present, MAY ignore the value. The
Challenge TLV MUST NOT be present in any EAP-Responses of type POTP-X
other than those that also carry an OTP TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
0 - Non-mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
16
Length
Length of Challenge field, >= 1
Challenge
The challenge value that was used to calculate the OTP used for
the accompanying OTP TLV.
4.11.14. Keep-Alive TLV
The Keep-Alive is used to avoid EAP-POTP timeouts.
The Keep-Alive TLV MAY be sent by a peer to avoid timeouts when the
peer has received an EAP-Request containing an OTP TLV or a New PIN
TLV and is waiting for a response from the user.
An EAP-Request containing a Keep-Alive TLV MUST be sent by an EAP
server when the server receives an EAP-Response containing a Keep-
Alive TLV, and the server has an outstanding request that did not
contain a Keep-Alive TLV. In this situation, the server does not
need to re-transmit its latest outstanding request, but, due to the
synchronous nature of EAP, it needs to send another request. Re-
transmission of the latest outstanding request could be confusing for
the peer since the request would get a new Identifier value. The
Keep-Alive TLV MAY also be sent by an EAP server when the server
detects that its processing time will exceed some locally configured
threshold and may cause a network timeout. In this case, the peer
MUST respond with an EAP-Response containing a Keep-Alive TLV.
This TLV type MUST be supported by all peers and all EAP servers
conforming to this specification and MUST NOT be responded to with a
NAK TLV. The Keep-Alive TLV MUST NOT be sent in any other situations
than the ones described above. The Keep-Alive TLV MUST NOT be sent
together with any other TLVs defined herein. Implementations SHOULD
also follow recommendations made in Section 4.3 of [1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for this
version. Recipients SHALL ignore this bit for this version of EAP-
POTP.
TLV Type
13
Length
0
4.11.15. Protected TLV
The Protected TLV SHALL be used to encrypt individual or multiple
TLVs after successful exchange of the Confirm TLV (i.e., as soon as
calculated keys have been confirmed). The Protected TLV therefore
wraps "ordinary" TLVs.
This TLV type may be sent by EAP servers as well as by peers and MUST
be supported by all peers conforming to this specification. It
SHOULD be supported by all EAP servers conforming to this
specification (it need not be supported if a server never will have a
need to continue a POTP-X conversation after exchange of the Confirm
TLV).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Authentication Code ... (16 octets)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encrypted TLVs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
14
Length
>32
Message Authentication Code (MAC)
This field integrity-protects the TLV. The MAC SHALL be
calculated over the IV and the Encrypted TLVs field in the
following manner:
mac = MAC(K_MAC, iv | encrypted_tlvs)
where
MAC is the negotiated MAC algorithm, "iv" is the IV field's value,
and "encrypted_tlvs" is the value of the Encrypted TLVs field.
The first 16 octets of the MAC is placed in the Message
Authentication Code field.
Recipients MUST verify the MAC. If the verification fails, the
conversation SHALL be terminated (i.e., peers send an empty POTP-X
EAP-Response message, and EAP servers send an EAP-Failure message
possibly preceded by an EAP-Request of type Notification).
IV
An initialization vector for the encryption; see below. The
length of the vector is dependent on the negotiated encryption
algorithm, e.g., for AES-CBC, it shall be 16 octets. For some
encryption algorithms, there may not be any initialization vector.
An IV, when present, shall be randomly chosen and non-predictable.
Encrypted TLVs
This field SHALL contain one or more encrypted POTP-X TLVs. The
encryption algorithm SHALL be as negotiated; use K_ENC as the
encryption key, and use the IV field as the initialization vector
(when applicable), to encrypt the concatenation of all the TLVs to
be protected.
4.11.16. Crypto Algorithm TLV
The Crypto Algorithm TLV allows for negotiation of cryptographic
algorithms. Cryptographic Algorithm negotiation is described in
detail in Section 4.3.
This TLV MUST be present in the initial EAP-Request of type POTP-X
that also carries an OTP TLV indicating protected mode, assuming the
EAP server wants to negotiate use of any other algorithms than the
default ones. It MAY also be present in an EAP-Request of type
POTP-X that carries an OTP TLV that is sent as a result of a failed
session resumption (in this case, the peer has not yet responded to
this TLV), or when the Crypto Algorithm TLV was part of the initial
message from the EAP server, and the client negotiated another EAP-
POTP version than the highest one supported by the EAP server. The
Crypto Algorithm TLV MUST NOT be present in any other EAP-Requests.
Further, the Crypto Algorithm TLV MUST NOT be present in an EAP-
Response of type POTP-X unless the preceding EAP-Request also
contained it, and it was legal for it to do so. This TLV MUST be
supported by all peers and all EAP servers conforming to this
specification and MUST NOT be responded to with a NAK TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |Hash Alg.Length| Hash Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encr.Alg.Length| Encryption Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|MAC Alg. Length| MAC Algorithms ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M
1 - Mandatory TLV
R
Reserved for future use. This bit SHALL be set to zero (0) for
this version. Recipients SHALL ignore this bit for this version
of EAP-POTP.
TLV Type
15
Length
>=4 (at least one class of algorithms and one algorithm for that
class needs to be present)
Reserved
Reserved for future use. This octet MUST be set to zero for this
version. Recipients SHALL ignore this octet for this version of
EAP-POTP.
Hash Alg. Length
The length of the Hash Algorithms field in octets.
Hash Algorithms
Each octet pair of this field represents a hash algorithm as
follows. An EAP server MAY supply several suggestions for hash
algorithms. Each algorithm MUST appear only once. The algorithms
SHALL be supplied in order of priority. Peers MUST supply, at
most, one algorithm (if none is present, the default applies).
The defined values are:
Value
Octet 1 Octet 2 Hash algorithm
------- ------- ----------------------------------
0x00 0x00 Reserved
0x00 0x01 SHA-1
0x00 0x02 SHA-224
0x00 0x03 SHA-256 (default)
0x00 0x04 SHA-384
0x00 0x05 SHA-512
0x80 - Vendor-specific (or experimental)
As indicated, values 0x8000 and higher are for proprietary
vendor-specific algorithms. Values in the range 0x0006 - 0x7fff
are to be assigned through IANA; see Section 7.
Encr Alg. Length
The length of the Encryption Algorithms field in octets.
Encryption Algorithms
Each octet pair of this field represents an encryption algorithm
as follows. An EAP server MAY supply several suggestions for
encryption algorithms. Each algorithm MUST appear only once. The
algorithms SHALL be supplied in order of priority. Peers MUST
supply, at most, one algorithm (if none is present, the default
applies). The defined values are:
Value
Octet 1 Octet 2 Encryption algorithm
------- ------- ------------------------
0x00 0x00 Reserved
0x00 0x01 AES-CBC (default) with 128-bit keys and 16-octet IVs
0x00 0x02 3DES-CBC with 112-bit keys and 8-octet IVs
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific
proprietary algorithms. Values in the range 0x0003 - 0x7fff are
to be assigned through IANA; see Section 7.
MAC Alg. Length
The length of the MAC Algorithms field in octets.
MAC Algorithms
Each octet pair of this field represents a MAC algorithm as
follows. An EAP server MAY supply several suggestions for MAC
algorithms. Each algorithm MUST appear only once. The algorithms
SHALL be supplied in order of priority. Peers MUST supply, at
most, one algorithm (if none is present, the default applies).
The defined values are:
Value
Octet 1 Octet 2 MAC algorithm
------- ------- -----------------
0x00 0x00 Reserved
0x00 0x01 HMAC (default)
0x80 - Vendor-specific
As indicated, values 0x8000 and higher are for vendor-specific
proprietary algorithms. Values in the range 0x0002 - 0x7fff are
to be assigned through IANA; see Section 7.
When HMAC is negotiated, the hash algorithm used for HMAC SHALL be
the negotiated hash algorithm.
(next page on part 3)