RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

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.

Report New Errata



Advanced Search