On Mon, 30 Dec 2024 at 15:29, Alan DeKok <al...@deployingradius.com> wrote:
> 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 > This change has new text about current inner method supporting EMSK. If I remember correctly, while the bis draft was actively worked on and implementations were tested, Windows did not use EMSK with inner EAP-TLS while, for example, wpa_supplicant does. Should TEAPv2 be more clear that if the current inner method supports EMSK, then it should or must use EMSK with the compound MAC calculation? As far as I know, EMSK hasn't been used by any of the current EAP methods. For example, the EPA RFC says EMSK is 'reserved', EAP-AKA says EMSK is 'for other purposes', EAP-TLS says 'Additional keying material', etc. EAP-MSCHAPv2 doesn't define EMSK at all. Now that TEAP wants to use EMSK it could be helpful for it to be clear about EMSK use. The RFC and the draft currently say: However, it is possible that the peer and server sides might not have the same capability to export EMSK. In order to maintain maximum flexibility while prevent downgrading attack, the following mechanism is in place. Would it be too strong a requirement for TEAPv2 to mandate use of EMSK when the method's specification supports it. The RFC talks about inner method supporting EMSK, but that's unclear. Does it mean the specification's support of EMSK or simply what the particular implementation has decided to support. Would it be OK and by the RFC to support EMSK every Tuesday and Friday? :-/ -- Heikki Vatiainen h...@radiatorsoftware.com
_______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
