Subject: [eap] Proposed Resolution to Issue 119 (RFC 2284bis only)

From: Bernard Aboba <[email-masked]>
Date: Tue, 12 Aug 2003 16:04:42 -0700 (PDT)

The text of Issue 119 is enclosed below.

The proposed resolution in terms of RFC 2284bis changes is as follows:

In Section 2, delete:

"Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time.  For a discussion
of security issues in peer-to-peer operation, see Section 7.7."

Add section 2.4:

"2.4 Peer-to-Peer Operation

Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer).  Both peers may act as
authenticators and authenticatees at the same time.

Although EAP supports peer-to-peer operation, selected EAP methods,
AAA protocols and link layers may not support this.  For example,
EAP-TLS [RFC2716] is a client-server protocol requiring a different
certificate profile for the client and server.  This implies that
a host supporting both the EAP-TLS peer and authenticator roles
would need to be provisioned with two distinct certificates, one
appropriate for each role.

Some EAP methods may support asymmetric authentication, with one
type of credential being required for the peer and another type
for the authenticator.  Hosts supporting peer-to-peer operation
with such a method would  need to be provisioned with both
types of credentials.

AAA protocols such as RADIUS/EAP [RFC3579] and
Diameter EAP [DiamEAP] only support "passthrough"
operation on behalf of an authenticator, not a peer.
For example, as noted in [RFC3579] Section 2.6.2,
a RADIUS server responds to an Access-Request
encapsulating an EAP-Request with an Access-Reject.

Link layers such as IEEE 802.11 may only support
uni-directional derivation and transport of transient
session keys.  For example, the group-key handshake defined in
[IEEE802.11i] is uni-directional, since in IEEE 802.11 only
the Access Point (AP) sends multicast traffic.  This means
that in adhoc operation where either peer may send multicast
traffic, two uni-directional group-key exchanges
are required.  Due to constraints imposed by the 4-way
unicast key handshake state machine, this also implies
two 4-way handshake and EAP method exchanges.

Link layers such as IEEE 802.11 adhoc also do not support
"tie breaking" wherein two hosts initiating authentication
with each other will only go forward with a single
authentication.  This implies that even if 802.11 were to
support a bi-directional group-key handshake, then two
authentications, one in each direction, might still occur."

----------------------------------------------------------------------
Issue 119: EAP Inappropriate for use in peer-to-peer
Submitter name: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: April 30, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:

In my opinion (emprical data amply demonstrates that no one has to agree
;-) the EAP framework is inappropriate in general for peer-to-peer
operation.  If you think through the model specified for peer-to-peer
operation, you get into a mire of problems that raise the issue of whether
EAP as constituted today is appropriately matched to the problem.

The first problem requires a solution outside (and way outside at that) of
EAP. Authentication presupposes a notion of a community with a common set
of credentials. It does not make sense to allow anyone to use any
credential in any context, because by definition all members of the
community must be able to somehow recognize one another as being
legitimate members of **THIS** community. In all systems I am aware of
this is accomplished through a common policy to utilize a common set of
credentials. In particular, a community corresponds to some common
credentialing or enrollment function, where each credential identifies its
bearer as a member of the community in some uniform way, and also implies
an access control (membership in the community) that is universally
recognized by all other members of the community. So point number one is
it is not feasible to establish a peer-to-peer network without first
establishing a notion of a network or community, and doing so is not EAP's
problem to solve.

The second problem is a special case of this. There are only three basic
trust models. The first is direct bilateral trust, where two parties
authenticate each other directly and make up a key shared only between
themselves. This model essentially works only in networks of two parties,
so is not a general solution; there is no way to enforce that all members
of a larger group will authenticate and establish their session keys in
exactly the same way. The second model is to rely on an on-line trusted
third party. This is the model used by 802.1X and Kerberos. All members of
the group are enrolled with the on-line trusted third party, and the
on-line trusted third party provides some mechanism for distributing
pairwise keys to any pair of communicating parties within the community.
In the peer-to-peer model one can imagine communities ranging from those
with one such on-line trusted third party (completely centralized
admission control) to those where every group member becomes an on-line
trusted third party (completely distributed admission control). However,
by definition, one and only one on-line trusted third party can mediate
any particular session between two members of the community, because it is
only one session. The third model relies on an off-line trusted third
party. TLS is an example that exploits this model. This model relies on
public/private key technology, as proof-of-possesion of the private key
pair is the ultimate basis for electronic identity. In this
model, since possession of a private key is assumed to establish identity,
the use of such a key by another member can be used to attest to the
membership of another party. This is a model that scales, because the
community member making an attestation need not be within communication
range when the access control decision is being made.

In my mind a general-purpose secure peer-to-peer model would need to
support all three approaches. The impression I get is that people are
thinking almost exclusively of the bilateral case, and they are struggling
to wedge the on-line trusted third party model that EAP is based on to fit
this, and this can't be done elegantly. If this impression is correct (and
I'm not claiming that is is, but rather only that it is my impression),
then the current approach is technically flawed in two dimensions: the
on-line trusted third party model is not the same as the bilateral model
that people are thinking of, and EAP should be expanded to support all
three models instead of just one. Oh, sure, any model can be used to
emulate any other model, but emulation costs MIPs, and my employer is
eternally grateful ("Sell more Pentiums") for each. Emulation abandons
many otherwise fine applications (e.g., the secure wireless lightbulb)
because of cost constraints.

The third problem centers around limitations of the security of data links
like 802.11. In particular, the security associations in this class of
networks use the **SAME** key for both directions of traffic flow between
two peers. This implies that the two peers must somehow agree on what this
key is. This is a much trickier problem than first appears, and EAP's
structure does not help solve it. I've pointed out this problem before: it
is essential to cryptographically relate the two independent
authentications. In particular, a cyrptographically sound authentication
method will establish a notion of a session that can be distinguish
**THIS** session from every other session between the **SAME** peers, so
one can figure out **WHICH** session key to use during **THIS** session.
Temproality of messages by themselves does nothing to establish this.
Indeed, protocols like TLS and AKEP and Archie establish session identity
by exchanging random nonces and mutually authenticating. For instance,
when EAP-TLS is used, clientHello.random and serverHello.random together
with the authentication information identify **THIS** session. But there
is nothing in EAP that can be used to accomplish this function. The EAP
Identifier field is the only possible candidate for the nonce space, but
the size of the Identifier field is way too small to provide anything
meaningful, and there are no native EAP cryptographic protections to
protect this field anyway. Identifying each session requires restricting
the authentication protocol to those that already come with all the
necessary bells and whisteles.

But this is not enough, because, to solve the 802.11 keying problem, one
still has to identify that the sessions established by each direction of
authentication are both extant between the same peers at the same time.
One can imagine, for instance, some sort of meta-EAP protocol that relies
on the larger nonce space when specificly restricted to protocols like
TLS or Archie; one could, for instance, make up rules that say in
peer-to-peer mode, if one receives an authenticate request from a peer to
whom one has an outstanding request, you must use the same nonce that you
have outstanding, etc. But this feels uncomfortably like trying to pound
a round peg into a square hole, and one has to struggle to suppress the
observation that we are really, really reaching here, and that there has
to be a better and easier and cheaper way.

The fourth problem is easy is some cases, if the other problems can be
solved. And that is how to pick out the session key to use. If you **CAN**
identify the two sessions in each direction, and **CAN** authoritatively
establish that both are indeed between the same pair of parties, then any
arbitrary scheme can be used to select one of the two session keys to use
to protect the underlying link, e.g., picking the smaller of two MAC
addresses in the 802 case.

So I am deeply skeptical about extending the current instantiation of EAP
to cover peer-to-peer; the intellectual spadework has not been done, and
the tiny bit I may have contributed in this missive tends to indicate, at
least to me, that EAP does not have the right shape. This strikes me as a
case, as the adage says, everything looks like a nail to someone who only
has a hammer. For whatever it is worth, that's my two cents.

[BA, Responding to Jesse Walker]:

> 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.

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 Bob Moskowitz has submitted a change
to IEEE 802.1aa to include 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-ARCHIE, which is a
peer-to-peer protocol (no distinction made between Initiator and Responder
with respect to say, authentication modes) -- yet it is being proposed to
encapsulate this within EAP, without requiring any changes to EAP.

> My point is that the current peer-to-peer direction does not appear
> sound or 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 scenarios contemplated in IEEE 802.1aa are
considerably simpler than this.

> 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.

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
> 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.

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

> constructions like 802.11i, however, because there is only one security
> 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 sessions 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
> whatever it is called this week).

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.

> 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;

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 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;

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 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

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

> 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.

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 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.

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.

[BA] Here are the proposed fixes for the EAP Keying Framework document.

Add the following requirements to Section 4.1:

Liveness

Methods deriving keys SHOULD exchange random nonces, and
SHOULD protect the nonces from modification.

Man-in-the-middle and replay protection

Methods deriving keys SHOULD detect replay and man-in-the-middle
attacks in either direction.

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

---

From: Jari Arkko <[email-masked]>
Date: Wed, 13 Aug 2003 17:04:22 +0300

Bernard,

Your text looks very good. This should be adequate.

--Jari