Chaining system authentication methods

Arran Cudbard-Bell a.cudbardb at
Wed Jan 28 09:02:23 CET 2015

> On 28 Jan 2015, at 14:27, Michael Lecuyer <mjl at> wrote:
> 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.

Hm, actually, RFC 3748 says

   An EAP conversation MAY utilize a sequence of methods.  A common
   example of this is an Identity request followed by a single EAP
   authentication method such as an MD5-Challenge.  However, the peer
   and authenticator MUST utilize only one authentication method (Type 4
   or greater) within an EAP conversation, after which the authenticator
   MUST send a Success or Failure packet.

I guess it's not supported by the base protocol. Maybe I read about it in
the context of a specific EAP method.

>>> 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.

No, you're wrong.

Read RFC3748 which describes how the base EAP protocol works.

> 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?

No, you're talking about TLS negotiation not EAP negotiation. Different protocol.


Arran Cudbard-Bell <a.cudbardb at>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

More information about the Freeradius-Users mailing list