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

[Bernard Aboba (bernard_aboba]

> 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.

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

> 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).

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

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

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
> server to delete the AMSK will prohibit the use of this framework by
> many of its current constituencies, examples:

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.

> 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.

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.

> 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?

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.