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

From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Date: Wed, 2 Nov 2005 12:37:46 -0500

Hi Bernard,

Thanks, Actually this is the very reason I initiated this discussion. So
I think we are now converging our focus on the problem.
We need a key that can be passed to the AAA server, so that the AAA
server can use this key (instead of creating something completely
random, which is expensive) for an application that AAA server has the
right to authorize, without the AAA having to destroy the key after
transporting it.

It seems that the AMSK as an "application master key" is being derived
from EMSK, so unless there is one additional hierarchy level between
EMSK and AMSK, three things are needed:

The EMSK to be exported to AAA server (I am ok if we say EMSK is not
exported to a generic lower layer, but only to the AAA server and not
transported out of AAA server).

The AMSK is generated at the AAA server using EMSK and
application-specific information, if needed (e.g. authorization info)
information. 

The ability for AAA server to cache the AMSK as long as the EMSK is
valid.

This way the AAA server and EAP keying framework can be used in a very
clean way to bootstrap keys for many applications. Ordering the AAA
server to delete the AMSK will prohibit the use of this framework by
many of its current constituencies, examples: 

WiMAX Proxy Mobile IP: needs a Mobile IP key between the authenticator
and the home agent, AMSK can be the PMIP key to be shared between an
authenticator acting as a proxy mobile IP client and the home agent. You
send the key separately to authenticator and to Mobile IP HA. If you
delete it after first transport, how could the HA can come ask for it.

Several EAP methods (EAP-AKA) are adding fast re-authentication
procedures, based on the knowledge of master key (have to read the draft
again, to see which key is needed) after the initial authentication. If
you delete the key, you cannot perform fast re-authentications.

Handover, say another authenticator gets involved after the handover, if
you delete the initial master keys, what would the AAA server do when it
receives a request from the new authenticator?

Madjid

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

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.

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.

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.

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 02 Nov 2005 10:18:16 -0800

>right to authorize, without the AAA having to destroy the key after

I think Joe provided an answer to this -- an AMSK can be created that is 
used solely for the purposes of caching.

>transported out of AAA server).

In the current draft, the EMSK is not passed to any lower layer, including 
AAA.

>application-specific information, if needed (e.g. authorization info)

The AMSK cannot be generated by the AAA server if it doesn't have access to 
the EMSK.

>The ability for AAA server to cache the AMSK as long as the EMSK is valid.

The AMSK lifetime cannot be determined by the EMSK lifetime if an AMSK is 
cached and the EMSK is to be destroyed after EAP authentication finishes.   
The existing draft says that "death of the parent causes death of the child" 
so some adjustment is required to this to accomodate AMSK caching.

>Ordering the AAA

So far, all that has been discussed is destruction of keys that are 
transported.  AMSKs explicitly created for caching do not have to be 
deleted.

>If you delete it after first transport, how could the HA can come ask for 
>it.

One of the AAA key management requirements is that keys only be provided to 
parties that "need to know" about them, and that parties generating keys be 
mutually authenticated.  Since the AAA server does not "need to know" the 
TSKs used between the EAP peer and authenticator, it must not have access to 
the information needed to generate those TSKs -- namely the transported 
keys. By deleting the transported keys, the Secure Association Protocol 
proof of possession gains greater meaning, since the EAP peer knows that 
only the EAP authenticator and itself have access to the transported keying 
material; the AAA server does not.

>you delete the key, you cannot perform fast re-authentications.

Fast re-authentication is typically based on EAP method-specific keys which 
are not exported.  So deletion of the MSK or EMSK has no bearing on fast 
re-authentication.

>receives a request from the new authenticator?

Under Joe's proposal, an AMSK created during the original exchange can be 
cached in the AAA server.  One way that "Key Request" could work would be 
for the EAP peer to request that a key be sent to the new authenticator.  It 
would make this request by contacting the new authenticator, which would 
generate a AAA request. The EAP peer would mutually authenticate to the AAA 
server, demonstrate possession of the cached AMSK, and then request that a 
key derived from that AMSK be sent to the new EAP authenticator.   Via the 
AAA request the new EAP authenticator would mutually authenticate to the AAA 
Server.

So we have:

a. Authentication of parties:  EAP peer- AAA server;  EAP authenticator - 
EAP server;  EAP peer-authenticator (through a subsequent SAP exchange)

b. Freshness.  Presumably the EAP peer - AAA server exchange includes nonces 
exchanged by both parties to ensure freshness of the derived keys.  Also the 
SAP exchange would include a nonce exchange.

c. "Channel binding":  The EAP peer requests that a key be sent via the 
entity that it wants the key sent to.  The new authenticator identifies 
itself to the AAA server, allowing the EAP peer and AAA server to verify 
that it is telling the same information to both the AAA server and EAP peer.

---

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

>you delete the key, you cannot perform fast re-authentications.
Methods do indeed have fast re-auth schemes. However,
the keys they use are internal to the methods (TEKs) and not
exported or visible to the EAP layer, lower layer, or AAA.
That is, they do not need EMSK or AMSK support.
Caching of TEKs is allowed by the keying framework.
Section 3.3 says:

   EAP methods may cache local keying material which may persist for
   multiple EAP conversations when fast reconnect is used [RFC 3748].
   For example, EAP methods based on TLS (such as EAP-TLS [RFC2716])
   derive and cache the TLS Master Secret, typically for substantial
   time periods.

Anyway, the use of such fast re-auth schemes helps with
expensive auth procedures (such as in TLS) or when
there's a potentially high volume of operations to the
long-term secret that you may wish to optimize (such
as in SIM/AKA). However, this does not help minimize
AAA transactions to the home network. That is, its
not a fast handoff mechanism if "fast handoff" is
defined as an operation that does not need another
transaction all the way back to the home network.

--Jari

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

---

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

Bernard Aboba wrote:

> Under Joe's proposal, an AMSK created during the original exchange can 
> be cached in the AAA server.  One way that "Key Request" could work 
> would be for the EAP peer to request that a key be sent to the new 
> authenticator.  It would make this request by contacting the new 
> authenticator, which would generate a AAA request. The EAP peer would 
> mutually authenticate to the AAA server, demonstrate possession of the 
> cached AMSK, and then request that a key derived from that AMSK be 
> sent to the new EAP authenticator.   Via the AAA request the new EAP 
> authenticator would mutually authenticate to the AAA Server.
>
> So we have:
>
> a. Authentication of parties:  EAP peer- AAA server;  EAP 
> authenticator - EAP server;  EAP peer-authenticator (through a 
> subsequent SAP exchange)
>
> b. Freshness.  Presumably the EAP peer - AAA server exchange includes 
> nonces exchanged by both parties to ensure freshness of the derived 
> keys.  Also the SAP exchange would include a nonce exchange.
>
> c. "Channel binding":  The EAP peer requests that a key be sent via 
> the entity that it wants the key sent to.  The new authenticator 
> identifies itself to the AAA server, allowing the EAP peer and AAA 
> server to verify that it is telling the same information to both the 
> AAA server and EAP peer.

I like this. What do we need to make this possible in the keying
framework?

- Say EMSK is kept in method layer

- Possibly say that EMSK can be deleted after AAA has made
  its declaration of what application keys its going to need
  (assuming we always know what applications are authorized
  a priori - but I think that's a good assumption).

- Clarify the caching and parent death rules for AMSks.

--Jari