Re: [Emu] draft-ietf-emu-rfc7170bis-00.txt Review

[Alan DeKok <[e-mail]>]

On Dec 31, 2022, at 12:14 PM, Oleg Pekar <[e-mail]> 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.