Subject: [eap] editorial issues 2284bis

From: [email-masked] (John Vollbrecht)
Date: Tue, 04 Mar 2003 17:32:13 -0500

Following are several editorial issues fore 2284 bis.

Description of issue: simplify Introduction by not introducing concepts 
before needed
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: 3/4/03
Reference:
Document: Document Requiring change RFC2284bis
Comment type:E
Priority: 1
Section: 1
Rationale/Explanation of issue: Concept of backend server is best 
introduced in its own sections
Length description of problem

Requested change:change wording from middle of 3rd paragraph
from:
   Rather than requiring the authenticator to be updated to support each
   new authentication method, EAP permits the use of a backend
   authentication server which may implement some or all authentication
   methods, with the authenticator acting as a pass-through for some or
   all methods and users.

   Within this document, authenticator requirements apply regardless of
   whether the authenticator is operating as a pass-through or not.
   Where the requirement is meant to apply to either the authenticator
   or backend authentication server, depending on where the EAP
   authentication

to:
   Rather than requiring the authenticator to be updated to support each
   new authentication method, EAP permits the authenticator to use a
   backend server to do the actual authentication method.

----------------------------------------
Comment type:E
Priority: 1
Section: 1.2
Rationale/Explanation of issue: Definition of EAP server is confusing
See discussion on EAP list on EAP State machine.

proposal:
change:
     EAP server
             The entity that terminates the EAP authentication with the
             peer.  In the case where there is no backend authentication
             server, this term refers to the authenticator. Where the
             authenticator operates in pass-through, it refers to the
             backend authentication server.
to:
     EAP server
             The entity that terminates the EAP authentication method with
             the peer. In the case where there is no backend authentication 

             server the EAP server is part of the authenticator.  In the
             case where the authenticator operates in pass through mode, 
the
             EAP server is located on the backend authentication server.

-----------------------------
Comment type:E
Priority: 2
Section: 1.2
Rationale/Explanation of issue: clarification of Mutual Authentication 
definition

Change:
Mutual authentication
             This refers to an EAP method in which, within an
             interlocked exchange, the authenticator authenticates the
             peer and the peer authenticates the authenticator. Two
             one-way conversations, running in opposite directions do
             not provide mutual authentication as defined here.
To:
Mutual authentication
             This refers to an EAP method in which, within an
             interlocked exchange, the authenticator authenticates the
             peer and the peer authenticates the authenticator. Two
             independent one-way methods, running in opposite directions do
             not provide mutual authentication as defined here.

----------------------

Comment type:E
Priority: 2
Section: 1.2
Rationale/Explanation of issue:clarification

proposal:
change :
Security claims terminology (see Section 7.2):

to:
Security claims terminology for EAP Methods (see Section 7.2):

-----------------
Comment type:E
Priority: 2
Section: 1.2
Rationale/Explanation of issue:clarification of integrity protection 
definition

proposal:
change:

   Integrity protection
             This refers to per-packet authentication and integrity
             protection of EAP packets, including EAP Requests and
             Responses, and method-specific success and failure 
indications.
             When making this claim, a method specification
             MUST describe the fields within the EAP packet that are
             protected.

to:
   Integrity protection
             This refers to per-packet authentication of all EAP packets,
             including EAP Requests and Responses.  When making this claim,
             a method specification MUST describe the fields within the EAP 

             packet that are authenticated.

--------------------

Comment type:E
Priority:1
Section: 2
Rationale/Explanation of issue: Simplify description

proposal:
change:
[1]    The authenticator sends a Request to authenticate the peer.  The
       Request has a type field to indicate what is being requested.
       Examples of Request types include Identity,  MD5-challenge, etc.
       The MD5-challenge type corresponds closely to the CHAP
       authentication protocol [RFC1994].  Typically, the authenticator
       will send an initial Identity Request; however, an initial
       Identity Request is not required, and MAY be bypassed. For
       example, the identity may not be required where it is determined
       by the port to which the peer has connected (leased lines,
       dedicated switch or dial-up ports); or where the identity is
       obtained in another fashion (via calling station identity or MAC
       address, in the Name field of the MD5-Challenge Response, etc.).

to:
[1]   The authenticator sends a Request to authenticate the peer.  The
       Request has a type field to indicate what is being requested.
       Examples of Request types include Identity,  MD5-challenge, etc.
       Typically, the authenticator will send an initial Identity Request.

      [Note: an initial
       Identity Request is not required, and MAY be bypassed. For
       example, the identity may not be required where it is determined
       by the port to which the peer has connected (leased lines,
       dedicated switch or dial-up ports); or where the identity is
       obtained in another fashion (via calling station identity or MAC
       address, in the Name field of the MD5-Challenge Response, etc.).]