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

[Avi Lior (avi]

Hi, 

> -----Original Message-----
> From: Narayanan, Vidya [mailto:vidyan [at] qualcomm.com] 
> Sent: Thursday, March 09, 2006 6:53 PM
> To: Avi Lior; Salowey, Joe; Jari Arkko
> Cc: eap [at] frascone.com
> Subject: RE: [eap] Strawman -10/EMSK deletion requirement?
> 
>  

<snip>

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

We don't want the EAP AS to cache the AMSK.

The AAA isnt responsible for caching either.  If we consider RADIUS,
RADIUS is stateless, it has no caching capabilites at all.  Diameter
does (however).

So AMSK is cached outside the EAP AS and outside AAA - I belive the AMSK
is cached in another functional entity called a KeyHolder/KeyGenerator.
That solves the problem for RADIUS.

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

Fine with me.  Its not about defining an application but rather the
important piece is defining the concept of a label. 

Because you have this possiblity as well and sounds like a lable needs
to be precisely defined.

FOO-A = KGF(EMSK,"FOO" | "A" | ....);
FOO-B = KGF(EMSK,"FOO" | "B" | ....); 

So the first part "FOO" is the lable and it is the key name and
therefore must be unique within each session.  Therefore, although FOO-A
<> FOO-B, the above is illegal.

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

I agree.....but I am easy going about this either way.
 
> Vidya
>