Subject: [eap] Re: MSK lifetime

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Aug 2003 07:47:33 -0700 (PDT)

Thanks for your question, Uri.

I've been working on adding a section to the Key Framework draft to
address the issue of SA lifetimes, and relationship between SAs.  I'll
post a pointer to this by the end of the week, and your review would be
most appreciated.

Much of what is going into that section comes from equivalent material
in IEEE 802.11i D5.  However, I'm not clear about all the implications of
what is written there or whether it really makes sense.

IEEE 802.11i D5 implies that the maximum lifetime of the AAA-Key SA (which
includes the AAA-Key)  is determined by the Session-Timeout
attribute sent by AAA.  Session-Timeout with no Termination-Action implies
that the session must die after the time expires.  With
Termination-Action, a re-authentication is to occur at that time.

However, the AAA-Key SA does not relate directly to the EAP SA (which
includes the MSK and EMSK derived by the EAP peer and server).  So just
because the AAA server sent a particular Session-Timeout attribute does
not necessarily imply that it deletes the MSK and EMSK after that point,
and all child SAs derived from them.  Rather, it probably has its own
internal key cache by which it manages MSK and EMSK expiration, the
structure of which is not described in IEEE 802.11i D5 (this probably
belongs in a AAA specification).

For example, in fast handoff, the AAA Server may have derived keys for
other APs via the EMSK.  Are those keys also sent with a Session-Timeout
attribute so as to cause expiration of all keying material derived from
the EAP SA at the same time?  I doubt it.

And of course, the peer is not aware of the Session-Timeout value so that
it also will not delete the MSK and EMSK at that point.  Therefore I think
it is more likely that the MSK and EMSK have lifetimes only known to the
AAA server, but that the TSKs have lifetimes that should be negotiated explicitly within
the secure association exchanges (unicast and multicast).

In terms of relationships between the different SAs (EAP SA, AAA-Key SA,
unicast secure association SA,  multicast secure association SA), I'm
still working through the implications of IEEE 802.11iD5.

For example, on failure of the unicast secure association exchange, I
believe that IEEE 802.11iD5 requires that the AAA-Key SA be deleted on
the authenticator and peer. This SA is "named" by something called the
PMKID -- which is a hash of the PMK itself and the AP and STA MAC
addresses.  So this implies that death (or lack of creation) of a child SA
can result in deletion of the parent SA.  The multicast secure association
SA can be the child of the unicast secure association SA or not (depending
on what exchange is used to create it) but I'm not sure that "death of the
child implies death of the parent" is true in that case as well.

Message: 8
Date: Wed, 06 Aug 2003 15:48:15 -0400 From: Uri Blumenthal
<[email-masked]>
Organization: Lucent Technologies
To: [email-masked]
Subject: [eap] MSK lifetime?

Folks (Bernard especially),

What's the expected life-time for MSK in the EAP key hierarchy?
Is it supposed to be discarded immediately after TSK's have been
derived? Is it supposed to be kept for the length of the current
EAP session (if so - for what purpose? Rekeying on TSK level?)?

And is session rekeying going to be considered/discussed?

Thanks!

Regards,
Uri.

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