Re: [Emu] Proposed Resolution for Errata 5845
I think this one is ready to go. The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20 Errata 5845: https://www.rfc-editor.org/errata/eid5845 Proposed Status: Verified Revision: Section 3.3.1 says: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. 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. It should say: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. Upon completion of an EAP authentication method, the server MUST send an Intermediate-Result TLV indicating the result. Notes: Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "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", Section 3.3.3 says "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", 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV. It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that. On Mon, Oct 26, 2020 at 8:23 PM Joseph Salowey wrote: > > > On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar > wrote: > >> >It should say: >> > >> > EAP method messages are carried within EAP-Payload TLVs defined in >> > Section 4.2.10. Upon method completion, the server MUST send an >> > Intermediate-Result TLV indicating the result. >> >> Jouni explained in errata 5767 that not all EAP methods are EAP >> authentication methods, to be exact. In the proposed fix for errata 5767 >> you have already suggested that for Section 3.3.1 text: >> >> >Section 3.3.1 >> > >> >It should say: >> >> > EAP method messages are carried within EAP-Payload TLVs defined in >> > Section 4.2.10. Upon completion of each EAP authentication method in >> > the tunnel, the server MUST send an Intermediate-Result TLV >> > indicating the result. >> >> > [Joe] Yes, I think you are correct. > > >> >> >> On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey wrote: >> >>> Errata 5845: https://www.rfc-editor.org/errata/eid5845 >>> Proposed Status: Verified >>> Revision: >>> >>> Section 3.3.1 says: >>> >>>EAP method messages are carried within EAP-Payload TLVs defined in >>>Section 4.2.10. 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. >>> >>> It should say: >>> >>>EAP method messages are carried within EAP-Payload TLVs defined in >>>Section 4.2.10. Upon method completion, the server MUST send an >>>Intermediate-Result TLV indicating the result. >>> >>> Notes: >>> >>> Description of whether Intermediate-Result TLV is supposed to be used in >>> the case where only a single inner EAP authentication method is used. >>> Section 3.3.1 says "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", Section 3.3.3 says "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", 4.2.13 says "It MUST be included with the >>> Intermediate-Result TLV to perform cryptographic binding after each >>> successful EAP method in a sequence of EAP methods", Annex C.3 shows an >>> example exchange with a single inner EAP authentication method with use of >>> Intermediate-Result TLV. >>> >>> It looks like the majority of the places discussion this topic implies >>> that there is going to be an Intermediate-Result TLV after each inner EAP >>> authentication method and the text in 3.3.1 is the only clear case of >>> conflicting (or well, at least misleading if one were to claim it does not >>> explicitly say MUST NOT for the one inner EAP authentication method case). >>> As such, I'd conclude the Intermediate-Result TLV is indeed going to be >>> exchanged afte
Re: [Emu] Proposed Resolution for Errata 5845
On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar wrote: > >It should say: > > > > EAP method messages are carried within EAP-Payload TLVs defined in > > Section 4.2.10. Upon method completion, the server MUST send an > > Intermediate-Result TLV indicating the result. > > Jouni explained in errata 5767 that not all EAP methods are EAP > authentication methods, to be exact. In the proposed fix for errata 5767 > you have already suggested that for Section 3.3.1 text: > > >Section 3.3.1 > > > >It should say: > > > EAP method messages are carried within EAP-Payload TLVs defined in > > Section 4.2.10. Upon completion of each EAP authentication method in > > the tunnel, the server MUST send an Intermediate-Result TLV > > indicating the result. > > [Joe] Yes, I think you are correct. > > > On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey wrote: > >> Errata 5845: https://www.rfc-editor.org/errata/eid5845 >> Proposed Status: Verified >> Revision: >> >> Section 3.3.1 says: >> >>EAP method messages are carried within EAP-Payload TLVs defined in >>Section 4.2.10. 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. >> >> It should say: >> >>EAP method messages are carried within EAP-Payload TLVs defined in >>Section 4.2.10. Upon method completion, the server MUST send an >>Intermediate-Result TLV indicating the result. >> >> Notes: >> >> Description of whether Intermediate-Result TLV is supposed to be used in >> the case where only a single inner EAP authentication method is used. >> Section 3.3.1 says "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", Section 3.3.3 says "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", 4.2.13 says "It MUST be included with the >> Intermediate-Result TLV to perform cryptographic binding after each >> successful EAP method in a sequence of EAP methods", Annex C.3 shows an >> example exchange with a single inner EAP authentication method with use of >> Intermediate-Result TLV. >> >> It looks like the majority of the places discussion this topic implies >> that there is going to be an Intermediate-Result TLV after each inner EAP >> authentication method and the text in 3.3.1 is the only clear case of >> conflicting (or well, at least misleading if one were to claim it does not >> explicitly say MUST NOT for the one inner EAP authentication method case). >> As such, I'd conclude the Intermediate-Result TLV is indeed going to be >> exchanged after each EAP authentication method and the proposed text change >> to 3.3.1 covers that. >> > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Proposed Resolution for Errata 5845
>It should say: > > EAP method messages are carried within EAP-Payload TLVs defined in > Section 4.2.10. Upon method completion, the server MUST send an > Intermediate-Result TLV indicating the result. Jouni explained in errata 5767 that not all EAP methods are EAP authentication methods, to be exact. In the proposed fix for errata 5767 you have already suggested that for Section 3.3.1 text: >Section 3.3.1 > >It should say: > EAP method messages are carried within EAP-Payload TLVs defined in > Section 4.2.10. Upon completion of each EAP authentication method in > the tunnel, the server MUST send an Intermediate-Result TLV > indicating the result. On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey wrote: > Errata 5845: https://www.rfc-editor.org/errata/eid5845 > Proposed Status: Verified > Revision: > > Section 3.3.1 says: > >EAP method messages are carried within EAP-Payload TLVs defined in >Section 4.2.10. 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. > > It should say: > >EAP method messages are carried within EAP-Payload TLVs defined in >Section 4.2.10. Upon method completion, the server MUST send an >Intermediate-Result TLV indicating the result. > > Notes: > > Description of whether Intermediate-Result TLV is supposed to be used in > the case where only a single inner EAP authentication method is used. > Section 3.3.1 says "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", Section 3.3.3 says "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", 4.2.13 says "It MUST be included with the > Intermediate-Result TLV to perform cryptographic binding after each > successful EAP method in a sequence of EAP methods", Annex C.3 shows an > example exchange with a single inner EAP authentication method with use of > Intermediate-Result TLV. > > It looks like the majority of the places discussion this topic implies > that there is going to be an Intermediate-Result TLV after each inner EAP > authentication method and the text in 3.3.1 is the only clear case of > conflicting (or well, at least misleading if one were to claim it does not > explicitly say MUST NOT for the one inner EAP authentication method case). > As such, I'd conclude the Intermediate-Result TLV is indeed going to be > exchanged after each EAP authentication method and the proposed text change > to 3.3.1 covers that. > ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Proposed Resolution for Errata 5845
Errata 5845: https://www.rfc-editor.org/errata/eid5845 Proposed Status: Verified Revision: Section 3.3.1 says: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. 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. It should say: EAP method messages are carried within EAP-Payload TLVs defined in Section 4.2.10. Upon method completion, the server MUST send an Intermediate-Result TLV indicating the result. Notes: Description of whether Intermediate-Result TLV is supposed to be used in the case where only a single inner EAP authentication method is used. Section 3.3.1 says "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", Section 3.3.3 says "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", 4.2.13 says "It MUST be included with the Intermediate-Result TLV to perform cryptographic binding after each successful EAP method in a sequence of EAP methods", Annex C.3 shows an example exchange with a single inner EAP authentication method with use of Intermediate-Result TLV. It looks like the majority of the places discussion this topic implies that there is going to be an Intermediate-Result TLV after each inner EAP authentication method and the text in 3.3.1 is the only clear case of conflicting (or well, at least misleading if one were to claim it does not explicitly say MUST NOT for the one inner EAP authentication method case). As such, I'd conclude the Intermediate-Result TLV is indeed going to be exchanged after each EAP authentication method and the proposed text change to 3.3.1 covers that. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
