Subject: [eap] RE: Request for feedback

From: [email-masked] (Walker, Jesse)
Date: Mon, 6 Jan 2003 07:49:24 -0800

Bernard,

Here is a response to your request for feedback on draft rfs2284bis rev 8.

Major Issues: Page 5 includes the text:

	7.	Since EAP is a Peer-to-Peer protocol, after
	authentication in one direction is complete, the direction
	of authentication MAY reverse, with the endpoint
	previously serving as the Authenticator assuming the Peer
	role, and the former Peer now taking on the Authenticator
	role. As with the original conversation, the reversal is
	signaled by the (new) Authenticator sending a Request.
	Support for bi-directional authentication requires that
	each endpoint implement both the Peer and Authenticator
	roles.

and page 31 continues in this theme with

	In EAP there is no requirement that authentication be full
	duplex or that the same protocol be used in both
	directions. It is perfectly acceptable for different
	protocols to be used in each direction. This will, of
	course, depend on the specific protocols negotiated.
	However, in general, completing a single, mutual
	authentication is preferable to two one-way
	authentications, one in each direction.

These two texts appear to have been written under the misapprehension that
two unrelated unilateral authentications glued together in arbitrary
undefined ways can result in multual authentication. It does not and cannot;
in general the two unilateral authentications remain simply unilateral
authentications. It is in general not feasible to defeat man-in-the-middle
attacks--and hence in general it is not feasible to rely on the unilateral
authentication for any useful assertion--without relating the two
cryptographically in very specific ways. Allowing reversal of roles is a
recipe for disaster unless very great care is taken to relate the two
authentications, and there is no evidence such a task is even feasible for
all but a few legacy unilateral authentication mechanisms. We have already
seen a variant of this problem with PEAP and TTLS, both of which are much
stronger than the construction this text seems to sanction.

To correct this problems, I suggest adding text at the end of that cited on
page 5 such as "In environments where man-in-the-middle attacks are
possible, at least one of the two concrete Authentications MUST rely on an
algorithm that performs a mutual authentication. This obviates the need for
reversing the roles of Authenticator and Peer." To the end of the text cited
from page 31, as text something like "This is because using separate
authentications that are not bound cryptographically to demonstrate they are
part of the same session are always subject to man-in-the-middle attacks."
Or better yet, explicitly ban role reversal of the kind indicated here. That
is simpler, and simplicity almost always leads to better security.

Page 6: There is a sentence that begins

	Unless protected by an underlying link layer ciphersuite

In the case where the Authentication Server is not the Authenticator, this
suffers from a similar problem. Relying on a link layer ciphersuite between
the Authenticator and the Peer to protect messages between the
Authentication Server and the Peer is subject to man-in-the-middle abuses;
if the protections are not applied end-to-end, then they cannot necessarily
be effective. I think what is really intended is that the EAP messages be
protected by a ciphersuite associated with the concrete authentication
method, and the text should be updated to reflect this.

Minor Issues:

Pages 1 (Abstract), 3 (Introduction): The text still speaks of EAP as an
"authentication protocol". It is not since in and of itself it performs no
authentication. How about "authentication protocol transport"?

Page 3: In the defintion of "Silently Discard, a sentence begins:

	The implementation SHOULD provide the capability of logging
	the error

There is an implicit assumption in this sentence that silently discard
occurs only in response to an error. This should be made explicit or else
the assumption removed.

Page 6: "Protected success/failure" is never defined.

Page 6: There is a sentence which says:

	Where a protected success/failure indication has been
	received at the EAP layer by an EAP Peer, it MUST accept
	and process the protected indication.

This is a vacuous requirement, because there is no definition of what it
means to "process" the "protected indication". At the very least this should
indicate that "to process" means something like (a) apply all the
protections of whatever ciphersuite that one believes to have been applied
to the message to (b) extract a success/failure message, which is then
handled according to the normal rules for EAP success/failure messages, and
(c) received EAP success/failure messages that arrive unprotected are
silently discarded if protection is expected.

Page 16: The phrase "and and" appears.

Pages 20, 21, and 22 use the phrase "IEEE 802" as a synonym for "IEEE 802
wired networks" Please clean this up.

Page 23 has the language "application specific" which is not wrong per se
but does appear to be misleading. Can we replace this with "vendor
specific", since that is what the text is talking about?

Page 32 Clause 7.11 says that

	This specification does not provide guidance on how EAP
	methods are to derive keys.

I think it is possible to give some general but practical guidelines:

a. the key MUST be a fresh, never-before used key, because otherwise it is
in general infeasible to use the key to detect messages replayed from prior
sessions.

b. there MUST be some way to name the key, to determine whether it belongs
to this or to some other session.

c. the key is an authorization token (use of the key demonstrates
authorization to access the channel), so the relation of the key to the
authentication that authorized this key MUST be made explicit to understand
the security relationship of the key to the EAP method.

d. in the case where more than authentication method is used (think of PEAP
or TTLS, not the approach complained about on page 5 and 31) and more than
one method derives keys, then the method description MUST indicate which
keys are distributed for use by the Authenticator and Peer, and how. For
instance, in the PEAP/TTLS case, the key derived by the inner method could
be combined using a pseudo-random function with the TLS key to
cryptographically bind the inner and outer keys, and this combined key would
be used by the Authenticator and Peer.

I would also like to see the following two additional guidelines, but they
may be more controversial, so I will not insist:

e. When the purpose of the authentication is to authorize use of the data
link channel between the Peer and the Authenticator, to understand its
security one needs to know how the derived key is bound to the channel, so
that (ab)use of it in other contexts can be detected. It would be nice if
the method could (SHOULD?) provide guidance on this issue, e.g., specify the
assumptions it makes about how this binding occurs.

f. When the Authenticator and Authentication Server are not the same party,
one needs to understand how the key is distributed to the Authenticator (and
to the Peer, if it needs to be transported) to understand the security
properties of the key. It would be nice if the method could (SHOULD?)
provide guidance about this, e.g., specify the assumptions it makes about
how key distribution is effected.

-- Jesse

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Saturday, December 21, 2002 11:18 AM
> To: Walker, Jesse
> Subject: Request for feedback
> 
> 
> Since  you will be taking a vacation during the holidays, may I
> suggest that you consider reading and commenting on an EAP WG 
> draft during
> your downtime.
> 
> EAP WG drafts make excellent reading material, particularly before bed
> time, taken with spiced egg nog. For your consideration, I 
> would like to
> recommend the following drafts:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284b
is-08.txt
http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-05.txt
(Keying framework -05 strawman)

As usual, Issues should be sent to the EAP WG mailing list using the
format described at:

http://www.drizzle.com/~aboba/EAP/eapissues.html

---

From: [email-masked] (James Carlson)
Date: Mon, 6 Jan 2003 11:25:51 -0500

> undefined ways can result in multual authentication. It does not and cannot;

Agreed.

> possible, at least one of the two concrete Authentications MUST rely on an

s/MUST/SHOULD/ -- there's no way to *require* that the peer somehow
implement authentication mechanisms that it doesn't.  An
implementation that chooses to proceed without such a method available
does so at its own risk.  (And various implementation-dependent
mechanisms might be appropriate -- a configuration flag allowing such
use, an interactive dialog authorizing the use, a set of reduced
capabilities under such a regime, et cetera.)

> is simpler, and simplicity almost always leads to better security.

I don't think that can be done explicitly.  EAP also runs on PPP, and
PPP's LCP allows independent negotiation of the authentication
protocol to be used in each direction on a link.  What you could do
would be to include more 'security considerations' advice that
indicates why use of a mutual authentication protocol should be
preferred over simultaneous authentication.  (The obvious cart-before-
horse problem: at Establish [LCP] time, there's no way to know what
EAP methods are known to the peer.  At Authentication [EAP] time,
you're already committed to the direction[s] of authentication.)

I suppose we could propose extending the LCP option for PPP to list
the algorithms [Type numbers] supported so that the peer can tell what
it might be able to do.  That seems slightly radical to me, though,
since it admits a problem with EAP's original design goals.

> to this or to some other session.

Isn't that really just an issue for media where reliable disconnection
indication isn't possible?

> how key distribution is effected.

I'd think that's an issue for documents that discuss the protocols
used for authentication servers, such as RADIUS and DIAMETER, and the
EAP methods themselves.  I don't see what value repetition of that
information here would provide.

(Perhaps a separate BCP on writing EAP methods could contain advice
like this ...)

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 6 Jan 2003 08:16:11 -0800 (PST)

Thanks for your feedback, Jesse. I will file this as Issue 57.