Re: CUI - issues addressed in version 3

[Barney Wolff <barney@databus.com>]

On Wed, Dec 15, 2004 at 04:47:32PM -0800, Adrangi, Farid wrote:
> 
> It seems to me the advertisement capability generating more heat than
> light!  Actually, I am not sure if the advertisement capability is
> really required as I stated in my previous e-mail (on a different
> thread).   What if we remove the advertisment capability and simply say
> this:
> 
> "
> In cases where the home RADIUS server cannot determine the NAS support
> for the CUI, if the home RADIUS server requires the NAS support for CUI
> for any reason (e.g., for billing or charging purposes), the home RADIUS
> server MUST reject the request by sending an Access-Reject message
> including an Error-Cause attribute [RFC3576] with value (to-be-defined)
> (decimal), "CUI-Support-Undetermined".  Otherwise, if the authentication
> is successful, the home RADIUS server MUST send both the User-Name (1)
> attribute and the CUI attribute, with the understanding that if the NAS
> supports the CUI attribute the CUI attribute will override the identity
> portion the User-Name (1) attribute.  That is, the User-Name(1)
> attribute will be used for routing and the CUI attribute will be used
> for identity purposes.  When an Access-Accept without the CUI attribute
> is received, if the NAS requires the CUI attribute to be present in the
> Access-Accept, the NAS SHOULD treat the Access-Accept as a reject.
> "
> 
> Is this aligned with your thoughts?

The last part is.  For the server, I cannot understand the case where
the server's owner demands CUI but the NAS/Proxy owners did not:  the
server can always use Class*.  Sending back User-Name risks the routing
problems that motivated a separate CUI.

* Let's not claim that Class is unreliable, or truncated, but somehow CUI
will avoid such problems.  Anyway, it's the server that gets to put in
the first Class attribute, so if truncation is a problem it will be boxes
upstream that suffer it.

> > 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!
> 
> IMO, even 1:1 relationship CUI<->real_user is also out of scope.  For
> clarify maybe the paragraph should be rephrased as below:
> "
> The CUI format (i.e., User-Identity types listed above) and
> configuration (e.g., CUI lifetime) will be determined based on
> business/deployment decisions by the *home network*.  Standards bodies /
> organizations like 3GPP and GSMA will be responsible for defining how
> the CUI should be formatted and configured based on their security /
> deployment requirements and business needs.
> "

This doesn't fly, if it is the NAS/proxy owner that's requiring CUI.
Surely the binding lifetime is part of that requirement.  I'm not concerned
with the value per se (that can always be configurable) but with its
interpretation.  For example, if lifetime is 1 hour, does that mean from
one session start to the next, or from session end to the next session
start, or simply that the binding can change each hour of the day, so
might change between sessions starting at 09:59 and 10:01?  Can a developer
write a RADIUS server that will work in any application?

If those demanding CUI have been specific enough to answer such questions,
I've missed it.

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