On Jan 2, 2023, at 10:07 AM, Oleg Pekar <oleg.pekar.2...@gmail.com> wrote: > [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)
If the inner EAP method just runs an EAP state machine, then it MUST finish with either EAP Success or EAP Failure. > 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) That's handled by RFC 3748. If the EAP server doesn't like the conversation for any reason, it just sends EAP Failure. TEAP just inherits that behaviour. i.e. when the EAP Failure is sent, TEAP sends Intermediate-Result with value Failure, and potentially an Error TLV indicating why it failed. I'll update the text for the Intermediate-Result TLV. > 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) Yes. > 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. The definition of Error TLV says which values are fatal. If a party sends one of those values, the other side must send a Result TLV indicating failure. > 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. I read it as referring to a non-fatal error. I'll update the text. > [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. Yes. I'll see if I can write some text which clarifies this. The only issue is that there isn't a lot of duplicate text, so there isn't a huge value in de-duplicating it. > >> 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. Sure. > >* 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. It should make a recommendation on limiting the number of inner authentications. Implementations MUST support at least 2 (for Machine and User), and SHOULD support some other number. Though we also have a limit on the overall number of packets exchanged in EAP. In practice this is about 50. That limits the amount of data which can be exchanged. > >* 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? I don't think so. :( > >> 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'll update the reference. > 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? In-line attachments might work? Or as a link to a web page? Alan DeKok. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
