addition to policy.conf

alan buxey A.L.M.Buxey at lboro.ac.uk
Sun Jun 3 23:03:52 CEST 2012


Hi,

> I think your ruleset is more or less equivalent to:
> 
> User-Name =~ /^[^@]*$| |@.*@|\\.\\.|@[^.]*$|\\.$|@\\./    --> invalid

yes - but as I said in previous email, it might be better to have each
rule as a seperate entity so that sites/systems that allow certain things
could edit/comment a single rule out - having one single REGEX means that
the admin would have to 'play around' with the regex - resulting, probably,
with a big mess (many admins have little skills these days it seems :-( )

> But I don't really see the point. Why not simply proxy it to the
> authoritative server, and let that server reply that it's invalid?  Why
> distribute policy about which realms may (or may not) be valid all over the
> place?  Such policy, if it is ever wrong, is likely to lead to
> difficult-to-debug problems.

the reason for doing it is because otherwise all the junk floats to the top -
the end sites proxy to the next tier, who then proxy up until finally the top
heirarchy are swamped with junk.....spending their time dealing with rejecting
(and logs filling with junk rather than the more interesting issues) - RADIUS
protocol is weak....whilst the proxy chain waits for the reject to come back
through its length, its using up precious limited state in the RADIUS proxy.

> 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). 

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.

alan


More information about the Freeradius-Devel mailing list