Subject: [eap] P802.1aa/D4.1 Ballot - Disapprove (fwd)

From: [email-masked] (Bernard Aboba)
Date: Mon, 9 Dec 2002 21:45:20 -0800 (PST)

A reminder that the IEEE 802.1aa D4-1 ballot is now running. Even if you
are not a voting member of the IEEE 802.1 task group, you can still read
the document and send in your ballot comments in order to ensure that IEEE
802.1X-2003 is aligned with RFC 2284bis.  Find enclosed an example
ballot with some example comments from a non-voting member (me). Ballots
can be mailed to [email-masked].

Access has been granted to the IEEE 802.1 archive for use by the EAP WG,
as folows:

http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4-1.pdf
userid:   p8021
password: go_wildcats

On Mon, 9 Dec 2002, Bernard Aboba wrote:

> P802.1aa/D4.1 EMAIL BALLOT
> 20th November 2002
> TO: Tony Jeffree
> Editor, P802.1aa
> SUBJECT: P802.1aa/D4.1 - Network Port Authentication
>
> _____ 802.1 Voting Member
> __X__ I Disapprove (must attach binding comments below)
>
> Bernard Aboba
> [email-masked]
>
> ------------------------------------------------------------------------
> INCLUDE COMMENTS BELOW THIS POINT
>
> NAME: Bernard Aboba
> COMMENT TYPE: T
> CLAUSE: 6.6
> PAGE: 20
> LINE: 16
> COMMENT START:
> Not sure what the implication is here. EAP has long supported
> peer to peer operation as is described in this section so that
> the authentication may be initiated by either party or both.
> So I'm not clear how this would result in a mutually authenticating
> EAP method being unsupported by 802.1X.
> COMMENT END:
> SUGGESTED CHANGES START:
> Change the entire section to:
>
> "The model of operation of 802.1X is one where the Supplicant
> is authenticated by the Authenticator, with the help of the
> Authentication Server function. In situations where bi-directional
> authentication is needed between a pair of systems connected by a
> common LAN segment, it is necessary for each system to adopt both
> Authenticator and Supplicant roles; operating as an Authenticator
> in order to authenticate the other system, and as a Supplicant in
> order to be authenticated by the other system.
>
> For example, this can be required within IEEE 802.11 in order to
> support adhoc authentication. Alternatively it may be desirable to
> protect a Bridged LAN from the attachment of additional unauthorized
> Bridges, and for the additional Bridges to protect themselves against
> being attached to an unauthorized Bridged LAN. In this case it would
> be appropriate for the Bridges to implement both Authenticator and
> Supplicant functionality. When two Bridges, A and B, first connect
> to each other, they would both initiate authentication exchanges.
> Once Bridge A successfully authenticates Bridge B, Bridge A's
> controlled Port would be authorized; however, data transfer between
> the Bridges can only take place once Bridge B has successfully
> authenticated Bridge A,  resulting in Bridge B's controlled Port
> being Authorized.
>
> Note that systems supporting bi-directional authentication need
> to be prepared for role reversal. That is, after completing
> authentication in one direction,  the system formerly operating
> as an Authenticator may receive an EAP-Request from the system
> formerly operating as a Supplicant, indicating the desire to
> reverse the direction of authentication.
>
> Systems supporting bi-directional authentication typically authenticate based on
> locally stored credentials, using a locally implemented authentication method,
> so that they may operate without requiring assistance from backend authentication
> servers. However, this need not necessarily be the case. It is even possible, though
> uncommon, for a Supplicant to be assisted by a backend authentication server, so
> that an EAP-Request could be encapsulated within an Access-Request, and
> answered by an EAP-Response encapsulated within an Access-Response. This is
> permitted by RFC 2869bis, though support is optional on the backend authentication
> server.
>
> Note also that from the point of view of security, two one-way authentication exchanges in
> each direction are not equivalent to a single mutual authentication exchange, since
> the two one-way authentication exchanges are not cryptographically bound together.
> For example, two EAP MD5 exchanges in each direction are vulnerable to man-in-the-middle
> and reflection attacks, whereas a single mutually authenticating exchange would not
> be, assuming that it derives a key that remains uncompromised by the attacker."
> SUGGESTED CHANGES END: