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

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

> This is indeed an issue. However, a bigger problem are NASs that NEVER send
> User-Name in accounting packets.

I know of no NAS vendor whose products will never send a User-Name attribute
in an accounting packet so I cannot comment.  Perhaps there is a configuration
option that needs to be modified in your current setup.

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

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.

File a bug report with the NAS vendor and explain your issues with the
product's behavior.

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.

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

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

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 09 Feb 1999 15:49:50 -0500

Aydin Edguer <[email-masked]> said:

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

>   The following table provides a guide to which attributes may be found
>   in which kinds of packets, and in what quantity.
>
>   Request   Accept   Reject   Challenge   #    Attribute
>   1         0        0        0            1   User-Name
> ...

  Sending a User-Name in an Access-Accept is non-compliant behaviour.

  My preference goes this way:

1 - An Acct-Session-Id SHOULD be in an Access-Request.

    The presence of the Acct-Session-Id allows the authentication and
    accounting information to be matched.

2 - If the User-Name attribute is unique (e.g. user name, not CLID hack),
    then the User-Name SHOULD be in the first Accounting-Request.

    This will help in the situation where the Acct-Session-Id is NOT
    sent in the Access-Request.  And the Acct-Session-Id in the first
    Accounting-Request will permit grouping of the accounting data.

3 - Failing that, the server SHOULD send a unique 'Class' to the NAS.
    This allows the information to be grouped under control of the server.

4 - If the User-Name is NOT unique, and the Acct-Session-Id is unknown,
    and there's no Class attribute, then there is little hope for matching
    an Access-Request packet to an Accounting-Request packet.

  In the case of item #4, we CAN use NAS-Port coupled with
NAS-IP-Address, but that's an ugly hack.

  In your case, your acceptance of User-Name in Access-Accept is
incorrect.  The Class attribute would be a better choice for a reply
attribute.

  The RFC is a little too vague on the topic of 1-3, as evidenced by
the confusion in the current discussion.

  Alan DeKok.
-

---

From: Dave Mitton <[email-masked]>
Date: Tue, 09 Feb 1999 16:05:26 -0500

>NAS-IP-Address, but that's an ugly hack.

	I'm sorry, but you cannot depend on User-Name to be unique at all.
The same user could be logging in multiple times (especially with
multi-link ppp) and without authentication there could be "others"
attempting authentication on other ports.

	I would submit that the proper way to generate a robust unique session key
is to combine all of, as best you can, NAS-IP-Address, NAS-Port-Type*,
NAS-Port-Number, User-Name, and Acct-Session-ID.  And you will have to use
place-holders and/or soft matching logic to make this work over multiple
vendors, and the Access-Request to Acct-Request(Start) gap.
In the later case, if you are a server vendor, you get to control the Class
attribute to help matters. But clients should not be generating their own
Class.

*(not all NASes generate unique port numbers across all port types)

	Further more there are Acct messages other than Start & Stop and a robust
server should recognize this and ignore them.

	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.