addition to policy.conf
stefan.winter at restena.lu
Mon Jun 4 07:58:08 CEST 2012
>> For an example of how this breaks things, look at all those websites which
>> validate domains to only .com, .net, .org and so on. Now that hundreds of
>> new TLDs are coming along, those sites will all erroneously reject perfectly
>> valid domains. The DNS is a database, so you may as well just query it, and
>> get the additional benefit of rejecting specific non-existent domains.
> the NAI ruleset is quite simple - and DOESNT require any policing of current
> and future domains.... the realm must contain a strong-dot-string minimum. it
> cannot start with a dot , end with a dot, have multiple consecutive dots
> or contain illegal characters (havent even added those rules yet).
Fully agree with Alan here. The NAI is part of an RFC, so there's reason
in creating a ruleset that sanitizes inputs to conformance with that
RFC. As simple as that. FreeRADIUS has many places where it polices
malformedness of various parts of the RADIUS protocol, like whether an
attribute is allowed in a specific datagram or not.
Since using the NAI spec for User-Name is optional, it needs to be
configurable in FreeRADIUS whether to make that syntax check or not. I
believe policy.conf is the perfect place to put these checks into.
NB, of course it is a dumb idea to block TLDs just because one doesn't
like them or doesn't know about them yet. But this has nothing to do
with the NAI compliance checks in this thread.
NB2: Yes, the RFC4282 that contains the NAI spec is broken in some
aspects (most notably, internationalisation). So creating a policy.conf
which goes to great lengths of enforcing the more dubious aspects is not
a good thing - especially given that RFC4282 is going to be revised
soon. But the regex checks in this thread are only doing the basic stuff
anyway, i.e. the parts that will extremely likely survive the RFC revision.
> as a national operator of a federated authentication system which is using RADIUS
> this issue is very close to my own personal interests - and remote sites sending
> junk upstream is the cause of several issues - easily solved if the RADIUS
> servers at all sites could have a simple policy rule to turn on.
> of course, when we move 100% to using tech such as dynamic server discovery
> then end sites will instantly know its a duff realm and we wont be bothered...but
> I'd rather fix the CURRENT problem than wait for some future world.
Many roaming consortia/enterprises use NAIs for their User-Name. Even in
a non-proxy world, there's some resources to be saved: If you do a full
TLS exchange for every incoming request vs. reject nonsense in the first
packet can make a difference for your server if your environment is busy...
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
Tel: +352 424409 1
Fax: +352 422473
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the Freeradius-Devel