On 1/3/21 10:38 PM, Martin Thomson wrote:
On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote:
# Key Schedule
The other thing I observe is the way that this slices up the exporter output.
This was something that old versions of TLS did, but TLS 1.3 did away with.
Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to. This could -
and should - do the same. All it means is having more exporter labels.
I appreciate that this uses exporters now rather than abusing the internal PRF.
That's good. The next step is to dispense with the intermediate values
(Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS
exporter for each of the six values that the protocol requires. I also note
that the 0x0D value is used multiple times, unnecessarily, both as a context
strong to the exporter and as a prefix to the session ID.
[Joe] I can see your point, but I don't think the way the keys are
derived is wrong and don't really see the need to change it at this
point.
Depends on what you consider "wrong". In TLS, we did this so that you could
exercise good key hygiene. If you are backing this with PKCS#11, then you might prefer
not to be exporting the value of keys just so that you can do some slicing and then
re-import the same value. I see no reason that EAP would be above this.
I agree with Martin here. The exporter interface should be used with
labels
to achieve key separation instead of generating a giant blob and slicing and
dicing. If an EAP method doesn't use an EMSK there's no reason it needs to
generate one. Also this will allow for new keys to be defined in the future
by just exporting a new labeled key. It's not that the old way is
"wrong", it's
that it's clumsy and rigid.
regards,
Dan.
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
