On Mon, 9 Jan 2023, at 22:36, Alan DeKok wrote: >> Section 3.3.1 - EAP Sequences >> >> * "Upon completion of each EAP method in the tunnel, the server MUST send an >> Intermediate-Result TLV indicating the result of the inner EAP method. The >> peer MUST respond to the Intermediate-Result TLV indicating its result. If >> the result indicates success, the Intermediate-Result TLV MUST be >> accompanied by a Crypto-Binding TLV." >> >> This could be interpreted as the peer sends the Crypto-Binding TLV (without >> reading further) and not the server. Can we amend this to something more >> front loaded such as: > > Or maybe just "the servers Intermediate-Result TLV MUST be accompanied..."
Sure. >> Section 4.3 - TLV Rules >> >> "The order of TLVs in TEAP does not matter, ..." >> >> We should though *recommend* an ordering to processing those TLVs as it >> already tripped one implementation[1]. Something like in descending priority: > > How about: > > The order in TLVs are encoded in a TEAP packet does not > matter, however there is an order in which TLVs must be processed: > > 1. Crypto-Binding-TLV > 2. Intermediate-Result-TLV > 3. Result-TLV > 4. Identity-Type TLV > 5. EAP-Payload TLV[Identity-Request] or Basic-Password-Auth-Req TLV > > That is, cryptographic binding is checked before any result is used, > and identities are checked before proposing authentication methods, as the > identity may influence the chosen authentication method. I am sure it is safe (and better/faster/...) to do Intermediate-Result-TLV first and then Crypto-Binding-TLV. Thinking of the how this would work in an implementation, if there is no Crypto-Binding-TLV when you would expect it you have a few more branches to catch whilst if you see straight up Intermediate-Result-TLV is a failure then you will just abort immediately and ignore everything else (except the error tlv). Otherwise I think this is perfect. >> Appendix C.10 - Channel Binding >> >> Maybe this is the key to what to do for a Crypto-Binding when doing >> Basic-Password-Auth and then immediately sending Result TLV indicating >> Success. The implementation is RECOMMENDED to send a Channel-Binding TLV; >> which is not a 'MUST be implemented' TLV so optional. > > I'm not sure what changes you're looking for here. Sorry, should have made myself clearer. Not a change, but this may help the other conversation around figuring out what to do with Basic-Password-Auth and making it 'safer'. Maybe the expectation of the authors originally was to run an opportunistic Channel-Binding request after a successful authentication and zero-MSK Crypto-Binding check...if I understand this all correctly. Cheers _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
