>
> Re: caching of MSKs by IKEv2. I agree with Bernard that
this
> seems to go beyond what current RFCs say, and I also
suspect
> that there are issues that we'd like to understand
before
> such usage could be allowed. For instance, if my AAA
server
> gives you an MSK to use for IKEv2 login, letting you
use that
> key multiple times would create interesting
interactions with
> concurrent session tracking.
>
> 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.
>
I'm not convinced that all keys derived from the EMSK must
expire when
the EMSK expires - some of the keys may be exported to
other entities
which may manage lifetimes differently, depending on the use
of the key.
I agree that we need to explore that further to ensure we
don't have any
problems - which is why I'm in favor of not specifying any
EMSK child
key characteristics in this document. Given that we don't
get into EMSK
usage at all in other respects in this spec, why is lifetime
an
exception? I think that text is better left for other
documents to
specify - especially given that we will have an EMSK usage
specification.
Regards,
Vidya
____________________________________________________________
_____
To unsubscribe or modify your subscription options, please
visit:
http:/
/lists.frascone.com/mailman/listinfo/eap
Arhives: http://lists.
frascone.com/pipermail/eap
|