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

From: [email-masked] (Bernard Aboba)
Date: Wed, 19 Feb 2003 09:25:54 -0800 (PST)

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

The issue appears to be whether some portion of the MSK needs to be
Reserved.

Today my understanding is that only the first 64B of the MSK is sent from
AAA server to NAS [RFC2548], even though 192B of MSK are defined in
[RFC2716].

Note that the last 64B of the MSK defined in [RFC2716] are a known
quantity (the IV); this is an artifact of US Export regulations which I
believe are no longer in effect.

This leaves the following situation:

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 AAA server
               to NAS.

Here MSK(X,Y) = portion of the MSK from bytes X to Y inclusive. MSK(0,31)
is known in IEEE 802.11i as the PMK.

Some Fast Handoff proposals are attempting to achieve Perfect Forward
Secrecy (PFS). The idea here is for the keying material sent to NAS1 to be
cryptographically independent of the keying material sent to NAS2.

In order to enable PFS, the keying material sent must be derived from a
quantity not known by NASes. In some of the existing proposals, it has
been suggested that this material be derived from the EAP Master Key (MK).

The problem with this is that the formulas typically assume a single PRF
(e.g. TLS PRF). This implies that the schemes will only work with selected
EAP methods (EAP TLS, PEAP, EAP TTLS, etc.), because in some EAP methods
(EAP SIM), it is not possible to export the Master Key and plug it into a
PRF other than that for which the protocol was designed.

To make the schemes more general, it is necessary for them to use a
quantity that is exported by all EAP Methods -- namely the MSK.

However, in examining the MSK it becomes clear that only MSK(64,127) could
qualify for such usage. MSK(128,192) may be a known quantity, so this
won't do.

MSK(0,63) also won't work, because the goal is to enable PFS. That means
that the keying material for NAS2 can't depend on the keying material for
the previous NAS. If it does, then if that NAS were compromised, then it
would also compromise the next NAS.

So the only quantity left that would work is MSK(64,127). Some of the
questions this raises are:

a. Is 64B of keying material transported between AAA server and
NAS *always* sufficient?

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

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