Subject: RE: [eap] Strawman -10/EMSK deletion requirement?

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 9 Mar 2006 20:50:39 -0800

> > 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'.
> 
> Motivation for above: Not sure if EAP session is defined; and 
> you delete
> the EMSK when the session is terminated either because it expired or
> because it was explicitly terminated.
> 

[Joe] I think we will probably need mopre definition around this. 
 
> > Further, an EMSK MUST NOT be used to generate more than one 
> > AMSK for a given application. 
> 
> I am not sure that the above does not pose a threat.  
> Normally we would
> think that one Application would require one AMSK.  But since 
> we are not
> defining what an application is -- and we shouldn't IMO enter that rat
> hole.  Then what if there was some application that requires an two
> AMSKs.?  Is there harm?
> 

[Joe] If they are generated at the same time I don't think there is a
problem.  If there is a delay in generation where the application
requires the EMSK to be cached it is less than optimal.  

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Mar 2006 09:46:51 +0200

>>hole.  Then what if there was some application that requires an two

This related originally to the EMSK deletion requirement. There
was an argument that the EMSK need to stay around so that
application X can keep on asking the 127th key that it needs.

Now that we seem to be saying that there is no strict EMSK
deletion requirement, this may be less urgent.

However, I still think it is a good idea that applications get
just one AMSK, and if they need multiple keys they generate
those themselves.  And the definition of an application can
be "an IANA registered label for an AMSK needed for a
specific purpose". Since the IANA registrations won't have
"handoff 1st key", "handoff 2nd key" etc but rather "handoff key",
then we satisfy this model. But this is still mostly to keep
the hierarchy structurally clean and simple, not for any
specific technical reason. (Other than that it still allows
early deletion of the EMSK better than if we would base
all keys on the EMSK.)

--Jari