On Fri, 10 Mar 2023 at 17:58, Joseph Salowey <j...@salowey.net> wrote:
>
> This is the working group last call for draft-ietf-emu-rfc7170bis-05
[1]. Please review the draft and send comments to the list or open issues
in GitHub [2]. Further discussion on the open issues will be considered
as part of the last call. The last call ends March 24, 2023. The chairs
would appreciate earlier reviews so we can plan to resolve issues during
our Monday meeting on the 27th.
My colleague has been working on a TEAP implementation. Earlier this week
we had a discussion about what he found out. Here's my summary of what I
learnt from him. I'm still working on to fully understand the issues, but I
also wanted to not go past the last call end.
The implementation was done based on the RFC and the draft but required
tailoring to make it interoperable with wpa_supplicant's eapol_test with
certain configurations, but that wasn't the main concern.
The main concern was about EMSK. Because EAP-FAST doesn't use EMSK S-IMCK
calculation, it's easier and more straight forward with its calculation
than TEAP. Can this simplicity brought back to TEAP by making EMSK support
mandatory as suggested below?
Problem: Not mandating EMSK
+++++++++++++++++++++++++++
Can EMSK support be made mandatory? Section 5.2 in the RFC and the draft
currently says:
If an inner method supports export of an Extended Master Session Key
(EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
[RFC5295].
The SHOULD above would change to MUST. This paragraph could then be removed
completely:
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.
The loop derived in the same section, section 5.2, (pseudo code after 'The
derivation of S-IMCK is as follows:') would then be defined to use EMSK if
the method supports it and MSK if EMSK is not supported. The end of section
5.2 that starts with 'In practice, ...' would also be removed together with
the the last two paragraphs in section '5.4 EAP Master Session Key
Generation'.
In other words, EMSK support would be mandatory and there would not be any
need to track _MSK and _EMSK derivations, as defined by end of section 5.2.
Ending up with different EMSK values
++++++++++++++++++++++++++++++++++++
If the peer and server have different capability of EMSK calculation,
correctly working implementations will end up with an error 2001 'Tunnel
Compromise Error' (or some other error). This can happen, for example, with
two chained methods that are both EMSK capable. If the server doesn't
export EMSK for the first method but both export EMSK for the second
method, the peer and server end up with different values for the EMSK after
the second round.
MSK and EMSK track inter-binding
++++++++++++++++++++++++++++++++
Another thing to note with separate MSK and EMSK chains is that there's no
binding between the two trackings (MSK vs EMSK tracking). This may also be
a concern?
Chaining is no longer full chaining
+++++++++++++++++++++++++++++++++++
Consider two methods: the first supports EMSK and the second supports only
MSK. In this case there's no compounding because the first method gets the
_EMSK suffixed results and the second gets the _MSK suffixed results.
With longer chains there would be jumps to and from MSK and EMSK depending
on what the methods support. Each time the next method has different EMSK
capability than the previous method, the compound chaining jumps to the
different tracking. There's no compound calculation for the full chain.
--
Heikki Vatiainen
h...@radiatorsoftware.com
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
