Re: CUI - issues addressed in version 3

[Barney Wolff <barney@databus.com>]

On Wed, Dec 15, 2004 at 03:18:02PM -0800, Adrangi, Farid wrote:
> 
> > 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.  
> 
> You are right - we need to make this clear.  In general, as you also
> alluded in your response to Lothar, CUI is not required by the device
> but rather it is required to be supported by the infrastructure as
> driven by the business requirements.  If so, to make this clear in the
> document, how about the following changes to the draft? 
> 
> 1) Add the following text to the end of the second paragraph in section
> 1.1
> "
> The CUI support by RADIUS infrastructure is driven by the business
> requirements between roaming entities, and hence it 
> should not be viewed as a technical or logical requirement for a
> particular RADIUS device (i.e., NAS, proxy, server).  
> Therefore whether a RADIUS server/proxy or client accepts or rejects the
> presence or lack of presence of the CUI attribute is a matter of
> business policy, that is local policy.  This conforms to the existing
> behavior of RFC 2865 as it states that RADIUS client or server MAY
> ignore attributes with an unknown type.
> "
> 
> 2) Remove the following sentence in section 1.1 and 2.1
> "   Existing RADIUS servers that do not understand the CUI attribute
> SHOULD silently discard the attribute."
> 
> Hope this provides a resolution to this both issue 21 and 22 -- if not,
> please let me know.  
> 
> > 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.

This, to me, is the key.  If the null CUI is inserted in the request
only by a device whose owner requires CUI to be present in the accept,
we never have the case of CUI being inserted when it's not absolutely
required and causing interoperability problems with some device that
does not understand it.

> > Finally, the draft's advice on the lifetime of a CUI seems a 
> > bit vague.
> > Would an implementation that assigned consecutive integers to each
> > Accept as the CUI be compliant, provided it kept a database of the
> > correspondence to the user's "true" identity?
> > 
> 
> Maybe.  In general, I think how CUI is configured and formatted will be
> determined by business decisions.  If so, how about we revise the
> following paragraph in section 2.1 as below?
> 
> Current paragraph:
> "
> The length of time for which the CUI is valid is outside of the scope of
> this specification.  It is assumed to be deployment related.  It should
> typically be long enough to serve some business needs and short enough
> such that it minimizes the chance of revealing the true identity of the
> user (either directly or indirectly).
> "
> 
> Revised paragraph:
> "
> The length of time for which the CUI is valid is outside of the scope of
> this specification.  The CUI format and  configuration will be
> determined by business/deployment decisions.  Standards bodies /
> organizations like 3GPP and GSMA will be responsible for defining how
> the CUI should be formatted and configured based on their security and
> deployment requirements and business needs."

The vagueness is, I think, in whether there needs to be a 1:1 relationship
CUI<->real_user and if so over what period.  "Valid" does not capture the
business requirement, which seems to be that the proxy/NAS owner demands
to be able to recognize that two sessions were initiated by the same user,
if I have understood things correctly.  Or perhaps I have it backwards,
and the requirement is to be sure that two sessions were initiated by
different users!

As a developer I would not be happy with an RFC that gave me no guidance
on what to do here.  Nor would it be pleasant if different standards bodies
or worse, different NAS/proxy owners, came to different decisions on the
required time period.  Does the server have enough information in the
request to make the right choice?

Barney

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

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