3. TEAP Protocol
This section preserves the RFC text for TEAPv1, including TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations, and examples.
3. TEAP Protocol
The operation of the protocol, including Phase 1 and Phase 2, is the
topic of this section. The format of TEAP messages is given in
Section 4, and the cryptographic calculations are given in Section 6.
3.1. Version Negotiation
TEAP packets contain a 3-bit Version field, following the TLS Flags
field, which enables future TEAP implementations to be backward
compatible with previous versions of the protocol. This
specification documents the TEAP version 1 protocol; implementations
of this specification MUST use a Version field set to 1.
Version negotiation proceeds as follows:
1. In the first EAP-Request sent with EAP type=TEAP, the EAP server
MUST set the Version field to the highest version it supports.
2. If the EAP peer supports this version of the protocol, it
responds with an EAP-Response of EAP type=TEAP, including the
version number proposed by the TEAP server.
3. If the TEAP peer does not support the proposed version but
supports a lower version, it responds with an EAP-Response of EAP
type=TEAP and sets the Version field to its highest supported
version.
4. If the TEAP peer only supports versions higher than the version
proposed by the TEAP server, then use of TEAP will not be
possible. In this case, the TEAP peer sends back an EAP-Nak
either to negotiate a different EAP type or to indicate no other
EAP types are available.
5. If the TEAP server does not support the version number proposed
by the TEAP peer, it MUST either terminate the conversation with
an EAP Failure or negotiate a new EAP type.
6. If the TEAP server does support the version proposed by the TEAP
peer, then the conversation continues using the version proposed
by the TEAP peer.
The version negotiation procedure guarantees that the TEAP peer and
server will agree to the latest version supported by both parties.
If version negotiation fails, then use of TEAP will not be possible,
and another mutually acceptable EAP method will need to be negotiated
if authentication is to proceed.
The TEAP version is not protected by TLS and hence can be modified in
transit. In order to detect a bid-down attack on the TEAP version,
the peers MUST exchange the TEAP version number received during
version negotiation using the Crypto-Binding TLV described in
Section 4.2.13. The receiver of the Crypto-Binding TLV MUST verify
that the version received in the Crypto-Binding TLV matches the
version sent by the receiver in the TEAP version negotiation.
Intermediate results are signaled via the Intermediate-Result TLV
(Section 4.2.11). However, the Crypto-Binding TLV MUST be validated
before any Intermediate-Result TLV or Result TLV is examined. If the
Crypto-Binding TLV fails to be validated for any reason, then it is a
fatal error and is handled as described in Section 3.9.3.
The true success or failure of TEAP is conveyed by the Result TLV
with value Success or Failure. However, as EAP terminates with
either a cleartext EAP Success or Failure, a peer will also receive a
cleartext EAP Success or Failure. The received cleartext EAP Success
or Failure MUST match that received in the Result TLV; the peer
SHOULD silently discard those cleartext EAP Success or Failure
messages that do not coincide with the status sent in the protected
Result TLV.
3.2. TEAP Authentication Phase 1: Tunnel Establishment
TEAP relies on the TLS handshake [RFC8446] to establish an
authenticated and protected tunnel. The TLS version offered by the
peer and server MUST be TLS version 1.2 [RFC5246] or later. This
version of the TEAP implementation MUST support the following TLS
cipher suites:
* TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Other cipher suites MAY be supported. Implementations MUST implement
the recommended cipher suites in [RFC9325], Section 4.2 for TLS 1.2
and in [RFC8446], Section 9.1 for TLS 1.3.
It is REQUIRED that anonymous cipher suites such as
TLS_DH_anon_WITH_AES_128_CBC_SHA [RFC5246] only be used in the case
when the Inner Method provides mutual authentication, key generation,
and resistance to on-path and dictionary attacks. TLS cipher suites
that do not provide confidentiality MUST NOT be used. During the
TEAP Phase 1, the TEAP endpoints MAY negotiate TLS compression.
During TLS tunnel establishment, TLS extensions MAY be used. For
instance, the Certificate Status Request extension [RFC6066] and the
Multiple Certificate Status Request extension [RFC6961] can be used
to leverage a certificate-status protocol such as the Online
Certificate Status Protocol (OCSP) [RFC6960] to check the validity of
server certificates. TLS renegotiation indications defined in
[RFC5746] MUST be supported.
Use of TLS-PSK is NOT RECOMMENDED. TEAP has not been designed to
work with TLS-PSK, and no use cases, security analyses, or
implementations have been done. TLS-PSK may work (or not) with TEAP,
depending on the status of a particular implementation, and it is
therefore not useful to deploy it.
The EAP server initiates the TEAP conversation with an EAP request
containing a TEAP/Start packet. This packet includes a set Start (S)
bit, the TEAP version as specified in Section 3.1, and an authority
identity TLV. The TLS payload in the initial packet is empty. The
authority identity TLV (Authority-ID TLV) is used to provide the peer
a hint of the server's identity that may be useful in helping the
peer select the appropriate credential to use. Assuming that the
peer supports TEAP, the conversation continues with the peer sending
an EAP-Response packet with EAP type of TEAP with the Start (S) bit
clear and the version as specified in Section 3.1. This message
encapsulates one or more TLS handshake messages. If the TEAP version
negotiation is successful, then the TEAP conversation continues until
the EAP server and EAP peer are ready to enter Phase 2. When the
full TLS handshake is performed, then the first payload of TEAP Phase
2 MAY be sent along with a server-finished handshake message to
reduce the number of round trips.
TEAP implementations MUST support mutual peer authentication during
tunnel establishment using the TLS cipher suites specified in this
section. The TEAP peer does not need to authenticate as part of the
TLS exchange but can alternatively be authenticated through
additional exchanges carried out in Phase 2.
The TEAP tunnel protects peer identity information exchanged during
Phase 2 from disclosure outside the tunnel. Implementations that
wish to provide identity privacy for the peer identity need to
carefully consider what information is disclosed outside the tunnel
prior to Phase 2. TEAP implementations SHOULD support the immediate
renegotiation of a TLS session to initiate a new handshake message
exchange under the protection of the current cipher suite. This
allows support for protection of the peer's identity when using TLS
client authentication. An example of the exchanges using TLS
renegotiation to protect privacy is shown in Appendix C.
3.3. Server Certificate Requirements
Server certificates MUST include a subjectAltName extension, with the
dnsName attribute containing a Fully Qualified Domain Name (FQDN)
string. Server certificates MAY also include a SubjectDN containing
a single element, "CN=", which contains the FQDN of the server.
However, this use of SubjectDN is deprecated for TEAP and is
forbidden in [RFC9525], Section 2.
The KeyUsage extensions MAY be included but are not required.
The Extended Key Usage extensions defined in [RFC5280] MAY also be
included, but their use is discouraged. Systems SHOULD use a private
Certification Authority (CA) for EAP in preference to public CAs.
The most commonly used public CAs are focused on the web, and those
certificates are not always suitable for use with EAP. In contrast,
private CAs can be designed for any purposes and can be restricted to
an enterprise or an other organization.
3.4. Server Certificate Validation
As part of the TLS negotiation, the server usually presents a
certificate to the peer. In most cases, the certificate needs to be
validated, but there are a number of situations where the EAP peer
does not need to do certificate validation:
* when the peer has the server's End Entity (EE) certificate pinned
or loaded directly into it's trusted anchor information [RFC4949];
* when the peer is requesting server unauthenticated provisioning;
* when the peer is certain that it will be using an authenticated
Inner Method.
In some cases, such as onboarding (or "bootstrapping"), the
certificate validation may be delayed. However, once the onboarding
has taken place, the validation steps described below MUST still be
performed.
In all other cases, the EAP peer MUST validate the server
certificate. This validation is done in the same manner as is done
for EAP-TLS, which is discussed in [RFC9190], Section 5.3 and in
[RFC5216], Section 5.3. Further guidance on server identity
validation can be found in [RFC9525], Section 6.
Where the EAP peer has an NAI, EAP peers MUST use the realm to
perform the DNS-ID validation as per [RFC9525], Section 6. The realm
is used both to construct the list of reference identifiers as
defined in [RFC9525], Section 6, and as the "source domain" field of
that same section.
When performing server certificate validation, implementations MUST
also support the rules in [RFC5280] for validating certificates
against a known trust anchor. In addition, implementations MUST
support matching the realm portion of the peer's NAI against a
SubjectAltName of type dnsName within the server certificate.
However, in certain deployments, this comparison might not be
appropriate or enabled.
In most situations, the EAP peer will have no network access during
the authentication process. It will therefore have no way of
correlating the server identity given in the certificate presented by
the EAP server with a hostname, as is done with other protocols such
as HTTPS. Therefore, if the EAP peer has no preconfigured trust
anchor, it will have few, if any, ways of validating the server's
certificate.
3.4.1. Client Certificates Sent During Phase 1
Note that since TLS client certificates are sent in the clear with
TLS 1.2, if identity protection is required, then it is possible for
the TLS authentication to be renegotiated after the first server
authentication. To accomplish this, the server will typically not
request a certificate in the server_hello; then, after the
server_finished message is sent and before TEAP Phase 2, the server
MAY send a TLS hello_request. This allows the peer to perform client
authentication by sending a client_hello if it wants to or sending a
no_renegotiation alert to the server indicating that it wants to
continue with TEAP Phase 2 instead. Assuming that the peer permits
renegotiation by sending a client_hello, then the server will respond
with server_hello, certificate, and certificate_request messages.
The peer replies with certificate, client_key_exchange, and
certificate_verify messages. Since this renegotiation occurs within
the encrypted TLS channel, it does not reveal client certificate
details. It is possible to perform certificate authentication using
EAP (for example, EAP-TLS) within the TLS session in TEAP Phase 2
instead of using TLS handshake renegotiation.
When TLS 1.3 or later is used, it is RECOMMENDED that client
certificates are sent in Phase 1 instead of via Phase 2 and EAP-TLS.
Doing so will reduce the number of round trips. Further discussion
of this issue is given below in Section 3.6.5
3.5. Resumption
For resumption, [RFC9190], Section 5.7 discusses EAP-TLS resumption
for all versions of TLS and is incorporated herein by reference.
[RFC9427], Section 4 is also incorporated by reference, as it
provides generic discussion of resumption for TLS-based EAP methods
when TLS 1.3 is used.
This document only describes TEAP issues when resumption is used for
TLS versions of 1.2 and earlier. It also describes resumption issues
that are specific to TEAP for TLS 1.3.
If the server agrees to resume the session, Phase 2 is bypassed
entirely. If the server does not agree to resume the session, then
the server rejects the resumption as per [RFC9190], Section 5.7. It
then continues with a full handshake. After the full TLS handshake
has completed, both EAP server and peer MUST proceed with Phase 2.
All TEAP implementations MUST support resumption. Using resumption
can significantly improve the scalability and stability of
authentication systems. For example, some environments such as
universities may have users re-authenticating multiple times a day,
if not hourly. Failure to implement resumption would increase the
load on the user database by orders of magnitude, leading to
unnecessary cost.
The following sections describe how a TEAP session can be resumed
based on server-side or client-side state.
3.5.1. TLS Session Resumption Using Server State
TEAP session resumption is achieved in the same manner TLS achieves
session resumption. To support session resumption, the server and
peer cache the Session ID, master secret, and cipher suite. The peer
attempts to resume a session by including a valid Session ID from a
previous TLS handshake in its ClientHello message. If the server
finds a match for the Session ID and is willing to establish a new
connection using the specified session state, the server will respond
with the same Session ID and proceed with the TEAP Phase 1 tunnel
establishment based on a TLS abbreviated handshake.
3.5.2. TLS Session Resumption Using Client State
TEAP supports the resumption of sessions based on the state being
stored on the client side using the TLS SessionTicket extension
techniques described in [RFC5077] and [RFC9190].
3.6. TEAP Authentication Phase 2: Tunneled Authentication
The second portion of the TEAP authentication occurs immediately
after successful completion of Phase 1. Phase 2 occurs even if both
peer and authenticator are authenticated in the Phase 1 TLS
negotiation. Phase 2 MUST NOT occur if the Phase 1 TLS handshake
fails, as that will compromise the security as the tunnel has not
been established successfully. Phase 2 consists of a series of
requests and responses encapsulated in TLV objects defined in
Section 4.2. Phase 2 MUST always end with a Crypto-Binding TLV
exchange described in Section 4.2.13 and a protected termination
exchange described in Section 3.6.6.
If the peer is not authenticated in Phase 1, the TEAP peer SHOULD
send one or more Identity-Hint TLVs (Section 4.2.20) as soon as the
TLS connection has been established. This information lets the TEAP
server choose an authentication type that is appropriate for that
identity. When the TEAP peer does not provide an Identity-Hint TLV,
the TEAP server does not know which Inner Method is supported by the
peer. It must choose an Inner Method and propose it to the peer,
which may reject that Inner Method. As a result, the peer fails to
authenticate and fails to obtain network access.
The TLV exchange includes the execution of zero or more inner methods
within the protected tunnel as described in Sections 3.6.2 and 3.6.3.
A server MAY proceed directly to the protected termination exchange
without performing any inner authentication if it does not wish to
request further authentication from the peer. A server MAY request
one or more authentications within the protected tunnel. After
completion of each Inner Method, the server decides whether or not to
begin another Inner Method or to send a Result TLV.
Implementations MUST support at least two sequential Inner Methods,
which allows both machine and user authentication to be performed.
Implementations SHOULD also limit the number of sequential inner
authentications, as there is no reason to perform a large number of
inner authentications in one TEAP conversation.
Implementations wishing to use their own proprietary authentication
method may substitute the EAP-Payload or Basic-Password-Auth-Req TLV
for the Vendor-Specific TLV, which carries another authentication
method. Any vendor-specific authentication method MUST support
calculation of the Crypto-Binding TLV and MUST use Intermediate-
Result TLV and Result TLV as is done with other authentication
methods.
3.6.1. Inner Method Ordering
Due to issues noted in Section 5, the order of Inner Methods has
implications for both security and interoperability.
Where the authentication is expected to use multiple Inner Methods,
implementations SHOULD order the methods so that a method that
derives an Extended Master Session Key (EMSK) is used first before
any other method. This ordering helps to securely tie the Inner
Method to the TLS session and therefore can prevent attacks.
Implementations SHOULD support both EAP and basic password
authentication for inner methods. Implementations that support
multiple types of Inner Methods (User and Machine) MUST support all
of those methods in any order or combination. That is, it is
explicitly permitted to "mix and match" Inner Methods.
For example, a server can request user authentication from the peer
and have the peer return machine authentication (or vice versa). If
the server is configured to accept machine authentication, it MUST
accept that response. If that authentication succeeds, then
depending on local policy, the server SHOULD proceed with requesting
user authentication again.
Similarly, a peer that is configured to support multiple types of
Inner Methods (User and Machine) can return a method other than what
the server requested. This action is usually taken by the peer so
that it orders Inner Methods for increased security. See
Section 6.2.3 for further discussion of this issue.
However, the peer and server MUST NOT assume that either will skip
Inner Methods or other TLV exchanges, as the other peer might have a
different security policy. The peer may have roamed to a network
that requires conformance with a different authentication policy, or
the peer may request the server take additional action (e.g., channel
binding) through the use of the Request-Action TLV as defined in
Section 4.2.9.
The completion of each Inner Method is signaled by an Intermediate-
Result TLV. Where the Intermediate-Result TLV indicates failure, an
Error TLV SHOULD also be included using the most descriptive error
code possible. The Intermediate-Result TLV may be accompanied by
another TLV indicating that the server wishes to perform a subsequent
authentication. When all Inner Methods have completed, the server
MUST send a Result TLV indicating success or failure instead of a TLV
that carries an Inner Method.
3.6.2. Inner EAP Authentication
EAP [RFC3748] prohibits use of multiple authentication methods within
a single EAP conversation in order to limit vulnerabilities to on-
path attacks. TEAP addresses on-path attacks through support for
cryptographic protection of the inner EAP exchange and cryptographic
binding of the inner EAP method(s) to the protected tunnel. Inner
Methods are executed serially in a sequence. This version of TEAP
does not support initiating multiple Inner Methods simultaneously in
parallel. The Inner Methods need not be distinct. For example, EAP-
TLS ([RFC5216] and [RFC9190]) could be run twice as an inner method,
first using machine credentials, followed by a second instance using
user credentials.
When EAP is used as an Inner Method, the EAP messages are carried
within EAP-Payload TLVs defined in Section 4.2.10. Note that in this
use case, TEAP is simply a carrier for EAP, much as RADIUS is a
carrier for EAP. The full EAP state machine runs as normal and is
carried over the EAP-Payload TLV. Each distinct EAP authentication
MUST be managed as a separate EAP state machine.
A TEAP server therefore MUST begin an EAP authentication with an EAP-
Request/Identity (carried in an EAP-Payload TLV). However, a TEAP
server MUST NOT finish the EAP conversation with an EAP Success or
EAP Failure packet; the Intermediate-Result TLV is used instead.
Upon completion of each EAP authentication in the tunnel, the server
MUST send an Intermediate-Result TLV indicating the result of that
authentication. When the result indicates success, it MUST be
accompanied by a Crypto-Binding TLV. The peer MUST respond to the
Intermediate-Result TLV indicating its own result. Similarly, upon
success, the peer MUST accompany the TLV with its own Crypto-Binding
TLV. The peer MUST respond to the Intermediate-Result TLV indicating
its own result and similarly on success MUST accompany the TLV with
its own Crypto-Binding TLV. The Crypto-Binding TLV is further
discussed in Sections 4.2.13 and 6.3. The Intermediate-Result TLVs
can be included with other TLVs that indicate a subsequent
authentication or with the Result TLV used in the protected
termination exchange.
If both peer and server indicate success, then the authentication is
considered successful. If either indicates failure, then the
authentication is considered failed. The result of failure of an EAP
authentication does not always imply a failure of the overall
authentication. If one Inner Method fails, the server may attempt to
authenticate the peer with a different method (EAP or password).
3.6.3. Inner Password Authentication
The authentication server (AS) initiates password authentication by
sending a Basic-Password-Auth-Req TLV defined in Section 4.2.14. If
the peer wishes to participate in password authentication, then it
responds with a Basic-Password-Auth-Resp TLV that contains the
username and password as defined in Section 4.2.15. If it does not
wish to perform password authentication, then it responds with a
Negative Acknowledgment (NAK) TLV indicating the rejection of the
Basic-Password-Auth-Req TLV.
The basic password authentication defined here is similar in
functionality to that used by EAP-TTLS [RFC5281] with inner password
authentication. It shares a similar security and risk analysis.
Multiple round trips of password authentication requests and
responses MAY be used to support some "housekeeping" functions such
as a password or pin change before a user is considered to be
authenticated. Multiple rounds MAY also be used to communicate a
user's password and, separately, a one-time password such as Time-
Based One-Time Passwords (TOTPs) [RFC6238].
Implementations MUST limit the number of round trips for password
authentication. It is reasonable to use one or two round trips.
Further round trips are likely to be problematic and SHOULD be
avoided.
The first Basic-Password-Auth-Req TLV received in a session MUST
include a prompt, which the peer displays to the user. Subsequent
authentication rounds SHOULD include a prompt, but it is not always
necessary.
When the peer first receives a Basic-Password-Auth-Req TLV, it should
allow the user to enter both a username and a password, which are
then placed in the Basic-Password-Auth-Resp TLV. If the peer
receives subsequent Basic-Password-Auth-Req TLVs in the same
authentication session, it MUST NOT prompt for a username and MUST
instead allow the user to enter only a password. The peer MUST copy
the username used in the first Basic-Password-Auth-Resp TLV into all
subsequent Basic-Password-Auth-Resp TLVs.
Servers MUST track the username across multiple password rounds and
reject authentication if the identity changes from one Basic-
Password-Auth-Resp TLV to the next. There is no reason for a user
(or machine) to change identities in the middle of authentication.
Upon reception of a Basic-Password-Auth-Resp TLV in the tunnel, the
server MUST send an Intermediate-Result TLV indicating the result.
The peer MUST respond to the Intermediate-Result TLV indicating its
result. If the result indicates success, the Intermediate-Result TLV
MUST be accompanied by a Crypto-Binding TLV. The Crypto-Binding TLV
is further discussed in Sections 4.2.13 and 6.3.
The Intermediate-Result TLVs can be included with other TLVs that
indicate a subsequent authentication or with the Result TLV used in
the protected termination exchange.
The use of EAP-FAST-GTC as defined in [RFC5421] is NOT RECOMMENDED
with TEAPv1 because EAP-FAST-GTC is not compliant with EAP-GTC
defined in [RFC3748]. Implementations should instead make use of the
password authentication TLVs defined in this specification.
3.6.4. EAP-MSCHAPv2
If using EAP-MSCHAPv2 [KAMATH] as an inner EAP method, the EAP-FAST-
MSCHAPv2 variant defined in [RFC5422], Section 3.2.3 MUST be used
instead of the derivation defined in [MSCHAP].
The difference between EAP-MSCHAPv2 and EAP-FAST-MSCHAPv2 is that the
first and the second 16 octets of the EAP-MSCHAPv2 Master Session Key
(MSK) are swapped when it is used as the Inner Method Session Keys
(IMSKs) for TEAP.
3.6.5. Limitations on Inner Methods
Implementations SHOULD limit the permitted inner EAP methods to a
small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of EAP-
MSCHAPv2. These EAP methods are the most commonly supported inner
methods in TEAP and are known to be interoperable among multiple
implementations.
Other EAP methods such as EAP-pwd, EAP-SIM, EAP-AKA, or EAP-AKA' can
be used within a TEAP tunnel. Any EAP method that derives both MSK
and EMSK is likely to work as an Inner Method for TEAP, because EAP-
TLS has that behavior and it works. EAP methods that derive only MSK
should work, as EAP-FAST-MSCHAPv2 has that behavior, and it works.
Other EAP methods are untested and may or may not work.
Tunneled EAP methods such as PEAP [PEAP], EAP-TTLS [RFC5281], and
EAP-FAST [RFC4851] MUST NOT be used for inner EAP authentication.
There is no reason to have multiple layers of TLS in order to protect
a password exchange.
The EAP methods defined in [RFC3748], Section 5, such as
MD5-Challenge, One-Time Password (OTP), and Generic Token Card (GTC),
do not derive an MSK or an EMSK and are vulnerable to on-path
attacks. The construction of the OTP and GTC methods makes this
attack less relevant, as the information being sent is generally a
one-time token. However, EAP-OTP and EAP-GTC offer no benefit over
the basic password authentication defined in Section 3.6.3, which
also does not perform crypto-binding of the Inner Method to the TLS
session. These EAP methods are therefore not useful as Phase 2
methods within TEAP.
Other EAP methods are less widely used and highly likely to not work
as the inner EAP method for TEAP.
In order to protect from on-path attacks, TEAP implementations MUST
NOT permit the use of inner EAP methods that fail to perform crypto-
binding of the Inner Method to the TLS session.
Implementations MUST NOT permit resumption for the inner EAP methods
such as EAP-TLS. If the user or machine needs to be authenticated,
it should use a method that provides full authentication. If the
user or machine needs to do resumption, it can perform a full
authentication once and then rely on the outer TLS session for
resumption. This restriction applies also to all TLS-based EAP
methods that can tunnel other EAP methods. As a result, this
document updates [RFC9427].
In general, the reason to use a non-TLS-based EAP method inside of a
TLS-based EAP method such as TEAP is for privacy. Many previous EAP
methods may leak information about user identity, and those leaks are
prevented by running the method inside of a protected TLS tunnel.
EAP-TLS is permitted in Phase 2 for two use cases. The first use
case is when TLS 1.2 is used, as the client certificate is not
protected as with TLS 1.3. It is therefore RECOMMENDED that when TLS
1.3 is used for the outer TEAP exchange, the client certificate is
sent in Phase 1 instead of doing EAP-TLS in Phase 2. This behavior
will simplify the authentication exchange and use fewer round trips
than doing EAP-TLS inside of TEAP.
The second use case for EAP-TLS in Phase 2 is where both the user and
machine use client certificates for authentication. Since TLS
permits only one client certificate to be presented, only one
certificate can be used in Phase 1. The second certificate is then
presented via EAP-TLS in Phase 2.
For basic password authentication, it is RECOMMENDED that this method
be only used for the exchange of one-time passwords. The existence
of password-based EAP methods such as EAP-pwd ([RFC5931] and
[RFC8146]) makes most cleartext password exchanges unnecessary. The
updates to EAP-pwd in [RFC8146] permit it to be used with databases
that store passwords in "salted" form, which greatly increases
security.
Where no Inner Method provides an EMSK, the Crypto-Binding TLV offers
little protection, as it cannot tie the inner EMSK to the TLS session
via the TLS-PRF. As a result, the TEAP session will be vulnerable to
on-path active attacks. Implementations and deployments SHOULD adopt
various mitigation strategies described in [RFC7029], Section 3.2.
Implementations also need to implement the Inner Method ordering
described in Section 6.1 in order to fully prevent on-path attacks.
3.6.6. Protected Termination and Acknowledged Result Indication
A successful TEAP Phase 2 conversation MUST always end in a
successful Crypto-Binding TLV and Result TLV exchange. A TEAP server
may initiate the Crypto-Binding TLV and Result TLV exchange without
initiating any Inner Methods in TEAP Phase 2. After the final Result
TLV exchange, the TLS tunnel is terminated, and a cleartext EAP
Success or EAP Failure is sent by the server. Peers implementing
TEAP MUST NOT accept a cleartext EAP Success or Failure packet prior
to the peer and server reaching synchronized protected result
indication.
The Crypto-Binding TLV exchange is used to prove that both the peer
and server participated in the tunnel establishment and sequence of
authentications. It also provides verification of the TEAP type,
version negotiated, and Outer TLVs exchanged before the TLS tunnel
establishment. Except as noted below, the Crypto-Binding TLV MUST be
exchanged and verified before the final Result TLV exchange,
regardless of whether or not there is an Inner Method. The Crypto-
Binding TLV and Intermediate-Result TLV MUST be included to perform
cryptographic binding after each successful authentication in a
sequence of one or more Inner Methods. The server may send the final
Result TLV along with an Intermediate-Result TLV and a Crypto-Binding
TLV to indicate its intention to end the conversation. If the peer
requires nothing more from the server, it will respond with a Result
TLV indicating success accompanied by a Crypto-Binding TLV and
Intermediate-Result TLV if necessary. The server then tears down the
tunnel and sends a cleartext EAP Success or EAP Failure.
If the peer receives a Result TLV indicating success from the server,
but its authentication policies are not satisfied (for example, it
requires a particular authentication mechanism to be run), it may
request further action from the server using the Request-Action TLV.
The Request-Action TLV is sent with a Status field indicating what
EAP Success/Failure result the peer would expect if the requested
action is not granted. The value of the Action field indicates what
the peer would like to do next. The format and values for the
Request-Action TLV are defined in Section 4.2.9.
Upon receiving the Request-Action TLV, the server may process the
request or ignore it, based on its policy. If the server ignores the
request, it proceeds with termination of the tunnel and sends the
cleartext EAP Success or Failure message based on the Status field of
the peer's Request-Action TLV. If the server honors and processes
the request, it continues with the requested action. The
conversation completes with a Result TLV exchange. The Result TLV
may be included with the TLV that completes the requested action.
Error handling for Phase 2 is discussed in Section 3.9.3.
3.7. Determining Peer-Id and Server-Id
The Peer-Id and Server-Id [RFC5247] may be determined based on the
types of credentials used during either the TEAP tunnel creation or
authentication. In the case of multiple peer authentications, all
authenticated peer identities and their corresponding identity types
(Section 4.2.3) need to be exported. In the case of multiple server
authentications, all authenticated server identities need to be
exported.
When X.509 certificates are used for peer authentication, the Peer-Id
is determined by the subject and subjectAltName fields in the peer
certificate. As noted in [RFC5280]:
| The subject field identifies the entity associated with the public
| key stored in the subject public key field. The subject name MAY
| be carried in the subject field and/or the subjectAltName
| extension. . . . If subject naming information is present only in
| the subjectAltName extension (e.g., a key bound only to an email
| address or URI), then the subject name MUST be an empty sequence
| and the subjectAltName extension MUST be critical.
|
| Where it is non-empty, the subject field MUST contain an X.500
| distinguished name (DN).
If an inner EAP authentication method is run, then the Peer-Id is
obtained from that inner EAP authentication method.
When the server uses an X.509 certificate to establish the TLS
tunnel, the Server-Id is determined in a similar fashion as stated
above for the Peer-Id, e.g., the subject and subjectAltName fields in
the server certificate define the Server-Id.
3.8. TEAP Session Identifier
For TLS 1.2 and earlier, the EAP session identifier [RFC5247] is
constructed using the tls-unique from the Phase 1 outer tunnel at the
beginning of Phase 2 as defined by Section 3.1 of [RFC5929]. The
Session-Id is defined as follows:
Session-Id = teap_type | tls-unique
Where:
* | denotes concatenation,
* teap_type is the EAP Type assigned to TEAP, and
* tls-unique = tls-unique from the Phase 1 outer tunnel at the
beginning of Phase 2 as defined by Section 3.1 of [RFC5929].
The Session-Id derivation for TLS 1.3 is given in [RFC9427],
Section 2.1
3.9. Error Handling
TEAP uses the error-handling rules summarized below:
1. Errors in the outer EAP packet layer are handled as defined in
Section 3.9.1.
2. Errors in the TLS layer are communicated via TLS alert messages
in both phases of TEAP.
3. The Intermediate-Result TLVs carry success or failure indications
of the individual Inner Methods in TEAP Phase 2. Errors within
an EAP conversation in Phase 2 are expected to be handled by the
individual EAP authentication methods.
4. Violations of the Inner TLV rules are handled using Result TLVs
together with Error TLVs.
5. Tunnel-compromised errors (errors caused by a failed or missing
Crypto-Binding) are handled using Result TLVs and Error TLVs.
3.9.1. Outer-Layer Errors
Errors on the TEAP outer-packet layer are handled in the following
ways:
1. If Outer TLVs are invalid or contain unknown values, they will be
ignored.
2. The entire TEAP packet will be ignored if other fields (version,
length, flags, etc.) are inconsistent with this specification.
3.9.2. TLS Layer Errors
If the TEAP server detects an error at any point in the TLS handshake
or the TLS layer, the server SHOULD send a TEAP request encapsulating
a TLS record containing the appropriate TLS alert message rather than
immediately terminating the TEAP exchange so as to allow the peer to
inform the user of the cause of the failure. The TEAP peer MUST send
a TEAP response to an alert message. The EAP-Response packet sent by
the peer SHOULD contain a TEAP response with a zero-length message.
The server MUST terminate the TEAP exchange with an EAP Failure
packet no matter what the client says.
If the TEAP peer detects an error at any point in the TLS layer, the
TEAP peer SHOULD send a TEAP response encapsulating a TLS record
containing the appropriate TLS alert message, which contains a zero-
length message. The server then MUST terminate the conversation with
an EAP failure as discussed in the previous paragraph.
While TLS 1.3 [RFC8446] allows for the TLS conversation to be
restarted, it is not clear when that would be useful (or used) for
TEAP. Fatal TLS errors will cause the TLS conversation to fail.
Non-fatal TLS errors can likely be ignored entirely. As a result,
TEAP implementations MUST NOT permit TLS restarts.
3.9.3. Phase 2 Errors
There are a large number of situations where errors can occur during
Phase 2 processing. This section describes both errors and the
recommended processing of them.
When the server receives a Result TLV with a fatal Error TLV from the
peer, it MUST terminate the TLS tunnel and reply with an EAP Failure.
When the peer receives a Result TLV with a fatal Error TLV from the
server, it MUST respond with a Result TLV indicating failure. The
server MUST discard any data it receives from the peer and reply with
an EAP Failure. The final message from the peer is required by the
EAP state machine and serves only to allow the server to reply to the
peer with the EAP Failure.
The following items describe specific errors and processing in more
detail.
Fatal Error processing a TLV:
Any time the peer or the server finds a fatal error outside of the
TLS layer during Phase 2 TLV processing, it MUST send a Result TLV
of failure and an Error TLV using the most descriptive error code
possible.
Fatal Error during TLV Exchanges:
For errors involving the processing of the sequence of exchanges,
such as a violation of TLV rules (e.g., multiple EAP-Payload
TLVs), the error code is Unexpected TLVs Exchanged.
Fatal Error due to tunnel compromise:
For errors involving a tunnel compromise, such as when the Crypto-
Binding TLV fails validation, the error code is Tunnel Compromise
Error.
Non-Fatal Error due to Inner Method:
If there is a non-fatal error while running the Inner Method, the
receiving side SHOULD NOT silently drop the Inner Method exchange.
Instead, it SHOULD reply with an Error TLV using the most
descriptive error code possible.
If there is no error code that matches the particular issue, then
the value Inner Method Error (1001) SHOULD be used. This response
is a positive indication that there was an error processing the
current Inner Method. The side receiving a non-fatal Error TLV
MAY decide to start a new and different Inner Method instead or
send back a Result TLV to terminate the TEAP authentication
session.
3.10. Fragmentation
Fragmentation of EAP packets is discussed in [RFC5216],
Section 2.1.5. There is no special handling of fragments for TEAP.
3.11. Services Requested by the Peer
Several TEAP operations, including server unauthenticated
provisioning, certificate provisioning, and channel binding, depend
on the peer trusting the TEAP server. If the peer trusts the
provided server certificate, then the server is authenticated.
Typically, this authentication process involves the peer validating
the certificate to a trust anchor by verifying that the server
presenting the certificate holds the private key and confirming that
the entity named by the certificate is the intended server. Server
authentication also occurs when the procedures in Section 3.2 are
used to resume a session where the peer and server were previously
mutually authenticated. Alternatively, the server is deemed to be
authenticated if an inner EAP method provides mutual authentication
along with an MSK and/or EMSK. The Inner Method MUST also provide
for cryptographic binding via the Compound Message Authentication
Code (MAC), as discussed in Section 4.2.13. This issue is further
described in Section 3.11.3.
TEAP peers MUST track whether or not server authentication has taken
place. When the server cannot be authenticated, the peer MUST NOT
request any services such as certificate provisioning
(Section 3.11.1) from it.
Unless the peer requests server unauthenticated provisioning, it MUST
authenticate the server and fail the current authentication session.
The authentication session fails if the server cannot be
authenticated.
An additional complication arises when an Inner Method authenticates
multiple parties, such as authenticating both the peer machine and
the peer user to the EAP server. Depending on how authentication is
achieved, only some of these parties may have confidence in it. For
example, if a strong shared secret is used to mutually authenticate
the user and the EAP server, the machine may not have confidence that
the EAP server is the authenticated party if the machine cannot trust
the user not to disclose the shared secret to an attacker. In these
cases, the parties who participate in the authentication need to be
considered when evaluating whether the peer should request these
services or whether the server should provide them.
The server MUST also authenticate the peer before providing these
services. The alternative is to send provisioning data to
unauthenticated and potentially malicious peers, which can have
negative impacts on security.
When a device is provisioned via TEAP, any subsequent authorization
MUST be done on the authenticated credentials. That is, there may be
no credentials (or anonymous credentials) passed in Phase 1, but
there will be credentials passed or provisioned in Phase 2. If later
authorizations are done on the Phase 1 identity, then a device could
obtain the wrong authorization. If authorization is done on the
authenticated credentials instead, then the device will obtain the
correct kind of network access.
The correct authorization must also be applied to any resumption, as
noted in [RFC9190], Section 5.7. However, as it is possible in TEAP
for the credentials to change, the new credentials MUST be associated
with the session ticket. If this association cannot be done, then
the server MUST invalidate any session tickets for the current
session. This invalidation will force a full re-authentication on
any subsequent connection; at which point, the correct authorization
will be associated with any session ticket.
Note that the act of re-provisioning a device is essentially
indistinguishable from any initial provisioning. The device
authenticates and obtains new credentials via the standard
provisioning mechanisms. The only caveat is that the device SHOULD
NOT discard the old credentials unless either they are known to have
expired or the new credentials have been verified to work.
3.11.1. Certificate Provisioning Within the Tunnel
Provisioning of a peer's certificate is supported in TEAP by
performing the Simple PKI Request/Response from [RFC5272] using
PKCS#10 and PKCS#7 TLVs, respectively. A peer sends the Simple PKI
Request using a PKCS#10 CertificationRequest [RFC2986] encoded into
the body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server
issues a Simple PKI Response using a PKCS#7 [RFC2315] unsigned (i.e.,
degenerate) "Certificates Only" message encoded into the body of a
PKCS#7 TLV (see Section 4.2.16) only after an Inner Method has run
and provided an identity proof on the peer prior to a certificate is
being issued.
In order to provide linking identity and proof-of-possession by
including information specific to the current authenticated TLS
session within the signed certification request, the peer generating
the request SHOULD obtain the tls-unique value from the TLS subsystem
as defined in "Channel Bindings for TLS" [RFC5929]. The TEAP peer
operations between obtaining the tls-unique value through generation
of the Certification Signing Request (CSR) that contains the current
tls-unique value and the subsequent verification of this value by the
TEAP server are the "phases of the application protocol during which
application-layer authentication occurs" that are protected by the
synchronization interoperability mechanism described in the
interoperability note in "Channel Bindings for TLS" ([RFC5929],
Section 3.1). When performing renegotiation, TLS
"secure_renegotiation" [RFC5746] MUST be used.
The tls-unique value is base-64-encoded as specified in Section 4 of
[RFC4648], and the resulting string is placed in the certification
request challengePassword field ([RFC2985], Section 5.4.1). The
challengePassword field is limited to 255 octets (Section 7.4.9 of
[RFC5246] indicates that no existing cipher suite would result in an
issue with this limitation). If tls-unique information is not
embedded within the certification request, the challengePassword
field MUST be empty to indicate that the peer did not include the
optional channel-binding information (any value submitted is verified
by the server as tls-unique information).
The server SHOULD verify the tls-unique information. This ensures
that the signed certificate request is being presented by an
authenticated TEAP peer that is in possession of the private key.
The Simple PKI Request/Response generation and processing rules of
[RFC5272] SHALL apply to TEAP, with the exception of error
conditions. In the event of an error, the TEAP server SHOULD respond
with an Error TLV using the most descriptive error code possible; it
MAY ignore the PKCS#10 request that generated the error.
3.11.2. Certificate Content and Uses
It is not enough to verify that the CSR provided by the peer to the
authenticator is from an authenticated user. The CSR itself should
also be examined by the authenticator or CA before any certificate is
issued.
The format of a CSR is complex and contains a substantial amount of
information. That information could be incorrect, such as a user
claiming a wrong physical address, email address, etc. It is
RECOMMENDED that systems provisioning these certificates validate
that the CSR contains the expected data and that it does not contain
unexpected data. For example, a CA could refuse to issue the
certificate if the CSR contained unknown fields or if a known field
contained an unexpected or invalid value. The CA can modify or
refuse a particular CSR to address these deficiencies for any
reasons, including local site policy. We note that the "A" in "CA"
means for "Authority", while the "R" in "CSR" means "Request". There
is no requirement for a CA to sign any and all CSRs that are
presented to it.
Once an EAP peer receives the signed certificate, the peer could
potentially be (ab)used for in TLS contexts other than TEAP. For
example, the certificate could be used with EAP-TLS, or even with
HTTPS. It is NOT RECOMMENDED to use certificates provisioned via
TEAP for any non-TEAP. One method of enforcing this restriction is
to have different CAs (or different intermediate CAs) that issue
certificates for different uses. For example, TLS-based EAP methods
could share one CA, and even use different intermediary CAs for
different TLS-based EAP methods. HTTPS servers could use an entirely
different CA. The different protocols could then be configured to
validate client certificates only from their preferred CA, which
would prevent peers from using certificates outside of the intended
use case.
Another method of limiting the uses of a certificate is to provision
it with an appropriate value for the Extended Key Purpose field
[RFC7299]. For example, the id-kp-eapOverLAN [RFC4334] value could
be used to indicate that this certificate is intended for use only
with EAP.
It is difficult to give more detailed recommendations than the above.
Each CA or organization may have its own local policy as to what is
permitted or forbidden in a certificate. All we can do in this
document is to highlight the issues and make the reader aware that
they have to be addressed.
3.11.3. Server Unauthenticated Provisioning Mode
In Server Unauthenticated Provisioning Mode, an unauthenticated
tunnel is established in Phase 1, and the peer and server negotiate
an Inner Method or methods in Phase 2. This Inner Method MUST
support mutual authentication, provide key derivation, and be
resistant to attacks such as on-path and dictionary attacks. In most
cases, this Inner Method will be an EAP authentication method.
Example Inner Methods that satisfy these criteria include EAP-pwd
[RFC5931] and EAP-EKE [RFC6124] but not EAP-FAST-MSCHAPv2.
This provisioning mode enables the bootstrapping of peers when the
peer lacks the ability to authenticate the server during Phase 1.
This includes both cases in which the cipher suite negotiated does
not provide authentication and in which the cipher suite negotiated
provides the authentication, but the peer is unable to validate the
identity of the server for some reason.
Upon successful completion of the Inner Method in Phase 2, the peer
and server exchange a Crypto-Binding TLV to bind the Inner Method
with the outer tunnel and ensure that an on-path attack has not been
attempted.
Support for the Server Unauthenticated Provisioning Mode is optional.
The cipher suite TLS_DH_anon_WITH_AES_128_CBC_SHA is RECOMMENDED when
using Server Unauthenticated Provisioning Mode, but other anonymous
cipher suites MAY be supported as long as the TLS pre-master secret
is generated from contribution from both peers.
When a strong Inner Method is not used with Server Unauthenticated
Provisioning Mode, it is possible for an attacker to perform an on-
path attack. In effect, Server Unauthenticated Provisioning Mode has
similar security issues as just running the Inner Method in the open
without the protection of TLS. All of the information in the tunnel
should be assumed to be visible to, and modifiable by, an attacker.
Implementations SHOULD exchange minimal data in Server
Unauthenticated Provisioning Mode. Instead, they should use that
mode to set up a secure/authenticated tunnel and then use that tunnel
to perform any needed data exchange.
It is RECOMMENDED that client implementations and deployments
authenticate TEAP servers if at all possible. Authenticating the
server means that a client can be provisioned securely with no chance
of an attacker eaves-dropping on the connection.
Note that server unauthenticated provisioning can only use anonymous
cipher suites in TLS 1.2 and earlier. These cipher suites have been
deprecated in TLS 1.3 ([RFC8446], Appendix C.5). For TLS 1.3, the
server MUST provide a certificate, and the peer performs server
unauthenticated provisioning by not validating the certificate chain
or any of its contents.
3.11.4. Channel Binding
[RFC6677] defines channel bindings for EAP that solve the "lying NAS"
and the "lying provider" problems, using a process in which the EAP
peer gives information about the characteristics of the service
provided by the authenticator to the Authentication, Authorization,
and Accounting (AAA) server protected within the EAP authentication
method. This allows the server to verify the authenticator is
providing information to the peer that is consistent with the
information received from this authenticator as well as the
information stored about this authenticator.
TEAP supports EAP channel binding using the Channel-Binding TLV
defined in Section 4.2.7. If the TEAP server wants to request the
channel-binding information from the peer, it sends an empty Channel-
Binding TLV to indicate the request. The peer responds to the
request by sending a Channel-Binding TLV containing a channel-binding
message as defined in [RFC6677]. The server validates the channel-
binding message and sends back a Channel-Binding TLV with a result
code. If the server did not initiate the channel-binding request and
the peer still wants to send the channel-binding information to the
server, it can do that by using the Request-Action TLV along with the
Channel-Binding TLV. The peer MUST only send channel-binding
information after it has successfully authenticated the server and
established the protected tunnel.