Subject: [eap] FW: peer-to-peer mutual authentication

From: [email-masked] (Walker, Jesse)
Date: Tue, 29 Apr 2003 08:43:56 -0700

Hi Dror,

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.

-- Jesse

> -----Original Message-----
> From: Dror Caspi [mailto:[email-masked]]
> Sent: Sunday, April 27, 2003 9:14 AM
> To: [email-masked]
> Cc: Yael Dayan
> Subject: [eap] FW: peer-to-peer mutual authentication
> 
> 
> [I'm resending this message since it seems the original got 
> lost - sorry if any of you got it the second time]
> 
> Description of issue 
> Submitter name: Dror Caspi
> Submitter email address: [email-masked] 
> Date first submitted: April 21, 2003 
> Reference: 
> http://www.drizzle.com/~aboba/EAP/eapissues.html#Issue%2057 
> Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa
> Comment type: Technical
> Priority: '2' May fix
> Section: N/A 
> Rationale/Explanation of issue:
>  
> Having looked at the drafts of RFC2284bis, EAP-Archie and 
> IEEE-802.1aa, it seems that most of the attention is given to 
> systems where there is a distinction between an authenticator 
> and a peer/supplicant.  This distinction still exists even 
> where mutual authentication is proposed (e.g., EAP-Archie).
> 
> But what happens when both parties are peers (e.g., two 
> bridge devices)?  The possibility of role reversal is 
> mentioned (i.e., run a session where one system is 
> Authenticator and the other Peer, and then reverse the role). 
>  However it seems quite cumbersome; a single session of a 
> protocol such as EAP-Archie would seem to provide the 
> required authentication - yet there needs to be a mechanism 
> to (randomly?) decide which party plays which role.
> 
> Probably some of the above is misunderstanding on my part.  
> However there seems to be a need for some explanatory text in 
> the standards, if not for actual changes to accomodate 
> peer-to-peer mutual authentication.
> 
> Requested change: 
> 
> Add explanatory text about peer-to-peer mutual 
> authentication.  Modify the standards if required.
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Alper Yegin)
Date: Tue, 29 Apr 2003 18:23:27 -0700

> already come with all the necessary bells and whisteles.

This can be solved within the EAP transport. For example, we are working on
adding a session-id to the PANA header, which might help with the above
problem.

Alper