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

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

Clearly I didn't articulate scenario D very well, and I was never assuming
there was a pass-thru supplicant.  I always assumed that if there were a
supplicant component configured and running, the EAP conversation was
terminated locally there, so thus the knowledge of whether the
authentication was mutual and included protected indications was well known
on the supplicant.

So, scenario D was trying to describe the following case (and yes, the
AP<->Switch example is a good one):


    -------------             -------------
-------------------------
    |           |             |           |           |
|
    | pass-thru |             | pass-thru |           | authentication
server |
    |   <AP>    |             | <switch>  |           |
|  
    -------------             -------------
-------------------------
           |                      |    |                          |
           ------------------------    ----------------------------

Both of these devices share the same authentication server.  Since both are
running both authenticator and supplicant, the AP's authenticator obviously
can't complete until the switch has opened its controlled port.  So the AP
supplicant would authenticate to the switch authenticator who could talk to
the AS, then the AP authenticator would authenticate the switch supplicant,
but since the switch has the new variable enabled, this doesn't prevent the
controlled port from being opened.  

Hope this makes sense...

Paul

> -----Original Message-----
> From: owner-stds-802-1 [at] majordomo.ieee.org 
> [mailto:owner-stds-802-1 [at] majordomo.ieee.org] On Behalf Of 
> Bernard Aboba
> Sent: Wednesday, December 03, 2003 7:40 AM
> To: Nick Petroni
> Cc: CONGDON,PAUL (HP-Roseville,ex1); eap [at] frascone.com; 
> stds-802-1 [at] ieee.org
> Subject: [802.1] RE: [eap] Issue 204: Peer-to-peer operation
> 
> 
> 
> > 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.
>