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

[Florent Bersani (florent.bersani]

Walker, Jesse wrote:

> Fair enough, but that is not the intended sense of the text.
Right: I was saying that although I finally understood some time ago 
what the text meant, I remember misunderstanding it at first and meeting 
other (non-native English speakers) that had made (or worse, kept making 
the same misunderstanding).

If I am one the only one then fine. If the probability that I am not the 
only is non-negligible, then my suggestion is to try and clarify (and I 
am sorry that I am still unhappy with my own proposed resolution) ;-)

> The
> intended sense is that when you do the security analysis, then you can
> tell what each party knows. If in the analysis the two parties do not
> agree on each other's identity under the analysis, there is a security
> problem. If in the analysis the two parties do not agree on the session
> key they designed, there is a security problem. If the analysis shows
> the protocol exposes the session key somehow to any third party, then
> there is a security problem. If the analysis shows that the parties can
> confuse messages from one instance of the protocol with another (aside
> from those in the first round trip), then there is a security problem.
>  
I totally agree. It makes a lot of sense!

> The intent of the language is to require that protocols that EAP methods
> used intended for use with 802.11 undergo a reasonable amount of
> analysis.
>  
I also fully support this.

However, since the "synchronization of state" is not IMHO a standard 
concept (unlike e.g. mutual authentication), I was only trying to avoid 
confusions.

> -- Jesse
>
> -----Original Message-----
> From: Florent Bersani [mailto:florent.bersani [at] rd.francetelecom.fr] 
> Sent: Wednesday, July 14, 2004 2:37 PM
> To: Walker, Jesse
> Cc: eap [at] frascone.com; Bernard Aboba
> Subject: Re: [eap] Proposed Resolution to Issue 243: State
> Synchronization
>
> 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
> >
> >
> >
> >
> >    
>
>
>