Sponsored development rlm_ldap and ocsp

Kostas Kalevras kkalev at noc.ntua.gr
Wed Aug 25 14:41:19 CEST 2010

  On 25/8/2010 3:32 μμ, John Dennis wrote:
> On 08/25/2010 03:51 AM, Kostas Kalevras wrote:
>> All attribute values could use the syntax "<op> <value>" where<op>  one
>> of =,:=, += etc (it's been a while since i used it though, see
>> ldap_pairget()). So it's probably a good idea to keep them that way.Why
>> would you handle most RADIUS attribute values as UTF-8 instead of plain
> Internally most software is agnostic as to whether string data is 
> ASCII or UTF-8 provided it handles the string as a whole unit and does 
> not try to operate on individual characters or substrings. Not all 
> attributes are appropriate candidates for i18n support, however those 
> which are fundamentally names and descriptions would benefit. For 
> example when I added client (e.g. NAS) support to rlm_ldap it seemed 
> to me the client short name and description should support i18n. For 
> the previously existing attributes in the schema I would imagine 
> things the the GroupName, HuntGroupName, Prompt, UserCategory, 
> ReplyMessage, etc. would be friendlier if you could specify these 
> values in your native language.
> An open question is if internally FreeRADIUS does anything with these 
> values other than copy them and compare them for equality, if that's 
> the only operations then there shouldn't in theory be a problem.  
> However even if there were internal problems with these values being 
> encoded in UTF-8 that is an independent issue from whether the 
> specification of a backend database schema which might be widely 
> deployed should fundamentally prohibit the possibility of storing 
> strings in a native language. Remember that ASCII is a proper subset 
> of UTF-8 so if current practice remains storing only ASCII strings 
> nothing would be affected (other than we've provided one part of the 
> path for any future support of i18n without having to go back and 
> modify your database). Does that make more sense?
RADIUS attributes sent over the wire that are expected to contain a 
UTF-8 value (like Reply-Message) should be set as UTF-8 in the LDAP 
schema. Other attributes which are primarily used by freeradius 
internally (like huntgroupname or groupname) could be set to UTF-8 as 
long as freeradius is able to handle UTF-8 values. Alan could answer on 
the last one better.

Kostas Kalevras
Network Operations Center, NTUA.GR
http://kkalev4economy.wordpress.compname or

More information about the Freeradius-Devel mailing list