| RE: Strawman -10/EMSK-->AMSK | <– Date –> <– Thread –> |
|
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri |
|
| Date: Wed, 1 Mar 2006 14:31:03 -0800 (PST) | |
So can I take this as to mean EMSK-->AMSK generation can be done at AAA layer in EAP/AAA server (backend server)? -----Original Message----- From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] Sent: Tuesday, January 31, 2006 11:02 AM To: rafa [at] dif.um.es Cc: eap [at] frascone.com Subject: Re: [eap] Strawman -10 >>The text forbidding the export was removed in Issue 320 with the >>following proposed change, so it would appear to me that the export is now allowed. > >I see. But I was wondering for example in the case of standalone >authenticator : will only MSK be available to lower layer as usual or >both >(MSK,EMSK) now? Note that the language relating to transport of the EMSK has not been touched so that restriction remains. In the passthrough case, the authenticator lower layer will not receive the EMSK, whereas it will receive it in the standalone case. Since the peer does not know which case is being run, this implies that the lower layer cannot derive the TSKs directly from the EMSK, but only from a quantity that is always available within the authenticator lower layer. As long as the keys that the lower layer depends on are always available on the authenticator, this doesn't violate mode independence from the peer's point of view. I'm not sure it necessarily violates it on the authenticator either, as long as the EMSK is destroyed after computation of the AMSK. If that is done, the end cryptographic state on the authenticator is the same in either the pass-through or standalone case. One advantage of this approach is that it keeps implementation of cryptography out of the EAP layer. Allowing cryptographic operations in the EAP layer is a problem because EAP does not support cryptographic negotiation, so that negotiation of cryptographic algorithms such as PRFs would require changes to existing EAP methods. By doing those calculations in the lower layer, instead, the Secure Association Protocol can negotiate the cryptographic algorithms and this problem is avoided. _________________________________________________________________ To unsubscribe or modify your subscription options, please visit: http://lists.frascone.com/mailman/listinfo/eap Arhives: http://lists.frascone.com/pipermail/eap
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.