Bernard,
I just like to comment on your points c and d extracted from your most recent mail sent today on this thread.
>Bernard wrote:
>c. If the RADIUS server needs information in the accounting record why can't this be
>accomplished via use of the Class attribute?
Lothar: we gone through that loop already - My interpretation of the result: because the home server may want to delegate to an intermediary some task requiring some kind of identity awareness, but the intermediary is not allowed to even interpret Class. Furthermore, I think overloading the Class attribute with "identity" would be the wrong approach, simply because the concepts of "Class" and "Identity" are very different. Class suggests something applicaple to multiple identities, whereas "identity" suggests uniqueness. Since this is a chargeable identity, it requires uniqueness, (uniquely identifying the user) therefore "Class" may be the wrong concept. Other arguments against the use of Class have been discussed, such as limited support for Class attributes exceeding a certain length(truncating) - which may be in contradiction to the uniqueness requirement.
Bernard wrote:
d. My understanding is that the NAS is sending the empty CUI attribute in order to signal the RADIUS Server that a CUI attribute is expected in the Access Accept. If this is correct, then to maintain backward compatibility, the NAS should only signal CUI support when the CUI is required. For example, the NAS might only signal CUI support if the client sends a "Privacy" NAI, and in that case (and only that case) will the NAS treat an Accept-Accept without CUI as an Access-Reject.
Lothar: This question relates to a mail from Barney in thread: CUI issue 22
In there, Barney maintains it is the NAS owner which *requires* CUI presence, whereas I had stated (and still maintain) my opinion that it is the home server operator who *requires* CUI presence.
Meanwhile, I think the discussion about "who requires CUI presence" may be rather useless because we do not seem to be able to agree on a coherent interpretation of the term *require* (technically, business-wise, etc)
Let us rather discuss who initially determines the requirement for CUI presence. This should make things clearer hopefully.
Many people seem to assume that the NAS may always be able to initially determine the requirement for CUI presence, suggesting a CUI requirement detection method which relies on being able to identify a "Privacy-NAI" being presented by the user/authenticating peer and interpret it as a "user initiated CUI-presence request".
Is that true for the roaming privacy application ? And is a privacy NAI well defined ? Is anonymous@example.com also a privacy NAI ? Or anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-privacy@example.com ?
What about any other applications of CUI (besides roaming privacy) that people may have in mind ?
By the way, it is interesting to see that your proposal d) may be interpreted as capability negotiation - one could argue that the NAS acts as master and negotiates with the Server (as slave) if the server supports CUI. My proposal has been the other way round. But perhaps your proposal fits more easily with the backwards compatibility requirement of both the server and the NAS. It requires however that the NAS is ALWAYS able to INITIALLY DETERMINE the requirement for CUI presence. This means it may ultimately have to rely on the end user presenting an identity which can be identified by the NAS as Request to one of the upstream sever(s) saying: "CUI-attribute-presence-required-in-the-accept-message-otherwise-I-will-change-the-accept-into-a-reject" .
Lothar