Chaining system authentication methods

[Arran Cudbard-Bell]

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

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

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

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