Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication

From: [email-masked] (Walker, Jesse)
Date: Wed, 30 Apr 2003 08:49:42 -0700

Bernard,

> EAP was created for use with a peer-to-peer protocol, PPP. 
> Although it is
> initiated by the "authenticator", either PPP peer can play 
> that role, and
> in fact both can do so in two simulataneous conversations.

While this is true, it is irrelevant, because it diverts attention from the
issue. The EAP model is clearly client-server, not peer-to-peer. This is not
wrong or bad; security association establishment protocols (at least the
ones that work :-) seem to be inherently client/server.

> In 802.1X-2001 it was the intent to support this feature of 
> EAP, but that
> was not made clear. The IEEE 802.1aa effort is in the process 
> of adding
> text to make it clear that peer-to-peer operation is 
> supported, and that
> use of a backend authentication server is entirely optional (as it is
> in both EAP and PPP).

My point is that the current peer-to-peer direction does not appear sound or
even properly thought through. It will take a lot of infrastructure outside
of 802.1aa or EAP to make peer-to-peer work, and it will only work when the
concrete EAP method is restricted to methods with very specific properties,
and when the credentials used are restricted in very specific ways. The
currently language in both 2284bis and in 802.1aa fails to reflect any of
these constraints. My suspcion is neither does so because we as a community
still don't comprehend the issues involved. I know I don't, but the
discussion thus far has blithely tiptoed along without any recognition that
this is the middle of a mine field.

Peer-to-peer is harder than client/server because the roles of the
participants are not fixed in advance. This is not a problem in a protocol
like IPsec, because there are separate security associations in each
direction of the conversation, so each can be keyed by an independent
security association establishment. It is a problem when dealing with
constructions like 802.11i, however, because there is only one security
association per link. This forces one to deal with issues that do not fit
comfortably into the client/server model; it forces one to deal with the
problem of which peer gets priority for key assignment and how both
recognize and establish this. This is a cryptographic design problem. The
authentications that might be initiated simultaneously by the peers have to
somehow be related in a way that both sides can trust in the presence of a
malicious adversary, or it will not be possible to reliably establish
agreement on precedence or that there is even a precedence decision.

It is hard enough to get one authentication right let alone two. It is
certainly feasible to glue together separate authentications initiated by
each of two peers, but so far as I can tell how this is accomplished is
still an art dependent on the internals of the specific concrete method. One
can certainly try to abstract this art and make a common recipe for doing so
for authentication methods with certain characteristics, but it is not
plausible that the EAP state machines will remain intact in their present
form. Hence it appears to be a work item that can be deferred until EAP2 (or
whatever it is called this week).

If EAP and 802.1aa continue on their present courses, here are some
constraints I'd suggest: both parties MUST use the same concrete
authentication method with the same credentials for both authentications;
the authentication method MUST exchange random nonces; the authentication
method MUST protect the nonces from modification; each authentication MUST
detect replay and man-in-the-middle attack in BOTH directions; if the two
peers initiate their separate authentications simultaneously, then they MUST
reuse the nonce they supplied for the authentication they initiated in the
authentication to which they are responding; if the peers do not initiate
simultaneously, then the peer that has not initiated should fall back to the
client-server model if it receives an authentication initiated by the peer
(is it the Authenticator or the Supplicant, in 802.1X-speak? I don't know).
More constraints may be needed, and some of these proposed constraints may
not be right, because, like I said, I don't claim I understand the problem,
but if you remove any one of these constraints, then I think it is possible
to construct attacks that can compromise at least an 802.11i protected link.

At this stage of my confusion and attempts to understand, peer-to-peer usage
of EAP appears to me to be as subtle or subtler than tunneled
authentication, and we already know we screwed up in the designs of PEAP and
TTLS. My appeal is for us to try not to screw up yet again. The discussion
thus far has treated the peer-to-peer case as mechanical. I hope that people
agree with me that it is not, and much more toil is required.

-- Jesse

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Apr 2003 09:58:11 -0700 (PDT)

> ones that work :-) seem to be inherently client/server.

What makes EAP "inherently client-server"? There are a few things about
the protocol that are asymmetric, such as retransmission behavior (handled
by the authenticator), and the sending of Success/Failure (the
authenticator sends this to the peer). However, with  the recent decisions
to only allow a single EAP authentication method per conversation, the
Success/Failure packets can be viewed as largely vestigial within a
mutually authenticating method, and the latest draft of IEEE 802.1aa
includes the notion of "controlled/uncontrolled ports" on both the
supplicant and authenticator.

While many of the original EAP methods are client-server protocols (e.g.
TLS), we have examples of peer-to-peer authentication technologies being
proposed for use with EAP. An example is EAP-IKE. IKE is a peer-to-peer
protocol (no distinction made between Initiator and Responder with respect
to say, authentication modes or certificate usage) -- yet it is being
proposed to encapsulate this within EAP, without requiring any changes
to EAP.

> even properly thought through.

I think we need to make a distinction between peer-to-peer usage as
envisaged in RFC 2284 and IEEE 802.1aa, and the "adhoc" or "mesh
networking" scenarios being contemplated in IEEE 802.11.

The "adhoc" or "mesh networking" scenarios in IEEE 802.11 are indeed
considerably more complex. In garden variety peer-to-peer between say,
two Bridges on a wired network, the Bridges are stationary and
typically within the same administrative domain. In that situation
there are certainly credential provisioning issues, but given some
"tie breaker" functionality, an appropriate EAP method
supporting peer-to-peer authentication, and sufficient intestinal
fortitude on the part of administrators, it can be made to work.

However, in the "adhoc" or "mesh networking" scenarios contemplated in
IEEE 802.11, we have mobile stations that can potentially be continually
bringing up and tearing down security associations where there is no
inherent trust model. Just as using OSPF for mesh network routing isn't
advisable in these situations, without some care it is likely that
stations will be unable to authenticate at all, or if they can, will spend
much of their time authenticating and very little time communicating.
However, I'm not clear to what extent use of EAP makes this problem worse.

I'd also note that IEEE 802.11i is running two authentications, one in
each direction, deriving two sets of keys, and *then* running a
tie-breaker. This seems wasteful, particularly when we are talking
about providing keying material for a ciphersuite that uses the same keys
in both directions.

> It will take a lot of infrastructure outside
> of 802.1aa or EAP to make peer-to-peer work

If by peer-to-peer you mean "IEEE 802.11 ahoc or mesh networking", I would
agree. However, the senarios contemplated in IEEE 802.1aa are considerably
simpler than this.

> My suspcion is neither does so because we as a community

Since mesh network security is an active research area, I'd agree that
this is not something that is sufficiently well understood. We could
certainly put in a section that describes some of the issues when
attempting to apply EAP to those problems.

> This is not a problem in a protocol
> security association establishment.

I'm curious as to why IKE can be used for independent security
association establishment, whereas EAP-IKE cannot be. What is it about
the EAP transport that somehow changes the security properties of an
existing protocol?

> association per link.

That seems like an 802.11 problem to me. There are certainly situations
where EAP can be used with more than one security association per link. An
example of this is PPPOE where it is possible to have a single host
bringing up multiple PPP sesssions to different ISPs, all operating over
the same link. Where EAP is used for authentication and key management, it
is possible to use PPPOE today to bring up multiple security associations
per link. So this isn't an EAP issue -- it's a link layer issue.

> It is hard enough to get one authentication right let alone two.

I would agree that the decision of IEEE 802.11i to do two authentications
*then* do election seems odd. But I'm not sure why this decision was
forced by the use of EAP.

In general, I'd observe that in situations where problem requirements are
poorly understood it is best to gain clarity *before* introducing
potential solutions. There are quite a few situations where conventional
EAP methods will not work well, but that's different from saying that
*some* EAP method cannot be made to work.

> Hence it appears to be a work item that can be deferred until EAP2 (or

Since this problem is neither caused by, or solved by EAP, creating a new
protocol is unlikely to add either to the clarity of the problem
statement, or to the value of a solution.

> authentication method with the same credentials for both authentications;

Why? RFC 2284 explicitly states that this is *not* a constraint.

> the authentication method MUST exchange random nonces;

For a mutually authenticating method this is sound advice and we should
add this. For a one-way method, it doesn't seem necessary though.

> the authentication method MUST protect the nonces from modification;

Seems reasonable.

> each authentication MUST detect replay and man-in-the-middle attack in
> BOTH directions;

Seems reasonable.

> if the two
> authentication to which they are responding;

Since we're already saying that two separate authentications is not
equivalent to one mutual one, I'm not sure why we should try to mandate
that they be interlinked. If the intent is to do something like this, why
do  two separate authentications in the first place, why not just do a
single mutual auth?

> if the peers do not initiate

It seems reasonable to suggest some sort of tie breaking behavior in the
case where a single mutually authenticating conversation is desired.

> to construct attacks that can compromise at least an 802.11i protected link.

Such an attack, if feasible, would derive from allowing two
non-interlinked authentications, one in each direction. This isn't an EAP
problem per say -- though we can certainly insert additional language
advising against this.

> The discussion

I would certainly agree that IEEE 802.11 "adhoc" or "mesh networking"
requires more thought. But few of the issues you've brought up so far
apply to the simple Bridge-Bridge cases discussed in IEEE 802.1aa.