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

[Yoshihiro Ohba (yohba]

On Sun, Nov 06, 2005 at 02:31:05AM +0200, Jari Arkko wrote:
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> >Hi Jari, 
> >
> >Ok, if people feel strongly about not exporting the EMSK to the lower
> >layer. Then it would seem that a generic AMSK needs to be generated and
> >passed down to the lower layer (AAA server). The AAA server then should
> >be able keep the AMSK and to generate other application-specific keys
> >from the AMSK. 
> > 
> >
> I do not think we want "generic" AMSKs. We want application
> specific AMSKs. Say, one AMSK for "fast handoff" and another
> one for "Mobile IPv6 Local HA Assignment". Otherwise one
> application can break another one. But yes, from a specific
> AMSK (e.g. for fast handoff) you can create more keys,
> specific, e.g., to a particular NAS that you have moved to.
> 
> >Furthermore, it should be possible for the AAA server to not to delete
> >every key it has transported to the pass-through authentication.
> >
> Well. Not sure about this. Lets look at this in more detail
> with an example.
> 
>   1. EMSK derived in method
> 
>   2. lower layer i.e. AAA requests one AMSK:
>       AMSK_handoff = ...

I am not sure this handoff key is to be used for both L2 mobility
(Wi-Max, etc.) and L3 mobility (MIPv6, FMIPv6, etc.) or just either of
them.

>       Lower layer derives to additional keys from
>       this:
>       AMSK_handoff_auth = f(AMSK_handoff|"auth")
>       AMSK_handoff_nasgen = f(AMSK_handoff|"nasgen")
>  
>   3. EAP authentication completes, EMSK deleted
> 
>   4. AMSK_handoff deleted in AAA server, AMSK_handoff_auth
>       and _nasgen kept.
> 
>   4. Host moves to a new authenticator, requests
>       a key to that without having to reauth at EAP
>       level. Nonce included.
> 
>   5. Host and AAA server prove mutual possession of
>       AMSK_handof_auth.
> 
>   6. Calculate
>         AMSK_handoff_nas_i = f(AMSK_handof_nasgen|i|nonce)
>       AAA server sends AMSK_handoff_nas_i to new NAS.
> 
>   7. AMSK_handoff_nas_i deletede from AAA server.
> 
>   8. Host and new NAS prove mutual posessions of
>       AMSK_handoff_nas_i
> 
> So from a deletion & caching perspective we can
> observe that
> 
> o  EMSK can be deleted immediately, as long as the
>    lower layer (AAA in this case) knows what applications
>    are going to be allowed.

This actually seems prohibiting "on-demand" key generation.  

Yoshihiro Ohba


> 
> o  Each application gets a AMSK that can be kept
>    an appropriate time, depending on whether it is
>    needed or not.
> 
> o  All sent keys can be deleted.
> 
> o  Other keys that are not sent can be cached.
> 
> --Jari
> 
> _______________________________________________
> eap mailing list
> eap [at] lists.frascone.com
> http://lists.frascone.com/mailman/listinfo/eap
>