Subject: RE: [eap] Issue 204: Peer-to-peer operation

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 1 Dec 2003 16:50:41 -0800

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: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, November 25, 2003 7:27 PM
> To: Nick Petroni
> Cc: [email-masked]
> 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
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Wed, 3 Dec 2003 07:38:01 -0500 (EST)

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

> a mutual method that delivers protected indications, actually succeeded.
Ok, that's my understanding as well.

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

> think this all works and I believe Jim Burns has walked these scenarios.
Yes, I think this is right.

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

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

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

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

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

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

> 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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 3 Dec 2003 07:40:18 -0800 (PST)

> corresponding independent EAP layer above each?  I think the answer is yes.

I'd say that there is a single EAP layer on the host, but EAP
authenticator and peer layers will be present above that.  This makes it
possible for the host to process traffic *both* for the EAP peer
(EAP Request (Code=1), Success (3), Failure (4)) and for the authenticator
(EAP Response (Code=2)).  However, an EAP packet will only be processed
if there is a method registered corresponding to the Type code
in the packet *and* the method has registered with the EAP peer or
authenticator layer or both.  So if a method has only registered with the
EAP peer layer and a packet destined for the authenticator layer is
received (e.g. Code=2), then that packet will be dropped.

> think this all works and I believe Jim Burns has walked these

There are not two EAP layers operating.  This is like saying that an IPv4
host that is both a TCP initiator and listener has two IP stacks.  The
EAP layer is capable of demultiplexing traffic between the EAP peer and
authenticator layers, using the Code field in the EAP packet.

The authenticator side would also be ignoring Success (3) and Failure (4)
packets.

> D. passthru to passthru with a single path to the authentication server

RFC 2284bis only defines passthrough operation for the EAP authenticator
layer,  not the EAP peer layer.  AAA protocols such as RADIUS &
Diameter only support pass-through of packets handled by the authenticator
layer. That said, EAP WG has had presentations where EAP methods were
resident on a smartcard, and "peer pass-through" was implemented for
methods supported by the smartcard.  However, the "peer pass-through" is
a very different animal from a AAA server, so I'm also unclear about case
D.

> 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

One thing to keep in mind is the operation of a device such as an AP which
also acts as an EAP peer to the switch to which it is attached.  In this
case, the AP is authenticating to the switch, presumably so as to prevent
the insertion of rogue APs.  Depending on the method used, if an
authentication initiated by the switch fails, then the switch will not
enable its controlled port, and the AP may also not enable the controlled
port on its wired (DS) side.  I am not sure that the operation of the AP
is determined by a variable, so much as the operation of the method in
question. After all, the AP is as much concerned with whether it is
attaching to an authenticatic network as the switch is concerned about
rogue APs.  Adding more knobs just increases the probability that they
will be set incorrectly.

> doesn't care about the second. Makes sense.

It makes sense if the variable is set by the method.

> where the authentication is taking place.

In C, one could assume the authentication taking place in a smartcard
attached to the Supplicant/peer.

> peer acting as authenticator could not talk to the authentication server and

I'm not sure that's incorrect, actually.  Imagine an AP authenticating to
a switch.  The AP will not be able to access its authentication server
until it convinces the switch that it is authentic, so that the switch
will enable the controlled port.  It is an interesting question whether
the switch would be able to reach an authentication server operating on the
wireless side of the AP, especially if in an EAP authentication
initiated by the switch, the switch fails to authenticate to the
peer in an EAP method supporting mutual authentication.  I believe the
answer to that question is that the authentication server would
not be reachable.

> unless the other side has decided not to initiate one.

I believe this is correct.  Regardless of what one side decides, the other
side can always decide that its policy isn't satisfied and that it wants
to initiate an authentication in the other direction.

---

From: Jim Burns <[email-masked]>
Date: Wed, 03 Dec 2003 15:07:30 -0500

Hi folks,
    Comments below.
Jim B.

>received (e.g. Code=2), then that packet will be dropped.
Our original assumption in the design of the .1X/EAP state machines was 
that EAP was a functional entity that could have multiple 
instantiations, one for each state machine.  So, the current .1X design 
delivers the EAP frame once to each EAP machine (which looks like two 
deliveries of the same frame if there is a single EAP mux/demux layer).

The .1X transport does not filter the frames as EAP peer frames and EAP 
authenticator frames because there is no indication in the EAPOL header 
of the type of EAP frame being carried and their is no logic in .1X 
which is related to the EAP header. 

So, we need to answer the question:
Is their a single EAP layer above the lower layer transport that does 
mux/demux?
Does the EAP layer assume there is a single channel to the lower layer 
transport or one for each of its EAP's state machine?

If the answer is that there is a single EAP layer that wants only one 
copy of the EAP frame then I believe there are several possibilities 
(all with consequences):
   1.  Add a mux/demux layer to the .1X standard that looks at the EAP 
header and directs only one copy of the frame to the correct .1X state 
machine.  This is a layer violation and any changes to the EAP header 
will require a change to the .1X standard.  I imagine that this will 
slow any changes just due to inter-standards bodies coordination.
   2.  Modify EAPOL to have a field that indicates which component 
generated it (Authenticator or Supplicant) and then add a mux/demux 
layer to the .1X standard that looks at this EAPOL header and directs 
the incoming frame appropriately.  This has backwards compatibility 
problems.  What do we do with a frame from an older version of .1X that 
does not have this field? (look at the EAP header? deliver the frame to 
both .1X machines (and hence deliver two copies to the mux/demux layer 
of EAP))
   3.  Alter the .1X state machines so that there is a single state 
machine that signals to EAP that an EAP frame is available, rather than 
have both .1X machines do this.    This solves the problem in one 
direction -- EAP only gets one copy of the EAP frame and .1X did not 
cause a layer violation.  Unfortunately, the .1X state machines will 
both transition as if an EAP frame had been seen and both will need a 
correct response from both EAP machines.  Since the EAP mux/demux will 
only send the EAP frame to the correct EAP machine there will only be 
one response forthcoming and the .1X/EAP machines will be out of sync.  
If the mux/demux EAP machine when it delivered the frame to one EAP 
machine, at the same time signalled the other .1X machine it would get 
no response (sets eapNoResp for .1X supplicant or sets eapNoReq for the 
.1X authenticator) then I think this may solve the problem without layer 
violations, multiple frame deliveries or backwards compatibilty 
problems.  This doesn't solve the other issue we seem to be discussing: 
both machines running, a mutual authentication EAP method is used 
between two of the machines so there is no need to run the two machines 
in the opposite direction.

As an aside, if there is a single EAP layer, then the control variables 
between the EAP layer and the .1X layer should have different names 
between the supplicant and authenticator (for instance, eapSuccess and 
eapFailure signaled from a single EAP layer is not meaningful since 
there is no context as to which machine is signalling success.  Rather, 
the EAP layer will need to signal eapPeerSuccess or eapAuthSuccess, 
etc.  Again, our assumption of an EAP instance per .1X state machine.

>The authenticator side would also be ignoring Success (3) and Failure (4)
This means that EAP is to be treated as a network layer, rather than a 
functional component that can have multiple instantiations within a 
single network layer.  Hence the requirement that it receive only a 
single stream of frames.
---------------------------------------------------------
With regard to the other issue, namely, if both machines are running in 
a single entity and one of the machines successfully completes a mutual 
authentication method then how can this open the controlled port 
(without the other machine needing to complete successfully or complete 
at all for that matter):
In an attempt to clarify how EAP could control this, I have created a 
picture which attempts to show the variables that control the controlled 
port within the .1X state machine in the case that both machines are active:

********>   This is an inter state-machine signal
----------->   This indicates a data flow

+------------------------------------------------------------------+
|                  Higher Layer (EAP/AAA)                          |
+------------------------------------------------------------------+
   |         *         ^               ^          *             |
   |         *         |               |          *             |
  EAP     eapSuccess   EAP             EAP       eapSuccess    EAP
response  eapFail      request         response  eapFail       request
   |         *         success         |          *            success
   |         *         fail            |          *            fail
   |         *         |               |          *             |
   V         V         |               |          V             V
+----------------------------------+ +----------------------------------+
|      .1X Supplicant              | |    .1X Authenticator             |
|switch (suppControlledPortControl)| |switch(authControlledPortControl) |
|  Force Unauthorized:             | |   Force Unauthorized:            |
|   suppPortStatus = FALSE         | |    authPortStatus = FALSE        |
|  Force Authorized:               | |   Force Authorized:              |
|   suppPortStatus = TRUE          | |    authPortStatus = TRUE         |
|  Auto:                           | |   Auto:                          |
|   suppPortStatus = (eapSuccess   | |    authPortStatus = (eapSuccess  |
|                       &&         | |                        &&        |
|                     portValid)   | |                      portValid)  |
+----------------------------------+ +----------------------------------+
            ^                                      ^
            |                                      |
            +--------------------------------------|
                                                   |
                                                   V
+----------------------------------+ +----------------------------------+
|       .1X Controlled Port        | |     .1X Uncontrolled Port        |
| AuthControlledPortStatus         | |                                  |
|   = portStatus                   | |                                  |
|   = (suppPortStatus &&           | |                                  |
|         authPortStatus)          | |                                  |
+----------------------------------+ +----------------------------------+
             ^                                     ^
             |                                     |
             +-----------------+-------------------+
                               |
                               |
                               V

I have taken a liberty with suppPortStatus and authPortStatus and 
indicated that they are directly set by eapSuccess...actually this is 
not 100% true, eapSuccess indirectly causes the setting of these 
variables, but for simplicity I have indicated as I have.

If the EAP/Higher layer detects that a mutual authentication has taken 
place on one of its machines set the .1X variable for the alternate 
machine (suppControlledPortControl or authControlledPortControl) to 
Force Authorized.  Actually, there may be some issues with this, but 
this is the basic idea: EAP knows it no longer cares about the result 
from the alternate machine and wishes to open the controlled port 
despite that machine's result so it sets a variable forcing the result 
from that machine to TRUE.   These two variables would need to be 
indicated as another inter state-machine variable in appendix F.

This is based on draft 7-2 of .1X.  I just received the draft 8 of 1X in 
my inbox, but want to get this out to folks.
Later,
Jim B.