Few comments: 1) It seems that the server MUST send Crypto-Binding TLV after a single EAP authentication method, after each of EAP authentications methods in a sequence, after no inner method but not after Basic-Password-Authentication. Shouldn't we close this gap for the sake of simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in this case, the same as in no inner method case). Is Basic-Password-Authentication treated as a case of no inner method? Technically it is already correct but still may not be clear enough.
This also affects section "4.2.13. Crypto-Binding TLV": 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. Shouldn't we mention "inner EAP method or basic password authentication"? 2) [Minor] It is written both "EAP methods **and** basic password authentication" and "EAP methods **or**basic password authentication" in different sections above. Shouldn't we use the same all the time? On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey <j...@salowey.net> wrote: > Errata 5844: https://www.rfc-editor.org/errata/eid5844 > Status: Verified > Revision: > > Section 3.3.2 says: > > Upon receiving the response, the server > indicates the success or failure of the exchange using an > Intermediate-Result TLV. > > It Should say: > > Upon receiving the response, the server MUST > indicate the success or failure of the exchange using an > Intermediate-Result TLV. > > Section 3.6 says: > > 3. The Intermediate-Result TLVs carry success or failure indications of > the individual EAP methods in TEAP Phase 2. > > It Should say: > > 3. The Intermediate-Result TLVs carry success or failure indications of > the individual EAP methods and basic password authentication in TEAP Phase > 2. > > Section 4.2.11 says: > > The Intermediate-Result TLV provides support for acknowledged intermediate > Success and Failure messages between multiple inner EAP methods within EAP. > > It Should say: > > The Intermediate-Result TLV provides support for acknowledged intermediate > Success and Failure messages between multiple inner EAP methods or basic > password authentication within EAP. > > Section C.1 says: > > <- Crypto-Binding TLV (Request), > Result TLV (Success), > (Optional PAC TLV) > > Crypto-Binding TLV(Response), > Result TLV (Success), > (PAC-Acknowledgement TLV) -> > > It should say: > > <- Intermediate-Result-TLV (Success), > Crypto-Binding TLV (Request), > Result TLV (Success), > (Optional PAC TLV) > > Intermediate-Result-TLV (Success), > Crypto-Binding TLV(Response), > Result TLV (Success), > (PAC-Acknowledgement TLV) -> > > Section C.2 Says: > <- Result TLV (Failure) > > Result TLV (Failure) -> > > It Should Say: > > <- Intermediate-Result-TLV (Failure), > Result TLV (Failure) > > Intermediate-Result-TLV (Failure), > Result TLV (Failure) -> > > > Notes: > > Section 3.3.2 implies that Intermediate-Result TLV is used after each > round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence > in C.1 does not show this. The proposed change in this errata adds the > Intermediate-Result TLV indication here. Similar change should be done in > C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that > include Result TLV) since the language in 3.3.2 describe the indication to > be used for both success and failure cases. > > In addition to this change in C.1, it would be good to clarify the > specification globally to avoid confusion about this case since almost all > discussion regarding Intermediate-Result TLV currently is in the context of > inner EAP authentication. 3.3.2 should have a MUST statement similar to > 3.3.1. 3.6 should cover success or failure indications of basic password > auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV > is used with both inner EAP and basic password auth. >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
