[Emu] RFC7170bis and lack of identities

2023-02-01 Thread Alan DeKok
I've opened an issue: https://github.com/emu-wg/rfc7170bis/issues/14 , summarized as: When using normal EAP, the server sees the EAP Identity before it selects which EAP type is being used. However, with TEAP, the inner tunnel method (EAP or basic password) has to be chosen by the server bef

[Emu] Publication has been requested for draft-ietf-emu-aka-pfs-10

2023-02-01 Thread Peter Yee via Datatracker
Peter Yee has requested publication of draft-ietf-emu-aka-pfs-10 as Informational on behalf of the EMU working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/ ___ Emu mailing list Emu@ietf.org htt

Re: [Emu] RFC7170bis and lack of identities

2023-02-01 Thread Eliot Lear
I am wondering if we should close this issue.  At the end of the day, if the client knows it's doing something like 2FA that requires an EAP method, *it* can initiate.  If it doesn't and the server decides it needs it based on the Basic-Password-Auth-Resp, then the server can insist, using a Re

[Emu] Request-Action Frame only in response to failed Result-TLV?

2023-02-01 Thread Eliot Lear
Section 4.2.9 reads:    The Request-Action TLV MAY be sent by both the peer and the server in    response to a successful or failed Result TLV. I suggest that this text be changed to allow a Request-Action TLV to be sent at any time.  The reasoning for this is that even with a successful TLS

Re: [Emu] Request-Action Frame only in response to successful or failed Result-TLV?

2023-02-01 Thread Eliot Lear
Sorry- I misread this text.  But I think the text still needs changing for the reasons given below. Eliot On 02.02.23 08:26, Eliot Lear wrote: Section 4.2.9 reads:    The Request-Action TLV MAY be sent by both the peer and the server in    response to a successful or failed Result TLV. I