Subject: [eap] Issue 222: Protected Result vs. synchronized state

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 9 Feb 2004 20:30:57 -0800

Submitter name: Joe Salowey	
Submitter email address: [email-masked]
Date first submitted: 2/9/2004
Reference:
http://mail.frascone.com/pipermail/public/eap/2004-February/002262.html
Document: RFC2284bis and/or draft-walker-ieee802-req-00 
Comment type: 'E'
Priority: '1' Should fix 
Section: 7.x
Rationale/Explanation of issue:

draft-walker-ieee802-req-00 places a requirement on synchronized state
which is then equated to protected result indicators.  It seems that the
two are not equivalent.  Synchronized state does not require protected
result indicators, since 802.11i has a 4-way handshake, protected result
indicators do not serve much purpose.  They are more important in
protocols that do not have subsequent protected messages such as
straight 802.1x (although if subsequent protection is not used there is
little you can do to secure the system in anycase).

Requested change:

Either add a section is 2284bis referring to synchronized state and
refer to it from draft-walker-ieee802-req-00 or  remove the reference to
protected result indicators in [3] of draft-walker-ieee802-req-00 and
replace with synchronized state reference.

Synchronized State

At the completion of an EAP authentication method the Peer and Server
MUST have the same notion of state related to the authentication.
Successful authentication MUST NOT result in a situation where both
parties believe the authentication succeeded, but have different notions
of state including; the 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 MUST also share the same view of
negotiable attributes of the EAP method specific protocol, such as
cipher suites, limitations of usage on all protocol state, and the same
view of what attributes of the protocol instance are public and which
are private to the two parties alone.  If the peer and the server do not
share the same notion of state then either or both of the parties MUST
fail the authentication and MUST NOT generate keys for export out of the
method.

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