2. Protocol Overview
This section preserves the RFC text for TEAPv1, including TLS tunnel establishment, tunneled authentication, TLV formats, cryptographic calculations, IANA registries, security considerations, and examples.
2. Protocol Overview
TEAP authentication occurs in two phases after the initial EAP
Identity request/response exchange. In the first phase, TEAP employs
the TLS [RFC8446] handshake to provide an authenticated key exchange
and to establish a protected tunnel. Once the tunnel is established,
the second phase begins with the peer and server engaging in further
conversations to establish the required authentication and
authorization policies. TEAP makes use of TLV objects to carry out
the inner authentication, results, and other information, such as
channel-binding information.
As discussed in Section 2.1.7 of [RFC9190] and Section 3.1 of
[RFC9427], the outer EAP Identity SHOULD be an anonymous Network
Access Identifier (NAI) as described in Section 2.4 of [RFC7542].
While Section 5.1 of [RFC3748] places no limits on the contents of
the Identity field, Section 2.6 of [RFC7542] states that Identities
that do not follow the NAI format cannot be transported in an
Authentication, Authorization, and Accounting (AAA) proxy network.
As such, Identities in non-NAI form are likely to not work outside of
limited and local networks.
Any inner identities (EAP or otherwise) SHOULD also follow the
recommendations of [RFC9427], Section 3.1 about inner identities.
[RFC7170] defined a Protected Access Credential (PAC) to mirror EAP-
FAST [RFC4851]. However, implementation experience and analysis
determined that the PAC was not necessary. Instead, TEAP performs
session resumption using the NewSessionTicket message as defined in
Sections 2.1.2 and 2.1.3 of [RFC9190]. As such, the PAC has been
deprecated.
The TEAP conversation is used to establish or resume an existing
session to typically establish network connectivity between a peer
and the network. Upon successful execution of TEAP, the EAP peer and
EAP server both derive strong session key material (Master Session
Key [RFC3748]) that can then be communicated to the network access
server (NAS) for use in establishing a link-layer security
association.
2.1. Architectural Model
The network architectural model for TEAP usage is shown below:
+----------+ +----------+ +----------+ +----------+
| | | | | | | Inner |
| Peer |<---->| Authen- |<---->| TEAP |<---->| Method |
| | | ticator | | server | | server |
| | | | | | | |
+----------+ +----------+ +----------+ +----------+
Figure 1: TEAP Architectural Model
The Peer and Authenticator are defined in [RFC3748], Section 1.2.
The TEAP server is the "backend authentication server" defined in
[RFC3748], Section 1.2. The "Inner Method server" is usually part of
the TEAP server and handles the application data (Inner Methods, EAP,
passwords, etc.) inside of the TLS tunnel.
The entities depicted above are logical entities and may or may not
correspond to separate network components. For example, the TEAP
server and Inner Method server might be a single entity; the
authenticator and TEAP server might be a single entity; or the
functions of the authenticator, TEAP server, and Inner Method server
might be combined into a single physical device. For example,
typical IEEE 802.11 deployments place the authenticator in an access
point (AP) while a RADIUS server may provide the TEAP and inner
method server components. The above diagram illustrates the division
of labor among entities in a general manner and shows how a
distributed system might be constructed; however, actual systems
might be realized more simply. The security considerations in
Section 8.3 provide an additional discussion of the implications of
separating the TEAP server from the Inner Method server.
2.2. Protocol-Layering Model
TEAP packets are encapsulated within EAP; EAP in turn requires a
transport protocol. TEAP packets encapsulate TLS, which is then used
to encapsulate user authentication information. Thus, TEAP messaging
can be described using a layered model, where each layer encapsulates
the layer above it. The following diagram clarifies the relationship
between protocols:
+------------------------------------------+
| Inner EAP Method | Other TLV information |
|------------------------------------------|
| TLV Encapsulation (TLVs) |
|------------------------------------------+---------------------+
| TLS | Optional Outer TLVs |
|----------------------------------------------------------------|
| TEAP |
|----------------------------------------------------------------|
| EAP |
|----------------------------------------------------------------|
| Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) |
+----------------------------------------------------------------+
Figure 2: Protocol-Layering Model
The TLV layer is a payload with TLV objects as defined in
Section 4.2. The TLV objects are used to carry arbitrary parameters
between an EAP peer and an EAP server. All data exchanges in the
TEAP-protected tunnel are encapsulated in a TLV layer.
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X [IEEE.802-1X.2020] may be used to
transport EAP between the peer and the authenticator; RADIUS
[RFC3579] or Diameter [RFC4072] may be used to transport EAP between
the authenticator and the EAP server.
2.3. Outer TLVs Versus Inner TLVs
TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows:
Outer TLVs
This term is used to refer to optional TLVs outside the TLS
tunnel, which are only allowed in the first two messages in the
TEAP. That is the first EAP-server-to-peer message and first
peer-to-EAP-server message. If the message is fragmented, the
whole set of fragments is counted as one message.
Inner TLVs
This term is used to refer to TLVs sent within the TLS tunnel. In
TEAP Phase 1, Outer TLVs are used to help establish the TLS
tunnel, but no Inner TLVs are used. In Phase 2 of TEAP, TLS
records may encapsulate zero or more Inner TLVs, but no Outer TLVs
are used.