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

From: [email-masked] (John Vollbrecht)
Date: Fri, 02 May 2003 11:45:16 -0400

This is very interesting, but probably out of scope for current EAP 
charter.  However, I have a couple comments below.

--On Monday, April 28, 2003 9:43 AM +0300 Jari Arkko <[email-masked]> 
wrote:

> Dror Caspi wrote:
> > 802.1aa/D5 (section 6.7) talks about this issue, but unless I
> > misunderstood some of the text it is still problematic.
> >
> > - The suggested method in the text for peers (e.g., two bridges) is to
> > play both Authenticatior and Supplicant.  Such systems should be
> >   prepared for role reversal.
> > - However the text clearly notes that from the two one-way
> > authentication exchanges in each direction are not equivalent to a
> >   single mutual authentication exchange.
>
> Right. One mutual auth is good enough, however, in theory. But there
> may still be protocol problems (see 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.
> >
This is being modified to indicate that the Supplicant will go to 
"Unauthenticated" state and its link should not go active.

> > 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.
>
> Yes.
>
> > However I am not sure that the above is still within the standard -
> > i.e., if we implement this (say as a proprietary EAP method) it would
> > still fit within the 802.1aa/D5 and RFC2284bis framework.
>

I am a bit confused as to what the proprietary EAP method would do.  One 
side or the other would have to send the Request, so that side would be the 
initiator.  The other side could NAK if it wanted to be initiator and 
propose something else.  Possibly they could agree on a method that allows 
one or the other to "drive" within the method.  Still, in EAP one or the 
other end is the initiator.  To change which is the initiator it would seem 
the choice must be made at the lower layer.  In PPP either side can request 
the other authenticate and use EAP.  It is then the initiator.  In 802.1X 
it is hard wired for now.

> This would be easier to determine if we had details available on exactly
> how the two peers go about doing the mutual authentication.
>
> As I see it, there are two fundamental issues:
>
>   - Who acts as the initiator (FCFS, highest
> identity/addrs/nonce/whatever,     ...)
>
>   - How to identify the initiator. As a responder, I can send my identity
>     in the Identity Response, but what if we are running a shared secret
>     method and I have different shared secrets for you and someone else?
>     I would need to know your identity before I can proceed with the
>     execution of the method. I don't know of a way how to do this in
>     EAP. OTOH, this is a similar issue as exists in the case of
>     multiple providers and credentials even in e.g. regular WLAN access
>     from a client, which I believe is solved with information from the
>     link layer (SSID).
>
Is knowing identity required to decide who is initiator?  It seems to me 
that once one know who is the initiator then one can take steps to find 
identity.

> Secondly, I see two approaches to solving these issues. One, we could
> do it at the EAP level. Two, we could do it at the link-layer level.
> For instance, the initiator could be chosen to be the peer with the
> smallest MAC address, and if the link-layer identity and other published
> information suffices to identify the initiator, I believe 2284bis would
> work fine in this case. But you wouldn't see this at the EAP layer;
> all the decisions take place at the link layer and then magically
> the EAP protocol is run in one direction between the two parties.
>
I think that perhaps a more aggressive method negotiating sequence could 
also solve this.  If the two parties agree on a "mutual" method, then it 
seems this could work.  With an appropriate method both are satisfied with 
the other's authentication.  Each side then goes to an authenticated state.

In 802.1aa this does work. The authenticator (initiator) sets the 
controlled port ON, and the peer goes to the Authenticated State.  The link 
won't work unless both sides have succeeded.

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