eap Mailing List: Issue 213: Cleanup issues

[Bernard Aboba (aboba]

Issue 213: Cleanup issues
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 1/20/2004
Reference:
Document: RFC 2284bis-08.l
Comment type: T
Priority: S
Section: 3.1, 7.2.1
Rationale/Explanation of issue:

This is a generic issue to cleanup the text of -08.l as reflected in
WG discussions.

In Section 2.4 change:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated and
authorized the server."

To:

"The authenticator SHOULD
interpret the receipt of a key attribute within an Accept packet
as an indication that the peer has successfully authenticated
the server."

In Section 7.2.1, change:

"   Protected result indications
             A method provides result indications if after the method
             has finished (1) if the peer is willing to use the access
             provided by the authenticator, it knows whether the
             authenticator will grant access (that is, only either an
             EAP-Success or EAP-Failure will be accepted, no more method
             specific messages are expected), and (2) if the
             authenticator decides to grant access, it knows whether the
             peer will accept it.  Result indications improve resilience
             to packet loss; see Section 4.2 for discussion. Depending
             on the method and circumstances, result indications can be
             spoofable by an attacker.  A method is said to provide
             protected result indications if it supports result
             indications as well as the "integrity protection" and
             "replay protection" claims.  A method claiming to support
             protected result indications MUST indicate which result
             indications are protected, and which are not.  See Section
             7.16 for details."
To:

Protected result indications
A method provides result indications if after the
method has finished:

1) When peer is willing to accept access to the network, it knows whether
the authenticator will grant access.

2) When the peer decides to grant access, it knows
whether the peer will accept it.

Result indications improve resilience to packet loss,
and prevent long timeouts; see Section 4.2 for discussion.
Depending on the method design and circumstances, result
indications may be vulnerable to spoofing or replay by an attacker.

A method is said to provide protected result indications if
it supports result indications as well as the
"integrity protection" and "replay protection" claims.
A method claiming to support protected result indications
MUST indicate which result indications are protected, and
which are not. See Section 7.16 for details."