Subject: Re: (radius) RFC2139: User-Name should be MUST

From: Barney Wolff <[email-masked]>
Date: Wed, 10 Feb 1999 09:57 EST

How about reading what's right after the definition of the Length,
namely the Value definition, which does say "zero or more octets."
By my way of thinking, an invalid length is <2 or beyond the end of
the packet, making further processing impossible.  At best, you can
claim that an empty attribute of a type that is not allowed to be
empty makes its *attribute* invalid, but not the whole packet.

"Be conservative in what you send, liberal in what you accept."

Barney Wolff  <[email-masked]>

> Date: Wed, 10 Feb 1999 01:01:01 -0800
> From: "Dale E. Reed Jr." <[email-masked]>
> To: Barney Wolff <[email-masked]>
> Cc: [email-masked]
> Subject: Re: (radius) RFC2139: User-Name should be MUST
> Content-Length: 2825
> Reply-To: "Dale E. Reed Jr." <[email-masked]>
> 
> RFC 2138 says:
> 
> >    Length
> > 
> >       The Length field is one octet, and indicates the length of this
> >       Attribute including the Type, Length and Value fields.  If an
> >       Attribute is received in an Access-Request but with an invalid
> >       Length, an Access-Reject SHOULD be transmitted.  If an Attribute
> >       is received in an Access-Accept, Access-Reject or Access-Challenge
> >       packet with an invalid length, the packet MUST either be treated
> >       an Access-Reject or else silently discarded.
> 
> Now, almost all of the attributes of variable lengths (like username)
> say:
> 
> >   Type
> >       1 for User-Name.
> > 
> >    Length
> >       >= 3
> 
> Now, reading the above, if we receive a request with the following data:
> 
> ... 01 02 04 06 ff 00 00 01 ...
> 
> Where 01 is the Username AVP, and 04 is the NAS-IP-Address AVP, then
> the length specifier for the username is NOT ">= 3" which means its
> "invalid" and "MUST" be either silently discarded or sent an
> Access-Reject. 
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

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

> empty makes its *attribute* invalid, but not the whole packet.

Then the RFC needs to either adjust the value to 1 or more or the
length to >= 2.  How can you have zero octets and maintain a
length of three?
 
> > >       an Access-Reject or else silently discarded.

I do agree that ignoring the attribute would be good, but the RFC
says "PACKET" not attribute.  It actually makes since though, since 
if the attribute length if bad, then rest of the packet may be
bad.  I just go by what the RFC says. :)

-- 
Dale E. Reed Jr.  ([email-masked])
_________________________________________________________________
       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs
 Internet Solutions for Today  |   http://www.iea-software.com
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 10 Feb 1999 10:58:06 -0800 (PST)

> > namely the Value definition, which does say "zero or more octets."

The individual attribute descriptions
state (at least) the minimum length of the attribute.  I can't find any
attributes for which the minimum length is less than three, which means
that empty value fields are illegal for the standard attributes.  The
passage you cite makes it possible to define a legal RADIUS attribute with
a zero-length Value field but that seems irrelevant in the current
context.

 > > By my way of thinking, an invalid
length is <2 or beyond the end
of > > the packet, making further processing impossible.  At best, you can
> > empty makes its *attribute* invalid, but not the whole packet.

The RFC is pretty specific about this.

-

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 1999 14:35:01 -0500

> namely the Value definition, which does say "zero or more octets."

  And which appears to be contradicting the "Length >= 3"
specification in every string attribute.  I choose one definition, you
choose another, and we have non-interoperating implementations.

> empty makes its *attribute* invalid, but not the whole packet.

  An empty string attribute may not be meaningless.  I can't figure
out what it would mean, but enough implementations use them that there
must be SOME rational purpose behind them.
 
> "Be conservative in what you send, liberal in what you accept."

  Is this necessarily a good philosophy for a secure authentication
and authorization server?  Can you implement a security policy in the
face of unknown or ambiguous information?

  We're forced to come up with new hacks every time we test our server
against another NAS, or another NAS vendor.  I'd prefer a well-defined
protocol that isn't ambiguous (e.g. w.r.t. Length), vendor
implementations that don't vary randomly from the spec, or at least
some agreement on the Right Way of Doing Things.

  Alan DeKok.
-

---

From: Dave Mitton <[email-masked]>
Date: Wed, 10 Feb 1999 14:54:52 -0500

You have now achieved enlightenment.
Welcome to the RADIUS working group.

;^p
	Dave. 

>'unsubscribe ietf-radius' in the body of the message.
---------------------------------------------------------------
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: Glen Zorn <[email-masked]>
Date: Wed, 10 Feb 1999 12:04:14 -0800 (PST)

> choose another, and we have non-interoperating implementations.

There's no contradiction.  Attributes with zero-length Value fields are
legal in RADIUS, but no standard attributes have zero-length Value fields.
 
> must be SOME rational purpose behind them.

And that's legal, as long as the attribute in question is not a standard
one.

> some agreement on the Right Way of Doing Things.

May I suggest Diameter?

-

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 1999 15:29:56 -0500

> legal in RADIUS, but no standard attributes have zero-length Value fields.

  ... as defined in the RFC's.

  But if I believed the RFC's, my RADIUS server would discard packets
from most major NAS vendors.  (sigh)

> > I'd prefer a well-defined

  Will Diameter protect me from vendors who decide to implement part
of the RFC, ignore part of the RFC, or add their own weirdness to the
protocol?  I'm optimistic, but also prepared for the worst.

  I think it would help if we had a reference implementation against
which we could measure standards compliance.  (e.g. bind.)  I hope
that such an implementation becomes available before Diameter is
widely used, or we'll end up suffering the same problems as we now
have with Radius.

  Alan DeKok.
-

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Wed, 10 Feb 1999 13:14:29 -0800

> from most major NAS vendors.  (sigh)

As DOES ours, unless the user turns on the "Allow Malformed" option,
which is becoming a support nightmare and is now the default.  So
now our pacakge isn't considered RFC compliant, unless they uncheck
a default. :(

---

From: Glen Zorn <[email-masked]>
Date: Wed, 10 Feb 1999 13:22:32 -0800 (PST)

> protocol?  I'm optimistic, but also prepared for the worst.

Nothing can protect you from wanton ignorance or disregard of the
standards.  A lot of the behavior yopu're talking about is, I think, just
implemented because RADIUS is not capable of doing what customers need.
I believe that Diameter is being designed to avoid those kind of pitfalls
e.g., with standard support for vendor-specific attributes _from the
start_, and attribute space that is large enough that assignment need not
be penuriious, server-initiated message exchanges, etc.).
 
> widely used, or we'll end up suffering the same problems as we now

I don't think that a reference implementation is the answer here, just a
protocol that's _really_ (as opposed to merely claimed to be) flexible and
extensible. 

-

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 10 Feb 1999 13:29:43 -0800 (PST)

> widely used, or we'll end up suffering the same problems as we now
The plan is to make a reference implementation available on the 'net for
interoperability testing before it becomes widely deployed.

PatC

-

---

From: Alan DeKok <[email-masked]>
Date: Wed, 10 Feb 1999 16:53:05 -0500

> implemented because RADIUS is not capable of doing what customers need.

  I'd respectfully disagree.  My experience has been that Radius
clients often:

- don't support Access-Challenge packets
- send empty attributes in requests
- ignore other length and value specifications in the RFC's
- require vendor-specific attributes before believing an Access-Accept
- etc.

  Radius servers are broken, too, as in they:

- treat 'Proxy-State' as something other than undistinguished octets
- send non-spec attributes on Accounting-Response
  etc.

  Taking the 'customer' as the NAS vendor or the ISP/business trying
to implement Radius, then NONE of these problems are a result of
"RADIUS not being capable of doing what customers need."

  Instead, the problems exist because of one of history;
misunderstanding; or sheer laziness.  The only way to catch and stop
these problems is with a reference implementation, not a
better-defined protocol.  (I won't comment on Diameter here.)

  Alan DeKok.
-

---

From: Paul Krumviede <[email-masked]>
Date: Wed, 10 Feb 1999 14:12:11 -0800

Glen Zorn wrote:

> standards.

True.

> A lot of the behavior yopu're talking about is, I think, just

This seems very unlikely. The RADIUS WG was, in some respects, a
strange entity: it was formed (originally) to document the existing
protocol (and thus, to some extent, implementations). To the extent
that it delayed doing so in favor of chasing enhancements that
*suppliers* wanted, it prolonged the period during which there
was no standard against which one could test an implementation
for compliance (note that I-Ds don't really count here, since
they highlight the fact that they are mutable).

Having said that, perhaps discussions of history don't really
help us engineer better solutions. So please take flames to
private email.

-paul
-

---

From: Glen Zorn <[email-masked]>
Date: Wed, 10 Feb 1999 14:31:08 -0800 (PST)

On Wed, 10 Feb 1999, Paul Krumviede wrote:

> protocol (and thus, to some extent, implementations). 

Yes.

> To the extent
> *suppliers* wanted, 

Hmm.  So "suppliers" made up these enhancements (presumably just to
spend money)?  I could have sworn that most of the enhancement requests
came from customers of said suppliers.

> it prolonged the period during which there 

But you just said that the WG was 'formed to document the existing
protocol'.  This implies that 'the existing protocol' (and, by extension,
the Livingston implementation) _was_ the 'standard
against which to test'.  In any case, I think that that is a pretty lame
excuse for shipping a non-compliant implementation today.  What is _not_ a
lame excuse is that the RFCs do not represent the true "standard", which
includes the Ascend extensions.  

> help us engineer better solutions. 

'Those who do not learn from history are doomed to repeat it.'

>So please take flames to

I was unaware that I was flaming anyone or anything.  Noting that RADIUS
is to some (large or small) extent inadequate for the tasks that need to
be performed is hardly novel nor (I imagined) very controversial.  

-

---

From: Paul Krumviede <[email-masked]>
Date: Wed, 10 Feb 1999 15:05:25 -0800

> came from customers of said suppliers.

I've heard, more than once, that "somebody in MCI" is requesting
particular work. When I ask who, nobody seems to remember. Given
the way some companies seem to work, this seems to be a not
uncommon tactic to win management approval for doing something.
I don't think that MCI is the only company to be named in this
kind of situation.

But the WG charter, as originally written, was to document
existing practice(s). We didn't do that first.

> includes the Ascend extensions.

I believe that the original charter was to document what existed. I
didn't write the charter, nor was (or am) I a member of the IESG,
but I don't think that the intent was to document any particular
implemtation.

-paul
-

---

From: Paul Krumviede <[email-masked]>
Date: Wed, 10 Feb 1999 14:50:18 -0800

> > private email.

For what it counts, I meant flames in response to my message. I
did not mean to imply that Glen's message, to which I responded,
was a flame.

-paul
-

---

From: Glen Zorn <[email-masked]>
Date: Wed, 10 Feb 1999 17:57:27 -0800 (PST)

> I don't think that MCI is the only company to be named in this

Sorry, I was not referring to MCI or WorldCom specifically; I have no idea
whether you folks made any requests e.g. to Ascend.  It's just that in my
experience vendors don't tend to do a lot of work without (at least the
perception on their part) of substantial customer demand.  Of course,
the meaning of "substantial" varies from vendor to vendor but I imagine
that a request from MCI or ATT would be seen as substantial by most
companies.

> but I don't think that the intent was to document any particular

Perhaps not, but allowing a Livingston employee to chair the WG more or
less guaranteed that, right?  Note that I am _not_ implying or suggesting
_any_ impropriety on the part of Carl Rigney; it just makes sense that
since RADIUS was (and to some extent still is) considered a Livingston
protocol and a Livingston employee is chairing the WG, the WG would tend
toward documenting the Livingston implementation.  This is not necessarily
bad, but in hind sight it might have been a better idea to issue the RFC
as Informational and go on from there.

-