On 1/28/2015 2:13 AM, Arran Cudbard-Bell wrote:
On 28 Jan 2015, at 13:25, Sautron Nick <sautronnick@yahoo.fr> wrote:
Hello everyone,
I wonder if it is possible to establish a chaining system authentication methods. In my case I would need to have the peap method first and then the TTLS method.
Your example doesn't show method chaining. It shows method negotiation which is a fundamental part of the EAP protocol.
EAP method is possible, but not supported by FreeRADIUS or by many (any?) supplicants.
example: - An unauthenticated client - The server offers to the method peap - The method is not compatible according to the customer - The server offers to the TTLS method - Authenticated Client
Yes, thats how EAP negotiation works currently, but I believe the supplicant sends back the method it wants to continue with after the initial offer by the server.
The default method the server offers, is configurable in the EAP module.
The EAP negotiation for the EAP method is driven by the client sending a list of EAP methods in the ClientHello TLS message. The server chooses one based on policy and responds with the most secure one (hopefully) in the ServerHello TLS message. In a tie for most secure it likely takes the first one the client offered. So the client is at least suggesting EAP-TTLS then EAP-PEAP. It's likely a TLS configuration problem somewhere. Why does the customer care if both work?
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team
FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html