Simul-posting - tks! - I think that answers my question on what goes on in
real deployments today.
I have a couple of quibbles though:
"You don't give the MSK to the NAS, that would defeat the entire point -
MSK is private between the radius server and EAP client, and is used to
derive further keys."
According to RFC5247 the MSK is potentially transported to the NAS in what it calls Phase Ib 'AAA Key transport'.
Quoting "Since existing TSK derivation and transport techniques depend solely on the MSK, in existing
implementations, this is the only keying material replicated in the AAA key transport phase 1b."
I
don't see that this RFC prohibits transport of MSK outside the EAP
server(it mentions another secret the EMSK - not used by any EAP
method at the moment - that it absolutely forbids leaving the EAP
server),
Furthermore you wouldn't want the RADIUS server to have to know every SSK-derivation scheme that crops-up
between NAS and user. I thought the reason for allowing full MSK export to the NAS is precisely the
separation
of duties: EAP Server only needs to know how to derive MSK ; it is
private to the NAS/User what encryption scheme is used and only they need to know how to derive SSKs.
With this understanding I can see the point of the Zorn draft -
it is used to transport the full MSK between NAS and EAP Server instead of making the EAP Server
responsible
for deriving TSKs (transient session keys - what you call SSKs) and
only communicating the TSKs to the NAS. Your thoughts on this?
OT - I hypothesize that the reason the EAP-Master-Session-Key
attribute was dropped from the latest version of the Aboba radext wlan
draft https://datatracker.ietf.org/drafts/draft-aboba-radext-wlan/ is because the Zorn draft
provides a more general way to communicate encrypted data within RADIUS.