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
