But why

classic Classic list List threaded Threaded
10 messages Options
| Threaded
Open this post in threaded view
|

But why

Users mailing list
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

Alan Buxey
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
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

Alan DeKok-2
In reply to this post by Users mailing list
On Oct 2, 2019, at 12:16 PM, Alberto Martínez Setién via Freeradius-Users <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

Users mailing list
In reply to this post by Alan Buxey
> > > 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

Users mailing list
In reply to this post by Alan DeKok-2
> > 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.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

Alan DeKok-2
On Oct 3, 2019, at 5:45 AM, Alberto Martínez Setién <[hidden email]> 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.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

arr2036


> On 3 Oct 2019, at 07:04, Alan DeKok <[hidden email]> wrote:
>
> On Oct 3, 2019, at 5:45 AM, Alberto Martínez Setién <[hidden email]> 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 <[hidden email]>
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
| Threaded
Open this post in threaded view
|

Re: But why

Alan DeKok-2
On Oct 4, 2019, at 4:33 PM, Arran Cudbard-Bell <[hidden email]> wrote:
>
> If it's EAP-MSCHAPv2 then it's using it because it provides a negotiation mechanism.

  Only if the supplicant starts doing EAP.  There's no way to negotiate EAP vs PAP vs CHAP vs MS-CHAP.

  Alan DeKok.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
| Threaded
Open this post in threaded view
|

Re: But why

arr2036


> On Oct 4, 2019, at 5:25 PM, Alan DeKok <[hidden email]> wrote:
>
> On Oct 4, 2019, at 4:33 PM, Arran Cudbard-Bell <[hidden email]> 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


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

signature.asc (849 bytes) Download Attachment
| Threaded
Open this post in threaded view
|

Re: But why

Users mailing list
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.
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html