eap Mailing List: RE: Issue 204: Peer-to-peer operation

[Pasi.Eronen (Pasi.Eronen]

Bernard Aboba wrote:
> As noted in the IEEE 802.1XD7.1 ballot resolution, comment 15,
> the current EAP SMs do not fully support peer-to-peer
> operation.
>
> The current EAP Peer SM does not provide a mechanism for the
> EAP method to signal to EAP and the lower layer that mutual
> authentication has been achieved.
>
> In addition, the EAP authenticator SM does not provide a
> mechanism for the EAP layer to indicate to the lower layer
> that a protected result indication has been received from the
> peer, indicating that the peer has authenticated the
> authenticator.
>
> Similarly, the EAP Peer SM does not provide a mechanism for
> the EAP layer to indicate to the lower layer that a protected
> result indication has been received from the authenticator,
> indicating that the Authenticator has authenticated the peer.
>
> As a result of these missing indications, it is not possible
> for EAP to provide for mutual opening of the 802.1X controlled
> ports for use in peer-to-peer operation, even where a method
> providing for protected result indications is in use.

Hmm, I'm not sure if I understand this... Is this issue about the 
case when there are two independent EAP conversations (i.e. both 
parties act as peers and authenticators), or ordinary mutual 
authentication with only a single EAP conversation?

The latter case should be rather simple, since setting the
controlled port to "authorized" when eapSuccess is set 
seems to be exactly the right thing to do (and the lower
layer doesn't really need to know anything else).

In the former case, both parties have both peer and
authenticator state machines, and this is something that .1X
doesn't handle well (for instance, we have two separate
variables both named eapSuccess :-). Is this what you mean?

Best regards,
Pasi