eap Mailing List: Re: Proposed Resolution to issue 318: Transient Session Keys

[Jari Arkko (jari.arkko]

This is mostly OK, but I have a few problems below:

> the EAP method that is used. IKEv2 does not cache EAP keying
> material or parameters, nor does it utilize the EAP Key-Lifetime
> parameter to determine the lifetime of IPsec SAs. As result,
> once IKEv2 authentication completes it is assumed that
> EAP keying material and parameters are discarded.

Hmm. This seems a bit problematic to me. In current AAA,
we do not have separate MSK and session lifetime attributes;
we just have one lifetime attribute. The description above
focuses only on the key lifetime aspects. But I would actually
like a security gateway to limit the lifetime of the SAs to
Session-Timeout in RADIUS, even if the lifetime can not be
communicated to the client.

> In order to avoid key reuse, the AAA layer MUST delete transported
> keys once they are sent.  The AAA layer MUST NOT retain keys that
> it has previously sent.  For example, a AAA
> layer that has transported the MSK MUST delete it, and keys MUST
> NOT be derived from the MSK from that point forward."

I believe we discussed this a bit in IETF-64 hokey bar bof.
The conclusion seemed to be that there are scenarios where
you need to deliver a symmetric key to two network elements
from AAA, and that we should support them. The requirement
in above text is more suited to cases where the EAP-derived
keys are used between the client and a single network
element.  So, should we say something that allows delivery
of a key to one or more parties, and only then deleting it?
OTOH, in the practical cases that I have seen for such symmetric
keys would have been better served by AAA-generated random
key than anything that has to do with EAP.

--Jari