[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Response to Issue 46

Bernard Aboba wrote: 
As I understand it, this scenario cannot be handled by the User-Name
attribute when:

a) The CUI is not a valid NAI 

Yes, although presumably pretty much anything could
be [and has been :-) ] mapped to a NAI using some
sort of a convention.

b) It is necessary for the Authentication-Request and
Accounting-Request to traverse the same path.


Yes. But I seem to recall that there were also other
issues in User-Name rewriting.

Are we clear why the Class attribute couldn't be used to handle this
scenario?  While RFC 2865, Section 5.25 says "The client MUST NOT
interpret the attribute locally", it doesn't say that the client can't
store the blob for the purpose of simultaneous usage comparison.


I think this one is clear -- there is no guarantee that class
attribute can be used for identity comparisons -- the equal
operator may not be defined for it, as that was never
required in the RFCs. Implementations could use something
else than a stable handle, like a pointer to an event
record in a database, portion of the contents could be
a sequence number of some kind, and so on.

I think the issue may be that the CUI is potentially usable by accounting
servers at intermediaries as well as the home accounting server.  This may
imply something about the CUI, such as that there needs to be a
unique mapping between a CUI and the actual user.  If so, the document
should state the requirement.


Yes.

--Jari

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