Hi Alan, I want to better understand how you see the TEAPv2 structure. >The intent is to say that the Initial-Binding TLV is sent after the TLS tunnel >has been established and fully authenticated.
So the Initial-Binding TLV protects from downgrade attack and also protects the outer TLVs exchanged in the first roundtrip, correct? > The Initial-Binding TLV protects the TLS tunnel from attackers. It is > sufficient to protect the tunnel from observers. Isn't the outer TLS itself sufficient to protect the tunnel from attackers and 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. Right, the Crypto-Binding TLV is a strong security element of TEAPv1, it is used in EAP-FAST and PEAP as well. It will probably be a serious security downgrade for parties that use the most popular inner methods like EAP-TLS or EAP-MSCHAPv2, and it is especially important for chaining inner methods of user and machine in the same TEAPv2 tunnel. It's clear that there's no benefit for other popular Basic-Password-Authentication inner exchanges or EAP-GTC. >I would suggest instead that we probably want to *remove* the Crypto-Binding >TLV entirely. I can easily understand that intent considering all the discrepancies we had about Crypto-Binding TLV in the first spec of TEAP. However security is also a very strong concern. >I will be doing a TEAPv2, and likely also doing patches for wpa_supplicant. That's great! On Mon, Nov 10, 2025 at 10:44 PM Alan DeKok <[email protected]> wrote: > > 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]
