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

From: Jonathan Garini <[email-masked]>
Date: Tue, 9 Feb 1999 21:33:17 +0200

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

Right. Either will do, but the first method should be easier to implement.
 
> 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 is indeed an issue. However, a bigger problem are NASs that NEVER send
User-Name in accounting packets.
Let me withdraw the implementation issue and stick with the problem (I hope
you agree should be solved). Do you have another implementation suggestion
that solves this problem?

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

Matching is not issue, the class attribute is indeed the way we workedaround
this problem in our server. My concern is not for our server, but for all
sites running the general server implementations and won't be able to know
to which user an accounting packet belongs to.

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

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?
-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Dale E. Reed Jr." <[email-masked]>
Date: Tue, 09 Feb 1999 14:01:53 -0800

> to which user an accounting packet belongs to.

I think the real problem is using a RADIUS client implementation that
is less than useful (like not sending usernames consistently in the 
account records).  You should be talking to the vendor of that
product to see if they have an update to correct the problem. In
my many years with RADIUS this is really a 1% of 1% type issue, and
not something that happens alot.
 
> shouldn't we make it a stanard, when most users think it is?

There are uses where the authenticated name in an Accept-Request
is the CallerID number.  The Accept-Accept returns a different
username for the NAS to report the accounting with. Therefore,
the two wont match.

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