Subject: [eap] Re: keying-03: issue 215 (sa terminology)

From: Bernard Aboba <[email-masked]>
Date: Sat, 17 Jul 2004 08:04:43 -0700 (PDT)

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sat, 17 Jul 2004 19:52:15 +0300

Bernard Aboba wrote:

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

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

> between the two protocols, during which the key lifetimes are undefined on

--Jari