Richard Chan wrote:
EAP-Message would be the obvious candidate.
I don't think this can be correct:
EAP-Message is used between NAS and FreeRadius to encapsulate the EAP protocol between client and server.
The NAS couldn't tell that a particular EAP-Message should terminate at itself in order to extract an MSK; it would just de-capsulate and pass the payload to the peer (functioning as an EAP proxy).
Notice the Zorn draft RFC doesn't use EAP-Message; it puts an encrypted MSK in an extended attribute. This kind of makes sense since it would be clear to the NAS that it is the intended termination point.
My question was how is it done today in the field (pre this draft becoming and RFC).
There are two sets of keys. MSK is the master session key. In most (all?) EAP method, it's derived by both the client and radius server independently e.g. using Diffie-Hellman or via their mutual shared secret. SSK is the session key; it's used to actually encrypt the traffic on the wire, and is generated by the client and radius server from the MSK. The SSK is also communicated from the radius server to the NAS. Every implementation of 802.1x I've seen uses the MS-CHAP key attributes to communicate the SSK to the NAS; even if the EAP method isn't MS-CHAP. See section 3.16 of RFC3580 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. From what I can see, that Zorn draft is just an attempt to standardise how you encrypt request/reply attributes. Frankly I can't imagine why they're suggesting sending the MSK over radius - it defeats the entire point. The whole draft seems suspect IMHO. RadSec is a far more effective way of protecting the contents of a radius packet, with provably better security.
------------------------------------------------------------------------
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html