RE: NAI decoration: User Identity issues

[Avi Lior <avi@bridgewatersystems.com>]

A UserAlias can contain some opaque value provided that the HomeNetwork
asserts that it represents a user for a period of time.  That is it will not
change over a period of time.  The period of time could be a month or even
longer.

Class attributes could change over the lifetime of even a session because
class attribute may store stuff other then just  the User Alias.  So you
cant use it as the User's Identity.


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, July 15, 2004 3:37 PM
> To: Nelson, David
> Cc: radiusext@ops.ietf.org
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > It would seem to me that in order to function as a billing 
> > reconciliation mechanism (see Roy Albert's response) such 
> an attribute
> > (User-Alias) MUST NOT be decorated or modified by intermediaries.
> 
> Yes.
> 
> > Could someone please review the technical (and business) 
> reasons that 
> > State could not serve this requirement?  Is it that State 
> is supposed 
> > to be an opaque object?  Is it that State is not required 
> to contain 
> > printable ASCII suitable for inclusion on billing statements?
> 
> I think that's the reason.  Basically, the local operator 
> needs to be assured that it has a billable identity on hand 
> before providing service. If privacy is being used, the 
> User-Name may not contain a billable identity, and the local 
> operator may not be able to determine from the Class, State, 
> etc. attribute whether a billable identity is present or not.
> 
> For example, what if the NAS receives 3 Class/State attributes:
> 
> dnelson@enterasys.com
> 82673F0D2745037126@BH239487sdkd2jd
> ToBeOrNotToBe.Shakespeare
> 
> Which one of these 3 attribute is the billable identity?  
> Does the NAS have to parse the attributes and determine 
> which, if any, comply with the grammar of RFC 2486bis?  
> Remember, the problem exists not on the RADIUS server (which 
> presumably can sort things out) but on the RADIUS client that 
> is trying to figure out if it is going to get paid.
> 
> Of course, exactly the same problems occur if a new attribute 
> is defined that can contain "anything", and can be sent 
> multiple times by the RADIUS server.
> 
> In summary:
> 
> * The problem occurs when Privacy is used and the User-Name 
> cannot be used
>   as a billable identity by the local operator.
> 
> * If sent in the Access-Accept, the User-Name attribute is 
> included in the
>   accounting record.
> 
> * Since the User-Name attribute sent by the RADIUS server is 
> undecorated,
>   it may cause mis-routing of accounting packets. So the
>   RADIUS server may not wish to send the User-Name attribute.
> 
> * The Billable-Identity attribute if sent by the RADIUS server, is
>   guaranteed to contain a billable identity.  It MUST NOT be modified
>   by intermediaries, and if received, is placed in the 
> accounting record
>   by the NAS.
> 
> * In all cases, the User-Name MUST be included in the 
> Accounting-Record.
> 
> --
> to unsubscribe send a message to 
> radiusext-request@ops.ietf.org with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>