>> 1) Section "3.3.1. EAP Sequences" >> It says "Upon completion of each EAP method in the tunnel, the server MUST send an Intermediate-Result TLV...". We have discussed previously that: >> a) EAP RFC 3748 calls EAP types 1..3 also "EAP methods":
>This is address with discussion in commit https://github.com/emu-wg/rfc7170bis/commit/57b157e748603b282f3fb1c50cea3598587c490e >In short, RFC 3748 uses "EAP method" everywhere to mean "EAP authentication method", >I'm OK with changing it, but I don't think it's a large source of confusion. [Oleg] I agree that this is a low priority remark, I just want to be sure that we don't leave any ambiguity here. The RFC 7170 implicitly says that after the peer replies with inner EAP Identity Response, and the server, for example, doesn't like the peer's identity then the server must respond with Intermediate-Result TLV. This thing is maybe good. We should make it explicitly clear after which inner EAP messages to send Intermediate-Result TLV. For this purpose I would suggest to do the following things: a) define what is "inner EAP method completion" (after EAP Success, EAP Failure, non-fatal Error TLV exchange) b) define what should the server do if it wants to reject peer's inner EAP Identity Response - to send Error TLV with Intermediate-Result TLV (Failure) c) as a consequence we should define the generic behavior (not related just to the section being discussed) after sending a non-fatal Error TLV - it should be probably accompanying it with Intermediate-Result TLV (Failure) d) another consequence - what to consider fatal and non-fatal Error TLV appearance - since the RFC 7170 has ambiguity here: "3.6.3. Phase 2 Errors If a server receives a Result TLV of failure with a fatal Error TLV, it MUST send a cleartext EAP Failure." There are few places in the RFC 7170 that mention the difference between fatal and non-fatal error ocurrence on a party side or receiving it from the other party. We can explicitly say that a party defines by itself which error to be considered for it fatal and non-fatal. e) There's another flaw in the RFC 7170 in the same section 3.6.3: The side receiving the Error TLV MAY decide to start a new inner method instead or send back a Result TLV to terminate the TEAP authentication session. What does the phrase "MAY decide to start a new inner method" mean for the peer side that cannot start an inner method and can just respond to server's inner method proposals? Maybe I should fill out an errata for this. >> 2) Regarding using both password authentication and EAP authentication method inside the same TEAP tunnel - should we merge the explanation on what to do after completion of each EAP authentication method and password authentication into a common section since the completion is the same? >Perhaps. I'm trying to keep it close to RFC 7170, as minimal changes may help it get published more quickly. [Oleg] If we decide to give more and more details on handling the inner method completion per the discussion above - then the duplication of behavior after inner EAP method and optional password authentication will grow and thus uniting their completions may make more sense. >> 4) Since multiple roundtrips of password authentication are allowed - we should specify what exactly to consider a "completion" of it since it induces the finalization flow >Perhaps it's best to add some clarifying text: >* the EAP server decides (somehow, implementation-defined) when it should stop sending Basic-Password-Auth-Req [Oleg] Good, since the peer can't explicitly control the inducing of the next cycle. Suggesting "After each optional password authentication TLV exchange [or roundtrip] the EAP server decides whether to start another exchange or to finish the flow", or similar. >* there is a limit on the number of round trips which can be made [Oleg] The RFC should not define the limit here, otherwise it should also define the other exchanges limits like the limit of the number of inner methods etc. >* Using this method to change passwords is NOT RECOMMENDED [Oleg] Correct, since EAP-FAST-GTC does allow password change explicitly in the RFC 5421. However, this way we leave the implementer with the dilema how to implement password change if the identity store is not compatible with EAP-MSCHAPv2. Are there recommended methods that we can mention? >> 5) Regarding "3.3.3. EAP-MSCHAPv2" I would suggest to explicitly mention the document where EAP-MSCHAPv2 MSK 16-octets blocks order is defined (the order that is different from EAP-FAST-MSCHAPv2). We should also mention that in PEAP and maybe some other protocols the original (non EAP-FAST-MSCHAPv2) order is used. >I can add a reference to https://datatracker.ietf.org/doc/html/draft-kamath-pppext-eap-mschapv2-02 for EAP-MSCHAPv2. [Oleg] then maybe better to refer to RFC 3079 where the order is claimed to be defined. But essentially, to be formal, it is not also explicitly defined even there! The only place we found the order is explicitly defined is here: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f >I'm less sure that it's useful to re-iterate that PEAP uses the "normal" version. I think it's best to just discuss TEAP, and how TEAP is different from everything else. [Oleg] You are absolutely right >Also for basic password, the Basic-Password-Auth-Req TLV is *not* marked mandatory. It should probably be marked mandatory to match the use of the "mandatory" bit: > >If the peer wishes to participate in password >authentication, then it responds with a Basic-Password-Auth-Resp TLV >as defined in Section 4.2.15 that contains the username and password. >If it does not wish to perform password authentication, then it >responds with a NAK TLV indicating the rejection of the Basic-Password-Auth-Req TLV. > > Whereas the later text in Section 4.2 says: > >The mandatory bit in a TLV indicates whether >support of the TLV is required. If the peer or server does not >support a TLV marked mandatory, then it MUST send a NAK TLV in the >response, and all the other TLVs in the message MUST be ignored. > It MUST NOT send a NAK >TLV for a TLV that is not marked mandatory [Oleg] Oh, this is a good catch I created basic password authentication protocol state machine diagram and would like to share it for reference. Is there a standard way to share images in the WG? Thanks Oleg On Sun, Jan 1, 2023 at 8:41 PM Alan DeKok <al...@deployingradius.com> wrote: > On Dec 31, 2022, at 12:14 PM, Oleg Pekar <oleg.pekar.2...@gmail.com> > wrote: > > > > Hi all, > > Few initial comments: > > > > > 1) Section "3.3.1. EAP Sequences" > > It says "Upon completion of each EAP method in the tunnel, the server > MUST send an Intermediate-Result TLV...". We have discussed previously that: > > a) EAP RFC 3748 calls EAP types 1..3 also "EAP methods": > > This is address with discussion in commit > https://github.com/emu-wg/rfc7170bis/commit/57b157e748603b282f3fb1c50cea3598587c490e > > In short, RFC 3748 uses "EAP method" everywhere to mean "EAP > authentication method", > > I'm OK with changing it, but I don't think it's a large source of > confusion. > > > 2) Regarding using both password authentication and EAP authentication > method inside the same TEAP tunnel - should we merge the explanation on > what to do after completion of each EAP authentication method and password > authentication into a common section since the completion is the same? > > Perhaps. I'm trying to keep it close to RFC 7170, as minimal changes > may help it get published more quickly. > > > 3) If we explicitly mention that password authentication can be used for > pin operations and thus multiple round trips are supported - should we also > allow passing user prompt and other pin related things? > > Yes. The Basic-Password-Auth-Req TLV already allows for a prompt field, > so that seems to be sufficient. > > > 4) Since multiple roundtrips of password authentication are allowed - we > should specify what exactly to consider a "completion" of it since it > induces the finalization flow > > The completion should just be sending a Result TLV? > > The final paragraph of 3.3.2 says: > > Multiple round trips of password authentication requests and responses MAY > be used to support some "housecleaning" functions such as a password or pin > change before a user is authenticated. > > Perhaps it's best to add some clarifying text: > > > * the EAP server decides (somehow, implementation-defined) when it should > stop sending Basic-Password-Auth-Req > > * there is a limit on the number of round trips which can be made > > * Using this method to change passwords is NOT RECOMMENDED > > > 5) Regarding "3.3.3. EAP-MSCHAPv2" I would suggest to explicitly > mention the document where EAP-MSCHAPv2 MSK 16-octets blocks order is > defined (the order that is different from EAP-FAST-MSCHAPv2). We should > also mention that in PEAP and maybe some other protocols the original (non > EAP-FAST-MSCHAPv2) order is used. > > I can add a reference to > https://datatracker.ietf.org/doc/html/draft-kamath-pppext-eap-mschapv2-02 > for EAP-MSCHAPv2. > > I'm less sure that it's useful to re-iterate that PEAP uses the "normal" > version. I think it's best to just discuss TEAP, and how TEAP is different > from everything else. > > Also for basic password, the Basic-Password-Auth-Req TLV is *not* > marked mandatory. It should probably be marked mandatory to match the use > of the "mandatory" bit: > > If the peer wishes to participate in password > authentication, then it responds with a Basic-Password-Auth-Resp TLV > as defined in Section 4.2.15 that contains the username and password. > If it does not wish to perform password authentication, then it > responds with a NAK TLV indicating the rejection of the > Basic-Password-Auth-Req TLV. > > Whereas the later text in Section 4.2 says: > > The mandatory bit in a TLV indicates whether > support of the TLV is required. If the peer or server does not > support a TLV marked mandatory, then it MUST send a NAK TLV in the > response, and all the other TLVs in the message MUST be ignored. > > It MUST NOT send a NAK > TLV for a TLV that is not marked mandatory > > > Alan DeKok. > >
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
