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

[Oleg Pekar <[e-mail]>]

>> 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 <[e-mail]> wrote:

> 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.
>
>