After implementing EAP-FAST and TEAP, I see a big value in simplifying the protocol state machine. If we draw a state machine diagram and it can be placed on a relatively small piece of [virtual] paper and clearly readable - it is much better for the implementers. Thus I would vote for keeping a common pattern for everything that happens in Phase 2.
Regarding Crypto-Binding TLV contents when there's no inner method crypto material available - outer tunnel crypto material is already included via S-IMCK[0]. Thanks Oleg On Thu, Dec 1, 2022 at 3:44 PM Eliot Lear <l...@lear.ch> wrote: > Hi, > > I am reviewing the errata on GitHub and would like to close on them. The > first one I am addressing is 5775, which can be found on the RFC Editor > page at https://www.rfc-editor.org/errata/eid5775. Joe's proposed fix > can be viewed at > https://github.com/emu-wg/teap-errata/commit/6fdcc5b155b8b844c4b9e2e24cddf8701a309424 > . > > Th proposed change is as follows: > > 4.2.13. Crypto-Binding TLV > > The Crypto-Binding TLV is used to prove that both the peer and server > participated in the tunnel establishment and sequence of authentications. > It also provides verification of the TEAP type, version negotiated, and > Outer TLVs exchanged before the TLS tunnel establishment. > > The Crypto-Binding TLV MUST be exchanged and verified before the final > Result TLV exchange, regardless of whether there is an inner EAP method > authentication or not. It MUST be included with the Intermediate-Result > TLV to perform cryptographic binding after each successful EAP method in a > sequence of EAP methods, before proceeding with another inner EAP methodeach > successful Intermediate-Result TLV to perform cryptographic binding after > each EAP authenticaiton or basic password method, before proceeding with > another authentication exchange. If no MSK or EMSK has been generated and a > Crypto-Binding TLS is required then the MSK Compound MAC field contains the > MAC using keys generated according to section 5.2. The Crypto-Binding TLV > is valid only if the following checks pass: > > I think we need to back up and review the three cases that we have: > > 1. There is an inner method. This means there is no issue (yay!). > 2. No inner method but authentication. > 3. No inner method and just TLVs. > > What value is crypto-binding offering in the latter two cases? I'm not > sure I see any. If that is the case, then we should suppress the > crypto-binding TLV with the result TLV. This would surely break existing > TEAP implementations, and would require a version bump. In this case, with > regard to the erratum, we would HOLD FOR UPDATE. > > If there is any value, then is simply zeroing the field seems wrong. > Section 5.3 talks about the BUFFER being created from outer TLV > information. But outer TLVs are not protected. Thus anyone can calculate > this with zero'd fields. This means we may wish to use TLS seed > information. But again, I'm not sure I see value here. > > If we choose to zero the field as is suggested in Section 5.2, then I > suggest we just say that in the text rather than referring to the entirety > of Section 5.2. In this case we could VERIFY the erratum. > > Eliot > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
