\000 in "octets" attribute?
Bjørn Mork
bjorn at mork.no
Thu Jun 15 11:14:35 CEST 2006
Stefan Winter <stefan.winter at restena.lu> writes:
>> I'm having a curious problem with a vendor-specific single-byte
>> "octets"-attribute and attr_rewrite.
>>
>> Essentially, I'm trying to rewrite an ascii "0" to a single-byte 0x00
>> value. But after this rewrite rule, a zero-byte value is returned
>> instead. Any way to get around this?
>>
>> With \001, \002, etc, all's well.
>>
>> (incidentally, this is freeradius version 1.0.1 in RHEL4)
>
> the RADIUS RFC forbids attributes with a terminating \000. The server knows
> that, and will shorten the octet attribute by cutting off the \000 - leaving
> an empty string behind. If your NAS really requires a trailing \000: fix the
> NAS. It is not RFC-compliant then.
RFC 2865 says
"Note that none of the types in RADIUS terminate with a NUL (hex
00). In particular, types "text" and "string" in RADIUS do not
terminate with a NUL (hex 00). The Attribute has a length field
and does not use a terminator. Text contains UTF-8 encoded 10646
[7] characters and String contains 8-bit binary data. Servers and
servers and clients MUST be able to deal with embedded nulls.
RADIUS implementers using C are cautioned not to use strcpy() when
handling strings."
There is nothing here that forbids an attribute containing nothing but
a NUL, or ending in NUL. The point is that the NUL in that case must
be a *significant part* of the attribute value. RADIUS clients and
servers MUST *handle* the NULs, not silently ignore them like string
terminators.
That is: "blah\000" and "blah" have different value and length, but
they are both allowed as attribute values.
In particular, integer attributes will often have 0 as value (just
grep the dictionary VALUEs), which of course ends in 0.
Bjørn
More information about the Freeradius-Users
mailing list