\000 in "octets" attribute?

[Erik Bolsø]

On 2006-06-15 11:09, Stefan Winter <stefan.winter at restena.lu> wrote:
> > Essentially, the vendor-specific attribute value is a 1-byte
> > unsigned
> > integer, not a string. Haven't done a live test yet, so I do not
> > know
> > how it handles the empty value. Perhaps all goes well. I'll let you
> > know.
> 
> Then you are supposed to use the "integer" type, not "octets" (then,
> you don't
> even have to jump through hoops to achieve a "0": just use the integer
> 0, no
> need for \000). 

But the radius integer type is a 4-byte value, which is three bytes too
long. I've tested that, it doesn't work.

> > My rfc-reading seems to contradict you a little bit, though?
> 
> No. I read this section quite a few times. octets is another word for
> string,
> i.e. treat what is in there as undistinguished octets (as opposed to:
> treat
> it as an integer). And that's why the section of RFC 2869 is perfectly
> right:
> you wanted to send a string that has a \000 (= hex 00, = NUL) as last 
> character. And that's forbidden:

Nothing forbidding a NUL here... "servers and clients MUST be able to
deal with embedded nulls". A 1-byte string containing just \000 seems
perfectly valid to me.

> > RFC2869 section 5:
> > 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
> > [8] 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.