| Re: transport of EMSK | <– Date –> <– Thread –> |
|
From: Bernard Aboba (bernard_aboba |
|
| Date: Thu, 16 Mar 2006 22:19:15 -0800 (PST) | |
Jari Arkko said:
RFC 3748 is fairly clear that transport of the EMSK is not allowed. From Section 1.2:
The EMSK is not shared with the authenticator or any other third party.
With respect to the handling of keys within EAP as well as AAA, RFC 4137 defines separate variables for the key structure within the EAP peer & server (eapKeyData) and on the authenticator in the passthrough case (aaaEapKeyData). So as far as I can tell, providing the EMSK to the lower layer on the EAP peer and server does not necessarily imply that it is transported via AAA to the authenticator.
(2) In the lower-layer based EMSK processing approach, the EMSK is delivered to the authenticator along with the MSK. KDF is selected either (a) by a default in EAP plus optional negotiation in methods, choice is communicated to the lower layer via AAA or (b) by lower layer negotiation alone. The lower layer is responsible for all use of the AMSKs in a local context. That is, no AAA key requests are needed or possible."
RFC 3748 is fairly clear that transport of the EMSK is not allowed. From Section 1.2:
The EMSK is not shared with the authenticator or any other third party.
With respect to the handling of keys within EAP as well as AAA, RFC 4137 defines separate variables for the key structure within the EAP peer & server (eapKeyData) and on the authenticator in the passthrough case (aaaEapKeyData). So as far as I can tell, providing the EMSK to the lower layer on the EAP peer and server does not necessarily imply that it is transported via AAA to the authenticator.
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.