Tunnel Extensible Authentication Protocol (TEAP) Version 2

Introduction Tunnel Extensible Authentication Protocol (TEAP) version 1 was first defined in . However, implementations of that specification were found to have limited interoperability, due to the complexity of the design, and to under-specification of the cryptographic key deriviations that it defined. TEAPv1 was updated and clarified in . That document described a large amount of potential functionality in the protocol, but also noted in that only a small subset of that functionality was interoperable. In addition, the interoperable parts of the protocol had security issues which could potentially allow on-path attackers control control over the data being transported inside of the TLS tunnel. We do not review the full security issues with TEAPv1 here. Instead, we define TEAPv2, with new and simpler cryptographic key deriviations. These derivations address all of the known issues with TEAPv1. NOTE: For simplicity, this current draft defines TEAPv2 as a delta from TEAPv1. Once the overall framework has been agreed upon, this document will be updated to define TEAPv2 without referring to TEAPv1. i.e. Implementing TEAPv2 will not require anyone to read the previous TEAPv1 document.

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 (). The derivations for the Master Session Key (MSK) and the Extended Master Session Key (EMSK) () have had only minor changes. The Crypto-Binding TLV 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.

Outline of this Document This document largely follows the same outline as . 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 .

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 when, and only when, they appear in all capitals, as shown here.

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 , but was not defined in that document.

Negotiation TEAPv2 uses the same version negotiation method as is defined in , with the Version field set to two (2) for TEAPv2. TEAPv2 MUST use TLS 1.3 or later. TEAPv2 MUST NOT use TLS-PSK.

Cryptographic Calculations The crytographic calculations for TEAPv2 have been substantially simplified from those defined in .

TEAP Authentication Phase 1: Key Derivations The session key seed is the same as defined in for TEAPv2. That definition is reproduced here verbatim:

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 . 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).

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 () 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 (), how the seed is used to derive an intermediate key (), how the seed is updated after each round (), and finally how the master keys are generated from the final round seed ().

Intermediate Key Seeding The intermediate compound key deriviations for TEAPv2 depend on the following RoundSeed structure. The RoundSeed structure is defined using the same syntax as is used for TLS : The RoundSeed structure fields have the following definitions: PrevRoundKey

A key which ties the previous round to the current round.

MSK

The Master Session Key (MSK) from the current round.

EMSK

The Extended Master Session Key (EMSK) from the current round.

At the start of Phase 2, the first 40 octets of the session_key_seed MUST be copied to the PrevRoundKey field of the RoundSeed structure. All other fields MUST be set to zero. The MSK and EMSK are taken from the inner authentication method for the current round. If the MSK or the EMSK are not available, the corresponding field in RoundSeed is set to zero. The RoundSeed structure is updated after the DerivedKey structure (, below) is calculated. The process to fill in and update the RoundSeed structure is defined below in .

Key Derivation After a successful inner round, a DerivedKey is calculated. The DerivedKey depends on the current value of RoundSeed via the following calculation. The DerivedKey is 72 octets in length, and is assigned to the following data structure: The DerivedKey structure fields have the following definitions: RoundKey

A key which is associated with this round. This field is copied to the PrevRoundKey field of the RoundSeed structure.

CMK

The Compound MAC Key (CMK) The CMK is mixed with with data from the TEAP negotiation to create the Compound-MAC ({#computing-compound-mac}) which is used in the Crypto-Binding TLV.

Updating RoundSeed The RoundSeed structure MUST be updated after the DerivedKey structure has been calculated. Each field is updated via the process defined below. Note that the RoundSeed value is updated at the end of each inner round, before the Crypto-Binding TLV is calculated. This update ensures that the final master key calculation (, below) uses a different value for the RoundSeed structure than was used in the last inner exchange. PrevRoundKey

The RoundKey field from the DerivedKey structure is copied to the PrevRoundKey field.

MSK

If the inner round did not define an MSK, this field is set to all zeros. If the inner method derived an MSK, then only the first 32 octets of that MSK are copied to this field.

EMSK

If the inner round did not define an EMSK, this field is set to all zeros. If the inner method derived an EMSK, then only the first 32 octets of that EMSK are copied to this field.

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: CMK is taken from the DerivedKey structure which was calculated for this round. The definition of BUFFER is the same as in 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}).

EAP Master Session Key Generation The final MSK and ESMK are generated via the following derivation: This construction ensures that the cryptographic binding requirements of are satisfied, while using a much simpler key derivation than was done for TEAPv1.

Message Formats The following sections describe the message formats used in TEAPv2. The fields are transmitted from left to right in network byte order.

EAP MTU defines a minimum EAP MTU of 1020 octets. However, it defines no maximum MTU, 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 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 () 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.

TEAPv2 Message Format The TEAPv2 message format is identical to that of TEAPv1 () with only one change: the Ver field is set to "2", to indicate that this is TEAPv2.

TEAPv2 TLVs The TEAPv2 TLV format and TLV definitions are identical to that for TEAPv1 (), with only the changes and additions noted below.

Crypto-Binding TLV The format of the TEAPv2 Crypto-Binding TLV is the same as for TEAPv1 (), with the following changes:

The Version field MUST set to two (2).
The Received-Ver field MUST be set to two (2), to indicate TEAPv2.
The Flags field MUST have value 2, to indicate that only the MSK Compound-MAC is present.
The Nonce is updated as with TEAPv1.
The ESMK Compound-MAC field is not used. It SHOULD be set to zeros by the sender. The receiver MUST ignore it.
The MSK Compound-MAC field is calculated as described above in .

Security Considerations

IANA Considerations