Re: RE: Issue: EMSK transported to other parties?
From: Jari Arkko (jari.arkkopiuha.net)
Date: Mon, 7 Nov 2005 14:53:43 -0500 (EST)
Someone 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.
>>>      
>>>
I am confused by this. KDF is a function, not an entity. Every we subdivide
the key hierarchy in some manner we need a function to do this... this
happens in different places in the network, depending on what level of
keys we are talking about.

and Bernard wrote:

>>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.
>>    
>>
Agreed.

and Yoshi wrote:

>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.
>  
>
We can have lower layer ask for AMSKs. Such AMSKs can have further
hierarchy. But I don't think we should have a generic AMSK in the
sense that its used for multiple applications. One per app, be it
mobile ipv6 with ha x, or handoffs within this domain, or...

--Jari


Results generated by Tiger Technologies using MHonArc.