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

From: Aydin Edguer <[email-masked]>
Date: Tue, 9 Feb 1999 13:29:19 -0500 (EST)

> RFC 2139 does not specify the User-Name attribute as a must but rather
> as a MAY.  Most of the NASs does send the User-Name in accounting packets.
> However, we have seen one NAS that don't send this attribute. This NAS
> indeed comply with RFC 2139, but it does not comply with real life
> operations. I think the RFC should be amended to include the User-ID
> attribute as MUST.

I am sorry, but I must disagree.  The Accounting-Request message is used
for more than just user accounting (i.e. Acct-Status-Type is Start or Stop).
These other purposes which are defined in RFC 2139, such as Accounting-On
and Accounting-Off do not and should not require a User-Name attribute.

In addition with the new tunneling extensions that are becoming available
(example: Tunnel-Start) (see draft-ietf-radius-tunnel-acct-02.txt) there
may be no user associated with a particular action that is being accounted.

Finally, there are some vendor equipment that allows the use of the
Accounting-Request, Acct-Status-Type = Stop message for network monitoring
of failed sessions which do not yet have a User-Name.  This feature can
typically be disabled with a configuration parameter on the NAS.

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

---

From: Jonathan Garini <[email-masked]>
Date: Tue, 9 Feb 1999 20:29:24 +0200

I will still go for a MUST (at least for Account-STOPs). All the scenarios
described can be handled by sending an empty string for the User-Name value,
like many NASes does currently.
Still, if you do have a User-Name you MUST provide it (e.g. if a session was
started with Access-Accept than the User-Name attribute must be present in
the account stop packet).
As to hard wired network lines, these are solved with the same method, and
of course, this is an RFC for remote dialup, which should be considered
most.

Regards,
Jonathan.

> -----Original Message-----
> From: Dale E. Reed Jr. [mailto:[email-masked]]
> Sent: Tuesday, February 09, 1999 8:20 PM
> To: Jonathan Garini
> Cc: [email-masked]
> Subject: Re: (radius) RFC2139: User-Name should be MUST
> 
> 
> Jonathan Garini wrote:
> > 
> > RFC 2139 does not specify the User-Name attribute as a must 
> but rather as a
> > MAY.
> > Most of the NASs does send the User-Name in accounting 
> packets. However, we
> > have seen one NAS that don't send this attribute. This NAS 
> indeed comply
> > with RFC 2139, but it does not comply with real life operations.
> > 
> > I think the RFC should be amended to include the User-ID 
> attribute as MUST.
> 
> There are situations where this is allowed in "real life".  
> For example:
> 
> 1) Accounting-on and Accounting-Off packets don't have users 
> associated
>    with them.
> 
> 2) Most NASes send a reboot accounting packet (like Livingston) to
> signal
>    that it rebooted and all sessions for it should be cleared/closed.
> 
> 3) Reporting a session-start before authentication (like on
> modem-answer).
> 
> 4) Reporting a disconnect problem on modem answer (like the user never
> did
>    connect, therefore obviously couldn't authenticate).  This 
> is a good
> one
>    for reporting to see what problems you are having.
> 
> I would recommend a strong SHOULD, but MUST isn't reasonable unless
> situations
> like the above are specifically allowed.
> 
> -- 
> Dale E. Reed Jr.  ([email-masked])
> _________________________________________________________________
>        IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs
>  Internet Solutions for Today  |   http://www.iea-software.com
> 
-

---

From: Jonathan Garini <[email-masked]>
Date: Tue, 9 Feb 1999 20:36:25 +0200

My suggestion does not hurt any of the functionality you described.  I think
you all agree  that when  dealing with dialup authenticated sessions than we
MUST know who the user was.

> From: Aydin Edguer [mailto:[email-masked]]
> Sent: Tuesday, February 09, 1999 8:29 PM
> To: [email-masked]
> Cc: [email-masked]
> but rather
> (example: Tunnel-Start) (see 
> draft-ietf-radius-tunnel-acct-02.txt) there
-

---

From: Jonathan Garini <[email-masked]>
Date: Tue, 9 Feb 1999 20:49:57 +0200

> 
> The only reason why having an empty User-Name is better than having no
> User-Name is if your server software is unable to accommodate 
> the absence
> of the attribute.  In this case, it would be better to 
> improve the server
> software to add an empty User-Name or to otherwise deal with 
> it than to
> add noise to the signal.
> 

I agree here. But Still the client MUST send User-Name for authenticated
sessions. Similar procedure that applied for the class attribute should be
applied for User-Name. When available in Access-Request MUST be send in
accounting as well.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 9 Feb 1999 14:10:25 -0500 (EST)

> MUST know who the user was.

First:
Having a requirement that if a User-Name is used in the Access-Request that
results in an Access-Accept, that the corresponding Accounting-Requests for
the service resulting from the Access-Accept include the User-Name is not
the same as requiring that all Accounting-Requests include a User-Name.

I would disagree with the blanket requirement of a User-Name in every
Accounting-Request.

Second:
Desiring to know who is authenticating is the reason why a User-Name is
currently required in the Access-Request message in RFC 2138.  However,
there are times when you are not providing service based upon a User-Name,
but instead upon other information (for example: the Calling-Station-Id).

In these situations and others, there is no reason that the User-Name in
the Access-Request and the Accounting-Request must correspond and in fact
they may not if the Access-Accept includes a User-Name attribute.

 [This functionality was specifically added to the RADIUS protocol after
  the release of RFC 2138 - I refer you back to the archives of the mailing
  list available from <ftp://ftp.livingston.com/pub/radius/archive/>

   [ietf-radius.9704]
   Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST)
   From: Carl Rigney <cdr>
   Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30
   ...
       Allowing Usernames in Access-Accepts (for use with Calling-Station-Id)?

   [ietf-radius.9708]
   Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT)
   From: Carl Rigney <cdr>
   Subject: (radius) 38th IETF RADIUS Working Group Minutes
   ...
   Usernames are now allowed in Access-Accepts, for example in a case
   where the User is identified by their Calling-Station-Id.
 ]

If you are trying to match Accounting records with Authentication records,
then you can try to use the Class attribute or for some vendors, the
Acct-Session-Id to link the messages.

I would disagree with requiring the User-Names to *have* to match between
an Access-Request and an Accounting-Request.

-

---

From: William "Chops" Westfield <[email-masked]>
Date: Tue, 9 Feb 99 12:03:49 PST

My suggestion does not hurt any of the functionality you described.  I
    think you all agree that when dealing with dialup authenticated
    sessions than we MUST know who the user was.

I disagree.  In fact, the cisco accounting code permits accounting to
be done without authentication (ie there is never a username.)

Accounting is not the same as billing.

BillW
cisco

-

---

From: Jonathan Garini <[email-masked]>
Date: Tue, 9 Feb 1999 22:26:01 +0200

> 
> Add the requirement that the NAS include the User-Name attribute (when
> reasonable) to your purchasing requirements and only buy 
> equipment that
> meets your needs.

Hmmm... So you think RFCs slips should be dealt this way?
> 
> File a bug report with the NAS vendor and explain your issues with the
> product's behavior.

Is it a bug?

> 
> Just because the behavior is permitted by a standard does not 
> mean that
> you must accept the behavior.  A reasonable dialogue with the 
> vendor is
> the best approach in many cases rather than trying to change 
> the standard
> to fit a specific need that does not necessarily match others' needs.

How would the NAS vendor or the customer should know they are doing
something wrong. Isn't it our job to prevent such things?
How can they figure it for themselves when reading the RFCs?

> > Why do you disagree? Isn't it how most of the NASs are 
> doing anyway? Why
> > shouldn't we make it a stanard, when most users think it is?
> 
> I gave an example.  In the case where the user is authenticated using
> the Calling-Station-Id, the RADIUS server may return a 
> User-Name attribute
> which changes the User-Name associated with a session and thus the
> User-Name which will be recorded in the Accounting-Request messages.
> 
> A vendor who can do this is Ascend Communications.  In this case, you
> can use "CLID" authentication and the User-Name that is included in
> the Access-Request will be the ASCII reprentation of the phone number
> (it will be identical to the Calling-Station-Id).  By returning the
> User-Name attribute in the Access-Accept, you can modify the name used
> for accounting to agree with a "real name" (User-Name = 
> "Frank_Black").
> 

What's your point? why do you disagree?

I have finished my role here for this thread, I don't like to argue for the
sake of the argument nor for what is obvious. 
The RFC is lacking in this case. 
I have raised the issue, if you think nothing should be done than let it be.
I have no personal interest here neither at the server nor the client side. 
I have spotted a problem and brought it up you can solve it or leave it, the
only people who are hurt are users of vendors who comply with the RFC but
still offers a crippled functionality.
I can see the narrow interest of a NAS vendor who does not have this problem
that it will remain a problem for new RADIUS client implementation, however,
I can't see how the RADIUS standard will benefit from such an approach.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Aydin Edguer <[email-masked]>
Date: Tue, 9 Feb 1999 15:50:05 -0500 (EST)

> >  By returning the User-Name attribute in the Access-Accept, you can
> > modify the name used for accounting to agree with a "real name"
> > (User-Name = "Frank_Black").
> 
>   ... and ignoring the explicit instructions of the RFC.
> 
>   May I quote from RFC 2138:

You may, but you will then be ignoring the previous message I sent, which
quoted from the RADIUS-WG notes that explicitly added the functionality
described:

   [ietf-radius.9704]

   [ietf-radius.9708]

> In your case, your acceptance of User-Name in Access-Accept is incorrect.

No, it is not incorrect, because the allowed behavior has been changed
since the publication of RFC 2138.
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: William "Chops" Westfield <[email-masked]>
Date: Wed, 10 Feb 99 12:18:41 PST

We had to fix a bug in cisco radius where a null username (typed by the
user) was passed to the radius authentication request packet as a zero-length
username (length 2 attribute.)  It must have been upsetting someone.

I guess we didn't handle the equivilent case for accounting.  (for authen,
the fix was not to permit a null username at the UI level.)

BillW
-

---

From: Aydin Edguer <[email-masked]>
Date: Wed, 10 Feb 1999 16:06:26 -0500 (EST)

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

There may have been rational purposes at one time, but in general, those
times are long past, if they ever existed.

For instance, one vendor will include a State attribute with an empty
string value in an Access-Request as a "hint" to the RADIUS server that
the NAS supported the Access-Challenge RADIUS packet types.

This made sense when it was done 4 years ago (long before RFC 2058 was
completed), but it does not make sense now, except for backwards
compatibility and a method for complying with the RFC should be added.

There is also a vendor that includes a vendor specific attribute with
an empty string value in an Access-Request.  This is allowed by the RFC,
since it is a vendor attribute, but it doesn't really make sense.  It
should be considered a bug, not a feature.

It is true that back when there were discussions about a fictitious
RADIUS 2 protocol and roaming, that the idea of using empty attributes
to override earlier attributes (basically to delete them) was discussed
but it was "what if" discussions, not actual implementations.

-

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 10 Feb 1999 17:16:05 -0500

Alan DeKok writes...

	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 think that you can catch these sorts of problems just as
effectively with "bake-off" style interoperability testing.
Perhaps more effectively.  As for stopping the problems, I
think that only market pressures can achieve that end.

Regards,

Dave
  
David B. Nelson                          Cabletron Systems, Inc.
Software Engineer V                      50 Minuteman Road
(978) 684-1330                           Andover, MA 01810

-

---

From: Carl Rigney <[email-masked]>
Date: Wed, 10 Feb 1999 18:58:38 -0800 (PST)

I don't see any value in discussions of past history.  That horse turned into
glue long, long ago.

--
Carl
-

---

From: William "Chops" Westfield <[email-masked]>
Date: Wed, 10 Feb 99 22:05:20 PST

>>    Sorry, I was not referring to MCI or WorldCom specifically;

Me either.  Given what amounts to a "weak" spec, given the choice between
implementing a customer request and sticking to the spec, the customers
win.  (customers ask for stuff like user configurable tcp timers too, but
at least there there is a strong spec with a lot of backing.)

BillW
-