eap Mailing List: Remaining EMSK-AMSK issues???

[Nakhjiri Madjid-MNAKHJI1 (Madjid.Nakhjiri]

So assuming that the EAP layer keeps EMSK _till_ it receives AMSK1,2,
...N requests from the AAA layer and creates these AMSKs and delete
EMSK. I think we are also laxing the requirement on having delete the
cache on a key transported to an authenticator (at least Jari seemed to
see the need for doing that). we still have the following questions to
be answered?

1) The EAP layer must have a wait to see an AMSK request in its "states"
and cannot delete EMSK prematurely. Is this considered?

2) What is the protocol between eAP layer and AAA layer, does "AMSK
request" include "NO-of-requested AMSKs", so EAP layer does not delete
EMSK prematurely. 

3) We need to separate the life time of AMSK from life time of EMSK and
allow the child to survive its parents..

4) we are assuming that the AAA layer below the EAP layer at the
physical EAP server (I like to see it at AAA server) has received the
authorization for all applications for which it needs AMSKs. Which means
all the "application agents" (think possibly MIP agents) need to make
sure they direct their requests are handled by the AAA server that is
doing the AMSK requests

5) issues that Bernard mentioned at the bottom of this email that we
will start working on slowly...

Madjid

-----Original Message-----
From: Bernard Aboba [mailto:bernard_aboba [at] hotmail.com] 
Sent: Wednesday, November 02, 2005 12:18 PM
To: Nakhjiri Madjid-MNAKHJI1; aboba [at] internaut.com
Cc: jari.arkko [at] piuha.net; eap [at] frascone.com
Subject: RE: [eap] RE: Issue: AAA Key Caching effectively prohibited?


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

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