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

[Bernard Aboba (aboba]

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

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

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

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.