One document matched: draft-zorn-emu-team-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc5246 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc3748 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY rfc5226 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.xml">
<!ENTITY rfc4282 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4282.xml">
<!ENTITY rfc4017 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4017.xml">
<!ENTITY rfc1968 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1968.xml">
<!ENTITY rfc1990 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1990.xml">
<!ENTITY rfc2548 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2548.xml">
<!ENTITY rfc2865 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY rfc5216 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5216.xml">
<!ENTITY rfc3579 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3579.xml">
<!ENTITY rfc3580 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3580.xml">
<!ENTITY rfc3766 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3766.xml">
<!ENTITY rfc3986 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY rfc5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
<!ENTITY rfc2315 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2315.xml">
<!ENTITY rfc2637 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2637.xml">
<!ENTITY rfc3931 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3931.xml">
<!ENTITY rfc2560 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2560.xml">
]>
<?rfc strict="yes"?>
<?rfc comments="no"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc rfcprocack="no"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-zorn-emu-team-01" ipr="noModificationTrust200902">
<front>
<title abbrev="TEAM">The Tunneled Extensible Authentication Protocol Method (TEAM)</title>
<author fullname="Glen Zorn" initials="G" surname="Zorn">
<organization>Network Zen</organization>
<address>
<postal>
<street>227/358 Thanon Sanphawut</street>
<city>Bang Na</city>
<region>Bangkok</region>
<code>10260</code>
<country>Thailand</country>
</postal>
<phone>+66 (0) 87-040-4617</phone>
<email>gwz@net-zen.net</email>
</address>
</author>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization abbrev="Huawei">Huawei Technologies Co., Ltd.</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>21001</code>
<country>China</country>
</postal>
<phone>+86-25-84565892</phone>
<email>sunseawq@huawei.com</email>
</address>
</author>
<author fullname="Dan Harkins" initials="D.H." surname="Harkins">
<organization>Aruba Networks</organization>
<address>
<postal>
<street>1322 Crossman Avenue</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089-1113</code>
<country>United States of America</country>
</postal>
<email>dharkins@arubanetworks.com</email>
</address>
</author>
<date year="2010"/>
<abstract>
<t>
The Extensible Authentication Protocol (EAP) provides support for
multiple authentication methods. This document defines the Tunneled Extensible Authentication
Method (TEAM), which provides
an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates
EAP authentication mechanisms.
TEAM uses TLS to protect against rogue authenticators, protect against various attacks on the
confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity
privacy.
TEAM also provides support for chaining multiple EAP mechanisms, cryptographic binding
between authentications performed by inner EAP mechanisms and the tunnel, exchange of
arbitrary parameters (TLVs),
and fragmentation and reassembly.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The Extensible Authentication Protocol (EAP), defined in <xref target="RFC3748"/>,
provides support for multiple authentication methods. EAP over PPP <xref target="RFC3748"/>
is typically
deployed with leased lines or
modem connections. <xref target="IEEE.802-1X.2004"/>
defines EAP over IEEE 802 local area
networks (EAPOL).
<vspace blankLines="1" />
Since its initial development, a number of weaknesses in the EAP framework have
become apparent. These include lack of support for:
<vspace blankLines="1"/>
<list>
<t>Identity protection</t>
<t>Protected method negotiation</t>
<t>Protected notification messages</t>
<t>Protected termination messages</t>
<t>Sequences of EAP methods</t>
<t>Fragmentation and reassembly</t>
<t>Exchange of arbitrary parameters in a secure channel</t>
<t>Optimized re-authentication</t>
</list>
<vspace blankLines="1"/>
In addition, some EAP methods lack the following features:
<vspace blankLines="1"/>
<list>
<t>Mutual authentication</t>
<t>Resistance to dictionary attacks</t>
<t>Adequate key generation</t>
</list>
<vspace blankLines="1"/>
By wrapping the EAP protocol within TLS, TEAM addresses deficiencies in EAP or EAP
methods. Benefits of TEAM include:
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Identity protection">
<vspace blankLines="0"/>
By encrypting the identity exchange, and allowing client identity
to be provided after negotiation of the TLS channel, TEAM
provides for identity protection.
<vspace blankLines="1"/>
</t>
<t hangText="Dictionary attack resistance">
<vspace blankLines="0"/>
By conducting the EAP conversation within a TLS channel, TEAM
protects EAP methods that might be subject to an offline dictionary
attack were they to be conducted in the clear.
<vspace blankLines="1"/>
</t>
<t hangText="Protected negotiation">
<vspace blankLines="0"/>
Since within TEAM, the EAP conversation is authenticated,
integrity and replay protected on a per-packet basis, the EAP
method negotiation that occurs within TEAM is protected, as are
error messages sent within the TLS channel (TLS alerts or EAP
Notification packets). EAP negotiation outside of TEAM is not protected.
<vspace blankLines="1"/>
</t>
<t hangText="Header protection">
<vspace blankLines="0"/>
Within TEAM, TLS provides per-packet encryption, authentication,
integrity and replay protection for the EAP conversation. As a
result, the Type-Data field within TEAM (including the EAP header
of the EAP method within TEAM) is protected against modification.
However, the EAP header of TEAM itself is not protected against
modification, including the Code, Identifier and Type fields.
<vspace blankLines="1"/>
</t>
<t hangText="Protected termination">
<vspace blankLines="0"/>
By sending success/failure indications within the TLS channel,
TEAM provides support for protected termination of the EAP
conversation. This prevents an attacker from carrying out denial
of service attacks by spoofing EAP Failure messages, or fooling the
EAP peer into accepting a rogue NAS, by spoofing EAP Success messages.
<vspace blankLines="1"/>
</t>
<t hangText="Fragmentation and Reassembly">
<vspace blankLines="0"/>
Since EAP does not include support for fragmentation and
reassembly, individual methods need to include this capability. By
including support for fragmentation and reassembly within TEAM,
methods leveraging TEAM do not need to support this on their own.
<vspace blankLines="1"/>
</t>
<t hangText="Fast reconnect">
<vspace blankLines="0"/>
Where EAP is used for authentication in wireless networks, the
authentication latency is a concern. As a result, it is valuable
to be able to do a quick re-authentication on roaming between
access points. TEAM supports this capability by leveraging the
TLS session resumption facility, and any EAP method running under
TEAM can take advantage of it.
<vspace blankLines="1"/>
</t>
<t hangText="Standard key establishment">
<vspace blankLines="0"/>
In order to provide keying material for a wide range of link layer
ciphersuites, EAP methods need to provide keying material. Key
derivation is complex. TEAM provides for key establishment by
relying on the widely implemented and well-reviewed TLS <xref target="RFC5246"/>
key derivation mechanism. TEAM provides keying material for any
EAP method running within it.
<!--
If EAP methods will also be deployed
without external protection (e.g. TEAM or IPSec), then the EAP
methods should follow the guidelines in <xref target="MITM-A-P"/>
to prevent the
man-in-the-middle attacks.
-->
<vspace blankLines="1"/>
</t>
<t hangText="Sequencing of multiple EAP methods">
<vspace blankLines="0"/>
In order to enhance security, TEAM implementations may choose to
provide multi-factor authentication that validates different
identities (for example user and machine identities) and/or uses
different credentials of the same or different identities of the
peer (e.g. user password and machine cert). TEAM provides a
standard way to chain different types of authentication mechanisms
supporting different types of credentials.
<vspace blankLines="1"/>
</t>
<t hangText="Protected exchange of arbitrary parameters">
<vspace blankLines="0"/>
Type-Length-Value (TLV) tuples provide a way to exchange arbitrary
information between peer and EAP server within a secure channel.
This information can include signaling parameters for the EAP protocol,
provisioning parameters, media specific and environment specific
data, and authorization parameters. The advantage of using TEAM
TLVs is that every EAP method does not have to be modified.
<vspace blankLines="1"/>
</t>
<t hangText="Credential provisioning">
<vspace blankLines="0"/>
TEAM supports provisioning of certificate trust anchors by the
server using TLVs and can be extended to support provisioning of other peer credentials.
<vspace blankLines="1"/>
</t>
<t hangText="Optimized for light weight devices">
<vspace blankLines="0"/>
In order to support peers that may not support certificate
ciphersuites, and may not support provisioning of certificate trust
anchors, TEAM enables negotiation of other TLS ciphersuites.
<vspace blankLines="1"/>
</t>
<t hangText="Server unauthenticated tunnel provisioning mode">
<vspace blankLines="0"/>
In some cases, the peer may only support password credentials and
may not be provisioned with a certificate trust anchor.
<vspace blankLines="1"/>
In server unauthenticated tunnel provisioning mode, a TEAM peer
can authenticate using a password, in order to be provisioned with
a pre-shared key and other credentials that can be used for
subsequent authentication. In server unauthenticated tunnel
provisioning mode the TEAM peer only confirms possession of the
private key corresponding to the public key contained within the
server certificate, but does not otherwise validate the server
certificate. As a result, it is possible for an attacker to act as
a man-in-the-middle during the initial exchange in order to perform
an offline dictionary attack, based on capture of the password-
based authentication exchange.
<vspace blankLines="1"/>
In TEAM, implementation of server unauthenticated tunnel
provisioning mode is optional and due to the security
vulnerabilities introduced by this mode, it is not recommended for
use with peers that support certificate validation and provisioning
of certificate trust anchors.
</t>
</list>
</t>
</section>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119"></xref>.
</t>
</section>
<section title="Terminology">
<t>
This document frequently uses the following terms:
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="Access Point">
<vspace blankLines="0"/>
A Network Access Server implementing 802.11.
<vspace blankLines="1"/>
</t>
<t hangText="Authenticator">
<vspace blankLines="0"/>
The end of the link initiating EAP authentication. This term is
also used in <xref target="IEEE.802-1X.2004"/>.
and has the same meaning in this document.
<vspace blankLines="1"/>
</t>
<t hangText="Backend Authentication Server">
<vspace blankLines="0"/>
A backend authentication server is an entity that provides an
authentication service to an Authenticator. When used, this server
typically executes EAP methods for the Authenticator. This
terminology is also used in <xref target="IEEE.802-1X.2004"/>.
<vspace blankLines="1"/>
</t>
<t hangText="EAP server">
<vspace blankLines="0"/>
The entity that terminates the EAP authentication method with the
peer. In the case where no backend authentication server is used,
the EAP server is part of the Authenticator. In the case where the
authenticator operates in pass-through mode, the EAP server is
located on the backend authentication server.
<vspace blankLines="1"/>
</t>
<t hangText="Link layer ciphersuite">
<vspace blankLines="0"/>
The ciphersuite negotiated for use at the link layer.
<vspace blankLines="1"/>
</t>
<t hangText="NAS">
<vspace blankLines="0"/>
Short for "Network Access Server".
<vspace blankLines="1"/>
</t>
<t hangText="Peer">
<vspace blankLines="0"/>
The end of the link that responds to the authenticator. In <xref target="IEEE.802-1X.2004"/>,
this end is known as the Supplicant.
<vspace blankLines="1"/>
</t>
<t hangText="TLS Ciphersuite">
<vspace blankLines="0"/>
The ciphersuite negotiated for protection of Phase 2 of the TEAM
conversation <xref target="T-P-2"/>.
<vspace blankLines="1"/>
</t>
<t hangText="EAP Master key (MK)">
<vspace blankLines="0"/>
A key derived between the TEAM client and server during the
authentication conversation, and that is kept local to TEAM and
not exported or made available to a third party.
<vspace blankLines="1"/>
</t>
<t hangText="Master Session Key (MSK)">
<vspace blankLines="0"/>
Keying material that is derived between the EAP peer and server and
exported by the EAP method. The MSK is at least 64 octets in
length. In existing implementations, a AAA server acting as an EAP
server transports the MSK to the authenticator.
<vspace blankLines="1"/>
</t>
<t hangText="Extended Master Session Key (EMSK)">
<vspace blankLines="0"/>
Additional keying material derived between the EAP client and
server that is exported by the EAP method. The EMSK is at least 64
octets in length. The EMSK is not shared with the authenticator or
any other third party. The EMSK is reserved for future uses that
are not defined yet.
<vspace blankLines="1"/>
</t>
<t hangText="Type Length Value (TLV)">
<vspace blankLines="0"/>
The TEAM protocol utilizes objects in Type Length Value (TLV)
format. The TLV format is defined in <xref target="TLV-F"/>
of this document.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Protocol Overview">
<t>
TEAM is comprised of a two-part conversation:
<vspace blankLines="1"/>
<list style="numbers">
<t>
In Phase 1 a TLS session is negotiated, with the server authenticating
to the client and (optionally) the client to the server. The
negotiated key is then used to protect Phase 2 of the
conversation.
<vspace blankLines="1"/>
</t>
<t>
In Phase 2, within the TLS session, zero or more EAP methods are
carried out. Phase 2 completes with a success/failure indication
protected by the TLS session or a protected error (TLS alert).
</t>
</list>
<vspace blankLines="1"/>
In the following sections, we discuss the TEAM operational model, its support for EAP method
sequencing and provide an overview of each of the parts of the TEAM conversation.
</t>
<section title="Operational Model">
<t>
In EAP, the EAP server may be implemented either within a Network
Access Server (NAS) or on a backend authentication server. Where the
EAP server resides on a NAS, the NAS is required to implement the
desired EAP methods, and therefore needs to be upgraded to support
each new EAP method.
<vspace blankLines="1"/>
One of the goals of EAP is to enable development of new
authentication methods without requiring deployment of new code on
the Network Access Server (NAS). Where a backend authentication
server is deployed, the NAS acts as a "passthrough" and need not
understand specific EAP methods.
<vspace blankLines="1"/>
This allows new EAP methods to be deployed on the EAP peer and
backend authentication server, without the need to upgrade code
residing on the NAS.
<vspace blankLines="1"/>
<xref target="fig1"/>
illustrates the relationship between the EAP peer, NAS and EAP
server. As shown in the figure, the EAP conversation occurs
between the EAP peer and EAP server, "passing through" the NAS. In
order for the conversation to proceed in the case where the NAS and
EAP server reside on separate machines, the NAS and EAP server need
to establish trust beforehand.
<figure align="center" anchor="fig1" title="Relationship between EAP client, backend authentication server and NAS"> <artwork><![CDATA[
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| Link | | Link |
| Layer | | Layer |
| Cipher- | | Cipher- |
| Suite | | Suite |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| |
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+ Trust +-+-+-+-+-+
| | EAP | |<======>| |
| | Conversation | | | |
| EAP |<================================>| EAP |
| Peer | (over PPP, | NAS | | Server |
| | 802.11,etc.) | |<=======| |
| | | | Keys | |
| | | | | |
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
^ ^
| |
| EAP API | EAP API
| |
V V
+-+-+-+-+-+ +-+-+-+-+-+
| | | |
| | | |
| EAP | | EAP |
| Method | | Method |
| | | |
+-+-+-+-+-+ +-+-+-+-+-+
]]></artwork></figure>
In TEAM, the conversation between the EAP peer and the EAP server
is encrypted, authenticated, integrity and replay protected within a
TLS channel.
<vspace blankLines="1"/>
As a result, where the NAS acts as a "passthrough" it does not have
knowledge of the TLS master secret derived between the peer and the
EAP server. In order to provide keying material for link-layer
ciphersuites, the NAS obtains the master session key, which is
derived from a one-way function of the TLS master secret as well as
keying material provided by EAP methods protected within a TLS
channel. This enables the NAS and EAP peer to subsequently derive
transient session keys suitable for encrypting, authenticating and
integrity protecting session data. However, the NAS cannot decrypt
the TEAM conversation or spoof session resumption, since this
requires knowledge of the TLS master secret.
</t>
</section>
<section title="Sequences">
<t>
EAP <xref target="RFC3748"/>
prohibits use of multiple authentication methods within
a single EAP conversation, except when tunneled methods such as
TEAM are used. This restriction was imposed in order to limit
vulnerabilities to man-in-the-middle attacks as well as to ensure
compatibility with existing EAP implementations.
<vspace blankLines="1"/>
Within TEAM these concerns are addressed since TEAM includes
support for cryptographic binding to address man-in-the-middle
attacks, as well as version negotiation so as to enable backward
compatibility with future versions of the protocol.
<vspace blankLines="1"/>
Within this document, the term "sequence" refers to a series of EAP
authentication methods run in sequence or TLV exchanges before or
after EAP methods. The methods need not be distinct - for example,
EAP-TLS could be run initially with machine credentials followed by
the same protocol authenticating with user credentials.
<vspace blankLines="1"/>
TEAM supports initiating additional EAP method(s) after a
successful or a failed EAP method. The result of failure of a EAP
method does not always imply a failure of the overall authentication.
The overall result of authentication depends on the policy at EAP
server and the peer. For example, successful authentication might
require a successful machine authentication followed by a successful
user authentication. Alternatively, if machine authentication fails,
then user authentication can be attempted. TEAM does not support
initiating multiple EAP methods simultaneously.
</t>
</section>
<section title="TEAM Phase 1" anchor="T-P-1">
<section title="Initial identity exchange" anchor="I-I-E">
<t>
The TEAM conversation typically begins with an optional identity
exchange. The authenticator will typically send an EAP-
Request/Identity packet to the peer, and the peer will respond with
an EAP-Response/Identity packet to the authenticator.
<vspace blankLines="1"/>
The initial identity exchange is used primarily to route the EAP
conversation to the EAP server. Since the initial identity exchange
is in the clear, the peer MAY decide to place a routing realm instead
of its real name in the EAP-Response/Identity. The real identity of
the peer can be established later, during Phase 2.
<vspace blankLines="1"/>
If the EAP server is known in advance (such as when all users
authenticate against the same backend server infrastructure and
roaming is not supported), or if the identity is otherwise determined
(such as from the dialing phone number or client MAC address), then
the EAP-Request/Response-identity exchange MAY be omitted.
<vspace blankLines="1"/>
Once the optional initial Identity Request/Response exchange is
completed, while nominally the EAP conversation occurs between the
authenticator and the peer, the authenticator MAY act as a
passthrough device, with the EAP packets received from the peer being
encapsulated for transmission to a backend authentication server.
However, TEAM does not require a backend authentication server; if
the authenticator implements TEAM, then it can authenticate local
users.
<vspace blankLines="1"/>
In the discussion that follows, we will use the term "EAP server" to
denote the ultimate endpoint conversing with the peer.
</t>
</section>
<section title="TLS Session Establishment" anchor="T-S-E">
<t>
In this section, the protocol is described. While this section will often describe
negotiation of a certificate-based ciphersuite within TLS, TEAM supports negotiation
of other ciphersuites (for example, ciphersuites that do not use
certificates) or extensions. However, the conversation may slightly
differ if other TLS ciphersuites or extensions are used.
<vspace blankLines="1"/>
Once having received the peer's Identity, and determined that TEAM
authentication is to occur, the EAP server MUST respond with a
TEAM/Start packet, which is an EAP-Request packet with EAP-Type=TEAM,
the Start (S) bit set, the TEAM version as specified in <xref target="V-N"/>,
and optionally, the Server-Identifier TLV (<xref target="S-I-TLV"/>).
<vspace blankLines="1"/>
Assuming that the peer supports TEAM, the TEAM conversation will then
begin, with the peer sending an EAP-Response packet with EAP-
Type=TEAM. The Type-Data field of the EAP-Response Packet will
encapsulate one or more TLS records containing the TLS handshake
messages. As defined in <xref target="RFC5246"/>,
the TLS handshake is used to
negotiate parameters and cryptographic keys and may take several
roundtrips between the TLS client and server.
<vspace blankLines="1"/>
The version offered by the TLS client and server MUST be TLS v1.0 or
later. TEAM implementations need not necessarily support all TLS
ciphersuites listed in <xref target="RFC5246"/>.
Not all TLS ciphersuites are
supported by available TLS tool kits and licenses may be required in
some cases.
<vspace blankLines="1"/>
To ensure interoperability, TEAMv2 peers and servers MUST support the
TLS v1.1 <xref target="RFC5246"/>
mandatory-to-implement ciphersuite:
<vspace blankLines="1"/>
<list>
<t>TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA</t>
</list>
<vspace blankLines="1"/>
In addition, TEAM servers SHOULD support and be able to negotiate
all of the following TLS ciphersuites:
<vspace blankLines="1"/>
<list>
<t>TLS_RSA_WITH_3DES_EDE_CBC_SHA</t>
<t>TLS_RSA_WITH_RC4_128_MD5</t>
<t>TLS_RSA_WITH_RC4_128_SHA</t>
<t>TLS_RSA_WITH_AES_128_CBC_SHA</t>
</list>
<vspace blankLines="1"/>
In addition, TEAM peers SHOULD support at least one of the
following TLS ciphersuites:
<vspace blankLines="1"/>
<list>
<t>TLS_RSA_WITH_3DES_EDE_CBC_SHA</t>
<t>TLS_RSA_WITH_RC4_128_MD5</t>
<t>TLS_RSA_WITH_RC4_128_SHA</t>
<t>TLS_RSA_WITH_AES_128_CBC_SHA</t>
</list>
<vspace blankLines="1"/>
TLS as described in <xref target="RFC5246"/>
supports compression as well as ciphersuite negotiation. Therefore during the TEAM Phase 1
conversation the TEAM endpoints MAY request or negotiate TLS
compression.
<vspace blankLines="1"/>
If the full TLS handshake is performed, then the first payload of
TEAM Phase 2 MAY be sent along with finished handshake message to
reduce number of round trips.
<vspace blankLines="1"/>
Since after the TLS session is established, another complete EAP
negotiation will occur and the peer will authenticate using a
secondary mechanism, with TEAM the client need not authenticate as
part of TLS session establishment.
<vspace blankLines="1"/>
Note that since TLS client certificates are sent in the clear, if
identity protection is required, then it is possible for the TLS
authentication to be re-negotiated after the first server
authentication. Alternatively, if identity protection is required,
then it is possible to perform certificate authentication using a EAP
method (for example: EAP-TLS <xref target="RFC5216"/>)
within the TLS session during TEAM Phase 2.
<vspace blankLines="1"/>
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 TEAM Phase 2 begins, the server MAY send a TLS
hello_request. This allows the client to perform client
authentication by sending a client_hello if it wants to, or send a
no_renegotiation alert to the server indicating that it wants to
continue with TEAM Phase 2 instead. Assuming that the client permits
renegotiation by sending a client_hello, then the server will respond
with server_hello, a certificate and certificate_request messages.
The client replies with certificate, client_key_exchange and
certificate_verify messages. Since this re-negotiation occurs within
the encrypted TLS channel, it does not reveal client certificate details.
</t>
</section>
<section title="Session Resumption" anchor="S-R">
<t>
The purpose of the sessionId within the TLS protocol and the Server-
Identifier TLV in TEAM is to allow for improved efficiency in the
case where a client repeatedly attempts to authenticate to an EAP
server within a short period of time. This capability is
particularly useful for support of wireless roaming.
<vspace blankLines="1"/>
In order to help the peer choose a sessionID that belongs to the
specific server, the EAP server MAY send an identifier (Server-
Identifier TLV) that the peer can use as a hint. The Server-
Identifier TLV MAY be sent in the first TEAM packet from the EAP
server to the peer. In order to detect modification of the Server-
Identifier TLV, the Server-Identifier TLV is included in calculation
of the compound MAC.
<vspace blankLines="1"/>
It is left up to the peer whether to attempt to continue a previous
session, thus shortening the TEAM Phase 1 conversation. Typically the
peer's decision will be made based on the time elapsed since the
previous authentication attempt to that EAP server.
<vspace blankLines="1"/>
Based on the sessionId chosen by the peer, and the time elapsed since
the previous authentication, the EAP server will decide whether to
allow the continuation, or whether to choose a new session.
<vspace blankLines="1"/>
If the EAP server is resuming a previously established session, then
it MUST include only a TLS change_cipher_spec message and a TLS
finished handshake message after the server_hello message. The
finished message contains the EAP server's authentication response to
the peer.
<vspace blankLines="1"/>
If the preceding server_hello message sent by the EAP server in the
preceding EAP-Request packet indicated the resumption of a previous
session, then the peer MUST send only the change_cipher_spec and
finished handshake messages. The finished message contains the
peer's authentication response to the EAP server. The latter contains
the EAP server's authentication response to the peer. The peer will
verify the hash in order to authenticate the EAP server.
<vspace blankLines="1"/>
If authentication fails, then the peer and EAP-server MUST follow the
error handling behavior specified in <xref target="E-H"/>
<vspace blankLines="1"/>
Even if the session is successfully resumed with the same EAP server,
the peer and EAP server MUST NOT assume that either will skip inner
EAP methods. The peer may have roamed to a network which may use the
same EAP server, but may require conformance with a different
authentication policy, and therefore may require inner EAP
authentication methods.
</t>
</section>
<section title="Version Negotiation" anchor="V-N">
<t>
TEAM packets contain a three bit version field, which enables TEAM
implementations to be backward compatible with previous versions of
the protocol. This specification documents version1 of the TEAM
protocol; implementations of this specification MUST use a version
field set to 1. Version negotiation proceeds as follows:
<vspace blankLines="1"/>
<list style="numbers">
<t>
In the first EAP-Request sent with EAP-Type=TEAM, the EAP server
MUST set the version field to the highest supported version number.
<vspace blankLines="1"/>
</t>
<t>
If the EAP peer supports that version of the protocol, it MUST
respond with an EAP-Response of EAP-Type=TEAM, and the version
number proposed by the EAP server.
<vspace blankLines="1"/>
</t>
<t>
If the EAP peer does not support that version, it responds with an
EAP-Response of EAP-Type=TEAM and the highest supported version number.
<vspace blankLines="1"/>
</t>
<t>
If the TEAM server does not support the version number proposed by
the TEAM peer, it either starts a different EAP type or terminates
the conversation by sending an EAP-Failure, depending on the server policy.
<vspace blankLines="1"/>
</t>
</list>
The version negotiation procedure guarantees that the EAP peer and
server will agree to the latest version supported by both parties.
If version negotiation fails, then use of TEAM will not be possible,
and another mutually acceptable EAP method will need to be negotiated
if authentication is to proceed.
<vspace blankLines="1"/>
The TEAM version field is not protected by TLS and therefore can be
modified in transit. In order to detect modification of the TEAM
version which could occur as part of a "downgrade" attack, the peer
and EAP server check if the version it sent during negotiation is
same as the version claimed to be received by the other party. Each
party uses the Crypto-Binding TLV (<xref target="Cryp-B-TLV"/>)
to inform the other party of the
version number it received during the TEAM version negotiation. The
receiver of the Crypto-Binding TLV must verify that the version in
the Crypto-Binding TLV matches the version it sent during TEAM
version negotiation.
</t>
</section>
</section>
<section title="TEAM Phase 2" anchor="T-P-2">
<t>
The second part of the TEAMv2 conversation typically consists of a
complete EAP conversation occurring within the TLS session negotiated
in TEAM Phase 1, ending with protected termination using the Result
TLV. TEAM Phase 2 will occur only if establishment of a new TLS
session in Phase 1 is successful or a TLS session is successfully
resumed in Phase 1. In cases where a new TLS session is established
in TEAMv2 Phase 1, the first payload of the Phase 2 conversation MAY be
sent by the EAP server along with the finished message to save a
round-trip.
<vspace blankLines="1"/>
Phase 2 SHOULD NOT occur if the EAP Server authenticates
unsuccessfully, and MUST NOT occur if establishment of the TLS
session in Phase 1 was not successful or a TLS fatal error has been
sent terminating the conversation.
<vspace blankLines="1"/>
Since all packets sent within the TEAM Phase 2 conversation occur
after TLS session establishment, they are protected using the
negotiated TLS ciphersuite. All EAP packets of the EAP conversation
in Phase 2 including the EAP header of the inner EAP method are
protected using the negotiated TLS ciphersuite.
<vspace blankLines="1"/>
Phase 2 may not always include a EAP conversation within the TLS
session, referred to in this document as inner EAP methods. However,
Phase 2 MUST always end with either protected termination or protected
error termination (e.g. TLS alert).
<vspace blankLines="1"/>
Within Phase 2, protected EAP conversation and protected termination
packets are always carried within TLVs. There are TLVs defined for
specific purposes such as carrying EAP-authentication messages and
carrying cryptographic binding information. New TLVs may be developed for other
purposes.
</t>
<section title="Protected Conversation" anchor="P-C">
<t>
Phase 2 of the TEAM conversation typically begins with the EAP
server sending an optional EAP-Request/Identity packet to the peer,
protected by the TLS ciphersuite negotiated in Phase 1 of TEAM. The
peer responds with an EAP-Response/Identity packet to the EAP server,
containing the peer's userId. Since this Identity Request/Response
exchange is protected by the ciphersuite negotiated in TLS, it is not
vulnerable to snooping or packet modification attacks.
<vspace blankLines="1"/>
After the TLS session-protected Identity exchange, the EAP server
will then select authentication method(s) for the peer, and will send
an EAP-Request with the Type field set to the initial method. As
described in <xref target="RFC3748"/>,
the peer can NAK the suggested EAP method,
suggesting an alternative. Since the NAK will be sent within the TLS
channel, it is protected from snooping or packet modification. As a
result, an attacker snooping on the exchange will be unable to inject
NAKs in order to "negotiate down" the authentication method. An
attacker will also not be able to determine which EAP method was
negotiated.
<vspace blankLines="1"/>
The EAP conversation within the TLS protected session may involve a
sequence of zero or more EAP authentication methods; it completes
with the protected termination described in <xref target="P-T"/>
Several TLVs may be included in each Request and Response. EAP packets are
always encapsulated within EAP Payload TLVs.
<vspace blankLines="1"/>
In a typical EAP conversation, the result of the conversation is
communicated by sending EAP Success or EAP Failure packets after the
EAP method is complete. The EAP Success or Failure packet is
considered the last packet of the EAP conversation; and therefore
cannot be used when sequences need to be supported. Hence, instead
of using the EAP Success or EAP Failure packet, both peer and EAP
server MUST use the Intermediate-Result TLV (<xref target="I-R-TLV"/>)
to communicate the result.
<vspace blankLines="1"/>
In a typical EAP conversation, the EAP Success or EAP Failure is
considered the last packet of the EAP conversation. Within TEAM,
the EAP server can start another EAP method after success or failure
of the previous EAP method inside the protected session.
<vspace blankLines="1"/>
In a sequence of more than one EAP authentication method, to make
sure the same parties are involved in tunnel establishment and
successful completion of previous inner EAP methods, before
completing negotiation of the next EAP method, both peer and EAP
server MUST use crypto binding (Crypto-Binding TLV).
<vspace blankLines="1"/>
The Intermediate-Result TLV is used to indicate the result of a
individual successful EAP method, and the Result TLV (<xref target="R-TLV"/>)
is used to indicate result of the entire TEAM conversation.
<vspace blankLines="1"/>
The Intermediate-Result and Crypto-Binding TLVs MUST be sent after
each EAP method that was successful. If the EAP method failed, or if
the EAP method negotiation did not complete, then an Intermediate-
Result TLV MAY be included, and the Crypto-Binding TLV MUST NOT be
included. An exception is that the Crypto-Binding TLV MUST be sent
along with a protected success/failure indication (see
<xref target="P-T"/>).
<vspace blankLines="1"/>
If these TLVs are not sent after a successful EAP method, it should
be considered a tunnel compromise error by peer and EAP server,
resulting in the termination of the conversation (as described in <xref target="E-H"/>).
<vspace blankLines="1"/>
A subsequent EAP conversation can be started after both TLVs are
exchanged in a TLV packet. Alternatively, if a subsequent EAP
conversation is being attempted, then in order to reduce round trips,
both TLVs SHOULD be sent with the EAP-Payload of the first EAP packet
of the next EAP conversation (for example, EAP-Identity or EAP
packet of the EAP method). Alternatively, if the next packet is the
protected success/failure packet, then in order to reduce round
trips, both TLVs MUST be sent with the protected success/failure packet.
<vspace blankLines="1"/>
If the EAP server sends a valid Crypto-Binding TLV to the peer, the
peer MUST respond with a Crypto-Binding TLV. If the Crypto-Binding
TLV is invalid, it should be considered a tunnel compromise error by
the peer. If the peer does not respond with a TLV packet containing
the Crypto-Binding TLV, it MUST be considered a tunnel compromise
error by the EAP server.
<vspace blankLines="1"/>
Within a TEAM part 2 conversation, a peer MAY request the trusted
root of a server certificate using a Server-Trusted-Root TLV (<xref target="S-T-R-TLV"/>), and
the EAP server MAY respond with a Server-Trusted-Root TLV to the
peer. The Server-Trusted-Root TLV can be exchanged in regular
authentication mode or server unauthenticated tunnel provisioning
mode.
<vspace blankLines="1"/>
After the peer has determined that it has successfully authenticated
the EAP server and determined that the tunnel and inner EAP methods
were between the same peer and EAP server by validating the Crypto-Binding TLV,
it MAY send one or more Server-Trusted-Root TLVs (marked
as optional) to request the trusted root of server certificate from
the EAP server. The peer may receive a response, but is not required
to use the trusted root received from the EAP server.
<vspace blankLines="1"/>
If the EAP server has determined that it has successfully
authenticated the peer and determined that the tunnel and inner EAP
methods were between the same peer and EAP server by validating the
Crypto-Binding TLV, then it MAY respond with the the server-trusted-
root containing the PCKS#7 TLV (<xref target="PKCS-TLV"/>).
</t>
</section>
<section title="Protected Termination" anchor="P-T">
<t>
Phase 2 of the TEAM conversation is completed by the exchange of
success/failure indications (Result TLV) within a TLV packet
protected by the TLS session.
<vspace blankLines="1"/>
Even if Crypto-Binding TLVs have been exchanged in previous
conversations, the Crypto-Binding TLV MUST be included in both
protected success/failure (Result TLV) indications. If the TLVs are
not included, or if the TLVs are invalid, it should be considered a
tunnel compromise error, and the peer and EAP server MUST follow the
rules described in <xref target="E-H"/>
to abort the conversation.
<vspace blankLines="1"/>
The Result TLV is sent within the TLS channel. The TEAM client then
replies with a Result TLV. The conversation concludes with the TEAM
server sending a cleartext success/failure indication.
<vspace blankLines="1"/>
The only outcome which should be considered as successful
authentication is when a Result TLV of Status=Success is answered by
the peer with a Result TLV of Status=Success.
<vspace blankLines="1"/>
The combinations (Result TLV=Failure, Result TLV=Success), (Result
TLV=Failure, Result TLV=Failure), (no TLVs exchange or no protected
success or failure) should be considered an authentication failure by
both the peer and EAP server. Once the peer and EAP server consider
that authentiation has failed, these are the last packets inside the
protected tunnel. These combinations are considered an
authentication failure regardless of whether a cleartext EAP Success
or EAP Failure packet is subsequently sent.
<vspace blankLines="1"/>
If the EAP server wants authentication to fail, it sends the TLV
response with Result TLV=Failure. If the EAP server sends a failure,
the peer MUST respond with Result TLV=Failure and the Crypto-Binding
TLV, without any other mandatory TLVs. The Crypto-Binding TLV is
calculated using the key derivation formula in Section 2.5; if for
some reason one or more inner EAP method MSKs were not derived, then
these MSKs are assumed to be null.
<vspace blankLines="1"/>
If the EAP server has sent the success indication (Result
TLV=Success), the peer is allowed to refuse to accept a Success
message from the EAP server since the client's policy may require
completion of certain EAP methods or the client may require
credentials.
<vspace blankLines="1"/>
If the EAP server has sent a success indication (Result TLV=success),
and the peer wants authentication to fail, it sends the TLV response
with Result TLV=Failure and Crypto-Binding TLV.
<vspace blankLines="1"/>
After the EAP-server returns success, if the peer wants to request
the EAP server to continue conversation, it sends a Result
TLV=Success along with a Request-Action TLV with the appropriate
action (e.g. Negotiate-EAP, or Process-TLV). If the Request-Action
TLV is set to mandatory, then the EAP server MUST process the action,
or return status=failure, closing the conversation inside the tunnel.
If the Request-Action TLV is set to optional, then the EAP server can
ignore the TLV and return Result TLV=Success again, closing the
conversation inside the tunnel.
</t>
</section>
<section title="Provisioning of Credentials" anchor="P-O-C">
<t>
TEAM supports built-in provisioning of certificate trust anchors
and can be extended to provisioning of other types of credentials.
The following two provisioning modes are suported:
<vspace blankLines="1"/>
<list style="numbers">
<t>Provisioning inside a server authenticated TLS tunnel</t>
<t>Provisioning inside a server unauthenticated TLS tunnel</t>
</list>
</t>
<section title="Provisioning Inside a Server Authenticated TLS Tunnel" anchor="P-I-S-A-T">
<t>
After regular authentication in TEAM Phase 2, the peer and EAP
server can use the Server-Trusted-Root TLV to request and provision
peer credentials. The provisioning payload is exchanged after the
peer and EAP server have determined that both have successfully
authenticated each other (either thru TLS handshake and/or inner
EAP method), and the tunnel and inner EAP methods are between the
same peers.
<vspace blankLines="1"/>
After the peer has determined that it has successfully
authenticated the EAP server and determined that the tunnel and
inner EAP methods were between the same peer and EAP server by
validating the Crypto-Binding TLV, it MAY send one or more Server-
Trusted-Root TLVs (marked as optional) to request credentials from
the EAP server. The EAP server will send corresponding credentials
in the Server-Trusted-Root TLVs if its internal policy has been
satisfied. It may ignore the credential provisioning request or
request additional authentication methods if its policy so dictates.
The peer may receive a credential, but is not required to use the
credentials received from the EAP server.
</t>
</section>
<section title="Provisioning Inside a Server Unauthenticated TLS Tunnel" anchor="P-I-S-U-T">
<t>
In some cases, the peer may lack the credentials necessary to authenticate the
server in the TLS handshake. At the same time, bootstrapping the
information to the peer out of band may be prohibitive from a
deployment cost perspective. It can rely on the inner EAP method
using existing credentials to authenticate the server. This
provisioning mode provides ease of deployment at the cost of
introducing man-in-the-middle vulnerabilities. As a result,
implementation of the server unauthenticated tunnel provisioning
mode is OPTIONAL.
<vspace blankLines="1"/>
In this provisioning mode, as part of TEAM Phase 1, if the peer
does not authenticate, or does not successfully authenticate the
EAP server during TLS negotiation, it can decide to go into server
unauthenticated tunnel provisioning mode. While this section
describes negotiation of a certificate-based ciphersuite within
TLS, TEAM supports negotiation of other ciphersuites (for
example, ciphersuites that do not use certificates such as
anonymous DH) or extensions. However, the conversation may
slightly differ if other TLS ciphersuites or extensions are used.
For example, in a certificate based TLS handshake, the peer
verifies that the EAP server possesses the private key
corresponding to the public key contained in the certificate
presented by the EAP server. However, the peer does not verify
whether the certificate presented by the server chains to a
provisioned trust anchor, as the peer may not be configured with a
certificate trust anchor required to validate the server
certificate. If the peer cannot verify that the server possesses
the corresponding private key, or if the certificate presented by
the server is unacceptable for any reason other than the lack of an
appropriate trust anchor, the peer MUST NOT use this provisioning
mode. Assuming that the server demonstrates possession of the
private key, the peer continues with establishment of the tunnel
(TEAM Phase 2). As a result, it is possible that the TLS channel
(TEAM Phase 2) may be terminated by an attacker.
<vspace blankLines="1"/>
The TEAM Phase 2 conversation is unchanged in this mode, except
that the peer will only accept an EAP method supporting mutual
authentication and key derivation that is compatible with its
initial credentials (such as a password-based EAP method). The
peer then uses the Crypto-Binding TLV to validate that the same
server terminates both the TLS channel and the successfully
completed EAP method, thereby verifying that the exchange was not
subject to a man-in-the-middle attack. Assuming that the Crypto-
Binding TLV exchange is successful, the peer will request and the
server will subsequently provide a trusted root, using the Server-
Trusted-Root TLV.
<vspace blankLines="1"/>
Once the initial provisioning exchange completes, the peer is
expected to use the provisioned credentials in subsequent TEAM
authentications, and SHOULD NOT use this provisioning mode.
<vspace blankLines="1"/>
TEAM servers implementing this provisioning mode MUST support the
following additional ciphersuites, beyond those specified in
<xref target="T-S-E"/>:
<vspace blankLines="1"/>
<list>
<t>TLS_DH_anon_WITH_AES_128_CBC_SHA</t>
</list>
<vspace blankLines="1"/>
TEAM peers implementing this provisioning mode MAY support the
following additional ciphersuites, beyond those specified in <xref target="T-S-E"/>:
<vspace blankLines="1"/>
<list>
<t>TLS_DH_anon_WITH_AES_128_CBC_SHA</t>
</list>
</t>
</section>
</section>
</section>
<section title="Error Handling" anchor="E-H">
<t>
TEAM does not have its own error message capabilities since:
<vspace blankLines="1"/>
<list style="numbers">
<t>TLS errors are communicated via TLS alert messages.</t>
<t>
Errors within the EAP conversation in TEAM Phase 2 are expected to
be handled by individual EAP methods.
</t>
<t>
Violation of the TLV rules <xref target="TLV-R"/>
for inner-TLVs are handled using
Result-TLVs together with the Error-Code TLV.
</t>
</list>
<vspace blankLines="1"/>
If an error occurs at any point in the TLS layer, the EAP server
SHOULD send a TLS alert message instead of the next EAP-request
packet to the peer. The EAP server SHOULD send an EAP-Request packet
with EAP-Type=TEAM, encapsulating a TLS record containing the
appropriate TLS alert message. The EAP server SHOULD send a TLS
alert message rather than immediately terminating the conversation so
as to allow the peer to inform the user of the cause of the failure
and possibly allow for a restart of the conversation. To ensure that
the peer receives the TLS alert message, the EAP server MUST wait for
the peer to reply with an EAP-Response packet.
<vspace blankLines="1"/>
The EAP-Response packet sent by the peer MAY encapsulate a TLS
client_hello handshake message, in which case the EAP server MAY
allow the TEAM conversation to be restarted, or it MAY contain an
EAP-Response packet with EAP-Type=TEAM and no data, in which case the
TEAM server MUST send an EAP-Failure packet, and terminate the
conversation.
<vspace blankLines="1"/>
It is up to the EAP server whether to allow restarts, and if so, how
many times the conversation can be restarted. An EAP server
implementing restart capability SHOULD impose a limit on the number
of restarts, so as to protect against denial of service attacks.
<vspace blankLines="1"/>
If an error occurs at any point in the TLS layer, the peer SHOULD
send a TLS alert message instead of the next EAP-response packet to
the EAP server. The peer SHOULD send an EAP-Response packet with
EAP-Type=TEAM, encapsulating a TLS record containing the appropriate
TLS alert message. The EAP server may restart the conversation by
sending a EAP-Request packet encapsulating the TLS
hello_request_handshake message, in which case the peer MAY allow the
TEAM conversation to be restarted; or the EAP server can response
with EAP Failure.
<vspace blankLines="1"/>
Any time the peer or the EAP server finds an error when processing
the sequence of exchanges, such as a violation of the TLV rules <xref target="TLV-R"/>,
it should send a Result TLV of failure and Error-Code
TLV=Unexpected_TLVs_Exchanged (a Fatal error), and terminate the
tunnel. This is usually due to an implementation problem and is
considered an fatal error. The party that receives the Error-Code
TLV=Unexpected_TLVs_Exchanged should terminate the tunnel.
<vspace blankLines="1"/>
If a tunnel compromise error (<xref target="T-P-2">see</xref>)
is detected by the
Peer or EAP server, the party SHOULD send a Result TLV of failure
without a Crypto-Binding TLV, and Error-Code TLV=Tunnel-compromise-
error (a Fatal error), and terminate the tunnel. The party that
receives the Error-Code TLV=Tunnel-compromise error should terminate
the tunnel.
</t>
</section>
<section title="Fragmentation and Reassembly" anchor="F-R">
<t>
A single TLS record may be up to 16384 octets in length, but a TLS
message may span multiple TLS records, and a TLS certificate message
may in principle be as long as 16MB.
<vspace blankLines="1"/>
The group of TEAM messages sent in a single round may thus be
larger than the PPP MTU size, the maximum RADIUS packet size of 4096
octets, or even the Multilink Maximum Received Reconstructed Unit (MRRU).
<vspace blankLines="1"/>
As described in <xref target="RFC1990"/>,
the multilink MRRU is negotiated via the
Multilink MRRU LCP option, which includes an MRRU length field of two
octets, and thus can support MRRUs as large as 64 KB.
<vspace blankLines="1"/>
However, note that in order to protect against reassembly lockup and
denial of service attacks, it may be desirable for an implementation
to set a maximum size for one such group of TLS messages. Since a
typical certificate chain is rarely longer than a few thousand
octets, and no other field is likely to be anywhere near as long, a
reasonable choice of maximum acceptable message length might be 64 KB.
<vspace blankLines="1"/>
If this value is chosen, then fragmentation can be handled via the
multilink PPP fragmentation mechanisms described in <xref target="RFC1990"/>.
this is desirable, EAP methods are used in other applications such as
<xref target="IEEE.802-11.2007"/>
and there may be cases in which multilink or the MRRU LCP
option cannot be negotiated. As a result, a TEAM implementation
MUST provide its own support for fragmentation and reassembly.
<vspace blankLines="1"/>
Since EAP is an ACK-NAK protocol, fragmentation support can be added
in a simple manner. In EAP, fragments that are lost or damaged in
transit will be retransmitted, and since sequencing information is
provided by the Identifier field in EAP, there is no need for a
fragment offset field as is provided in IPv4.
<vspace blankLines="1"/>
TEAM fragmentation support is provided through addition of flag
bits within the EAP-Response and EAP-Request packets, as well as a
TLV Message Length field of four octets. Flags include the Length
included (L), More fragments (M), and TEAM Start (S) bits. The L
flag is set to indicate the presence of the four octet TLV Message
Length field, and MUST be set only for the first fragment of a
fragmented TLV message or set of messages.
<vspace blankLines="1"/>
The TLV Message Length field in the TEAM header is not protected,
and hence can be modified by a attacker. The TLS record length in
the TLS data is protected. Hence, if the TLV Message length received
in the first packet (with L bit set) is greater or less than the
total size of TLS messages received including multiple fragments,
then the TLV message length should be ignored.
<vspace blankLines="1"/>
In order to protect against reassembly lockup and denial of service
attacks, it may be desirable for an implementation to set a maximum
size for a single group of Outer-TLV messages. Since a typical
certificate chain is rarely longer than a few thousand octets, and no
other field is likely to be anywhere near as long, a reasonable
choice of maximum acceptable message length for all the Outer-TLVs in
a group of messages might be 64 KB.
<vspace blankLines="1"/>
The M flag is set on all but the last fragment. The S flag is set
only within the TEAM start message sent from the EAP server to the
peer. The TLV Message Length field is four octets, and provides the
total length of the TLV message or set of messages that is being
fragmented; this simplifies buffer allocation.
<vspace blankLines="1"/>
When a peer receives an EAP-Request packet with the M bit set, it
MUST respond with an EAP-Response with EAP-Type=TEAM and no data.
This serves as a fragment ACK. The EAP server MUST wait until it
receives the EAP-Response before sending another fragment. In order
to prevent errors in processing of fragments, the EAP server MUST
increment the Identifier field for each fragment contained within an
EAP-Request, and the peer MUST include this Identifier value in the
fragment ACK contained within the EAP-Response. Retransmitted
fragments will contain the same Identifier value.
<vspace blankLines="1"/>
Similarly, when the EAP server receives an EAP-Response with the M
bit set, it MUST respond with an EAP-Request with EAP-Type=TEAM and
no TLS data. This serves as a fragment ACK. The EAP peer MUST wait
until it receives the EAP-Request before sending another fragment.
In order to prevent errors in the processing of fragments, the EAP
server MUST increment the Identifier value for each fragment ACK
contained within an EAP-Request, and the peer MUST include this
Identifier value in the subsequent fragment contained within an EAP-
Response.
</t>
</section>
<section title="Key Derivation" anchor="K-D">
<t>
Since the normal TLS keys are used in the handshake, and therefore
should not be used in a different context, new keys must be derived
from the TLS master secret to protect the conversation within the
TEAM tunnel.
<vspace blankLines="1"/>
Instead of deriving keys specific to link layer ciphersuites, EAP
methods provide a Master Session Key (MSK) used to derive keys in a
link layer specific manner. The method used to extract ciphering
keys from the MSK is beyond the scope of this document.
<vspace blankLines="1"/>
TEAM also derives an Extended Master Session Key (EMSK) which is
reserved for use in deriving keys in other ciphering applications.
This draft also does not discuss the format of the attributes used to
communicate the master session keys from the backend authentication
server to the NAS; examples of such attributes are provided in <xref target="RFC2548"/>.
<vspace blankLines="1"/>
TEAM combines key material from the TLS exchange with key material
from inner key generating EAP methods to provide stronger keys and to
bind inner authentication mechanisms to the TLS tunnel. Both the
peer and EAP server MUST derive compound MAC and compound session
keys using the procedure described below.
<vspace blankLines="1"/>
The input for the cryptographic binding includes the following:
<vspace blankLines="1"/>
<list style="numbers">
<t>
The TEAM tunnel key (TK) is calculated using the first 40 octets
of the (secret) key material generated as described in the EAP-TLS
algorithm (<xref target="RFC5216">see Section 2.3 of</xref>)
More explicitly, the TK is the
first 40 octets of the PRF as defined in RFC 5216:
<vspace blankLines="1"/>
<list style="hanging" hangIndent="29">
<t hangText="Key_Material = TLS-PRF-128(">
master_secret, "client EAP encryption", client.random || server.random )
</t>
</list>
<vspace blankLines="1"/>
</t>
<t>
The first 32 octets of the MSK provided by each successful inner
EAP method for each successful EAP method completed within the tunnel.
<vspace blankLines="1"/>
ISK1..ISKn are the MSK portion of the EAP keying material obtained
from methods 1 to n. The ISKj SHALL be the first 32 octets of the
generated MSK of the jth EAP method. If the MSK length is less than
32 octets, it SHALL be padded with 0x00's to ensure the MSK is 32
octets. Similarly, if no keying material is provided for the EAP
method, then ISKj SHALL be set to zero (e.g. 32 octets of 0x00).
</t>
</list>
<vspace blankLines="1"/>
The PRF algorithm is based on PRF+ from IKEv2 <xref target="RFC5996"/>
shown below ("|" denotes concatenation).
<vspace blankLines="1"/>
<list>
<t>PRF (K,S,LEN) = T1 | T2 | T3 | T4 | ...</t>
</list>
<vspace blankLines="1"/>
Where:
<list>
<t>K = Key</t>
<t>S = Seed</t>
<t>LEN = output length, represented as binary in a single octet</t>
</list>
and
<list>
<t>T1 = HMAC-SHA1(K, S | LEN | 0x01)</t>
<t>T2 = HMAC-SHA1 (K, T1 | S | LEN | 0x02)</t>
<t>T3 = HMAC-SHA1 (K, T2 | S | LEN | 0x03)</t>
<t>T4 = HMAC-SHA1 (K, T3 | S | LEN | 0x04)</t>
<t>...</t>
</list>
<vspace blankLines="1"/>
The intermediate combined key is generated as described below
after each successful EAP method inside the tunnel.
<vspace blankLines="1"/>
<list>
<t>S-IPMK0 = TK</t>
<t>for j = 1 to k do</t>
<t>
<list style="hanging" hangIndent="15">
<t hangText="IPMKj = PRF+(">
S-IPMK(j-1),"Inner Methods Compound Keys " | ISKj, 60 )
</t>
</list>
</t>
</list>
<vspace blankLines="1"/>
Where
<list>
<t>
S-IPMKj are the first 40 octets of IPMKj
and CMKj are the last 20 octets of IPMKj used to generate
the intermediate Compound MACs
</t>
</list>
and
<list>
<t>
k = the last successful EAP method inside the tunnel at the point
where the combined MAC key is derived
</t>
</list>
<vspace blankLines="1"/>
Each IPMKj output is 60 octets. The first 40 octets are used as the
key input to the succeeding IPMK(j+1) derivation and the latter 20
octets are used as the key, CMKj, used to generate the intermediate
Crypto-Binding Compound MAC value at the jth EAP method.
</t>
<section title="Compound Session Key Derivation" anchor="C-S-K-D">
<t>
The compound session key (CSK) is derived on both the peer and EAP server:
<vspace blankLines="1"/>
<list>
<t>CSK = PRF+(S-IPMKn, "Session Key Generating Function", OutputLength)</t>
</list>
<vspace blankLines="1"/>
The output length of the CSK must be at least 128 bytes. The first 64
octets are taken as the MSK and the second 64 octets are taken as
the EMSK. The MSK and EMSK are described in <xref target="RFC3748"/>.
</t>
</section>
</section>
<section title="Ciphersuite Negotiation" anchor="C-N">
<t>
Since TLS supports TLS ciphersuite negotiation, peers completing the
TLS negotiation will also have selected a TLS ciphersuite, which
includes key strength, encryption and hashing methods. However,
unlike in <xref target="RFC5216"/>,
within TEAM, the negotiated TLS ciphersuite
relates only to the mechanism by which the TEAM Phase 2 conversation
will be protected, and has no relationship to link layer security
mechanisms negotiated within the PPP Encryption Control Protocol
(ECP) <xref target="RFC1968"/>
or within IEEE 802.11 <xref target="IEEE.802-11.2007"/>.
<vspace blankLines="1"/>
As a result, this specification currently does not support secure negotiation of link layer
ciphersuites.
</t>
</section>
</section>
<section title="TEAM Protocol Description" anchor="T-P-D">
<section title="TEAM Protocol Layers" anchor="T-P-L">
<t>
TEAM packets may include TLVs both inside and outside the TLS
tunnel. The term "Outer TLVs" is used to refer to optional TLVs
outside the TLS tunnel, which are only allowed in the first two
messages in the TEAM protocol. 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 messages is counted as one message. The
term "Inner TLVs" is used to refer to TLVs sent within the TLS
tunnel.
<vspace blankLines="1"/>
In TEAM Phase 1, Outer TLVs are used to help establishing the TLS
tunnel, but no Inner TLVs are used. Therefore the layering of TEAM Phase 1 is as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS | Optional Outer TLVs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TEAM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
In Phase 2 of the TEAM conversation, TLS records may encapsulate zero or more Inner
TLVs, but no Outer TLVs. EAP packets (including EAP header fields)
used within tunneled EAP authentication methods are carried within
Inner TLVs. Therefore the layering of TEAM Phase 2 is as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner-TLVs (EAP-Payload TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TEAM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
</t>
</section>
<section title="TEAM Packet Format" anchor="T-P-F">
<t>
A summary of the TEAM packet format is shown below. The fields are
transmitted from left to right.
<figure align="center" suppress-title="true"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Flags | Ver | Fragment Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fragment Message Length | TLS Message Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLS Message Length | TLS Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="Code">
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="1 -">Request</t>
<t hangText="2 -">Response</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Identifier">
<vspace blankLines="1"/>
The Identifier field is one octet and aids in matching responses
with requests. The Identifier field MUST be changed on each
Request packet. The Identifier field in a Response packet MUST
match the Identifier field from the corresponding Request.
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
The Length field is two octets and indicates the length of the EAP
packet including the Code, Identifier, Length, Type, Flags,
Version, Fragmented Length, TLS Message Length, TLS Data, and
Outer-TLV fields. Octets outside the range of the Length field
should be treated as Data Link Layer padding and should be ignored
on reception.
<vspace blankLines="1"/>
</t>
<t hangText="Type">
<vspace blankLines="1"/>
<TBD1> - TEAM
<vspace blankLines="1"/>
</t>
<t hangText="Flags">
<figure align="left" suppress-title="true"><artwork><![CDATA[
0 1 2 3 4
+-+-+-+-+-+
|L M S T R|
+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="L =">Length included</t>
<t hangText="M =">More fragments</t>
<t hangText="S =">TEAM start</t>
<t hangText="T =">TLS length included</t>
<t hangText="R =">Reserved (must be zero)</t>
</list>
<vspace blankLines="1"/>
The L bit (Fragmented Message Length included) is set to indicate
the presence of the four octet Fragmented Message Length field,
and MUST be set for the first fragment of a fragmented TEAM
message or set of messages. The M bit (more fragments) is set on
all but the last fragment. The S bit (TEAM start) is set in a
TEAM Start message. This differentiates the TEAM Start message
from a fragment acknowledgment. The T bit (TLS Message Length
included) is set to indicate the presence of the four octet TLS
Message Length field, and MUST only be set for packet that
contains Outer-TLVs. It can be used to calculate the start of the
Outer-TLVs.
<vspace blankLines="1"/>
</t>
<t hangText="Version">
<figure align="left" suppress-title="true"><artwork><![CDATA[
0 1 2
+-+-+-+
|R|0|1|
+-+-+-+
]]></artwork></figure>
R = Reserved (must be zero)
<vspace blankLines="1"/>
</t>
<t hangText="Fragmented Message Length">
<vspace blankLines="1"/>
The Fragmented Message Length field is four octets, and is present
only if the L bit is set. This field provides the total length of
the data after the Fragmented Message Length field in the TEAM
message or set of messages that is being fragmented.
<vspace blankLines="1"/>
</t>
<t hangText="TLS Message Length">
<vspace blankLines="1"/>
The TLS Message Length field is four octets, and is present only
if the T bit is set. This field provides the total length of the
TLS Data in the TEAM message. Data after this length of TLS data
are the Outer TLVs.
<vspace blankLines="1"/>
</t>
<t hangText="TLS Data">
<vspace blankLines="1"/>
The TLS data consists of the encapsulated packet in TLS record format.
<vspace blankLines="1"/>
</t>
<t hangText="Outer TLVs">
<vspace blankLines="1"/>
The Outer-TLVs consists of the optional data used to help
establishing the TLS tunnel in TLV format. The start of the
Outer-TLV can be derived from the EAP Length field and TLS Length
field.
</t>
</list>
</t>
</section>
</section>
<section title="Type-Length-Value Tuples" anchor="TLV-T">
<t>
The TLVs used within TEAM are standard Type-Length-Value (TLV)
objects. The TLV objects could be used to carry arbitrary parameters
between EAP peer and EAP server. Possible uses for TLV objects
include: language and character set for Notification messages and
cryptographic binding.
<vspace blankLines="1"/>
The EAP peer may not necessarily implement all the TLVs supported by
the EAP server; and hence to allow for interoperability, TLVs allow
an EAP server to discover if a TLV is supported by the EAP peer,
using the NAK TLV. The TEAM packet does not have to contain any
TLVs, nor need it contain any mandatory TLVs.
<vspace blankLines="1"/>
The mandatory bit in a TLV indicates whether support of the TLV is
required. If the peer or server does not support the TLV, it MUST
send a NAK TLV in response, and all the other TLVs in the message
MUST be ignored. If an EAP peer or server finds an unsupported TLV
which is marked as optional, it can ignore the unsupported TLV. It
MUST NOT send an NAK TLV.
<vspace blankLines="1"/>
Note that a peer or server may support a TLV with the mandatory bit
set, but may not understand the contents. The appropriate response
to a supported TLV with content that is not understood is defined by
the TLV specification.
<vspace blankLines="1"/>
Outer-TLVs SHOULD NOT be included in messages after the first two
Outer-TLV messages sent by the peer and EAP server respectively. A
single Outer-TLV message may be fragmented in multiple TEAM packets.
<vspace blankLines="1"/>
All Outer-TLVs MUST NOT have the mandatory bit set. If an Outer-TLV
has the mandatory bit set, then the packet MUST be ignored.
<vspace blankLines="1"/>
TEAM implementations MUST support TLVs, as well as processing of
mandatory/optional settings on the TLV.
</t>
<section title="TLV Format" anchor="TLV-F">
<t>
TLVs are defined as described below. The fields are transmitted from left to right.
<figure align="left" suppress-title="true"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="0 -">Optional TLV</t>
<t hangText="1 -">Mandatory TLV</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
Reserved, set to zero (0)
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
A 14-bit field, denoting the TLV type. Allocated types include:
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="1 -">Result</t>
<t hangText="2 -">NAK</t>
<t hangText="3 -">Error-Code</t>
<t hangText="4 -">Connection-Binding</t>
<t hangText="5 -">Vendor-Specific</t>
<t hangText="6 -">URI</t>
<t hangText="7 -">EAP-Payload</t>
<t hangText="8 -">Intermediate-Result</t>
<t hangText="9 -">Crypto-Binding</t>
<t hangText="10 -">Calling-Station-Id</t>
<t hangText="11 -">Called-Station-Id </t>
<t hangText="12 -">NAS-Port-Type</t>
<t hangText="13 -">Server-Identifier</t>
<t hangText="14 -">Identity-Type</t>
<t hangText="15 -">Server-Trusted-Root</t>
<t hangText="16 -">Request-Action</t>
<t hangText="17 -">PKCS#7</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
The length of the Value field in octets
<vspace blankLines="1"/>
</t>
<t hangText="Value">
<vspace blankLines="1"/>
The value of the TLV
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Result TLV" anchor="R-TLV">
<t>
The Result TLV provides support for acknowledged success and failure
messages within TEAM. TEAM implementations MUST support this
TLV, which cannot be responded to with a NAK TLV. If the Status
field does not contain one of the known values, then the peer or EAP
server MUST drop the connection. The Result TLV is defined as
follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
1 for Result
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
2
<vspace blankLines="1"/>
</t>
<t hangText="Status">
<vspace blankLines="1"/>
The Status field is two octets. Values include:
<vspace blankLines="1"/>
<list>
<t hangText="1 -">Success</t>
<t hangText="2 -">Failure</t>
</list>
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="NAK TLV" anchor="N-TLV">
<t>
The NAK TLV allows a peer to detect TLVs that are not supported by
the other peer. A TLV packet can contain 0 or more NAK TLVs. TEAM
implementations MUST support the NAK TLV, which cannot be responded
to with a NAK TLV. The NAK TLV is defined as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
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....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
2 for NAK
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 6
<vspace blankLines="1"/>
</t>
<t hangText="Vendor-ID">
<vspace blankLines="1"/>
The Vendor-Id field is four octets, and contains the Vendor-Id of
the TLV that was not supported. The high-order octet is 0 and the
low-order 3 octets are the SMI Network Management Private
Enterprise Code of the Vendor in network byte order. The Vendor-
Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
<vspace blankLines="1"/>
</t>
<t hangText="NAK-Type">
<vspace blankLines="1"/>
The NAK-Type field is two octets. The field contains the Type of
the TLV that was not supported. A TLV of this Type MUST have been
included in the previous packet.
<vspace blankLines="1"/>
</t>
<t hangText="TLVs">
<vspace blankLines="1"/>
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.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Error-Code TLV" anchor="E-C-TLV">
<t>
The Error-Code TLV allows a TEAM peer or server to indicate errors
to the other party. A TLV packet can contain 0 or more Error TLVs.
Error-Code TLVs MUST be marked as Mandatory. TEAM implementations
MUST support the Error-Code TLV, which cannot be responded to with a
NAK TLV. The Error-Code TLV is defined as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error-Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
3 for Error-Code
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
4
<vspace blankLines="1"/>
</t>
<t hangText="Error-Code">
<vspace blankLines="1"/>
The Error-Code field is four octets. Error Codes 1-999 represent
successful outcomes (informative messages), 1000-1999 represent
warnings, and codes 2000-2999 represent fatal errors. If an Error-
Code TLV with a fatal error has been sent, then the conversation
must be terminated.
<vspace blankLines="1"/>
Currently defined values for Error-Code include:
<vspace blankLines="1"/>
<list>
<t hangText="2001 -">Tunnel_Compromise_Error</t>
<t hangText="2002 -">Unexpected_TLVs_Exchanged</t>
</list>
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Crypto-Binding TLV" anchor="Cryp-B-TLV">
<t>
The Crypto-Binding TLV is used prove that both peers participated in
the sequence of authentications (specifically the TLS session and
inner EAP methods that generate keys).
<vspace blankLines="1"/>
Both the Binding Request (B1) and Binding Response (B2) use the same
packet format. However the Sub-Type indicates whether it is B1 or B2.
<vspace blankLines="1"/>
The Crypto-Binding TLV MUST be used to perform Cryptographic Binding
after each successful EAP method in a sequence of EAP methods is
complete in TEAM Phase 2. The Crypto-Binding TLV can also be used
during Protected Termination.
<vspace blankLines="1"/>
The Crypto-Binding TLV must have the version number received during
the TEAM version negotiation. The receiver of the Crypto-Binding TLV
must verify that the version in the Crypto-Binding TLV matches the
version it sent during the TEAM version negotiation. If this check
fails then the TLV is invalid.
<vspace blankLines="1"/>
The receiver of the Crypto-Binding TLV must verify that the subtype
is not set to any value other than the ones allowed. If this check
fails then the TLV is invalid.
<vspace blankLines="1"/>
This message format is used for the Binding Request (B1) and also the
Binding Response. This uses TLV type CRYPTO_BINDING_TLV. TEAM
implementations MUST support this TLV and this TLV cannot be
responded to with a NAK TLV. The Crypto-Binding TLV is defined as
follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 | Version | Received Ver. | Sub-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Nonce ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Compound MAC ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
9 for Crypto-Binding
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
56
<vspace blankLines="1"/>
</t>
<t hangText="Reserved">
<vspace blankLines="1"/>
Reserved, set to zero (0)
<vspace blankLines="1"/>
</t>
<t hangText="Version">
<vspace blankLines="1"/>
The Version field is a single octet, which is set to the version
of Crypto-Binding TLV. For the Crypto-Binding TLV defined in this
specification, it is set to one (1).
<vspace blankLines="1"/>
</t>
<t hangText="Sub-Type">
<vspace blankLines="1"/>
The Sub-Type field is two octets. Possible values include:
<vspace blankLines="1"/>
<list style="hanging">
<t hangText="0 -">Binding Request</t>
<t hangText="1 -">Binding Response</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="Nonce">
<vspace blankLines="1"/>
The Nonce field is 32 octets. It contains a 256 bit nonce that is
temporally unique, used for compound MAC key derivation at each
end. This is the S_NONCE for the B1 message and a C_NONCE for the
B2 message.
<vspace blankLines="1"/>
</t>
<t hangText="Compound MAC">
<vspace blankLines="1"/>
The Compound MAC field is 20 octets. This can be the Server MAC
(B1_MAC) or the Client MAC (B2_MAC). It is computed using the
HMAC-SHA1-160 keyed MAC that provides 160 bits of output using the
CMK key. The MAC is computed over the buffer created after
concatenating these fields in the following order:
<vspace blankLines="1"/>
<list style="numbers">
<t>
The entire Crypto-Binding TLV attribute with the MAC field zeroed out
</t>
<t>
The EAP Type sent by the other party in the first TEAM message
</t>
<t>
All the Outer-TLVs from the first TEAM message sent by EAP-server
to peer. If a single TEAM message is fragmented into multiple TEAM
packets; then the Outer-TLVs in all the fragments of that message
MUST be included.
</t>
<t>
All the Outer-TLVs from the first TEAM message sent by the peer to
the EAP server. If a single TEAM message is fragmented into
multiple TEAM packets, then the Outer-TLVs in all the fragments of
that message MUST be included.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Connection-Binding TLV" anchor="Conn-B-TLV">
<t>
The Connection-Binding TLV allows for connection specific information
to be sent by the peer to the AAA server. This TLV should be logged
by the EAP or AAA server. The AAA or EAP server should not deny
access if there is a mismatch between the value sent through the AAA
protocol and this TLV.
<vspace blankLines="1"/>
The format of this TLV is defined for the layer that defines the
parameters. The format of the value sent by the peer to the EAP
server may be different from the format of the corresponding value
sent through the AAA protocol. For example, the connection binding
TLV may contain the 802.11 MAC Address or SSID <xref target="IEEE.802-11.2007"/>.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV and this TLV MUST NOT be
responded to with a NAK TLV. The Connection-Binding TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
4 for Connection-Binding
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 0
<vspace blankLines="1"/>
</t>
<t hangText="TLVs">
<vspace blankLines="1"/>
The field contains a list of TLVs, each in the same format defined
in <xref target="TLV-F"/>,
with the Mandatory flag bit cleared (0). These TLVs contain
information on the identity of the peer and authenticator (layer 2
or IP addresses); the media used to connect the peer and
authenticator (NAS-Port-Type); and/or the service the client is
trying to access on the gateway (SSID). See <xref target="C-B-T-R"/> for further
information.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Vendor-Specific TLV" anchor="V-S-TLV">
<t>
The Vendor-Specific TLV is available to allow vendors to support
their own extended attributes not suitable for general usage.
<vspace blankLines="1"/>
A Vendor-Specific-TLV can contain one or more TLVs,
referred to as Vendor TLVs. The TLV-type of the Vendor-TLV will be
defined by the vendor. All the Vendor TLVs inside a single Vendor-
Specific TLV belong to the same vendor.
<vspace blankLines="1"/>
TEAM implementations MUST support the Vendor-Specific TLV, and this
TLV MUST NOT be responded to with a NAK TLV. TEAM implementations
may not support the Vendor TLVs inside in the Vendor-Specific TLV,
and can respond to the Vendor TLVs with a NAK TLV containing the
appropriate Vendor-ID and Vendor-TLV type.
<vspace blankLines="1"/>
Vendor TLVs may be optional or mandatory. Vendor TLVs sent in the
protected success and failure packets MUST be marked as optional. If
Vendor TLVs sent in protected success/failure packets are marked as
Mandatory, then the peer or EAP server MUST drop the connection.
<vspace blankLines="1"/>
The Vendor-Specific TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
5 for Vendor-Specific
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 4
<vspace blankLines="1"/>
</t>
<t hangText="Vendor-ID">
<vspace blankLines="1"/>
The Vendor-Id field is four octets, and contains the Vendor-Id of
the TLV that was not supported. The high-order octet is 0 and the
low-order 3 octets are the SMI Network Management Private
Enterprise Code of the Vendor in network byte order. The Vendor-
Id field MUST be zero for TLVs that are not Vendor-Specific TLVs.
For Vendor-Specific TLVs, the Vendor-ID MUST be set to the SMI code.
<vspace blankLines="1"/>
</t>
<t hangText="Vendor TLVs">
<vspace blankLines="1"/>
This field is of indefinite length. It contains vendor-specificTLVs,
in a format defined by the vendor.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="URI TLV" anchor="U-TLV">
<t>
The URI TLV allows a server to send a URI to the client to refer it
to a resource. The TLV contains a URI in the format specified in
RFC 3986 <xref target="RFC3986"/>
with UTF-8 encoding. Interpretation of the value of the URI
is outside the scope of this document.
<vspace blankLines="1"/>
If a packet contains multiple URI TLVs, then the client SHOULD select
the first TLV it can implement, and ignore the others. If the client
is unable to implement any of the URI TLVs, then it MAY ignore the
error. TEAM implementations MAY support this TLV; and this TLV
cannot be responded to with a NAK TLV. The URI TLV is defined as
follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
6 for URI
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 0
<vspace blankLines="1"/>
</t>
<t hangText="URI">
<vspace blankLines="1"/>
This field is of indefinite length, and conforms to the format specified in RFC 3986.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="EAP-Payload TLV" anchor="E-P-TLV">
<t>
To allow piggybacking EAP request and response with other TLVs, the
EAP Payload TLV is defined, which includes an encapsulated EAP packet
and 0 or more TLVs. TEAM implementations MUST support this TLV,
which cannot be responded to with a NAK TLV. The EAP-Payload TLV is
defined as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EAP-Packet...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
7 for EAP-Payload
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 0
<vspace blankLines="1"/>
</t>
<t hangText="EAP-Packet">
<vspace blankLines="1"/>
This field contains a complete EAP packet, including the EAP
header (Code, Identifier, Length, Type) fields. The length of
this field is determined by the Length field of the encapsulated
EAP packet.
<vspace blankLines="1"/>
</t>
<t hangText="TLVs">
<vspace blankLines="1"/>
This (optional) field contains a list of TLVs associated with the
EAP-Packet field (see <xref target="E-P-T-R"/>).
The TLVs utilize the same format described
<xref target="TLV-F"/>,
and MUST NOT have the mandatory bit set. The total
length of this field is equal to the Length field of the EAP-
Payload-TLV, minus the Length field in the EAP header of the EAP
packet field.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Intermediate-Result TLV" anchor="I-R-TLV">
<t>
The Intermediate-Result TLV provides support for acknowledged
intermediate Success and Failure messages within EAP. TEAM
implementations MUST support this TLV, which cannot be responded to
with a NAK TLV. The Intermediate-Result TLV is defined as follows:
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
8 for Intermediate-Result
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 2
<vspace blankLines="1"/>
</t>
<t hangText="Status">
<vspace blankLines="1"/>
The Status field is two octets. Values include:
<vspace blankLines="1"/>
<list>
<t>1 - Success</t>
<t>2 - Failure</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="TLVs">
<vspace blankLines="1"/>
This (optional) field contains a list of TLVs associated with the
Intermediate-Result TLV. The TLVs utilize the same format described
<xref target="TLV-F"/>,
and MUST NOT have the mandatory bit set.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Calling-Station-Id TLV" anchor="Cg-S-TLV">
<t>
This TLV allows a peer to send information to EAP server about the
call originator. This TLV MAY be included in the Connection-Binding-
TLV.
<vspace blankLines="1"/>
For dial-up, the Called-Station-ID TLV contains the phone number of
the peer. For use with IEEE 802.1X, the MAC address of the peer is
included <xref target="RFC3580"/>.
<vspace blankLines="1"/>
For VPN, this attribute is used to send the IPv4 or IPV6 address of
the interface of the peer used to initiate the VPN in ASCII format.
Where the Fully Qualified Domain Name (FQDN) of the VPN client is
known, it SHOULD be appended, separated from the address with a " "
(space). Example: "12.20.2.3 vpnserver.example.com".
<vspace blankLines="1"/>
As described in <xref target="RFC3748">Section 7.15 of</xref>,
this TLV SHOULD be logged by
the EAP or AAA server, and MAY be used for comparison with
information gathered by other means.
<vspace blankLines="1"/>
However, since the format of this TLV may not match the format of the
information gathered by other means, if an EAP server or AAA server
supports the capability to deny access based on a mismatch, spurious
authentication failures may occur. As a result, implementations
SHOULD allow the administrator to disable this check.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV and this TLV MUST NOT be
responded to with a NAK TLV. The Calling-Station-ID TLV is defined
as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
10 for Calling-Station-Id
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 0
<vspace blankLines="1"/>
</t>
<t hangText="String">
<vspace blankLines="1"/>
The field should be the same as the value of the Calling-Station-ID attribute in
<xref target="RFC2865"/>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Called-Station-Id TLV" anchor="Cd-S-TLV">
<t>
This TLV allows a peer to send information to EAP server about the
NAS it called. This TLV MAY be included in the Connection-Binding
TLV.
<vspace blankLines="1"/>
For dial-up, the Calling-Station-ID TLV contains the phone number
called by the peer. For use with IEEE 802.1X, the MAC address of the
NAS is included, as specified in <xref target="RFC3580"/>.
<vspace blankLines="1"/>
For VPN, this attribute is used to send the IPv4 or IPv6 address of
VPN server in ASCII format. Where the Fully Qualified Domain Name
(FQDN) of the VPN server is known, it SHOULD be appended, separated
from the address with a " " (space). Example: "12.20.2.3
vpnserver.example.com".
<vspace blankLines="1"/>
This TLV SHOULD be logged by the EAP or AAA server, and MAY be used
for comparison with information gathered by other means. However,
since the format of this TLV may not match the format of the
information gathered by other means, if an EAP server or AAA server
supports the capability to deny access based on a mismatch, spurious
authentication failures may occur. As a result, implementations
SHOULD allow the administrator to disable this check.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV, and this TLV MUST NOT be
responded to with a NAK TLV. The Called-Station-ID TLV is defined as
follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
11 for Called-Station-Id
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
>= 0
<vspace blankLines="1"/>
</t>
<t hangText="String">
<vspace blankLines="1"/>
The field should be the same as the value of the Called-Station-ID attribute in
<xref target="RFC2865"/>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="NAS-Port-Type TLV" anchor="N-P-T-TLV">
<t>
This TLV allows a peer to send information to EAP server about the
type of physical connection used by the peer to connect to NAS. This
TLV MAY be included in the Connection-Binding-TLV.
<vspace blankLines="1"/>
The value of this field is the same as the value of NAS-Port-Type
attribute in <xref target="RFC2865"/>.
<vspace blankLines="1"/>
This TLV SHOULD be logged by the EAP or AAA server and MAY be used
for comparison with information gathered by other means. However,
since the format of this TLV may not match the format of the
information gathered by other means, if an EAP server or AAA server
supports the capability to deny access based on a mismatch, spurious
authentication failures may occur. As a result, implementations
SHOULD allow the administrator to disable this check.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV; and this TLV MUST NOT be
responded to with a NAK TLV. The NAS-Port-Type TLV is defined as
follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
12 for NAS-Port-Type
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
4
<vspace blankLines="1"/>
</t>
<t hangText="String">
<vspace blankLines="1"/>
The String field is four octets.
Values are the same as for the NAS-Port-Type attribute defined in
<xref target="RFC2865"/>.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Server-Identifier TLV" anchor="S-I-TLV">
<t>
This TLV allows a EAP server to send a hint to the EAP peer to help
the EAP peer select the appropriate sessionID for session resumption.
The field is a string sent by the EAP server, and the field should be
treated as a opaque string by the peer. During a full-tls-handshake,
the EAP peer MAY keep track of this field and the corresponding
sessionID, and use it as a hint to select the appropriate sessionID
during session resumption.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV and this TLV MUST NOT be
responded to with a NAK TLV. The Server-Identifier TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
13 for Server-Identifier
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
≥ 0
<vspace blankLines="1"/>
</t>
<t hangText="String">
<vspace blankLines="1"/>
Contains an identifier sent by the EAP server.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Identity-Type TLV" anchor="I-T-TLV">
<t>
The Identity-Type TLV allows an EAP-server to send a hint to help the
EAP-peer select the right type of identity; for example; user or
machine.
<vspace blankLines="1"/>
TEAM implementations MAY support this TLV, which cannot be
responded to with a NAK TLV.
<vspace blankLines="1"/>
If the Identity-type field does not contain one of the known values
or if the EAP peer does not have an identity corresponding to the
identity-type, then the peer MUST ignore the value. The Identity-
Type TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identity-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
14 for Identity-Type
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
2
<vspace blankLines="1"/>
</t>
<t hangText="Identity-Type">
<vspace blankLines="1"/>
The Identity-Type field is two octets. Values include:
<list>
<t>1 - Human</t>
<t>2 - Machine</t>
</list>
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Server-Trusted-Root TLV" anchor="S-T-R-TLV">
<t>
The Server-Trusted-Root TLV allows the peer to send a request to the
EAP server for a trusted root in PKCS #7 format.
<vspace blankLines="1"/>
The Server-Trusted-Root TLV is always marked as optional, and cannot
be responded to with a NAK TLV. TEAM server implementations that
claim to support provisioning MUST support Server-Trusted-Root TLV,
PKCS#7 TLV, and the PKCS#7-Server-Certificate-Root credential format
defined in this TLV. TEAM peer implementations may not support
this TLV.
<vspace blankLines="1"/>
The Server-Trusted-Root TLV can only be sent as an inner TLV (inside the
TEAM Phase 2 conversation), in both server unauthenticated tunnel
provisioning mode, and the regular authentication process.
<vspace blankLines="1"/>
The peer MUST NOT request, or accept the trusted root sent inside the
Server-Root credential TLV by the EAP-server until it has completed
authentication of the EAP server, and validated the Crypto-Binding TLV.
The peer may receive a trusted root, but is not required to use the
trusted root received from the EAP server.
<vspace blankLines="1"/>
If the EAP server sets credential-format to PKCS#7-Server-
Certificate-Root, then the Server-Trusted-Root TLV MUST contain the
root of the certificate chain of the certificate issued to the EAP
server packages in a PKCS#7 TLV. If the Server certificate is a
self-signed certificate, then the root is the self-signed
certificate. In this case, the EAP server does not have to sign the
certificate inside the PCKS#7 TLV since it does not necessarily have access to
the private key for it.
<vspace blankLines="1"/>
If the Server-Trusted-Root TLV credential format does not contain one
of the known values, then the EAP-server MUST ignore the value.
<vspace blankLines="1"/>
The Server-Trusted-Root TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Credential Type | TLVs...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
15 for Server-Trusted-Root
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
≥ 2
<vspace blankLines="1"/>
</t>
<t hangText="Credential Type">
<vspace blankLines="1"/>
The Credential Type field is two octets. Values include:
<list>
<t>1 - PKCS#7-Server-Certificate-Root</t>
</list>
<vspace blankLines="1"/>
</t>
<t hangText="TLVs">
<vspace blankLines="1"/>
This (optional) field contains a list of TLVs associated with the
Server-Trusted-Root TLV. The TLVs utilize the same format described
<xref target="TLV-F"/>
and MUST NOT have the mandatory bit set. See <xref target="S-T-R-T-R"/>
for further information.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="PKCS#7 TLV" anchor="PKCS-TLV">
<t>
This
TLV contains a certificate or certificate chain requested by the peer in
PKCS#7
format <xref target="RFC2315"/>.
<vspace blankLines="1"/>
The PKCS#7 TLV is always marked as optional, and cannot be
responded to with a NAK TLV. TEAM server implementations that
claim to support provisioning MUST support this TLV. TEAM peer
implementations may not support this TLV.
<vspace blankLines="1"/>
If the PKCS#7 TLV contains a certificate or certificate chain that is
not acceptable to the peer, then peer MUST ignore the value.
<vspace blankLines="1"/>
The PKCS#7 TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PKCS#7 data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
0 (Optional)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
17 for PKCS#7
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
≥ 0
<vspace blankLines="1"/>
</t>
<t hangText="PKCS#7 Data">
<vspace blankLines="1"/>
This field contains a certificate or certificate chain in PKCS#7 format.
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Request-Action-TLV" anchor="R-A-TLV">
<t>
The Request-Action TLV MAY be sent by the peer along with
acknowledged failure. It allows the peer to request the EAP server
to negotiate EAP methods or process TLVs specified in the failure
packet. The server MAY ignore this TLV.
<vspace blankLines="1"/>
TEAM implementations MUST support this TLV, which cannot be
responded to with a NAK TLV.
<vspace blankLines="1"/>
The Request-Action TLV is defined as follows:
<vspace blankLines="1"/>
<figure align="center" suppress-title="true"><artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Action |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<list style="hanging">
<t hangText="M">
<vspace blankLines="1"/>
1 (Mandatory)
<vspace blankLines="1"/>
</t>
<t hangText="R">
<vspace blankLines="1"/>
0
<vspace blankLines="1"/>
</t>
<t hangText="TLV Type">
<vspace blankLines="1"/>
16 for Request-Action
<vspace blankLines="1"/>
</t>
<t hangText="Length">
<vspace blankLines="1"/>
2
<vspace blankLines="1"/>
</t>
<t hangText="Action">
<vspace blankLines="1"/>
The Action field is two octets. Values include:
<vspace blankLines="1"/>
<list>
<t>0 - Reserved</t>
<t>1 - Process-TLV</t>
<t>2 - Negotiate-EAP</t>
</list>
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="TLV Rules" anchor="TLV-R">
<t>
To save round trips, multiple TLVs can be sent in the single TEAM
packet. However, the encapsulation of multiple EAP Payload TLVs within a single TEAM
packet is not supported in this version and MUST NOT be sent. If the
peer or EAP server receives multiple EAP Payload TLVs, then it MUST
drop the connection.
<vspace blankLines="1"/>
<?rfc needLines="10"?>
The following table defines the meaning of the table entries in the sections below:
<vspace blankLines="1"/>
<list style="hanging" hangIndent="5">
<t hangText="0">This TLV MUST NOT be present in the packet</t>
<t hangText="0+">Zero or more instances of this TLV MAY be present in packet</t>
<t hangText="0-1">Zero or one instances of this TLV MAY be present in packet</t>
<t hangText="1">Exactly one instance of this TLV MUST be present in packet</t>
</list>
</t>
<section title="Outer TLVs">
<texttable align="left" suppress-title="true">
<preamble>
The following table provides a guide to which TLVs may be included in the TEAM packet outside the TLS channel, which kind of packets, and in what quantity:
</preamble>
<ttcol align="left">Request</ttcol>
<ttcol align="left">Response</ttcol>
<ttcol align="left">Success</ttcol>
<ttcol align="left">Failure</ttcol>
<ttcol align="left">TLV in unencrypted-TLVs field</ttcol>
<c>0-1</c>
<c>0</c>
<c>0</c>
<c>0</c>
<c>Server-Identifier TLV</c>
<c>0+</c>
<c>0+</c>
<c>0</c>
<c>0</c>
<c>Vendor-Specific TLV</c>
</texttable>
<t>
Outer-TLVs MUST be marked as optional. Vendor-TLVs inside a Vendor-Specific TLV MUST
be marked as optional when included in Outer TLVs.
Outer-TLVs MUST NOT be included in messages after the first two
TEAM messages sent by peer and EAP-server respectively, i.e.,
the first EAP server to peer message and first peer to EAP server
message. If a message is fragmented, the whole set of fragments is
counted as one message. If Outer-TLVs are included in messages after
the first two TEAM messages, they MUST be ignored.
</t>
</section>
<section title="Inner TLVs">
<texttable align="left" suppress-title="true">
<preamble>
The following table provides a guide to which Inner TLVs may be
encapsulated in TLS in TEAM Phase 2, in which kind of packets, and
in what quantity:
</preamble>
<ttcol align="left">Request</ttcol>
<ttcol align="left">Response</ttcol>
<ttcol align="left">Success</ttcol>
<ttcol align="left">Failure</ttcol>
<ttcol align="left">Inner TLV</ttcol>
<c>0-1</c>
<c>0-1</c>
<c>0-1</c>
<c>0-1</c>
<c>Intermediate-Result</c>
<c>0-1</c>
<c>0-1</c>
<c>0</c>
<c>0</c>
<c>EAP-Payload</c>
<c>0-1</c>
<c>0-1</c>
<c>1</c>
<c>1</c>
<c>Result</c>
<c>0-1</c>
<c>0-1</c>
<c>1</c>
<c>1</c>
<c>Crypto-Binding</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>Error</c>
<c>0+</c>
<c>0+</c>
<c>0</c>
<c>0</c>
<c>NAK</c>
<c>0-1</c>
<c>0-1</c>
<c>0-1</c>
<c>0-1</c>
<c>Connection-Binding</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>Vendor-Specific</c>
<c>0+</c>
<c>0</c>
<c>0+</c>
<c>0-1</c>
<c>URI</c>
<c>0+</c>
<c>0</c>
<c>0</c>
<c>0</c>
<c>Identity-Type</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>0+</c>
<c>Server-Trusted-Root</c>
<c>0</c>
<c>0-1</c>
<c>0</c>
<c>0-1</c>
<c>Request-Action</c>
<postamble>
Vendor TLVs (included in Vendor-Specific TLVs) sent in the protected
success and failure packets MUST be marked as optional. If Vendor
TLVs sent in protected success/failure packets are marked as
Mandatory, then the peer or EAP server MUST drop the connection.
</postamble>
</texttable>
<texttable align="left">
<ttcol align="left">Packet Type</ttcol>
<ttcol align="left">Description</ttcol>
<c>Request</c>
<c>TLS packet sent by the EAP server to the peer</c>
<c>Response</c>
<c>TLS packet sent by the peer to the EAP server</c>
<c>Success</c>
<c>TLS packet sent by the peer or EAP server as a protected success indication</c>
<c>Failure</c>
<c>TLS packet sent by the peer or EAP server as a protected failure indication</c>
</texttable>
</section>
<section title="EAP-Payload TLV" anchor="E-P-T-R">
<texttable align="left">
<preamble>
The EAP-Payload TLV can contain other TLVs. The table below defines
which TLVs can be contained inside the EAP-Payload TLV and how many
such TLVs can be included.
</preamble>
<ttcol align="left">Request</ttcol>
<ttcol align="left">Response</ttcol>
<ttcol align="left">TLV</ttcol>
<c>0+</c>
<c>0+</c>
<c>Vendor-Specific</c>
<c>0+</c>
<c>0+</c>
<c>Identity-Type</c>
<postamble>
Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as optional when
included in an EAP-Payload TLV.
</postamble>
</texttable>
</section>
<section title="Connection-Binding" anchor="C-B-T-R">
<texttable align="left">
<preamble>
The Connection-Binding TLV can contain other TLVs. The table below defines
which TLVs can be contained inside the Connection-Binding TLV and how many
such TLVs can be included.
</preamble>
<ttcol align="left">Request</ttcol>
<ttcol align="left">Response</ttcol>
<ttcol align="left">TLV</ttcol>
<c>0-1</c>
<c>0</c>
<c>Calling-Station-ID</c>
<c>0-1</c>
<c>0</c>
<c>Called-Station-ID</c>
<c>0-1</c>
<c>0</c>
<c>NAS-Port-Type</c>
<c>0+</c>
<c>0+</c>
<c>Vendor-Specific</c>
<postamble>
Vendor TLVs encapsulated in a Vendor-Specific TLV MUST be marked as optional when
included in a Connection-Binding TLV.
</postamble>
</texttable>
</section>
<section title="Server-Trusted-Root TLV" anchor="S-T-R-T-R">
<texttable align="left">
<preamble>
The Server-Trusted-Root TLV can contain other TLVs. The table below defines
which TLVs can be contained inside the Server-Trusted-Root TLV and how many
such TLVs can be included.
</preamble>
<ttcol align="left">Request</ttcol>
<ttcol align="left">Response</ttcol>
<ttcol align="left">TLV</ttcol>
<c>0-1</c>
<c>0</c>
<c>PKCS#7</c>
</texttable>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<section title="Authentication and Integrity Protection" anchor="A-I-P">
<t>
TEAM provides a server authenticated, encrypted and integrity
protected tunnel. All data within the tunnel has these properties.
Data outside the tunnel such as EAP Success and Failure, Outer-TLVs,
authentication methods negotiated outside of TEAM and the TEAM
headers themselves (including the EAP-Type in the header) are not
protected by this tunnel.
<vspace blankLines="1"/>
In addition, the Crypto-Binding TLV can reveal a man-in-the-middle
attack described in <xref target="MITM-A-P"/>, below.
Hence, the server should not reveal
any sensitive data to the client until after the Crypto-Binding TLV
has been properly verified.
<vspace blankLines="1"/>
In order to detect the modification of Outer TLVs, the first two Outer
TLV messages sent by both peer and EAP-server are included in the
calculation of the Crypto-Binding TLV. Outer-TLVs SHOULD NOT be
included in other TEAM packets since there is no mechanism to detect
modification.
<vspace blankLines="1"/>
In order to detect modification of EAP-Type sent in the clear (EAP-Type
should be set to TEAM), the EAP-Type sent in the first two
messages by both peer and EAP-server is included in the calculation
of Crypto-Binding TLV. The EAP-Type in the clear could be modified
in other TEAM packets and will likely result in failure, hence it is
not included in the Crypto-Binding calculation.
</t>
</section>
<section title="Method Negotiation" anchor="M-N">
<t>
If the peer does not support TEAM, or does not wish to utilize
TEAM authentication, it MUST respond to the initial EAP-
Request/TEAM-Start with a NAK, suggesting an alternate authentication
method. Since the NAK is sent in cleartext with no integrity
protection or authentication, it is subject to spoofing. Inauthentic
NAK packets can be used to trick the peer and authenticator into
"negotiating down" to a weaker form of authentication, such as EAP-
MD5 (which only provides one way authentication and does not derive a key).
<vspace blankLines="1"/>
Since a subsequent protected EAP conversation can take place within
the TLS session, selection of TEAM as an authentication method does
not limit the potential secondary authentication methods. As a
result, the only legitimate reason for a peer to NAK TEAM as an
authentication method is that it does not support it. Where the
additional security of TEAM is required, server implementations
SHOULD respond to a NAK with an EAP-Failure, terminating the
authentication conversation.
<vspace blankLines="1"/>
Since method negotiation outside of TEAM is not protected, if the
peer is configured to allow TEAM and other EAP methods at the same
time, the negotiation is subject to downgrade attacks. Since method
negotiation outside of TEAM is not protected, if the peer is
configured to allow TEAM and previous TEAM versions at the same
time, the negotiation is subject to negotiation downgrade attacks.
However, peers configured to allow TEAM and later TEAM versions may
not be subject to downgrade negotiation attack since the highest
version supported by both peers is checked within the protected
tunnel.
<vspace blankLines="1"/>
If peer implementations select incorrect methods or credentials with
EAP servers, then attacks are possible on the credentials. Hence, a
TEAM peer implementation should preferably be configured with a set
of credentials and methods that may be used with a specific TEAM
server. The peer implementation may be configured to use different
methods and/or credentials based on the TEAM server.
</t>
</section>
<section title="TLS Session Cache Handling" anchor="T-S-C-H">
<t>
In cases where a TLS session has been successfully resumed, in some
circumstances, it is possible for the EAP server to skip TEAM Phase 2,
and successfully conclude the conversation with a protected termination.
<vspace blankLines="1"/>
TEAM "fast reconnect" is desirable in applications such as wireless
roaming, since it minimizes interruptions in connectivity. It is
also desirable when the "inner" EAP mechanism used is such that it
requires user interaction. The user should not be required to re-
authenticate herself, using biometrics, token cards or similar, every
time the radio connectivity is handed over between access points in
wireless environments.
<vspace blankLines="1"/>
However, there are issues that need to be understood in order to
avoid introducing security vulnerabilities.
<vspace blankLines="1"/>
Since Phase 1 of TEAM may not provide client authentication,
establishment of a TLS session (and an entry in the TLS session
cache) does not by itself provide an indication of the peer's
authenticity.
<vspace blankLines="1"/>
Some TEAM implementations may not be capable of removing TLS
session cache entries established in TEAM Phase 1 after an
unsuccessful Phase 2 authentication. In such implementations,
the existence of a TLS session cache entry provides no indication
that the peer has previously been authenticated. As a result,
implementations that do not remove TLS session cache entries after a
TEAM Phase 2 authentication or failed protected termination
MUST use other means than successful TLS resumption as the indicator
of whether the client is authenticated or not. The implementation
MUST determine that the client is authenticated only after the
completion of protected termination. Failing to do this would enable
a peer to gain access by completing TEAM Phase 1, tearing down the
connection, re-connecting and resuming TEAM Phase 2, thereby proving
herself authenticated. Thus, TLS resumption MUST only be enabled if
the implementation supports TLS session cache removal. If an EAP
server implementing TEAM removes TLS session cache entries of peers
failing TEAM Phase 2 authentication, then it MAY skip the TEAM
Phase 2 conversation entirely after a successful session resumption,
successfully terminating the TEAM conversation as described in
<xref target="P-T"/>.
</t>
</section>
<section title="Certificate Revocation" anchor="C-R">
<t>
Since the EAP server usually has network connectivity during the EAP
conversation, the server is capable of following a certificate chain
or verifying whether the peer's certificate has been revoked. In
contrast, the peer may or may not have network connectivity, and thus
while it can validate the EAP server's certificate based on a pre-
configured set of CAs, it may not be able to follow a certificate
chain or verify whether the EAP server's certificate has been
revoked.
<vspace blankLines="1"/>
In the case where the peer is initiating a voluntary Layer 2 channel
using PPTP <xref target="RFC2637"/>
or L2TP <xref target="RFC3931"/>,
the peer will typically already have network
connectivity established at the time of channel initiation. As a
result, during the EAP conversation it is capable of checking for
certificate revocation.
<vspace blankLines="1"/>
As part of the TLS negotiation, the server presents a certificate to
the peer. The peer SHOULD verify the validity of the EAP server
certificate, and SHOULD also examine the EAP server name presented in
the certificate, in order to determine whether the EAP server can be
trusted. Please note that in the case where the EAP authentication is
remoted, the EAP server will not reside on the same machine as the
authenticator, and therefore the name in the EAP server's certificate
cannot be expected to match that of the intended destination. In
this case, a more appropriate test might be whether the EAP server's
certificate is signed by a CA controlling the intended destination
and whether the EAP server exists within a target sub-domain.
<vspace blankLines="1"/>
In the case where the peer is attempting to obtain network access, it
will not have network connectivity. The TLS Extensions <xref target="RFC5246"/>
support piggybacking of an Online Certificate Status Protocol <xref target="RFC2560"/>
response within TLS, therefore can be utilized by the peer in order
to verify the validity of server certificate. However, since not all
TLS implementations implement the TLS extensions, it may be necessary
for the peer to wait to check for certificate revocation until after
network access has been obtained. In this case, the peer SHOULD
conduct the certificate status check immediately upon going online
and SHOULD NOT send data until it has received a positive response to
the status request. If the server certificate is found to be invalid
as per client policy, then the peer SHOULD disconnect.
<vspace blankLines="1"/>
If the client has a policy to require checking certificate revocation
and it cannot obtain revocation information then it may need to
disallow the use of all or some of the inner methods since some
methods may reveal some sensitive information.
</t>
</section>
<section title="Separation of EAP Server and Authenticator" anchor="S-E-S-A">
<t>
As a result of a complete TEAM conversation, the
EAP endpoints will mutually authenticate, and derive a session key
for subsequent use in link layer security. Since the peer and EAP
client reside on the same machine, it is necessary for the EAP client
module to pass the session key to the link layer encryption module.
<vspace blankLines="1"/>
The situation may be more complex on the Authenticator, which may or
may not reside on the same machine as the EAP server. In the case
where the EAP server and the Authenticator reside on different
machines, there are several implications for security. Firstly, the
mutual authentication defined in TEAM will occur between the peer
and the EAP server, not between the peer and the authenticator. This
means that as a result of the TEAM conversation, it is not possible
for the peer to validate the identity of the NAS or channel server
that it is speaking to.
<vspace blankLines="1"/>
The second issue is that the session key negotiated between the peer
and EAP server will need to be transmitted to the authenticator.
Therefore a secure mechanism needs to be provided to transmit the
session key from the EAP server to the authenticator or channel
server that needs to use the key. The specification of this transit
mechanism is outside the scope of this document.
</t>
</section>
<section title="Separation of TEAM Phase 1 and 2 Servers" anchor="S-T-P-1-2">
<t>
The EAP server involved in TEAM Phase 2 need not necessarily be the
same as the EAP server involved in Phase 1. For example, a
local authentication server or proxy might serve as the endpoint for
the Phase 1 conversation, establishing the TLS channel. Subsequently,
once the EAP-Response/Identity has been received within the TLS
channel, it can be decrypted and forwarded in cleartext to the
destination realm EAP server. The rest of the conversation will
therefore occur between the destination realm EAP server and the
peer, with the local authentication server or proxy acting as an
encrypting/decrypting gateway. This permits a non-TLS capable EAP
server to participate in the TEAM conversation.
<vspace blankLines="1"/>
Note however that such an approach introduces security
vulnerabilities. Since the EAP Response/Identity is sent in the
clear between the proxy and the EAP server, this enables an attacker
to snoop the user's identity. It also enables a remote environments,
which may be public hot spots or Internet coffee shops, to gain
knowledge of the identity of their users. Since one of the potential
benefits of TEAM is identity protection, this is undesirable.
<vspace blankLines="1"/>
If the EAP method negotiated during TEAM Phase 2 does not support
mutual authentication, then if the Phase 2 conversation is proxied to
another destination, the TEAM peer will not have the opportunity to
verify the secondary EAP server's identity. Only the initial EAP
server's identity will have been verified as part of TLS session
establishment.
<vspace blankLines="1"/>
Similarly, if the EAP method negotiated during TEAM Phase 2 is
vulnerable to dictionary attack, then an attacker capturing the
cleartext exchange will be able to mount an offline dictionary attack
on the password.
<vspace blankLines="1"/>
Finally, when a Phase 2 conversation is terminated at a different
location than the Phase 1 conversation, the Phase 2 destination is
unaware that the EAP client has negotiated TEAM. As a result, it is
unable to enforce policies requiring TEAM. Since some EAP methods
require TEAM in order to generate keys or lessen security
vulnerabilities, where such methods are in use, such a configuration
may be unacceptable.
<vspace blankLines="1"/>
In summary, TEAM encrypting/decrypting gateway configurations are
vulnerable to attack and SHOULD NOT be used. Instead, the entire
TEAM connection SHOULD be proxied to the final destination, and the
subsequently derived master session keys need to be transmitted back.
This provides end-to-end protection of TEAM. The specification of
this transit mechanism is outside the scope of this document, but
mechanisms similar to those described in <xref target="RFC2548"/>
can be used. These steps protect the client from revealing her identity to the remote environment.
<vspace blankLines="1"/>
In order to find the proper TEAM destination, the EAP client SHOULD
place a Network Access Identifier (NAI) <xref target="RFC4282"/>
in the Identity Response.
<vspace blankLines="1"/>
There may be cases where a natural trust relationship exists between
the (foreign) authentication server and final EAP server, such as on
a campus or between two offices within the same company, where there
is no danger in revealing the identity of the station to the
authentication server. In these cases, a proxy solution without end
to end protection of TEAM MAY be used. If RADIUS <xref target="RFC2865"/>
is used to
communicate between gateway and EAP server, then the TEAM
encrypting/decrypting gateway SHOULD provide support for IPsec
protection of RADIUS in order to provide confidentiality for the
portion of the conversation between the gateway and the EAP server,
as described in <xref target="RFC3579"/>.
</t>
</section>
<section title="Identity Verification" anchor="I-V">
<t>
Since the TLS session has not yet been negotiated, the initial
Identity request/response occurs in the clear without integrity
protection or authentication. It is therefore subject to snooping and
packet modification.
<vspace blankLines="1"/>
In configurations where all users are required to authenticate with
TEAM and the first portion of the TEAM conversation is terminated
at a local backend authentication server, without routing by proxies,
the initial cleartext Identity Request/Response exchange is not
needed in order to determine the required authentication method(s) or
route the authentication conversation to its destination. As a
result, the initial Identity and Request/Response exchange may not
be present, and a subsequent Identity Request/Response exchange MAY
occur after the TLS session is established.
<vspace blankLines="1"/>
If the initial cleartext Identity Request/Response has been tampered
with, after the TLS session is established, it is conceivable that
the EAP Server will discover that it cannot verify the peer's claim
of identity. For example, the peer's userID may not be valid or may
not be within a realm handled by the EAP server. Rather than
attempting to proxy the authentication to the server within the
correct realm, the EAP server SHOULD terminate the conversation.
<vspace blankLines="1"/>
The TEAM peer can present the server with multiple identities. This
includes the claim of identity within the initial EAP-
Response/Identity (MyID) packet, which is typically used to route the
EAP conversation to the appropriate home backend authentication
server. There may also be subsequent EAP-Response/Identity packets
sent by the peer once the TLS channel has been established.
<vspace blankLines="1"/>
Note that since the TEAM peer may not present a certificate, it is
not always possible to check the initial EAP-Response/Identity
against the identity presented in the certificate, as is done in <xref target="RFC5216"/>.
<vspace blankLines="1"/>
Moreover, it cannot be assumed that the peer identities presented
within multiple EAP-Response/Identity packets will be the same. For
example, the initial EAP-Response/Identity might correspond to a
machine identity, while subsequent identities might be those of the
user. Thus, TEAM implementations SHOULD NOT abort the
authentication just because the identities do not match. However,
since the initial EAP-Response/Identity will determine the EAP server
handling the authentication, if this or any other identity is
inappropriate for use with the destination EAP server, there is no
alternative but to terminate the TEAM conversation.
<vspace blankLines="1"/>
The protected identity or identities presented by the peer within
TEAM Phase 2 may not be identical to the cleartext identity
presented in TEAM Phase 1, for legitimate reasons. In order to
shield the userID from snooping, the cleartext Identity may only
provide enough information to enable routing of the authentication
request to the correct realm. For example, the peer may initially
claim the identity of "nouser@bigco.com" in order to route the
authentication request to the bigco.com EAP server. Subsequently,
once the TLS session has been negotiated, in TEAM Phase 2, the peer
may claim the identity of "fred@bigco.com". Thus, TEAM can provide
protection for the user's identity, though not necessarily the
destination realm, unless the TEAM Phase 1 conversation terminates
at the local authentication server.
<vspace blankLines="1"/>
As a result, TEAM implementations SHOULD NOT attempt to compare the
Identities claimed with Phases 1 and 2 of the TEAM conversation.
Similarly, if multiple Identities are claimed within TEAM Phase 2,
these SHOULD NOT be compared. An EAP conversation may involve more
than one EAP authentication method, and the identities claimed for
each of these authentications could be different (e.g. a machine
authentication, followed by a user authentication).
</t>
</section>
<section title="Man-in-the-Middle Attack Protection" anchor="MITM-A-P">
<t>
TLS protection can address a number of weaknesses in the EAP method;
as well as EAP protocol weaknesses listed in the abstract and
introduction sections in this document.
<vspace blankLines="1"/>
Hence, the recommended solution is to always deploy authentication
methods with protection of TEAM.
<vspace blankLines="1"/>
If a deployment chooses to allow a EAP method protected by TEAM
without protection of TEAM or IPsec at the same time, then this
opens up a possibility of a man-in-the-middle attack.
<vspace blankLines="1"/>
A man-in-the-middle can spoof the client to authenticate to it
instead of the real EAP server; and forward the authentication to the
real server over a protected tunnel. Since the attacker has access to
the keys derived from the tunnel, it can gain access to the network.
<vspace blankLines="1"/>
TEAM prevents this attack by using the keys generated by
the inner EAP method in the crypto-binding exchange described in
protected termination section. This attack is not prevented if the
inner EAP method does not generate keys or if the keys generated by
the inner EAP method can be compromised. Hence, in cases where the
inner EAP method does not generate keys, the recommended solution is
to always deploy authentication methods protected by TEAM.
<vspace blankLines="1"/>
Alternatively, the attack can also be thwarted if the inner EAP
method can signal to the peer that the packets are being sent within
the tunnel. In most cases this may require modification to the inner
EAP method. In order to allow for these implementations, TEAM
implementations should inform inner EAP methods that the EAP method
is being protected by a TEAM tunnel.
<vspace blankLines="1"/>
Since all sequence negotiations and exchanges are protected by TLS
channel, they are immune to snooping and MITM attacks with the use of
Crypto-Binding TLV. To make sure the same parties are involved tunnel
establishment and previous inner method, before engaging the next
method to sent more sensitive information, both peer and server MUST
use the Crypto-Binding TLV between methods to check the tunnel
integrity. If the Crypto-Binding TLV failed validation, they SHOULD
stop the sequence and terminate the tunnel connection, to prevent
more sensitive information being sent in subsequent methods.
</t>
</section>
<section title="Cleartext Forgeries" anchor="C-F">
<t>
<xref target="RFC3748">As described in</xref>,
EAP Success and Failure packets are not
authenticated, so that they may be forged by an attacker without fear
of detection. Forged EAP Failure packets can be used to convince an
EAP peer to disconnect. Forged EAP Success and Failure packets may
be used to convince a peer to disconnect; or convince a peer to
access the network even before authentication is complete, resulting
in denial of service for the peer.
<vspace blankLines="1"/>
By supporting encrypted, authenticated and integrity protected
success/failure indications, TEAM provides protection against these
attacks.
<vspace blankLines="1"/>
Once the peer responds with the first TEAM packet; and the EAP server
receives the first TEAM packet from the peer, both MUST silently
discard all clear text EAP messages unless both the TEAM peer and
server have indicated success or failure or error using a protected
error or protected termination mechanism. The success/failure
decisions sent by a protected mechanism indicate the final decision
of the EAP authentication conversation. After success/failure has
been indicated by a protected mechanism, the TEAM client can
process unprotected EAP success and EAP failure message; however MUST
ignore any unprotected EAP success or failure messages where the
decision does not match the decision of the protected mechanism.
<vspace blankLines="1"/>
After a Fatal alert is received or after protected termination is
complete, the peer or EAP server should accept clear text EAP
messages. If the TEAM tunnel is nested inside another tunnel, then
the clear text EAP messages should only be accepted after protected
termination of outer tunnels.
<vspace blankLines="1"/>
RFC 3748
states that an EAP Success or EAP Failure packet terminates
the EAP conversation, so that no response is possible. Since EAP
Success and EAP Failure packets are not retransmitted, if the final
packet is lost, then authentication will fail. As a result, where
packet loss is expected to be non-negligible, unacknowledged
success/failure indications lack robustness.
<vspace blankLines="1"/>
As a result, a EAP server SHOULD send a clear text EAP Success or
Failure packet after the protected success or failure packet or
TLS alert. The peer MUST NOT require the clear text EAP Success or
EAP Failure if it has received the protected success or failure or
TLS alert. For more details, refer to Section 4.2 of RFC 3748.
</t>
</section>
<section title="TLS Ciphersuites" anchor="TLS-C">
<t>
Anonymous ciphersuites are vulnerable to man-in-the-middle attacks,
and SHOULD NOT be used with TEAM, unless the EAP methods inside
TEAM can address the man-in-the-middle attack or unless the man-in-
the-middle attack can be addressed by mechanisms external to TEAM.
</t>
</section>
<section title="Denial of Service Attacks" anchor="DoS-A">
<t>
Denial of service attacks are possible if the attacker can insert or
modify packets in the authentication channel. The attacker can
modify unprotected fields in the TEAM packet such as the EAP protocol
or TEAM version number. This can result in a denial of service
attack. It is also possible for the attacker to modify protected
fields in a packet to cause decode errors resulting in a denial of
service. In these ways the attacker can prevent access for peers
connecting to the network.
<vspace blankLines="1"/>
Denial of service attacks with multiplier impacts are more
interesting than the ones above. It is possible to multiply the
impact by creating a large number of TLS sessions with the EAP
server.
</t>
</section>
<section title="Server Unauthenticated Tunnel Provisioning Mode" anchor="S-U-T-P-M">
<t>
This section describes the rationale and security risks behind server
unauthenticated tunnel provisioning mode. Server unauthenticated
tunnel provisioning mode results in potential security
vulnerabilities. Hence, this mode is optional in TEAM
implementations.
<vspace blankLines="1"/>
In order to achieve strong mutual authentication, it is best to use
an out of band mechanism to pre-provision the device with strong
symmetric or asymmetric keys. In addition, if the device is not
physically secure (mobile or devices at public places), then it is
important to ensure that the device has secure storage.
<vspace blankLines="1"/>
Server unauthenticated tunnel provisioning mode is not recommended
for use in devices which already support secure provisioning and
secure credential storage capabilities, since the security
vulnerabilities will outweight the benefits.
<vspace blankLines="1"/>
If the provisioned credential is a shared key or asymmetric key
issued to the peer, then the credential should only be issued to
devices that can protect the provisioned credentials using secure
storage, or use physical security.
<vspace blankLines="1"/>
If the credentials are not protected, the attacker can compromise the
provisioned credentials, and use it to get access to the network.
Mobile light weight devices are typically not physically secure.
Another concern is that credentials provisioned to a light weight
mobile device that does not use secure storage could be transferred
to a general operating system and used to get access to the network.
<vspace blankLines="1"/>
If the provisioned credential is a certificate trusted root of the
EAP server, this is public information and hence not susceptible to
the same attacks as a shared key or asymmetric key.
<vspace blankLines="1"/>
In server unauthenticated tunnel provisioning mode, an attacker may
terminate the tunnel instead of the real server. The attacker can be
detected after the Crypto-Binding TLV is exchanged and validated.
However, the EAP packets exchanged inside the tunnel until Crypto-
Binding TLV is validated are available in unencrypted form to the
attacker. It is difficult to completely negate the security risk
unless the EAP methods inside the tunnel are secure; or unless
physical wire security is assumed.
<vspace blankLines="1"/>
The standard credential request/response capability is designed to be
independent of the server unauthenticated tunnel provisioning mode,
and can be used in regular authentication mode to provision other
credentials to the peer that can be used for authentication to the
network, or for potentially authentications to other services.
<vspace blankLines="1"/>
The security risks vary depending on the type of credential
exchanged, the scope of use of the credential, and the implementation
of the device.
<vspace blankLines="1"/>
These are a few guidelines to reduce the security risk:
<vspace blankLines="1"/>
<list style="numbers">
<t>
Minimize the use of this mode only during initial authentication to
the network to reduce the risk of attack
<vspace blankLines="1"/>
</t>
<t>
If the password-based EAP method used in provisioned mode is
susceptible to dictionary attacks, then the implementation should
support deployment of sound password password policies e.g.
capability to enforce strong password policies and support rotation
of passwords
<vspace blankLines="1"/>
</t>
<t>
Disable this mode by default and require users to initiate
provisioning mode explicitly rather than being prompted during
initiation of regular authentication process
<vspace blankLines="1"/>
</t>
<t>
Provide appropriate policy capabilities to allow administrators to
lockdown the device and prevent regular users from enabling the mode
<vspace blankLines="1"/>
</t>
<t>
Ensure that the EAP methods used support mutual authentication
<vspace blankLines="1"/>
</t>
<t>
Ensure that the EAP methods used generate keys of sufficient
strength to prevent compounding binding from being compromised
<vspace blankLines="1"/>
</t>
<t>
Minimize the information disclosed to the EAP server
<vspace blankLines="1"/>
</t>
</list>
</t>
</section>
<section title="Security Claims" anchor="S-C">
<t>
<list style="hanging" hangIndent="26">
<t hangText="Intended use:">
Wireless or Wired networks, and over
the Internet, where physical security
cannot be assumed
<vspace blankLines="1"/>
</t>
<t hangText="Authentication mechanism:">
Uses arbitrary EAP and TLS authentication
mechanisms for authentication of the
client and server.
<vspace blankLines="1"/>
</t>
<t hangText="Ciphersuite negotiation: ">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Mutual authentication:">
Yes (depends on the type of EAP method
used within the tunnel and the type of
authentication used within TLS)
<vspace blankLines="1"/>
</t>
<t hangText="Integrity protection:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Replay protection:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Confidentiality:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Key derivation:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Key strength:">
Variable
<vspace blankLines="1"/>
</t>
<t hangText="Dict. attack protection:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Fast reconnect:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Cryptographic binding:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Acknowledged S/F:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Session independence:">
Yes
<vspace blankLines="1"/>
</t>
<t hangText="Fragmentation:">
Yes<vspace blankLines="1"/>
</t>
<t hangText="State synchronization:">
Yes
<vspace blankLines="1"/>
</t>
</list>
The TEAM protocol is unconditionally compliant with the
requirements for WLAN authentication mechanisms, as specified in <xref target="RFC4017"/>.
<vspace blankLines="1"/>
TEAM derives keys by combining keys from TLS and the inner EAP
methods. It should be noted that the use of TLS ciphersuites with a
particular key lengths does not guarantee that the key strength of
the keys will be equivalent to the length. The key exchange
mechanisms (e.g., RSA or Diffie-Hellman) used must provide sufficient
security or they will be the weakest link. For example RSA key sizes
with a modulus of 1024 bits provides less than 128 bits of security,
this may provide sufficient key strength for some applications and
not for others. See <xref target="RFC3766">BCP 86</xref>
for a detailed analysis of
the strength requirements on the public keys used to exchange symmetric keys.
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
TLV Types may assume a value between 0 and 16383 of which 0-20
are allocated in this document <xref target="TLV-T"/>.
Additional TLV type codes may be allocated following the
"Specification Required" policy <xref target="RFC5226"/>.
<vspace blankLines="1"/>
The Identity-Type field may assume a value between 0 and 65535, of
which 0-2 are allocated in this document <xref target="I-T-TLV"/>,
Additional Identity-Type values may
be allocated following the "Specification Required" policy <xref target="RFC5226"/>.
<vspace blankLines="1"/>
The Credential Type field of the Server-Trusted-Root TLV <xref target="S-T-R-TLV"/>
may assume a value between 0 and 65535, of
which 1 is allocated in this document.
Additional Credential Type values may
be allocated following the "Specification Required" policy <xref target="RFC5226"/>.
<vspace blankLines="1"/>
The Action field field of the Request-Action TLV
may assume a value between 0 and 65535, of which 0-2
have already been allocated.
Additional Action values may be
allocated following the "Specification Required" policy <xref target="RFC5226"/>.
</t>
</section>
<section title="Contributors">
<t>
A great deal of the text in the first draft of this note was taken from a document
by Ashwin Palekar, Dan Simon, Glen Zorn, Simon Josefsson, Hao Zhou and Joe Salowey;
the authors gratefully acknowledge their contribution.
<vspace blankLines="1"/>
TEAM is a direct descendent of the Protected Extensible Authentication Protocol (PEAP),
which was created by Glen Zorn while employed by Cisco Systems.
</t>
</section>
<section title="Acknowledgements">
<t>
Hakan Andersson, Jan-Ove Larsson, Magnus Nystrom, Bernard Aboba, Vivek Kamath,
Stephen Bensley, Narendra Gidwani, Ilan Frenkel, Nancy Cam-Winget,
Victor Lortz, Ashwin Palekar, Dan Simon, Glen Zorn, Simon Josefsson,
Hao Zhou, Joe Salowey, Bernard Aboba, Paul Funk and Jose Puthenkulam all
contributed at various stages to the development of this protocol.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3748;
&rfc5246;
&rfc3986;
&rfc5226;
&rfc4282;
</references>
<references title="Informative References">
<reference anchor="IEEE.802-1X.2004">
<front>
<title>IEEE Standard for Local and metropolitan area networks: Port-Based Network Access Control</title>
<author>
<organization>IEEE Computer Society</organization>
</author>
<date day="13" month="December" year="2004"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.1X" />
</reference>
<reference anchor="IEEE.802-11.2007">
<front>
<title>
Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications
</title>
<author>
<organization>IEEE Computer Society</organization>
</author>
<date day="12" month="June" year="2007"/>
</front>
<seriesInfo name="IEEE" value="Standard 802.11" />
</reference>
<!--
<reference anchor="FIPSDES">
<front>
<title>Data Encryption Standard</title>
<author>
<organization>National Bureau of Standards</organization>
</author>
<date month="January" year="1977"/>
</front>
<seriesInfo name="FIPS PUB" value="46"/>
</reference>
-->
<!--
<reference anchor="DESMODES">
<front>
<title>DES MODES of Operation</title>
<author>
<organization>National Bureau of Standards</organization>
</author>
<date month="December" day="1980"/>
</front>
<seriesInfo name="FIPS PUB" value="81"/>
</reference>
-->
&rfc1968;
&rfc4017;
&rfc2315;
&rfc1990;
&rfc2548;
&rfc2865;
&rfc5216;
&rfc3579;
&rfc3580;
&rfc3766;
&rfc5996;
&rfc2637;
&rfc3931;
&rfc2560;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 07:43:41 |