Subject: Re: (radius) Zero-length strings

From: Carl Rigney <[email-masked]>
Date: Thu, 25 Feb 1999 10:03:07 -0800 (PST)

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

I believe this can't be emphasized enough, and wholeheartedly agree that
we want to avoid baroque interpretations - in the real world protocols get
implemented by programmers on tight schedules, and we should strive for
simplicity wherever feasible.  Complicated "magic" interpretations are a
sure attractor for interoperability problems.

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

---

From: "Varghese, Joe" <[email-masked]>
Date: Thu, 25 Feb 1999 15:19:13 -0600

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

Answer: Because the User-Name *must* be present in the Auth-Request. 

Comment: All the arguments for a null User-Name can also be made for the
User-Password or CHAP-Password attribute.

If the protocol demands a certain attribute, shouldn't it contain a
provision for implementations which dont use it at all (i.e., a zero length
string)? 

Of course, the argument could be made that if an implementation is not using
the User-Name as stated, then it's not RADIUS but a RADIUS flavor. This does
limit the flexibility of the protocol, though.

--------------------------------
George (Joe) Varghese
[email-masked]
(630) 713-9522

-

---

From: Jeff Weisberg <[email-masked]>
Date: Thu, 25 Feb 1999 17:17:57 -0500 (EST)

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

Username and <Some>-Password are required to be present.

	--jeff

-

---

From: Jeff Weisberg <[email-masked]>
Date: Thu, 25 Feb 1999 17:18:01 -0500 (EST)

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

For standard attrs? probably no. 

Or the general case of any attr? In which case, not present and empty 
are clearly different for the hypothetical 
	"Text-To-Display-Instead-of-Normal-NAS-Banner" attribute:

<not present>:
	FoobarOS version 7.0

Text-To-Display-Instead-of-Normal-NAS-Banner = "Welcome to My ISP"
	Welcome to My ISP

Text-To-Display-Instead-of-Normal-NAS-Banner = ""

<displays nothing at all>

	--jeff

or to paraphrase Firth:
  One of the main causes of the fall of the Roman Empire was that 
  lacking zero length AVPs, they had no way to indicate ...

-

---

From: Aydin Edguer <[email-masked]>
Date: Thu, 25 Feb 1999 17:35:35 -0500 (EST)

> Why?  Was there a different description for the State attribute at that
> time?

In the beginning... billions and billions of nano-seconds ago... many NASes
did not support the RADIUS Access-Challenge.  Sending them an Access-Challenge
would not result in good behavior.  In order to differentiate between a
NAS that was willing to do it and a NAS that just wouldn't, the inclusion
of the empty string in the State attribute of the Access-Request was useful
as a hint that the NAS supported the Access-Challenge.

Thus the hack was started for backwards compatibility reasons.

Now, there is a legacy server, that needs the hack in order for the
Access-Challenge to be used, so the NAS continues the behavior in the
name of backwards compatibility.

It is recognized by the vendor that this is *NOT* RFC compliant.  This
is not an attempt to excuse the behavior but to answer the original
question "Is there any implementation that actually USES an AVP Length
of two".  The answer was "yes".

-

---

From: William "Chops" Westfield <[email-masked]>
Date: Thu, 25 Feb 99 15:45:42 PST

Good example.  In fact, I believe that cisco's implementation treats
the existing Reply-Message (18) in exactly the way you describe.

BillW
cisco
-

---

From: Carl Rigney <[email-masked]>
Date: Thu, 25 Feb 1999 15:56:24 -0800 (PST)

> Therefore the protocol must allow packets that do not contain
> User-Name and User-Password attributes, if the user sends empty strings
> to the NAS.

There's no problem with an empty User-Password; you just null-pad 16
bytes of data and encrypt it as usual.

The new draft allows you to omit User-Name where its no longer needed,
such as for Call-Check or EAP.

I'm still unsure with regard to users just hitting return on the
User-Name.  I'm not sure a zero-length username is valid from an
authentication standpoint, and if authentication isn't being done, its
not a matter for RADIUS.

I note that email to "@foo.com" is not considered valid either.

--
Carl
-