eap Mailing List: Re: Proposed Resolution to Issue 243: State Synchronization

[Florent Bersani (florent.bersani]

Jesse,

Walker, Jesse wrote:

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

> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On Behalf
> Of Florent Bersani
> Sent: Wednesday, July 14, 2004 1:37 PM
> To: eap [at] frascone.com
> 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
> > eap [at] frascone.com
> > http://mail.frascone.com/mailman/listinfo/eap
> >
> >
> >
> >    
> _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>
>
>