eap Mailing List: RE: Question on draft-walker-ieee802-req-00

[Joseph Salowey (jsalowey]

So, by synchronized state I would expect the following of a complying
method.  

At the completion of authentication results in either one of two things:

1.  Both parties share the same cryptographic state and understanding of
the parties authenticated and parameters negotiated as part of the
protocol execution. If valid keys are generated on both sides then both
side MUST have the same understanding of the parties authenticated and
the parameters negotiated.

Or

2.  The authentication protocol has failed and protected communication
will not be possible because one or both parties failed to generate keys
as a result of protocol failure or perhaps because the cryptographic
state does not match between the two parties.

You MUST NOT ever have a result where both parties arrive at the same
cryptographic state enabling protected communication, but have different
notions of other state such as (from Jesse's previous message):

"protocol both executed, what credentials were presented and accepted by
both parties, what keys both have derived, and how to distinguish this
instance of the protocol from all other instances of the protocol. They
will also share the same view of negotiable attributes of the protocol,
such as cipher suites, and the same limitations of usage on all protocol
state, and particularly the same view of what attributes of the protocol
instance are public and which are private to the two parties alone."

Joe

> -----Original Message-----
> From: Walker, Jesse [mailto:jesse.walker [at] intel.com] 
> Sent: Monday, February 09, 2004 7:22 AM
> To: Joseph Salowey; eap [at] frascone.com
> Cc: Bernard Aboba; dstanley [at] agere.com
> Subject: RE: Question on draft-walker-ieee802-req-00
> 
> 
> Joe,
> 
> >In a hypothetical cryptographic protocol the client and 
> server exchange 
> >nonces in order to derive keys from a share secret.  In the 
> penultimate 
> >message the server sends a message to the client protected with keys 
> >derived form the new key material and in the final message 
> the client 
> >sends a message to the server protected with keys derived 
> from the new 
> >key material.
> >  
> >The client can be sure that the server derived the same keys 
> and vice 
> >versa.  Is the state now synchronized?
> 
> In any protocol one side always has to complete its state 
> first; there is no  getting around this. The point is that 
> the protocol must be designed so that the other side will not 
> proceed until it has synchronized its state as well. My 
> assertion is that protocols that do not have this property 
> are not and cannot be secure, at least not in the context of 
> IEEE 802.11.
> 
> >The client does not yet know if the server had a problem 
> verifying its 
> >final message. Is it required that the server acknowledge the final 
> >client message in order to say the state is synchronized? If 
> the server 
> >does have a problem verifying the final client message then the 
> >authenticator will not receive keys and the 802.11i handshake will
> fail.
> 
> In EAP this is automatic with a properly designed method. If 
> the Authentication Server does not receive the "final" 
> message, it will either retry the EAP Request to elicit the 
> final response from the EAP Peer, or it will give up and 
> abort the authentication process. In neither case will the 
> Authentication Server compute a PMK and push it to the NAS.
> 
> -- Jesse
>