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

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 2 Dec 2003 20:22:44 -0800

Hope everyone had a joyous thanksgiving holiday. 
 
To clarify, Issue 204 was filed against the EAP State Machine document in order to address a problem in the EAP authenticator state machine pointed out in the resolution of Comment 15 on the IEEE 802.1aa D7.1 ballot. The EAP issues list is available here:
http://www.drizzle.com/~aboba/EAP/eapissues.html
 
The EAP WG discussion of Issue 204 is available starting here:
http://mail.frascone.com/pipermail/public/eap/2003-November/001896.html
 
The resolution to Issue 15 pointed out an asymmetry in the operation of a pass-through authenticator and a non-passthrough authenticator with respect to peer-to-peer operation.  Since in EAP the two cases are supposed to behave identically with respect to the on-the-wire protocol, this is believed to represent a bug in the operation of the authenticator state machine, as well as a potential difficiency in AAA, which may require the definition of a new attribute.  
 
A proposed fix to the EAP authenticator SM which would also affect the 802.1X/EAP state machine interface, is available here:
http://mail.frascone.com/pipermail/public/eap/2003-November/001915.html
 
RFC 2284bis sections 2.3 and 2.4 were posted to the list for reference purposes, since they discuss the authenticator pass-through model and peer-to-peer operation in general, even they do not discuss the authenticator state machine or the proposed fixes to it. The entire text of RFC 2284bis-07 (which has now completed IETF last call) is available for inspection here:
 
http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-07.txt

---

From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 3 Dec 2003 17:21:05 -0500

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Bernard Aboba
> Sent: Wednesday, December 03, 2003 7:40 AM
> To: Nick Petroni
> Cc: CONGDON,PAUL (HP-Roseville,ex1); [email-masked]; 
> [email-masked]
> 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.
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Mon, 8 Dec 2003 17:42:19 +0200

Jim Burns wrote:
>
> 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?

The current versions of EAP state machines don't mind if all EAP
frames are delivered to both state machines. The EAP Peer state
machine ignores all EAP Responses (by setting eapNoResp to TRUE), 
and EAP Authenticator state machine ignores EAP Requests, Successes
and Failure (by setting eapNoReq to TRUE).

Adding a "EAP demultiplexing layer" somewhere might be more
elegant than delivering the frames twice, but personally I could 
live with the current approach (especially since these state 
machines specify only externally visible behavior, not 
implementation).

Best regards,
Pasi

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 08 Dec 2003 15:12:09 -0800

>machines specify only externally visible behavior, not

Exactly.  The state machines don't require that an implementation process 
every packet twice.

_________________________________________________________________
Wonder if the latest virus has gotten to your computer? Find out. Run the 
FREE McAfee online computer scan! 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963