1 - 2 - 3 - 4 - 6 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - R - S - T - U - V - W - X
EAP
Click on the red underlined text to get to the source
... method can be used to provide unilateral or mutual authentication,
and key material, in protocols utilizing EAP, such as PPP [10], IEEE
802.1X ...
... authenticate a user towards some service. This document
describes an EAP method intended to meet the needs of organizations
wishing to use OTP ...
... tokens in an interoperable manner to authenticate
users over EAP. The method is designed to be independent of
particular OTP ...
... Note: The term "OTP" as used herein shall not be confused with the
EAP OTP method defined in [1 ...
...
EAP-POTP has been designed with the intent that its messages and data
elements be easily parsed by EAP ...
... EAP-POTP has been designed with the intent that its messages and data
elements be easily parsed by EAP implementations. This makes it
easier to programmatically use the EAP method ...
... elements be easily parsed by EAP implementations. This makes it
easier to programmatically use the EAP method in the peer and the
authenticator ...
... 1], which uses text strings
generated by the EAP server, is intended to be interpreted and acted
upon by humans. Furthermore, EAP-POTP allows for mutual
authentication ...
... generated by the EAP server, is intended to be interpreted and acted
upon by humans. Furthermore, EAP-POTP allows for mutual
authentication and establishment of keying material, which GTC ...
... GTC does
not. To retain the generic nature of GTC, the EAP-POTP method has
been designed to support a wide range of OTP ...
... example of a particular OTP algorithm and is not related to the EAP
method defined in this document, other than that a profile ...
... method defined in this document, other than that a profile of EAP-
POTP may be created for the OTP ...
... algorithms. The same is true for EAP-POTP, the
EAP method defined herein. Advantages of profiling a particular OTP
...
...
The EAP-POTP method provides user authentication as defined below.
Additionally, it may provide mutual authentication ...
... Additionally, it may provide mutual authentication (authenticating
the EAP server to the EAP client) and establish keying material ...
... mutual authentication (authenticating
the EAP server to the EAP client) and establish keying material.
...
...
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
...
... authenticator.
The term "EAP server" is used here with the same meaning as in [1].
Any protocol used between the authenticator ...
... RADIUS [15] is a typical choice. It is assumed that the EAP client
and the peer are located on the same host ...
... "peer" is used in the following for these entities.
The EAP-POTP method assumes the use of a shared secret key, or
"seed", which is known both by the user ...
... authentication server.
In its most basic variant, the EAP-POTP method provides only one
Service (namely, user authentication ...
... Description of the EAP-POTP Method ...
...
Note: Since the EAP-POTP method is general in nature, the term
"POTP-X" is used below as a placeholder for an EAP ...
... EAP-POTP method is general in nature, the term
"POTP-X" is used below as a placeholder for an EAP method type
identifier ...
... OTP algorithm with
EAP-POTP. As an example, in the case of using RSA SecurID tokens
within EAP-POTP ...
... EAP-POTP. As an example, in the case of using RSA SecurID tokens
within EAP-POTP, the EAP method type shall be 32 (see Appendix A).
...
... method type shall be 32 (see Appendix A).
A typical EAP-POTP authentication is performed as follows (Appendix B
provides more detailed examples):
...
... provides more detailed examples):
a. The optional EAP Identity Request/Response is exchanged, as per
...
... TLV), defined below, later in the exchange.
b. The EAP server sends an EAP-Request of type POTP-X with a Version ...
... OTP (possibly in
protected form), and may contain a challenge and some other
information, like server policies. The EAP server should also
include a Server-Info TLV in the request, and must do so if it
...
... session, and may be used by the peer to find an already existing
session with the EAP server.
c. The peer responds with an EAP-Response ...
... EAP server.
c. The peer responds with an EAP-Response of type Nak (3) if it does
not support POTP-X or if it does not support a version ...
... version of this method that is also
supported by the EAP server, the peer generates an EAP-Response
of type POTP-X ...
... method that is also
supported by the EAP server, the peer generates an EAP-Response
of type POTP-X as follows:
...
... TLV will be part of the EAP-
Response to the EAP server.
* Next, if the peer's highest supported version ...
... * Next, if the peer's highest supported version equals that of
the EAP server, and the EAP server sent a Server-Info TLV, the
...
... 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 ...
... 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 ...
... * Otherwise, if the peer's highest supported version equals that
of the EAP server, and the received EAP-Request message
contains an OTP ...
... version equals that
of the EAP server, and the received EAP-Request message
contains an OTP TLV ...
... 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 ...
... OTP token
type, some of the information in the EAP-Request may not be
used in the OTP calculation, and the PIN may be optional too).
...
... 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 ...
... negotiation failed and the EAP server may try with
another EAP method. Otherwise, the EAP server checks the peer's
...
... 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 ...
... TLVs adjusted for that version. Otherwise, assuming
the EAP server did send additional TLVs in its initial EAP-
...
... the EAP server did send additional TLVs in its initial EAP-
Request, the EAP server will attempt to authenticate ...
... 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
...
... based on the response provided in c). Depending on the result of
this authentication, the EAP server may do one of the following:
* send a new EAP-Request ...
... EAP server may do one of the following:
* send a new EAP-Request of type POTP-X to the peer indicating
that session ...
...
* accept the authentication (and send an EAP-Request message
containing a Confirm TLV to the peer if the received response
...
... P bit set or was a successful attempt at a protected-
mode session resumption; otherwise, send an EAP-Success
message to the peer), or
...
...
* fail the authentication (and send an EAP-Failure message --
possibly preceded by an EAP-Request message of type
...
... authentication (and send an EAP-Failure message --
possibly preceded by an EAP-Request message of type
Notification (2) -- to the peer).
...
... Notification (2) -- to the peer).
e. If the peer receives an EAP-Success or an EAP-Failure message the
protocol run ...
...
e. If the peer receives an EAP-Success or an EAP-Failure message the
protocol run is finished. If the peer receives an EAP-Request ...
... EAP-Failure message the
protocol run is finished. If the peer receives an EAP-Request of
type Notification, it responds as specified by RFC 3748prop ...
... TLV, it attempts to authenticate the EAP server using the
provided data. If the authentication is successful, the peer
...
... provided data. If the authentication is successful, the peer
responds with an EAP-Response of type POTP-X with a Confirm TLV.
...
... 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 ...
... EAP-
Response of type POTP-X. If the peer receives an EAP-Request of
type POTP-X containing some other TLVs ...
... a Confirm TLV present, it can proceed in one of two ways: If it
has detected that there is a need to send additional EAP-Requests
of type POTP-X, it shall enter a "protected state ...
... update her OTP PIN; hence, the EAP server needs to send a New PIN
TLV. At that point, the handshake is back at step c) above
...
... version negotiation and the protection of all
TLVs). If there is no need to send additional EAP-Request
packets, the EAP server shall instead send an EAP ...
... TLVs). If there is no need to send additional EAP-Request
packets, the EAP server shall instead send an EAP-Success method
...
... EAP-Request
packets, the EAP server shall instead send an EAP-Success method
to the peer to indicate successful protocol completion. The EAP
server ...
... EAP-Success method
to the peer to indicate successful protocol completion. The EAP
server may not continue the conversation unless it indicates its
intent to do so in the Confirm TLV.
...
... POTP-X with
a Confirm TLV and receives an EAP-Response of type POTP-X, which
is empty (i.e., does not contain any TLVs ...
... is empty (i.e., does not contain any TLVs), shall respond with an
EAP-Failure and terminate the handshake.
...
...
The EAP-POTP method provides a version negotiation mechanism that
enables implementations to be backward compatible with previous
...
... enables implementations to be backward compatible with previous
versions of the protocol. This specification documents the EAP-POTP
protocol version 1. Version negotiation ...
... Version negotiation proceeds as follows:
a. In the first EAP-Request of type POTP-X, the EAP server MUST send
...
... version number, and the "Lowest" field to its lowest
supported version number. The EAP server MAY include other TLV
triplets, as described below, that are compatible with the
...
... the range of versions indicated by the EAP server, it MUST
respond with an EAP-Response of type POTP-X ...
... versions indicated by the EAP server, it MUST
respond with an EAP-Response of type POTP-X that contains a
Version ...
... supported by the peer. The peer MUST also respond to any TLV
triplets included in the EAP-Request, if it supported the
"Highest" supported version indicated in the server's Version ...
... TLV.
The EAP peer MUST respond with an EAP-Response of type Nak (3) if
it does not support a version ...
...
The EAP peer MUST respond with an EAP-Response of type Nak (3) if
it does not support a version that falls within the range ...
... range of
versions indicated by the EAP server. This will allow the EAP
server to use another EAP method ...
... versions indicated by the EAP server. This will allow the EAP
server to use another EAP method for peer authentication ...
... versions indicated by the EAP server. This will allow the EAP
server to use another EAP method for peer authentication.
...
... 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 ...
... 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 ...
... 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 ...
... EAP server did not
include any TLV triplets in the initial request, the EAP server
sends a new EAP-Request of type POTP-X ...
... TLV triplets in the initial request, the EAP server
sends a new EAP-Request of type POTP-X with the negotiated
version ...
...
The version negotiation procedure guarantees that the EAP peer and
server will agree to the highest version supported by both parties.
...
... version supported by both parties.
If version negotiation fails, use of EAP-POTP will not be possible,
and another mutually acceptable EAP method ...
... version negotiation fails, use of EAP-POTP will not be possible,
and another mutually acceptable EAP method will need to be negotiated
if authentication ...
... authentication is to proceed.
The EAP-POTP version field may be modified in transit by an attacker.
...
... version field may be modified in transit by an attacker.
It is therefore important that EAP entities only accept EAP-POTP
versions ...
... by an attacker.
It is therefore important that EAP entities only accept EAP-POTP
versions according to an explicit policy.
...
... Cryptographic algorithms are negotiated through the use of the Crypto
Algorithm TLV. EAP-POTP provides a default digest algorithm
(SHA-256 ...
... 5], and these algorithms MUST be
supported by all EAP-POTP implementations. An EAP server that does
not want to make use of any other algorithms ...
... algorithms MUST be
supported by all EAP-POTP implementations. An EAP server that does
not want to make use of any other algorithms than the default ones
...
... need not send a Crypto Algorithm TLV. An EAP server that does want
to negotiate use of some other algorithms MUST send the Crypto
Algorithm ...
... algorithms MUST send the Crypto
Algorithm TLV in the initial EAP-Request of type POTP-X that also
contains an OTP ...
... P bit set. The TLV MUST NOT be present
in any other EAP-Request in the session. (The two exceptions to this
are 1) if the client ...
... Crypto Algorithm TLV was part of the initial message from the EAP
server, and the client negotiated another EAP-POTP version ...
... 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 ...
... EAP-POTP version than the
highest one supported by the EAP server. When either of these cases
apply, the server MUST include the Crypto Algorithm TLV ...
... version
negotiation.) In the Crypto Algorithm TLV, the EAP server suggests
some combination of digest, encryption, and MAC algorithms ...
... The peer MUST include a Crypto Algorithm TLV in an EAP-Response if
and only if an EAP-Request of type POTP-X ...
... TLV in an EAP-Response if
and only if an EAP-Request of type POTP-X has been received
containing a Crypto Algorithm ...
... containing a Crypto Algorithm TLV, it was legal for that EAP-Request
to contain a Crypto Algorithm TLV ...
... TLV, the peer does not try to resume an
existing session, and the peer and the EAP server agree on at least
one algorithm not being the default one. If the peer does not supply
...
... algorithms. Servers MUST fail a session
(i.e., send an EAP-Failure) if they receive an EAP-Response TLV
...
... session
(i.e., send an EAP-Failure) if they receive an EAP-Response TLV
containing both a Resume TLV ...
... TLV.
Clearly, EAP servers and peers MUST NOT suggest any other algorithms
than the ones their policy allows them to use. Policies may also
...
... 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
...
...
In order to help the peer find a session associated with the EAP
server, an EAP server that supports session resumption MUST send a
...
... In order to help the peer find a session associated with the EAP
server, an EAP server that supports session resumption MUST send a
Server-Info TLV ...
... Server-Info TLV containing a server identifier in its initial EAP-
Request of type POTP-X that also contains an OTP ...
...
previous authentication attempt to that EAP server. If the peer
decides to attempt to resume a session with the EAP server ...
... 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 ...
... TLV identifying the chosen session and other contents, as
described below, to the EAP server.
Based on the session identifier ...
... session identifier chosen by the peer, and the time
elapsed since the previous authentication, the EAP server will decide
whether to allow the session resumption, or continue with a new
...
... session.
o If the EAP server is willing to resume a previously established
session, it MUST authenticate ...
... Confirm TLV authenticates the EAP server, then the peer
responds with an empty Confirm TLV, to which the EAP server ...
... EAP server, then the peer
responds with an empty Confirm TLV, to which the EAP server
responds with an EAP-Success message. If the Confirm TLV ...
... TLV, to which the EAP server
responds with an EAP-Success message. If the Confirm TLV does
not authenticate ...
... TLV does
not authenticate the EAP server, the peer responds with an
empty EAP-Response of type POTP-X ...
... created from a basic-mode peer authentication, then the
server MUST respond with an EAP-Success message.
If the authentication ...
...
If the authentication of the peer fails, the EAP server SHOULD
send another EAP-Request containing an OTP ...
... authentication of the peer fails, the EAP server SHOULD
send another EAP-Request containing an OTP TLV and a Server-Info
...
... bit set to indicate that no session resumption is
possible. The EAP server MAY also send an EAP-Failure message,
possibly preceded by an EAP-Request ...
... session resumption is
possible. The EAP server MAY also send an EAP-Failure message,
possibly preceded by an EAP-Request of type Notification ...
... EAP server MAY also send an EAP-Failure message,
possibly preceded by an EAP-Request of type Notification (2), in
which case, the EAP ...
... EAP-Request of type Notification (2), in
which case, the EAP run will terminate.
o If the EAP server ...
... EAP run will terminate.
o If the EAP server is not willing or able to resume a previously
established session, it will respond with another EAP-Request ...
... EAP server is not willing or able to resume a previously
established session, it will respond with another EAP-Request
containing an OTP TLV ...
... brute-force
searching for the OTP in 24 hours, then EAP-POTP session lifetimes
should be clearly less than this value.
...
...
EAP does not allow for the sending of an EAP-Response of type Nak (3)
within a method after the initial EAP-Request ...
... EAP-Response of type Nak (3)
within a method after the initial EAP-Request and EAP-Response pair
of that particular method ...
... within a method after the initial EAP-Request and EAP-Response pair
of that particular method has been exchanged (see [1 ...
... method has been exchanged (see [1], Section 2.1).
Instead, when a peer is unable to continue an EAP-POTP session, the
peer MAY respond to an outstanding EAP-Request ...
... EAP-POTP session, the
peer MAY respond to an outstanding EAP-Request by sending an empty
EAP-Response of type POTP-X ...
... 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 ...
... EAP-Response of type POTP-X rather than immediately terminating the
conversation. This allows the EAP server to log the cause of the
error.
...
... error.
To ensure that the EAP server receives the empty EAP-Response, the
peer SHOULD wait for the EAP server ...
...
To ensure that the EAP server receives the empty EAP-Response, the
peer SHOULD wait for the EAP server to reply before terminating 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 ...
... peer SHOULD wait for the EAP server to reply before terminating the
conversation. The EAP server MUST reply with an EAP-Failure.
...
... EAP server to reply before terminating the
conversation. The EAP server MUST reply with an EAP-Failure.
When EAP-POTP ...
... EAP-Failure.
When EAP-POTP is run in protected mode, the exchange of the Confirm
TLV (Section 4.11.6) serves as a success result indication; when the
...
... TLV (Section 4.11.6) serves as a success result indication; when the
peer receives a Confirm TLV, it knows that the EAP server has
successfully authenticated it. Similarly, when the EAP server ...
... EAP server has
successfully authenticated it. Similarly, when the EAP server
receives the Confirm TLV response from the peer, it knows that the
...
... peer has authenticated it. In protected mode, the peer will not
accept an EAP-Success packet unless it has received and validated a
Confirm TLV ...
... Confirm TLV. The Confirm TLV sent from the EAP server to the peer is
a "protected result indication" as defined in [1], as it is integrity ...
... protected and cannot be replayed. The Confirm TLV sent from the peer
to the EAP server is, however, not a protected result indication. An
empty EAP-POTP response sent from the peer to the EAP server ...
... to the EAP server is, however, not a protected result indication. An
empty EAP-POTP response sent from the peer to the EAP server serves
as a failure result indication.
...
... EAP server is, however, not a protected result indication. An
empty EAP-POTP response sent from the peer to the EAP server serves
as a failure result indication.
...
... Use of the EAP Notification Method ...
...
Except where explicitly allowed in the following, the EAP
Notification method MUST NOT be used within an EAP-POTP session ...
... Except where explicitly allowed in the following, the EAP
Notification method MUST NOT be used within an EAP-POTP session. The
EAP Notification ...
...
o The EAP server MAY send an EAP-Request of type Notification (2)
when it has received an EAP-Response ...
... EAP-Request of type Notification (2)
when it has received an EAP-Response containing an OTP TLV and is
...
... TLV and is
unable to authenticate the user. In this case, once the EAP-
Response of type Notification is received, the EAP server ...
... EAP-
Response of type Notification is received, the EAP server MAY
retry the authentication and send a new EAP-Request ...
...
o The EAP server MAY send an EAP-Request of type Notification (2)
when it has received an unacceptable New PIN TLV ...
... when it has received an unacceptable New PIN TLV. In this case,
once the EAP-Response of type Notification is received, the EAP
server MAY retry the PIN update ...
... once the EAP-Response of type Notification is received, the EAP
server MAY retry the PIN update and send a new EAP-Request with a
...
... Notification is received, the EAP
server MAY retry the PIN update and send a new EAP-Request with a
New PIN TLV, or it MAY fail the session ...
... brute-force search for an OTP, given an observed EAP-POTP handshake
in protected mode. One way to do this is to do a high number of
...
... 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:
...
... practice, the procedure is as follows:
a. The EAP server indicates in its OTP TLV whether it supports
...
... then a pepper will not be used in the response computation.
c. The EAP server may, in its subsequent Confirm TLV, provide a
pepper to the peer for later use. In this case, the pepper will
...
... lifetime should be limited.
An EAP server that is not capable of storing pepper values for each
user it is authenticating may still support the use of pepper; the
...
... sent. This evidence is a MAC on the hash of (certain parts of) EAP-
POTP messages exchanged so far in a session using a key K_MAC ...
... To compute a message hash for the MAC, given a sequence of EAP
messages msg_1, msg_2, ..., msg_n, the following operations shall be
carried out:
...
... Note: The resulting sequence of messages must be an alternating
sequence of EAP Request and EAP Response messages.
...
... sequence of messages must be an alternating
sequence of EAP Request and EAP Response messages.
b. The contents (i.e., starting ...
...
b. The contents (i.e., starting with the EAP "Type" field and
excluding the EAP "Code", "Identifier ...
... starting with the EAP "Type" field and
excluding the EAP "Code", "Identifier", and "Length" fields) of
each message, msg_1, msg_2, ..., msg_n, is concatenated together.
...
... Identifier" field is that the actual,
transmitted "Identifier" field is not always known to the EAP method
layer ...
... EAP-POTP Packet Format ...
...
A summary of the EAP-POTP packet format is shown below. The fields
are transmitted from left to right.
...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | TLV-based EAP-POTP message ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
The Length field is 2 octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, Version ...
... 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
...
... EAP POTP-X are used to carry parameters between
the EAP peer and the EAP server. An EAP peer may not necessarily
...
... POTP-X are used to carry parameters between
the EAP peer and the EAP server. An EAP peer may not necessarily
implement all the TLVs ...
... the EAP peer and the EAP server. An EAP peer may not necessarily
implement all the TLVs supported by an EAP server ...
... EAP peer may not necessarily
implement all the TLVs supported by an EAP server, and to allow
for interoperability, a special TLV ...
... for interoperability, a special TLV allows an EAP server to
discover if a TLV is supported by the EAP ...
... NAK TLV in response; all
other TLVs in the message MUST be ignored. If an EAP peer or
server finds an unsupported TLV that is marked as non-mandatory
...
... EAP-POTP TLV Objects ...
... 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 ...
... 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 peer. It MUST NOT be present in any subsequent EAP-Request or
EAP-Response in the session. The Version TLV ...
... 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 ...
... 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
...
... 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 ...
... 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 ...
... 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 ...
... 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 ...
... 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.
...
...
The Server-Info TLV carries information about the EAP server and the
session (when applicable). It provides one piece in the framework ...
... 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 ...
... 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
...
... server. The value of the identifier SHOULD be chosen so as to
reduce the risk of collisions with other EAP server