RE: NAI decoration: User Identity issues

[Avi Lior <avi@bridgewatersystems.com>]

See inline.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, July 15, 2004 3:14 PM
> To: Avi Lior
> Cc: 'Nelson, David'; radiusext@ops.ietf.org
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > The details of what is placed in the User-Alias will be worked out 
> > between the operators when they negotiate their roaming agreements.
> 
> If this were the case then the Class attribute would suffice. 
>  To distinguish itself from Class, the local operator MUST be 
> sure that a billable identity is contained within the 
> attribute.  If it "could be anything" then this assurance 
> does not exist (as it does not exist for Class).  Introducing 
> multiple attribute also clouds the picture. How does the 
> operator know which one (if any) of the operators contains a 
> billable identity?

Class attribute cannot function as the User Alias.

Intermediaries should not look at the contents of the class attribute. Or am
I missing something?  So if I cant look inside it how can I use it to
represent the User-Alias?
 
> And if intermediaries decorate this attribute then you have 
> re-introduced all the problems that already existed with User-Name.

I never said that intermediaries should decorate this attribute.

But remember that RADIUS is a hop by hop protocol and Intermediaries are
allowed to make changes to the packet (in either direction) as it progress
between the NAS and the Home server.

Related to this Bernard also stated:
>No. The User-Name attribute is not re-written by intermediaries when sent
in an Access-Accept. 

I disagree.  Can you show me where this is specified?






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