RE: NAI decoration: User Identity issues

[Avi Lior <avi@bridgewatersystems.com>]

Bernard, Barney and Farid,

Bernard's point is well taken.

I checked the latest posted draft and it says that the User-Alias-Identity
MUST be placed in Accounting if it was received in an Access Accept.

I think the MUST should be changed to SHOULD and thus not requiring any
changes to NASes.

In a situtaion where a NAS does not support this attribute yet an
Intermediary needed to correlate accounting to the User-Alias-Identity, the
Intermediary would insert the Class attribute in the Access Accept and if
the NAS supported the Class attribute, problem solved.

Avi.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Friday, July 16, 2004 1:21 AM
> To: Barney Wolff
> Cc: radiusext@ops.ietf.org
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> > > 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.
> 
> Depends who "you" is.  Presumably, the RADIUS server can use 
> it, since it sent the Class attribute.  But I think the point 
> is that the RADIUS client can't be sure that the Class 
> attribute contains a billable identity. If in addition the 
> User-Name does not contain a billable identity (e.g.
> privacy) then the RADIUS client has no assurance of billability.
> 
> > all the world's NAS's have to be upgraded?
> 
> This raises the question about whether the billable-identity 
> is an optional or mandatory attribute.  My take is that it is 
> optional. Here's why. If it is sent by the RADIUS server and 
> not understood by the NAS, RFC 2865 states clearly that it 
> MAY be ignored.
> 
> My understanding is that the issue here is on the RADIUS 
> client side, because if the RADIUS server wanted to make sure 
> that got the opaque string back in the accounting record, it 
> could always send that opaque blob *both* in the 
> billable-identity attribute and in Class.  That way, if the 
> RADIUS client cared about billable-identity, it would have 
> it; if not, it would ignore it.
> 
> If you buy this logic, then no NAS upgrade is required.
> 
> > If all NAS's are not forced to upgrade, how will the server know 
> > whether it can include User-Alias?
> 
> If the above argument isn't convincing, and we conclude that 
> this attribute is Mandatory, then we have an issue.  RFC 2865 
> doesn't support Mandatory attributes.  There are a number of 
> proposals on the table to fix this, however (e.g. Jari's 
> proposal for a new attribute format with an 'M' bit).
> 
> --
> 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/>