Re: Issue: AAA Key Caching effectively prohibited?
From: Jari Arkko (jari.arkkopiuha.net)
Date: Sat, 5 Nov 2005 19:33:15 -0500 (EST)
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 = ...
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.

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


Results generated by Tiger Technologies using MHonArc.