Re: CUI - issues addressed in version 3

[Bernard Aboba <aboba@internaut.com>]

> Let me preface these remarks by saying that if I'm the only one
> resisting CUI the wg should go ahead anyway; consensus does not
> require unanimity.

Looking through the mailing list, it appears your doubts were shared by
others, and therefore the issues you raised will need to be resolved for
this document to proceed.

> The core of my Issue 21 is that the draft obsoletes a piece of
> RFC 2865 by saying that servers that do not understand CUI SHOULD
> silently discard the attribute.  Since an implementation that does
> not understand CUI will not know that it's CUI that it's ignoring,
> the draft effectively says that servers SHOULD silently discard all
> unknown attributes.  2865 says MAY.  If we are going to make existing
> implementations retroactively non-compliant with RADIUS, we need
> to rev 2865.

Backward compatibility is a requirement of the RADEXT WG charter.  In the
case of documents that modify existing behavior rather than adding
totally new functionality, this boils down to whether existing RADIUS servers
behave the way that the draft wishes them to.  A survey of existing
implementations would appear to be required.

Assuming that it can be shown that the draft is backward compatible with
existing implementations, then I don't think RFC 2865 needs to be
modified.  It's just that the MAY is widely implemented.

If existing RADIUS servers *don't* behave that way, then the WG has a
major task ahead of it in introducing this (and other) new functionality,
because we are saying that RADIUS servers that could interact
with a NAS with CUI support need to be upgraded.

Note that a key question is the population of RADIUS servers that
need to be upgraded -- the scope of applicability of CUI. For example, if
the scope of CUI were limited to use with a package of significant new
functionality, or a block of older functionality, where it could be
demonstrated that existing RADIUS servers implementing that
functionality behave as desired.

In this particular case, the need for CUI appears to arise from "Privacy",
a feature that is only supported within EAP, but not within other forms of
access (VPN, Dialup, etc.) So it looks to me like we're only talking about
RADIUS servers supporting RFC 3579.

If this is the case, then it might be sufficient to demonstrate that
RADIUS servers supporting RFC 3579 and perhaps RFC 3580 behave as desired.
This is a different thing from demonstrating that all RADIUS servers supporting
RFC 2865 and 2866 behave as desired, since that would include RADIUS
servers only used for Dialup Access, installed in 1995, and using the old
Livingston code base.  RADIUS servers in that kind of deployment aren't
likely to be upgraded soon :)

> Issue 22 is about which party requires that CUI be present.  Given
> the business case claimed, it appears to be the NAS owner or proxy,
> not the server owner.

Another issue is *when* CUI is required to be present.  My understanding
was that CUI was only required where user privacy was being used.
Otherwise, the User-Name attribute could be used instead.  If so, we're
restricting the use of CUI to a potential set of RADIUS servers
that might be more likely to be backward compatible, since we could be
requiring RFC 3579, 3580 *and* privacy support.

> If that's so, the draft's suggestions on how
> to indicate support for CUI seem backwards.  If the NAS or a proxy
> *requires* CUI, rather than simply supporting it, that's the case
> where putting a null CUI in the Request makes sense, and an Accept
> that comes back without CUI can then be treated as a Reject.

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