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

[Nick Petroni (npetroni]

Thanks for picking up on this thread Paul. Some comments are inline.

> From what I understand from this thread, the situation we are talking about
> is the case where both supplicant and authenticator are configured and
> enabled on the same port (i.e. they are both contributing to the opening of
> the controlled port), and the objective is to avoid running a 2nd
> authentication in the opposite direction when the 1st authentication, using
> a mutual method that delivers protected indications, actually succeeded.
Ok, that's my understanding as well.

> understand if it does.  First question is when there is both an independent
> supplicant and authenticator configured at the 802.1X layer, is there also a
> corresponding independent EAP layer above each?  I think the answer is yes.
Depending on how you draw/label your layers there are probably not 2 "EAP
Layers," but certainly the Peer and Authenticator traffic gets
demultiplexed to separate state machines. Figure 2 in 2284bis, which you
included in your second email, shows this best I think. Either way, I
think your conclusion that they are separate is the right one.

> I believe the assumption from the 802.1X level is that a received EAP frame
> is delivered to both supplicant and authenticator in this case, and would
> thus be handed up to their respective EAP layers.  The peer side would be
> ignoring responses and the authenticator side would be ignoring requests.  I
> think this all works and I believe Jim Burns has walked these scenarios.
Yes, I think this is right.

> A. standalone to standalone
> B. standalone to passthru
> C. passthru to passthru, each with their own path to their authentication
>    server
> D. passthru to passthru with a single path to the authentication server
ok. I didn't quite understand D, but I think I'm still with you.

> In scenario A, since the EAP conversation is terminated locally, knowledge
> of the mutual nature of the authentication and receipt of the protected
> indications is well known on both sides.   In this case, the side that acted
I agree that both sides can know the authentication information but from a
purely abstract point of view I think we should be clear which LAYERS know
this information. The state machines are designed around a specific
interface and the semantics may not be as clear as they could be in this
case. I would argue that on the peer side eapSuccess only gets set if BOTH
the peer and the authenticator have satisfied their policies. This is to
avoid session hijacking and other attacks that can occur if the Peer EAP
layer is not selective about when it tells the lower layer it will allow
access. The reverse is not (necessarily) true of eapSuccess on the
Authenticator side, even in the standalone case. I think it's ambiguous
what a method is supposed to return if mutual auth fails but the peer is
authenticated. Most would probably argue eapSuccess only means the peer
has been authenticated in the Authenticator, but IMHO this is not the same
as the peer side. It would be possible, however, to configure a
(hypothetical) method to only return succees if it is confirmed that both
sides accept the authentication. The question, at least for me, comes down
to what the signals mean explicitly.

> authenticator authorized.  I understand, however, that we want the
> standalone and passthru models to work the same, so this is a bit of a hack.
I agree we want these to be the same. Furthermore, I would argue that the
semantics of the interface variables need to be the same, not just the
overall system to behave the same.


> Scenario B is the typical case today where we don't configure both
> supplicant and authenticator, but rather have the station act as supplicant
> and the access point act as authenticator.  Nonetheless, we must look at
> this scenario in two cases.  The first case, where the passthru mode starts
> out as authenticator and the standalone as supplicant.  In this case the
> passthru would likely take advantage of the new variable defined for 802.1X
> that opens the port regardless of what it's supplicant component is saying.
> It would still run the supplicant machine however, just not depend upon the
> result, so we would have two authentications taking place if the other side
Ok, so I think you are saying this new variable indicates that the
authenticator was sufficiently satisfied by the first authentication so it
doesn't care about the second. Makes sense.

> really wanted.  The standalone side, however, would know it is satisfied and
> could force authorize its authenticator and thus not run the second
> authentication.  In the second case, the passthru starts out as supplicant.
> Again, since the passthru would be satisfied as supplicant, it could force
> authorize its authenticator and not run the other machine.  The standalone
hmm, this part I am not so sure about, but maybe I just haven't worked it
out right in my head. If the passthru is the supplicant, then the backend
will not be involved in that particular authentication right? I mean,
there is no passthru supplicant per se, so I am confused how the server
part of the authentication gets done in this direction. I think I get
really confused when we get to C and D too, as I don't understand exactly
where the authentication is taking place.


Before I say anymore, perhaps someone could clarify for me what C and D
really look like. When you have two passthru machines, where does the
supplicant live? My understanding was that the passthru device has a local
supplicant, but then when it is acting this way how does it involve its
backend server?
> Scenario C would again have to take advantage of the new variable for the
> side that started out as authenticator and would then need to force
> authorize on the side that started out supplicant.  We can always assume the
> supplicant has full knowledge of the mutual authentication and protected
> indications since it must terminate one side of the EAP conversation. The
> supplicant side can always force authorize its authenticator complement, but
> since the machines are independent, it is likely that the authenticator is
> already running and the 2nd authentication is already going on.  If the new
> variable were not configured to ignore the supplicant result, the side that
> started out as authenticator would always need to run and complete its
> supplicant component.
>
> Scenario D is a strange special case that points out the need for the new
> variable we added as a result of comment 15.  It is simply impossible to
> support this scenario unless there is the ability for the passthru NAS with
> the path to the authentication server to open its port regardless of the
> result of its supplicant component.  If it didn't open its port the remote
> peer acting as authenticator could not talk to the authentication server and
> we are hung.

>
> Conclusion:
> -----------
>
> The supplicant side or any standalone system always has full knowledge of
> the mutual nature of the authentication, so it could use this knowledge to
I think you are right, but it depends on the semantics of eapSuccess I
think. If eapSuccess only indicates confirmation of one-way
authentication, then I think even though the local system 'knows' both
sides are happy, EAP needs to make this clear somehow to the lower layer.

> disable the other half of the 802.1X component (or force it authorized) and
> cause only a single authentication exchange to take place.  The passthru
> authenticator side can ignore the result of its supplicant side by using the
> new control variable, but it does not eliminate the second authentication
> unless the other side has decided not to initiate one.
OK, This seems fine to me. Assuming it has the information it needs from
above, this works I think.


Thanks Paul. Comment welcome.

Regards,
nick