eap Mailing List: RE: Strawman -10/EMSK deletion requirement?

[Narayanan, Vidya (vidyan]

> > > Hi,
> > > I would like to modify what you wrote as follows:
> > > 
> > > > "The EMSK MUST NOT be used to generate any keys other 
> than AMSKs 
> > > > needed for the same EAP peer that owns the EMSK.
> > > 
> > > The EMSK MUST NOT be used to generate any keys other than
> > AMSKs needed
> > > for the same session for which the EMSK was generated.
> > > 
> > 
> > Sounds good. 
> > 
> > > > The
> > > > EMSK MUST NOT be transported out of the EAP (AAA?) Layer
> > > and MUST be
> > > > deleted when the corresponding EAP session expires.
> > > 
> > > Replace EAP (AAA?) with EAP Authentication Server; and
> > "corresponding
> > > EAP session expires" with 'corresponding session has ended'.
> > > 
> > 
> > I guess when you say EAP Authentication Server, it is a bit vague 
> > about whether that is the EAP layer or AAA layer. I'm not sure if 
> > there is value in clarifying this or if it makes more sense 
> to leave 
> > it to implementation.
> 
> Well it is not happening in the AAA layer.  My understanding 
> is that the EAP Method executes within the EAP Auth Server.  
> EAP Auth Server may or may not be colocated with the AAA server.
> 

I wonder if this is a problem - if we want the EAP AS to generate the
EMSK/AMSK and cache it for an entity (such as a MIP HA) to fetch the
AMSK later upon receiving a BU or something, the HA will only contact
the AAA server. Or, do you envision the AMSK in such cases to be sent to
the AAA server for caching? 

<snip>

> > Hmmm. If an application requires more than one key, would 
> there really 
> > be a case where creation of a root AMSK and subsequent keys 
> from that 
> > root AMSK not work? I'm wondering why you need to create multiple 
> > AMSKs for the same application directly from the EMSK. I'd 
> personally 
> > like to have no more than one key coming out of the EMSK 
> for the same 
> > key label (unique per application) in AMSK derivation.
> 
> Lets get to right down to the label(s).  If I have an 
> application called foo, can I generate two AMSKs as follows:
> 
> AMSK-FOO-A = KGF(EMSK,"FOO-A" | ......)
> AMSK-FOO-B = KGF(EMSK,"FOO-B" | ......)
> 

As far as the EAP server is concerned, I'd argue that FOO-A and FOO-B
are different applications. So, we could just say that no more than one
EMSK for a given key label is allowed. 


> I don't know why an application FOO would like to do this.  Maybe FOO
> application is really two applications.    
> 

<snip>


> > 
> > > > It is RECOMMENDED that all
> > > > necessary AMSKs corresponding to various applications be
> > generated
> > > > immediately upon EMSK generation and that the EMSK be
> > deleted right
> > > > away thereafter."
> > > 
> > > I prefer:
> > > 
> > > Once all AMSKs have been derived and the EMSK is not needed
> > it shall
> > > be deleted.
> > > 
> > 
> > To Joe's earlier points (about trying to keep the EMSK as secure as 
> > possible and delete it as quickly as possible), I would like to see 
> > this recommendation. Maybe appending the former text with 
> "When this 
> > is not feasible, the EMSK MUST be deleted once all the 
> AMSKs have been 
> > derived"
> > makes sense? 
> 
> I think my statement addresses Joe's concern.  But I find the 
> whole concept of immediacy silly especially when EAP does not 
> concern itself with key lifetimes etc....
> 
> Why are we all of a sudden concerned about timelyness?
> 

I'd personally be okay with leaving this out - even if it is recommended
to be deleted, implementations are likely to cache it for practical
reasons anyway. 

Vidya