[Emu] RFC7170bis and lack of identities
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 before it sees any user identity. This limitation means that it is impossible for the server to divide users into groups, as with: • users matching X get basic password auth • all other users get EAP Perhaps we have to define an Identity-Hint TLV which is sent by the peer as soon as the inner tunnel is established? The server can then use this hint to select which authentication method to use. i.e .when the EAP authenticator receives TEAP, it has no idea whether to pick EAP or basic password. It just has to pick one randomly, and hope for the best. If it picks the wrong one, then there are "extra" rounds of authentication, or users might not get authenticated. In practice, this likely means that TEAP implementations will either do password authentication all of the time, or EAP authentication all of the time. But not both on the same server. At the minimum, this issue should be discussed in the document, with a warning of "here be dragons". If we're willing to extend TEAP, I don't think we need to rev the protocol. We could just add an optional Identity-Hint TLV which is sent by the supplicant as soon as the inner tunnel is established. If the server sees the TLV, it can use it. Otherwise, it's an optional TLV, and the server is free to ignore it. I think this is almost the last open issue. It would help to get feedback from people currently using TEAP, to see if (a) this is a real problem, or (b) it's fine and we can ignore it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Publication has been requested for draft-ietf-emu-aka-pfs-10
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 https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC7170bis and lack of identities
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 Request-Action TLV that requests EAP. I could be convinced otherwise, tho. Eliot On 01.02.23 21:42, Alan DeKok wrote: 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 before it sees any user identity. This limitation means that it is impossible for the server to divide users into groups, as with: • users matching X get basic password auth • all other users get EAP Perhaps we have to define an Identity-Hint TLV which is sent by the peer as soon as the inner tunnel is established? The server can then use this hint to select which authentication method to use. i.e .when the EAP authenticator receives TEAP, it has no idea whether to pick EAP or basic password. It just has to pick one randomly, and hope for the best. If it picks the wrong one, then there are "extra" rounds of authentication, or users might not get authenticated. In practice, this likely means that TEAP implementations will either do password authentication all of the time, or EAP authentication all of the time. But not both on the same server. At the minimum, this issue should be discussed in the document, with a warning of "here be dragons". If we're willing to extend TEAP, I don't think we need to rev the protocol. We could just add an optional Identity-Hint TLV which is sent by the supplicant as soon as the inner tunnel is established. If the server sees the TLV, it can use it. Otherwise, it's an optional TLV, and the server is free to ignore it. I think this is almost the last open issue. It would help to get feedback from people currently using TEAP, to see if (a) this is a real problem, or (b) it's fine and we can ignore it. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Request-Action Frame only in response to failed Result-TLV?
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 exchange, the *server* may decide that the client needs a new certificate. That may be due to many factors, including trust anchor changes or some sort of compromise condition. Since nobody previously implemented the PKCS#10/PKCS#7 TLVs, this shouldn't cause interoperability problems with earlier configs. Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Request-Action Frame only in response to successful or failed Result-TLV?
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 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 exchange, the *server* may decide that the client needs a new certificate. That may be due to many factors, including trust anchor changes or some sort of compromise condition. Since nobody previously implemented the PKCS#10/PKCS#7 TLVs, this shouldn't cause interoperability problems with earlier configs. Eliot ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
