> > 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.
Shouldn't it be: Upon receiving the response, the server MUST indicate the success or failure of the exchange using an Intermediate-Result TLV and Crypto-Binding TLV. Since necessity to send Crypto-Binding TLV after basic password authentication was already mentioned in section 4.2.13 of Errata 5775 mail thread. On Mon, Nov 2, 2020 at 12:12 AM Joseph Salowey <j...@salowey.net> wrote: > Revision for 8544. The wording needs some review. Additional revisions > were made to section 4.2.13 in 5775. > > PR Section 5: https://github.com/emu-wg/teap-errata/pull/19 > PR section 3: https://github.com/emu-wg/teap-errata/pull/22 > PR section 3: https://github.com/emu-wg/teap-errata/pull/23 > PR section 4: https://github.com/emu-wg/teap-errata/pull/24 > > 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 > each individual EAP authentication method or 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 for inner EAP authentication methods and basic > password authentication. > > 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. > > > > On Mon, Oct 26, 2020 at 8:44 PM Joseph Salowey <j...@salowey.net> wrote: > >> >> >> On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey <j...@salowey.net> wrote: >> >>> >>> >>> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar <oleg.pekar.2...@gmail.com> >>> 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. >>> >>> >> >> [Joe] Section 4.2.11 contradicts this - "An Intermediate-Result TLV >> indicating success MUST be accompanied by a Crypto-Binding TLV." I >> think we need to use the 0 MSK with the 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? >>>> >>>> [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 <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
