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

[CONGDON,PAUL (HP-Roseville,ex1) (paul.congdon]

In coming up to speed on this issue, I have a few comments and questions...
Sorry for the length of this...

In 802.1X, once the control port is opened, it is opened, so when a passthru
authenticator receives an Access-Accept from the authentication server as
the result of a successful authentication (be it mutual or not) it will open
the port from its perspective.  If it also has a supplicant configured, the
port will remain closed until the supplicant is also successful.  However,
as part of the resolution of comment 15 in 802.1X-REV/D7.1 we added a local
management variable that allows the device to override the supplicant's need
to also authenticate and be satisfied with the authenticator's result.  This
would be used in passthru devices such as bridges and perhaps access points,
but less likely in ad-hoc peers.

>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.
Since in 802.1X, the supplicant and authenticator machine are independent,
it isn't clear how this 2nd authentication would be controlled or avoided.
The management variable created as a result of Issue 15 is, perhaps, one
approach.  There may be others.

I have a general question about how the above scenario will work and we
should walk through the sets of state machines of both 802.1X and EAP to
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.
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.

To aid in my understanding, I'd like to toss out a taxonomy of
configurations where both supplicant and authenticator are configured and
enabled on a port.  Sorry if this makes reading difficult, but perhaps it
will help us understand how important this is (or is not).  In each of the
configurations, it is possible for any one side to complete the initial
authentication as the supplicant and the other as the authenticator.  The
configurations, and possible examples as I see them are as follows:

A. standalone to standalone
        - each side has its own authentication server component
        - For example, an ad-hoc 802.11 set of stations.
B. standalone to passthru
        - one side is acting as a passthru, but the other is standalone.
        - passthru side has access to authentication server via another
authorized port.
        - For example, a station connecting to an access point or bridge
C. passthru to passthru, each with their own path to their authentication
server
        - both sides can freely talk to their authentication servers via
another authorized port
        - For example, two bridges talking to one another   
D. passthru to passthru with a single path to the authentication server
        - both sides need to talk to the authentication server, but one must
reach it via the other's controlled port
        - For example, two bridges talking to one another, only a single
authentication server

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
as authenticator could effectively force its supplicant role to be
authorized and the side that acted as supplicant could force its
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.

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
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
side would have to do the same thing based upon its knowledge of the
successful mutual authentication.

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
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.

Paul    


> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, November 25, 2003 7:27 PM
> To: Nick Petroni
> Cc: eap [at] frascone.com
> Subject: Re: [eap] Issue 204: Peer-to-peer operation
> 
> 
> > Do we agree there is no problem on the peer side? If so, 
> let's turn to 
> > the authenticator...
> 
> Yes, I agree with this.  Not sure about the IEEE 802.1aa 
> folks.  Can anyone who was there fill us in?
> 
> > It seems to me what you are saying is that even after receiving an 
> > Accept-Accept, the passthrough does not know it is allowed to have 
> > access even though it is allowed.
> 
> Yes, the pass-through knows it will provide access to the 
> peer, but doesn't know whether the peer will accept the 
> access.  Note that if the authenticator was not a 
> pass-through, then it would know, because it would have 
> received the result indication from the peer.
> 
> > There are two possible solutions I see-
> > 1. make Access-Accept mean that BOTH things are ok and that mutual 
> > auth is known to have succeeded or
> 
> I don't think we can change the meaning of Access-Accept at 
> this point.
> 
> > 2. make Access-Accept strictly mean the Peer is to be given access, 
> > and make some other AAA signal/message provide the other 
> information.
> 
> This one could work.  For example, we could add a "P2P 
> complete" attribute to tell the pass-through that the peer 
> has sent a successful result indication.
> 
> > If mutual auth is required, the server can tie the auth directly to 
> > the EAP aaaEapSuccess signal. That is, both must be 
> authenticated for 
> > aaaEapSuccess to be true. This only works for case 1 above, 
> as the AAA 
> > layer can't separate these two if it is only given binary input. I 
> > believe THIS is the missing variable you describe?
> 
> I think another variable is needed on the authenticator SM to 
> indicate that a result indication has been received from the peer.
> 
> > I am really having trouble with the model for why the passthrough 
> > needs this information. when using a peer and a passthrough 
> > authenticator, it's tough for me to see the true peer-to-peer 
> > relationship we are describing in any real-world scenario.
> 
> The scenario that IEEE 802.1af has been looking are bridges 
> talking to one another.  I think that the IEEE 802.11 adhoc 
> scenario may also be affected. The way to think about this is 
> "can the two sides confirm that both controlled ports are 
> passing packets, so that another EAP authentication will not 
> have to be run in both directions".  If the answer is no, 
> then you need to do another authentication, which is wasteful.
> 
> > That being said, this does not mean we
> > shouldn't handle the situation. My understanding of all passthrough 
> > implementations is that if there was to be mutual 
> authentication, but 
> > the peer failed to authenticate the authenticator the peer 
> will just 
> > go away (or try again) anyway.
> 
> Yes.
> 
> > Additionally, I understand the argument that we want 
> passthrough and 
> > standalone to have the same semantics, but I think even in the peer 
> > and standalone statemachines it is policy that is tying 
> together the 
> > two authentication decisions into a single signal. The 
> method should 
> > be set to only succeed in the case of mutual authentication 
> if mutual 
> > auth is required.
> 
> I think there may be subtle distinction being made between 
> mutual auth (where the authenticator might not know whether 
> the peer is going to accept the access it granted), and 
> protected result indications, where the authenticator would 
> know the peer decision, absent the pass-through issues we 
> just talked about.
> 
> > My current position is that I don't see why you need two 
> answers. If 
> > you know you are using a method with mutual authentication, 
> then you 
> > should be able to tie the outcome of that method to a two-way 
> > relationship.
> 
> As mentioned above, I think it's about both sides being able 
> to confirm that they are willing to talk at L3, not just for 
> the authenticator to confirm its willingness to offer access 
> to the peer. _______________________________________________
> eap mailing list
> eap [at] frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>