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

From: [email-masked] (Subrata Goswami)
Date: Mon, 28 Apr 2003 09:04:38 -0700

The second question (or point) has to be do with the authentication
mechanism used by either authenticators. The strength of authentication
mechanisms are different, hence a rouge authenticator can potentially
fool the other authenticator to be the supplicant or use a less strong
authentication mechanism.  

Suppose Authenticator 1 can only use PAP, whereas Authenticator 2
understands both PAP and Certificates. The election mechanism could
elect the strongest authentication, and it may happen that  the  elected
supplicant  may not have the certificates.  So now the authenticators
know that they have to go down to PAP.  As they are equal now, either
can be the authenticator. Even in this situation the elected supplicant
may not have the security credentials, so now the authenticators can
reverse their roles and try again. Here a rouge authenticator can just
let the peer in and explorer the peer's network at will.  

Subrata

> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:[email-masked]] 
> Sent: Monday, April 28, 2003 8:36 AM
> To: 'Subrata Goswami'; [email-masked]
> Subject: RE: [eap] FW: peer-to-peer mutual authentication
> 
> 
> 
> >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. 
> >
> 
> Correct that EAPOL is outside of EAP, but could offer a link 
> layer solution to the problem.  Presummably a node capabile 
> of being both supplicant and authenticator would act as both 
> and send EAPOL-Start messages.  An infrastructure device 
> would seem to be the one wanting to act as either/both.
> 
> >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.
> 
> Don't fully understand the question, but neither EAP nor 
> EAPOL (802.1X) are symmetric in how the conversation is 
> driven and takes place.  An election process or set of rules 
> as described earlier would seem to offer the best approach 
> for selecting the one who will drive the conversation given 
> the current framework.
> 
> Paul
> 
> > -----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:35:35 -0400

>framework - correct ? So EAP need to have a way of its own to determine who

Correct that EAPOL is outside of EAP, but could offer a link layer solution
to the problem.  Presummably a node capabile of being both supplicant and
authenticator would act as both and send EAPOL-Start messages.  An
infrastructure device would seem to be the one wanting to act as
either/both.

>Also , there is the issue of  is one being the authenticator the same as

Don't fully understand the question, but neither EAP nor EAPOL (802.1X) are
symmetric in how the conversation is driven and takes place.  An election
process or set of rules as described earlier would seem to offer the best
approach for selecting the one who will drive the conversation given the
current framework.

Paul

> 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
> 
> 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.
> 
> connecting entities of two networks.
> 
>     Authenticator       Authenticator           1 and 2 sends Request
> > then how do you decide on who plays the Authenticator and who plays
> > However I am not sure that the above is still within the standard - 
> > > We did attempt to put some words in 802.1aa/D4 around this topic.
> > of a protocol such as EAP-Archie would seem to provide the required 
> > [email-masked]
> > http://mail.frascone.com/mailman/listinfo/eap
> > 
>