Tunnel Extensible Authentication Protocol (TEAP) Version 2

1.1. Common Elements With TEAPv1

Most parts of TEAPv1 are unchanged. The message and TLV formats are the same, as are the derivations for the session_key_seed ([I-D.ietf-emu-rfc7170bis], Section 6.1). The derivations for the Master Session Key (MSK) and the Extended Master Session Key (EMSK) ([I-D.ietf-emu-rfc7170bis], Section 6.4) have had only minor changes.¶

The Crypto-Binding TLV [I-D.ietf-emu-rfc7170bis], Section 4.2.13 has the same format as for TEAPv1, although its value is now calculated via a different derivation. The Crypto-Binding TLV is now used only when the inner exchange is an EAP authentication method.¶

The largest difference between TEAPv1 and TEAPv2 is in the cryptographic calculations of the intermediate keys. The calculations are simpler than the ones defined for TEAPv1, without compromising on security.¶

A related problem with TEAPv1 was that the Crypto-Binding TLV calculation had significant differences between independent implementations. These differences were due to complex derivations of multiple intermediate keys, some of which were defined ambiguously. This complexity and lack of clarity lead to interoperability problems. TEAPv2 simplifies the key deriviations, reduces the number of intermediate keys, and gives smaller (and hopefully clearer) definitions for the derivations.¶

NOTE: TEAPv2 will also include mandatory support for all protocol operations.¶

1.2. Outline of this Document

This document largely follows the same outline as [I-D.ietf-emu-rfc7170bis]. Where changes from that document are made, the same section titles are used in order to ensure easy comparison of the documents. New sections are added, with new titles. For parts of TEAP which are not mentioned herein, this document makes no changes from [I-D.ietf-emu-rfc7170bis].¶

1.3. Specification Requirements

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.4. Terminology

Round¶

• A round is one set of inner message exchanges. Each round finishes with an Interim-Result TLV and a Cryptographic-Binding TLV. Other TLVs may also be included in a round.¶

  A round can include multiple inner message exchanges, e.g. EAP-TLS.¶

  This term was used in [I-D.ietf-emu-rfc7170bis], but was not defined in that document.¶

3.1. TEAP Authentication Phase 1: Key Derivations

The session key seed is the same as defined in [I-D.ietf-emu-rfc7170bis], Section 6.2.1 for TEAPv2. That definition is reproduced here verbatim:¶

   session_key_seed = TLS-Exporter(
                      "EXPORTER: teap session key seed",, 40)

3.2. Inner Methods

There are multiple possible message exchanges for Inner Methods, including passwords, PKCS#7 data, and EAP methods. Not all of these inner methods will provide an MSK or an EMSK.¶

TEAPv2 uses the Crypto-Binding TLV to protect both parties from the attacks outlined in [RFC6677]. As those attacks are only possible when the inner method is EAP, TEAPv2 defines key derivations only when then inner method is EAP. TEAPv2 does not define key deriviations or use the Crypto-Binding TLV for other inner method exchanges.¶

The key deriviations described below MUST be done when the inner method is EAP (i.e. when the parties exchange EAP-Payload TLVs). The key deriviations described below MUST NOT be done when the inner method is anything other than EAP (i.e. when the inner method does not include EAP-Payload TLVs).¶

Since the Crypto-Binding TLV depends on the key derivations, it has the same requirements. A Crypto-Binding TLV MUST be used when the inner method is EAP. A Crypto-Binding TLV MUST NOT be used when the inner method is anything other than EAP.¶

Inner EAP methods MUST produce an MSK and/or an EMSK. Inner EAP methods which produce neither MSK or EMSK (e.g. EAP-GTC) MUST NOT be used. A party which sees an attempt to use a forbidden inner EAP method MUST either respond with an EAP NAK that suggests one or more acceptable EAP methods, or else respond with a fatal error, and an Error-TLV contain value "Invalid EAP Method" (TBD).¶

3.3. Intermediate Compound Key Derivations

The intermediate key derivation in TEAPv2 proceeds via the following steps:¶

• Combine the seed from the previous round with the MSK and/or the EMSK from the current round. If the MSK or EMSK is not available, the relevant field is set to zero. The resulting data is the "RoundSeed", which is used to seed the intermediate key derivations for this round.¶

• At the conclusion of an inner round, call the TLS-Exporter() function ([RFC8446], Section 7.5) with the RoundSeed as the "context_value" in order to derive intermediate keying data.¶

• Split the resulting intermediate keying data into two subkeys. One subkey is used as the seed to the next round. The other subkey is the Compound MAC Key (CMK) which is used to calculate the Crypto-Binding TLV.¶

The following sections explain how the round seed is created (Section 3.3.1), how the seed is used to derive an intermediate key (Section 3.3.2), how the seed is updated after each round (Section 3.3.3), and finally how the master keys are generated from the final round seed (Section 3.5).¶

   struct {
       opaque PrevRoundKey[40]
       opaque MSK[32];
       opaque EMSK[32]
    } RoundSeed

   DerivedKey = TLS-Exporter(
                "EXPORTER: TEAPv2 Inner Methods Compound Keys",
                RoundSeed, 72)

   struct {
       opaque RoundKey[40];
       opaque CMK[32]
   } DerivedKey

3.4. Computing the Compound-MAC

The Compound-MAC used in the Crypto-Binding TLV is calculated via method as for TEAPv1. That definition is reproduced here verbatim:¶

   Compound-MAC = the first 20 octets of MAC( CMK, BUFFER )

CMK is taken from the DerivedKey structure which was calculated for this round. The definition of BUFFER is the same as in [I-D.ietf-emu-rfc7170bis], Section 6.3 for TEAPv1.¶

For TEAPv2, only one CMK is derived for each inner message. This limitation also means that only one Compound-MAC is derived for the Crypto-Binding TLV ({#crypto-binding}).¶

3.5. EAP Master Session Key Generation

The final MSK and ESMK are generated via the following derivation:¶

   MSK  = the first 64 octets of TLS-PRF(RoundSeed,
          "Session Key Generating Function")
   EMSK = the first 64 octets of TLS-PRF(RoundSeed,
          "Extended Session Key Generating Function")

This construction ensures that the cryptographic binding requirements of [RFC6677] are satisfied, while using a much simpler key derivation than was done for TEAPv1.¶

4.1. EAP MTU

[RFC3748], Section 3.1 defines a minimum EAP MTU of 1020 octets. However, it defines no maximum MTU, [RFC3748] also provides no way for EAP methods to negotiate an MTU.¶

Implementation and operational experience has shown that there is a need to define a maximum MTU. Without a defined maximum, EAP peers may assume that the MTU is limited by the local network, which could be as large as 9K octets. Such large EAP packets can have issues when transiting subsequent systems in the network.¶

For example, the RADIUS protocol often carries EAP, and [RFC2865], Section 3 defines a maximum RADIUS packet length of 4096 octets. This limit can therefore be in conflict with different local network limits seen by the EAP peer.¶

As a result, TEAPv2 mandates a maximum MTU. TEAPv2 impementations are limited to sending EAP packets which are no larger than 1280 octets in size. That is, the EAP packet Length field ([RFC3748], Section 4) MUST contain a value which is no larger than 1280.¶

This size was chosen to be small enough that the TEAPv2 packets can transit nearly all networks, but large enough to not require too many message exchanges.¶

4.2. TEAPv2 Message Format

The TEAPv2 message format is identical to that of TEAPv1 ([I-D.ietf-emu-rfc7170bis], Section 4.1) with only one change: the Ver field is set to "2", to indicate that this is TEAPv2.¶

4.3. TEAPv2 TLVs

The TEAPv2 TLV format and TLV definitions are identical to that for TEAPv1 ([I-D.ietf-emu-rfc7170bis], Section 4.2), with only the changes and additions noted below.¶

7.1. Normative References

[I-D.ietf-emu-rfc7170bis]

DeKok, A., "Tunnel Extensible Authentication Protocol (TEAP) Version 1", Work in Progress, Internet-Draft, draft-ietf-emu-rfc7170bis-22, 28 May 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-22>.

[RFC3748]

Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/rfc/rfc3748>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

7.2. Informative References

[RFC2865]

Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/rfc/rfc2865>.

[RFC6677]

Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <https://www.rfc-editor.org/rfc/rfc6677>.

[RFC7170]

Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <https://www.rfc-editor.org/rfc/rfc7170>.