Hi Alan, Thanks for the prompt reply. A few things: 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). 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. What is the exact place in the flow where the Initial-Binding TLV must be sent? 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. 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. If we leave the Crypto-Binding TLV presence up to the implementers' decision, then some implementations may choose to allow skipping it or may not implement it at all. Some secure clients and servers will have a configuration option to require the Crypto-Binding TLV (like PEAPv2 in Microsoft supplicants). All this will increase the complexity for the protocol and decrease its security. Thus I would recommend keeping Crypto-Binding TLV as mandatory after each successful inner method that generates MSK and/or EMSK. 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. 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. E) Do we have any volunteers who want to implement a PoC for TEAPv2 in clients and servers during the draft development? Thanks, Oleg On Mon, Nov 10, 2025 at 2:47 AM Alan DeKok <[email protected]> wrote: > > On Nov 9, 2025, at 9:25 AM, Oleg Pekar <[email protected]> wrote: > > Few questions after the first read-through. > > > > General questions about the doc intent: > > 1) Is the plan to keep the TEAPv2 draft pointing only to the differences > > between the TEAPv1-bis draft and the TEAPv2 definition? > > Largely, yes. There is no need to repeat much of the text in 7170bis which > talks about packet format, TLV format, etc. > > > 2) If yes, then does it mean we should develop both the TEAPv1 bis and > > TEAPv2 drafts in parallel and only the combination of both final RFCs can > > define TEAPv2 completely and clearly? > > 7170bis has been submitted to the IESG for publication. The only changes > should be editorial, which means that there's no more technical development > to be done on it. > > > 3) Is the intention to recommend that implementers develop both > > TEAPv1 bis and TEAPv2 protocols and use them in parallel in their > > products? > > The intention of 7170bis is to document what implementors have done. > > I would very much hope that no one makes further changes to their TEAPv1 > implementation. The functionally documented in Section 5 of 7170bis is what > works, and pretty much nothing else will work. > > The bottom of Section 5 says: > > Any changes to the TEAP protocol can then be done in a future TEAPv2 > specification. > > Perhaps it should also say that implementers should not develop their > TEAPv1 functionality any more. If they do, there is no guarantee that the > changes will be compatible with anyone else's TEAPv1 code. > > > Technical questions and nits: > > 4) Section "3.2. Initial-Binding TLV" says: > ... > > 5) "A party receiving an initial message from the other party MUST check > ... > > 6) The TLV scheme title still says "The Crypto-Binding TLV is defined > > as follows:" while this should be "The Initial-Binding TLV is defined > > as follows:" > > 7) "The Version field is a single octet, which is set to the version > > of Crypto-Binding TLV the TEAP method is using." > > I'll fix all of those points, thanks. > > > 8) Section "3.4. Intermediate Compound Key Derivations" says: > > "define a seed which combines data from the current inner message > > along with data from the previous round" > > - should says "inner method". There is a mixture of terms "inner > > message" and "inner method", both should be explicitly explained, > > probably in the beginning of the doc > > The intent was to use the same "inner method" terminology as 7170bis. But > given some recent discussions, I suspect much of the text around IMCK, etc. > will be going away. > > So I'll omit responding to review comments for that text. > > > ... > > 17) "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." > > - the next idea may be specific to my vision of adding TEAPv2 to the > > existing TEAPv1 implementation of a typical AAA product: TEAPv1 > > implementation should stay since some other clients or servers may > > still support it. TEAPv2 may use a different codebase so as not to > > interfere with the existing TEAPv1 and to decrease the code > > complexity. Considering this, changing the format of the > > Crypto-Binding TLV sounds reasonable > > OK. > > > 18) If Initial-Binding TLV is sent in the beginning of TEAP > > conversation - as far as I understand, the Crypto-Binding TLV can be > > skipped. Wouldn’t this make the protocol vulnerable to certain > > attacks? > > One attack is where an attacker terminates the TLS tunnel, and forwards the > inner data to someone else. The Initial-Binding TLV is sufficient to protect > from this attack. > > The next question is whether we want the inner methods bound to the tunnel, > and whether we want the outer MSK bound to the inner MSKs. > > If we don't bind the inner methods to the tunnel, then a trusted > authentication server can forward the inner methods to another authentication > server. Whether this is an attack or a design requirement is perhaps a > subject for discussion. > > If we do bind the inner methods to the tunnel, then we will need the full > Crypto-Binding TLV, perhaps in a TEAPv2 format. But we then have the problem > of what to do when the inner method does not derive an MSK. e.g. Basic > Password, PKCS#7, etc. > > i.e. if we try to bind the inner methods to the tunnel, then that binding > can't be done for some inner methods. Which makes the binding work only > sometimes. That limitation suggests to me that we should just give up on > binding the inner method to the tunnel. > > We then need to decide if it's OK for a trusted authentication server to > forward inner methods somewhere else. This would be a subject for more > discussion in EMU. > > Alan DeKok. > _______________________________________________ Emu mailing list -- [email protected] To unsubscribe send an email to [email protected]
