Subject: [eap] Re: Issue 51: Turnaround Description

From: [email-masked] (Bernard Aboba)
Date: Thu, 2 Jan 2003 09:36:22 -0800 (PST)

This looks reasonable. Any objections to accepting this change?

Issue 51: Turnaround description
Submitter name: James Carlson
Submitter email address: [email-masked].
Date first submitted: January 2, 2003
Document: RFC2284bis
Comment type: T
Priority: S
Section: 2
Rationale/Explanation of issue:

This problem seems to have been introduced with the resolution to
issue #48. The description, though, is at odds with the original EAP
design and usage in PPP. Despite the text, there is no requirement of
synchronization between the independent authentication sessions in
each direction. The words "after" and "complete" are misleading.

Requested change:

from:

[7] Since EAP is a Peer-to-Peer protocol, after authentication in one
direction is complete, the direction of authentication MAY reverse,
with the endpoint previously serving as the Authenticator assuming
the Peer role, and the former Peer now taking on the Authenticator
role. As with the original conversation, the reversal is signalled
by the (new) Authenticator sending a Request. Support for bi-
directional authentication requires that each endpoint implement
both the Peer and Authenticator roles.

to:
[7] Since EAP is a Peer-to-Peer protocol, an independent and
simultaneous authentication may take place in the reverse
direction. Both peers may act as authenticators and
authenticatees at the same time.