[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CUI - issues addressed in version 3
Hi Barney,
Thanks for the dialogue. Please see my responses inline.
BR,
Farid
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Barney Wolff
> Sent: Wednesday, December 15, 2004 3:57 PM
> To: Adrangi, Farid
> Cc: radiusext@ops.ietf.org
> Subject: Re: CUI - issues addressed in version 3
>
>
> 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.
>
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?
> > > 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!
>
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.
"
> 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?
>
First, don't you think the CUI format and configuration should be
determined by the home network (i.e., NOT NAS or proxy)? IMHO, as a
developer, you should enable dynamic configuration for the CUI that
meets the needs/requirements by various SDOs. For example, 3gpp
operator may set the lifetime to x value, where 3gpp2 operator sets it
to y value through the dynamic configuration.
> 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/>
>
--
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/>