Subject: [eap] Re: Issue 113: Rewrite of Security Considerations Section

From: [email-masked] ([email-masked])
Date: Mon, 28 Apr 2003 21:17:30 +0300

Hi,

In a message earlier today, I commented that the cryptographic
separation of MK and MSK might be unnecessarily restrictive in
some cases.

It seems that the requirement that TEKs are cryptographically
separate from TSKs (and thus cryptographically separate from
MSK) is also be too restrictive, and actually might prohibit
certain types of completely sound EAP methods (e.g. DLC-based
key transport from NIST 800-56 draft).

Thus, I'm beginning to feel that we should avoid discussion of
how the keys are derived in this document (especially when that
discussion contains MUSTs or MUST NOTs). Also, there is some
duplication between section 7.10 and 7.13, so I decided to try
to rephrase it. Here's a proposed replacement for section 7.10:

"7.10 Key derivation

It is possible for the peer and EAP server to mutually
authenticate, and derive keys. In order to provide keying
material for use in a subsequently negotiated ciphersuite, an
EAP method supporting key derivation MUST export a 64 octet
Master Session Key (MSK), and a 64 octet Extended Master Session
Key (EMSK), and MAY export a 64 octet Initialization Vector
(IV).

MSK, EMSK, and IVs are not used directly to protect data;
however, they are of sufficient size to enable subsequent
derivation of Transient Session Keys (TSKs) for use with the
selected ciphersuite. Each ciphersuite is responsible for
specifying how to derive the TSKs from the MSK.

EAP methods provide Master Session Keys and not Transient
Session Keys so as to allow EAP methods to be ciphersuite and
media independent. Depending on the lower layer, EAP methods may
run before or after ciphersuite negotiation, so that the
selected ciphersuite may not be known to the EAP method. By
providing keying material usable with any ciphersuite, EAP
methods can used with a wide range of ciphersuites and media.

The EMSK is reserved for future use and MUST remain on the EAP
peer and EAP server where it is derived; it MUST NOT be
transported to, or shared with, additional parties, or used to
derive any other keys. (This restriction will be relaxed in a
future document that specifies how the EMSK can be used.)

This specification does not provide detailed guidance on how EAP
methods are to derive the MSK, EMSK and IV. Key derivation is an
art that is best practiced by professionals; rather than
inventing new key derivation algorithms, reuse of existing
algorithms such as those specified in IKE [RFC2409], or TLS
[RFC2246] is recommended."

(I also added more restrictive text about EMSK; the previous
version could be read to allow any use except as-is
transportation to third parties)

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 28 Apr 2003 13:38:06 -0700 (PDT)

> separation of MK and MSK might be unnecessarily restrictive in

Are you saying that there is no problem if possession of the MSK allows
the recovery of the MK by methods more efficient than brute force?
Since the MK is the residual of a successful authentication, if fast
resume or fast handoff is supported, then once obtained, the MK allows
an attacker to impersonate the EAP peer in attaching to another NAS. So
the compromise of the MK has considerable impact. If one can get from
the MSK to the MK, then any NAS (or a proxy for that matter) that has
access to any MSK could potentially impersonate the EAP peer and gain
access elsewhere. That seems undesirable.

> key transport from NIST 800-56 draft).

Are you saying that based on capture the EAP conversation, it should be
possible to recover the transient session keys used to protect data by
methods more efficient than brute force? The TSKs are only used for a
particular session at a particular NAS, so their compromise isn't as
serious as compromise of the MKs. However, if one can go from the TSKs to
the TEKs, then the next step would be compromise the MK. So it still seems
to me that you'd want these quantities to be cryptographically separate.

> discussion contains MUSTs or MUST NOTs).

I think there are two issues here -- one is whether some of the material
in Section 7 belongs elsewhere (such as the Key Framework document).
Another issue is whether it belongs anywhere.

In terms of deciding what material belongs in at least one document,
the Security ADs have prepared a list of requirements that
EAP/AAA documents must satisfy in order to survive IESG review:

http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt

On slide 5, there are two requirements that appear relevant to the issue
of cryptographic separation:

2. "Maintain confidentiality of session keys"

3. "Compromise of a single NAS cannot compromise any other part of the
system, including session keys and long term keys"

I interpret #2 to relate to key wrap as well as to the ability to recover
session keys based on passive eavesdropping or active attacks such as
offline dictionary attack.

My interpretation of #3 is that this is mandating PFS between NASes, as
well as inability to recover other keys based on compromise of the MSK.

We could of course leave much of this discussion to the Key Framework
document, but then it would be hard to argue that it should be
Informational, since it would contain requirements that were not present
in RFC 2284bis, that are needed to meet the security guidelines.

>I've added language about the EMSK...

This looks pretty good.

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 28 Apr 2003 22:34:59 -0700 (PDT)

> separation of MK and MSK might be unnecessarily restrictive in

You're right. The definition of "cryptographic separation" we're using
requires that that the MSK not be derivable from the MK, as well as the
other way around. This *is* too strict. All we really need is that the MK
not be derivable from the MSK. Perhaps we need another term for
this?

> MSK) is also be too restrictive

The TSKs are *not* cryptographically separate from the MSK typically,
since the TSKs are derived from the MSK. However, the TEKs and TSKs are on
separate branches of the key hierarchy, so I think they *do* meet the
definition of cryptographic separation. Is that right??