Chaining system authentication methods
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. 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 Thank you to enlighten me about it S.Nick
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.
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. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
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.
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@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
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
Thanks you So in my case, in eap.conf file I put the default peap method, and I also configures the TTLS method? the customer can use the method peap and TTLS too ? Le Mercredi 28 janvier 2015 11h13, Arran Cudbard-Bell <a.cudbardb@freeradius.org> a écrit :
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.
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. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Thanks you so much S.Nick Le Mercredi 28 janvier 2015 12h44, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> a écrit :
Thanks you So in my case, in eap.conf file I put the default peap method, and I >also configures the TTLS method?
the customer can use the method peap >and TTLS too ?
Yep... and others too. We do this to support widest range of clients. Alan
Hi, with basic config this can be done. eg ensure eap config has peap as the default , server will offer that. The client will NAK , if the server is also configured for ttls then it will offer that (next, if it's the next available configured method) client then authenticated. Alan
participants (4)
-
Alan Buxey -
Arran Cudbard-Bell -
Michael Lecuyer -
Sautron Nick