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

From: [email-masked] (Subrata Goswami)
Date: Mon, 28 Apr 2003 08:27:14 -0700

If two authenticators connect, neither would send an EAPOL-Start type
message. Also EAPOL messages are outside the EAP framework - correct ?
So EAP need to have a way of its own to determine who would be the
authenticator. 

Also , there is the issue of  is one being the authenticator the same as
the other being the authenticator ?  This assumption of equality of
authenticators is not correct as the authentication mechanism that can
be used is different.

Subrata

> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:[email-masked]] 
> Sent: Monday, April 28, 2003 8:14 AM
> To: 'Subrata Goswami'; [email-masked]
> Subject: RE: [eap] FW: peer-to-peer mutual authentication
> 
> 
> 
> If the underlying link layer is 802.1X, then it is pretty 
> clear who is supplicant and who is authenticator since the 
> supplicant sends EAPOL-Start messages.  If someone who is 
> interested in playing either role receives an EAPOL-Start, it 
> may play the role of authenticator.  
> 
> Paul
> 
> -----Original Message-----
> From: Subrata Goswami [mailto:[email-masked]] 
> Sent: Monday, April 28, 2003 7:41 AM
> To: [email-masked]
> Subject: RE: [eap] FW: peer-to-peer mutual authentication
> 
> 
> Does not the Supplicant know that it is trying to join an 
> infrastructure network ? In other words, the EAP 
> Authenticator sends an Request Identity packet as soon as it 
> sees a Supplicant connecting to it. There would be a race 
> condition (or conflict) when two EAP Authenticators try to 
> connect to each other. Such a situation can arise when two 
> isolated networks try to connect to each other. This can be 
> solved by the usual random back-off technique.
> 
> In other words the following table shows the situation for 
> connecting entities of two networks.
> 
>  Network 1 Entity    Network 2 Entity          Behavior
> ===============================================================
>     Supplicant          Supplicant              Can not connect
>     Supplicant          Authenticator           2 sends 
> Request Identity
> packet to 1
>     Authenticator       Supplicant              1 sends 
> Request Identity
> packet to 2
>     Authenticator       Authenticator           1 and 2 sends Request
> Identity packet after random time.
> 
> 
> Subrata
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> > Of Dror Caspi
> > Sent: Sunday, April 27, 2003 11:22 PM
> > To: CONGDON,PAUL (HP-Roseville,ex1); [email-masked]
> > Cc: Yael Dayan
> > Subject: RE: [eap] FW: peer-to-peer mutual authentication
> > 
> > 
> > 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.
> > - 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.
> > 
> > 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 
> method) it would 
> > still fit within the 802.1aa/D5 and RFC2284bis framework.
> > 
> > Dror
> > 
> > 
> > > -----Original Message-----
> > > 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
> > > 
> > > 
> > > 
> > > 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
> > > 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
> > _______________________________________________
> > eap mailing list
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> > 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Mon, 28 Apr 2003 11:13:50 -0400

If the underlying link layer is 802.1X, then it is pretty clear who is
supplicant and who is authenticator since the supplicant sends EAPOL-Start
messages.  If someone who is interested in playing either role receives an
EAPOL-Start, it may play the role of authenticator.  

Paul

-----Original Message-----
From: Subrata Goswami [mailto:[email-masked]] 
Sent: Monday, April 28, 2003 7:41 AM
To: [email-masked]
Subject: RE: [eap] FW: peer-to-peer mutual authentication

Does not the Supplicant know that it is trying to join an infrastructure
network ? In other words, the EAP Authenticator sends an Request Identity
packet as soon as it sees a Supplicant connecting to it. There would be a
race condition (or conflict) when two EAP Authenticators try to connect to
each other. Such a situation can arise when two isolated networks try to
connect to each other. This can be solved by the usual random back-off
technique.

In other words the following table shows the situation for connecting
entities of two networks.

 Network 1 Entity    Network 2 Entity          Behavior
===============================================================
    Supplicant          Supplicant              Can not connect
    Supplicant          Authenticator           2 sends Request Identity
packet to 1
    Authenticator       Supplicant              1 sends Request Identity
packet to 2
    Authenticator       Authenticator           1 and 2 sends Request
Identity packet after random time.

Subrata

> From: [email-masked] [mailto:[email-masked]] On Behalf 
> Of Dror Caspi
> prepared for role
> 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 
> the Supplicant? - both sides are equal peers.  One way we thought of 
> was for both peers start as Authenticator and  do some pseudo-random 
> i.e., if we implement this (say as a proprietary EAP method) it would 
> > 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
> > 
> > [I'm resending this message since it seems the original got lost -
> IEEE-802.1aa Comment
> IEEE-802.1aa, it seems that most of the attention is given to systems 
> 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 
> there seems to be a need for some explanatory text in the standards, 
> Add explanatory text about peer-to-peer mutual authentication.  Modify