Subject: [eap] Issue 169: Review of Key Framework -07

From: Bernard Aboba <[email-masked]>
Date: Sun, 24 Aug 2003 15:05:56 -0700 (PDT)

Submitter name: Dan Simon
Submitter email address: [email-masked]
Date first submitted: 8/24/2003
Reference:
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