eap Mailing List: Re: Re: issue 361: child key expiry

[Jari Arkko (jari.arkko]

Lakshminath Dondeti wrote:

> Sure, but I'd argue that this may be a case of 'perfect' being the
> enemy of the 'good.'  Absent potentially strong keymat that might come
> from say an EAP exchange, PSK provisioning procedures (proprietary)
> might be all over the place, some result in strong keys and others not
> so strong keys!  I do understand that this issue might be out of scope
> for this draft and so might be addressed elsewhere.

Well, we do have the PSK provisioning process for the
IKEv2 if you assume there's an EAP credential that can
be used. Namely, EAP authentication in IKEv2 :-)

Of course, it has been in some cases argued that its
too slow and needs to be optimized. I'd be interested
in looking at data that says such optimizations are
needed -- given things like child SA creation,
MOBIKE or the "K" bit in Mobile IPv6, there's typically
no reason why the IKEv2 run needs to be rerun often.
In this area it would be useful to study whether
existing mechanisms are sufficient before we
create new ones.

Or are you thinking of semi-permanent PSK
provisioning? This may indeed need work. But
we should be able to do this in a different spec.

>> Re: EMSK lifetime spec. I don't see a fundamental problem
>> in specifying some general characteristics of the entire
>> key hierarchy in the keying framework doc, even if we
>> should develop some specific parts of the hierarchy in
>> some other documents. Personally, the current lifetime
>> text is appealing mainly because its so simple -- all derived
>> keys should expire latest when the exported material
>> expires. This is also good for cache management.
>
>
> That's true unless derived keys are passed to other entities.  If the
> exported keymat expires due to another EAP authentication, the server
> would have to contact all of those entities that received the derived
> keys and force key deletion.  It may be feasible in some cases and not
> in others.  It is also counter-intuitive if the keys are not
> compromised, and the EAP authentication was run due to policy changes
> that do not affect the derived key usage.

I agree, but I was thinking that the keymat expiration is
dependent on its lifetime, communicated/assumed when
its exported or transported. If expiration covers also re-
authentication then we may indeed have an issue.

--Jari