5. Cryptographic Calculations
For key derivation and crypto-binding, TEAP uses the Pseudorandom
Function (PRF) and MAC algorithms negotiated in the underlying TLS
session. Since these algorithms depend on the TLS version and
ciphersuite, TEAP implementations need a mechanism to determine the
version and ciphersuite in use for a particular session. The
implementation can then use this information to determine which PRF
and MAC algorithm to use.
5.1. TEAP Authentication Phase 1: Key Derivations
With TEAPv1, the TLS master secret is generated as specified in TLS.
If a PAC is used, then the master secret is obtained as described in
TEAPv1 makes use of the TLS Keying Material Exporters defined in
[RFC5705] to derive the session_key_seed. The label used in the
derivation is "EXPORTER: teap session key seed". The length of the
session key seed material is 40 octets. No context data is used in
the export process.
The session_key_seed is used by the TEAP authentication Phase 2
conversation to both cryptographically bind the inner method(s) to
the tunnel as well as generate the resulting TEAP session keys. The
other TLS keying materials are derived and used as defined in
5.2. Intermediate Compound Key Derivations
The session_key_seed derived as part of TEAP Phase 2 is used in TEAP
Phase 2 to generate an Intermediate Compound Key (IMCK) used to
verify the integrity of the TLS tunnel after each successful inner
authentication and in the generation of Master Session Key (MSK) and
Extended Master Session Key (EMSK) defined in [RFC3748]. Note that
the IMCK MUST be recalculated after each successful inner EAP method.
The first step in these calculations is the generation of the base
compound key, IMCK[n] from the session_key_seed, and any session keys
derived from the successful execution of nth inner EAP methods. The
inner EAP method(s) may provide Inner Method Session Keys (IMSKs),
IMSK1..IMSKn, corresponding to inner method 1 through n.
If an inner method supports export of an Extended Master Session Key
(EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
[RFC5295]. The usage label used is "TEAPbindkey@ietf.org", and the
length is 64 octets. Optional data parameter is not used in the
IMSK = First 32 octets of TLS-PRF(EMSK, "TEAPbindkey@ietf.org" |
"\0" | 64)
where "|" denotes concatenation, EMSK is the EMSK from the inner
method, "TEAPbindkey@ietf.org" consists the ASCII value for the
label "TEAPbindkey@ietf.org" (without quotes), "\0" = is a NULL
octet (0x00 in hex), length is the 2-octet unsigned integer in
network byte order, and TLS-PRF is the PRF negotiated as part of
TLS handshake [RFC5246].
If an inner method does not support export of an Extended Master
Session Key (EMSK), then IMSK is the MSK of the inner method. The
MSK is truncated at 32 octets if it is longer than 32 octets or
padded to a length of 32 octets with zeros if it is less than 32
However, it's possible that the peer and server sides might not have
the same capability to export EMSK. In order to maintain maximum
flexibility while prevent downgrading attack, the following mechanism
is in place.
On the sender of the Crypto-Binding TLV side:
If the EMSK is not available, then the sender computes the Compound
MAC using the MSK of the inner method.
If the EMSK is available and the sender's policy accepts MSK-based
MAC, then the sender computes two Compound MAC values. The first
is computed with the EMSK. The second one is computed using the
MSK. Both MACs are then sent to the other side.
If the EMSK is available but the sender's policy does not allow
downgrading to MSK-generated MAC, then the sender SHOULD only send
On the receiver of the Crypto-Binding TLV side:
If the EMSK is not available and an MSK-based Compound MAC was
sent, then the receiver validates the Compound MAC and sends back
an MSK-based Compound MAC response.
If the EMSK is not available and no MSK-based Compound MAC was
sent, then the receiver handles like an invalid Crypto-Binding TLV
with a fatal error.
If the EMSK is available and an EMSK-based Compound MAC was sent,
then the receiver validates it and creates a response Compound MAC
using the EMSK.
If the EMSK is available but no EMSK-based Compound MAC was sent
and its policy accepts MSK-based MAC, then the receiver validates
it using the MSK and, if successful, generates and returns an MSK-
based Compound MAC.
If the EMSK is available but no EMSK Compound MAC was sent and its
policy does not accept MSK-based MAC, then the receiver handles
like an invalid Crypto-Binding TLV with a fatal error.
If the ith inner method does not generate an EMSK or MSK, then IMSKi
is set to zero (e.g., MSKi = 32 octets of 0x00s). If an inner method
fails, then it is not included in this calculation. The derivation
of S-IMCK is as follows:
S-IMCK = session_key_seed
For j = 1 to n-1 do
IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
S-IMCK[j] = first 40 octets of IMCK[j]
CMK[j] = last 20 octets of IMCK[j]
where TLS-PRF is the PRF negotiated as part of TLS handshake
5.3. Computing the Compound MAC
For authentication methods that generate keying material, further
protection against man-in-the-middle attacks is provided through
cryptographically binding keying material established by both TEAP
Phase 1 and TEAP Phase 2 conversations. After each successful inner
EAP authentication, EAP EMSK and/or MSKs are cryptographically
combined with key material from TEAP Phase 1 to generate a Compound
Session Key (CMK). The CMK is used to calculate the Compound MAC as
part of the Crypto-Binding TLV described in Section 4.2.13, which
helps provide assurance that the same entities are involved in all
communications in TEAP. During the calculation of the Compound MAC,
the MAC field is filled with zeros.
The Compound MAC computation is as follows:
CMK = CMK[j]
Compound-MAC = MAC( CMK, BUFFER )
where j is the number of the last successfully executed inner EAP
method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
BUFFER is created after concatenating these fields in the following
1 The entire Crypto-Binding TLV attribute with both the EMSK and MSK
Compound MAC fields zeroed out.
2 The EAP Type sent by the other party in the first TEAP message.
3 All the Outer TLVs from the first TEAP message sent by EAP server
to peer. If a single TEAP message is fragmented into multiple
TEAP packets, then the Outer TLVs in all the fragments of that
message MUST be included.
4 All the Outer TLVs from the first TEAP message sent by the peer to
the EAP server. If a single TEAP message is fragmented into
multiple TEAP packets, then the Outer TLVs in all the fragments of
that message MUST be included.
5.4. EAP Master Session Key Generation
TEAP authentication assures the Master Session Key (MSK) and Extended
Master Session Key (EMSK) output from the EAP method are the result
of all authentication conversations by generating an Intermediate
Compound Key (IMCK). The IMCK is mutually derived by the peer and
the server as described in Section 5.2 by combining the MSKs from
inner EAP methods with key material from TEAP Phase 1. The resulting
MSK and EMSK are generated as part of the IMCKn key hierarchy as
MSK = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
EMSK = TLS-PRF(S-IMCK[j],
"Extended Session Key Generating Function", 64)
where j is the number of the last successfully executed inner EAP
The EMSK is typically only known to the TEAP peer and server and is
not provided to a third party. The derivation of additional keys and
transportation of these keys to a third party are outside the scope
of this document.
If no EAP methods have been negotiated inside the tunnel or no EAP
methods have been successfully completed inside the tunnel, the MSK
and EMSK will be generated directly from the session_key_seed meaning
S-IMCK = session_key_seed.
6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the TEAP
protocol, in accordance with BCP 26 [RFC5226].
The EAP Method Type number 55 has been assigned for TEAP.
The document defines a registry for TEAP TLV types, which may be
assigned by Specification Required as defined in [RFC5226].
Section 4.2 defines the TLV types that initially populate the
registry. A summary of the TEAP TLV types is given below:
1 Authority-ID TLV
2 Identity-Type TLV
3 Result TLV
4 NAK TLV
5 Error TLV
6 Channel-Binding TLV
7 Vendor-Specific TLV
8 Request-Action TLV
9 EAP-Payload TLV
10 Intermediate-Result TLV
11 PAC TLV
12 Crypto-Binding TLV
13 Basic-Password-Auth-Req TLV
14 Basic-Password-Auth-Resp TLV
15 PKCS#7 TLV
16 PKCS#10 TLV
17 Trusted-Server-Root TLV
The Identity-Type defined in Section 4.2.3 contains an identity type
code that is assigned on a Specification Required basis as defined in
[RFC5226]. The initial types defined are:
The Result TLV defined in Section 4.2.4, Request-Action TLV defined
in Section 4.2.9, and Intermediate-Result TLV defined in
Section 4.2.11 contain a Status code that is assigned on a
Specification Required basis as defined in [RFC5226]. The initial
types defined are:
The Error-TLV defined in Section 4.2.6 requires an error code. TEAP
Error-TLV error codes are assigned based on a Specification Required
basis as defined in [RFC5226]. The initial list of error codes is as
1 User account expires soon
2 User account credential expires soon
1021 Realm mismatch between inner and outer identity
1022 Unsupported Algorithm In Certificate Signing Request
1023 Unsupported Extension In Certificate Signing Request
1024 Bad Identity In Certificate Signing Request
1025 Bad Certificate Signing Request
1026 Internal CA Error
1027 General PKI Error
1028 Inner method's channel-binding data required but not supplied
1029 Inner method's channel-binding data did not include required
1030 Inner method's channel binding failed
1031 User account credentials incorrect [USAGE NOT RECOMMENDED]
2001 Tunnel Compromise Error
2002 Unexpected TLVs Exchanged
The Request-Action TLV defined in Section 4.2.9 contains an action
code that is assigned on a Specification Required basis as defined in
[RFC5226]. The initial actions defined are:
The PAC Attribute defined in Section 220.127.116.11 contains a Type code
that is assigned on a Specification Required basis as defined in
[RFC5226]. The initial types defined are:
The PAC-Type defined in Section 18.104.22.168 contains a type code that is
assigned on a Specification Required basis as defined in [RFC5226].
The initial type defined is:
1 Tunnel PAC
The Trusted-Server-Root TLV defined in Section 4.2.18 contains a
Credential-Format code that is assigned on a Specification Required
basis as defined in [RFC5226]. The initial type defined is:
The various values under the Vendor-Specific TLV are assigned by
Private Use and do not need to be assigned by IANA.
TEAP registers the label "EXPORTER: teap session key seed" in the TLS
Exporter Label Registry [RFC5705]. This label is used in derivation
as defined in Section 5.1.
TEAP registers a TEAP binding usage label from the "User Specific
Root Keys (USRK) Key Labels" name space defined in [RFC5295] with a
7. Security Considerations
TEAP is designed with a focus on wireless media, where the medium
itself is inherent to eavesdropping. Whereas in wired media an
attacker would have to gain physical access to the wired medium,
wireless media enables anyone to capture information as it is
transmitted over the air, enabling passive attacks. Thus, physical
security can not be assumed, and security vulnerabilities are far
greater. The threat model used for the security evaluation of TEAP
is defined in EAP [RFC3748].
7.1. Mutual Authentication and Integrity Protection
As a whole, TEAP provides message and integrity protection by
establishing a secure tunnel for protecting the authentication
method(s). The confidentiality and integrity protection is defined
by TLS and provides the same security strengths afforded by TLS
employing a strong entropy shared master secret. The integrity of
the key generating authentication methods executed within the TEAP
tunnel is verified through the calculation of the Crypto-Binding TLV.
This ensures that the tunnel endpoints are the same as the inner
The Result TLV is protected and conveys the true Success or Failure
of TEAP, and it should be used as the indicator of its success or
failure respectively. However, as EAP terminates with either a
cleartext EAP Success or Failure, a peer will also receive a
cleartext EAP Success or Failure. The received cleartext EAP Success
or Failure MUST match that received in the Result TLV; the peer
SHOULD silently discard those cleartext EAP Success or Failure
messages that do not coincide with the status sent in the protected
7.2. Method Negotiation
As is true for any negotiated EAP protocol, NAK packets used to
suggest an alternate authentication method are sent unprotected and,
as such, are subject to spoofing. During unprotected EAP method
negotiation, NAK packets may be interjected as active attacks to
negotiate down to a weaker form of authentication, such as EAP-MD5
(which only provides one-way authentication and does not derive a
key). Both the peer and server should have a method selection policy
that prevents them from negotiating down to weaker methods. Inner
method negotiation resists attacks because it is protected by the
mutually authenticated TLS tunnel established. Selection of TEAP as
an authentication method does not limit the potential inner
authentication methods, so TEAP should be selected when available.
An attacker cannot readily determine the inner EAP method used,
except perhaps by traffic analysis. It is also important that peer
implementations limit the use of credentials with an unauthenticated
or unauthorized server.
7.3. Separation of Phase 1 and Phase 2 Servers
Separation of the TEAP Phase 1 from the Phase 2 conversation is NOT
RECOMMENDED. Allowing the Phase 1 conversation to be terminated at a
different server than the Phase 2 conversation can introduce
vulnerabilities if there is not a proper trust relationship and
protection for the protocol between the two servers. Some
o Loss of identity protection
o Offline dictionary attacks
o Lack of policy enforcement
o Man-in-the-middle attacks (as described in [RFC7029])
There may be cases where a trust relationship exists between the
Phase 1 and Phase 2 servers, such as on a campus or between two
offices within the same company, where there is no danger in
revealing the inner identity and credentials of the peer to entities
between the two servers. In these cases, using a proxy solution
without end-to-end protection of TEAP MAY be used. The TEAP
encrypting/decrypting gateway MUST, at a minimum, provide support for
IPsec, TLS, or similar protection in order to provide confidentiality
for the portion of the conversation between the gateway and the EAP
server. In addition, separation of the inner and outer method
servers allows for crypto-binding based on the inner method MSK to be
thwarted as described in [RFC7029]. Implementation and deployment
SHOULD adopt various mitigation strategies described in [RFC7029].
If the inner method is deriving EMSK, then this threat is mitigated
as TEAP utilizes the mutual crypto-binding based on EMSK as described
7.4. Mitigation of Known Vulnerabilities and Protocol Deficiencies
TEAP addresses the known deficiencies and weaknesses in the EAP
method. By employing a shared secret between the peer and server to
establish a secured tunnel, TEAP enables:
o Per-packet confidentiality and integrity protection
o User identity protection
o Better support for notification messages
o Protected EAP inner method negotiation
o Sequencing of EAP methods
o Strong mutually derived MSKs
o Acknowledged success/failure indication
o Faster re-authentications through session resumption
o Mitigation of dictionary attacks
o Mitigation of man-in-the-middle attacks
o Mitigation of some denial-of-service attacks
It should be noted that in TEAP, as in many other authentication
protocols, a denial-of-service attack can be mounted by adversaries
sending erroneous traffic to disrupt the protocol. This is a problem
in many authentication or key agreement protocols and is therefore
noted for TEAP as well.
TEAP was designed with a focus on protected authentication methods
that typically rely on weak credentials, such as password-based
secrets. To that extent, the TEAP authentication mitigates several
vulnerabilities, such as dictionary attacks, by protecting the weak
credential-based authentication method. The protection is based on
strong cryptographic algorithms in TLS to provide message
confidentiality and integrity. The keys derived for the protection
relies on strong random challenges provided by both peer and server
as well as an established key with strong entropy. Implementations
should follow the recommendation in [RFC4086] when generating random
7.4.1. User Identity Protection and Verification
The initial identity request response exchange is sent in cleartext
outside the protection of TEAP. Typically, the Network Access
Identifier (NAI) [RFC4282] in the identity response is useful only
for the realm of information that is used to route the authentication
requests to the right EAP server. This means that the identity
response may contain an anonymous identity and just contain realm
information. In other cases, the identity exchange may be eliminated
altogether if there are other means for establishing the destination
realm of the request. In no case should an intermediary place any
trust in the identity information in the identity response since it
is unauthenticated and may not have any relevance to the
authenticated identity. TEAP implementations should not attempt to
compare any identity disclosed in the initial cleartext EAP Identity
response packet with those Identities authenticated in Phase 2.
Identity request/response exchanges sent after the TEAP tunnel is
established are protected from modification and eavesdropping by
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 renegotiated after the first server
authentication. To accomplish this, the server will typically not
request a certificate in the server_hello; then, after the
server_finished message is sent and before TEAP Phase 2, the server
MAY send a TLS hello_request. This allows the peer to perform client
authentication by sending a client_hello if it wants to or send a
no_renegotiation alert to the server indicating that it wants to
continue with TEAP Phase 2 instead. Assuming that the peer permits
renegotiation by sending a client_hello, then the server will respond
with server_hello, certificate, and certificate_request messages.
The peer replies with certificate, client_key_exchange, and
certificate_verify messages. Since this renegotiation occurs within
the encrypted TLS channel, it does not reveal client certificate
details. It is possible to perform certificate authentication using
an EAP method (for example, EAP-TLS) within the TLS session in TEAP
Phase 2 instead of using TLS handshake renegotiation.
7.4.2. Dictionary Attack Resistance
TEAP was designed with a focus on protected authentication methods
that typically rely on weak credentials, such as password-based
secrets. TEAP mitigates dictionary attacks by allowing the
establishment of a mutually authenticated encrypted TLS tunnel
providing confidentiality and integrity to protect the weak
credential-based authentication method.
7.4.3. Protection against Man-in-the-Middle Attacks
Allowing methods to be executed both with and without the protection
of a secure tunnel opens up a possibility of a man-in-the-middle
attack. To avoid man-in-the-middle attacks it is recommended to
always deploy authentication methods with the protection of TEAP.
TEAP provides protection from man-in-the-middle attacks even if a
deployment chooses to execute inner EAP methods both with and without
TEAP protection. TEAP prevents this attack in two ways:
1. By using the PAC-Key to mutually authenticate the peer and server
during TEAP authentication Phase 1 establishment of a secure
2. By using the keys generated by the inner authentication method
(if the inner methods are key generating) in the crypto-binding
exchange and in the generation of the key material exported by
the EAP method described in Section 5.
TEAP crypto binding does not guarantee man-in-the-middle protection
if the client allows a connection to an untrusted server, such as in
the case where the client does not properly validate the server's
certificate. If the TLS ciphersuite derives the master secret solely
from the contribution of secret data from one side of the
conversation (such as ciphersuites based on RSA key transport), then
an attacker who can convince the client to connect and engage in
authentication can impersonate the client to another server even if a
strong inner method is executed within the tunnel. If the TLS
ciphersuite derives the master secret from the contribution of
secrets from both sides of the conversation (such as in ciphersuites
based on Diffie-Hellman), then crypto binding can detect an attacker
in the conversation if a strong inner method is used.
7.4.4. PAC Binding to User Identity
A PAC may be bound to a user identity. A compliant implementation of
TEAP MUST validate that an identity obtained in the PAC-Opaque field
matches at minimum one of the identities provided in the TEAP Phase 2
authentication method. This validation provides another binding to
ensure that the intended peer (based on identity) has successfully
completed the TEAP Phase 1 and proved identity in the Phase 2
7.5. Protecting against Forged Cleartext EAP Packets
EAP Success and EAP Failure packets are, in general, sent in
cleartext and may be forged by an attacker without detection. Forged
EAP Failure packets can be used to attempt to convince an EAP peer to
disconnect. Forged EAP Success packets may be used to attempt to
convince a peer that authentication has succeeded, even though the
authenticator has not authenticated itself to the peer.
By providing message confidentiality and integrity, TEAP provides
protection against these attacks. Once the peer and authentication
server (AS) initiate the TEAP authentication Phase 2, compliant TEAP
implementations MUST silently discard all cleartext EAP messages,
unless both the TEAP peer and server have indicated success or
failure using a protected mechanism. Protected mechanisms include
the TLS alert mechanism and the protected termination mechanism
described in Section 3.3.3.
The success/failure decisions within the TEAP tunnel indicate the
final decision of the TEAP authentication conversation. After a
success/failure result has been indicated by a protected mechanism,
the TEAP peer can process unprotected EAP Success and EAP Failure
messages; however, the peer MUST ignore any unprotected EAP Success
or Failure messages where the result does not match the result of the
To abide by [RFC3748], the server sends a cleartext EAP Success or
EAP Failure packet to terminate the EAP conversation. However, since
EAP Success and EAP Failure packets are not retransmitted, the final
packet may be lost. While a TEAP-protected EAP Success or EAP
Failure packet should not be a final packet in a TEAP conversation,
it may occur based on the conditions stated above, so an EAP peer
should not rely upon the unprotected EAP Success and Failure
7.6. Server Certificate Validation
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. When performing server certificate validation,
implementations MUST provide support for the rules in [RFC5280] for
validating certificates against a known trust anchor. In addition,
implementations MUST support matching the realm portion of the peer's
NAI against a SubjectAltName of type dNSName within the server
certificate. However, in certain deployments, this might not be
turned on. Please note that in the case where the EAP authentication
is remote, 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 certification authority
(CA) controlling the intended domain and whether the authenticator
can be authorized by a server in that domain.
7.7. Tunnel PAC Considerations
Since the Tunnel PAC is stored by the peer, special care should be
given to the overall security of the peer. The Tunnel PAC MUST be
securely stored by the peer to prevent theft or forgery of any of the
Tunnel PAC components. In particular, the peer MUST securely store
the PAC-Key and protect it from disclosure or modification.
Disclosure of the PAC-Key enables an attacker to establish the TEAP
tunnel; however, disclosure of the PAC-Key does not reveal the peer
or server identity or compromise any other peer's PAC credentials.
Modification of the PAC-Key or PAC-Opaque components of the Tunnel
PAC may also lead to denial of service as the tunnel establishment
will fail. The PAC-Opaque component is the effective TLS ticket
extension used to establish the tunnel using the techniques of
[RFC5077]. Thus, the security considerations defined by [RFC5077]
also apply to the PAC-Opaque. The PAC-Info may contain information
about the Tunnel PAC such as the identity of the PAC issuer and the
Tunnel PAC lifetime for use in the management of the Tunnel PAC. The
PAC-Info should be securely stored by the peer to protect it from
disclosure and modification.
7.8. Security Claims
This section provides the needed security claim requirement for EAP
Auth. mechanism: Certificate-based, shared-secret-based, and
various tunneled authentication mechanisms.
Ciphersuite negotiation: Yes
Mutual authentication: Yes
Integrity protection: Yes. Any method executed within the TEAP
tunnel is integrity protected. The
cleartext EAP headers outside the tunnel are
not integrity protected.
Replay protection: Yes
Key derivation: Yes
Key strength: See Note 1 below.
Dictionary attack prot.: Yes
Fast reconnect: Yes
Cryptographic binding: Yes
Session independence: Yes
Key Hierarchy: Yes
Channel binding: Yes
1. BCP 86 [RFC3766] offers advice on appropriate key sizes. The
National Institute for Standards and Technology (NIST) also
offers advice on appropriate key sizes in [NIST-SP-800-57].
[RFC3766], Section 5 advises use of the following required RSA or
DH (Diffie-Hellman) module and DSA (Digital Signature Algorithm)
subgroup size in bits for a given level of attack resistance in
bits. Based on the table below, a 2048-bit RSA key is required
to provide 112-bit equivalent key strength:
Attack Resistance RSA or DH Modulus DSA subgroup
(bits) size (bits) size (bits)
----------------- ----------------- ------------
70 947 129
80 1228 148
90 1553 167
100 1926 186
150 4575 284
200 8719 383
250 14596 482
This specification is based on EAP-FAST [RFC4851], which included the
ideas and efforts of Nancy Cam-Winget, David McGrew, Joe Salowey, Hao
Zhou, Pad Jakkahalli, Mark Krischer, Doug Smith, and Glen Zorn of
Cisco Systems, Inc.
The TLV processing was inspired from work on the Protected Extensible
Authentication Protocol version 2 (PEAPv2) with Ashwin Palekar, Dan
Smith, Sean Turner, and Simon Josefsson.
The method for linking identity and proof-of-possession by placing
the tls-unique value in the challengePassword field of the CSR as
described in Section 3.8.2 was inspired by the technique described in
"Enrollment over Secure Transport" [RFC7030].
Helpful review comments were provided by Russ Housley, Jari Arkko,
Ilan Frenkel, Jeremy Steiglitz, Dan Harkins, Sam Hartman, Jim Schaad,
Barry Leiba, Stephen Farrell, Chris Lonvick, and Josh Howlett.
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC
3748, June 2004.
[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295, August
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, March 2010.
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
[RFC6677] Hartman, S., Clancy, T., and K. Hoeper, "Channel-Binding
Support for Extensible Authentication Protocol (EAP)
Methods", RFC 6677, July 2012.
9.2. Informative References
IEEE, "Local and Metropolitan Area Networks: Port-Based
Network Access Control", IEEE Standard 802.1X, December
National Institute of Standards and Technology,
"Recommendation for Key Management", NIST Special
Publication 800-57, July 2012.
[PEAP] Microsoft Corporation, "[MS-PEAP]: Protected Extensible
Authentication Protocol (PEAP)", February 2014.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, March 1998.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985,
[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
Request Syntax Specification Version 1.7", RFC 2986,
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
Dial In User Service) Support For Extensible
Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005.
[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
Authentication Protocol (EAP) Application", RFC 4072,
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol Method (EAP-FAST)", RFC 4851, May
[RFC4945] Korver, B., "The Internet IP Security PKI Profile of IKEv1
/ISAKMP, IKEv2, and PKIX", RFC 4945, August 2007.
[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", BCP
132, RFC 4962, July 2007.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, August 2008.
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, June 2008.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication
Protocol Tunneled Transport Layer Security Authenticated
Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008.
[RFC5421] Cam-Winget, N. and H. Zhou, "Basic Password Exchange
within the Flexible Authentication via Secure Tunneling
Extensible Authentication Protocol (EAP-FAST)", RFC 5421,
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009.
[RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication
Protocol (EAP) Authentication Using Only a Password", RFC
5931, August 2010.
[RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011.
[RFC6124] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An
EAP Authentication Method Based on the Encrypted Key
Exchange (EKE) Protocol", RFC 6124, February 2011.
[RFC6678] Hoeper, K., Hanna, S., Zhou, H., and J. Salowey,
"Requirements for a Tunnel-Based Extensible Authentication
Protocol (EAP) Method", RFC 6678, July 2012.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, June 2013.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
[RFC7029] Hartman, S., Wasserman, M., and D. Zhang, "Extensible
Authentication Protocol (EAP) Mutual Cryptographic
Binding", RFC 7029, October 2013.
[RFC7030] Pritikin, M., Yee, P., and D. Harkins, "Enrollment over
Secure Transport", RFC 7030, October 2013.
[X.690] ITU-T, "ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, November 2008.
Appendix B. Major Differences from EAP-FAST
This document is a new standard tunnel EAP method based on revision
of EAP-FAST version 1 [RFC4851] that contains improved flexibility,
particularly for negotiation of cryptographic algorithms. The major
1. The EAP method name has been changed from EAP-FAST to TEAP; this
change thus requires that a new EAP Type be assigned.
2. This version of TEAP MUST support TLS 1.2 [RFC5246].
3. The key derivation now makes use of TLS keying material exporters
[RFC5705] and the PRF and hash function negotiated in TLS. This
is to simplify implementation and better support cryptographic
4. TEAP is in full conformance with TLS ticket extension [RFC5077]
as described in Section 3.2.2.
5. Support is provided for passing optional Outer TLVs in the first
two message exchanges, in addition to the Authority-ID TLV data
6. Basic password authentication on the TLV level has been added in
addition to the existing inner EAP method.
7. Additional TLV types have been defined to support EAP channel
binding and metadata. They are the Identity-Type TLV and
Channel-Binding TLVs, defined in Section 4.2.