\000 in "octets" attribute?

[Bjørn Mork]

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