Subject: [eap] Proposed Resolution to Issue 169: Review of KEYFRAME-07

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Oct 2003 17:25:01 -0700 (PDT)

The text of Issue 169 is enclosed below.  The proposed fixes are as
follows:

The proposed fixes are as follows:

In Section 1.2, change:

"In other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x, but the work an
adversary must do to perform this computation is equivalent to
performing exhaustive search for the secret state value."

To:

"In other words, if the keys are cryptographically separate, there is
no shortcut to compute x from y or y from x."

In Section 1.3, change:

"While EAP methods may be based on key management protocols, EAP itself
is not a key management protocol. Thus, while EAP may provide for
mutual authentication and derivation of keying material, it does not
provide for the derivation or naming of transient session keys, the
selection of traffic modes such as transport or tunnel mode, the secure
negotiation of capabilities such as ciphersuites or filters, or support
for key activation. As a result, where EAP is used for key derivation,
a secure association protocol (phase 2) should be provided, supporting
the creation and deletion of unicast (phase 2a) and multicast (phase 2b)
security associations used for the protection of data."

To:

"While EAP methods may mutually authenticate and derive keys, EAP
does not provide for the derivation or naming of transient session keys,
the selection of traffic modes such as transport or tunnel mode, the
secure negotiation of capabilities such as ciphersuites or filters, or
support for key activation. As a result, where EAP is used for key
derivation, a secure association protocol (phase 2) should be provided,
supporting the creation and deletion of unicast (phase 2a) and multicast
(phase 2b) security associations used for the protection of data."

In Section 1.3.3, change:

"[4] Mutual proof of possession of the keying material generated during
EAP authentication (phase 1). By requiring a mutual proof of
possession of the AAA-Key, the secure association protocol
demonstrates that both the EAP peer and authenticator have been
authenticated and authorized by the AAA server. Note that mutual
proof of possession is not the same thing as mutual authentication.
For example, as a result of a secure association protocol exchange,
the EAP peer may not be able to confirm the identity of the
authenticator."

To:

"[4] Mutual proof of possession of the AAA-Key. This
demonstrates that both the EAP peer and authenticator have been
authenticated and authorized by the AAA server. Since mutual
proof of possession is not the same as mutual authentication,
the EAP peer cannot verify authenticator assertions (including
the authenticator identity) as a result of this exchange."

In Section 2.2, change:

"Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the EAP client
and server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716] it cannot be used in computation of any quantity that
needs to remain secret, and is not used with any known ciphersuite.
As a result, its use has been deprecated and EAP methods are not
required to generate it."

To:

"Initialization Vector (IV)
A quantity of at least 64 octets, suitable for use in an
initialization vector field, that is derived between the EAP client
and server. Since the IV is a known value in methods such as EAP-
TLS [RFC2716] it cannot be used by itself for computation of any
quantity that needs to remain secret. As a result, its use has
been deprecated and EAP methods are not required to generate it."

In Section 3.3, change:

"A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA. Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA. However, the failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) is grounds for removal of a
AAA-Key SA by both parties."

To:

"A unicast secure association SA (phase 2a) may not persist longer than
the maximum lifetime of its parent AAA-Key SA (if known). However, the
deletion of a parent EAP or AAA-Key SA does not necessarily imply
deletion of the corresponding unicast secure association SA. Similarly,
the deletion of a unicast secure association protocol SA does not imply
the deletion of the parent AAA-key SA or EAP SA. Failure
to mutually prove possession of the AAA-Key during the unicast secure
association protocol exchange (phase 2a) need not be grounds for removal
of a AAA-Key SA by both parties; rate-limiting unicast secure association
exchanges should suffice to prevent a brute force attack."

In Section 3.3, change:

"820.11" to "802.11"

In Section 3.4, change:

"Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA. However, the failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) is grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs."

To:

"Similarly, the deletion of a multicast secure association protocol SA
does not imply the deletion of the parent EAP, AAA-Key or unicast secure
association SA. Failure to mutually prove possession of
the AAA-Key during the unicast secure association protocol exchange
(phase 2a) need not be grounds for removal of the AAA-Key, unicast secure
association and multicast secure association SAs;
rate-limiting unicast secure association
exchanges should suffice to prevent a brute force attack."

In Section 3.5, change:

"In order to securely bind the EAP security association (phase 1) to its
child phase 2 security association, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the EAP (phase 1) keying material derived during the EAP
exchange (phase 1). In order to avoid confusion in the case where an
EAP peer has more than one EAP security association (phase 1) applicable
to establishment of a given phase 2 security association, the secure
association protocol (phase 2) supports key naming so that the
appropriate phase 1 keying material can be utilized by both parties in
the secure association protocol exchange."

To:

"In order to securely bind the AAA-Key security association (phase 1b) to
its child phase 2 security associations, the phase 2 secure association
protocol allows the EAP peer and authenticator to mutually prove
possession of the AAA-Key. In order to avoid confusion in the case where
an EAP peer has more than one AAA-Key (phase 1b) applicable
to establishment of a phase 2 security association, it is necessary
for the secure association protocol (phase 2) to support key selection,
so that the appropriate phase 1b keying material can be utilized by
both parties in the secure association protocol exchange."

In Section 6.2, change:

"Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the MSK may
be recovered by an attacker in control of the untrusted intermediary.
Possession of the MSK enables decryption of data traffic sent between
the peer and a specific authenticator; however where Perfect Forward
Secrecy (PFS) is implemented, compromise of the MSK does enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
redirect functionality, as provided in [DiamBASE]."

To:

"Where an untrusted AAA intermediary is present (such as a RADIUS proxy
or a Diameter agent), and data object security is not used, the AAA-Key
may be recovered by an attacker in control of the untrusted intermediary.
Possession of the AAA-Key enables decryption of data traffic sent between
the peer and a specific authenticator; however where key separation
is implemented, compromise of the AAA-Key does not enable an
attacker to impersonate the peer to another authenticator, since that
requires possession of the MK or EMSK, which are not transported by the
AAA protocol. This vulnerability may be mitigated by implementation of
redirect functionality, as provided in [DiamBASE]."

In Section 6.3, change:

"In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and authenticator can prove that they
have participated in the entire EAP exchange."

To:

"In order to prevent these attacks, [MiTM] recommends derivation of a
compound key by which the EAP peer and server can prove that they
have participated in the entire EAP exchange."

Add Section 6.5:

"6.5 Denial of Service Attacks

The caching of security associations may result in vulnerability to
denial of service attacks. Since an EAP peer may derive multiple
EAP SAs with a given EAP server, and creation of a new EAP SA does
not implicitly delete a previous EAP SA, EAP methods that result in
creation of persistant state may be vulnerable to denial of
service attacks by a rogue EAP peer.

As a result, EAP methods creating persistent state may wish to
limit the number of cached EAP SAs (Phase 1a) corresponding to an EAP
peer. For example, an EAP server may choose to only retain
a few EAP SAs for each peer. This prevents a rogue peer from
denying access to other peers.

Similarly, an authenticator may have multiple AAA-Key SAs
corresponding to a given EAP peer; to conserve resources an
authenticator may choose to limit the number of cached
AAA-Key (Phase 1 b) SAs for each peer.

Depending on the media, creation of a new unicast secure
association SA may or may not imply deletion of a previous
unicast secure association SA. Where there is no implied
deletion, the authenticator may choose to limit
Phase 2 (unicast and multicast) secure association SAs
for each peer."

-----------------------------------------------------------------
Issue 169: Review of Key Framework-07
Submitter name: Dan Simon
Submitter email address: [email-masked]
Date first submitted: 8/24/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-August/001615.html
Document: Key-07
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
p. 7, 1st para.:

"exhaustive search" is not the best terminology, since some algorithms
(notably number-theoretic ones) are attackable by means other than
brute force. "Breaking a cryptographic assumption", which you use
earlier in the paragraph, is a better phrasing.

p. 8, last para.:

"Key management" is often used as a synonym for "key distribution",
so the question of whether EAP itself is a key management protocol
should be thought of primarily in terms of whether it's EAP or
individual EAP methods that handle key distribution (i.e., key exchange).
I'll leave it to you to decide which way you like to think of it.

p. 13, first para.:

the IV must not be used by itself in computation of any quantity that
needs to remain secret. Obviously, it can be used in combination
with secret keys to derive other secret keys.

p. 21, 1st para.:

removing an SA based on a (single) failed authentication suggests an
easy targeted DoS attack (although, granted, a strictly local one, and
hence not that much of a concern). In any event, rate-limiting
authentication attempts should suffice, especially when strong keys
are being used.

p. 21, 3rd para.: You mean 802.11, not 820.11, right?

p. 22, 4th para.: See comment on p. 21, 1st para., above.

p. 24, last para.: I don't think you mean "perfect forward secrecy"
here so much as "key separation". None of the keys are being
"rolled forward" over time; rather, the MSK is being kept
cryptographically separated from the keys needed to impersonate
the backend server or peer.

p. 25, 2nd last para.: "between the peer and server",
not "between the peer and authenticator". (Right?)

p. 29, "Cryptographic separation": see first comment, on p. 7, above.

p. 30, "Key Strength" and "Freshness": I have no fundamental objection to
the 128-bit requirement, but I also would have no objection if it were
weakened somewhat (e.g., to 96 bits), and I wouldn't want to see an
otherwise reasonable future EAP method proposal get shot down over key-length
paranoia. On the other hand, if you're confident that this won't be a problem (i.e.,
that nobody will ever have trouble meeting the 128-bit requirement within
their method), I'll accept your judgment.

General: I was wondering if it might be a good idea to have a "DoS attack"
section in the security considerations section, spelling out what makes a
DoS attack worthy or unworthy of concern. One thought that came to mind
as I was reading the doc, for instance: you mention a peer having multiple
SAs with the same authenticator--might that allow a client to start
establishing SAs with the authenticator (e.g., an AP) until the latter "blows up" or
maxes out, then move on to the next authenticator and do the same? Again, if it
only disables the authenticator while the client is around, then the
attack could be dismissed as "microwave-oven-equivalent"--but could the request
for multiple SAs conceivably cause the authenticator to freeze up for a longer
period while it holds huge amounts of SA state for the single client,
waiting for it to return?

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap