Hi, Few comments: >Change 1 >Clarify text on "TLS inside of TLS". This change has no impact on the >protocol or implementations, and is editorial. "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. >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. Regards Oleg On Mon, Dec 30, 2024 at 3:29 PM Alan DeKok <al...@deployingradius.com> wrote: > > Jouni Malinen and I have been having off-line discussions about TEAP > implementations. Some analysis leads us to conclude that 7170bis needs some > changes. > > The good news is that these changes simply document existing behavior. > They address corner cases which were under-specified in earlier revisions of > the document. > > The bad news is that we might need to publish TEAPv2 in order to address > the security issues discovered here. > > I've pushed 3 commits to the GitHub repository, but haven't issued a new > revision of the draft. I hope that these changes are acceptable to the WG. > I know the document is in the "almost done" phase, but it's best to have it > describe all known issues. > > Change 1: > > Clarify text on "TLS inside of TLS". This change has no impact on the > protocol or implementations, and is editorial. > > https://github.com/emu-wg/rfc7170bis/commit/1c419e5b1fdbecea3250800665013b7b569ce3e5 > > > Change 2: > > Clarify "Limitations on inner methods" section. This change has no impact on > the protocol or implementations, and is editorial. > > https://github.com/emu-wg/rfc7170bis/commit/666b575a5486b8260c610889cdb16d5e0c8cab83 > > > Change 3: > > Add an "oops" section which documents some fairly serious issues. This > change has no impact on the protocol or on existing implementations. It > simply documents issues which were not documented before. > > https://github.com/emu-wg/rfc7170bis/commit/5af2750c3a4de06655a44e2efbc241266b7187a8 > > > The outcome of the last change above is that we likely want to define > TEAPv2. The current TEAPv1 method works only for a limited set of inner > methods (EAP-TLS, and EAP-FAST-MSCHAPv2). It is highly likely that it > doesn't work for anything else. > > Any TEAPv2 would correct the above deficiencies by changing how the inner > IMSK_MSK and IMSK_EMSK are derived, along with the Crypto-Binding TLV. The > rest of the protocol could remain unchanged. > > We could also mandate support for the Identity-Hint TLV in TEAPv2. As > noted earlier on this list, the lack of Identity-Hint makes it almost > impossible to negotiate a mutually acceptable set of authentication methods. > Instead, the methods have to be defined up front on both peer and server. > Any mis-matched configuration would result in authentication failure. > > If there are no objections, I will publish a new version of the document in > early January. I don't expect that these changes will impact the publication > timeline of 7170bis. I'm looking for some additional discussion of this > topic. Comments from implementors are especially welcome. > > i.e. if Cisco, Aruba, and Microsoft can confirm that their implementation > matches this behaviour, then we're good to go. I fully expect this to be the > case, because all implementations appear to be interoperable. But it would > be good to get explicit feedback from the implementors that this is the case. > > Alan DeKok. > > _______________________________________________ > Emu mailing list -- emu@ietf.org > To unsubscribe send an email to emu-le...@ietf.org _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
