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

[Bernard Aboba (aboba]

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

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

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.

> 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

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.

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

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

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

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

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

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.

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

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.