Subject: [eap] Re: Issue 114: Terminology fixes

From: [email-masked] ([email-masked])
Date: Mon, 28 Apr 2003 10:28:55 +0300

One comment and addition:

> On April 27th, Bernard Aboba wrote:
> ...
> Master Session Key (MSK)
> Keying material (64 octets) that is derived between the EAP client
> and server. The MSK is used in the derivation of Transient Session
> Keys (TSKs) for the ciphersuite negotiated between the EAP peer and
> authenticator. Where a backend authentication server is present,
> acting as an EAP server, it will typically transport the MSK to the
> authenticator.
>=20
> The MSK differs from the MK in that it not assumed to remain local
> to the EAP method, and is known by all parties in the EAP exchange:
> the peer, authenticator and the authentication server (if present).
> The MSK MAY be derived from the MK via a one-way function, or it
> may be an independent quantity. However possession of the MSK MUST
> NOT provide any information useful in determining the MK.

I think the last sentence is a method detail that applies to some
methods, but not to all. It's possible to envision a perfectly good
method where the MSK does provide information about MK, but this does
not weaken the security in any way (or a method where an intermediate
"MK step" does not really exist, so MK=3D=3DMSK).

Whether this is a good idea depends on the details of the method; but
if it's not necessary, I think it shouldn't be specified in 2284bis
with a "MUST" (the same requirement occurs also in section 7.10).
Would a "SHOULD" be a better choice?

And here's an another addition to the terminology list (I submitted
this on March 7th, but I guess it got lost somewhere).

  Message Integrity Code (MIC)
  A keyed hash function used to protect integrity of data. This is=20
  usually called a Message Authentication Code (MAC), but IEEE 802=20
  specifications (and this document) use the acronym MIC to avoid=20
  confusion with Medium Access Control.

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 28 Apr 2003 07:05:17 -0700 (PDT)

> "MK step" does not really exist, so MK=3D=3DMSK).

By "information" I meant the ability to recover the MK with less effort
than brute force. Is it possible to envisage a good method where that
would be true?

>   confusion with Medium Access Control.

Good. I will add this.