Thank you, Alan. Both solutions make sense to me. We just need to ensure that they are explained to the protocol implementers.
On Mon, Dec 30, 2024 at 11:44 PM Alan DeKok <al...@deployingradius.com> wrote: > > On Dec 30, 2024, at 12:44 PM, Oleg Pekar <oleg.pekar.2...@gmail.com> wrote: > > "The second use-case for EAP-TLS in Phase 2 is where both the user and > > machine use client certificates for authentication. Since TLS permits > > only one client certificate to be presented, only one certificate can > > be used in Phase 1." > > > > How are we going to figure out whether this certificate in Phase 1 > > belongs to the user or to the machine? Since we can't send > > Identity-Type TLV during TEAP tunnel establishment. > > Why not? Identity-Type can be used as an Outer TLV, and Section 2.3 > defines Outer TLVs as: > > ... > This term is used to refer to optional TLVs outside the TLS tunnel, which are > only allowed in the first two messages in the TEAP protocol. That is the > first EAP-server-to-peer message and first peer-to-EAP-server message > ... > > Which leads me to conclude that it should be possible. The peer sends EAP > Request / Identity. The server replies with TEAP and Outer TLVs. The peer > replies with TEAP and Outer TLVs, including Identity-Type. > > And double-checking the document, it looks there is no example of sending > Identity-Type as an outer TLV. > > Checking some client implementations, it looks like they don't send Outer > TLVs. But they do process the Outer TLVs sent by the server in the first > TEAP message from server to peer. > > >> Change 2 > >> Clarify "Limitations on inner methods" section. This change has no impact > >> on the protocol or implementations, and is editorial. > > "Implementations SHOULD limit the permitted inner EAP methods to a > > small set such as EAP-TLS and the EAP-FAST-MSCHAPv2 variant of > > EAP-MSCHAPv2." > > > > There is a benefit in positioning TEAP as a framework for other EAP > > methods to be used inside the tunnel. Since TEAP RFC defines exactly > > the integration of any inner method it looks sure enough to allow any > > inner method to run inside. I understand the motivation to suggest > > only methods that were thoroughly tested by the community and most of > > them support keys generation. However such a sentence could be > > off-putting implementers. > > I'll clarify. Jouni also pointed out that because EAP-TLS works, it is > highly likely that other EAP types work so long as they derive MSK and EMSK. > > Alan DeKok. > _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
