Subject: (radius) Zero-length strings

From: Carl Rigney <[email-masked]>
Date: Wed, 24 Feb 1999 13:26:59 -0800 (PST)

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
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Wed, 24 Feb 1999 13:36:09 -0800

> (Its fine to email me directly, or to the list, as you prefer.)

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.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Richard S. Conto" <[email-masked]>
Date: Wed, 24 Feb 1999 17:01:01 -0500

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.

===============================================================
> originally from: "Dale E. Reed Jr." <[email-masked]>
> originally to:   Carl Rigney <[email-masked]>
> originally cc: [email-masked]
> subject: Re: (radius) Zero-length strings
> date: Wed, 24 Feb 1999 13:36:09 -0800
> --------
>Carl Rigney wrote:
>> 

-

---

From: Glen Zorn <[email-masked]>
Date: Wed, 24 Feb 1999 15:09:25 -0800 (PST)

> attributes of 1-253 octets.

Ditto.

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 00:21:38 -0500 (EST)

> by explicitly describing what to do with a zero length attribute.

I strongly prefer allowing 0 length attributes, mostly because I see no
valid reason to exclude it and because I have seen other unrelated
protocols exhibit strange behavior because of similar restrictions.  (E.g.
Sybase's SQL server has to store zero-length strings as a single space.)

I would like to see the following semantics defined:

Attribute not included:
	attribute is not relevant, and any default behavior shoul be used.

Attribute included, length field=2:
	integer/date types: not permitted, or possibly a shorthand for 0
	string types: a zero-length string

Attribute included, 0 value:
	Set the attribute to 0.  *Not* just use the default on the client
or whatever.  That should be implied by absense of the attribute, not some
hacked in value.

I would encourage allowing zero-length strings in many standard
attributes:
	User-Name, to indicate we want to authenticate "" (as in the
person pressed Enter when prompted for username).
	Class, to cause the NAS to pass an empty string back in
accounting.
	State, to cause an empty State to be passed back by the server to
the client.

The problem with all of this is that it does not document the way vendors
currently use it, and it would not be interoperable with the broken things
they currently do.  If it comes down to disallowing zero-length attributes
or allowing them and making them simply meaningless place-holders, I would
have to vote to disallow them.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net, An ISP with Excellence in the Greater Boston Area.

-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Wed, 24 Feb 1999 21:56:47 -0800

> a user provides, and that includes empty strings and garbage

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.

> architectural reason that an empty value is different from a

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).

--

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Wed, 24 Feb 1999 22:22:58 -0800

> Sybase's SQL server has to store zero-length strings as a single space.)

Thats a sybase thing.  MS SQL 7 finally fixed that totaly annoying
"bug" and allows zero Length Strings for a varchar.  But comparing a
fixed number of fields database (where the field has to be there 
regardless if you set it to anything or not) to a dynamic field
protocol like RADIUS isn't fair.
 
>         string types: a zero-length string

I don't see the relevance for either.  My gripe about this is that we
want to keep the protocol clean and fast.  Putting a whole bunch of
meaningless attributes in just clutters things up.  I mean this whole
semantic thing would be required to complicate things is it simply
wasn't allowed.  
 
> or whatever.  That should be implied by absense of the attribute, not some

This is a per-attribute issue of how to interpret the value, and doesn't
need to be addressed globally.
 
> person pressed Enter when prompted for username).

The NAS shouldn't send a request in that case (it should just re-prompt
or eventually dump the user).  If you are talking Caller-ID auth, thats
a different story.

>         Class, to cause the NAS to pass an empty string back in

Which is just more waste of processing and accomplished nothing?

>         State, to cause an empty State to be passed back by the server to

Same as above.
 
> have to vote to disallow them.

IMHO, forcing broken implementations to get fixed is a GOOD thing. 
Adding
the ability for something to be interpreted many different ways is a bad
thing.

--

---

From: Bob Natale <[email-masked]>
Date: Thu, 25 Feb 1999 01:33:51 -0500

>At 2/25/99:01:22 AM, Dale E. Reed Jr. wrote:

Hi Dale,

<...>
>Adding the ability for something to be interpreted many different
>ways is a bad thing.

Yes, I agree.  This kind of guidance needs to be added to the
IETF "way"...on a par with the older wisdom such as "Be liberal
in what you accept and conservative in what you send" (paraphrased).

Backwards compatibility has its place, and its limits.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 06:51:06 -0500 (EST)

> semantic thing would be required to complicate things is it simply

Perhaps, but I mean to suggest that it not be a special case.  A
zero-length string is a well defined object that might be useful and is
well behaved wrt the common operations that a radius server would be
performing (logging it, string comparisons, and so forth).  The values of
mant attributes ought to be considered as undistinguished octets, in which
case a zero-length values is just as much a black box as a 13-length one
or a 4-length one.

> or eventually dump the user).

Why?  What if I want that to be a valid guest login?  That should not be
something unnaturally restricted at the protocol level.

> Which is just more waste of processing and accomplished nothing?

No, to the client and the protocol it is a black box, and who is to say
what it might mean to the server.

> >         State, to cause an empty State to be passed back by the server to
Agreed, they are the same.

-

---

From: "Richard S. Conto" <[email-masked]>
Date: Thu, 25 Feb 1999 10:55:52 -0500

> date: Wed, 24 Feb 1999 21:56:47 -0800
> --------
...
>client is supposed to be simple, its not supposed to be stupid. :(

I can suggest several reasons, such as being used as a placeholder,
or to be part of some more complicated, multi-pass authentication
policy enforced by the NAS. 

And I don't think a NAS should immediately reject a zero (empty)
USER-NAME. That's a policy that should be determined by the
service provider, and should be entirely be between the service
provider and the user. Perhaps CALLING-STATION-ID would sufficiently
identify the user (as far as the service-provider is concerned), or
the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT.

>This is one I brought up over a year ago and am excited about 

I think you need to justify why an empty string should be explicitly
disallowed. An empty string (in most cases) is no different than
any other invalid value, such as a mal-formed FRAMED-ROUTE. If the
RADIUS server wants to disallow it, that's fine. 
...

>NULL terminated in RADIUS).

Missing data really is different than default (or zero) data.
And making a special case that an empty string should be
represented as a one octet string with the value '\0' goes
contrary to the spirit of your previous arguments against
special cases (and only makes sense to a programmer who
things that C-strings are undistinguished octets.)

-

---

From: MARC DE VRIES WE41/KT <[email-masked]>
Date: Thu, 25 Feb 1999 18:58:08 +0200 (MET-DST)

>by explicitly describing what to do with a zero length attribute.

Changing the 0-253 to 1-253 will not allow future extension to use zero-length
attributes.
Including text saying zero-length attribs should/must be ignored or smth would
also limit future extensions.

Currently, zero-length attributes are possible, but none of the standard
attributes can be zero-length (len >=3).

Including something similar to the above statement _is_ something I think most
people can live with? (does not change a thing, only clarifies)

>draft's only a couple of days away.

I may have missed it, but I doubt the RFC states that Livingston RADIUS 1.13 is
to be used as a reference. 
No matter what history is tied to it, a standard protocol should/must not refer
to any particalur vendor implementation, and certainly not one that has already
been outdated by that same standard.

Many vendors use zero-length strings. It is irrelevant whether or not this
breaks Livingston RADIUS or any other implementation. What is relevant is that
it does not conform to the standard as it is today. 

Implementaions that do conform to the current RFC, must not use zero-length
strings in the listed attributes, and will be interoperable wrt this issue. So
(IMHO), except for some clarifying statement, I do not think any changes to the
RFC are required for this.

regards,

Marc.

-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Thu, 25 Feb 1999 12:56:28 -0800

> policy enforced by the NAS.

Can someone come up with a clear reason why having an AVP length
of two is ANY diffrent than not including the attribute?  Thats
all I'm trying to get at.  I will not accept the definition of a
default, because a default is an ambiguity that we are trying
to avoid and should be a defined value for the attribute, not
an empty string.  I'm very accepting of a reason, but I don't 
like "just because".
 
> the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT.

I agree that this is a NAS configuration issue.  Do you allow 
blank passwords as well?
 
> RADIUS server wants to disallow it, that's fine.

Because I think an empty string is the same as not sending the 
attribute.  An invalid value is NOT the same as not including
a value at all.
 
> Missing data really is different than default (or zero) data.

This is dependant on the implementation.  

For example, if I don't send a Framed-Address to a client, 
most will assign an address.  Is that considered the default?  
What will happen if I send an AVP length of two for a Framed-Address?  
I think missing data in most cases tells the NAS to use the default.

For a server, if we receive a NAS-Port-Type with an AVP length
of 2, is that considered an Async call?  There is no default and 
the attribute should never have been sent in the first place.

> things that C-strings are undistinguished octets.)

I wasn't making a special case.  I was just saying that I
could live with an avp length of three with some "blank" single
octet (regardless what it was) but I don't like an AVP len of
two.

--

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Thu, 25 Feb 1999 13:05:46 -0800

> Changing the 0-253 to 1-253 will not allow future extension to use zero-length

RADIUS is based on Attribute-Value pairs.  Now we are trying to say
its ok to remove the Value from AVP?  An attribute that doesn't have
atleast two values, doesn't really qualify for an attribute, IMHO.
An attribute must have atleast two possible values, and as a result
not sending a value introduces ambiguity in the interpretation.

> also limit future extensions.

This is only for the standard attributes.  Vendor Specific attributes
are
not limited by this.
 
> attributes can be zero-length (len >=3).

That isn't a consensus, and many vendors today don't follow that (the
second
part).
 
> people can live with? (does not change a thing, only clarifies)

At the minimum, I would like to see that clairified.
 
> it does not conform to the standard as it is today.

I agree with this.
 
> RFC are required for this.

Can anyone come up with an attribute were an AVP len of two is useful?

--

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 16:12:10 -0500 (EST)

> I agree that this is a NAS configuration issue.  Do you allow 

I imagine a blank username would have a blank password to go with it.

> the attribute should never have been sent in the first place.

I wouldn't think AVP length 2 would be allowed for either of these
examples.

> octet (regardless what it was) but I don't like an AVP len of

But an AVP length of 2 is the natural way to specify an octet array of
length 0, and one of length 3 with a special character is the natural way
to denote a single octet with that value.  I realize that you are not
recommending your proposal, but I can't see why you would prefer it over
allowing the natural denotion of a zero length octet array.

-- 
Steven P. Crain, Development
http://www.shore.net/~scrain
Shore.Net: Local Ties... World Class Connections

-

---

From: "Steven P. Crain" <[email-masked]>
Date: Thu, 25 Feb 1999 16:25:13 -0500 (EST)

> not sending a value introduces ambiguity in the interpretation.

If sending a zero-length value were "not sending a value" then I wouls
aggree.  But "" is a value, just the ultimate short value.  And the
attribute can still take any number of other values.

(Pardon the "" shorthand.)

I don't think there should be any special significance for "".  It should
not be treated the same as the attribute being ommitted, but only as a
diminutive case of a string.

-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Thu, 25 Feb 1999 13:29:28 -0800

> allowing the natural denotion of a zero length octet array.

But why include it at all?  My main complaint is that you shouldn't
specify an attribute if you don't also specify a value for it.
An Octet array of zero is no specified value, which just leads to
an interpretation problem of what is trying to be sent.  For those
cases like state that are not supposed to be interpreted, I have to
ask what is the server doing with the octet array of zero, besides
just ignoring it (which is further proof it shouldn't have been
in the request).  Is there any implementation that actually USES an
AVP Length of two that is receives for something and doesn't just
ignore it?

--

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Thu, 25 Feb 1999 13:33:41 -0800

> (Pardon the "" shorthand.)

Sure, but I don't agree.  If you look at the protocol there are two
octets
that represent the Attribute ID and and the AVP length.  The VALUE
octet(s)
follow that.  If the AVP length is 2, there is NO value octets that
follow that.  Therefore, an AVP length of two is NOT "", its simply not
including a value.
 
> diminutive case of a string.

I don't think I can agree with that as a reason. :(

--