Subject: [eap] RE: Issue: AAA Key Caching effectively prohibited?

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 16:20:26 -0500

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. 
Furthermore, it should be possible for the AAA server to not to delete
every key it has transported to the pass-through authenticator

Madjid

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Tuesday, November 01, 2005 2:41 PM
To: Bernard Aboba
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]; [email-masked]
Subject: Re: Issue: AAA Key Caching effectively prohibited?

Bernard Aboba wrote:

> I would like to point out one other consequence of preventing lower 
> layers (including AAA) from accessing the EMSK.  It appears to me that

> this severely restricts implementation of a key cache on the AAA
server.
>
> 1. We've talked about deletion of transported keys from the AAA 
> server.  So if an MSK (or AMSK) is calculated within the AAA layer and

> subsequently transported, that key is destroyed and cannot be cached.

 From what I can recall, our earlier discussions about this focused on
the MSK. I'm not sure the same should apply on AMSKs, particularly when
we haven't defined what they are used for.

> 2. We've talked about how the EMSK cannot be passed down to the lower 
> layer (including AAA).  Therefore the EMSK also cannot be cached by 
> the AAA layer.

This I still think should apply.

>
> 3. Given 1) and 2) what keys *can* be cached in the AAA layer?  
> Limited answers appear to be available.  Caching of MSKs does not make

> much sense, even if they are not transported in a particular 
> application, because some applications *do* transport MSKs.
>
> It would be possible for the AAA layer to request more than one AMSK, 
> then cache the AMSKs that are not transported.
>
> However, this approach does not appear to enable implementation of 
> schemes such as "Key Request" and "Pre-emptive Key Distribution", both

> of which appear to require the AAA layer to calculate AMSKs *on
demand*.
>
> To be able to do this, it would seem like the AAA server would need to

> have access to the EMSK -- since the EAP layer doesn't cache EMSKs, 
> how else could AMSKs be calculated once EAP authentication completes?
> In the case of roaming systems it is not feasible to ask the EAP layer

> to calculate every conceivable AMSK that could be useful -- there 
> could be thousands of them.

I think the answer lies in where the hierarchy is split. I still believe
EAP server should hold to EMSK and calculate AMSKs on demand.
But it seems possible to hand keys to lower layers (e.g. AAA server side
logic) that are themselves branching of to number of subkeys.
E.g. "the master handoff key for session xyz". The entity holding such
an AMSK can then branch it to, e.g., "the i:th handoff key for NAS abc".
There's a lot of room to do various designs, including proxy, AAA-server
etc. based caching.

--Jari

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 02 Nov 2005 19:49:25 -0500

What protocol do we assume for transporting an application-specific
key from the entity that implements KDF (Key Derivation Function) to
application-specific entities?  I think we don't always assume a AAA
protocol for this transport, Kerberos could be used for example and in
that case no key needs to be cached in the AAA server/proxy/client
once the generic AMSK is passed to the entity that implements KDF.

Regards,

Yoshihiro Ohba

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 02 Nov 2005 21:43:37 -0800

>every key it has transported to the pass-through authenticator

All existing AAA servers delete transported keys today -- and the "proof of 
security" required for EAP rests on this assumption.

The goal of AAA key management is to derive keys known to be fresh that are 
available only to mutually authenticated parties with a "need to know".   By 
deleting transported keys, the AAA server guarantees that it can never 
resend that same key.  The EAP authenticator does not really have much of a 
mechanism for knowing that the transported keys are fresh -- the Session-ID 
only allows it to guarantee against stale keys for the lifetime of the key 
cache.  However, deleting the transported keys on the AAA server means that 
the only way an EAP authenticator can receive a stale key is for the 
Session-ID to repeat, which is unlikely unless both the EAP peer and server 
have broken random number generators.  Also by deleting the transported 
keys, the EAP authenticator and peer can derive other keys (the TSKs) known 
only to those parties and not to the AAA server.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 06 Nov 2005 02:31:05 +0200

>be able keep the AMSK and to generate other application-specific keys
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.

>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

_______________________________________________
eap mailing list
[email-masked]
http://lists.frascone.com/mailman/listinfo/eap

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 7 Nov 2005 17:12:46 -0500

>   2. lower layer i.e. AAA requests one AMSK:

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 (AAA in this case) knows what applications

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

Yoshihiro Ohba