Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd)

From: [email-masked] (Joe Salowey)
Date: Wed, 19 Feb 2003 14:54:03 -0800

In my experience only the first 64B of the MSK are sent to the NAS. =20

How did we come about with the format for the MSK? =20

EAP-TLS doesn't seem to actually specify the format of the MSK. I can't
seem to find where is it specified that the IV should be the last 64
bytes of the MSK? =20

An MSK with known bytes is of dubious value. In any case unless you
change EAP-TLS the IV bytes will always be known and probably should not
be considered part of any MSK. =20

Pasi Eronen and I are working on a draft that relates to the issue of
reserving keys and key derivation that we hope to publish before the
cutoff. =20
=20
> a. Is 64B of keying material transported between AAA server=20
> and NAS *always* sufficient?
>=20
[Joe] I think for existing applications it is.  If future ciphers use
this value as key derivation key then several keys can be derived from
it to satisfy the needs of the ciphersuite in use (as in 802.11i).  If
the underlying EAP mechanism can produce 64 byte secrets then this is a
lot of key material.  However it is impossible to know how far into the
future this amount of keying material is  satisfactory.=20

> b. Does it make sense to reserve some portion of the MSK=20
> (64B?) to be generated by the EAP method, but *not* sent to the NAS?

[Joe] yes, There are applications for key material that don't directly
involve the NAS.

> c. In order to compensate for MSK(128,192) potentially being=20
> a known quantity, should EAP methods generate more than 192B of MSK?

[Joe] Part of the MSK should NEVER be a known quantity. Any known
quantity should be eliminated from the MSK.  =20

Cheers,

Joe

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Wednesday, February 19, 2003 9:26 AM
> To: [email-masked]
> Subject: [eap] Re: [AAA-WG]: Issue 397 (fwd)
>=20
>=20
>=20
>=20
> ---------- Forwarded message ----------
> Date: Wed, 19 Feb 2003 09:23:27 -0800 (PST)
> From: Bernard Aboba <[email-masked]>
> To: Glen Zorn <[email-masked]>
> Cc: AAA WG <[email-masked]>, [email-masked]
> Subject: Re: [AAA-WG]: Issue 397
>=20
> The issue appears to be whether some portion of the MSK needs=20
> to be Reserved.
>=20
> Today my understanding is that only the first 64B of the MSK=20
> is sent from AAA server to NAS [RFC2548], even though 192B of=20
> MSK are defined in [RFC2716].
>=20
> Note that the last 64B of the MSK defined in [RFC2716] are a=20
> known quantity (the IV); this is an artifact of US Export=20
> regulations which I believe are no longer in effect.
>=20
> This leaves the following situation:
>=20
> MSK(0,63)      Sent from AAA server to  NAS.
> MSK(64,127)    Not currently transported from AAA server to NAS.
> MSK(128,192)   Known quantity. Not currently transported from=20
> AAA server
>                to NAS.
>=20
> Here MSK(X,Y) =3D portion of the MSK from bytes X to Y=20
> inclusive. MSK(0,31) is known in IEEE 802.11i as the PMK.
>=20
> Some Fast Handoff proposals are attempting to achieve Perfect=20
> Forward Secrecy (PFS). The idea here is for the keying=20
> material sent to NAS1 to be cryptographically independent of=20
> the keying material sent to NAS2.
>=20
> In order to enable PFS, the keying material sent must be=20
> derived from a quantity not known by NASes. In some of the=20
> existing proposals, it has been suggested that this material=20
> be derived from the EAP Master Key (MK).
>=20
> The problem with this is that the formulas typically assume a=20
> single PRF (e.g. TLS PRF). This implies that the schemes will=20
> only work with selected EAP methods (EAP TLS, PEAP, EAP TTLS,=20
> etc.), because in some EAP methods (EAP SIM), it is not=20
> possible to export the Master Key and plug it into a PRF=20
> other than that for which the protocol was designed.
>=20
> To make the schemes more general, it is necessary for them to=20
> use a quantity that is exported by all EAP Methods -- namely the MSK.
>=20
> However, in examining the MSK it becomes clear that only=20
> MSK(64,127) could qualify for such usage. MSK(128,192) may be=20
> a known quantity, so this won't do.
>=20
> MSK(0,63) also won't work, because the goal is to enable PFS.=20
> That means that the keying material for NAS2 can't depend on=20
> the keying material for the previous NAS. If it does, then if=20
> that NAS were compromised, then it would also compromise the next NAS.
>=20
> So the only quantity left that would work is MSK(64,127).=20
> Some of the questions this raises are:
>
>=20
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 19 Feb 2003 14:06:13 -0800 (PST)

> In my experience only the first 64B of the MSK are sent to the NAS.

RFC 2548 says that only 64B are sent to the NAS.

> bytes of the MSK?

RFC 2716 specifies how to derive different keying material, but there's no
format per se. It's just easier to talk about all the keying material as a
single quantity, than to give individual names to each individual portion.
However, since this seems to be confusing, we can separate it into the
secret part (the MSK) and the possibly known part (the IV).

> An MSK with known bytes is of dubious value.

The requirement for exportability was that the IV was a known quantity.
This is how TLS key generation works in "export mode".

> be considered part of any MSK.

They are exported by that EAP method. We can call the known part "the IV"
if you like.

> > a. Is 64B of keying material transported between AAA server
> [Joe] I think for existing applications it is.

But presumably we would like this to work with future applications too,
no?

> lot of key material.

Depends on how much entropy is contained in the 64B.

> However it is impossible to know how far into the
> future this amount of keying material is  satisfactory.

There are papers that go over these kind of issues, so couldn't we look at
what the requirement would be say, if someone wanted to key 256-bit AES?

> > b. Does it make sense to reserve some portion of the MSK

I'm coming to that conclusion as well.

> quantity should be eliminated from the MSK.

I think there is some confusion in terminology here. EAP methods may pass
known quantities for an IV. But we'll keep those quantities logically
separate from the secret part, which we'll call the MSK.

If we look at it that way, then EAP methods potentially only generate 128B
of MSK. If we reserve the second 64B, and transport the first 64B to the
NAS, then we better be pretty sure that the 64B is enough to key future
ciphersuites.

That's still a lot of keying material, assuming that the underlying
entropy is large enough. So perhaps it is enough. But I'd like to see some
formal analysis of this.