On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar <[email protected]> wrote:
> 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"? > [Joe] There are two cases where CryptoBinding is used, after completion of an EAP authentication exchange and with the Result-TLV exchange. Since password based authentication does not generate a key there is no need for crypto binding. It is just treated as a TLV. > > 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? > > [Joe] It should be consistent. Re-worded slightly: 3. The Intermediate-Result TLVs carry success or failure indications of each individual EAP authentication method or basic password authentication in TEAP Phase 2. And The Intermediate-Result TLV provides support for acknowledged intermediate Success and Failure messages for inner EAP authentication methods or basic password authentication. > > On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/emu
