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

[Bernard Aboba (aboba]

On Tue, 25 Nov 2003, Nick Petroni 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.
>
> I am not completely convinced of this. It seems to me what you are asking
> for here is for EAP to provide two signals indicating the success of
> authentication in each direction. This is not how I read the model of
> 2284bis. I would argue that the use of a method providing mutual
> authentication still requires EAP to provide only one answer to
> the conversation. It is possible to require mutual authentication before
> Success and even to guarantee that answer with protection, but I do not
> see a reason for the lower layer to get an explicit "mutual
> authentication" signal. If mutual authentication is required and it was
> not obtained then success (the signal, not the packet) will never follow
> for a properly configured peer.

That makes sense to me, because the peer would not accept the access
offered by the authenticator otherwise.  However, the response to IEEE
802.1X D7.1 comment 15 suggests that something further is needed. I'm not clear
what this is, but I'm suggesting that we need to be clear on why this is
not required (and note this explicitly in the SM document).

> > 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.
> I disagree. If you require mutual authentication then EAP Success is this
> indication.

The resolution of IEEE 802.1X D7.l comment 15 states explicitly that this
indication is insufficient for peer-to-peer operation, potentially because
of the issue with protected result indications below.

> > 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.
> hmm, this one is slightly more interesting, but I have no idea how the
> backend would ever alert the passthrough of this. Still, I think it is
> possible to say that if mutual authentication is required and not
> achieved then the decision will be fail.

I think the issue is the following:

a. The authenticator figures out whether it wants to offer access to the
peer or not.  In the case of pass-through this is communicated in the
Access-Accept.

b. The authenticator communicates it desire to offer access to the peer.
This occurs via a protected result indication.

c. The peer figures out whether it wants to accept that access. This is
communicated to the authenticator via a protected result indication
and communicated to the peer lower layer via eapSuccess.

c. This creates a situation where the peer has full knowledge of each
side's decision (peer knows the authenticator is offering access, and that
it wants to use the access), but the authenticator may not (authenticator
knows that it wants to offer access, but in the case of pass-through
operation it may not know if the peer has accepted it).

To fix this, the authenticator SM could have a variable that says that
the peer has provided a protected result indication to it, indicating that
it will accept the offered access.  In terms of AAA, this
could result in a new attribute indicating "peer-to-peer auth achieved" or
something of that nature, so that another EAP authentication need not be
rerun in the opposite direction.

> I disagree that peer-to-peer is not supported. I would agree that the
> specific interface is not provided for two signals, but I would like to
> understand better why those signals are needed. Also, a suggestion for
> where these signals would go and who sets them might help me understand
> this issue better.

Have a look at the IEEE 802.1X D7.1 resolutions to comment 15.  They're
available here:

http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf

Username: p8021
password: go_wildcats