Chaining system authentication methods

Michael Lecuyer mjl at
Wed Jan 28 08:27:23 CET 2015

On 1/28/2015 2:13 AM, Arran Cudbard-Bell wrote:
>> On 28 Jan 2015, at 13:25, Sautron Nick <sautronnick at> 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 at>
> FreeRADIUS development team
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
> -
> List info/subscribe/unsubscribe? See

More information about the Freeradius-Users mailing list