On 28 Jan 2015, at 14:27, Michael Lecuyer <mjl@iterpacis.org> wrote:
On 1/28/2015 2:13 AM, Arran Cudbard-Bell wrote:
On 28 Jan 2015, at 13:25, Sautron Nick <sautronnick@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@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2