eap Mailing List: Re: keying-03: issue 215 (sa terminology)

[Bernard Aboba (aboba]

> At the moment at least I don't
> see MSK lifetime being maintained by current systems. But I may
> have missed something.

It would appear to me that various AMSK applications (e.g. Bill Arbaugh's
pre-emptive handoff work) seem to maintain such state.  The question is:
for how long? How do the parties negotiate the lifetime?

For example, when AMSKs are derived from the EMSK,  how long does the EMSK
remain in the AAA server cache for this purpose? For example, if my host
created an MSK & EMSK, then went to sleep and woke up the next day, are
those key cache entries still valid for AMSK key derivation? Is there some
implicit assumption that there is only one currently valid MSK/EMSK root
from which AMSKs are derived, and once a new MSK/EMSK set is derived on
the peer and server, then the previous hierarchy is invalidated?

The problem is that EAP and EAP methods don't negotiate a lifetime for the
EMSK/MSK, and neither does the EAP lower layer. This leaves these
lifetimes (as well as lifetimes of derived quantities such as the AAA-Key
and AMSKs) undefined after the completion of the EAP negotatiation.

There have been proposals for including a Key-Lifetime within the AAA-Token,
but that only helps in synchronization between the AAA server and authenticator.
Where the AMSK (or even AAA-Key) is potentially cached, the peer needs to be 
able to
guess whether that key remains valid at some future time.  Things get even
more messy if authorizations are provided along with the AAA-Token in
order to restrict key scope or usage.  In that case, the peer may be
unaware not only of the key lifetime, but also its usage restrictions.

I've been struggling with these issues in the Key Lifetime section, and
seem to have come to the conclusion that the problem may not be solvable
unless the Secure Association Protocol follows closely after the EAP
conversation so as to allow the key lifetimes to be negotiated there.
However, in architectures such as 802.11i there may be a (long?) hiatus
between the two protocols, during which the key lifetimes are undefined on
the peer.