Chaining system authentication methods
mjl at iterpacis.org
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 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?)
>> - 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
More information about the Freeradius-Users