EAP MSK: how is it transported between server and authenticator

[Richard Chan]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20081010/aa0060fd/attachment.html>