Hi,
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... Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473