Subject: [eap] 2284 bis issues

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

Description of issue : simplify description of sequences / separate 
description from security issues
Submitter name: John Vollbrecht
Submitter email address: [email-masked]
Date first submitted: 3/4/03

Document: RFC2284bis
Comment type: E
Priority: S
Section: 2.1
Rationale/Explanation of issue: Description implies that sequences are not 
supported.  The rationale for this is security indications, and should be 
in the security section.

Requested change:

change:
   An EAP conversation MAY utilize a sequence of methods. A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge. However, within or
   associated with each EAP server, it is not anticipated that a
   particular named peer will utilize multiple authentication methods
   (Type 4 or greater), either by supporting a choice of methods or by
   using multiple methods in sequence.  This would make the peer
   vulnerable to attacks that negotiate the least secure method from
   among a set (negotiation attacks, described in Section 7.8) or
   man-in-the-middle attacks (described in Section 7.4). Instead, for
   each named peer there SHOULD be an indication of exactly one method
   used to authenticate that peer name. If a peer needs to make use of
   different authentication methods under different circumstances, then
   distinct identities SHOULD be employed, each of which identifies
   exactly one authentication method.  If additional authentication
   methods are required beyond the initial one, the authenticator MAY
   send a Request packet for a subsequent authentication method, or it
   MAY send another Identity request.  If the peer does not support
   additional methods, it SHOULD respond with a Nak, indicating no
   acceptable alternative, as described in Section 5.3.  However, peer
   implementations MAY not respond at all, in which case a timeout will
   result and authentication will fail. Since the authenticator
   presumably requires successful completion of the sequence in order to
   grant access, authentication failure is the correct result.
   Therefore, it is not necessary for the authenticator to determine
   that the peer supports sequences prior to sending a Request for a
   subsequent authentication method.

to:

   An EAP conversation MAY utilize a sequence of methods. A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge.  If additional
   authentication
   methods are required beyond the initial one, the authenticator MAY
   send a Request packet for a subsequent authentication method, or it
   MAY send another Identity request.  If the peer does not support
   additional methods, it SHOULD respond with a Nak, indicating no
   acceptable alternative, as described in Section 5.3.  However, peer
   implementations MAY not respond at all, in which case a timeout will
   result and authentication will fail. Since the authenticator
   presumably requires successful completion of the sequence in order to
   grant access, authentication failure is the correct result.
   Therefore, it is not necessary for the authenticator to determine
   that the peer supports sequences prior to sending a Request for a
   subsequent authentication method.

and rewrite the following and add to security section:
   However, within or
   associated with each EAP server, it is not anticipated that a
   particular named peer will utilize multiple authentication methods
   (Type 4 or greater), either by supporting a choice of methods or by
   using multiple methods in sequence.  This would make the peer
   vulnerable to attacks that negotiate the least secure method from
   among a set (negotiation attacks, described in Section 7.8) or
   man-in-the-middle attacks (described in Section 7.4). Instead, for
   each named peer there SHOULD be an indication of exactly one method
   used to authenticate that peer name. If a peer needs to make use of
   different authentication methods under different circumstances, then
   distinct identities SHOULD be employed, each of which identifies
   exactly one authentication method.