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

From: [email-masked] (Dror Caspi)
Date: Sun, 27 Apr 2003 19:14:12 +0300

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

---

From: [email-masked] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Mon, 28 Apr 2003 00:22:02 -0400

We did attempt to put some words in 802.1aa/D4 around this topic.  I'm not
sure they were exactly what was needed, so there maybe some slight
re-wording in 802.1aa/D5 when it comes out this week.  Have a look and see
if your issue is  still not properly addressed.

Paul

-----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 
Documents: RFC2284bis, draft-jwalker-eap-archie-00.txt, IEEE-802.1aa Comment
type: Technical
 
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] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Sun, 27 Apr 2003 23:47:04 -0700

The current draft under development (not yet published) suggests making a
change to the item below

>- The text also notes that EAP methods that perform mutual authentication
can be
>   used - and that the Supplicant action at the end of such exchange is
currently
>   undefined.

It indicates what the supplicant should do, and from my understanding,
802.11i will go a step further and indicate that the supplicant must take
appropriate action.  We haven't gone as far as create a purely symmetrical
802.1X with controlled ports on both sides, as the LinkSec group would
likely want to do, but we have created a portStatus variable on the
Supplicant that can be used for this purpose.  I believe 802.11i will take
advantage of this.

>So based on the above, what I would really like to do is use a single
exchange with a mutual authentication method (e.g., >EAP-Archie).  But then
how do you decide on who plays the Authenticator and who plays the
Supplicant? - both sides are
>equal peers.  One way we thought of was for both peers start as
Authenticator and  do some pseudo-random decision - say
>based on the highest MAC address or highest pseudo-random NONCE value sent
as part of the initial EAP request.
>
>However I am not sure that the above is still within the standard - i.e.,
if we implement this (say as a proprietary EAP>Lmethod) it would still fit
within the 802.1aa/D5 and RFC2284bis framework.

This doesn't sound like it is within what rfc2284bis would support.  EAP is
still very one-sided in who is driving the conversation.

Paul

> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:[email-masked]]
> Sent: Monday, April 28, 2003 7:22 AM
> To: Dror Caspi; [email-masked]
> Cc: Yael Dayan
> Subject: RE: [eap] FW: peer-to-peer mutual authentication
> 
> 
> 
> 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:

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.

Requested change:

---

From: [email-masked] (Dror Caspi)
Date: Wed, 30 Apr 2003 09:32:18 +0300

Hi Jesse,

Thanks for your elaborate answer.  Based on that and other answers we have received so far, we have decided to go with a proprietary solution - which is fine for now since we provide the equipment on both sides.

Hopefully some day there will be a standardized way to do this (maybe as part of the new link security effort).

Dror

> From: Walker, Jesse [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 6:44 PM
> 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
> 
> > [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 
> > 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]
> _______________________________________________
> eap mailing list
> [email-masked]