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

From: "Joseph Salowey" <[email-masked]>
Date: Thu, 5 Feb 2004 16:29:51 -0800

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: "Walker, Jesse" <[email-masked]>
Date: Mon, 9 Feb 2004 07:06:45 -0800

Jari

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

What the definition is attempting to capture is that there is some state
that has to be identical at both the EAP Peer and the Authentication
Server. If this state is not the same, then this is an exploitable
vulnerability. Some of the state may be method specific, but it is easy
to give examples. If the authenticated identities of both parties at the
EAP Peer and the Authentication Server are different, then the
vulnerability is that an attacker might be able to convince the two that
they are communicating with parties other than the true peers. If the
key identifier at the EAP Peer and the Authentication Server is not the
same, then the vulnerability is an attacker might be able to convince
the two that they are using a different key from what they really are.
If the method's Master Key or one of the derived keys is different at
the two parties, then the vulnerability is an attacker might be able to
act as a man-in-the-middle. If the session identifier at the EAP Peer
and the Authentication Server is not the same, then the vulnerability is
an attacker might be able to convince one of the two to use the wrong
session.

If you can suggest a better way to express this, please suggest. But I
don't think we can eliminate state synchronization as a requirement,
because synchronized state is a requirement for a method to be secure.

>> 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.
>
>I'm assuming this all is still only about what happens in EAP,
>not about e.g. link layer properties.

Right; we are talking about requirements for EAP methods. These
requirements are imposed by the environment. Many EAP methods that are
fine in a wired environment (because the market said so ;-) are not in a
wireless environment (even though the market hasn't said so yet, if you
try to use methods that assume the physical security of a wired
environment, you won't like the result when it finally speaks). A method
cannot be used in arbitrary circumstances unless it was explicitly
designed for use in arbitrary circumstances. Most method designers have
cut corners.

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

I haven't thought sufficiently about this, but my instinct is to respond
that most usable EAP methods are likely to be well-designed to
accomplish this. If the EAP Peer's state is not complete, then the EAP
Peer will not respond to the final EAP request establishing that state,
so the Authentication's state cannot become complete, either. This view
assumes, of course, that (a) the EAP Peer's synchronized state is
established at a point in the method prior to the Authentication Server,
and (b) the Peer's messages at this point are protected from replay and
from forgery. Similarly, if the Authentication Server fails to complete
the state synchronization steps of the protocol, it will not create a
PMK for the NAS. This view assumes that there is an end-to-end channel
between the Authentication Server and the NAS that protects the
confidentiality of the transferred PMK, and also protects the PMK
message from replay and from forgery.