eap Mailing List: Re: Issue: AAA Key Caching effectively prohibited?

[Jari Arkko (jari.arkko]

Salowey, Joe wrote:

> [Joe] The applications define how they use AMSKs.  They could define two
> different AMSKs for caching and transport if that was what was required.
> There are lots of ways an application can misuse keys. The purpose of
> the AMSK is to keep one applications misuse of keys from harming
> another. 
>  
Right. This is what I believe we need to specify in the keying
framework. (And we can't probably specify much beyond that,
given that we don't even know what the applications are.)

> [Joe] Mostly I have reservations about caching the EMSK.  The EMSK is
> the root of a hierarchy and if you can obtain that then all uses derived
> from it are compromised.  Therefore it would be good to destroy it as
> soon as possible.  AMSKs should be cryptographically independent and it
> should not be computationally feasible to get the EMSK from and AMSK.  
>  
I agree.

Note: "destroy EMSK as soon as possible" can be
interpreted in various ways. I don't think it would be appropriate
for the EAP server to get rid of the EMSK problem by delivering
it to the lower layer and forgetting about it. Essentially, the
EMSK needs to stay in the physical box where the EAP method
runs, but we have had troubly defining what that exactly
means. Also, it only needs to exist while there's a possibility that
AMSKs can be requested. This is another hard-to-specify part -
when can AMSKs be requested?

--Jari