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
