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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> > 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.
>
>
> The principle is a general one (snip)
>
> As an example, the Secure Association Protocol relies on mutual proof of
> possession of keying material to enable the EAP peer and authenticator to
> determine that they are mutually authorized.  If the keying material used
> for proof could also possessed by other parties then mutual
> authorization is not demonstrated -- the EAP peer could be talking
> to the AAA server or a proxy instead of the EAP authenticator.
>
> As a result, without key deletion, the EAP peer and authenticator no 
> longer demonstrate authorization; neither the transported keys nor the 
> derived TSKs are uniquely held;  the scope of
> transported keys and TSKs is undefined; even Channel Bindings become 
> open to forgery.

I could be missing something obvious, but I'm not sure the above
is true if we look at the details. Not all keys are created equal...
Secure Association Protocol runs on MSKs, so a compromise of
an AMSK form the same session could not compromise Secure
Association Protocol or the MSK, given that we already require
that these keys are cryptographically separate.

Similarly, if the usage of AMSK_1 in application 1 is compromised,
this does not lead to a compromise of AMSK_2 in application 2.

However, what we DO want to ensure is that if AMSKs are used
for a fast handoff design, then in that particular design
the Secure Association Protocol can still demonstrate
mutual proof of possession. This may not be trivial, but
I would note that we do not have a proposal on the table
for this, so the issue seems Someone Else's Problem from
the point of view of the EAP keying framework document.

--Jari