eap Mailing List: Re: RE: Issue: EMSK transported to other parties?

[Yoshihiro Ohba (yohba]

On Thu, Nov 03, 2005 at 04:18:16PM -0800, Bernard Aboba wrote:
> >I think it makes sense to have the KDF in the AAA server only when (1)
> >such an entity resides in the same domain as the AAA server and (2)
> >use of the AAA protocol for distributing application-specific keys to
> >application-specific entities is assumed.  For other cases (i.e.,
> >bootstrapping applications in visiting domain or using non-AAA
> >protocol for distributing application-specific keys), it might be
> >good to put the KDF in a separate entity from the AAA server.
> 
> How could an entity other than the EAP peer or server gain access to the 
> EMSK in order to generate AMSKs?  The EMSK cannot be transported, so only 
> the EAP peer and server can have access to it.   An entity must have access 
> to the EMSK to apply a Key Distribution Function (KDF) to it in order to 
> produce an AMSK.  So therefore only the EAP peer and the EAP server can 
> apply a KDF to the EMSK to produce AMSKs.

If we use generic AMSK to derive other AMSKs, the EAP server can
derive the generic AMSK from the EMSK and give it to the entity
providing KDF (and I think the generic AMSK should be
cryptographically bound to the identity of the KDF entity which could
be the AAA server or something else in general).  Once it is done, the
generic AMSK can be deleted from the EAP server and no entity needs to
access the EMSK and the generic AMSK.

Yoshihiro Ohba

> 
> Of course, a KDF is just a cryptographic function, not anything magic, so 
> any entity (EAP peer, authenticator, server) can call the function.  They 
> just can't use the EMSK as an input to it.
> 
> 
>