Tunnel Extensible Authentication Protocol (TEAP) Version 2

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:

Initial-Binding TLV NOTE: We should use either the Initial-Binding TLV OR the Crypto-Binding TLV. We do not need both. The Initial-Binding TLV is used to prove that both the peer and server participated in the tunnel establishment and sequence of authentications. It also provides verification of the TEAP type, version negotiated, and Outer TLVs exchanged before the TLS tunnel establishment. The Initial-Binding TLV MUST be included in the first message sent by each party, and MUST NOT be included in any subseqent messages. A party receiving an initial message from the other party MUST check that the message contains an Initial-Binding TLV. The Initial-Binding TLV MUST be validated by the receiving part before processing any other field is process. The Initial-Binding TLV is valid only if the following checks pass on its contents:

The Version field contain a known value,
The Received-Ver field matches the TEAP version sent by the receiver during the EAP version negotiation,
The Sub-Type field is set to the correct value for this exchange,
The Compound-MAC verifies correctly.

If any of the above checks fails, then the TLV is invalid. An invalid Initial-Binding TLV is a fatal error and is handled as described in ((RFC7170bis phase 2 errors)) Once the Initial-Binding TLV(s) have been exchanged and verified, both parties know that the TLS tunnel is secure. Any subsequent Crypto-Binding TLV exchange is unnecessary. The Crypto-Binding TLV is defined as follows: M

Mandatory, set to one (1)

Reserved, set to zero (0)

TLV Type

TBD - Initial-Binding TLV

Length

Reserved

Reserved, set to zero (0)

Version

The Version field is a single octet, which is set to the version of Crypto-Binding TLV the TEAP method is using. For an implementation compliant with TEAPv1, the version number MUST be set to one (1).

Received-Ver

The Received-Ver field is a single octet and MUST be set to the TEAP version number received during version negotiation. Note that this field only provides protection against downgrade attacks, where a version of EAP requiring support for this TLV is required on both sides. For TEAPv1, this version number MUST be set to one (1).

Flags

The Flags field is four bits.
- The field MUST be set to zero. All other values of the Flags field are invalid.

Sub-Type

The Sub-Type field is four bits. Defined values include
- 0 Binding Request
  - MUST be used by authentication server.
  1 Binding Response
  - MUST be used by peer.
  All other values of the Sub-Type field are invalid.

Nonce

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. The nonce in a request MUST have its least significant bit set to zero (0), and the nonce in a response MUST have the same value as the request nonce except the least significant bit MUST be set to one (1).

Compound-MAC

The Compound-MAC field is 20 octets. The computation of the MAC is described in . Note that this field is always 20 octets in length. Any larger MAC is simply truncated. All validations or comparisons MUST be done on the truncated value.

### The CMK used to calculate the Compound-MAC is defined as Note that the Nonce is different for the Binding Request and Binding Response.

MSK and EMSK

EAP Master Session Key Generation When the Initial-Binding TLV is used, the final TEAP MSK and EMSK are not bound to the inner methods. The MSK and EMSK are derived as:

Intermediate Compound Key Derivations NOTE: We should use either the Initial-Binding TLV OR the Crypto-Binding TLV. We do not need both. If we use the Initial-Binding TLV, then the intermediate compound key deriviations are not necessary. Instead of using a complex key deriviation method as was done with TEAPv1, TEAPv2 uses a much simpler method to derive the keys. This method is split into a few steps:

define a seed which combines data from the current inner message along with data from the previous round.
Call the TLS-Exporter() function () with the above seed as the "context_value", in order to derive keying data.
Split the resulting keying data into subkeys, which are each used for different purposes.

TEAPv1 mixed data from each inner exchange into the key derivation, TEAPv2 mixes data only from inner exchanges which derive an MSK and/or an EMSK. For inner exchanges which do not derive an MSK or EMSK, TEAPv2 omits the Crypto-Binding TLV. That is, some inner authentication methods do not derive MSK or EMSK, such as Basic-Password-Req TLV and Basic-Password-Resp TLV. Other inner message exchanges such as the CSR-Attributes TLV, PKCS#7 TLV, or PKCS#10 TLV also do not derive MSK or EMSK. Inner messages which contain those TLVs MUST NOT contain a Crypto-Binding TLV. Where an inner authentication methed derives the MSK and/or EMSK, those keys are mixed with a seed from previous rounds beginning with the TEAP Phase 2 session_key_seed, to yield a new set of keys for this round. The seed from the final round is then used to derive the MSK and EMSK for TEAP.

Key Seeding All intermediate compound key deriviations for TEAPv2 depend on the same structure as input to the key deriviations. For simplicity, we define the structure using the same syntax as is used for TLS The above fields have the following definitions: PrevRoundKey

A key which ties the current exchange to the previous exchange. For the first round, this field is taken from the session_key_seed. For subsequent rounds, this field is the previous rounds RoundKey field, which is taken from the DerivedKey structure defined in the next section.

MSK

The Master Session Key (MSK) from the inner authentication method. If the MSK is longer than 32 octets, the extra octets are not used in this structure. If the inner authentication method derives an EMSK but not an MSK, then this field MUST be initialized to all zeros.

EMSK

The Extended Master Session Key (EMSK) from the inner authentication method. If the EMSK is longer than 32 octets, the extra octets are not used in this structure. If the inner authentiction method derives an MSK but not an EMSK, then this field MUST be initialized to all zeros.

Where the inner message is not an authentication method, or the inner authentication method does not derive MSK or EMSK (e.g. Basic-Password-Resp TLV), then the RoundSeed structure MUST NOT be modified. The inner message also MUST NOT send a Crypto-Binding TLV.

Key Derivation Each round produces a DerivedKey, which is depends on the RoundSeed for this round via the following calculation. The DerivedKey is 104 octets in length, and assigned to the following structure: The above fields have the following definitions: RoundKey

The key for this round, which is copied to the PrevRoundKey field in the RoundSeed structure, in order to seed the next round.

CMK

The Compound MAC Key (CMK) The CMK is mixed with with various data from the TEAP negotiation to create the Compound-MAC field of the Crypto-Binding attribute.

Challenge

The implicit challenge used for inner authentication methods such as EAP-MSCHAPv2. Unlike the implicit challenge in , this challenge is fixed size in length. The inner method uses only as much of the Challenge as it needs, and the remainder of the Challenge is ignored. If the inner method does not use a challenge, then the Challenge field is ignored.

TBD: this derivation should be from each message, NOT from each side. That is, instead of each party keeping track of "ours" and "theirs" key data, there should only be one set of data "session". The party which sends the first inner message is the one which is bootstraps this process. Each inner exchange then updates RoundKey.

Methods which do not generate MSK or EMSK Where an inner round has not generated MSK or EMSK, then the resulting inner message MUST NOT contain a Crypto-Binding TLV. For these inner messages, the RoundSeed contents MUST remain unchanged. That is, the Crypto-Binding TLV is calculated, and the RoundSeed updated only for inner authentication methods which derive MSK or EMSK. The Crypto-Binding TLV is therefore calculated as if other inner exchanges do not exist.

Computing the Compound-MAC The Compound-MAC used in the Crypto-Binding TLV is calculated exactly the same as with TEAPv1: Where CMK is the Compound MAC key derived above for this round, and the definition of BUFFER is the same as in for TEAPv1.

EAP Master Session Key Generation TEAP authentication assures that the MSK and EMSK output from running TEAP are combined result of all inner methods. The resulting MSK and ESMK are generated from the final inner method, via the following derivation: The value for RoundSeed MUST use the PrevRoundSeed from the previous round, along with the MSK and the EMSK (if available) from the final inner exchange. Where no inner exchange derives an MSK or EMSK, then the RoundSeed structure is unchanged from its initial value, which has PrevRoundKey set to Seed, and the MSK and EMSK fields are all zero.

Operation across Multiple Rounds Unlike TEAPv1, every message for every round in TEAPv2 MUST contain a Crypto-Binding TLV. This cryptographic binding helps protect from on-path attackers. Any party which sends a message in TEAPv2 MUST include a Crypto-Binding TLV. Any party which receives a message in TEAPv2 MUST verify that it contains a Crypto-Binding TLV TBD: discuss why use of MSK only in TEAPv1 is likely to avoid cryptographic binding? The session_key_seed is taken from the TLS-Exporter(), which binds it to the tunnel. But subsequent exchanges of MSK-only methods do not bind the results to the tunnel. This may or may not be a problem?

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 field is set to random values. There is no need to set the least significant bit to zero or one. If the least significant bit is set to a particular value, it has no impact on the protocol.
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 .

Note that unlike TEAPv1, only one CMK is derived for each inner message, which also means that only one Compound-MAC is derived. This Compound-MAC is placed into the MSK Compound-MAC field, and the EMSK Compound-MAC field is not used. It would be possible to redefine the entire contents of the Crypto-Binding TLV, in the interest of minor optimization. However, re-using the existing Crypto-Binding TLV format means that there are minimal changes required to implementations, which is a more useful property than saving a few octets of data being exchanged.

Implicit Challenges TBD EAP-MSCHAPv2