RE: AW: backwards compatible introduction of NEW attribute such a s CU I

[Avi Lior <avi@bridgewatersystems.com>]

Bernard, Lothar,

I stated this in another email but I want to do it here as well.  I don't
think that CUI should be tied down to 3579.

I think business drivers should determine whether or not CUI is used.

Furthermore:

Barney's issue 22 raised the question "who needs the CUI?"  Barney later
answers this question  "it is the NAS owner which *requires* CUI presence"

Lothar "statead (and still maintain) my opinion  that it is the home server
operator who *requires* CUI presence."

I don't agree with Lothar at all. Barney is absolutely correct. In fact this
statement by Barney reflects the driver for CUI: 

"the NAS owner only requires CUI if iPass won't do business without it.
That's not a technical requirement, or a logical requirement, but it is,
perhaps, a statement about the real world."

The home network doesn't need CUI. CUI provides the following capabilities:
-it allows correlation of mulitple access-request/access-accepts to the same
user.
-it allows correlation of accounting sessions to the same user.

The home network can do the above correlation without the need for CUI.
Since it knows the identity of the user it can correlate multiple
access-request to that user and thus can prevent multiple logons.

The home network can use class to correlate accounting information to the
same user.

In order for Proxies to perform the same operations they need CUI.  This is
what iPass requires to do business and other intermediaries.


> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com] 
> Sent: Thursday, December 16, 2004 10:23 AM
> To: Lothar Reith
> Cc: 'Adrangi, Farid'; 'radiusext@ops.ietf.org'
> Subject: Re: AW: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> > Is that true for the roaming privacy application ?  And is 
> a privacy 
> > NAI well defined ? Is anonymous@example.com also a privacy NAI ? Or 
> > 
> anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-priv
> > acy@ex
> > ample.com ?
> 
> One of the tasks for RFC 2486bis was to add privacy support 
> to RFC 2486. Are you claiming that the draft does not define 
> this service?  My understanding was that "Privacy" in RFC 
> 2486bis is defined as an NAI without a user-id portion.  
> While I realize that there are RADIUS servers that treat user 
> "anonymous" differently, this is not universally implemented 
> (or even specified) so it will not interoperate.
> 
> > My proposal has been the other way round. But perhaps your proposal 
> > fits more easily with the backwards compatibility 
> requirement of both 
> > the server and the NAS.
> 
> The problem with requiring that the RADIUS server *always* 
> send CUI is that no existing RADIUS servers do this.  
> However, if we restrict the applicability of CUI, then it may 
> be reasonable to expect that a RADIUS server that implements 
> RFC 3579 and "Privacy" as defined in RFC 2486bis will be 
> upgraded to also support CUI.  CUI support therefore becomes 
> part of the "Privacy" functionality package.
> 
> > It requires however that the NAS is ALWAYS able to 
> INITIALLY DETERMINE 
> > the requirement for CUI presence. This means it may 
> ultimately have to 
> > rely on the end user presenting an identity which can be 
> identified by 
> > the NAS as Request to one of the upstream sever(s) saying: 
> > 
> "CUI-attribute-presence-required-in-the-accept-message-otherwise-I-wil
> > l-chan
> > ge-the-accept-into-a-reject" .
> 
> Yes.  And I think defining that sufficiently well is the task 
> of RFC 2486bis.
> 
> --
> 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/>