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

From: [email-masked] (Dror Caspi)
Date: Mon, 28 Apr 2003 09:21:50 +0300

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

---

From: [email-masked] (Jari Arkko)
Date: Mon, 28 Apr 2003 09:43:35 +0300

>   exchanges in each direction are not equivalent to a single mutual authentication

Right. One mutual auth is good enough, however, in theory. But there
may still be protocol problems (see below).

> 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…

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.

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

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.

--Jari

---

From: [email-masked] (Subrata Goswami)
Date: Mon, 28 Apr 2003 07:40:59 -0700

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
> Sent: Sunday, April 27, 2003 11:22 PM
> To: CONGDON,PAUL (HP-Roseville,ex1); [email-masked]
> Cc: Yael Dayan
> 802.1aa/D5 (section 6.7) talks about this issue, but unless I
> misunderstood some of the text it is still problematic.
> 
> 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
> 
> 
> > 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
> > [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]