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
