Subject: [eap] RE: Question on draft-walker-ieee802-req-00

From: "Walker, Jesse" <[email-masked]>
Date: Fri, 6 Feb 2004 07:06:29 -0800

Joe,

Here is my view of what "synchronization of state" means.

If both parties complete the authentication, then they will agree on
what 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.

If one of the parties fails to complete the authentication, then the two
parties will not agree on at least some of this information, and one
must be able to demonstrate that this lack of synchronization will
prevent the IEEE 802.11i 4-Way Handshake from completing successfully.

The complete list of requirements is a first attempt at imposing a
definition of what it means to be secure, so we can have some hope of
knowing what we are talking about. If you can suggest improvements to
this list of requirements or how they are expressed, it will be
appreciated.

-- Jesse

-----Original Message-----
From: Joseph Salowey [mailto:[email-masked]] 
Sent: Thursday, February 05, 2004 4:30 PM
To: [email-masked]; Walker, Jesse; 'Bernard Aboba'; [email-masked]
Subject: Question on draft-walker-ieee802-req-00

What does item [3], "synchronization of state," mean? 

What state do you expect to be synchronized?  

I ask because it is not clear to me that this is the same as "protected
result indicators."

Thanks,

Joe

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Sun, 08 Feb 2004 19:10:30 +0200

Hi Jesse,

Thanks for the explanation! A couple of clarifying questions
inline:

> the protocol. 

This seems clear, but a question to clarify the precise meaning
of "agree": Lets say your protocol needs to agree about three
parameters A, B, and C. You exchange A and B over the protocol
in authenticated messages, and then derive C as a function of A
and B using the same formula on both sides. Have you synchronized
the full state now?

I hate to pressure you on the meaning of common English words,
but what does "accept" mean? As in authenticated? Or also as in
authorized for access?

> They will also share the same view of negotiable

I'm assuming this all is still only about what happens in EAP,
not about e.g. link layer properties.

> prevent the IEEE 802.11i 4-Way Handshake from completing successfully.

This seems right. Can you explain where protected result indications
fit in? It seems that since the 4-way handshake requires key material,
a Fail/Reject decision from anyone on the list
    - peer
    - authenticator
    - aaa proxy
    - server
would result in there being no other party to complete the handshake
with. Or are the protected result indications necessary only if you
use plain .1X and no 4-way handshake at all?

--Jari

---

From: "Joseph Salowey" <[email-masked]>
Date: Sun, 8 Feb 2004 16:16:43 -0800

Thanks Jesse,

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? 

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.

Since the 802.11i 4-way handshake will fail appropriately, it would seem
that protected result indicators are not required in the 802.11i case.  

Joe

Walker, Jesse wrote:
> If both parties complete the authentication, then they will
> agree on what 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.
> 
> If one of the parties fails to complete the authentication,
> then the two parties will not agree on at least some of this
> information, and one must be able to demonstrate that this
> lack of synchronization will prevent the IEEE 802.11i 4-Way
> Handshake from completing successfully.
> 
> The complete list of requirements is a first attempt at
> imposing a definition of what it means to be secure, so we
> can have some hope of knowing what we are talking about. If
> you can suggest improvements to this list of requirements or
> how they are expressed, it will be appreciated.
> 
> -- Jesse
> 
> To: [email-masked]; Walker, Jesse; 'Bernard Aboba';
> [email-masked] Subject: Question on draft-walker-ieee802-req-00
> 
> I ask because it is not clear to me that this is the same as
> "protected result indicators."
> 
> Thanks,
> 
> Joe