Let me rephrase my question in another way (hopefully clearer): NAS acting as EAP pass-thru' device USER ---------------------- NAS ----------------------- FREERADIUS +++++++EAP+++++++++==EAP over RADIUS========== (****) EAP over RADIUS uses EAP-Message attribute. After EAP completes we have: USER ---------------------- NAS ----------------------- FREERADIUS MSK MSK ...but the NAS needs the MSK to do whatever layer 2 encryption scheme.. ..so... USER ---------------------- NAS ----------------------- FREERADIUS MSK <================= MSK (OOOO) HOW?? Ivan Kalik tnt@kalik.net suggests EAP-Message; but I think this is only used in **** not in OOOO Alan DeKok suggests 'Access-Accept for attributes named "key"'. I couldn't find any such attributes, and further more where would you configure the KEK (Key encryption key) to wrap the MSK? I hope this makes more sense. Example NAS: The following NAS actually allows you to configure an AES Key Wrap secret http://www.cisco.com/en/US/docs/wireless/controller/4.2/configuration/guide/... This document goes on to say that it works with "a key-wrap compliant RADIUS authentication server". Is FreeRadius such a "key-wrap compliant RADIUS authentication server".

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.

Phil Mayers wrote:

See my other email. MSK is not sent to the nas. SSK (derived from MSK) is, and it's sent in the attributes:

Hmm... the MSK *is* sent in the MS-MPPE-*-Key attributes. Alan DeKok.

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

On Fri, Oct 10, 2008 at 4:31 PM, Alan DeKok <aland@deployingradius.com>wrote:

Richard Chan wrote:

...

After an EAP authentication which supports key derivation (MSK) how does freeradius transport the MSK to an NAS(authenticator)? I.e., what kind of attribute is used?

Run an EAP method. Look in the Access-Accept for attributes named "key".

Can you provide a reference such an attribute defined? A glance through http://freeradius.org/rfc/attributes.html doesn't show any "key" attributes other than those related to MS-CHAP. Are you referring to the attribute 'EAP-Master-Session-Key' in http://tools.ietf.org/html/draft-aboba-radext-wlan-00#page-6. This attribute seems to do exactly what I was asking but this draft is superseded by a later version which no longer provides an attribute to transfer MSKs. http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-08.txt

...

There is an IETF draft on encrypted RADIUS attributes (which specifically mentions "EAP MSK"): http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-14.txt but this seems too recent to be actually used in the field (besides including undefined magic numbers).

It's not relevant.

Disagree - it explicitly suggests a way to transport wrapped MSKs between NAS and EAP Server. How would you do it otherwise?

...

Browsing another RADIUS server document (Cisco Secure ACS), there is a "RADIUS Key Wrap" secret that can be configured. Presumably this is used to send MSKs between server and authenticator,

That's not relevant, either.

Disagree again - it's relevant insofar as it indicates that Cisco considers a need to do key wrapping between NAS and EAP Server. Unfortunately the document doesn't explicitly mention that the 'RADIUS Key Wrap' shared secret is used to encrypt MSKs nor does it explain how it is used.

...

I couldn't find a similar configuration parameter in the freeradius config files, either radiusd.conf (http://wiki.freeradius.org/Radiusd.conf) or the client side ( http://wiki.freeradius.org/Clients.conf).

The MSK isn't configured. It's mandated by the EAP method.

I was not referring to MSK (I know that this is an artifact of the EAP method). I was referring to the KEK that is used to encrypt the MSK between FreeRADIUS and NAS.

Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html