Chaining system authentication methods

[Michael Lecuyer]

On 1/28/2015 2:13 AM, Arran Cudbard-Bell wrote:
> 
>> On 28 Jan 2015, at 13:25, Sautron Nick <sautronnick at 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 at 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
> 
>