eap Mailing List: Re: Key derivation and the principle of equivalence

[Yoshihiro Ohba (yohba]

On Tue, May 17, 2005 at 11:06:46PM -0700, Bernard Aboba wrote:
> > > The EAP Session-ID is effectively an SA name.
> >
> > I think naming the SA as a octetstring is over-specifying.  Isn't it
> > sufficient to say "the SA is identifed by Expanded EAP Type Code and
> > Method-ID"?
> 
> Since the SA section was somewhat confusing to people, I'd prefer to say
> "the EAP conversation is identified by the Expanded EAP Type Code and
> Method-ID".
> 
> I agree that defining the format is not required in the Key Framework
> document, but presumably it is required in the documents that define
> attribute carrying a key name or EAP session-ID.

Yes.

> 
> Unfortunately, Diameter EAP does not define the format for the key-name
> attribute, but references the EAP Key Framework draft for this
> (non-normatively at that).
> 
> So if the Key Management framework document doesn't define the format,
> then we would need to add this to the Diameter EAP document.  Since it's
> now in AUTH48, that might force it to be recycled to the AAA WG.

If I understand your comment correctly, even if the key Management
framework document defines EAP session-ID (or some other attribute
that servers as key versioning), if Diameter EAP needs to carry that
attribute, I think the attribute needs to be added in Diameter EAP
document and recycling would be needed anyways.  

> 
> > If a key caching is allowed, then I agree that we might need some
> > label for key versioning within an SA.  For example, PANA defines
> > Key-Id AVP for that purpose.  Similary, when an MSK is exported to a
> > particular EAP lower-layer session every time re-authentication is
> > performed for that session, each MSK for that session may be carried
> > with a key version information when it is carried from an EAP server
> > to an authenticator over a AAA protocol.
> 
> However, if it is clearly understood that the lower layer always uses the
> MSK, then the EAP Session-ID should be sufficient.

I agree.

> 
> Similarly, if an AMSK with a particular label is always used, then the EAP
> Session-ID is also sufficient.

I agree.

> 
> However, if *both* an MSK and AMSK could be used (as in the pre-emptive
> keying proposal by Arbaugh), then it is possible that both an MSK and AMSK
> might be present on the same authenticator, and then a means would be
> necessary to differentiate them.

Yes.  One means for that is to define a different type of
AVP/attribute for a AAA protocol to differenciate AMSK from MSK.

Yoshihiro Ohba