Subject: [eap] EAP multiplexor issues

From: [email-masked] (John Vollbrecht)
Date: Tue, 24 Sep 2002 09:31:25 -0400

Here are three issues for the EAP group.  I hope this is an appropriate
way to add them to the issues list.

Issue A -
In 2284bis-05 the Identity type is treated as a special method.  I think
it is just another method, and while it may be required in some
applications, it should not be special in the EAP spec.

I would like references to it as a unique method removed.  It can be
used as an example in sequencing methods.

Issue B -
Where and when Success and Failure messages are created and sent is not
clear.  I think that Success and Failure messages should be generated by
the EAP Mux, not by individual methods.  The alternative is to have
methods send and EAP mux receive, but then all methods would need to
send, and chaining methods might be difficult.

This should be clarified so implementations of methods can work
together.

Issue C- 
If the authenticator starts an  EAP method but doesn't complete the
whole method sequence, how does the client indicate that it is not
finished?  

In this case the client EAP mux has been happily passing EAP messages to
the appropriate method, then gets a different EAP type.  If it is going
to complain it needs to know that the prior EAP method is not complete. 
This implies some signalling between the EAP method and the EAP Mux.

The interactions between the mux and methods needs to be spelled out
more.  This may not be a protocol, but is part of what is required to
understand what the protocol needs to support.

---

From: [email-masked] (Jacques Caron)
Date: Tue, 24 Sep 2002 15:45:17 +0200

Hi,

I agree with the two issues below (I have to go back and read the latest 
draft to understand what you're talking about in the first issue...), and I 
think they could be at least partially solved by defining an EAP method API 
(which would also help development of EAP methods and encapsulations 
independently), both on the authenticator and on the supplicant sides.

Right now, the only published API for EAP methods is Microsoft's, and I 
personally don't find it very clear :-( Also, it mixes both supplicant and 
authenticator auth in a single API, which doesn't help, and it makes some 
assumptions which I believe won't be true in the future (like having one 
single method, and that method picking the way the identity is provided, 
for instance.

In the implementation I'm working on, on the authenticator (RADIUS server) 
side, it's indeed the main EAP engine that decides when to send 
Access-Accept/EAP-Success or Access-Reject/EAP-Failure, based on response 
from the EAP method, not the EAP method itself. Haven't tried it with 
multiple methods chained yet (though it is definitely the intent), but I 
suspect it definitely won't work with XP's client, as there is no way I 
know of to have multiple client methods used there :-(

Jacques.

At 15:31 24/09/2002, John Vollbrecht wrote:
>_______________________________________________
>eap mailing list
>[email-masked]
>http://mail.frascone.com/mailman/listinfo/eap

-- Jacques Caron, IP Sector Technologies
    Join the discussion on public WLAN open global roaming:
    http://lists.ipsector.com/listinfo/openroaming