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

[Jari Arkko (jari.arkko]

Bernard Aboba wrote:

> It would appear to me that various AMSK applications (e.g. Bill Arbaugh's
> pre-emptive handoff work) seem to maintain such state.  

Yes.

> The question is: for how long? How do the parties negotiate the lifetime?

Right. (And where do we document such protocols and SAs? Some
amount of specification seems appropriate in the keying draft,
but the actual protocols and detailed SA contents could be
application specific.)

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

This is accurate. (And it is a consequence of EAP not being designed
initially for this purpose.)

One thing we can do easily is to ensure that usage of quantities
such as the AMSK which have not yet (outside experiments?) been used
occurs in an appropriate way.

For instance, while we have no easy way to agree about the MSK or
EMSK lifetimes, the derivation of AMSK certainly occurs within
some application protocol context. We can require that such derivation
must also agree about the key lifetimes and other parameters that
we see as important.

We could attempt to design secure association protocols that
are better than the current ones in this respect, but I'm not
sure how helpful that is, if the current ones are still out
there. Or do you think we can prevent the use of EMSK-derived
quantities in the 802.11 context? Also, it may be hard to
convince the link layer folks to change their protocols
in order to support something which could be related to
something else than that link layer -- we have not restricted
the use of the AMSK on a particular link layer only.

Another thing that we could do easily is to require that
AAA/EAP servers that support AMSK derivation (an optional
feature) must keep the EMSK and AMSK state as long as
the session is alive. One problem with this is, however,
that it forces the authentication server to be stateful.
While many servers are stateful in order to control, e.g.,
session limits or prepaid, this is currently not a requirement.
Are we willing to put that requirement in when EMSK/AMSK
usage is needed?

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

--Jari