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

[Narayanan, Vidya (vidyan]

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