Subject: (radius) Zero Length Summary

From: Carl Rigney <[email-masked]>
Date: Fri, 26 Feb 1999 09:55:43 -0800 (PST)

So after carefully reading dozens of messages this is how it seems to
me.

The people against zero length strings want examples of what they're
good for, and all the examples so far seem to fall into one of the
following cases, each of which can be handled more cleanly in the
existing framework, or in some cases with minor changes that have
already been incorporated into the new draft.

Most uses of zero length strings is to get around the requirement that
certain attributes must be present in the packet.  It strikes me as odd
that implementers are willing to violate the length requirements in the
RFC, but balk at violating the rules on what attributes are required.
The new draft loosens up requirements so this should no longer be
necessary.

A few vendors are using zero length strings to convey special
undocumented meanings.  This harms interoperability and is therefore
evil and not to be encouraged.

There needs to be a way to convey an empty password.  This is already
easily done because User-Password is required to be null padded to a
multiple of 16 bytes of data.  At first thought, it troubled me that a
null password would then give a snooper the MD5 checksum of the shared
secret followed by the request authenticator, but as far as I know,
having both Y and MD5(X+Y) does not get you any closer to discovering
X, so there's no real security problem here.  And besides, an attacker
could sign up for his own account, xor his own captured packet, and
uncover the same information.  So this doesn't seem to be a problem.

Possibly there needs to be a way to convey an empty username. I'm
uncomfortable with the whole notion of authenticating a nameless user;
I can't send email to "@livingston.com", why should I be able to
authenticate "" as a user?  But for those who really want to have
nameless users, they should just omit the User-Name attribute.  I
contemplated adding language allowing null padding for User-Names, but
"Carl" and "Carl\0" are seperate users, and in particular UTF-8 can
have embedded zero octets and RADIUS should support UTF-8 as the IETF's
choice for internationalization, so I think its simpler just to omit
attributes when they are zero length.

And the existing document has never had zero length strings, so I'm
going to correct the 0-253 typo that allowed people to willfully
misunderstand all the explicit length desciptions.

I'm still willing to entertain NEW arguments one way or the other, but
please, no repeats of things already said or rehashes of existing
arguments.

--
Carl Rigney
[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Dave Mitton <[email-masked]>
Date: Fri, 26 Feb 1999 15:18:06 -0500

Let me make my position clear.

I do not want to send zero length attributes just because they may be
required for some situations.  In those situations, either the requirement
should be relaxed, or the operation should be revisited.

I only want to send zero length strings (not integers) when it means
something to set the value to null.  Often this means overriding an
otherwise inaccessable or unknown default.

	Dave.

>please, no repeats of things already said or rehashes of existing
---------------------------------------------------------------
David Mitton			  		ESN: 248-4570
Consulting Engineer, Nortel Networks	978-916-4570 Direct
Carrier Packet Solutions, I&SP Netwks	978-916-4789 FAX
Billerica, MA 01821				[email-masked]
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 26 Feb 1999 15:32:05 -0500

> otherwise inaccessable or unknown default.

  For which RADIUS attributes is this behaviour useful, and in what
situations?

  Alan DeKok.
-

---

From: Stuart A Barkley <[email-masked]>
Date: Fri, 26 Feb 1999 16:10:18 -0500 (EST)

As usual these are my personal opinion, but they all really seem to be
so obvious that I can't argue for them very well.

Starting with: 

There is a big difference between not having an attribute and having a
null value for the attribute as was shown with the system prompt
example. 

The specification of individual attribute can make the determination
of whether that specific attribute can have a zero length value and
what meaning is conveyed.

All of the currently defined standard attributes seem to explicitly
disallow zero length values which is not inconsistent with generally
allowing transport of zero length values.

Future additions or changes to individual standard attributes need to
make the determination of whether zero length values are meaningful
and are subject of separate discussions (where I can see lots of
different opinions). 

Vendor specific attributes may allow zero length attributes. 

Gives: 

Zero length values need to be supported by the base radius transport
protocol. 

So: 

A radius server or client should generally expect to need to deal with
zero length values for attributes and the programmers of radius code
should take that into account during the system design.  (Just like
they need to deal with embedded 0 bytes in character strings and lots
of other subtle considerations.) 

Stuart
-- 
Stuart A Barkley                        email: [email-masked]
UUNET WorldCom                          phone: +1 703 206 5645

I've never been lost; I was once bewildered for three days, but never lost!
                                        --  Daniel Boone

-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Sat, 27 Mar 1999 20:44:47 -0800

> null value for the attribute as was shown with the system prompt

Heres my opinion on this.  For something that has the ability to
have a null value (like System prompt), there needs to be another 
attribute like "Show-System-Prompt" that would say whether to show
the system prompt or not.  If there is a case where the attribute
of zero length has a meaning, its best to have a way to specifically
list an on/off state without having to interpret a zero length
attribute as off.
 
> Vendor specific attributes may allow zero length attributes.

Attribute #26 can not have a zero length value.  The actual content
of the data of attribute 26 is not defined, although its recommended
to also be in AVP type format.  
 
> Zero length values need to be supported by the base radius transport

I don't equate the VSA contents to the base radius transports.
Looking at the RFC:

>       The String field is one or more octets.  The actual format of the
>       information is site or application specific, and a robust
>       implementation SHOULD support the field as undistinguished octets.

Therefore, I don't see how you can even assume that the VAS has
a length in it.  Several VSA implementations don't even have a
length octet in the data of attribute #26.

-- 

Dale E. Reed Jr.      Emerald and RadiusNT
__________________________________________
IEA Software, Inc.    www.iea-software.com

-