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

From: [email-masked] ([email-masked])
Date: Tue, 29 Apr 2003 11:08:38 +0300

Hi,

See comments inline.

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 11:38 PM
> To: Eronen Pasi (NRC/Helsinki)
> Cc: [email-masked]
> Subject: Re: Issue 113: Rewrite of Security Considerations Section
>=20
>=20
> > In a message earlier today, I commented that the cryptographic
> > separation of MK and MSK might be unnecessarily restrictive in
> > some cases.
>=20
> 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.

MK is currently defined to be internal to a method, so the
method knows exactly what it is used for. If the compromise of
MK doesn't allow anything worse than compromise of MSK, then it
doesn't matter if MSK would help in recovering MK.

If the method uses MK for fast resume (again, something internal
to a method), it knows this, and then it has to ensure that MSK
does't help in recoving MK.  If we change that so that the MK
can be exported by the method to some unforeseen use (e.g. to
some "fast handoff" protocol), then it becomes necessary for all
methods to do this.

However, this is probably a very bad idea, since this would make
the derivation of "fast handoff keys" from MK method-specific
(something that we would like to avoid; these keys should
probably be derived from EMSK).

> > 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).
>=20
> 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.

No, of course not :) I intended to say that in some perfectly good
protocols, knowing TEKs allows you to recover the MSK (and thus
TSKs). Naturally, then it must not be possible to recover TEKs
from the EAP conversation (more efficiently than brute force).

> > 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).
>=20
> 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.
>=20
> 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:
>=20
> http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt
>=20
> On slide 5, there are two requirements that appear relevant to
> the issue of cryptographic separation:
>=20
> 2. "Maintain confidentiality of session keys"
>=20
> 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.
>=20
> 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.

The requirements in AAA-Key-Mgmt.ppt are good. I'm just thinking
that those requirements could be met by an EAP method that is
internally completely different than EAP-TLS or the model
presented in Key Framework.

What we should specify is what the "method black box" looks to
outside, and speaking of that, there's one very important
requirement we've forgotten so far. Proposed text (after
reference to IKE and TLS):

  "Non-overlapping substrings of MSK MUST be cryptographically
  separate from each other. This is required because some
  existing ciphersuites form TSKs by simply splitting the MSK to
  pieces of appropriate length. Likewise, non-overlapping
  substrings of EMSK MUST be cryptographically separate from
  each other, and from substrings of MSK."

(This forbids expanding a short key to a longer MSK by simply
repeating the original key, or padding it with zeroes).

Another issue related to this: Should we say something more
about IVs? For instance, CBC mode encryption requires that IVs
are unpredictable (but e.g. the IVs exported by EAP-TLS are
not). Or maybe we shouldn't mention them at all, since
it seems that no ciphersuites actually use them?

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 29 Apr 2003 05:35:51 -0700 (PDT)

> doesn't help in recoving MK.

Correct. Perhaps this is expressed in a requirement that knowing one MSK
cannot make it easier to recover another one more efficiently than brute
force? This is the problem that is observable.

> probably be derived from EMSK).

Yes. It would also require that the *all* EAP methods export the MK, which
quite a few methods (SIM, TLS-derived methods, Kerberos, etc.) cannot do.

> from the EAP conversation (more efficiently than brute force).

Hmm. Isn't recovery of  the TEKs a function of the ciphersuite negotiated
within the EAP method? For example in EAP TLS, if RC4 is negotiated, then
presumably recovery of the TEKs is easier than if say, AES had been
negotiated instead.

> presented in Key Framework.

Sure. The question is what requirements we impose on the EAP method so
that the "black box" outputs are guaranteed to meet requirements. Ideally we
should not be ruling out good methods in the process.

> repeating the original key, or padding it with zeroes).

Yes. This is a good requirement. Will add.

> it seems that no ciphersuites actually use them?

The EAP TLS IV derivation is taken from the TLS key hierarchy, which uses
them with ciphersuites such as 3DES CBC mode. While the IVs are not a
secret (this resulted from now-defunct export rules) they are based on the
client and server nonces so they are live.