<div dir="ltr">Simul-posting - tks! - I think that answers my question on what goes on in<br>real deployments today.<br><br>I have a couple of quibbles though:<div class="Ih2E3d"><br><br>"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."<br><br></div>According to RFC5247 the MSK is potentially transported to the NAS in what it calls Phase Ib 'AAA Key transport'.<br><br>Quoting "Since existing TSK derivation and transport techniques depend solely on the MSK, in existing<br>

implementations, this is the only keying material replicated in the AAA key transport phase 1b."<br><br>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),<br>
<br>Furthermore you wouldn't want the RADIUS server to have to know every SSK-derivation scheme that crops-up<br>between NAS and user. I thought the reason for allowing full MSK export to the NAS is precisely the<br>
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.<br>
<br>With this understanding I can see the point of the Zorn draft -<br>it is used to transport the full MSK between NAS and EAP Server instead of making the EAP Server <br>responsible
for deriving TSKs (transient session keys - what you call SSKs) and
only communicating the TSKs to the NAS. Your thoughts on this?<br>
<br>OT - I hypothesize that the reason the EAP-Master-Session-Key
attribute was dropped from the latest version of the Aboba radext wlan
draft <a href="https://datatracker.ietf.org/drafts/draft-aboba-radext-wlan/" target="_blank">https://datatracker.ietf.org/drafts/draft-aboba-radext-wlan/</a> is because the Zorn draft<br>
provides a more general way to communicate encrypted data within RADIUS.</div>