Subject: RE: (radius) Zero-length strings

From: "Beadles, Mark A." <[email-masked]>
Date: Thu, 25 Feb 1999 12:12:36 -0500

From: Richard S. Conto [mailto:[email-masked]]
>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.

You've got it exactly, Richard..  A NAS is properly a Policy Enforcement
Point in this scenario, and should not undertake to make such policy
decisions as "reject user if username === null". 

But wait, the above seems to be in the realm of what a NAS SHOULD do,
and not what the RADIUS protocol LOOKS like, right?  So therefore the only
possible choice is to EITHER allow a NAS to send a null attribute, or to
allow that it NOT SEND an attribute that is otherwise required by the 
protocol.  So I would say that zero-length attributes are in.

+ Mark Anthony Beadles +       MCI WorldCom      +
+  [email-masked]   +    http://www.wcom.net  +
+  Voice 614.723.1941  +      Fax 614.723.8407   +
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Glen Zorn <[email-masked]>
Date: Thu, 25 Feb 1999 13:04:12 -0800 (PST)

> >the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT.

Which begs the question "Why are you sending a User-Name at all?". 

> protocol.  So I would say that zero-length attributes are in.

I disagree.  Given a choice between a bad hack to work around a protocol
deficiency and fixing the protocol, I'd pick the latter every time.

-

---

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

> Which begs the question "Why are you sending a User-Name at all?". 

Those examples probably shouldn't be sending a User-Name, but in the case
where the person has specifically pressed enter after the "login:" prompt,
you need to ask the RADIUS server if User-Name = "" is allowed to log in.

The current draft of the RADIUS spec does not provide a way to ask this
question, should someone have the policy to desire it.

> deficiency and fixing the protocol, I'd pick the latter every time.

As far as needing a bad hack to work around non- User-Name authentication,
you are correct.  We should (and did, as I recall) fix the spec to not
require some hacked up username.

OTOH, having to store a zero-length string value as at least one byte is
also a "bad hack to work around a protocol deficiency."

The biggest arguments against zero length values seem to be:

1) They aren't discussed at all in the drafts, and many implementations
are abusing them.
	We simply need to discuss and limit their use.  If we specifically
state that they refer to a value consisting of an undistinguished string
of octets 0 bytes long, and prohibit them from being used to indicate the
absence of an attribute, it should curb the abuse.  They won't get used
very much, but when they are used it will be well-defined.

2) They are a diminutive case with very little apparent usefulness.
	I have indicated at least one case in which they could be
immediately useful (request authentication of a person who entered a
zero-length User-Name, perhaps to bring them to a guest service, new
account signup, forgotten username lookup service or the like).  I admit
that the usefulness is very limitted.

On the pro side, there is also that there is no compelling reason to
remove the diminutive case of a zero length value.  (Yeah, I'm the
mathematician type that starts off Fibonacci's sequence 0,1 instead of the
more common 1,1.)

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

-