Jorge, thanks for correction: Intermediate-Result TLV must be sent at the end of Basic Password Authentication. I think we also need to list all four inner method cases that I mention in above explicitly, for example in "3.3.3. Protected Termination and Acknowledged Result Indication" section.
Since every Intermediate-Result TLV indicating success must be accompanied with Crypto-Binding TLV (section "4.2.11. Intermediate-Result TLV") - please refer to the Zero-MSK addition discussed in the other thread with subject "[Emu] draft-dekok-emu-tls-eap-types discussion". Zero-MSK based Crypto-Binding TLV should be used when we have no inner method or after Basic Password Authentication exchange. Per Joe's suggestion and Jorge's confirmation we should not support downgrading from MSK to Zero MSK if the inner method supports MSK. Thanks Oleg On Fri, May 22, 2020 at 11:56 PM Jorge Vergara <jover...@microsoft.com> wrote: > I am going to consider these 3 errata separately as I think it is clearest: > > > > Errata ID 5767: > > > > I believe Jouni’s differentiation of an “EAP authentication method” vs > “EAP method” is that an “EAP authentication method” has a type >= 4. Jouni > mentions this in his errata filing and it is also mentioned in RFC 3748 > Section 2.1 <https://tools.ietf.org/html/rfc3748#section-2.1> (possibly > other places also). Jouni, I apologize if I have misinterpreted – please > correct me if so. > > > > So, an EAP-Identity (type 1) request is an “EAP method”, but there is > obviously no intermediate result TLV or crypto binding TLV exchanged after > an EAP-Identity exchange. > > > > Jouni has done an excellent job in this errata of identifying where the > terminology should be updated, and I agree with Jouni’s changes. I think > the intent of the RFC in the four instances Jouni identified was fairly > clear. > > > > Errata ID 5844: > > > > Oleg, your final proposal seems to indicate that an Intermediate-Result > TLV should NOT be sent after Basic Password Authentication – I’m not sure I > follow this. Section 3.3.2 outlines that an Intermediate-Result TLV SHOULD > be sent after Basic Password Authentication. > > > > So I find this errata valid and agree with Jouni that section C.1 and C.2 > should be updated to include the Intermediate-Result TLV in the diagrams. > > > > I agree with the rest of the proposals Jouni has made as well that this > should be made clearer throughout the document. Most of the time where the > Intermediate-Result TLV is mentioned, only EAP is discussed and the Basic > Password Authentication is forgotten. I don’t believe Jouni’s proposals > change any timings – just clarify the language. > > > > Errata ID 5845: > > > > I find the errata valid and agree with Jouni. The direction in the rest of > the document seems to be that an Intermediate-Result TLV is always > exchanged (after both EAP authentication methods and Basic Password > Authentications) and the text in 3.3.1 is confusing. > > > > ***** > > > > In summary – I find all of these errata valid and appreciate Jouni’s > suggestions for clarifications. I find them all to be language > clarifications and don’t believe any exchanges need to be altered.. > > > > Oleg, your final proposal seems to be removing the exchange of > Intermediate-Result TLVs in the Basic Password Authentication case – I am > not sure I follow this but if you believe this is needed for the resolution > of this errata I would like to better understand why. > > > > Thanks, > > Jorge > > > > *From:* Emu <emu-boun...@ietf.org> *On Behalf Of * Oleg Pekar > *Sent:* Sunday, May 3, 2020 10:02 AM > *To:* Jouni Malinen <j...@w1.fi>; EMU WG <emu@ietf.org> > *Subject:* [Emu] TEAP - RFC 7170 - Errata > > > > Hi Jouni, > > You filed Errata ID: 5767, 5844, 5845 regarding sending of > Intermediate-Result TLV. Can we clarify a general scheme of > sending Intermediate-Result TLV and Crypto-Binding TLV in all cases? It is > not exactly clear what is "EAP authentication method" and what is its > different from "EAP method" (you referred to appendix C.3 as an example of > "EAP Method" but it is not clear why it is not an "EAP authentication > method" - could you please clarify). > > > > Here's the list of cases with the current RFC instructions (please add if > something is missing): > > > > 1. A single inner EAP method is executed inside the tunnel. > > *** RFC says *** > > Section 4.2.11 "An Intermediate-Result TLV indicating success MUST be > accompanied by a Crypto-Binding TLV". Section 3.3 "Phase 2 MUST always end > with a Crypto-Binding TLV exchange" > > > > 2. Multiple inner EAP methods are executed inside the tunnel. > > *** RFC says *** > > Send Intermediate-Result TLV if more than one method is going to be > executed in the tunnel. Send Crypto-Binding TLV if Intermediate-Result > TLV indicates success. > > Section 3.3.1 "If more than one method is going to be executed in the > tunnel, then upon method completion, the server MUST send an > Intermediate-Result TLV indicating the result" - wrong > > Section 3.3.3 "The Crypto-Binding TLV and Intermediate-Result TLV MUST be > included to perform cryptographic binding after each successful EAP method > in a sequence of one or more EAP methods" - correct > > > > 3. Basic Password Authentication (using Basic-Password-Auth-Req/Response) > is executed inside the tunnel > > *** RFC says *** > > Send Intermediate-Result TLV. > > Section 3.3.2 "Upon receiving the response, the server indicates the > success or failure of the exchange using an Intermediate-Result TLV" - thus > Crypto-Binding TLV MUST be also sent as quoted in #1. > > > > 4. No inner EAP method is executed inside the tunnel. > > *** RFC says *** > > Section 3.3.3 "A successful TEAP Phase 2 conversation MUST always end in > a successful Crypto-Binding TLV and Result TLV exchange. A TEAP server may > initiate the Crypto-Binding TLV and Result TLV exchange without initiating > any EAP conversation in TEAP Phase 2" > > Section 4.2.13 "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" > > > > ****** > > Jouni, you provided multiple suggestions for fixing this. Incorporating > you suggestions, the bottomline could be: > > * Send Intermediate-Result TLV after each inner EAP method but not after Basic > Password Authentication TLV exchange > > * Send Crypto-Binding TLV based on inner method MSK/EMSK after each inner > EAP method that exports MSK/EMSK and send Crypto-Binding TLV based on > Zero-MSK in case of no inner method was executed > > > > And then it should be declared explicitly and all the places where these > TLV are mentioned can be fixed accordingly. > > > > Please share your opinion. > > ~ Oleg > > > > > > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
