RE: Strawman -10/EMSK-->AMSK
From: Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjirimotorola.com)
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.