Re: AW: backwards compatible introduction of NEW attribute such as CU I

[Bernard Aboba <aboba@internaut.com>]

> 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@ex
> ample.com ?

One of the tasks for RFC 2486bis was to add privacy support to RFC 2486.
Are you claiming that the draft does not define this service?  My
understanding was that "Privacy" in RFC 2486bis is defined as an NAI
without a user-id portion.  While I realize that there are RADIUS servers
that treat user "anonymous" differently, this is not universally
implemented (or even specified) so it will not interoperate.

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

The problem with requiring that the RADIUS server *always* send CUI is
that no existing RADIUS servers do this.  However, if we restrict the
applicability of CUI, then it may be reasonable to expect that a RADIUS
server that implements RFC 3579 and "Privacy" as defined in RFC 2486bis
will be upgraded to also support CUI.  CUI support therefore becomes
part of the "Privacy" functionality package.

> 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-chan
> ge-the-accept-into-a-reject" .

Yes.  And I think defining that sufficiently well is the task of RFC
2486bis.

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