Subject: RE: [eap] Proposed Resolution to Issue 243: State Synchronization

From: "Walker, Jesse" <[email-masked]>
Date: Wed, 14 Jul 2004 13:48:56 -0700

Florent,

Yes, the distributed consensus problem does not admit a solution. But
this is because the protocol does not complete due to network
partitions. If the protocol completes, however, there is a certain
amount of state that must be synchronized, or else the protocol can't be
considered secure under any reasonable definition of secure. This is
what the language "when the EAP method completes successfully" from the
first sentence is supposed to capture. Can you suggest another way to
express this concept?

-- Jesse

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Florent Bersani
Sent: Wednesday, July 14, 2004 1:37 PM
To: [email-masked]
Cc: Bernard Aboba
Subject: Re: [eap] Proposed Resolution to Issue 243: State
Synchronization

I understand what is meant but I feel concerned that "synchronization of

state" may be understood as "common knowledge" (which is impossible to 
reach in a distributed environment with unreliable communications 
http://www.cs.cornell.edu/home/halpern/papers/common_knowledge.pdf - 
using the paper's terminology page 5, what we want here is E or E2 but 
not C that we can't provide).

Though I tried I couldn't figure out some simple wording to reflect this

(but I am still trying to).

Am I the only one that is uncomfortable with this wording?

Bernard Aboba wrote:

>The proposed resolution is to change clause [4] of Section 2.2 to the
>following:
>
>[4]  Synchronization of state.  The EAP method state of the EAP peer
and
>     server must be synchronized when the EAP method completes
>     successfully.  This includes the internal state of the
>     authentication protocol but not the state external to the EAP
>     method,  such as the negotiation occuring prior to initiation of
>     the EAP method.  The exact state attributes that are shared may
>     vary from method to method but typically include the method
version
>     number, what credentials were presented and accepted by both
>     parties, what cryptographic keys are shared and what EAP method
>     specific attributes were negotiated, such as ciphersuites and
>     limitations of usage on all protocol state.  Both parties must be
>     able to distinguish this instance of the protocol from all other
>     instances of the protocol and they must share the same view of
>     which state attributes are public and which are private to the two
>     parties alone.
>_______________________________________________
>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: Florent Bersani <[email-masked]>
Date: Wed, 14 Jul 2004 23:37:12 +0200

Jesse,

Walker, Jesse wrote:

>considered secure under any reasonable definition of secure. 
>
I guess this is my problem: you cannot be sure (in some sense) that the 
protocol successfully completed.

For instance, there are some instances in which, despite protected 
result indications, a station might believe it has successfully ended 
the EAP authentication whereas the other fails. This "desynchronization" 
is not detected by EAP but by the subsequent protocol.

To take a concrete example:
Peer                                      
Server                                        Attacker

    EAP dialog (e.g. EAP-PSK)
<------------------------------------>

Protected result indication (e.g. Done success delivered by the server 
to the peer)
<-------------------------------------

Protected result indication (e.g. Done success delivered by the server 
to the peer) intercepted by the attacker
-------------->X

EAP-Success
<----------------------------------------------------------------------------------

Protected result indication (e.g. Done success delivered by the server 
to the peer) retransmitted by the server
<-------------------------------------

The EAP peer is "not listening any more" (IINM - I have already asked 
questions on the "nature" of the EAP peer e.g. compared to the nature of 
an IKEv2 peer that keeps listening even after successful initial IKE 
exchanges that unfortunately were not answered :-()

You could argue that this does not conflict with the definition because 
in this scenario one of the two parties fail (so the dialog is not 
successful so the state need not be synchronized).

What makes me uncomfortable is that whether success or not has been 
reached is "somehow" part of the state and people might understand, 
under your definition, that it is impossible for a party to believe that 
it has succeeded and that its state is synchronized when it is not...

>This is
No I can't :-( and I am *open* to people telling me that I am the only 
one who has such metaphysical semantic concerns.

I guess my temporary proposed resolution would be to explicitly give an 
example like the one I have given and allude to the distributed 
consensus to say that it is *not* what is meant

>-- Jesse
Florent