[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue: Treatment of null Identity Response
At 11:30 12/13/2005 -0500, Nelson, David wrote:
>Well, yes, but... RFC 2865 defines the value field of attributes as
>follows:
>
><quote>
>
> The format of the value field is one of five data types. Note
> that type "text" is a subset of type "string".
>
> text 1-253 octets containing ...
> string 1-253 octets containing ...
Long ago, in the previous instance of a RADIUS WG, a similar question was
posted and the WG decision was that attributes with empty value fields
must not be sent (hence, the 1-253 octets limit for text and string).
Back then, some people tried (unsuccessfully) to argue that the presence
of a null valued attribute is different from the absence of such attribute.
In my mind (and apparently, in a few others as well), an absent attribute
should mean "I don't know anything about that attribute" whereas an empty
attribute should mean "the attribute is known and its value is empty"
but that's not what the RFC says.
Appended are some related messages from the old WG mailing list that may
help shed some light on this issue. I don't know if the old mailing list
is archived somewhere (livingston.com went offline a long time ago) but
if there is, google doesn't seem to know about it.
HTH,
-Ignacio
>Date: Wed, 24 Feb 1999 13:26:59 -0800 (PST)
>From: Carl Rigney <cdr@livingston.com>
>Message-Id: <199902242126.NAA29532@server.livingston.com>
>To: ietf-radius@livingston.com
>Subject: (radius) Zero-length strings
>
>Right now there are no zero-length strings in RADIUS, because all the
>definitions require at least an octet of data. People's use of zero
>length attributes disturbs me, because I suspect they're implying
>semantics in such usage that are not documented and therefore non
>interoperable. So I want to pin this discrepancy down by either
>updating the language from "0-253 octets of data" to "1-253 octets" or
>by explicitly describing what to do with a zero length attribute.
>
>The reference implementation (RADIUS 1.13 from Livingston) didn't allow
>zero length attributes; if the protocol is going to be changed to allow
>zero length attributes I want to see really strong justification for
>their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next
>draft's only a couple of days away.
>
>(Its fine to email me directly, or to the list, as you prefer.)
>
>--
>Carl Rigney
>cdr@livingston.com
=======================================
>Date: Wed, 24 Feb 1999 13:36:09 -0800
>From: "Dale E. Reed Jr." <daler@iea-software.com>
>To: Carl Rigney <cdr@livingston.com>
>CC: ietf-radius@livingston.com
>Subject: Re: (radius) Zero-length strings
>References: <199902242126.NAA29532@server.livingston.com>
>
>I'm an advocate of "if there isn't any data, don't include the
>attribute". Therefore, I'd like to see a requirement on all
>attributes of 1-253 octets.
=======================================
>To: "Dale E. Reed Jr." <daler@iea-software.com>
>cc: Carl Rigney <cdr@livingston.com>, ietf-radius@livingston.com,
> rsc@merit.edu
>Subject: Re: (radius) Zero-length strings
>In-reply-to: Your message of "Wed, 24 Feb 1999 13:36:09 PST."
> <36D470C9.106FDAF@iea-software.com>
>Date: Wed, 24 Feb 1999 17:01:01 -0500
>From: "Richard S. Conto" <rsc@merit.edu>
>
>
>I don't like zero length strings (I call them empty strings,
>because people I've worked will have been confused between
>NULL and 0 and ""), but that doesn't mean that an empty string
>isn't valid. It's like the difference between reporting 0 or
>not reporting anything at all (0 vs. missing data.)
>
>At least one vendor uses zero length strings, (in the STATE
>attribute) and as one of the contributors to a well known
>RADIUS implementation, I have to cope with it.
>
>I also have to anticipate RADIUS clients that accept whatever
>a user provides, and that includes empty strings and garbage
>filled strings.
>
>I think that zero-length (empty) strings MUST be allowed,
>especially where the value may be provided by a human being,
>or where the use of the value is left to the vendor (USER-NAME
>and STATE come to mind.) I think so for the pragmatic
>reason that there are implementations using it, and for the
>architectural reason that an empty value is different from a
>missing value.
=======================================
>Date: Wed, 24 Feb 1999 21:56:47 -0800
>From: "Dale E. Reed Jr." <daler@iea-software.com>
>To: "Richard S. Conto" <rsc@merit.edu>
>CC: Carl Rigney <cdr@livingston.com>, ietf-radius@livingston.com
>Subject: Re: (radius) Zero-length strings
>References: <199902242201.RAA21650@merit.edu>
>
>"Richard S. Conto" wrote:
>>
>> I don't like zero length strings (I call them empty strings,
>> because people I've worked will have been confused between
>> NULL and 0 and ""), but that doesn't mean that an empty string
>> isn't valid. It's like the difference between reporting 0 or
>> not reporting anything at all (0 vs. missing data.)
>>
>> At least one vendor uses zero length strings, (in the STATE
>> attribute) and as one of the contributors to a well known
>> RADIUS implementation, I have to cope with it.
>>
>> I also have to anticipate RADIUS clients that accept whatever
>> a user provides, and that includes empty strings and garbage
>> filled strings.
>
>I can't agree with this. What possible usefullness can state
>with an empty contents (AVP length of two) contribute to anything
>and what makes it different than not including it at all? The
>same thing really goes for username. A NAS should reject a
>request immediately is a user hits enter for the username, and
>not even bother with sending the request. Althought the RADIUS
>client is supposed to be simple, its not supposed to be stupid. :(
>
>Because there are broken or current implementations that send
>a AVP length of two, doesn't mean that the RFC has to accept
>or allow it. The purpose of this update that Carl is working
>on is to clarify the implementation rules and clean up problems.
>This is one I brought up over a year ago and am excited about
>getting cleaned up.
>
>> I think that zero-length (empty) strings MUST be allowed,
>> especially where the value may be provided by a human being,
>> or where the use of the value is left to the vendor (USER-NAME
>> and STATE come to mind.) I think so for the pragmatic
>> reason that there are implementations using it, and for the
>> architectural reason that an empty value is different from a
>> missing value.
>
>Whats different from the server making interpreting a missing
>attribute the same as it would interpret an AVP length of two?
>I really don't like (although I can live with it) an AVP
>length of 3 with the single data of 0. I interpret this as
>a blank NULL terminated string (and we all know strings are not
>NULL terminated in RADIUS).
>
>--
>
>Dale E. Reed Jr. Emerald and RadiusNT
>__________________________________________
>IEA Software, Inc. www.iea-software.com
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>