Skip to Content.
Sympa Menu

cat-users - Re: [[cat-users]] CAT installer broken on TTLS PAP

cat-users AT lists.geant.org

Subject: The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

List archive

Re: [[cat-users]] CAT installer broken on TTLS PAP


Chronological Thread 
  • From: Tomasz Wolniewicz <twoln AT umk.pl>
  • To: Zenon Mousmoulas <zmousm AT noc.grnet.gr>, Stefan Winter <stefan.winter AT restena.lu>
  • Cc: cat-users AT lists.geant.org
  • Subject: Re: [[cat-users]] CAT installer broken on TTLS PAP
  • Date: Wed, 24 Oct 2018 10:47:42 +0200
  • Openpgp: preference=signencrypt

These checks are for user input therefore for the inner identity - this
is the only thing that the user needs to provide to the installer. Inner
identity may have implication for routing in the case of Windows PEAP,
since Windows automatically uses the realm from inner identity and you
cannot override that. How far we gow with the checks depends on what the
admin sets in the options but also when no options are set we try to
filter things that look like complete nonsense and may be a result uf
user mistyping the username string.

The files are __validate_user_name in linux/Files/main.py (the change
not yet pushed to git) and validateUsername in ms/Files/common.inc

Tomasz



W dniu 24.10.2018 o 08:47, Zenon Mousmoulas pisze:
> Hi,
>
> I don't know how these checks work exactly -- perhaps you could point to
> the code so we can have a better understanding.
>
> However is it correct to say these checks should only work against the
> username that is used for routing? Os is it the case that it doesn't know
> if anonymous outer identity is enabled at the point this happens?
>
> Regards,
> Z.
>
> October 24, 2018 9:38 AM, "Tomasz Wolniewicz" <twoln AT umk.pl> wrote:
>
>> I have also removed the check form the Linux installer.
>> Tomasz
>>
>> W dniu 23.10.2018 o 16:25, Stefan Winter pisze:
>>
>>> Hi,
>>>
>>>> So indeed the installer has a problem. We did not think of a situation
>>>> where an IdP would be using inner identifiers like user@staff
>>>> We have been asked many times to add some identifier checks and we have
>>>> two new options on that - the admins now can test if the realm in user's
>>>> identifier matches the realm provided in the configuration or even
>>>> prefill the username field with "@realm". With no options set, we still
>>>> run some basic checks like multiple @ signs or a dot immediately after @
>>>> or no dot in the realm part. This last test causes the error in Paolo's
>>>> case. It looks like we have no choice but to drop this one test as it
>>>> may be doing more harm than good.
>>> Just for the sake of making an argument, I'd like to point out that
>>> something@staff is not a valid user identifier in the sense of the
>>> IETF's "Network Access Identifier (NAI)" RFC. Nor is something with two
>>> @@ signs in it or an @. .
>>>
>>> If this kind of identifier is used /without/ enabling outer identity
>>> with a correct NAI, it leads to actual breakage when roaming. I'm
>>> assuming that this IdP has thus turned on outer identities, making this
>>> internal use "okay".
>>>
>>> So, I think in general we have a point in testing for these conditions.
>>> But since reality shows us that these identifiers are in actual
>>> deployment, and our sense for standards-correctness is getting in the
>>> way of real deployments, I'm okay with removing the check.
>>>
>>> Greetings,
>>>
>>> Stefan
>> --
>> Tomasz Wolniewicz
>> twoln AT umk.pl http://www.home.umk.pl/~twoln
>>
>> Uczelniane Centrum Informatyczne Information&Communication Technology
>> Centre
>> Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University,
>> pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland
>> tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576

--
Tomasz Wolniewicz
twoln AT umk.pl http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika Nicolaus Copernicus University,
pl. Rapackiego 1, Torun pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750 fax: +48-56-622-1850 tel kom.: +48-693-032-576


Attachment: smime.p7s
Description: Kryptograficzna sygnatura S/MIME




Archive powered by MHonArc 2.6.19.

Top of Page