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

From: Barney Wolff <[email-masked]>
Date: Tue, 9 Feb 1999 18:10 EST

> Date: Tue, 09 Feb 1999 14:14:34 -0800
> From: "Dale E. Reed Jr." <[email-masked]>
> 
> An AVP Pair length of 2 is non-RFC compliant (a blank data field).  
> Many NASes send them (Ascend, USR, Cisco, ...) but that doesn't mean 
> the RFC should be again updated to police this.  Its up to us to
> not only follow the RFC, but use atleast SOME common sense when
> working with RADIUS so that we can get our products to work together.

Well, that is not true in general, only for specific attribute types.
In fact, requiring a non-empty value has always been on the order of
a typo, rather than a well-considered and agreed-on decision.  It has,
in fact, misled at least one vendor (you know who you are) into adding
a trailing null on non-empty string attributes.

We're well into the gray area between NASREQ (of blessed memory?) and
RADIUS.  It would be an outrage to tolerate a NAS that knows the user's
identity but omits it from an acct start/stop.

If anybody cares, I'm in the camp that would not send a fake empty
user attribute, but would make it a MUST that the attribute be sent
if the user is known.  So now both sides can hate me.

Barney Wolff  <[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, 10 Feb 1999 01:01:01 -0800

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. 

Looking at 2139:

>    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 Accounting-Request with an invalid
>       Length, the entire request should be silently discarded.

And you can guess the rest.  This is what I am talking about.  I know
of ATLEAST 4 major NAS vendors that send an AVP pair with a length
of 2, which if you interpret the above strictly, cause major pains
with Authentication and Accounting. Now if we require that the 
username attribute be required (even if there is no username itself), 
then to follow the RFC as I've noted above, it would have to contain 
atleast one character or something (read, kludge).

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