Subject: [eap] Proposed Resolution of Issue 224: State Synchronization

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 May 2004 20:17:00 -0700 (PDT)

The text of Issue 224 is enclosed below.  The proposed resolution is as
follows:

Change item [4] to the following:

"[4]  Synchronization of state.  This requirement applies when the EAP
     method completes successfully. The exact state attributes that are
     shared may vary from method to method but typically include 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."

--------------------------------------------------------------------------
Issue 224: State SynchronizationSubmitter name: Joe Salowey
Submitter email address: [email-masked]
Date first submitted: 2/24/2004
Reference:
http://mail.frascone.com/pipermail/public/eap/2004-February/002229.html;
see also issue 222
Document: EAP-WLAN-00
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 2.2, clause [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.

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

---

From: "Joseph Salowey" <[email-masked]>
Date: Tue, 11 May 2004 19:25:10 -0700

Looks good to me.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Monday, May 10, 2004 8:17 PM
> To: [email-masked]
> Subject: [eap] Proposed Resolution of Issue 224: State Synchronization
> 
> 
> Submitter email address: [email-masked] Date first 
> submitted: 2/24/2004
> Reference: 
see also issue 222
Document: EAP-WLAN-00

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.