On Nov 10, 2025, at 2:03 PM, Oleg Pekar <[email protected]> wrote: > A) Can you please clarify the place of the Initial-Binding TLV in the > protocol flow? > > The draft says: > > "The Initial-Binding TLV is used to prove that both the peer and > server participated in the tunnel establishment and sequence of > authentications" > > This means that the Initial-Binding TLV is sent after all inner > methods (or at least after the first of them).
The intent is to say that the Initial-Binding TLV is sent after the TLS tunnel has been established and fully authenticated. > But the following text > says: > > "The Initial-Binding TLV MUST be included in the first message sent by > each party, and MUST NOT be included in any subseqent messages." > > This means that the Initial-Binding TLV is sent in the first TEAP > message, before the tunnel establishment is complete. The intent is to say that the Initial-Binding TLV is sent as the first TEAP message inside of the tunnel. There are no TEAP messages outside of the tunnel. There are "outer TLVs", but those aren't TEAP messages. > What is the exact place in the flow where the Initial-Binding TLV must be > sent? Inside of the TLS tunnel. As part of the TEAP message exchange. > B) "NOTE: We should use either the Initial-Binding TLV OR the Crypto- > Binding TLV. We do not need both." > > If we must use exactly one of these two TLVs and "Initial-Binding TLV > MUST be included in the first message..." then the Crypto-Binding TLV > must never be sent. We need to resolve this ambiguity. Yes. That's a discussion for this list. I welcome ideas as to what we should do here. > C) In TEAPv1 the Crypto-Binding TLV is sent after each successful > inner authentication method that generates MSK and/or EMSK, protecting > the protocol from at least two known inner method attacks. If we don't > use it, we leave the protocol unprotected unless we implement this > protection in another way. The Initial-Binding TLV protects the TLS tunnel from attackers. It is sufficient to protect the tunnel from observers. The question is whether we also want to prevent the trusted authenticator from forwarding the inner authentications methods. This forwarding is impossible in TEAPv1, due to how the Crypto-Binding TLV is designed. > If we leave the Crypto-Binding TLV presence > up to the implementers' decision, We should never do that. The question in the document, and here, is what the standard should say. It would be good to have a discussion of the pros / cons around allowing the trusted authenticator to forward the inner authentication methods. > D) The Basic-Password-Authentication method and a few others don't > generate MSK/EMSK of course. There are more inner methods that don't > (e.g. EAP-GTC). It's not possible to prohibit them in the protocol, > otherwise some ID stores will be unsupported (e.g. RADIUS token > servers, ROPC etc.). The idea in the TEAPv2 draft to skip the > Crypto-Binding TLV after such an inner method is excellent. I would suggest instead that we probably want to *remove* the Crypto-Binding TLV entirely. > On the > other hand, it makes the implementation more complex, since it > requires branching of the behavior of inside-the-tunnel TLVs after a > successful inner method with MSK/EMSK and after one without it. So > maybe it is worth sending a Crypto-Binding TLV with all zeros as the > inner method MSK to keep the pattern stable. I would much prefer to just remove it entirely from TEAPv2. > E) Do we have any volunteers who want to implement a PoC for TEAPv2 in > clients and servers during the draft development? I will be doing a TEAPv2, and likely also doing patches for wpa_supplicant. Alan DeKok. _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
