I'm getting this debug output when trying to authenticate from an iPad:
Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Peer sent packet with method EAP NAK (3) Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Found mutually acceptable type MSCHAPv2 (26) Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Calling submodule eap_mschapv2 to process data Wed Oct 2 17:57:23 2019 : Debug: (10) eap_mschapv2: Issuing Challenge Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Sending EAP Request (code 1) ID 2 length 43
This is the content of the eap module: eap {
default_eap_type = ttls timer_expire = 60 ignore_unknown_eap_types = no cisco_accounting_username_bug = no max_sessions = ${max_requests} md5 { } leap { } gtc { auth_type = PAP } tls-config tls-common { private_key_file = ${certdir}/deusto.key certificate_file = ${certdir}/deusto.pem dh_file = ${certdir}/dh ca_path = ${cadir} cipher_list = "DEFAULT" cipher_server_preference = no ecdh_curve = "prime256v1" cache { enable = no } verify { } ocsp { enable = no override_cert_url = yes url = "http://127.0.0.1/ocsp/" } } tls { tls = tls-common } ttls { tls = tls-common default_eap_type = pap copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" } peap { tls = tls-common default_eap_type = gtc copy_request_to_tunnel = no use_tunneled_reply = no virtual_server = "inner-tunnel" } mschapv2 { } }
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2 Is this a normal outcome? Why iOS doesn't try PAP? Having a User-Password attribute doesn't serve as a hint for the server when looking for a mutually acceptable type? Regards, Alberto
hi,
Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Peer sent packet with method EAP NAK (3)
client didnt like what was offered
Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Found mutually acceptable type MSCHAPv2 (26) Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Calling submodule eap_mschapv2
but was happy to do eap_mschapv2 given your default peap method is gtc, that was what probably caused the NAK in the tiny snippet of logs you provided
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2
Is this a normal outcome? Why iOS doesn't try PAP?
because 'clients' - was this client configured by a profile or was it configured by hand or was it configured by just trying to join the SSID?
Having a User-Password attribute doesn't serve as a hint for the server when looking for a mutually acceptable type?
it could do - but you havent provided any config or full debug output so i couldnt say how your server is configured. alan
Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Peer sent packet with method EAP NAK (3)
client didnt like what was offered
Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Found mutually acceptable type MSCHAPv2 (26) Wed Oct 2 17:57:23 2019 : Debug: (10) eap: Calling submodule eap_mschapv2
but was happy to do eap_mschapv2
So... how can I make the client like the offering and try TTLS-PAP?
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2
Is this a normal outcome? Why iOS doesn't try PAP?
because 'clients' - was this client configured by a profile or was it configured by hand or was it configured by just trying to join the SSID?
Just by trying to join the SSID. There is not a chance for configuring by hand in iOS. I'll post a full debug later.
On Oct 2, 2019, at 12:16 PM, Alberto Martínez Setién via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
I'm getting this debug output when trying to authenticate from an iPad:
That's fine.
This is the content of the eap module:
That's not really relevant. Also, the documentation says "don't post config files to the list". We don't need to see them, they don't help.
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2
Why?
Is this a normal outcome?
Yes. Plenty of clients do TTLS + MS-CHAPv2.
Why iOS doesn't try PAP?
Because it wasn't configured to to PAP. No amount of poking FreeRADIUS will change the configuration on the iPad. You MUST change the iPad configuration on the iPad.
Having a User-Password attribute doesn't serve as a hint for the server when looking for a mutually acceptable type?
How would that work? There''s not User-Password from the client in the inner tunnel data. The server never sends a User-Password to the client. EAP just doesn't do "I hope it works like I want". EAP works the way it works. If you want to understand why it's *not* doing what you want, you have to first understand how it works. In this case, if you want the client to do TTLS + PAP, then you need to configure the client to do TTLS + PAP. Alan DeKok.
Pretty much standard. I expect TTLS + PAP, not MSCHAPv2
Why?
I thought that default_eap_type worked that way # Loaded module rlm_eap
# Loading module "eap" from file /usr/local/freeradius-3.0.17/etc/raddb/mods-enabled/eap eap { default_eap_type = "ttls"
Is this a normal outcome?
Yes. Plenty of clients do TTLS + MS-CHAPv2.
Does iOS prefer doing TTLS + MS-CHAPv2 over TTLS-PAP? There is no way of letting it know the preferred method without the use of a WiFi profile?
Why iOS doesn't try PAP?
Because it wasn't configured to to PAP. No amount of poking FreeRADIUS will change the configuration on the iPad. You MUST change the iPad configuration on the iPad.
I believe that this is an answer to my question before. But is it really so? Does the iPad always do TTLS+MSCHAPv2 when trying to connect to an unconfigured 802.1x network?
Having a User-Password attribute doesn't serve as a hint for the server when looking for a mutually acceptable type?
How would that work? There''s not User-Password from the client in the inner tunnel data. The server never sends a User-Password to the client.
Your are right, sorry. The client doesn't send the User-Password in the inner tunnel before deciding the inner-tunnel auth method.
On Oct 3, 2019, at 5:45 AM, Alberto Martínez Setién <alberto.martinez@deusto.es> wrote:
I thought that default_eap_type worked that way
No, it works the way it's documented to work. The default_eap_type is what the server *suggests* that the client use. If you read the debug output, you would see that the client sends a NAK to that request, and instead asks for a different EAP type. But even then, default_eap_type applies to *EAP*. It doesn't apply to PAP or MSCHAPv2.
Does iOS prefer doing TTLS + MS-CHAPv2 over TTLS-PAP?
Generally, yes. Why? Ask Apple. We didn't write iOS.
There is no way of letting it know the preferred method without the use of a WiFi profile?
Generally, no. Why? Ask Apple. We didn't write iOS.
I believe that this is an answer to my question before. But is it really so? Does the iPad always do TTLS+MSCHAPv2 when trying to connect to an unconfigured 802.1x network?
Why are you asking us that question? We didn't write iOS. Alan DeKok.
On 3 Oct 2019, at 07:04, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 3, 2019, at 5:45 AM, Alberto Martínez Setién <alberto.martinez@deusto.es> wrote:
I thought that default_eap_type worked that way
No, it works the way it's documented to work. The default_eap_type is what the server *suggests* that the client use.
If you read the debug output, you would see that the client sends a NAK to that request, and instead asks for a different EAP type.
But even then, default_eap_type applies to *EAP*. It doesn't apply to PAP or MSCHAPv2.
Does iOS prefer doing TTLS + MS-CHAPv2 over TTLS-PAP?
Generally, yes. Why? Ask Apple. We didn't write iOS.
There is no way of letting it know the preferred method without the use of a WiFi profile?
Generally, no. Why? Ask Apple. We didn't write iOS.
I believe that this is an answer to my question before. But is it really so? Does the iPad always do TTLS+MSCHAPv2 when trying to connect to an unconfigured 802.1x network?
Why are you asking us that question? We didn't write iOS.
If it's EAP-MSCHAPv2 then it's using it because it provides a negotiation mechanism. i.e. the supplicant and server can negotiate an inner tunnel method, so it's the most broadly compatible way of running EAP-TTLS. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Oct 4, 2019, at 5:25 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Oct 4, 2019, at 4:33 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
If it's EAP-MSCHAPv2 then it's using it because it provides a negotiation mechanism.
Only if the supplicant starts doing EAP.
Yeah that was exactly my point. If it's doing EAP-MSCHAPv2, then it's doing it to allow EAP negotiation. -Arran
FYI: https://serverfault.com/a/693040/218902 *iOS clients* won’t support EAP-TTLS with PAP (only MsCHAPv2) unless you
manually (via a computer) install a profile.
participants (4)
-
Alan Buxey -
Alan DeKok -
Alberto Martínez Setién -
Arran Cudbard-Bell