eap Mailing List: Issue : IEEE802.11 requirements doc item (3)

[Joseph Salowey (jsalowey]

Submitter name: Joe Salowey
Submitter email address: jsalowey [at] cisco.com
Date first submitted: 2/24/2004
Reference:
http://mail.frascone.com/pipermail/public/eap/2004-February/002229.html;
see also issue 222
Document: IEEE 802.11 document
Comment type: 'T'echnical 
Priority:  '1' Should fix 
Section: [3]
Rationale/Explanation of issue:

Synchronization of state is not the same as protected result indicators.
It is possible to have synchronized state without protected result
indicators and it is possible for a poorly implemented method to
implement protected result indicators and not have synchronized state.
The suggestion is to replace protected result indicators with a
description of synchronized state.  The following suggested text is
based on some email exchanges on the EAP list with Jessie Walker.

Synchronized State

At the completion of an EAP authentication method the Peer and Server
must have the same notion of state information related to the
authentication. If the peer and the server do not share the same notion
of state information then either or both of the parties must fail the
authentication and must not generate keys for export out of the method.
The exact state attributes that are shared may vary from method to
method but it typically includes the protocol both executed, what
credentials were presented and accepted by both parties, what
cryptographic keys are shared and what EAP method specific attributes
were negotiated, such as cipher suites 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.