RFC Errata
RFC 7170, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", May 2014
Note: This RFC has been updated by RFC 9427
Source of RFC: emu (sec)See Also: RFC 7170 w/ inline errata
Errata ID: 7145
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eliot Lear
Date Reported: 2022-10-05
Verifier Name: Paul Wouters
Date Verified: 2024-04-01
Section 3.3.3 says:
The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication.
It should say:
Except as noted below, the Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, regardless of whether or not there is an inner EAP method authentication
Notes:
The text contradicts itself in the same paragraph, because it goes on to say:
The server may send the final Result TLV along with an
Intermediate-Result TLV and a Crypto-Binding TLV to indicate its
intention to end the conversation. If the peer requires nothing more
from the server, it will respond with a Result TLV indicating success
accompanied by a Crypto-Binding TLV and Intermediate-Result TLV if
necessary.
So there are actually several legal combinations here:
1. Server and peer perform a crypto-binding exchange in anticipation of later sending Result TLVs
2. The server and peer combine their crypto-binding and Result TLV in the same message.
3. One side initiates a crypto-binding TLV and the OTHER responds with both crypto-binding and Result TLV.
The practice seems to be to include the crypto-binding TLVs alongside Result TLVs.