RE: CUI - issues addressed in version 3

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hi Barney,
Thanks so much for quick attention on this.  Please see
responses/suggestions inline.
BR,
Farid

> -----Original Message-----
> From: Barney Wolff [mailto:barney@databus.com] 
> Sent: Wednesday, December 15, 2004 12:17 AM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org
> Subject: Re: CUI - issues addressed in version 3
> 
> 
> On Mon, Dec 13, 2004 at 12:48:39PM -0800, Adrangi, Farid wrote:
> > 
> > Issues addressed in Version 3
> > =============================
> > Issue 21 (Owner: Barney Wolff)
> > Issue 22 (Owner: Barney Wolff) 
> > 
> > The description of these issues can be found in in
> > http://www.drizzle.com/~aboba/RADEXT/#Issue%2014.
> 
> 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.
> 

> I will ignore my continuing doubt of the need for CUI.
> 
> 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.

I see your point!  We can change this to MAY -- I think the proposed
solution to issue 22 (below) also addresses this issue.

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


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

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