Subject: RE: Consensus on CUI Usage and Applicability
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Fri, 31 Dec 2004 09:15:02 -0800 (PST)

Sure.

On Fri, 31 Dec 2004 [email-masked] wrote:

> Bernard,
>
> Could we write the usage scenario up in an email, and send it to the
> list for a consensus call? That has significantly less overhead than
> writing a draft.
>
> thanks,
> John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 31 Dec 2004 07:04:00 +0000
content-class: urn:content-classes:message
Subject: RE: Consensus on CUI Usage and Applicability
Date: Fri, 31 Dec 2004 09:03:09 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

Could we write the usage scenario up in an email, and send it to the
list for a consensus call? That has significantly less overhead than
writing a draft.

thanks,
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> Sent: 31 December, 2004 01:10
> To: [email-masked]
> Subject: Consensus on CUI Usage and Applicability
>=20
>=20
> One of the guidelines for IETF work is "rough consensus and=20
> running code".
>=20
> Looking over the recent WG discussion on CUI usage and=20
> applicability, it
> is difficult to discern much in the way of consensus.  With respect to
> quite a few points (opacity, backward compatibility, NAS vs. Proxy vs.
> Server) RADEXT WG participants appear to be deeply divided.
>=20
> If the RADEXT WG cannot come to consensus on what CUI is intended to
> achieve and how it is to be used, then it seems unlikely that=20
> we will be
> able to make progress on completing this work item.  Therefore it is
> important for us to make progress on this, and figure out why opinions
> are so divergent.
>=20
> There are several potential explanations for the wide range of
> opinions that have been expressed:
>=20
> a. People are looking at CUI to solve several different problems.
> Depending on the problem of interest, the usage and applicability may
> differ substantially.  If this is the case, then we may be=20
> able to make
> progress by specifying the usage scenarios and describing how=20
> CUI can be
> used in each situation, omitting the scenarios on which the=20
> WG cannot come
> to consensus.
>=20
> b. Within a given usage scenario there may be differences as=20
> to the use
> and applicability of CUI.  If this is the problem, then we will not be
> able to proceed on that usage scenario.  Hopefully, this won't be
> the case for all usage scenarios.
>=20
> c. There is confusion about the usage of the existing Class attribute
> and that is affecting people's opinions on how CUI would be=20
> used. If this
> is the problem, then further discussion and clarifications within the
> specification should help.
>=20
> Based on the discussion so far, my guess is that a) may be=20
> closer to the
> mark than b).  However, the discussion so far also provides=20
> some evidence
> for c).
>=20
> In order to try to find our way through this issue, the=20
> Chairs would like
> to suggest the following approach:
>=20
> a.  Have the document editors write up a series of usage scenarios,
> describing how CUI would be used within each scenario, and how
> backward compatibility issues would be addressed.
>=20
> b. The Chairs will then call for consensus on each scenario, in order
> to isolate what usage scenarios have consensus and which do not.
>=20
> Our hope is that this approach will identify points of=20
> agreement that will
> allow the specification to move forward.  We can then focus=20
> on the points
> of disagreement to understand whether an alternative approach=20
> (such as use
> of different attributes, including Class) may be required.
>=20
> Comments welcome.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 30 Dec 2004 23:10:35 +0000
Date: Thu, 30 Dec 2004 15:09:37 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Consensus on CUI Usage and Applicability

One of the guidelines for IETF work is "rough consensus and running code".

Looking over the recent WG discussion on CUI usage and applicability, it
is difficult to discern much in the way of consensus.  With respect to
quite a few points (opacity, backward compatibility, NAS vs. Proxy vs.
Server) RADEXT WG participants appear to be deeply divided.

If the RADEXT WG cannot come to consensus on what CUI is intended to
achieve and how it is to be used, then it seems unlikely that we will be
able to make progress on completing this work item.  Therefore it is
important for us to make progress on this, and figure out why opinions
are so divergent.

There are several potential explanations for the wide range of
opinions that have been expressed:

a. People are looking at CUI to solve several different problems.
Depending on the problem of interest, the usage and applicability may
differ substantially.  If this is the case, then we may be able to make
progress by specifying the usage scenarios and describing how CUI can be
used in each situation, omitting the scenarios on which the WG cannot come
to consensus.

b. Within a given usage scenario there may be differences as to the use
and applicability of CUI.  If this is the problem, then we will not be
able to proceed on that usage scenario.  Hopefully, this won't be
the case for all usage scenarios.

c. There is confusion about the usage of the existing Class attribute
and that is affecting people's opinions on how CUI would be used. If this
is the problem, then further discussion and clarifications within the
specification should help.

Based on the discussion so far, my guess is that a) may be closer to the
mark than b).  However, the discussion so far also provides some evidence
for c).

In order to try to find our way through this issue, the Chairs would like
to suggest the following approach:

a.  Have the document editors write up a series of usage scenarios,
describing how CUI would be used within each scenario, and how
backward compatibility issues would be addressed.

b. The Chairs will then call for consensus on each scenario, in order
to isolate what usage scenarios have consensus and which do not.

Our hope is that this approach will identify points of agreement that will
allow the specification to move forward.  We can then focus on the points
of disagreement to understand whether an alternative approach (such as use
of different attributes, including Class) may be required.

Comments welcome.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 29 Dec 2004 23:09:41 +0000
Content-class: urn:content-classes:message
Subject: CUI version -01
Date: Wed, 29 Dec 2004 15:08:53 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Hi all,
I just submitted -01 version of the CUI.  The draft does yet appear in
I-D repository, but you can access it here :
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-01.txt.

This version provides resolutions to the following issues listed in
http://www.drizzle.com/~aboba/RADEXT/#Issue%2014.

Issue 14 (Bernard Aboba)
Issue 18 (Greg Weber)
Issue 21 and 22 (Barney Wolf)
Issue 35, 36, 46 (David Nelson)

In this version, the CUI is represented just in cleartext format -
please see the draft for more details.  Hope this version brings us
closer to some consensus.  Thanks to all reviewers and folks
participated in the discussions.

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 22:54:09 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Thu, 23 Dec 2004 17:53:29 -0500

Well,

I am not against have non opaque CUIs.

Regarding LEA. LEA is hard enough in one jurisdiction.  I wouldn't want to
guess or even try to understand what the ultimate solution for that problem
is.

The reason I didn't oppose having the other types of CUI is that I see no
harm in having them.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Thursday, December 23, 2004 4:06 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Hi Avi,
> 
> Continuing the requirements discussion still for one
> part:
> 
> > Regarding legal interception:
> > 
> > Yes they may want certain CUI forms but Opaque may also 
> sufficie.  For 
> > example, with Opaque values they may insist that the issuer of the 
> > opaque CUI not reuse any of the values for six months. That 
> is, they 
> > may issue a new opaque value for the a identity every 
> month. But will 
> > freeze the value for 6 months.
> > 
> > Then the law enforcement agency (LEA) can then issue a 
> court order and 
> > require that the issuer of the opaque value resolve it back to the 
> > user identity.
> 
> If legal interception is a requirement, I'm not sure the
> above is sufficient. There are multiple organizations and 
> countries involved. If I am visiting in country X and they 
> want to intercept all my usage in that country, it does not 
> help if CUI indicates "[email-masked]" -- particularly 
> if X and Y don't want to reveal to each other who they are 
> tracking. From the point of view of the access network and 
> country X, its much easier to just require cleartext CUIs...
> 
> (I'm just guessing that this might be one of the reasons
> why people want to have non-opaque CUIs. It would be good
> if someone could confirm this.)
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 21:42:10 +0000
Date: Thu, 23 Dec 2004 16:41:42 -0500
From: Barney Wolff <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI

On Thu, Dec 23, 2004 at 11:05:39PM +0200, Jari Arkko wrote:
> 
> >Regarding legal interception:
> >
> >Yes they may want certain CUI forms but Opaque may also sufficie.  For
> >example, with Opaque values they may insist that the issuer of the opaque
> >CUI not reuse any of the values for six months. That is, they may issue a
> >new opaque value for the a identity every month. But will freeze the value
> >for 6 months.
> >
> >Then the law enforcement agency (LEA) can then issue a court order and
> >require that the issuer of the opaque value resolve it back to the user
> >identity.
> 
> If legal interception is a requirement, I'm not sure the
> above is sufficient. There are multiple organizations and
> countries involved. If I am visiting in country X and they
> want to intercept all my usage in that country, it does
> not help if CUI indicates "[email-masked]" -- particularly
> if X and Y don't want to reveal to each other who they are
> tracking. From the point of view of the access network and
> country X, its much easier to just require cleartext CUIs...
> 
> (I'm just guessing that this might be one of the reasons
> why people want to have non-opaque CUIs. It would be good
> if someone could confirm this.)

This dives into very deep philosophical waters, both as to ethics and
even more profoundly as to the nature of identity.

CUI is CHARGEable user identity.  I've always taken that in the financial
sence, not in the sense of issuance of an indictment.  Even if one were
to accept the latter sense, what could the home server supply that would
uniquely identify a single individual out of the 6+E9 in the world?
Common name is not nearly unique enough, and in the case of many "persons
of interest" these days the variability in transliteration makes it
common for a single individual to legitimately appear variously in ASCII.

IANAL but I can imagine EU privacy regulations forbidding disclosure of
the user's "true" identity to a non-EU network owner, absent evidence of
abuse.  List decorum prevents me from expressing my opinion of my own
country's privacy climate.

-- 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 21:06:31 +0000
Date: Thu, 23 Dec 2004 23:05:39 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

Hi Avi,

Continuing the requirements discussion still for one
part:

> Regarding legal interception:
> 
> Yes they may want certain CUI forms but Opaque may also sufficie.  For
> example, with Opaque values they may insist that the issuer of the opaque
> CUI not reuse any of the values for six months. That is, they may issue a
> new opaque value for the a identity every month. But will freeze the value
> for 6 months.
> 
> Then the law enforcement agency (LEA) can then issue a court order and
> require that the issuer of the opaque value resolve it back to the user
> identity.

If legal interception is a requirement, I'm not sure the
above is sufficient. There are multiple organizations and
countries involved. If I am visiting in country X and they
want to intercept all my usage in that country, it does
not help if CUI indicates "[email-masked]" -- particularly
if X and Y don't want to reveal to each other who they are
tracking. From the point of view of the access network and
country X, its much easier to just require cleartext CUIs...

(I'm just guessing that this might be one of the reasons
why people want to have non-opaque CUIs. It would be good
if someone could confirm this.)

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 20:13:49 +0000
Date: Thu, 23 Dec 2004 15:13:32 -0500
From: Barney Wolff <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

On Thu, Dec 23, 2004 at 02:28:22PM -0500, Alan DeKok wrote:
> Barney Wolff <[email-masked]> wrote:
> > I beg to differ.  Class is simply an octet string sent, via a meandering
> > route,
> 
>   I'm not sure what you mean by "a meandering route".  The
> participants in the RADIUS conversation are well-known, and named.  We
> should use those names to avoid miscommunication.

Sorry for a failed attempt at humor.  I meant simply that Class is not
sent directly from the auth server to the acct server, but is relayed
through some number of proxies and the NAS.

> > from the sender of an Access-Accept to the receiver of an
> > Accounting-Request.  Any interpretation of the octets is strictly up
> > to those two parties, and no other characterization of Class can be made.
> 
>    I agree.  But for those two parties, the Class attribute
> establishes some kind of "opaque token" which they have associated
> with the session.  Semantically, this token is their determination of
> the "identity" of the session, where they determine what that identity
> means.

Class might well not be unique to session or even user.  My point, which
I've already belabored overmuch, was just to emphasize its opacity.

> > CUI is indeed assigned by the home server, but has nothing to do with
> > a specific session, but rather with the user of the session.
> 
>   To pick nits: the existence of a user is visible only through his
> existence in a specific session.  I don't think he CUI would be
> applicable to a session where there was no end-user involved, as that
> session would (almost by definition) not exist.

Again, by the business case(s) presented, CUI must have some cross-session
stability or it does no good.  That's all I was trying to say.

-- 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 20:03:01 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Season's Greetings.
Date: Thu, 23 Dec 2004 15:02:46 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E92A.5F369F50
Content-Type: text/plain

To all on the RADIUSEXT list.
 
I would like to wish you and yours a very happy and healthy holiday season
and a happy and healthy new year.
 
We have achieved a lot in the last year with the creation of this WG and
with the work that we are doing.
 
I am proud to be associated with the folks on this list.
 
Cheers and please be safe,
 
Avi

------------------------------------------------

Avi Lior                                    
Bridgewater Systems Corporation                
Phone :  (613) 591-9104 x6417

Cell    :  (613) 297-2177
E-mail :  <mailto:[email-masked]>
mailto:[email-masked]

www.bridgewatersystems.com <http://www.bridgewatersystems.com/>  

 

------_=_NextPart_001_01C4E92A.5F369F50
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D172265719-23122004>To =
all on the=20
RADIUSEXT list.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D172265719-23122004>I =
would like to wish=20
you and yours a very happy and healthy holiday season and a happy and =
healthy=20
new year.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D172265719-23122004>We =
have achieved a=20
lot in the last year with the creation of this WG and with the work =
that we are=20
doing.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D172265719-23122004>I am =
proud to be=20
associated with the folks on this list.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN =
class=3D172265719-23122004>Cheers and please be=20
safe,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D172265719-23122004>Avi</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV class=3DSection1>
<P align=3Dleft><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><?xml:namespace prefix =
=3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p></SPAN></P>
<P class=3DMsoNormal><STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">------------------------------------------------</SPAN></STRONG=
></P>
<P class=3DMsoNormal><STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: Verdana">Avi=20
Lior</SPAN></STRONG><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
<BR>Bridgewater Systems=20
Corporation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>Phone :&nbsp; (613) 591-9104 x6417</SPAN></P>
<P class=3DMsoNormal><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: #0080c0; FONT-FAMILY: =
Verdana">Cell&nbsp;&nbsp;&nbsp;&nbsp;:&nbsp;=20
(613)&nbsp;297-2177<BR>E-mail : </SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><A=20
href=3D"mailto:[email-masked]"><SPAN=20
style=3D"COLOR: =
#0080c0">mailto:[email-masked]</SPAN></A></SPAN><o:p></o:p><=
/P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial size=3D2><A=20
href=3D"http://www.bridgewatersystems.com/">www.bridgewatersystems.com</=
A></FONT>&nbsp;<o:p></o:p></P></DIV>
<DIV><o:p>&nbsp;</o:p></DIV></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4E92A.5F369F50--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 19:54:29 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Thu, 23 Dec 2004 14:53:55 -0500

Hi David,

Great let me summarize here.

Regarding scenario 1)  I could agree that that is in scope of the document:
Notice I reworded it a bit.

"The home network provides the CUI as a suplemental or alternative
information to User-Name."

Scenario 2) is out.  We the authors decided to keep CUI out of the COA
domain.  But maybe we should put it back in.  Why? In the absence of a
user-identity in the User-Name as in EAP methods we may not be able to use
User-Name since it would be too broad (it will cover all the realm of users
belonging to example.com).  Hmmmm something to think about.

Scenario 3) I think we agree.

So now to the argument of what format of CUI to support:

An opaque CUI will suffice for scenario 2 and 3.  Which are the original
intent of this draft.

At some point later we added other possibilities for CUI.  One driver was to
match Diameter, the other one is that it came from GSMA folks.  A CUI that
is not opaque can server scenario 3 and scenario 1.

So as Jari points out:

"However, looking at the definition of the CUI, it seems
that people want *also* the ability to use a cleartext
user handle of a specific format. One reason for wanting
to do this would be to, say, be able to feed the identity
to an existing roaming/accounting/billing system that can
only support a specific type of an identity. Is this
the reason why we have non-opaque values in the document
too? Or is there some other reason, such as tracing/
legal interception/logging need to see actual user
identities?"

At this point we can go to a CUI that is pure Opaque (like Class) and only
support scenario 3; or
We can allow for the other values and stick the above text in the draft.

Also note that if we stay with Opaque, that would not prevent a SDO like GSM
to specify what is in the CUI blob.  But obviously they would do that only
for their networks.

Lastly, related to the Opaque CUI, is the issue that concerns Barney and
others, and  that is how long is the binding of the Opaque value to the
Identity.

My position was to leave that out but only because I don't think we can
specify this in the IETF.  It would change depending on many circumstances.
Types of networks, bgusiness relationships, etc.  So we let others figure it
out. If anyone has a good answer to this problem please let us know.

We could say that: "When the value is opaque, the lifetime of the binding to
the true identity, is not in scope.  This duration MUST be understood by the
parties, and it SHOULD NOT be long enough to comprimse the user's identity
when privacy is concerned."

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 4:39 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > If the home network is compliant to the draft it the assertion
> > must be of a User or a Chargeable Entity in the home network. 
> > Any other meaning are not acceptable.
> 
> OK. That's a helpful clarification.
> 
> > Huh? Accounting-Session-Id? Accounting Session Id changes even
> > within a single Login.  Its purpose is to link Starts with Interims 
> > and Stops.
> 
> I'm fishing for a better understanding of CUI.  The term 
> "assertion of identity" is pretty general.

Yes it is. Does it need to be tightened? Give us some words. Note Identity
is defined to be Chargeable User Identity.  So "Assertion of Chargeable User
Identity".

> > > 1.) The NAS includes a previously received CUI in 
> Accounting-Request 
> > > messages, as supplemental or alternative information to 
> User-Name or 
> > > Acct-Session-ID.
> > 
> > What problem does this usecase address? If this usecase is trying to
> > *STRICTLY* solve the association of an particular 
> Access-Request to an 
> > accounting stream associated with that session, Irrespective of the
> User
> > Identity. Then this use case is not in-scope.  Class and
> Acct-Session-Id
> > could do this.   So we would exclude this one. It's covered by other
> RFCs.
> 
> I'd swear this use case is described in the 00 CUI draft.  
> :-)  If it's out of scope, then I'm even more confused...  
> Perhaps the analogy to Acct-Session-ID has clouded the issue for you?

Well so ignoring accounting id. The NAS includes a previously received CUI
in Accounting-Request message as suplemental or alternative information to
User-name.

Okay. But for whom? For the home network? No. For intermediaries perhaps
yes.

But even then, I think the wording of the use case is more accurate this
way:

"The home network provides the CUI as a suplemental or alternative
information to User-Name."

> So, the RADIUS Client never includes the CUI attribute in any 
> RADIUS messages, with the possible exception of a NULL 
> version in an Access-Request as capability advertisement?  
> That's not what the 00 CUI draft says.

Hold on lets reset the converstation. Here it the general behavior:

The RADIUS Client includes the NUL CUI in the Access Request to signal its
requirement for the CUI.
Upon Receiving the NUL CUI, the RADIUS server that owns the user identity
MUST supply the CUI in an Access-Accept.

The RADIUS Client that requested the CUI MUST ensure that it copies the CUI
received in an Access Accept to the Accounting messages associated with that
session.

> > > 2.) The HAAA (or Proxies??) include CUI in a CoA-Request 
> message as 
> > > a session identifier, of sorts.  (Of course, this begs 
> the question 
> > > of whether CUI is always unique to a particular session...)
> > 
> > I think we dropped CUI for dynamic authorization.
> 
> There are still references in the 00 CUI draft.

There has been other versions since that may not have hit the street.

>  
> > > 3.) The NAS may compare the value of one instance of CUI 
> to another 
> > > instance of CUI to get some idea of whether the Home AAA Server 
> > > considerers the identity of the users represented by these CUI 
> > > instances as "equivalent" in some sense -- either the 
> same user or 
> > > members of the same user group.
> > 
> > Yes NAS or to be even more precise RADIUS Client.
> 
> We need to resolve the disposition of use case (1) above, as 
> it does appear in the 00 CUI draft, and has been frequently 
> discussed on the list.  We also need to see if there is 
> consensus on these use cases as being the only important ones 
> to consider.  

So usecase one I belive I covered up there.
 
> If that consensus is obtained, then I would agree that the CUI format
> (syntax) should be changed to an opaque token, and perhaps we 
> could borrow the syntax description from Class (but not the 
> semantics description!).  In that case it would be the 
> explicit CUI "name formats" (01 - 04) that should be removed 
> from the draft.  We should also include text that prohibits 
> RADIUS Clients from attempting to interpret the CUI content, 
> or make any other local use of CUI beyond the equality 
> comparison operation.
> 
> I have heard other use cases advocated on the list, however, 
> so it will be important to poll for consensus on this issue.
> 
>  
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Thu, 23 Dec 2004 19:16:28 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Scope of applicability for CUI 
Date: Thu, 23 Dec 2004 14:28:22 -0500
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> I beg to differ.  Class is simply an octet string sent, via a meandering
> route,

  I'm not sure what you mean by "a meandering route".  The
participants in the RADIUS conversation are well-known, and named.  We
should use those names to avoid miscommunication.

> from the sender of an Access-Accept to the receiver of an
> Accounting-Request.  Any interpretation of the octets is strictly up
> to those two parties, and no other characterization of Class can be made.

   I agree.  But for those two parties, the Class attribute
establishes some kind of "opaque token" which they have associated
with the session.  Semantically, this token is their determination of
the "identity" of the session, where they determine what that identity
means.

> CUI is indeed assigned by the home server, but has nothing to do with
> a specific session, but rather with the user of the session.

  To pick nits: the existence of a user is visible only through his
existence in a specific session.  I don't think he CUI would be
applicable to a session where there was no end-user involved, as that
session would (almost by definition) not exist.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 17:18:09 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Barney Wolff <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Thu, 23 Dec 2004 12:17:44 -0500

Jari, David, et al

To your last part....
> Is this
> the reason why we have non-opaque values in the document
> too? Or is there some other reason, such as tracing/
> legal interception/logging need to see actual user identities?

As I recall, the non-opaque values came about from GSMA and also to align
this attribute with Diameter CC.

Opaque CUI was solving the original problem just fine.

I think the other values were added in cases where user privacy was not
required and EAP was used. So let me give an example.

In WiFi EAP is very important to use EAP because the security issues over
the air. But in the AAA infrastructure it may not be that important because
AAA infrastructure typically runs over a secure network.  So you could use a
CUI that reveals the identity of the user (IMSI etc) in the AAA
infrastructure.  Now you can actaully use a more "concrete" identity for the
user.

Also note another "feature" is that even when using the SIP URI forms and
the NAI form you may still hide the true identity of the user.  That is the
NAI form could be [email-masked] revealing the realm of the user
(west coast of example.com organization) but hiding the identity of the
user.

I belive in the latest version we give examples of these.

Regarding legal interception:

Yes they may want certain CUI forms but Opaque may also sufficie.  For
example, with Opaque values they may insist that the issuer of the opaque
CUI not reuse any of the values for six months. That is, they may issue a
new opaque value for the a identity every month. But will freeze the value
for 6 months.

Then the law enforcement agency (LEA) can then issue a court order and
require that the issuer of the opaque value resolve it back to the user
identity.

Avi 

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, December 23, 2004 8:25 AM
> To: Barney Wolff; Nelson, David
> Cc: [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Barney Wolff wrote in response to David Nelson:
> 
> >>Given this description of CUI, what is the utility of the
> opaque data
> >>format of CUI?  I understand that opaqueness can be rendered
> >>transparent with the bilateral sharing of proprietary information, 
> >>pursuant to a business contract.  However, that exception 
> >>notwithstanding, if the intent of CUI is visibility and 
> utility to the
> >>NAS and to the Proxies, I suggest that the opaque data format be
> >>removed from the draft.
> > 
> > 
> > Whether the CUI is opaque or an NAI does not change the
> fact that it
> > should be meaningful only to the home server.  The only
> test that the
> > NAS/proxy should be able to make on CUI is for equality to some
> > previously seen CUI.  Otherwise the privacy of the user has been 
> > compromised for no legitimate reason.  A business agreement on how 
> > long a one-to-one relation between CUI and the "true" user identity 
> > must persist does not depend in any way on the form of the 
> CUI.  Given
> > that, I would have said the opposite, that CUI should always be an
> > opaque octet string.
> 
> And then David Nelson responded:
> 
> > Well, you and Avi seem to agree on this, but if that is the case, 
> > how is CUI different from Class?
> 
> As others have pointed out, CUI contents are still meant to
> be looked at, just that the only basic operation expected to 
> be done for them is equality test.
> 
> But this brings me to a new issue. Remember how we agreed
> that CUI helps in policy decisions, such as the 
> one-session-at-a-time rule. My question is whether there's a 
> second utility which is not quite as apparent because it 
> operates again at the "billing layer" which is not 
> standardized. We can make CUI an opaque entity, only designed 
> for the equality test. An opaque CUI can also be used as a 
> billing handle, as long as organizations X and Y agree that 
> they are using the CUIs in this process, either in the RADIUS 
> accounting messages or in the postprocessing/billing 
> transactions or in both.
> 
> However, looking at the definition of the CUI, it seems
> that people want *also* the ability to use a cleartext
> user handle of a specific format. One reason for wanting
> to do this would be to, say, be able to feed the identity
> to an existing roaming/accounting/billing system that can only support 
> a specific type of an identity. Is this the reason why we have 
> non-opaque values in the document too? Or is there some other reason, 
> such as tracing/ legal interception/logging need to see actual user
> identities?
> 
> --Jari
> 
> --
> to unsubscribe send a message to
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 16:34:48 +0000
Date: Thu, 23 Dec 2004 11:34:11 -0500
From: Barney Wolff <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI

> Alan DeKok wrote:
> 
> >  User-Name is a token by which the NAS which establishes the
> >"identity" of a user within a session.
> >
> >  Class is one or more tokens by which each proxying RADIUS server
> >establishes it's own view of the "identity" of a session.

I beg to differ.  Class is simply an octet string sent, via a meandering
route, from the sender of an Access-Accept to the receiver of an
Accounting-Request.  Any interpretation of the octets is strictly up
to those two parties, and no other characterization of Class can be made.

> >  CUI is proposed to be a token by which the home server establishes
> >it's own view of the "identity" of a session.  (If I interpret the
> >proposal correctly.)

CUI is indeed assigned by the home server, but has nothing to do with
a specific session, but rather with the user of the session.  CUI would
be useless if there were not a one-to-one relation between CUI and the
true user for some period of time.  Indeed, I am still somewhat nervous
about the lack of definition of how long that period should be, since
a particular server may be dealing with requests from more than one
set of clients.

The home server should be protective of its users' privacy (else
why use a non-individual User-Name?) so should want the relation
to persist for the shortest possible time.  The client networks
naturally want the CUI<->user relation to persist for as long as
possible, to ease detection of abuse.  So there will always be
something of an adversarial relationship to the process.  The current
draft leaves the negotiation of the durability of CUI to an out-of-band
process, presumably between humans.  I wonder if instead of a NUL
CUI the device demanding CUI should insert the time until which it
demands that the CUI<->user relation be unique.  That's a violation
of KISS but would make life much easier for a server dealing with
multiple client networks.  A simpleminded server could ignore the
value and just note the presence of CUI in the request, if it has
to deal with only one value of durability.

-- 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 15:40:45 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Thu, 23 Dec 2004 10:39:33 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Jari Arkko writes...

> But this brings me to a new issue. Remember how we agreed that
> CUI helps in policy decisions, such as the one-session-at-a-time
> rule. My question is whether there's a second utility which
> is not quite as apparent because it operates again at the
> "billing layer" which is not standardized. We can make CUI
> an opaque entity, only designed for the equality test. An
> opaque CUI can also be used as a billing handle, as long
> as organizations X and Y agree that they are using the CUIs
> in this process, either in the RADIUS accounting messages
> or in the postprocessing/billing transactions or in both.
>=20
> However, looking at the definition of the CUI, it seems
> that people want *also* the ability to use a cleartext
> user handle of a specific format. One reason for wanting
> to do this would be to, say, be able to feed the identity
> to an existing roaming/accounting/billing system that can
> only support a specific type of an identity. Is this
> the reason why we have non-opaque values in the document
> too? Or is there some other reason, such as tracing/
> legal interception/logging need to see actual user
> identities?

I guess this is what I've been poking at in the past few days.  Do we
have two different problems that we're attempting to solve using a
single attribute?  The "paradox" as I've stated it is maintaining the
notion of CUI as an opaque handle and at the same time providing for
explicit (and ostensibly clear-text, human readable) name formats in the
same attribute.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 13:25:08 +0000
Date: Thu, 23 Dec 2004 15:24:32 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Barney Wolff <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

Barney Wolff wrote in response to David Nelson:

>>Given this description of CUI, what is the utility of the opaque data
>>format of CUI?  I understand that opaqueness can be rendered transparent
>>with the bilateral sharing of proprietary information, pursuant to a
>>business contract.  However, that exception notwithstanding, if the
>>intent of CUI is visibility and utility to the NAS and to the Proxies, I
>>suggest that the opaque data format be removed from the draft.
> 
> 
> Whether the CUI is opaque or an NAI does not change the fact that
> it should be meaningful only to the home server.  The only test
> that the NAS/proxy should be able to make on CUI is for equality
> to some previously seen CUI.  Otherwise the privacy of the user has
> been compromised for no legitimate reason.  A business agreement
> on how long a one-to-one relation between CUI and the "true" user
> identity must persist does not depend in any way on the form of the
> CUI.  Given that, I would have said the opposite, that CUI should
> always be an opaque octet string.

And then David Nelson responded:

> Well, you and Avi seem to agree on this, but if that is the 
> case, how is CUI different from Class?

As others have pointed out, CUI contents are still meant to be
looked at, just that the only basic operation expected to be
done for them is equality test.

But this brings me to a new issue. Remember how we agreed that
CUI helps in policy decisions, such as the one-session-at-a-time
rule. My question is whether there's a second utility which
is not quite as apparent because it operates again at the
"billing layer" which is not standardized. We can make CUI
an opaque entity, only designed for the equality test. An
opaque CUI can also be used as a billing handle, as long
as organizations X and Y agree that they are using the CUIs
in this process, either in the RADIUS accounting messages
or in the postprocessing/billing transactions or in both.

However, looking at the definition of the CUI, it seems
that people want *also* the ability to use a cleartext
user handle of a specific format. One reason for wanting
to do this would be to, say, be able to feed the identity
to an existing roaming/accounting/billing system that can
only support a specific type of an identity. Is this
the reason why we have non-opaque values in the document
too? Or is there some other reason, such as tracing/
legal interception/logging need to see actual user
identities?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 13:16:47 +0000
Date: Thu, 23 Dec 2004 15:16:06 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

Alan DeKok wrote:

>   User-Name is a token by which the NAS which establishes the
> "identity" of a user within a session.
> 
>   Class is one or more tokens by which each proxying RADIUS server
> establishes it's own view of the "identity" of a session.
> 
>   CUI is proposed to be a token by which the home server establishes
> it's own view of the "identity" of a session.  (If I interpret the
> proposal correctly.)
> 
>   The attributes are created by different entities in the network, and
> are intended to do different things.  There's only one NAS in a
> session, so there can be only one User-Name.  There are multiple
> proxying servers, so there can be multiple Class attributes.  There's
> only one home server, so there can only be one CUI.
> 
>   Taken in combination, the above attributes allows each participant
> in the RADIUS conversation to associate a "token" with a login
> session, that it, and it alone, controls.
> 
>   Like the User-Name, the CUI should be (at some level) visible &
> interpretable by every participant in the RADIUS conversation.  This
> may include a definition of CUI as an opaque token.  The important
> difference between CUI and Class, though, is that CUI is defined to be
> a token added by the home server.  All proxying servers, and the NAS,
> can use & interpret CUI in that context.  They are explicitly
> forbidden from doing so for the Class attribute.

This is a good summary. Thanks!

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 23 Dec 2004 13:15:57 +0000
Date: Thu, 23 Dec 2004 15:14:55 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Emile van Bergen <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

Emile van Bergen wrote:

> And I also think that we shouldn't try to hide the fact that Class can
> also solve a lot of the scenarios. It should be /very/ clear what the
> differences and limitations are of each, eg.:

This would be a really valuable part of the new document.
If you have problem A, go use Class. If you have problem B,
use CUI. If you have problem C, go use User-Name. And so on...
not necessarily to enumerate *all* possible scenarios, but
some guidance here would really go a long way towards
clarifying to future readers what should be used in what
case.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 22 Dec 2004 23:13:28 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Scope of applicability for CUI 
Date: Wed, 22 Dec 2004 18:25:20 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Not 100% accurate. User-Name may only be used for routing. Right?

  ... to the home server, which is the only one that can establish
user identity.  In addition, the User-Name often contains the identity
of the home server.

  It's a matter of getting to a common terminology.

> Again not 100% accurate.  We can't really say what class is used for.

  It's used by each proxying server, to associate it's local, private,
meaning to a session.

> So to make sure that we are 100% accurate: the identity is not for for the
> homenetwork its for the those outside the homenetwork that require this
> assertion by the home network to do business.

  I agree.

> I suppose this can be correct.  That is if we agree that Class is used for
> identity tracking.

  Not "user" identity, but "session" identity.

> -We can't use Class to do what we want because the standards already tell us
> what Class is used for.

  Agreed.

  I just want to be sure I understand the threat models of CUI, and
that it's design and/or description addresses those threats.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 21:40:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 16:39:22 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> If the home network is compliant to the draft it the assertion=20
> must be of a User or a Chargeable Entity in the home network.=20
> Any other meaning are not acceptable.

OK. That's a helpful clarification.

> Huh? Accounting-Session-Id? Accounting Session Id changes even=20
> within a single Login.  Its purpose is to link Starts with Interims=20
> and Stops.

I'm fishing for a better understanding of CUI.  The term "assertion of
identity" is pretty general.

> > 1.) The NAS includes a previously received CUI in
> > Accounting-Request messages, as supplemental or alternative
> > information to User-Name or Acct-Session-ID.
>=20
> What problem does this usecase address? If this usecase is trying to
> *STRICTLY* solve the association of an particular Access-Request to an
> accounting stream associated with that session, Irrespective of the
User
> Identity. Then this use case is not in-scope.  Class and
Acct-Session-Id
> could do this.   So we would exclude this one. It's covered by other
RFCs.

I'd swear this use case is described in the 00 CUI draft.  :-)  If it's
out of scope, then I'm even more confused...  Perhaps the analogy to
Acct-Session-ID has clouded the issue for you?

So, the RADIUS Client never includes the CUI attribute in any RADIUS
messages, with the possible exception of a NULL version in an
Access-Request as capability advertisement?  That's not what the 00 CUI
draft says.

> > 2.) The HAAA (or Proxies??) include CUI in a CoA-Request
> > message as a session identifier, of sorts.  (Of course, this
> > begs the question of whether CUI is always unique to a
> > particular session...)
>=20
> I think we dropped CUI for dynamic authorization.

There are still references in the 00 CUI draft.
=20
> > 3.) The NAS may compare the value of one instance of CUI to
> > another instance of CUI to get some idea of whether the Home
> > AAA Server considerers the identity of the users represented
> > by these CUI instances as "equivalent" in some sense --
> > either the same user or members of the same user group.
>=20
> Yes NAS or to be even more precise RADIUS Client.

We need to resolve the disposition of use case (1) above, as it does
appear in the 00 CUI draft, and has been frequently discussed on the
list.  We also need to see if there is consensus on these use cases as
being the only important ones to consider. =20

If that consensus is obtained, then I would agree that the CUI format
(syntax) should be changed to an opaque token, and perhaps we could
borrow the syntax description from Class (but not the semantics
description!).  In that case it would be the explicit CUI "name formats"
(01 - 04) that should be removed from the draft.  We should also include
text that prohibits RADIUS Clients from attempting to interpret the CUI
content, or make any other local use of CUI beyond the equality
comparison operation.

I have heard other use cases advocated on the list, however, so it will
be important to poll for consensus on this issue.

=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 21:09:49 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 16:09:23 -0500

David ,

See inline.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 3:01 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> While my last posting in this thread addressed process 
> issues, here I attempt to address substance.
>  
> > They use it as a number. So if CUI is "234OIUOIU" they know 
> that that 
> > value represents an assertion by the home network that this is 
> > represent user A in my network.
> 
> In the absence of any bindings, it would appear that the CUI, 
> as you describe it, is an assertion by the Home AAA Server 
> that the content is a token that represents *some* user, or 
> group of users, known to the HAAA.  It would be a stretch to 
> assert that it represents "user A" or any other *specific* 
> meta-user.  The only binding is that the CUI token is 
> associated with the current NAS service session, as 
> authorized by the Access-Accept message in which the CUI appears.

If the home network is compliant to the draft it the assertion must be of a
User or a Chargeable Entity in the home network.  Any other meaning are not
acceptable.
  
> > I think though that there is consensus on the following:
> > -CUI is for the entities outside the home network;
> > -It is needed in cases where clients need to have an identity
> assertion
> > especially where there is no such possibility as in the 
> case where the 
> > username cannot be used for that purpose.

> OK.  So in this use case CUI is an alternate to User-Name (or 
> possibly to Acct-Session-ID).

Huh? Accounting-Session-Id? Accounting Session Id changes even within a
single Login.  Its purpose is to link Starts with Interims and Stops. That's
it.
 
> > No. The "How: is not important. The "What" is. How you 
> calculate the 
> > number is really up to the operator.  The important thing is the 
> > "What" which is what the number stands for. That is what we are to 
> > standardize.
> 
> I take it you are proposing to exclude from consideration any 
> use cases for CUI other than:
> 
> 1.) The NAS includes a previously received CUI in 
> Accounting-Request messages, as supplemental or alternative 
> information to User-Name or Acct-Session-ID.

What problem does this usecase address? If this usecase is trying to
*STRICTLY* solve the association of an particular Access-Request to an
accounting stream associated with that session, Irrespective of the User
Identity. Then this use case is not in-scope.  Class and Acct-Session-Id
could do this.   So we would exclude this one. It's covered by other RFCs.

> 2.) The HAAA (or Proxies??) include CUI in a CoA-Request 
> message as a session identifier, of sorts.  (Of course, this 
> begs the question of whether CUI is always unique to a 
> particular session...)

I think we dropped CUI for dynamic authorization. BTW CUI would identify all
sessions for the user on that NAS, just the same as username would.  You
need a session identifier (e.g., Acct-Session-Id) to surgically remove a
particular session of a user.

> 3.) The NAS may compare the value of one instance of CUI to 
> another instance of CUI to get some idea of whether the Home 
> AAA Server considerers the identity of the users represented 
> by these CUI instances as "equivalent" in some sense -- 
> either the same user or members of the same user group.

Yes NAS or to be even more precise RADIUS Client.
 
> I think it is true that the Class attribute could be used for 
> (1) but not for (2) or (3).
                       
> Does that sound about right?

As indicated, yes. 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 20:01:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 15:00:32 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

While my last posting in this thread addressed process issues, here I
attempt to address substance.
=20
> They use it as a number. So if CUI is "234OIUOIU" they know that
> that value represents an assertion by the home network that this=20
> is represent user A in my network.

In the absence of any bindings, it would appear that the CUI, as you
describe it, is an assertion by the Home AAA Server that the content is
a token that represents *some* user, or group of users, known to the
HAAA.  It would be a stretch to assert that it represents "user A" or
any other *specific* meta-user.  The only binding is that the CUI token
is associated with the current NAS service session, as authorized by the
Access-Accept message in which the CUI appears.
=20
> I think though that there is consensus on the following:
> -CUI is for the entities outside the home network;
> -It is needed in cases where clients need to have an identity
assertion
> especially where there is no such possibility as in the case where the
> username cannot be used for that purpose.
=20
OK.  So in this use case CUI is an alternate to User-Name (or possibly
to Acct-Session-ID).
=20
> No. The "How: is not important. The "What" is. How you calculate the
> number is really up to the operator.  The important thing is the=20
> "What" which is what the number stands for. That is what we are to
> standardize.

I take it you are proposing to exclude from consideration any use cases
for CUI other than:

1.) The NAS includes a previously received CUI in Accounting-Request
messages, as supplemental or alternative information to User-Name or
Acct-Session-ID.

2.) The HAAA (or Proxies??) include CUI in a CoA-Request message as a
session identifier, of sorts.  (Of course, this begs the question of
whether CUI is always unique to a particular session...)

3.) The NAS may compare the value of one instance of CUI to another
instance of CUI to get some idea of whether the Home AAA Server
considerers the identity of the users represented by these CUI instances
as "equivalent" in some sense -- either the same user or members of the
same user group.

I think it is true that the Class attribute could be used for (1) but
not for (2) or (3).

Does that sound about right?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 19:21:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 14:20:59 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> We are not looking for consensus of the use cases.  I don't=20
> belive that we would ever achieve consensus on the list for=20
> all or even most use cases.

But isn't achieving a level of "rough consensus" a fundamental
cornerstone of the IETF process?  Are you recommending that the WG
standardize the syntax of CUI without standardizing the semantics (which
I believe requires understanding the use cases)?

> > Is there another, more satisfying, resolution to this
> > apparent paradox?
>=20
> I don't see a paradox but lets just agree to disagree and=20
> move on.

Well, if there *is* a paradox, then I don't see how we can "move on".  I
assert that one property of formal standards definition (such as IETF
Standards Track protocols) is that they don't contain any mysteries,
unresolved paradoxes, or other points of ambiguity or likely confusion.
The "document quality" requirement for standards is that anyone
reasonably well practiced in the art can read the document and create an
interoperable implementation, without external hints or context.
=20
> And even if I agree there is a paradox.  I don't think all=20
> paradoxes need to be solved.

In IETF Standards Track protocols they do!  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 19:06:22 +0000
From: Avi Lior <[email-masked]>
To: 'John Schnizlein' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 14:06:08 -0500

John,

You must have snoozed at the point of the lesson.

"Acounting Server" that is in the same adminsirative domain as the issuer of
the Class.

The Accounting Server could be the RADIUS Server or not.  But because it is
in the same realm it therefore it knows what is in the Class.

I don't know about common practice -- but I don't think that is germain to
how class works.

Does that help?

Avi

> -----Original Message-----
> From: John Schnizlein [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 1:45 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> At 11:16 AM 12/22/2004, Avi Lior wrote:
> >...
> >I think you don't understand how class works.
> >The fundemental piece that you are missing is that the only 
> entity that can
> >draw any meaning out of the "Class" attribute is the entity 
> that issued the
> >"Class" attribute.  This is well documented in 2865.
> 
> Since David has tutored me in subtleties of the Class 
> attribute, I suspect he understands it better than most. I am 
> still trying to catch up..
> 
> My reading of its specification in RFC 2865 (quoted in 
> entirety below) is that the accounting server is expected to 
> be able to extract meaning from the Class attribute sent to 
> the NAS by the authentication server. Isn't it common 
> practice for these to be different servers?
> 
> John
> 
> 5.25.  Class
> 
>    Description
> 
>       This Attribute is available to be sent by the server to 
> the client
>       in an Access-Accept and SHOULD be sent unmodified by 
> the client to
>       the accounting server as part of the Accounting-Request 
> packet if
>       accounting is supported.  The client MUST NOT interpret the
>       attribute locally.
> 
>    A summary of the Class Attribute format is shown below.  The fields
>    are transmitted from left to right.
> 
>     0                   1                   2
>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>    |     Type      |    Length     |  String ...
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> 
>    Type
> 
>       25 for Class.
> 
>    Length
> 
>       >= 3
> 
>    String
> 
>       The String field is one or more octets.  The actual 
> format of the
>       information is site or application specific, and a robust
>       implementation SHOULD support the field as 
> undistinguished octets.
> 
>       The codification of the range of allowed usage of this field is
>       outside the scope of this specification.
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 18:54:12 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 13:54:01 -0500

Hi David,

See comments inline.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 11:56 AM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > If CUI was carried in the Class attribute then NASes (or more
> > accurately) RADIUS clients would have to infere what is in the
> > Class attribute. This is because Class can carry more then just
> > CUI.
> 
> Agreed.  However, if the only "consumer" of CUI is the Home 
> AAA server, then it doesn't matter if CUI is commingled with 
> Class.  So therefore, NASes and Proxies must be "consumers" of CUI.

Yes. And that is why we say that Home Netowrk is the producer of CUI and not
the consumer of CUI.

> > Since CUI servers one purpose as defined by the draft then the
> > RADIUS clients just need to use it without interpreting its 
> > contents.
> 
> I guess this is what still confuses me -- how the NASes and 
> Proxies make use of the CUI without interpreting it.  That 
> leads me to believe they treat it as an opaque cookie, 
> similar to (but subtly different from) Class.  What, exactly, 
> do the NASes and Proxies do with this CUI cookie? Is that not 
> for the RFC reader to know?

They use it as a number. So if CUI is "234OIUOIU" they know that that value
represents an assertion by the home network that this is represent user A in
my network.  That is why originally we wanted to call it an Alias.

A lot different then Class.  Because Class has no such meaning and can have
no such meaning from a standard point of view. The purpose and use of Class
is already cast in stone.

 
> > Are you suggesting the CUI would be "TEXT" as opposed to "String".
> > I hope not.
> 
> While I had not explicitly made that connection, it might be 
> logical in support of some of the suggested use cases.  Let 
> me be clear -- it is not at all evident to me that there is 
> consensus on the list as to what the CUI use cases are.  
> Quite a few differing suggestions have been made (and not all 
> of them by the authors of the CUI draft).

We are not looking for consensus of the use cases.  I don't belive that we
would ever achieve consensus on the list for all or even most use cases.

I think though that there is consensus on the following:
-CUI is for the entities outside the home network;
-It is needed in cases where clients need to have an identity assertion
especially where there is no such possibility as in the case where the
username cannot be used for that purpose.

I think that other use cases are possible.  And we have some suggest them.
 
> > I mean one of the most crucial piece of evidence would be the 
> > User-name attribute which is a String.  So are we going to re-write 
> > all of these attributes in "TEXT". Lets get real here.
> 
> Please be assured that I am "real".  :-)  The User-Name 
> attribute was defined in the very first RADIUS RFC, before 
> the introduction of the Text data type.  Therefore it is 
> still String.  I suspect most implementations, however, in 
> fact treat it as Text.

And is that broken?  I don't think so.
When CUI is opaque then it should be able to take any octet as a value. 

> > I think presentation of a packet has a hex dump as evidence would
> > *not* be considered novel in judice prudence.
> 
> That may be so.  Let me play amateur attorney here for a 
> second and suggest that learned counsel for the plaintiff 
> would not likely recommend HEX format evidence as the 
> preferential format, given a
> choice.  :-)   The difference being what you *could* do, if 
> pressed, and
> what would be *convenient* to do, given some influence over 
> the choice. Why make life complicated?

Exactly why make life complicated. Lets just move on here ;-)

> > CUI is a String and is no different then User-Name also a 
> string. The 
> > user identity part in username can be a number as well. As in an 
> > account number. I think we are going ahead of ourselves.
> 
> I'm simply reflecting what I have heard from posters to the list...

Well sorry for shoting the messenger.  It still doesn't change the fact that
the username can be [email-masked]

> > How an operator comes up with a unique value is really no concern
> > of ours.
> 
> Yes, assuming we finally come to consensus that opaque is the 
> way to go, and that the semantics are limited to the stated 
> purpose of the CUI attribute.

No. The "How: is not important. The "What" is. How you calculate the number
is really up to the operator.  The important thing is the "What" which is
what the number stands for. That is what we are to standardize.

Whether they take the username and apply a hash to it, or whether they
assign the CUI to each user is up to them.  The end result needs to be the
same. The number must be unique withing the scope of the home network.

> > I think you don't understand how class works.
> 
> I think that you're mistaken in that assertion.

Well perhaps I am but then why do we come back to class?

> > The fundemental piece that you are missing is that the only entity 
> > that can draw any meaning out of the "Class" attribute is 
> the entity 
> > that issued the "Class" attribute.
> 
> No argument here.
> 
> What baffles me, however is two apparently conflicting assertions:
> 
> - CUI is issued by the Home AAA Server and is intended to be 
> interpreted by the NASes and Proxies.
> 
> - CUI is opaque (or might be opaque) and therefore can only 
> be interpreted by the Home AAA Server that issued it.
> 
> I see two possible ways to resolve this apparent paradox:
> 
> - The CUI is opaque to the Internet Community at large and 
> therefore can only be interpreted by the Home AAA Server that 
> issues it, but with the knowledge of some "secret sauce", the 
> NASes and Proxies in specific deployment environments are 
> capable of interpreting the CUI.

I don't understand interpreted by the Home AAA Server.  In the case where
the CUI is opaque, the Home Network sets its value to some "String" that it
asserts represents a unique user in the network.  Call it a temporary user
id if you like.

We call it opaque because:

The homenetwork could do the following:

"Timestamp|hashofUser|...."

So its opaque because we don't need the consumers of the CUI to know what
the receipe or format of the number is.  We are intentianly not specifying
what the value is.

So this is not a new concept in IETF. I think we are going to agree to
disagree here.

> - The CUI is opaque to the NASes and Proxies that use it, and 
> the only form that the "use" takes is to compare one instance 
> of a CUI cookie to see if it matches another instance of a 
> CUI cookie.  (I would note that this does not meet all the 
> requirements of all of the proposed CUI use
> cases.)

We therefore allow several forms other then Opaque. My original assertions
is that Opaque was the only one that was needed. But there are just some
things that are not worth taking on.  After all, I want to maintain a good
working relationship with my authors.

> 
> It is the potential for any such "secret sauce" that concerns 
> me, in terms of its negative impact on global, multi-vendor 
> interoperability. IMHO, the existence of "secret sauce" is 
> incompatible with IETF Standards Track protocol definition.

How the unique number is internally formated and/or generated does not break
interoperability.  That is why we say opaque. We don't care.

I don't see how we can't achieve interoperability with an opaque value.  If
I tell you that the number represents a unique user in my network then you
really don't need to know how I calculated it.  

What we care about is What that number represents!!!.

And the IETF has lots of examples of opaque attributes.

> Is there another, more satisfying, resolution to this 
> apparent paradox?

I don't see a paradox but lets just agree to disagree and move on.

And even if I agree there is a paradox.  I don't think all paradoxes need to
be solved.

> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 18:46:00 +0000
Date: Wed, 22 Dec 2004 13:45:22 -0500
To: Avi Lior <[email-masked]>
From: John Schnizlein <[email-masked]>
Subject: RE: Scope of applicability for CUI
Cc: [email-masked]

At 11:16 AM 12/22/2004, Avi Lior wrote:
>...
>I think you don't understand how class works.  
>The fundemental piece that you are missing is that the only entity that can
>draw any meaning out of the "Class" attribute is the entity that issued the
>"Class" attribute.  This is well documented in 2865.

Since David has tutored me in subtleties of the Class attribute, I suspect he understands it better than most. I am still trying to catch up..

My reading of its specification in RFC 2865 (quoted in entirety below) is that the accounting server is expected to be able to extract meaning from the Class attribute sent to the NAS by the authentication server. Isn't it common practice for these to be different servers?

John

5.25.  Class

   Description

      This Attribute is available to be sent by the server to the client
      in an Access-Accept and SHOULD be sent unmodified by the client to
      the accounting server as part of the Accounting-Request packet if
      accounting is supported.  The client MUST NOT interpret the
      attribute locally.

   A summary of the Class Attribute format is shown below.  The fields
   are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  String ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      25 for Class.

   Length

      >= 3

   String

      The String field is one or more octets.  The actual format of the
      information is site or application specific, and a robust
      implementation SHOULD support the field as undistinguished octets.

      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 16:57:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 11:56:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> If CUI was carried in the Class attribute then NASes (or more=20
> accurately) RADIUS clients would have to infere what is in the
> Class attribute. This is because Class can carry more then just
> CUI.

Agreed.  However, if the only "consumer" of CUI is the Home AAA server,
then it doesn't matter if CUI is commingled with Class.  So therefore,
NASes and Proxies must be "consumers" of CUI.

> Since CUI servers one purpose as defined by the draft then the=20
> RADIUS clients just need to use it without interpreting its=20
> contents.

I guess this is what still confuses me -- how the NASes and Proxies make
use of the CUI without interpreting it.  That leads me to believe they
treat it as an opaque cookie, similar to (but subtly different from)
Class.  What, exactly, do the NASes and Proxies do with this CUI cookie?
Is that not for the RFC reader to know?

> Are you suggesting the CUI would be "TEXT" as opposed to "String". =20
> I hope not.

While I had not explicitly made that connection, it might be logical in
support of some of the suggested use cases.  Let me be clear -- it is
not at all evident to me that there is consensus on the list as to what
the CUI use cases are.  Quite a few differing suggestions have been made
(and not all of them by the authors of the CUI draft).

> I mean one of the most crucial piece of evidence would be the
> User-name attribute which is a String.  So are we going to re-write=20
> all of these attributes in "TEXT". Lets get real here.

Please be assured that I am "real".  :-)  The User-Name attribute was
defined in the very first RADIUS RFC, before the introduction of the
Text data type.  Therefore it is still String.  I suspect most
implementations, however, in fact treat it as Text.

> I think presentation of a packet has a hex dump as evidence would=20
> *not* be considered novel in judice prudence.

That may be so.  Let me play amateur attorney here for a second and
suggest that learned counsel for the plaintiff would not likely
recommend HEX format evidence as the preferential format, given a
choice.  :-)   The difference being what you *could* do, if pressed, and
what would be *convenient* to do, given some influence over the choice.
Why make life complicated?
=20
> CUI is a String and is no different then User-Name also a string.
> The user identity part in username can be a number as well. As in
> an account number. I think we are going ahead of ourselves.

I'm simply reflecting what I have heard from posters to the list...

> How an operator comes up with a unique value is really no concern=20
> of ours.

Yes, assuming we finally come to consensus that opaque is the way to go,
and that the semantics are limited to the stated purpose of the CUI
attribute.

> I think you don't understand how class works.

I think that you're mistaken in that assertion.

> The fundemental piece that you are missing is that the only entity
> that can draw any meaning out of the "Class" attribute is the entity=20
> that issued the "Class" attribute.=20

No argument here.

What baffles me, however is two apparently conflicting assertions:

- CUI is issued by the Home AAA Server and is intended to be interpreted
by the NASes and Proxies.

- CUI is opaque (or might be opaque) and therefore can only be
interpreted by the Home AAA Server that issued it.

I see two possible ways to resolve this apparent paradox:

- The CUI is opaque to the Internet Community at large and therefore can
only be interpreted by the Home AAA Server that issues it, but with the
knowledge of some "secret sauce", the NASes and Proxies in specific
deployment environments are capable of interpreting the CUI.

- The CUI is opaque to the NASes and Proxies that use it, and the only
form that the "use" takes is to compare one instance of a CUI cookie to
see if it matches another instance of a CUI cookie.  (I would note that
this does not meet all the requirements of all of the proposed CUI use
cases.)

It is the potential for any such "secret sauce" that concerns me, in
terms of its negative impact on global, multi-vendor interoperability.
IMHO, the existence of "secret sauce" is incompatible with IETF
Standards Track protocol definition.

Is there another, more satisfying, resolution to this apparent paradox?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 16:35:05 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 11:34:49 -0500

Hi Alan,

See comments inline.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 11:26 AM
> To: [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> "Nelson, David" <[email-masked]> wrote:
> > Hmmm. If the format of CUI can be *anything*, then it is an opaque 
> > token or cookie, and fairly indistinguishable from Class.  Am I 
> > missing a fundamental point here?
> 
>   To rephrase:
> 
>   User-Name is a token by which the NAS which establishes the 
> "identity" of a user within a session.

Not 100% accurate. User-Name may only be used for routing. Right?

>   Class is one or more tokens by which each proxying RADIUS 
> server establishes it's own view of the "identity" of a session.

Again not 100% accurate.  We can't really say what class is used for. It
could be for identity tracking and it could be for other things.  That is
the problem with class. The minute we try to standerdize it's meaning we
will break someone's RADIUS implementation.

For us class carries some state information and not necessarily identity.
It's use changes between customers etc.

For example, the value for Class that I use for joe's session
([email-masked]) and for franks session ([email-masked]) may be
identical.  After all I maybe using the Class attribute to track something
about realms and not users.

>   CUI is proposed to be a token by which the home server 
> establishes it's own view of the "identity" of a session.  
> (If I interpret the proposal correctly.)

CUI is a token by which the home network (home server) establishes a handle
to a user in the home network. The value can be a permament handle (bad if
privacy is an issue) or a temporary handle that is valid for some period of
time.

So to make sure that we are 100% accurate: the identity is not for for the
homenetwork its for the those outside the homenetwork that require this
assertion by the home network to do business.
 
>   The attributes are created by different entities in the 
> network, and are intended to do different things.  There's 
> only one NAS in a session, so there can be only one 
> User-Name.  There are multiple proxying servers, so there can 
> be multiple Class attributes.  There's only one home server, 
> so there can only be one CUI.

They may or may not be created by different entities in the homenetwork.
But yes to the rest.

>   Taken in combination, the above attributes allows each 
> participant in the RADIUS conversation to associate a "token" 
> with a login session, that it, and it alone, controls.

I suppose this can be correct.  That is if we agree that Class is used for
identity tracking.
 
>   Like the User-Name, the CUI should be (at some level) 
> visible & interpretable by every participant in the RADIUS 
> conversation.  This may include a definition of CUI as an 
> opaque token.  The important difference between CUI and 
> Class, though, is that CUI is defined to be a token added by 
> the home server.  All proxying servers, and the NAS, can use 
> & interpret CUI in that context.  They are explicitly 
> forbidden from doing so for the Class attribute.

Exactly.

Well the importance difference between CUI and Class is that:
-We can't use Class to do what we want because the standards already tell us
what Class is used for.
 
>   Avi?  Does that sound like a reasonable summary?

>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 16:16:47 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 11:16:31 -0500

David,

See inline,

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, December 22, 2004 10:15 AM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> John Loughney writes...
> 
> > Is there a need or use fo have the attribute be parsable by 
> the NAS or 
> > Proxy?
> 
> It seems to me that there is, based on assertions that have 
> been made on the list regarding the properties and uses of 
> CUI.  For example:
> 
> - It has been asserted that one of the reasons that the Class 
> attribute doesn't fill the need is because NASes are 
> prohibited from interpreting the content of Class.  I infer, 
> therefore, that NASes are, in at least some cases, required 
> to interpret the content of CUI.

If CUI was carried in the Class attribute then NASes (or more accurately)
RADIUS clients would have to infere what is in the Class attribute. This is
because Class can carry more then just CUI.

Since CUI servers one purpose as defined by the draft then the RADIUS
clients just need to use it without interpreting its contents.

> - It has been asserted that one of the use cases for CUI is 
> to provide a mechanism for all parties (ISPs, Mediators, 
> Brokers, Roaming Consortia Members, etc.) to be able to 
> ensure that that get their full share of the attendant 
> revenues.  In order for any such mechanism to have any 
> "teeth" it is required, I think, that the evidence of any 
> such transactions, including the CUI, be in a format suitable 
> for submission to a court of law.  Yes, this is the last 
> resort, but without it the system has no checks and balances. 
>  Therefore, I presume that the CUI must be printable ASCII 
> and capable of convincing a Judge that payment for services 
> rendered is due to the plaintiff.

Are you suggesting the CUI would be "TEXT" as opposed to "String".  I hope
not.  I mean one of the most crucial piece of evidence would be the
User-name attribute which is a String.  So are we going to re-write all of
these attributes in "TEXT". Lets get real here.

I think presentation of a packet has a hex dump as evidence would *not* be
considered novel in judice prudence.
 
> - It has been asserted that in certain jurisdictions, IPSs 
> (and others) may have a legal obligation to provide the 
> identity of users who are suspected of launching 
> cyber-attacks.  In such jurisdictions, one would suppose that 
> the level of privacy in the CUI would not be resistant to 
> judicial inspection, however that might be arranged.  In such 
> cases the parties to the transaction need to have a form of 
> CUI that that can be delivered to the authorized law 
> enforcement authorities.

CUI is a String and is no different then User-Name also a string.
The user identity part in username can be a number as well. As in an account
number. I think we are going ahead of ourselves.

> > I guess you are worried that if there is no standardized format, it 
> > could be used at some point in the future to carry other
> information
> > not related to CUI uses;
> 
> That is a secondary concern.  There is some inherent 
> temptation for implementers to overload IETF standard RADIUS 
> attributes, that are opaque strings, with new functions, 
> rather that using VSAs, or seeking to standardize new attributes.

How an operator comes up with a unique value is really no concern of ours.
The attribute if it conforms to the draft must be unique for a given amount
of time.

> > but as currently defined, I don't see the issue of needing 
> a standard
> > format and syntax for CUI.
> 
> Hmmm. If the format of CUI can be *anything*, then it is an 
> opaque token or cookie, and fairly indistinguishable from 
> Class.  Am I missing a fundamental point here?

I think you don't understand how class works.  
The fundemental piece that you are missing is that the only entity that can
draw any meaning out of the "Class" attribute is the entity that issued the
"Class" attribute.  This is well documented in 2865.
 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Wed, 22 Dec 2004 16:14:25 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Scope of applicability for CUI 
Date: Wed, 22 Dec 2004 11:25:55 -0500
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Hmmm. If the format of CUI can be *anything*, then it is an opaque token
> or cookie, and fairly indistinguishable from Class.  Am I missing a
> fundamental point here?

  To rephrase:

  User-Name is a token by which the NAS which establishes the
"identity" of a user within a session.

  Class is one or more tokens by which each proxying RADIUS server
establishes it's own view of the "identity" of a session.

  CUI is proposed to be a token by which the home server establishes
it's own view of the "identity" of a session.  (If I interpret the
proposal correctly.)

  The attributes are created by different entities in the network, and
are intended to do different things.  There's only one NAS in a
session, so there can be only one User-Name.  There are multiple
proxying servers, so there can be multiple Class attributes.  There's
only one home server, so there can only be one CUI.

  Taken in combination, the above attributes allows each participant
in the RADIUS conversation to associate a "token" with a login
session, that it, and it alone, controls.

  Like the User-Name, the CUI should be (at some level) visible &
interpretable by every participant in the RADIUS conversation.  This
may include a definition of CUI as an opaque token.  The important
difference between CUI and Class, though, is that CUI is defined to be
a token added by the home server.  All proxying servers, and the NAS,
can use & interpret CUI in that context.  They are explicitly
forbidden from doing so for the Class attribute.

  Avi?  Does that sound like a reasonable summary?

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 15:15:34 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 10:14:57 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

John Loughney writes...

> Is there a need or use fo have the attribute be parsable by the NAS or
> Proxy?=20

It seems to me that there is, based on assertions that have been made on
the list regarding the properties and uses of CUI.  For example:

- It has been asserted that one of the reasons that the Class attribute
doesn't fill the need is because NASes are prohibited from interpreting
the content of Class.  I infer, therefore, that NASes are, in at least
some cases, required to interpret the content of CUI.

- It has been asserted that one of the use cases for CUI is to provide a
mechanism for all parties (ISPs, Mediators, Brokers, Roaming Consortia
Members, etc.) to be able to ensure that that get their full share of
the attendant revenues.  In order for any such mechanism to have any
"teeth" it is required, I think, that the evidence of any such
transactions, including the CUI, be in a format suitable for submission
to a court of law.  Yes, this is the last resort, but without it the
system has no checks and balances.  Therefore, I presume that the CUI
must be printable ASCII and capable of convincing a Judge that payment
for services rendered is due to the plaintiff.

- It has been asserted that in certain jurisdictions, IPSs (and others)
may have a legal obligation to provide the identity of users who are
suspected of launching cyber-attacks.  In such jurisdictions, one would
suppose that the level of privacy in the CUI would not be resistant to
judicial inspection, however that might be arranged.  In such cases the
parties to the transaction need to have a form of CUI that that can be
delivered to the authorized law enforcement authorities.

> I guess you are worried that if there is no standardized format,
> it could be used at some point in the future to carry other
information
> not related to CUI uses;

That is a secondary concern.  There is some inherent temptation for
implementers to overload IETF standard RADIUS attributes, that are
opaque strings, with new functions, rather that using VSAs, or seeking
to standardize new attributes.

> but as currently defined, I don't see the issue of needing a standard=20
> format and syntax for CUI.

Hmmm. If the format of CUI can be *anything*, then it is an opaque token
or cookie, and fairly indistinguishable from Class.  Am I missing a
fundamental point here?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 13:04:58 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked]
Cc: [email-masked]
Subject: RE: review of draft-decnodder-radext-dynauth-server-mib-02.txt
Date: Wed, 22 Dec 2004 14:04:19 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E826.BF453D66
Content-Type: text/plain;
	charset="windows-1255"

Thanks for your review Dan!
 
Bert

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Wednesday, December 22, 2004 10:35
To: [email-masked]
Cc: [email-masked]
Subject: review of draft-decnodder-radext-dynauth-server-mib-02.txt

At the request of the Operations and Management Area Director I reviewed draft-decnodder-radext-dynauth-server-mib-02.txt. Please find below my comments. 

Regards,

Dan

1. The boilerplate does not conform with the latest recommendations referring to Intellectual Property notices. See http://www.ietf.org/ietf/1id-guidelines.txt <http://www.ietf.org/ietf/1id-guidelines.txt>  for the mandatory notices. 

2. The Introduction section contains un-expanded acronyms which are not public domain knowledge for the Internet community - CoA, NAS.  

3. Section 5 in this document duplicates much of the similar section 5 in draft-decnodder-radext-dynauth-client-mib-02.txt. It may be better to avoid duplication by having the respective text be written only in one document and referred by the other. 

5.Is this MIB module implemented in conjunction with other MIB modules - for example those defined in RFC 2618 through 2621? If this is the case, this relationship should be discussed in one of the 'narrative' sections - probably in Section 5. The current text says no more than 'this memo ... relates to the following document...' which is un-sufficient and incorrect grammatically, and a list of multiple documents (plural) follows. 

6. Usage of radiusMIB root. As clarified by the Area Director doing a separate subtree for each technology is discouraged. 

So 

radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 } 

is not good. We'd rather see: 

radiusDynamicAuthorization OBJECT IDENTIFIER ::= { mib-2 xxx } -- xxx to be assigned by IANA 

The reason is that we have run into clashed (i.e. conflicting definitions) when WGs try to keep track of registrations underneath a MIB branch. See also the recommendation in MIB review guidelines draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd bullet. So pls go for assignment under mib-2. If you want to stick it under radiusMIB, then you need to write a document similar to RFC3737.

7. There is a need for a RFC Editor note after "Initial version as published in RFC XXXX"

8. What is the purpose of the radiusDynAuthServerIdentifier object? If this is about software versions, application names, etc. there are objects in other MIB modules already defining this - see for example RFC 2737. If there is a something specific about a RADIUS dynamic authentication server identifier, some more information is needed - for example provide a reference to a 'NAS-Identifier'. 

9. DESCRIPTION clause of radiusDynAuthServerEntry - change '...representing the Dynamic...' with '...representing one Dynamic...'

10. DESCRIPTION clause of  radiusDynAuthServerCoAPacketsDropped - I suggest to add '...by the client application' after 'silently discarded'. 

11. I suggest to add UNITS clauses to the counter objects - messages, packets, retransmissions, etc. 

12. Section 9.1 - I wonder if references to RFC 2618 through 2621 are really normative references. I do not see the strong dependence on these specifications that would justify it.

13. There is no IANA Consideration section. Even if no actions are required from IANA, such a section must be present and just mention this

14. idnits complains about a weird spacing problem in line 605  '... client with ...' 

------_=_NextPart_001_01C4E826.BF453D66
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE>review of draft-decnodder-radext-dynauth-server-mib-02.txt</TITLE>

<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=646591812-22122004><FONT color=#0000ff size=2>Thanks for your 
review Dan!</FONT></SPAN></DIV>
<DIV><SPAN class=646591812-22122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=646591812-22122004><FONT color=#0000ff 
size=2>Bert</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Romascanu, Dan (Dan) 
  [mailto:[email-masked]]<BR><B>Sent:</B> Wednesday, December 22, 2004 
  10:35<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> 
  [email-masked]<BR><B>Subject:</B> review of 
  draft-decnodder-radext-dynauth-server-mib-02.txt<BR><BR></FONT></DIV><!-- Converted from text/rtf format -->
  <P dir=ltr><FONT face=Arial size=2>At the request of the Operations and 
  Management Area Director I reviewed 
  draft-decnodder-radext-dynauth-server-mib-02.txt. Please find below my 
  comments. </FONT></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Regards,</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Dan</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>1. The boilerplate does 
  not conform with the latest recommendations referring to Intellectual Property 
  notices. See <A 
  href="http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/ietf/1id-guidelines.txt</A></FONT></SPAN><SPAN 
  lang=he><FONT face=Arial size=2></FONT></SPAN><SPAN lang=en-us> <FONT 
  face=Arial size=2>for the mandatory notices. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>2. The Introduction 
  section contains un-expanded acronyms which are not public domain knowledge 
  for the Internet community - CoA, NAS.&nbsp; </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>3. Section 5 in this 
  document duplicates much of the similar section 5 in</FONT></SPAN><SPAN 
  lang=he> <FONT face=Arial 
  size=2>draft-decnodder-radext-dynauth-client-mib-02.txt. It may be better to 
  avoid duplication by having the respective text be written only in one 
  document and referred by the other. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>5.Is this MIB module 
  implemented in conjunction with other MIB modules - for example those defined 
  in RFC 2618 through 2621? If this is the case, this relationship should be 
  discussed in one of the 'narrative' sections - probably in Section 5. The 
  current text says no more than 'this memo ... relates to the following 
  document...' which is un-sufficient and incorrect grammatically, and a list of 
  multiple documents (plural) follows. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>6.</FONT> <FONT face=Arial 
  size=2>Usage of radiusMIB root. As clarified by the Area Director</FONT><FONT 
  face=Arial color=#000000 size=2> doing a separate subtree for each technology 
  is discouraged. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 size=2>So 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 
  size=2>radiusDynamicAuthorization OBJECT IDENTIFIER ::= { radiusMIB 3 } 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 size=2>is not good. 
  We'd rather see: </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 
  size=2>radiusDynamicAuthorization OBJECT IDENTIFIER ::= { mib-2 xxx } -- xxx 
  to be assigned by IANA </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 size=2>The reason 
  is that we have run into clashed (i.e. conflicting definitions) when WGs try 
  to keep track of registrations underneath a MIB branch. See also the 
  recommendation in MIB review guidelines 
  draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd bullet. So pls go 
  for assignment under mib-2. If you want to stick it under radiusMIB, then you 
  need to write a document similar to RFC3737.</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 size=2>7. There is 
  a need for a RFC Editor note after "Initial version as published in RFC 
  XXXX"</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial color=#000000 size=2>8.</FONT> 
  <FONT face=Arial size=2>What is the purpose of the</FONT> <FONT 
  face="Times New Roman">radiusDynAuthServerIdentifier object? If this is about 
  software versions, application names, etc. there are objects in other MIB 
  modules already defining this - see for example RFC 2737. If there is a 
  something specific about a RADIUS dynamic authentication server identifier, 
  some more information is needed - for example provide a reference to a 
  'NAS-Identifier'. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">9. DESCRIPTION clause 
  of radiusDynAuthServerEntry - change '...representing the Dynamic...' with 
  '...representing one Dynamic...'</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">10.</FONT> <FONT 
  face=Arial size=2>DESCRIPTION clause of</FONT>&nbsp;<FONT 
  face="Times New Roman"> radiusDynAuthServerCoAPacketsDropped - I suggest to 
  add '...by the client application' after 'silently discarded'.</FONT> 
  </SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">11. I suggest to add 
  UNITS clauses to the counter objects - messages, packets, retransmissions, 
  etc. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">12. Section 9.1 - I 
  wonder if references to RFC 2618 through 2621 are really normative references. 
  I do not see the strong dependence on these specifications that would justify 
  it.</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">13. There is no IANA 
  Consideration section. Even if no actions are required from IANA, such a 
  section must be present and just mention this</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">14. idnits complains 
  about</FONT> <FONT face=Arial size=2>a<B></B> weird spacing problem in line 
  605</FONT>&nbsp;<FONT face="Times New Roman"> '... client with ...' 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4E826.BF453D66--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 09:35:42 +0000
content-class: urn:content-classes:message
Subject: review of draft-decnodder-radext-dynauth-server-mib-02.txt
Date: Wed, 22 Dec 2004 11:34:58 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E809.80954A07
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

At the request of the Operations and Management Area Director I reviewed =
draft-decnodder-radext-dynauth-server-mib-02.txt. Please find below my =
comments.=20

Regards,

Dan

1. The boilerplate does not conform with the latest recommendations =
referring to Intellectual Property notices. See =
http://www.ietf.org/ietf/1id-guidelines.txt for the mandatory notices.=20
2. The Introduction section contains un-expanded acronyms which are not =
public domain knowledge for the Internet community - CoA, NAS. =20
3. Section 5 in this document duplicates much of the similar section 5 =
in draft-decnodder-radext-dynauth-client-mib-02.txt. It may be better to =
avoid duplication by having the respective text be written only in one =
document and referred by the other.=20
5.Is this MIB module implemented in conjunction with other MIB modules - =
for example those defined in RFC 2618 through 2621? If this is the case, =
this relationship should be discussed in one of the 'narrative' sections =
- probably in Section 5. The current text says no more than 'this memo =
... relates to the following document...' which is un-sufficient and =
incorrect grammatically, and a list of multiple documents (plural) =
follows.=20
6. Usage of radiusMIB root. As clarified by the Area Director doing a =
separate subtree for each technology is discouraged.=20
So=20
radiusDynamicAuthorization OBJECT IDENTIFIER ::=3D { radiusMIB 3 }=20
is not good. We'd rather see:=20
radiusDynamicAuthorization OBJECT IDENTIFIER ::=3D { mib-2 xxx } -- xxx =
to be assigned by IANA=20
The reason is that we have run into clashed (i.e. conflicting =
definitions) when WGs try to keep track of registrations underneath a =
MIB branch. See also the recommendation in MIB review guidelines =
draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd bullet. So pls =
go for assignment under mib-2. If you want to stick it under radiusMIB, =
then you need to write a document similar to RFC3737.
7. There is a need for a RFC Editor note after "Initial version as =
published in RFC XXXX"
8. What is the purpose of the radiusDynAuthServerIdentifier object? If =
this is about software versions, application names, etc. there are =
objects in other MIB modules already defining this - see for example RFC =
2737. If there is a something specific about a RADIUS dynamic =
authentication server identifier, some more information is needed - for =
example provide a reference to a 'NAS-Identifier'.=20
9. DESCRIPTION clause of radiusDynAuthServerEntry - change =
'...representing the Dynamic...' with '...representing one Dynamic...'
10. DESCRIPTION clause of  radiusDynAuthServerCoAPacketsDropped - I =
suggest to add '...by the client application' after 'silently =
discarded'.=20
11. I suggest to add UNITS clauses to the counter objects - messages, =
packets, retransmissions, etc.=20
12. Section 9.1 - I wonder if references to RFC 2618 through 2621 are =
really normative references. I do not see the strong dependence on these =
specifications that would justify it.
13. There is no IANA Consideration section. Even if no actions are =
required from IANA, such a section must be present and just mention this
14. idnits complains about a weird spacing problem in line 605  '... =
client with ...'=20

------_=_NextPart_001_01C4E809.80954A07
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6603.0">
<TITLE>review of =
draft-decnodder-radext-dynauth-server-mib-02.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">At the request of the =
Operations and Management Area Director I reviewed =
draft-decnodder-radext-dynauth-server-mib-02.txt. Please find below my =
comments. </FONT></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Regards,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Dan</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">1. The =
boilerplate does not conform with the latest recommendations referring =
to Intellectual Property notices. See <A =
HREF=3D"http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/=
ietf/1id-guidelines.txt</A></FONT></SPAN><SPAN LANG=3D"he"><FONT =
SIZE=3D2 FACE=3D"Arial"></FONT></SPAN><SPAN LANG=3D"en-us"> <FONT =
SIZE=3D2 FACE=3D"Arial">for the mandatory notices. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">2. The =
Introduction section contains un-expanded acronyms which are not public =
domain knowledge for the Internet community - CoA, NAS.&nbsp; =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">3. =
Section 5 in this document duplicates much of the similar section 5 =
in</FONT></SPAN><SPAN LANG=3D"he"> <FONT SIZE=3D2 =
FACE=3D"Arial">draft-decnodder-radext-dynauth-client-mib-02.txt. It may =
be better to avoid duplication by having the respective text be written =
only in one document and referred by the other. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">5.Is =
this MIB module implemented in conjunction with other MIB modules - for =
example those defined in RFC 2618 through 2621? If this is the case, =
this relationship should be discussed in one of the 'narrative' sections =
- probably in Section 5. The current text says no more than 'this memo =
... relates to the following document...' which is un-sufficient and =
incorrect grammatically, and a list of multiple documents (plural) =
follows. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">6.</FONT> <FONT SIZE=3D2 FACE=3D"Arial">Usage of =
radiusMIB root. As clarified by the Area Director</FONT><FONT =
COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"> doing a separate subtree for =
each technology is discouraged. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">So </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">radiusDynamicAuthorization OBJECT IDENTIFIER ::=3D { =
radiusMIB 3 } </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">is not good. We'd rather see: </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">radiusDynamicAuthorization OBJECT IDENTIFIER ::=3D { =
mib-2 xxx } -- xxx to be assigned by IANA </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">The reason is that we have run into clashed (i.e. =
conflicting definitions) when WGs try to keep track of registrations =
underneath a MIB branch. See also the recommendation in MIB review =
guidelines draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd =
bullet. So pls go for assignment under mib-2. If you want to stick it =
under radiusMIB, then you need to write a document similar to =
RFC3737.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">7. There is a need for a RFC Editor note after =
&quot;Initial version as published in RFC XXXX&quot;</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT COLOR=3D"#000000" SIZE=3D2 =
FACE=3D"Arial">8.</FONT> <FONT SIZE=3D2 FACE=3D"Arial">What is the =
purpose of the</FONT> <FONT FACE=3D"Times New =
Roman">radiusDynAuthServerIdentifier object? If this is about software =
versions, application names, etc. there are objects in other MIB modules =
already defining this - see for example RFC 2737. If there is a =
something specific about a RADIUS dynamic authentication server =
identifier, some more information is needed - for example provide a =
reference to a 'NAS-Identifier'. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">9. =
DESCRIPTION clause of radiusDynAuthServerEntry - change '...representing =
the Dynamic...' with '...representing one Dynamic...'</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New =
Roman">10.</FONT> <FONT SIZE=3D2 FACE=3D"Arial">DESCRIPTION clause =
of</FONT>&nbsp;<FONT FACE=3D"Times New Roman"> =
radiusDynAuthServerCoAPacketsDropped - I suggest to add '...by the =
client application' after 'silently discarded'.</FONT> </SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">11. I =
suggest to add UNITS clauses to the counter objects - messages, packets, =
retransmissions, etc. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">12. =
Section 9.1 - I wonder if references to RFC 2618 through 2621 are really =
normative references. I do not see the strong dependence on these =
specifications that would justify it.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">13. =
There is no IANA Consideration section. Even if no actions are required =
from IANA, such a section must be present and just mention =
this</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">14. =
idnits complains about</FONT> <FONT SIZE=3D2 FACE=3D"Arial">a<B></B> =
weird spacing problem in line 605</FONT>&nbsp;<FONT FACE=3D"Times New =
Roman"> '... client with ...' </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E809.80954A07--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 04:28:47 +0000
content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 06:27:43 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David,

I haven't had my coffee yet, so maybe that adds to my confusion,
but ..

> I wonder if we are using the word "transparent" in a similar fashion?
> My argument is that the format and syntax of the CUI be standardized.
> That is what I means by transparent.  I mean that it is possible for =
the
> NAS or Proxy to parse the CUI attribute and do something with the
> content, such as export it to a local backup accounting system.
> Reconciliation of accounting/billing information between =
intermediaries
> and home AAA operators has been listed as one of the use cases for =
CUI.
> In that event, the intermediaries need to be able to know what form it
> takes.
>=20
> It does not, of course, mean that having the CUI "parsed" will remove
> any of the privacy.  The fact that I can look at a CUI of the form
> [email-masked] does not assist me =
in
> mapping that CUI to the human user behind it.  Ostensibly, only the =
Home
> AAA Server can do that.

Is there a need or use fo have the attribute be parsable by the NAS or
Proxy?  I guess you are worried that if there is no standardized format,
it could be used at some point in the future to carry other information
not related to CUI uses; but as currently defined, I don't see the issue
of needing a standard format and syntax for CUI.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 04:18:36 +0000
content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Wed, 22 Dec 2004 06:16:09 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Barney,

>=20
> On Tue, Dec 21, 2004 at 04:14:52PM -0500, Nelson, David wrote:
> >=20
> > There have been suggestions made that the content of CUI has some =
local
> > semantics at the NAS or a Proxy, beyond its utility for inclusion in
> > on-line or off-line accounting records.  To the extent that common =
use
> > cases for local semantics (e.g. limitation of simultaneous logins) =
are
> > identified, they should be documented, in the interest of global,
> > multi-vendor interoperability.
> >=20
> > Given this description of CUI, what is the utility of the opaque =
data
> > format of CUI?  I understand that opaqueness can be rendered =
transparent
> > with the bilateral sharing of proprietary information, pursuant to a
> > business contract.  However, that exception notwithstanding, if the
> > intent of CUI is visibility and utility to the NAS and to the =
Proxies, I
> > suggest that the opaque data format be removed from the draft.
>=20
> Whether the CUI is opaque or an NAI does not change the fact that
> it should be meaningful only to the home server.  The only test
> that the NAS/proxy should be able to make on CUI is for equality
> to some previously seen CUI.  Otherwise the privacy of the user has
> been compromised for no legitimate reason.  A business agreement
> on how long a one-to-one relation between CUI and the "true" user
> identity must persist does not depend in any way on the form of the
> CUI.  Given that, I would have said the opposite, that CUI should
> always be an opaque octet string.

I agree with your interpretation.  I don't see how the opaqueness hurts
interoperability here.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 22 Dec 2004 02:56:01 +0000
Date: Tue, 21 Dec 2004 21:55:28 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

On Tue, Dec 21, 2004 at 05:02:10PM -0500, Nelson, David wrote:
> Barney Wolff writes...
> 
> > Whether the CUI is opaque or an NAI does not change the fact that
> > it should be meaningful only to the home server.  The only test
> > that the NAS/proxy should be able to make on CUI is for equality
> > to some previously seen CUI.  Otherwise the privacy of the user has
> > been compromised for no legitimate reason.  A business agreement
> > on how long a one-to-one relation between CUI and the "true" user
> > identity must persist does not depend in any way on the form of the
> > CUI.  Given that, I would have said the opposite, that CUI should
> > always be an opaque octet string.
> 
> I wonder if we are using the word "transparent" in a similar fashion?
> My argument is that the format and syntax of the CUI be standardized.
> That is what I means by transparent.  I mean that it is possible for the
> NAS or Proxy to parse the CUI attribute and do something with the
> content, such as export it to a local backup accounting system.
> Reconciliation of accounting/billing information between intermediaries
> and home AAA operators has been listed as one of the use cases for CUI.
> In that event, the intermediaries need to be able to know what form it
> takes.

I don't understand the need to parse the CUI.  The NAS/proxy would be
foolish to take the "who to bill" from the CUI, which is under the
complete control of the home server, when the realm is known from
User-Name and the IP address from which the Accept was received is also
known.

If it's not parsed, the only issue is whether to require that it be a
printable string rather than an arbitrary octet string.  Again, the NAS/
proxy would be foolish to count on there being no control characters in
the CUI even if the RFC said that there must be none.  So in effect there
is no saving of software effort in requiring a printable string.

> It does not, of course, mean that having the CUI "parsed" will remove
> any of the privacy.  The fact that I can look at a CUI of the form
> [email-masked] does not assist me in
> mapping that CUI to the human user behind it.  Ostensibly, only the Home
> AAA Server can do that.
> 
> Beyond that, any notion of "security by obscurity" in allowing undefined
> syntax and formats for the CUI seems pointless.

I don't for a minute believe that making it an opaque string provides any
better security, but it does reinforce to NAS/proxy developers that the
only operations that should be attempted on CUI are memcmp() and memcpy(),
never strxxx().

> I don't advocate the loss of privacy, just the standardization of packet
> payload formats.  

There's only one standard way to print an octet string - in hex. :)

Regards,
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 23:16:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 18:16:19 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...
=A0
> So yes the Home Network can cheat but why would it do so?=A0
> After all it is relying on its relationship with the broker=20
> to generate additional revenue.=A0

The Home Network may not always be an ISP.  It might be an end-user =
(enterprise or organization) out-sourcing its network access.   In that =
case, it's not generating revenue, its incurring expense.  Not to say =
that the incentive to cheat is substantially larger, but the motivation =
would be different.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 23:01:16 +0000
From: Avi Lior <[email-masked]>
To: 'Bikramjit Singh' <[email-masked]>, 'Alan DeKok' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 18:00:42 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E7B0.E5B98EA0
Content-Type: text/plain

By roaming agreement the HAAA will not send the same CUI for all its users.
When a broker network negotiates with the home network it will require the
home network to issue the CUI which is different for every user.
 
So yes the Home Network can cheat but why would it do so?  After all it is
relying on its relationship with the broker to generate additional revenue.
If the Home network is found to commit fraud then it is the home network
that would be the loser at the end as no one will want to do business with
it.
 
But the broker network also has a way of validating that the CUI is not
being missused. For example, if the broker network sees that the same CUI is
being reported to two different NASes it would just reject the request, log
it, and I am sure there will be phone call between two CEOs in that case.
So cheating is possible but hard -very hard.
 
Scenario 2:
 
As I understand scenario 2 it is all about routing.  CUI is not about
routing - its not intended for that but is intended for your scenario 1.
 
The username is still in the packet and contains the realm and potentially a
route selected by the user -- see other works by my co-author. Routing is
done on the realm part of the UserName not the identity part.
 
When eap methods are being used the User Name looks like     "@example.com".
We route only on the realm part or decoration part of the NAI. See 2486bis.
 
Once the Access-Request reaches the home network the AAA path has already
been determined. The CUI is applied to the Access-Accept.
 
Hope this resolves your concerns.
 
Avi

-----Original Message-----
From: Bikramjit Singh [mailto:[email-masked]] 
Sent: Tuesday, December 21, 2004 3:53 PM
To: 'Alan DeKok'; [email-masked]'
Subject: RE: Scope of applicability for CUI

I have been reading this thread for a while and I am not sure if this
attribute helps in 2 scenarios that an intermediary can face...

1) The wholesale billing plans that are being seen currently in WLAN roaming
world are based on per-user-per-location for 24 hour period. That means that
the same user is allowed to login and logout any number of times from that
location and he will be charged only once for that 24 hour period.. This
requires correlation of the multiple RADIUS sessions of that user from a
particular location (NAS) and currently this is being achieved by using the
username and NAS-ID attribute.. How would we be able to do this once TTLS
EAP or other protected mechanisms are required and 802.1x becomes a
requirement for the roaming world?? The CUI will not be able to be of much
help since the home AAA can theoretically send the same CUI for all its
users logins from that location so that it doesn't have to pay the
intermediary for separate users.. This is a not an issue in a clear-text
username attribute correlation where an intermediary knows who is being
authenticated and accounted for.

2) Consider a business relationship scenario like this. 

          +---C----+---E 
          |        | 
A-------B-+        +---D 
          |            | 
          +------------+ 

B is the intermediary and C is an intermediary.. B would like to deny access
to D through C since it has a direct roaming agreement with D or atleast it
wants to tell D that the only way to get access to A (access network) is
through B.. But by using protected usernames, D can do a roaming
relationship with C without B knowing about it and maybe C is getting a
better deal for it since it has already negotiated discounted rates with B
and it is getting a piece of the pie even in the case where it is not
required... For whatever reasons, how can B know that a particular request
is finally ending up in D via C if the user identity is hidden.. CUI will
not help in this scenario either.. B has to do business with C since C has
exclusive access to E.. But B knows that it can get to D on its own and
wants to shut off access for D's users if they are being authenticated
through C.. Apart from pricing model restrictions, what is the technical
feasibility using RADIUS to allow/deny this from happening... Right now
there is a way using usernames that if the username is C/[email-masked] then B
can reject that access-request.. however if it is C/xdfaer342 (encrypted)
then how does B prevent it?? 

Thanks 

-Bik 

-----Original Message----- 
From: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ] On Behalf Of Alan DeKok 
Sent: Tuesday, December 21, 2004 12:09 PM 
To: [email-masked] 
Subject: Re: Scope of applicability for CUI 

Avi Lior <[email-masked]> wrote: 
> Yes there is only one instance. But that is the least of the differences. 
> Unlike Class, CUI is supposed to be interpreted by the client.  In so far 
> that the client knows the CUI is assertion by the Home Network that this
is 
> a handle to a subscriber. 

  If the main purpose of the CUI is to give an opaque handle to a 
subscriber so proxies can control multiple logins, then I'm not sure 
what it gains us.  The home server can limit multiple logins, so the 
proxy server doesn't have to.  As Emile said, if the proxy server 
doesn't trust the home server to manage multiple logins, it shouldn't 
trust the home server to create the same CUI for the same user. 

  The main benefit I see is that the multiple login use of the CUI is 
managed by the proxy server, which means the home servers can be 
simpler to configure. 

  If that's the main reason for CUI, then I would like to see a 
sentence or two in the document explaining the different approaches, 
the issues with CUI, and why this approach was chosen. 

  I'm not opposing it, I just want the reasons for choosing it to be 
clear 3 years from now to people outside of radiusext. 

  Alan DeKok. 

-- 
to unsubscribe send a message to [email-masked] with 
the word 'unsubscribe' in a single line as the message text body. 
archive: <http://psg.com/lists/radiusext/ <http://psg.com/lists/radiusext/>
> 

------_=_NextPart_001_01C4E7B0.E5B98EA0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2900.2523" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>By 
roaming agreement the HAAA will not send the same CUI for all its users.&nbsp; 
When a broker network negotiates with the home network it will require the home 
network to issue the CUI which is different for every user.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>So yes 
the Home Network can cheat but why would it do so?&nbsp; After all it is relying 
on its relationship with the broker to generate additional revenue.&nbsp; If the 
Home network is found to commit fraud then it is the home network that would be 
the loser at the end as no one will want to do business with 
it.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>But 
the broker network also has a way of validating that the CUI is not being 
missused. For example, if the broker network sees that the same CUI 
is&nbsp;being reported&nbsp;to&nbsp;two different NASes it would just reject the 
request, log it, and I am sure there will be phone call between two CEOs in that 
case.&nbsp; So cheating is possible but hard -very hard.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004>Scenario 2:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>As I 
understand scenario 2 it </SPAN></FONT><FONT face=Arial color=#0000ff 
size=2><SPAN class=334572222-21122004>is all about routing.&nbsp; CUI is not 
about routing - its not intended for that but is intended for your scenario 
1.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>The 
username is still in the packet and contains the realm and potentially a route 
selected by the user -- see other works by my co-author. Routing is done on the 
realm part of the UserName not the identity part.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>When 
eap methods are being used the User Name looks like&nbsp;&nbsp;&nbsp;&nbsp; 
"@example.com".&nbsp; We route only on the realm part or decoration part of the 
NAI. See 2486bis.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>Once 
the Access-Request reaches the home network the AAA path has already been 
determined. The CUI is applied to the Access-Accept.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=334572222-21122004>Hope 
this resolves your concerns.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004>Avi</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=334572222-21122004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Bikramjit Singh 
  [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, December 21, 2004 3:53 
  PM<BR><B>To:</B> 'Alan DeKok'; [email-masked]'<BR><B>Subject:</B> RE: 
  Scope of applicability for CUI<BR><BR></FONT></DIV>
  <P><FONT size=2>I have been reading this thread for a while and I am not sure 
  if this attribute helps in 2 scenarios that an intermediary can 
  face...</FONT></P>
  <P><FONT size=2>1) The wholesale billing plans that are being seen currently 
  in WLAN roaming world are based on per-user-per-location for 24 hour period. 
  That means that the same user is allowed to login and logout any number of 
  times from that location and he will be charged only once for that 24 hour 
  period.. This requires correlation of the multiple RADIUS sessions of that 
  user from a particular location (NAS) and currently this is being achieved by 
  using the username and NAS-ID attribute.. How would we be able to do this once 
  TTLS EAP or other protected mechanisms are required and 802.1x becomes a 
  requirement for the roaming world?? The CUI will not be able to be of much 
  help since the home AAA can theoretically send the same CUI for all its users 
  logins from that location so that it doesn't have to pay the intermediary for 
  separate users.. This is a not an issue in a clear-text username attribute 
  correlation where an intermediary knows who is being authenticated and 
  accounted for.</FONT></P>
  <P><FONT size=2>2) Consider a business relationship scenario like this.</FONT> 
  </P>
  <P><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  +---C----+---E </FONT><BR><FONT 
  size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> <BR><FONT 
  size=2>A-------B-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +---D</FONT> 
  <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT> 
  <BR><FONT size=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  +------------+</FONT> </P>
  <P><FONT size=2>B is the intermediary and C is an intermediary.. B would like 
  to deny access to D through C since it has a direct roaming agreement with D 
  or atleast it wants to tell D that the only way to get access to A (access 
  network) is through B.. But by using protected usernames, D can do a roaming 
  relationship with C without B knowing about it and maybe C is getting a better 
  deal for it since it has already negotiated discounted rates with B and it is 
  getting a piece of the pie even in the case where it is not required... For 
  whatever reasons, how can B know that a particular request is finally ending 
  up in D via C if the user identity is hidden.. CUI will not help in this 
  scenario either.. B has to do business with C since C has exclusive access to 
  E.. But B knows that it can get to D on its own and wants to shut off access 
  for D's users if they are being authenticated through C.. Apart from pricing 
  model restrictions, what is the technical feasibility using RADIUS to 
  allow/deny this from happening... Right now there is a way using usernames 
  that if the username is C/[email-masked] then B can reject that access-request.. 
  however if it is C/xdfaer342 (encrypted) then how does B prevent it?? 
  </FONT></P>
  <P><FONT size=2>Thanks</FONT> </P>
  <P><FONT size=2>-Bik</FONT> </P>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
  [email-masked] [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  On Behalf Of Alan DeKok</FONT> <BR><FONT size=2>Sent: Tuesday, December 21, 
  2004 12:09 PM</FONT> <BR><FONT size=2>To: [email-masked]</FONT> 
  <BR><FONT size=2>Subject: Re: Scope of applicability for CUI </FONT></P>
  <P><FONT size=2>Avi Lior &lt;[email-masked]&gt; wrote:</FONT> 
  <BR><FONT size=2>&gt; Yes there is only one instance. But that is the least of 
  the differences.</FONT> <BR><FONT size=2>&gt; Unlike Class, CUI is supposed to 
  be interpreted by the client.&nbsp; In so far</FONT> <BR><FONT size=2>&gt; 
  that the client knows the CUI is assertion by the Home Network that this 
  is</FONT> <BR><FONT size=2>&gt; a handle to a subscriber.</FONT> </P>
  <P><FONT size=2>&nbsp; If the main purpose of the CUI is to give an opaque 
  handle to a</FONT> <BR><FONT size=2>subscriber so proxies can control multiple 
  logins, then I'm not sure</FONT> <BR><FONT size=2>what it gains us.&nbsp; The 
  home server can limit multiple logins, so the</FONT> <BR><FONT size=2>proxy 
  server doesn't have to.&nbsp; As Emile said, if the proxy server</FONT> 
  <BR><FONT size=2>doesn't trust the home server to manage multiple logins, it 
  shouldn't</FONT> <BR><FONT size=2>trust the home server to create the same CUI 
  for the same user.</FONT> </P>
  <P><FONT size=2>&nbsp; The main benefit I see is that the multiple login use 
  of the CUI is</FONT> <BR><FONT size=2>managed by the proxy server, which means 
  the home servers can be</FONT> <BR><FONT size=2>simpler to configure.</FONT> 
  </P>
  <P><FONT size=2>&nbsp; If that's the main reason for CUI, then I would like to 
  see a</FONT> <BR><FONT size=2>sentence or two in the document explaining the 
  different approaches,</FONT> <BR><FONT size=2>the issues with CUI, and why 
  this approach was chosen.</FONT> </P>
  <P><FONT size=2>&nbsp; I'm not opposing it, I just want the reasons for 
  choosing it to be</FONT> <BR><FONT size=2>clear 3 years from now to people 
  outside of radiusext.</FONT> </P>
  <P><FONT size=2>&nbsp; Alan DeKok.</FONT> </P>
  <P><FONT size=2>--</FONT> <BR><FONT size=2>to unsubscribe send a message to 
  [email-masked] with</FONT> <BR><FONT size=2>the word 
  'unsubscribe' in a single line as the message text body.</FONT> <BR><FONT 
  size=2>archive: &lt;<A href="http://psg.com/lists/radiusext/" 
  target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> 
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4E7B0.E5B98EA0--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:46:31 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:46:13 -0500

Well originally everyone wanted to be compliant to Diameter CC and that is
exactly what we did.

Now ....

I think the current draft works.  It lines up with Diameter CC and also
provides a CUI that looks like NAI.

I thought we were done comparing CUI to Class.  There is no comparison
between these attributes.

I also get the feeling that even if we said what you said to do that someone
out there would still compare CUI to Class.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 5:35 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
>  
> > I am sure some of you folks are amuzed by the number of messages and
> the
> > circular nature that are being generated for an RFC with one
> attribute.
> 
> I'm sure some are.  :-)
> 
> Maybe if we focused on thinking of CUI as an alternate form 
> of User-Name (just like User-Name, except for ...) instead of 
> focusing on comparing and contrasting CUI and Class, it would 
> make the issues clearer.
> 
> Could we generically describe CUI as having the same format 
> and syntax as User-Name, with the difference being that 
> User-Name originates from the end-station (client of the NAS) 
> when used in an Access-Request, has "routing" semantics in 
> Proxy deployments, and can be returned in an Access-Accept 
> with modified content, while CUI originates from the Home AAA 
> server, has no "routing" semantics, and cannot be modified.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:36:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:34:52 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...
=20
> I am sure some of you folks are amuzed by the number of messages and
the
> circular nature that are being generated for an RFC with one
attribute.

I'm sure some are.  :-)

Maybe if we focused on thinking of CUI as an alternate form of User-Name
(just like User-Name, except for ...) instead of focusing on comparing
and contrasting CUI and Class, it would make the issues clearer.

Could we generically describe CUI as having the same format and syntax
as User-Name, with the difference being that User-Name originates from
the end-station (client of the NAS) when used in an Access-Request, has
"routing" semantics in Proxy deployments, and can be returned in an
Access-Accept with modified content, while CUI originates from the Home
AAA server, has no "routing" semantics, and cannot be modified.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:20:20 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:20:00 -0500

Because we want to get the document out. And we don't need to enumerate all
possible scenarios.  That is just silly and it is not done anywhere else.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 4:50 PM
> To: Avi Lior; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > > There have been suggestions made that the content of CUI has some 
> > > local semantics at the NAS or a Proxy, beyond its utility for 
> > > inclusion in on-line or off-line accounting records.  To 
> the extent 
> > > that common use cases for local semantics (e.g. limitation of 
> > > simultaneous logins) are identified, they should be 
> documented, in 
> > > the interest of global, multi-vendor interoperability.
> > 
> > I think we cover that. But there are many other cases as 
> well. I don't 
> > think we should start enumerating these uses.
> 
> Why not?
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:18:19 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:17:55 -0500

I am sure some of you folks are amuzed by the number of messages and the
circular nature that are being generated for an RFC with one attribute.

CUI is by agreement will be long lived.  In some cases where the user's
privacy is not a concern CUI is very long lived.

In other cases it has a life time that is "long enough" to act as a handle
and not too long as to allow it to reveal the user identities.  The business
relationship will dictate the length. Is it one billing period, is it a day
etc...

The value of class could change from second to second. In our implmenetation
it would change because it is signed and encrypted etc and the Class
associated with Joe's second login will be almost gauarnateed to be
different.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 5:07 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > Amongst other differences Class can change between 
> authentications of
> the
> > same subscriber.
> > 
> > Joe logs in Class = A
> > Joe logs in again Class = B.
> 
> And given the finite lifetime of a single instance of CUI, 
> who's to say that Joe won't get two different (temporary) 
> instances of CUI upon successive logins?  I don't see this as 
> a fundamental (i.e. invariate, always true) difference 
> between the attributes.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:07:40 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:07:16 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> Amongst other differences Class can change between authentications of
the
> same subscriber.
>=20
> Joe logs in Class =3D A
> Joe logs in again Class =3D B.

And given the finite lifetime of a single instance of CUI, who's to say
that Joe won't get two different (temporary) instances of CUI upon
successive logins?  I don't see this as a fundamental (i.e. invariate,
always true) difference between the attributes.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 22:03:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 17:02:10 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolff writes...

> Whether the CUI is opaque or an NAI does not change the fact that
> it should be meaningful only to the home server.  The only test
> that the NAS/proxy should be able to make on CUI is for equality
> to some previously seen CUI.  Otherwise the privacy of the user has
> been compromised for no legitimate reason.  A business agreement
> on how long a one-to-one relation between CUI and the "true" user
> identity must persist does not depend in any way on the form of the
> CUI.  Given that, I would have said the opposite, that CUI should
> always be an opaque octet string.

I wonder if we are using the word "transparent" in a similar fashion?
My argument is that the format and syntax of the CUI be standardized.
That is what I means by transparent.  I mean that it is possible for the
NAS or Proxy to parse the CUI attribute and do something with the
content, such as export it to a local backup accounting system.
Reconciliation of accounting/billing information between intermediaries
and home AAA operators has been listed as one of the use cases for CUI.
In that event, the intermediaries need to be able to know what form it
takes.

It does not, of course, mean that having the CUI "parsed" will remove
any of the privacy.  The fact that I can look at a CUI of the form
[email-masked] does not assist me in
mapping that CUI to the human user behind it.  Ostensibly, only the Home
AAA Server can do that.

Beyond that, any notion of "security by obscurity" in allowing undefined
syntax and formats for the CUI seems pointless.

I don't advocate the loss of privacy, just the standardization of packet
payload formats. =20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:59:03 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:58:47 -0500

Amongst other differences Class can change between authentications of the
same subscriber.

Joe logs in Class = A
Joe logs in again Class = B.

Also 2865 does not allow a Client to interpret Class.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 4:48 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Barney Wolf writes...
> 
> > Whether the CUI is opaque or an NAI does not change the 
> fact that it 
> > should be meaningful only to the home server.  The only 
> test that the 
> > NAS/proxy should be able to make on CUI is for equality to some 
> > previously seen CUI.  Otherwise the privacy of the user has been 
> > compromised for no legitimate reason.  A business agreement on how 
> > long a one-to-one relation between CUI and the "true" user identity 
> > must persist does not depend in any way on the form of the 
> CUI.  Given 
> > that, I would have said the opposite, that CUI should always be an 
> > opaque octet string.
> 
> Well, you and Avi seem to agree on this, but if that is the 
> case, how is CUI different from Class?
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:57:17 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI
Date: Tue, 21 Dec 2004 16:56:59 -0500

David,

Opaque value was used in Diameter.

Also, see inline.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 4:46 PM
> To: [email-masked]
> Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI
> 
> 
> > Infact, I think that only the oqaque value should have been 
> placed in
> the
> > draft in the first place.  SDOs then can define what format 
> they want
> to
> > use.
> 
> I completely disagree.  This is the sort of loose definition 
> that has caused interoperability issues with RADIUS in the past.
> 
> This attribute should not be viewed as an "opaque transport 
> mechanism" for SDOs and individual vendors to create 
> proprietary, non-interoperable implementations that appear to 
> have the imprimatur of IETF standardization.
> 
> > One it allows the home network to create a handle for the 
> user that is 
> > private. It's a number that represents the user for a 
> period of time.
> 
> Hmmm...  I'm confused.  Is the CUI private to the Home AAA 
> server?  In that case Class will do as well, so I think this 
> cannot be a valid justification.

Sorry being rushed here a bit.  Handle for the user that makes the identity
private.  It's a handle to an assertion made by the home network that states
that this Auth/Auth represents a unique user in my network.
 
> > As well, the opaque value allows an SDO to define another format for
> the
> > CUI without the need to go to the IETF.
> 
> Which, IMHO, is a Bad Thing (tm).  At least without some form 
> of IETF action, such as Expert Review, as part of the IANA 
> considerations section.

Well. We can agree to disagree here.  IETF defines the protocol. The value
can be defined by any other community that wishes to interoperate.  No need
to burden IANA or IETF. After all we are talking about a value for an
attribute.

The only time you would need to go to IETF is when that group seeks to
Interoperate in a more global sense.

> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:50:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:49:59 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Avi Lior writes...

> > There have been suggestions made that the content of CUI has
> > some local semantics at the NAS or a Proxy, beyond its
> > utility for inclusion in on-line or off-line accounting
> > records.  To the extent that common use cases for local
> > semantics (e.g. limitation of simultaneous logins) are
> > identified, they should be documented, in the interest of
> > global, multi-vendor interoperability.
>=20
> I think we cover that. But there are many other cases as well.
> I don't think we should start enumerating these uses.

Why not?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:48:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:47:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Barney Wolf writes...

> Whether the CUI is opaque or an NAI does not change the fact that
> it should be meaningful only to the home server.  The only test
> that the NAS/proxy should be able to make on CUI is for equality
> to some previously seen CUI.  Otherwise the privacy of the user has
> been compromised for no legitimate reason.  A business agreement
> on how long a one-to-one relation between CUI and the "true" user
> identity must persist does not depend in any way on the form of the
> CUI.  Given that, I would have said the opposite, that CUI should
> always be an opaque octet string.

Well, you and Avi seem to agree on this, but if that is the case, how is
CUI different from Class?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:45:55 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI
Date: Tue, 21 Dec 2004 16:45:31 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> Infact, I think that only the oqaque value should have been placed in
the
> draft in the first place.  SDOs then can define what format they want
to
> use.

I completely disagree.  This is the sort of loose definition that has
caused interoperability issues with RADIUS in the past.

This attribute should not be viewed as an "opaque transport mechanism"
for SDOs and individual vendors to create proprietary, non-interoperable
implementations that appear to have the imprimatur of IETF
standardization.

> One it allows the home network to create a handle for the user that is
> private. It's a number that represents the user for a period of time.

Hmmm...  I'm confused.  Is the CUI private to the Home AAA server?  In
that case Class will do as well, so I think this cannot be a valid
justification.

> As well, the opaque value allows an SDO to define another format for
the
> CUI without the need to go to the IETF.

Which, IMHO, is a Bad Thing (tm).  At least without some form of IETF
action, such as Expert Review, as part of the IANA considerations
section.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:43:33 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:43:17 -0500

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 4:15 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Emile van Bergen writes...
> 
> > And I also think that we shouldn't try to hide the fact 
> that Class can 
> > also solve a lot of the scenarios. It should be /very/ 
> clear what the 
> > differences and limitations are of each, eg.:
> > 
> > 	Class can be used by a home AAA and any intermediate to
> > 	provide itself, and itself only, with a cookie set at accept
> > 	time and received at accounting time.
> > 
> > 	CUI can be used by a home AAA to provide a value to the client
> > 	and each intermediate, set at accept time and received at
> > 	accounting time. It can be used at accounting time, and when
> > 	receiving an accept, in deciding whether or not to honour it.
> > 
> > 	The other properties of CUI follow from that: only one instance,
> > 	and no modifications allowed.
> > 
> > 	Because intermediates cannot add their own CUI, it cannot be
> > 	used by intermediates to implement their own tracking schemes.
> > 	In such cases they need Class, not CUI.
> 
> This is a good summary, I think.

I agree with the summary.  I object to telling people why they should use
class.

And class is not only used for tracking. So lets leave it for other
documents to specify what class should or should not be used for.

> One point that should be emphasized is that the content of 
> CUI is the Home AAA Server's *assertion* of [billable, 
> chargeable] identity, and all "downstream" entities should 
> trust its content to be meaningful only to the extent that 
> the Home AAA Server, and the organization that operates it, 
> are both reliable and trustworthy.

I think we do that in the draft.
 
> There have been suggestions made that the content of CUI has 
> some local semantics at the NAS or a Proxy, beyond its 
> utility for inclusion in on-line or off-line accounting 
> records.  To the extent that common use cases for local 
> semantics (e.g. limitation of simultaneous logins) are 
> identified, they should be documented, in the interest of 
> global, multi-vendor interoperability.

I think we cover that. But there are many other cases as well. I don't think
we should start enumerating these uses.
 
> Given this description of CUI, what is the utility of the 
> opaque data format of CUI?  I understand that opaqueness can 
> be rendered transparent with the bilateral sharing of 
> proprietary information, pursuant to a business contract.  
> However, that exception notwithstanding, if the intent of CUI 
> is visibility and utility to the NAS and to the Proxies, I 
> suggest that the opaque data format be removed from the draft.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:39:57 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:39:39 -0500

The business cases for CUI have already been stated.  And I think the next
email shows yet another driver.

I belive we already state why Class does not work and why CUI was choosen.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 3:09 PM
> To: [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Avi Lior <[email-masked]> wrote:
> > Yes there is only one instance. But that is the least of the 
> > differences. Unlike Class, CUI is supposed to be interpreted by the 
> > client.  In so far that the client knows the CUI is 
> assertion by the 
> > Home Network that this is a handle to a subscriber.
> 
>   If the main purpose of the CUI is to give an opaque handle 
> to a subscriber so proxies can control multiple logins, then 
> I'm not sure what it gains us.  The home server can limit 
> multiple logins, so the proxy server doesn't have to.  As 
> Emile said, if the proxy server doesn't trust the home server 
> to manage multiple logins, it shouldn't trust the home server 
> to create the same CUI for the same user.
> 
>   The main benefit I see is that the multiple login use of 
> the CUI is managed by the proxy server, which means the home 
> servers can be simpler to configure.
> 
>   If that's the main reason for CUI, then I would like to see 
> a sentence or two in the document explaining the different 
> approaches, the issues with CUI, and why this approach was chosen.
> 
>   I'm not opposing it, I just want the reasons for choosing 
> it to be clear 3 years from now to people outside of radiusext.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:39:38 +0000
Date: Tue, 21 Dec 2004 16:39:07 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Scope of applicability for CUI

On Tue, Dec 21, 2004 at 04:14:52PM -0500, Nelson, David wrote:
> 
> There have been suggestions made that the content of CUI has some local
> semantics at the NAS or a Proxy, beyond its utility for inclusion in
> on-line or off-line accounting records.  To the extent that common use
> cases for local semantics (e.g. limitation of simultaneous logins) are
> identified, they should be documented, in the interest of global,
> multi-vendor interoperability.
> 
> Given this description of CUI, what is the utility of the opaque data
> format of CUI?  I understand that opaqueness can be rendered transparent
> with the bilateral sharing of proprietary information, pursuant to a
> business contract.  However, that exception notwithstanding, if the
> intent of CUI is visibility and utility to the NAS and to the Proxies, I
> suggest that the opaque data format be removed from the draft.

Whether the CUI is opaque or an NAI does not change the fact that
it should be meaningful only to the home server.  The only test
that the NAS/proxy should be able to make on CUI is for equality
to some previously seen CUI.  Otherwise the privacy of the user has
been compromised for no legitimate reason.  A business agreement
on how long a one-to-one relation between CUI and the "true" user
identity must persist does not depend in any way on the form of the
CUI.  Given that, I would have said the opposite, that CUI should
always be an opaque octet string.

Regards,
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:38:52 +0000
Content-class: urn:content-classes:message
Subject: Issue: Transparency (e.g. NAS visibility of) CUI
Date: Tue, 21 Dec 2004 16:37:57 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Oh, yeah... the template.  Sorry.  :-(

Description of issue: The transparency (e.g. NAS visibility) of CUI
Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: December 21, 1004
Reference: (general CUI thread on the lsit)
Document: draft-ietf-radext-chargeable-user-id-00.txt
Comment type: T
Priority: S
Section: 2.1
Rationale/Explanation of issue:

Since CUI is intended for utilization at the NAS and at intermediate
Proxies in a way that is not possible using the Class attribute, what is
the utility of the opaque data format of CUI?  I understand that
opaqueness can be rendered transparent with the bilateral sharing of
proprietary information, pursuant to a business contract.  However, that
exception notwithstanding, if the intent of CUI is visibility and
utility to the NAS and to the Proxies, I suggest that the opaque data
format be removed from the draft, in the interest of global,
multi-vendor interoperability.

Requested change:

In Section 2.1, delete the following text:

    " 04 - Opaque string
         Opaque string is a value that is assigned to the user by the
         home network in an unspecified format, where the home network
         asserts that this value represents a particular user. "

and modify the following text, from:

     " 05 - reserved "
to:

     " 04-FF - reserved "

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:36:42 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI
Date: Tue, 21 Dec 2004 16:36:16 -0500

Infact, I think that only the oqaque value should have been placed in the
draft in the first place.  SDOs then can define what format they want to
use.

The opaque value gives us two capabilities.

One it allows the home network to create a handle for the user that is
private. It's a number that represents the user for a period of time.

As well, the opaque value allows an SDO to define another format for the CUI
without the need to go to the IETF. 

Some of the current values for the CUI are very specific to 3GPP and 3GPP2.
I felt that the IETF should have provided an opaque value and let those
organizations define the contents.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 4:23 PM
> To: [email-masked]
> Subject: Issue: Transparency (e.g. NAS visibility of) CUI
> 
> 
> Since CUI is intended for utilization at the NAS and at 
> intermediate Proxies in a way that is not possible using the 
> Class attribute, what is the utility of the opaque data 
> format of CUI?  I understand that opaqueness can be rendered 
> transparent with the bilateral sharing of proprietary 
> information, pursuant to a business contract.  However, that 
> exception notwithstanding, if the intent of CUI is visibility 
> and utility to the NAS and to the Proxies, I suggest that the 
> opaque data format be removed from the draft, in the interest 
> of global, multi-vendor interoperability.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:24:27 +0000
Content-class: urn:content-classes:message
Subject: Issue: Transparency (e.g. NAS visibility of) CUI
Date: Tue, 21 Dec 2004 16:23:09 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Since CUI is intended for utilization at the NAS and at intermediate
Proxies in a way that is not possible using the Class attribute, what is
the utility of the opaque data format of CUI?  I understand that
opaqueness can be rendered transparent with the bilateral sharing of
proprietary information, pursuant to a business contract.  However, that
exception notwithstanding, if the intent of CUI is visibility and
utility to the NAS and to the Proxies, I suggest that the opaque data
format be removed from the draft, in the interest of global,
multi-vendor interoperability.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:18:11 +0000
From: Avi Lior <[email-masked]>
To: 'Emile van Bergen' <[email-masked]>, Avi Lior <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:17:56 -0500

Hi Emile,

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Tuesday, December 21, 2004 3:14 PM
> To: Avi Lior
> Cc: Jari Arkko; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Hi,
> 
> On Tue, Dec 21, 2004 at 10:56:43AM -0500, Avi Lior wrote:
> 
> > I think we agree overall.
> 
> Indeed.
> 
> > See comments inline.
> 
> Same here.
> 
> > > -----Original Message-----
> > > From: Emile van Bergen [mailto:[email-masked]]
> > > Sent: Monday, December 20, 2004 5:36 PM
> > > To: Jari Arkko
> > > Cc: Avi Lior; [email-masked]
> > > Subject: Re: Scope of applicability for CUI
> > > 
> > > 
> > > Hi,
> > > 
> > > Ok, I understand that. But then it seems to me that CUI could
> > > get the exact same semantics of Class, with the exception 
> > > that there may only be one instance present.
> > 
> > Hmmmmm....When explaining CUI to some folks I must admit 
> that I said 
> > it was "Like Class but different".  The differences are what matter 
> > though.
> > 
> > Yes there is only one instance. But that is the least of the 
> > differences. Unlike Class, CUI is supposed to be interpreted by the 
> > client.  In so far that the client knows the CUI is 
> assertion by the 
> > Home Network that this is a handle to a subscriber.
> 
> I still fail to see how the fact that the home network not 
> only accepts the user but has also associated the login with 
> a 'subscriber' is in any way interesting to any intermediate 
> or the client.

In order to support one of the cases this must happen no? Your acceptance of
the scenario that Jari presented (which is really my scneario) requires this
to happen.

> 
> The policies applied by the home AAA should be irrelevant to 
> anyone else, as long as 'accept' means that it's willing to 
> accept the bill for the session.

I am not going to "battle" with you on this.
 
> If the intermediate or client doesn't trust the home AAA in 
> that, it shouln't send requests there or act upon its accepts.

If the world were only that simple.
 
> I fail to see how the fact that the home AAA has succeeded in 
> associating the login with anything is relevant to anyone 
> else in the chain.

See your next remark.  If you agree with that then that should be good
enough no?

> The only use I can see for that is as was suggested by Jari, 
> to outsource the counting of sessions per 'user' (as defined 
> by the home
> AAA) from the home AAA to an intermediate or the client. In 
> circumstances 
> where the home AAA wishes to provide the key for the counter, CUI 
> addresses that need.

Be as it may there are two cases that have been articulated:
-Accounting case, where Accounting needs to be mediated, concoledated at
intermediares based on userids or a handle to the user; and the last case.
 
> > Clients must not modify CUI whereas they can modify Class providing 
> > they restore class in the accounting stream.
> 
> Right, this is in line with 'only one instance', so that the 
> whole chain sees the same thing, defined by the home AAA. 

Not sure I follow what you mean.

> > Clients that understand CUI must ensure that CUI is placed in the 
> > Accounting Packets.  With Class this is a SHOULD.
> 
> And a shame that SHOULD is. I know that the process would be 
> difficult, and that a MUST there wouldn't provide the other 
> features CUI has over Class, but as I said earlier, for new 
> applications I'd always favour tightening requirements like 
> that to already implemented practice (echoing Class is 
> nothing new), than working around the problem by creating a 
> new application specific attribute.

But even if you made the specs as tight as you wanted. Class does not
address the mail (as acknowledged by you).
 
> It's not uncommon for roaming brokers to demand stricter 
> conformance in areas where that is required.
> 
> But it's a moot point here because of the other properties of CUI.

Right.
 
> > > And I think to avoid the confusion, it should be made more
> > > clear then that CUI is only a communications device from a 
> > > home AAA (at the time of accept) to a proxy AAA (at the time 
> > > of accept and when accounting, via the NAS); for all 'normal' 
> > > cases, Class should be used.
> > 
> > No I disagree strongly with that direction.  Class should not even 
> > enter this picture. It's role is to allow the issuer of the Class 
> > attribute to correlate accounting records for its own purpose.
> > 
> > I think people understand the purpose of class. We just 
> explained in 
> > the document why we couldn't use class. But I feel that even that 
> > should not be present in the document.
> 
> I disagree. The document should do its utmost to explain when 
> CUI offers anything above Class. Class is more generic, and 
> in most cases, more flexible as every hop in the chain can do 
> its own tracking using an extra instance or by modifying the value. 

We already say why Class doesn't work in the document.  What we should not
say is "For all 'normal" cases use Class".  

Class has a purpose and that is articulated elsewhere.  

> CUI is only more useful if you want to communicate one 
> identifier, defined by the home network, to the other parties 
> in the chain.
> 
> > > An empty CUI as advertisement violates RFC2865 though, which
> > > says that empty string attributes MUST NOT be sent [p. 24]. 
> > 
> > I agree so we send a NULL.  Good point though, many people 
> don't get 
> > that.
> 
> Ah, the second L gave me some confusion. I associated it with 
> SQL. I think the ASCII mnemonic for the \0 character is NUL (one L).

Sure. Sorry for the confusion.

> > > I still think it's a bit weird for an intermediate to enforce
> > > a limit (on simultaneous use, no less) based on data supplied 
> > > by the home AAA, instead of the home AAA enforcing that limit 
> > > itself. With the use of CUI as in your example, iPass needs 
> > > to  trust the home AAA that it doesn't simply generate a 
> > > random CUI for every single authentication to thwart such a limit.
> > 
> > Absolutely.
> 
> [snip]
> 
> > > No need for trust, and no need for CUI; this actually seems a
> > > better solution for your scenario.
> > 
> > In the case where they are counting ports per ISP you are 
> right. But 
> > that is not the scenario we are trying to solve.
> 
> [snip]
> 
> > CUI solves a problem that we know and understand today. It 
> can be used 
> > for other purposes I am sure.  That is why we are very 
> insistant that 
> > we don't tie its use specifically to EAP and 2486bis.
> 
> And the specific problem being solved is the client or 
> intermediate's ability to count ports per 'user' as defined 
> by the home AAA? To allow the home AAA to say, if you see 
> this guy/CUI already logged in (and the client knows with 
> certainty whether or not it is), please ignore my accept -- 
> if the home AAA and the client owner have established such a 
> policy together?
> 
> In that case I think it's a good idea. However, I think it 
> would be valuable if we leave it as generic as that (ie. a 
> device for the home AAA to communicate a value at accept time 
> to the other parties at accept and accounting time), and 
> allow any application that the chain may agree on. Whether 
> that's limiting or counting simultaneous use, fraud 
> prevention, or whatever.

Yes. But some wanted the business justification. So read the latest draft
and tell us whether you find it offensive. 
 
> And I also think that we shouldn't try to hide the fact that 
> Class can also solve a lot of the scenarios. It should be 
> /very/ clear what the differences and limitations are of each, eg.:
> 
> 	Class can be used by a home AAA and any intermediate to
> 	provide itself, and itself only, with a cookie set at accept
> 	time and received at accounting time.

Yes. Stated in the draft when we explain why Class does not work.

> 	CUI can be used by a home AAA to provide a value to the client
> 	and each intermediate, set at accept time and received at
> 	accounting time. It can be used at accounting time, and when
> 	receiving an accept, in deciding whether or not to honour it.

Yes I think this is covered.

> 	The other properties of CUI follow from that: only one instance,
> 	and no modifications allowed.

Already mentioned in the draft.

> 	Because intermediates cannot add their own CUI, it cannot be
> 	used by intermediates to implement their own tracking schemes.
> 	In such cases they need Class, not CUI.

That is a given. We don't need to say that.  But it is also not true.  If
you know CUI is there you could use if for tracking.  Since CUI or CUI @
home realm is going to be unique I can use it for tracking.  So we don't
want to go and tell people what they ought to do with Class.  After all
Class maynot be used for tracking in the first place.  Class is a cookie
that is the best and safest way to describe it and its use.

> The advertising business is really a separate issue; 
> considering Class' SHOULD, it would also benefit from that.
> 
> At any rate, a document describing CUI that ignores Class, 
> will waste a lot of users' time on trying to use it when they 
> should use class, and vice versa.The differences are subtle, 
> but important, and therefore they should be discussed together.

Well as I said we say what CUI is for and we say why Class doesn't work. I
don't think we need to tell people how and for what to use Class.

> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:16:20 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 16:14:52 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Emile van Bergen writes...

> And I also think that we shouldn't try to hide the fact that Class can
> also solve a lot of the scenarios. It should be /very/ clear what the
> differences and limitations are of each, eg.:
>=20
> 	Class can be used by a home AAA and any intermediate to
> 	provide itself, and itself only, with a cookie set at accept
> 	time and received at accounting time.
>=20
> 	CUI can be used by a home AAA to provide a value to the client
> 	and each intermediate, set at accept time and received at
> 	accounting time. It can be used at accounting time, and when
> 	receiving an accept, in deciding whether or not to honour it.
>=20
> 	The other properties of CUI follow from that: only one instance,
> 	and no modifications allowed.
>=20
> 	Because intermediates cannot add their own CUI, it cannot be
> 	used by intermediates to implement their own tracking schemes.
> 	In such cases they need Class, not CUI.

This is a good summary, I think.

One point that should be emphasized is that the content of CUI is the
Home AAA Server's *assertion* of [billable, chargeable] identity, and
all "downstream" entities should trust its content to be meaningful only
to the extent that the Home AAA Server, and the organization that
operates it, are both reliable and trustworthy.

There have been suggestions made that the content of CUI has some local
semantics at the NAS or a Proxy, beyond its utility for inclusion in
on-line or off-line accounting records.  To the extent that common use
cases for local semantics (e.g. limitation of simultaneous logins) are
identified, they should be documented, in the interest of global,
multi-vendor interoperability.

Given this description of CUI, what is the utility of the opaque data
format of CUI?  I understand that opaqueness can be rendered transparent
with the bilateral sharing of proprietary information, pursuant to a
business contract.  However, that exception notwithstanding, if the
intent of CUI is visibility and utility to the NAS and to the Proxies, I
suggest that the opaque data format be removed from the draft.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 21:00:55 +0000
From: Bikramjit Singh <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Scope of applicability for CUI 
Date: Tue, 21 Dec 2004 12:52:49 -0800

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E79F.0828FFDC
Content-Type: text/plain

I have been reading this thread for a while and I am not sure if this
attribute helps in 2 scenarios that an intermediary can face...

1) The wholesale billing plans that are being seen currently in WLAN roaming
world are based on per-user-per-location for 24 hour period. That means that
the same user is allowed to login and logout any number of times from that
location and he will be charged only once for that 24 hour period.. This
requires correlation of the multiple RADIUS sessions of that user from a
particular location (NAS) and currently this is being achieved by using the
username and NAS-ID attribute.. How would we be able to do this once TTLS
EAP or other protected mechanisms are required and 802.1x becomes a
requirement for the roaming world?? The CUI will not be able to be of much
help since the home AAA can theoretically send the same CUI for all its
users logins from that location so that it doesn't have to pay the
intermediary for separate users.. This is a not an issue in a clear-text
username attribute correlation where an intermediary knows who is being
authenticated and accounted for.

2) Consider a business relationship scenario like this.

          +---C----+---E 
          |        |
A-------B-+        +---D
          |            |
          +------------+

B is the intermediary and C is an intermediary.. B would like to deny access
to D through C since it has a direct roaming agreement with D or atleast it
wants to tell D that the only way to get access to A (access network) is
through B.. But by using protected usernames, D can do a roaming
relationship with C without B knowing about it and maybe C is getting a
better deal for it since it has already negotiated discounted rates with B
and it is getting a piece of the pie even in the case where it is not
required... For whatever reasons, how can B know that a particular request
is finally ending up in D via C if the user identity is hidden.. CUI will
not help in this scenario either.. B has to do business with C since C has
exclusive access to E.. But B knows that it can get to D on its own and
wants to shut off access for D's users if they are being authenticated
through C.. Apart from pricing model restrictions, what is the technical
feasibility using RADIUS to allow/deny this from happening... Right now
there is a way using usernames that if the username is C/[email-masked] then B
can reject that access-request.. however if it is C/xdfaer342 (encrypted)
then how does B prevent it?? 

Thanks

-Bik

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, December 21, 2004 12:09 PM
To: [email-masked]
Subject: Re: Scope of applicability for CUI 

Avi Lior <[email-masked]> wrote:
> Yes there is only one instance. But that is the least of the differences.
> Unlike Class, CUI is supposed to be interpreted by the client.  In so far
> that the client knows the CUI is assertion by the Home Network that this
is
> a handle to a subscriber.

  If the main purpose of the CUI is to give an opaque handle to a
subscriber so proxies can control multiple logins, then I'm not sure
what it gains us.  The home server can limit multiple logins, so the
proxy server doesn't have to.  As Emile said, if the proxy server
doesn't trust the home server to manage multiple logins, it shouldn't
trust the home server to create the same CUI for the same user.

  The main benefit I see is that the multiple login use of the CUI is
managed by the proxy server, which means the home servers can be
simpler to configure.

  If that's the main reason for CUI, then I would like to see a
sentence or two in the document explaining the different approaches,
the issues with CUI, and why this approach was chosen.

  I'm not opposing it, I just want the reasons for choosing it to be
clear 3 years from now to people outside of radiusext.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E79F.0828FFDC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>RE: Scope of applicability for CUI </TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I have been reading this thread for a while and I am =
not sure if this attribute helps in 2 scenarios that an intermediary =
can face...</FONT></P>

<P><FONT SIZE=3D2>1) The wholesale billing plans that are being seen =
currently in WLAN roaming world are based on per-user-per-location for =
24 hour period. That means that the same user is allowed to login and =
logout any number of times from that location and he will be charged =
only once for that 24 hour period.. This requires correlation of the =
multiple RADIUS sessions of that user from a particular location (NAS) =
and currently this is being achieved by using the username and NAS-ID =
attribute.. How would we be able to do this once TTLS EAP or other =
protected mechanisms are required and 802.1x becomes a requirement for =
the roaming world?? The CUI will not be able to be of much help since =
the home AAA can theoretically send the same CUI for all its users =
logins from that location so that it doesn't have to pay the =
intermediary for separate users.. This is a not an issue in a =
clear-text username attribute correlation where an intermediary knows =
who is being authenticated and accounted for.</FONT></P>

<P><FONT SIZE=3D2>2) Consider a business relationship scenario like =
this.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+---C----+---E </FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT =
SIZE=3D2>A-------B-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+---D</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
+------------+</FONT>
</P>

<P><FONT SIZE=3D2>B is the intermediary and C is an intermediary.. B =
would like to deny access to D through C since it has a direct roaming =
agreement with D or atleast it wants to tell D that the only way to get =
access to A (access network) is through B.. But by using protected =
usernames, D can do a roaming relationship with C without B knowing =
about it and maybe C is getting a better deal for it since it has =
already negotiated discounted rates with B and it is getting a piece of =
the pie even in the case where it is not required... For whatever =
reasons, how can B know that a particular request is finally ending up =
in D via C if the user identity is hidden.. CUI will not help in this =
scenario either.. B has to do business with C since C has exclusive =
access to E.. But B knows that it can get to D on its own and wants to =
shut off access for D's users if they are being authenticated through =
C.. Apart from pricing model restrictions, what is the technical =
feasibility using RADIUS to allow/deny this from happening... Right now =
there is a way using usernames that if the username is C/[email-masked] then =
B can reject that access-request.. however if it is C/xdfaer342 =
(encrypted) then how does B prevent it?? </FONT></P>

<P><FONT SIZE=3D2>Thanks</FONT>
</P>

<P><FONT SIZE=3D2>-Bik</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] On Behalf Of Alan DeKok</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, December 21, 2004 12:09 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Scope of applicability for CUI </FONT>
</P>

<P><FONT SIZE=3D2>Avi Lior &lt;[email-masked]&gt; wrote:</FO=
NT>
<BR><FONT SIZE=3D2>&gt; Yes there is only one instance. But that is the =
least of the differences.</FONT>
<BR><FONT SIZE=3D2>&gt; Unlike Class, CUI is supposed to be interpreted =
by the client.&nbsp; In so far</FONT>
<BR><FONT SIZE=3D2>&gt; that the client knows the CUI is assertion by =
the Home Network that this is</FONT>
<BR><FONT SIZE=3D2>&gt; a handle to a subscriber.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; If the main purpose of the CUI is to give an =
opaque handle to a</FONT>
<BR><FONT SIZE=3D2>subscriber so proxies can control multiple logins, =
then I'm not sure</FONT>
<BR><FONT SIZE=3D2>what it gains us.&nbsp; The home server can limit =
multiple logins, so the</FONT>
<BR><FONT SIZE=3D2>proxy server doesn't have to.&nbsp; As Emile said, =
if the proxy server</FONT>
<BR><FONT SIZE=3D2>doesn't trust the home server to manage multiple =
logins, it shouldn't</FONT>
<BR><FONT SIZE=3D2>trust the home server to create the same CUI for the =
same user.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; The main benefit I see is that the multiple =
login use of the CUI is</FONT>
<BR><FONT SIZE=3D2>managed by the proxy server, which means the home =
servers can be</FONT>
<BR><FONT SIZE=3D2>simpler to configure.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; If that's the main reason for CUI, then I =
would like to see a</FONT>
<BR><FONT SIZE=3D2>sentence or two in the document explaining the =
different approaches,</FONT>
<BR><FONT SIZE=3D2>the issues with CUI, and why this approach was =
chosen.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; I'm not opposing it, I just want the reasons =
for choosing it to be</FONT>
<BR><FONT SIZE=3D2>clear 3 years from now to people outside of =
radiusext.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp; Alan DeKok.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with</FONT>
<BR><FONT SIZE=3D2>the word 'unsubscribe' in a single line as the =
message text body.</FONT>
<BR><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E79F.0828FFDC--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 20:08:56 +0000
Date: Tue, 21 Dec 2004 21:13:33 +0100
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Jari Arkko <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI
Mail-Followup-To: Avi Lior <[email-masked]>, Jari Arkko <[email-masked]>, [email-masked]

Hi,

On Tue, Dec 21, 2004 at 10:56:43AM -0500, Avi Lior wrote:

> I think we agree overall.

Indeed.

> See comments inline.

Same here.

> > -----Original Message-----
> > From: Emile van Bergen [mailto:[email-masked]] 
> > Sent: Monday, December 20, 2004 5:36 PM
> > To: Jari Arkko
> > Cc: Avi Lior; [email-masked]
> > Subject: Re: Scope of applicability for CUI
> > 
> > 
> > Hi,
> > 
> > Ok, I understand that. But then it seems to me that CUI could 
> > get the exact same semantics of Class, with the exception 
> > that there may only be one instance present.
> 
> Hmmmmm....When explaining CUI to some folks I must admit that I said it was
> "Like Class but different".  The differences are what matter though.
> 
> Yes there is only one instance. But that is the least of the differences.
> Unlike Class, CUI is supposed to be interpreted by the client.  In so far
> that the client knows the CUI is assertion by the Home Network that this is
> a handle to a subscriber.

I still fail to see how the fact that the home network not only accepts
the user but has also associated the login with a 'subscriber' is
in any way interesting to any intermediate or the client.

The policies applied by the home AAA should be irrelevant to anyone
else, as long as 'accept' means that it's willing to accept the bill for
the session.

If the intermediate or client doesn't trust the home AAA in that, it
shouln't send requests there or act upon its accepts.

I fail to see how the fact that the home AAA has succeeded in
associating the login with anything is relevant to anyone else in the
chain.

The only use I can see for that is as was suggested by Jari, to
outsource the counting of sessions per 'user' (as defined by the home
AAA) from the home AAA to an intermediate or the client. In circumstances 
where the home AAA wishes to provide the key for the counter, CUI 
addresses that need.

> Clients must not modify CUI whereas they can modify Class providing they
> restore class in the accounting stream.

Right, this is in line with 'only one instance', so that the whole chain
sees the same thing, defined by the home AAA. 

> Clients that understand CUI must ensure that CUI is placed in the Accounting
> Packets.  With Class this is a SHOULD.

And a shame that SHOULD is. I know that the process would be difficult,
and that a MUST there wouldn't provide the other features CUI has over
Class, but as I said earlier, for new applications I'd always favour
tightening requirements like that to already implemented practice
(echoing Class is nothing new), than working around the problem by
creating a new application specific attribute.

It's not uncommon for roaming brokers to demand stricter conformance in
areas where that is required.

But it's a moot point here because of the other properties of CUI.

> > And I think to avoid the confusion, it should be made more 
> > clear then that CUI is only a communications device from a 
> > home AAA (at the time of accept) to a proxy AAA (at the time 
> > of accept and when accounting, via the NAS); for all 'normal' 
> > cases, Class should be used.
> 
> No I disagree strongly with that direction.  Class should not even enter
> this picture. It's role is to allow the issuer of the Class attribute to
> correlate accounting records for its own purpose.
> 
> I think people understand the purpose of class. We just explained in the
> document why we couldn't use class. But I feel that even that should not be
> present in the document.

I disagree. The document should do its utmost to explain when CUI offers
anything above Class. Class is more generic, and in most cases, more
flexible as every hop in the chain can do its own tracking using an
extra instance or by modifying the value. 

CUI is only more useful if you want to communicate one identifier,
defined by the home network, to the other parties in the chain.

> > An empty CUI as advertisement violates RFC2865 though, which 
> > says that empty string attributes MUST NOT be sent [p. 24]. 
> 
> I agree so we send a NULL.  Good point though, many people don't get that.  

Ah, the second L gave me some confusion. I associated it with SQL.
I think the ASCII mnemonic for the \0 character is NUL (one L).

> > I still think it's a bit weird for an intermediate to enforce 
> > a limit (on simultaneous use, no less) based on data supplied 
> > by the home AAA, instead of the home AAA enforcing that limit 
> > itself. With the use of CUI as in your example, iPass needs 
> > to  trust the home AAA that it doesn't simply generate a 
> > random CUI for every single authentication to thwart such a limit.
> 
> Absolutely.

[snip]

> > No need for trust, and no need for CUI; this actually seems a 
> > better solution for your scenario.
> 
> In the case where they are counting ports per ISP you are right. But that is
> not the scenario we are trying to solve.

[snip]

> CUI solves a problem that we know and understand today. It can be used for
> other purposes I am sure.  That is why we are very insistant that we don't
> tie its use specifically to EAP and 2486bis.

And the specific problem being solved is the client or intermediate's
ability to count ports per 'user' as defined by the home AAA? To allow
the home AAA to say, if you see this guy/CUI already logged in (and the
client knows with certainty whether or not it is), please ignore my
accept -- if the home AAA and the client owner have established such a
policy together?

In that case I think it's a good idea. However, I think it would be
valuable if we leave it as generic as that (ie. a device for the home
AAA to communicate a value at accept time to the other parties at accept
and accounting time), and allow any application that the chain may agree
on. Whether that's limiting or counting simultaneous use, fraud
prevention, or whatever.

And I also think that we shouldn't try to hide the fact that Class can
also solve a lot of the scenarios. It should be /very/ clear what the
differences and limitations are of each, eg.:

	Class can be used by a home AAA and any intermediate to
	provide itself, and itself only, with a cookie set at accept
	time and received at accounting time.

	CUI can be used by a home AAA to provide a value to the client
	and each intermediate, set at accept time and received at
	accounting time. It can be used at accounting time, and when
	receiving an accept, in deciding whether or not to honour it.

	The other properties of CUI follow from that: only one instance,
	and no modifications allowed.

	Because intermediates cannot add their own CUI, it cannot be
	used by intermediates to implement their own tracking schemes.
	In such cases they need Class, not CUI.

The advertising business is really a separate issue; considering Class'
SHOULD, it would also benefit from that.

At any rate, a document describing CUI that ignores Class, will waste a
lot of users' time on trying to use it when they should use class, and
vice versa.The differences are subtle, but important, and therefore they
should be discussed together.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 21 Dec 2004 19:57:02 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Scope of applicability for CUI 
Date: Tue, 21 Dec 2004 15:08:46 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Yes there is only one instance. But that is the least of the differences.
> Unlike Class, CUI is supposed to be interpreted by the client.  In so far
> that the client knows the CUI is assertion by the Home Network that this is
> a handle to a subscriber.

  If the main purpose of the CUI is to give an opaque handle to a
subscriber so proxies can control multiple logins, then I'm not sure
what it gains us.  The home server can limit multiple logins, so the
proxy server doesn't have to.  As Emile said, if the proxy server
doesn't trust the home server to manage multiple logins, it shouldn't
trust the home server to create the same CUI for the same user.

  The main benefit I see is that the multiple login use of the CUI is
managed by the proxy server, which means the home servers can be
simpler to configure.

  If that's the main reason for CUI, then I would like to see a
sentence or two in the document explaining the different approaches,
the issues with CUI, and why this approach was chosen.

  I'm not opposing it, I just want the reasons for choosing it to be
clear 3 years from now to people outside of radiusext.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 17:22:06 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Emile van Bergen'" <[email-masked]>
Cc: Jari Arkko <[email-masked]>, "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 11:21:32 -0600

Thanks for the explanation Emile, It forced me to go back at RFC 2607 and read the use of class attribute there. However, it says there that the class attribute is not to be modified by the NAS or intermediaries and that is the issue the CUI proponents have with using class.

Madjid

-----Original Message-----
From: Emile van Bergen [mailto:[email-masked]] 
Sent: Monday, December 20, 2004 10:50 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Jari Arkko; 'Avi Lior'; 'Nelson, David'; [email-masked]
Subject: Re: Scope of applicability for CUI

Hi,

On Mon, Dec 20, 2004 at 10:34:30AM -0600, Nakhjiri Madjid-MNAKHJI1 wrote:

> Can you explain it a bit more for the less sophisticated?

Well, a suggestion was made that a. CUI could be learned at the
Access-Accept, and b. that it would be a session identifier to allow the
/home/ AAA and the NAS to correlate their accounting records.

To me, this exactly describes Class; the home AAA is the first source of
the accept after, and thus defines Class; and it can use the Class
received in accounting records to correlate them with the unique access
value it generated earlier in Access-Accept.

The value can be either unique per login, or unique for a certain ad-hoc
identity that allows a number of minutes, or volume during a certain
timeslot.

At any rate, the entity that ultimately charges the user (the home AAA,
that vouches for the user's credentials) defines it, and it's present in
all accounting about this user.

So, the /only/ reason for CUI would be if some home AAA wishes to accept
a user, while expecting an intermediate AAA's owner to bill the user,
and it wants to convey the entity to bill to the intermediate AAA.

That such a scheme with distinguishable CUIs can be easily compromised 
by a non-trusted NAS owner is conveniently ignored. 

I'm of the school of belief that you should only send an accept for a
user if you're willing to foot the bill for him. And for all such
circumstances, Class works fine, and cannot be forged by the NAS owner
or any intermediate proxy owner if properly generated by the home AAA.

Kind regards,

Emile.

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Saturday, December 18, 2004 12:19 PM
> To: Jari Arkko
> Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> Hi,
> 
> On Sat, Dec 18, 2004 at 11:21:13AM +0200, Jari Arkko wrote:
> 
> > This also implies that the CUI is something that can be learned
> > very late in the process, perhaps even as late as in the Access-Accept.
> > 
> > By the way, what would be the meaning of CUI for "pay as you go"
> > type of approaches, e.g., micropayments or the like over EAP?
> > There might not be any billable user identity; the only thing
> > that could be provided in those cases is some kind of a session
> > identifier so that the home AAA and the NAS can correlate their
> > accounting records.
> 
> To paraphrase Henry Spencer: those that do not understand Class are
> condemned to reinvent it -- poorly.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 17:01:32 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: "Romascanu, Dan (Dan)" <[email-masked]>, [email-masked]
Subject: RE: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt
Date: Tue, 21 Dec 2004 18:00:22 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E77E.8EF79102
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Thanks for the review Dan.
=20
Let me add w.r.t. point 6
=20
We do not like the idea of doing a separate subtree for each =
technology.
So=20
     radiusDynamicAuthorization  OBJECT IDENTIFIER ::=3D { radiusMIB 3 =
}
is not good. We'd rather see:
=20
   radiusDynamicAuthorization  OBJECT IDENTIFIER ::=3D { mib-2 xxx } -- =
xxx to be assigned by IANA
=20
The reason is that we have run into clashed (i.e. conflicting =
definitions) when WGs try to keep
track of registrations underneath a MIB branch. See also the =
recommendation
in MIB review guidelines draft-ietf-ops-mib-review-guidelines-03.txt =
sect 4.5, 3rd bullet.
=20
So pls go for assignment under mib-2. If you want to stick
it under radiusMIB, then I'd like to see a document similar
to  RFC3737.
=20
Bert
=20
 -----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, December 20, 2004 15:39
To: [email-masked]
Cc: [email-masked]
Subject: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt

At the request of the Operations and Management Area Director I =
reviewed draft-decnodder-radext-dynauth-client-mib-02.txt. Please find =
below my comments.=20

Regards,

Dan

1. The boilerplate does not conform with the latest recommendations =
referring to Intellectual Property notices. See =
http://www.ietf.org/ietf/1id-guidelines.txt =
<http://www.ietf.org/ietf/1id-guidelines.txt>  =FDfor the mandatory =
notices.=20

2. The Introduction section contains un-expanded acronyms which are not =
public domain knowledge for the Internet community - CoA, NAS. =20

3. Section 5 in this document duplicates much of the similar section 5 =
in draft-decnodder-radext-dynauth-server-mib-02.txt. It may be better =
to avoid duplication by having the respective text be written only in =
one document and referred by the other.=20

4. Section 5, first paragraph - 'The RADIUS dynamic authorization =
extensions ... distinguishes...' - grammar problem

5.Is this MIB module implemented in conjunction with other MIB modules =
- for example those defined in RFC 2618 through 2621? If this is the =
case, this relationship should be discussed in one of the 'narrative' =
sections - probably in Section 5.=20

6. radiusMIB is already defined in other documents - see for example =
RFC 2619 -  RADIUS-AUTH-SERVER-MIB - I suggest that it is imported from =
there.=20

7. What is the purpose of the radiusDynAuthClientIdentifier object? If =
this is about software versions, application names, etc. there are =
objects in other MIB modules already defining this - see for example =
RFC 2737. If there is a something specific about a RADIUS dynamic =
authentication client identifier, some more information is needed.=20

8. DESCRIPTION clause of radiusDynAuthServerEntry. I suggest to say =
'representing one Dynamic...' instead of 'representing the Dynamic...'.

9. The DESCRIPTION clause of radiusDynAuthServerIndex should be clear =
in saying that this number is allocated by the agent implementing this =
MIB module, and unique in this context (and not for an admin domain)

10. Add REFERENCE clauses for objects defining NAS attributes from RFC =
2865, 2869, 3162 - =FDfrom case to case

11. DESCRIPTION clause of radiusDynAuthClientRoundTripTime - this =
should be defined as the time between sending a Disconnect or CoA =
request and the reception of a corresponding Disconnect-reply/CoA-reply =

12. what are the values of the objects in the radiusDynAuthServerEntry =
that depend on processing replies like radiusDynAuthClientRoundTripTime =
before a first reply is received from the server? For example what will =
be returned by an agent implementing this MIB module for =
radiusDynAuthClientRoundTripTime before a first reply is received and a =
meaningful round trip delay can be presented?=20

13. DESCRIPTION clause of  radiusDynAuthClientDisconPacketsDropped - I =
suggest to add '...by the client application' after 'silently =
discarded'.=20

14. same for radiusDynAuthClientCoAPacketsDropped

15. I suggest to add UNITS clauses to the counter objects - packets, =
retransmissions, etc.=20

16. Section 7, 4th paragraph - should be 'These' rather than 'this' =
because the phrase refers to the two objects above

17. Section 9.1 - I wonder if references to RFC 2618 through 2621 are =
really normative references. I do not see the strong dependence on =
these specifications that would justify it.

18. There is no IANA Consideration section. Even if no actions are =
required from IANA, such a section must be present and just mention =
this.=20

------_=_NextPart_001_01C4E77E.8EF79102
Content-Type: text/html;
	charset="windows-1255"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1255">
<TITLE>Comments on draft-decnodder-radext-dynauth-client-mib-02.txt</TITLE>

<META content="MSHTML 6.00.2800.1458" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>Thanks for the 
review Dan.</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>Let me add w.r.t. 
point 6</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>We do not like 
the idea of doing a separate subtree for each technology.</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>So 
</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>&nbsp; 
&nbsp;&nbsp; radiusDynamicAuthorization&nbsp; OBJECT IDENTIFIER ::= { radiusMIB 
3 }</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>is not good. We'd 
rather see:</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>&nbsp;&nbsp; 
radiusDynamicAuthorization&nbsp; OBJECT IDENTIFIER ::= {&nbsp;mib-2 xxx } -- xxx 
to be assigned by IANA</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>The reason is 
that we have run into clashed (i.e. conflicting definitions) when WGs try to 
keep</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>track of 
registrations underneath a MIB branch. See also the 
recommendation</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>in MIB review 
guidelines draft-ietf-ops-mib-review-guidelines-03.txt sect 4.5, 3rd 
bullet.</FONT></SPAN></DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=699165416-21122004><FONT color=#0000ff size=2>So pls go for 
assignment under mib-2. If you want to stick</FONT></SPAN></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=699165416-21122004><FONT 
face=Arial color=#0000ff>it under radiusMIB, then I'd like to see a document 
similar</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=699165416-21122004><FONT 
face=Arial color=#0000ff>to&nbsp; RFC3737.</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=699165416-21122004></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=699165416-21122004>Bert</SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=699165416-21122004></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=699165416-21122004>&nbsp;</SPAN>-----Original Message-----<BR><B>From:</B> 
Romascanu, Dan (Dan) [mailto:[email-masked]]<BR><B>Sent:</B> Monday, 
December 20, 2004 15:39<BR><B>To:</B> [email-masked]<BR><B>Cc:</B> 
[email-masked]<BR><B>Subject:</B> Comments on 
draft-decnodder-radext-dynauth-client-mib-02.txt<BR><BR></DIV></FONT></FONT>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px"><!-- Converted from text/rtf format -->
  <P dir=ltr><FONT face=Arial size=2>At the request of the Operations and 
  Management Area Director I reviewed 
  draft-decnodder-radext-dynauth-client-mib-02.txt. Please find below my 
  comments. </FONT></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Regards,</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>Dan</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>1. The boilerplate does 
  not conform with the latest recommendations referring to Intellectual Property 
  notices. See <A 
  href="http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/ietf/1id-guidelines.txt</A></FONT></SPAN><SPAN 
  lang=he></SPAN><SPAN lang=he><FONT face="Arial (Hebrew)" size=2><SPAN dir=rtl> 
  </SPAN></FONT></SPAN><SPAN lang=en-us></SPAN><SPAN lang=en-us><FONT face=Arial 
  size=2>ýfor the mandatory notices. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>2. The Introduction 
  section contains un-expanded acronyms which are not public domain knowledge 
  for the Internet community - CoA, NAS.&nbsp; </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>3. Section 5 in this 
  document duplicates much of the similar section 5 in</FONT></SPAN><SPAN 
  lang=he> <FONT face=Arial 
  size=2>draft-decnodder-radext-dynauth-server-mib-02.txt. It may be better to 
  avoid duplication by having the respective text be written only in one 
  document and referred by the other. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>4. Section 5, first 
  paragraph - 'The RADIUS dynamic authorization extensions ... distinguishes...' 
  - grammar problem</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>5.Is this MIB module 
  implemented in conjunction with other MIB modules - for example those defined 
  in RFC 2618 through 2621? If this is the case, this relationship should be 
  discussed in one of the 'narrative' sections - probably in Section 5. 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>6. radiusMIB is already 
  defined in other documents - see for example RFC 2619 -&nbsp;</FONT> <FONT 
  face="Times New Roman">RADIUS-AUTH-SERVER-MIB - I suggest that it is imported 
  from there.</FONT></SPAN><SPAN lang=he></SPAN><SPAN lang=he> </SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>7. What is the purpose of 
  the</FONT> <FONT face="Times New Roman">radiusDynAuthClientIdentifier object? 
  If this is about software versions, application names, etc. there are objects 
  in other MIB modules already defining this - see for example RFC 2737. If 
  there is a something specific about a RADIUS dynamic authentication client 
  identifier, some more information is needed. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">8. DESCRIPTION clause 
  of radiusDynAuthServerEntry. I suggest to say 'representing one Dynamic...' 
  instead of 'representing the Dynamic...'.</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">9. The DESCRIPTION 
  clause of radiusDynAuthServerIndex should be clear in saying that this number 
  is allocated by the agent implementing this MIB module, and unique in this 
  context (and not for an admin domain)</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">10. Add REFERENCE 
  clauses for objects defining NAS attributes from RFC 2865, 2869, 
  3162</FONT></SPAN><SPAN lang=he></SPAN><SPAN lang=he> <FONT 
  face="Arial (Hebrew)" size=2><SPAN dir=rtl>- </SPAN></FONT></SPAN><SPAN 
  lang=en-us></SPAN><SPAN lang=en-us><FONT face=Arial size=2>ýfrom case to 
  case</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>11. DESCRIPTION clause 
  of</FONT> <FONT face="Times New Roman">radiusDynAuthClientRoundTripTime - this 
  should be defined as the time between sending a Disconnect or CoA 
  request</FONT> <FONT face=Arial size=2>and the reception of a 
  corresponding</FONT> <FONT face="Times New Roman">Disconnect-reply/CoA-reply 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">12. what are the 
  values of the objects in the radiusDynAuthServerEntry that depend on 
  processing replies</FONT> <FONT face=Arial size=2>like</FONT> <FONT 
  face="Times New Roman">radiusDynAuthClientRoundTripTime before a first reply 
  is received from the server?</FONT> <FONT face=Arial size=2>For example what 
  will be returned by an agent implementing this MIB module for</FONT> <FONT 
  face="Times New Roman">radiusDynAuthClientRoundTripTime before a first reply 
  is received and a meaningful round trip</FONT> <FONT face=Arial size=2>delay 
  can be presented? </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face=Arial size=2>13. DESCRIPTION clause 
  of</FONT>&nbsp;<FONT face="Times New Roman"> 
  radiusDynAuthClientDisconPacketsDropped - I suggest to add '...by the client 
  application' after 'silently discarded'. </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">14. same for 
  radiusDynAuthClientCoAPacketsDropped</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">15. I suggest to add 
  UNITS clauses to the counter objects - packets, retransmissions, etc. 
  </FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">16. Section 7, 4th 
  paragraph - should be 'These' rather than 'this' because the phrase refers to 
  the two objects above</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">17. Section 9.1 - I 
  wonder if references to RFC 2618 through 2621 are really normative references. 
  I do not see the strong dependence on these specifications that would justify 
  it.</FONT></SPAN></P>
  <P dir=ltr><SPAN lang=en-us><FONT face="Times New Roman">18. There is no IANA 
  Consideration section. Even if no actions are required from IANA, such a 
  section must be present and just mention this.<B></B></FONT><B> 
</B></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P>
  <P dir=ltr><SPAN lang=he></SPAN></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4E77E.8EF79102--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 17:01:09 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: Checks on draft-decnodder-radext-dynauth-server-mib-02.txt
Date: Tue, 21 Dec 2004 18:00:21 +0100

--- running idnits ... fyi ---

$ idnits draft-decnodder-radext-dynauth-server-mib-02.txt
idnits 1.58

draft-decnodder-radext-dynauth-server-mib-02.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...
    the boilerplate looks good.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet).

  Miscellaneous warnings:

  - Line 308 has weird spacing: '... client  with ...'

    Run idnits with the --verbose option for more detailed information.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 17:01:04 +0000
From: "Wijnen, Bert (Bert)" <[email-masked]>
To: [email-masked]
Subject: Checks on draft-decnodder-radext-dynauth-client-mib-02.txt
Date: Tue, 21 Dec 2004 18:00:21 +0100

---- running idnits ... fyi ----

$ idnits draft-decnodder-radext-dynauth-client-mib-02.txt
idnits 1.58

draft-decnodder-radext-dynauth-client-mib-02.txt:

  Checking nits according to http://www.ietf.org/ID-Checklist.html :

  * The document seems to lack an IANA Considerations section.
    Checking conformance with RFC 3667/3668 boilerplate...
    the boilerplate looks good.
  * There are 2 instances of lines with control characters in the document.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt :

    Nothing found here (but these checks does not cover all of 1id-guidelines.txt yet).

  Miscellaneous warnings:

  - Line 315 has weird spacing: '... server  with ...'

    Run idnits with the --verbose option for more detailed information.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 21 Dec 2004 15:57:51 +0000
From: Avi Lior <[email-masked]>
To: 'Emile van Bergen' <[email-masked]>, Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Tue, 21 Dec 2004 10:56:43 -0500

Hi Emile,

I think we agree overall.

See comments inline.

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Monday, December 20, 2004 5:36 PM
> To: Jari Arkko
> Cc: Avi Lior; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Hi,
> 
> On Mon, Dec 20, 2004 at 10:30:35PM +0200, Jari Arkko wrote:
> 
> > Avi Lior wrote:
> > 
> > >An intermediate proxy when seeing Authentication/Authorization 
> > >traffic
> > >can't
> > >correlated it to a specific user when methods such as EAP 
> are being used.
> > >
> > >The only thing a intermediary can do is use class to correlate an
> > >accounting
> > >stream with a authentication stream. But it can't 
> correlate that to a
> > >specific user.
> > >
> > >So if iPass wants to limit how many times John logs in 
> (and they do) 
> > >then they would not be able to do so when certain EAP methods are 
> > >being used.
> > 
> > Agreed. This is for me the prime reason why CUI is needed.
> 
> Ok, I understand that. But then it seems to me that CUI could 
> get the exact same semantics of Class, with the exception 
> that there may only be one instance present.

Hmmmmm....When explaining CUI to some folks I must admit that I said it was
"Like Class but different".  The differences are what matter though.

Yes there is only one instance. But that is the least of the differences.
Unlike Class, CUI is supposed to be interpreted by the client.  In so far
that the client knows the CUI is assertion by the Home Network that this is
a handle to a subscriber.
Clients must not modify CUI whereas they can modify Class providing they
restore class in the accounting stream.
Clients that understand CUI must ensure that CUI is placed in the Accounting
Packets.  With Class this is a SHOULD.

> And I think to avoid the confusion, it should be made more 
> clear then that CUI is only a communications device from a 
> home AAA (at the time of accept) to a proxy AAA (at the time 
> of accept and when accounting, via the NAS); for all 'normal' 
> cases, Class should be used.

No I disagree strongly with that direction.  Class should not even enter
this picture. It's role is to allow the issuer of the Class attribute to
correlate accounting records for its own purpose.

I think people understand the purpose of class. We just explained in the
document why we couldn't use class. But I feel that even that should not be
present in the document.

> 
> Let's try to work out your example a little. A proxy AAA like iPass' 
> could refuse to forward the accept towards the NAS if it 
> doesn't receive a CUI from the home AAA, and send a reject 
> instead. Ok.

Sure.
 
> Similarly, if it wants to get (some) certainty about whether 
> it can expect to receive CUI in the subsequent accounting 
> from the NAS, it could reject all requests from NASes that 
> don't advertise their support for echoing CUI by putting a 
> dummy CUI in their access requests.

Sure.
 
> An empty CUI as advertisement violates RFC2865 though, which 
> says that empty string attributes MUST NOT be sent [p. 24]. 

I agree so we send a NULL.  Good point though, many people don't get that.  

> Any valid value should do though, the empty value conveys no 
> special meaning here. If the attribute is present at all, the 
> NAS indicates its support for echoing CUI. A single NUL 
> character SHOULD perhaps be used by NASes, but the receiver 
> MUST not attach any meaning to it for the purpose of 
> establishing the NAS' support for CUI.

Yes.

> I still think it's a bit weird for an intermediate to enforce 
> a limit (on simultaneous use, no less) based on data supplied 
> by the home AAA, instead of the home AAA enforcing that limit 
> itself. With the use of CUI as in your example, iPass needs 
> to  trust the home AAA that it doesn't simply generate a 
> random CUI for every single authentication to thwart such a limit.

Absolutely.

> If iPass would be smart, they would only limit things it can 
> actually count without trusting the home AAA. It knows eg. 
> when it sends an access request to which home AAA, and so 
> with /some/ certainty, it knows how many sessions are open 
> for a wholesale customer (if it doesn't miss too many Stop 
> records). Let it count the total number of simulatenous 
> sessions for a wholesale customer then, instead of for a 
> particular CUI, and let the customer's AAA enforce the limits 
> for its individual end users, using any policy it wishes to use.

Yes but they also want to enforce how many simultaneouse logins Joe has. So
they need CUI when EAP is used etc.  You may think that that is not smart
;-)
 
> No need for trust, and no need for CUI; this actually seems a 
> better solution for your scenario.

In the case where they are counting ports per ISP you are right. But that is
not the scenario we are trying to solve.

> Are there any scenarios where 
> CUI-as-a-vehicle-between-home-and-intemediate offers perhaps 
> some more improvement? This is not rhetorical, but a honest question.

Not sure, and I hesitate to answer in fears of getting into a long delay.
CUI solves a problem that we know and understand today. It can be used for
other purposes I am sure.  That is why we are very insistant that we don't
tie its use specifically to EAP and 2486bis.

> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 22:31:26 +0000
Date: Mon, 20 Dec 2004 23:35:55 +0100
From: Emile van Bergen <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI
Mail-Followup-To: Jari Arkko <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]

Hi,

On Mon, Dec 20, 2004 at 10:30:35PM +0200, Jari Arkko wrote:

> Avi Lior wrote:
> 
> >An intermediate proxy when seeing Authentication/Authorization traffic 
> >can't
> >correlated it to a specific user when methods such as EAP are being used.
> >
> >The only thing a intermediary can do is use class to correlate an 
> >accounting
> >stream with a authentication stream. But it can't correlate that to a
> >specific user.
> >
> >So if iPass wants to limit how many times John logs in (and they do) then
> >they would not be able to do so when certain EAP methods are being used.
> 
> Agreed. This is for me the prime reason why CUI is needed.

Ok, I understand that. But then it seems to me that CUI could get the
exact same semantics of Class, with the exception that there may only be
one instance present.

And I think to avoid the confusion, it should be made more clear then
that CUI is only a communications device from a home AAA (at the
time of accept) to a proxy AAA (at the time of accept and when
accounting, via the NAS); for all 'normal' cases, Class should be used.

Let's try to work out your example a little. A proxy AAA like iPass' 
could refuse to forward the accept towards the NAS if it doesn't receive
a CUI from the home AAA, and send a reject instead. Ok.

Similarly, if it wants to get (some) certainty about whether it can
expect to receive CUI in the subsequent accounting from the NAS, it
could reject all requests from NASes that don't advertise their support for
echoing CUI by putting a dummy CUI in their access requests.

An empty CUI as advertisement violates RFC2865 though, which says that
empty string attributes MUST NOT be sent [p. 24]. Any valid value should
do though, the empty value conveys no special meaning here. If the
attribute is present at all, the NAS indicates its support for echoing
CUI. A single NUL character SHOULD perhaps be used by NASes, but the
receiver MUST not attach any meaning to it for the purpose of
establishing the NAS' support for CUI.

I still think it's a bit weird for an intermediate to enforce a limit
(on simultaneous use, no less) based on data supplied by the home AAA,
instead of the home AAA enforcing that limit itself. With the use of CUI
as in your example, iPass needs to  trust the home AAA that it doesn't
simply generate a random CUI for every single authentication to thwart
such a limit.

If iPass would be smart, they would only limit things it can actually
count without trusting the home AAA. It knows eg. when it sends an access
request to which home AAA, and so with /some/ certainty, it knows how
many sessions are open for a wholesale customer (if it doesn't miss too
many Stop records). Let it count the total number of simulatenous
sessions for a wholesale customer then, instead of for a particular CUI,
and let the customer's AAA enforce the limits for its individual end
users, using any policy it wishes to use.

No need for trust, and no need for CUI; this actually seems a better
solution for your scenario.

Are there any scenarios where
CUI-as-a-vehicle-between-home-and-intemediate offers perhaps some more
improvement? This is not rhetorical, but a honest question.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 20:31:17 +0000
Date: Mon, 20 Dec 2004 22:30:35 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: Emile van Bergen <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI

Avi Lior wrote:

> An intermediate proxy when seeing Authentication/Authorization traffic can't
> correlated it to a specific user when methods such as EAP are being used.
> 
> The only thing a intermediary can do is use class to correlate an accounting
> stream with a authentication stream. But it can't correlate that to a
> specific user.
> 
> So if iPass wants to limit how many times John logs in (and they do) then
> they would not be able to do so when certain EAP methods are being used.

Agreed. This is for me the prime reason why CUI is needed.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 20:06:18 +0000
From: Avi Lior <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>,  "[email-masked]'" <[email-masked]>
Cc: 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 15:04:56 -0500

CUI is not needed for TTLS.

Its need after. At least that is what we need if for.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Monday, December 20, 2004 11:31 AM
> To: [email-masked]'
> Cc: 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Hi Jari,
> 
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Saturday, December 18, 2004 3:21 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> > Hi Avi,
> > 
> > I agree with most of what you are saying. I guess I know understand 
> > the point "EAP cannot be the only use case for CUI). I can 
> think one 
> > example where CUI would not even work with EAP. The way I 
> understand 
> > it, EAP-TTLS uses a model where a TTLS server that can be different 
> > from the AAAH of the client establishes a TLS session with 
> the client. 
> > The purpose of TLS is to protect the user identity/ 
> authentication. So 
> > in the early stage of EAP you need to use a pseudo identity. If the 
> > AAAH is the only place that understands that pseudo 
> identity, then you 
> > are in trouble, because the TLS is established with the TTLS server 
> > and not with the AAAH. AAAH only comes in place when the client is 
> > authenticating. The TTLS server does not know the CUI. So 
> in that case 
> > you can't even use CUI as an alias.
> 
> This is an interesting issue. But presumably *some* server
> will eventually learn the true user identity. If this server
> is the TTLS server, it can use CUI to inform the NAS. If this 
> server is someone else, that server and the TTLS server need 
> to communicate first so that the TTLS server can send the CUI 
> to the NAS.
> 
> Madjid>>I thought user-aliases were needed during EAP to 
> locate the TTLS 
> Madjid>>server (or AAAH server for the user), no?
> Why would the TTLS server need to send the CUI to the NAS? 
> The TTLS server knows which NAS the EAP signaling is coming 
> from. The NAS knows which the user the request is coming from 
> through L2 addressing methods. Did I miss something?
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 20:06:15 +0000
From: Avi Lior <[email-masked]>
To: Emile van Bergen <[email-masked]>,  [email-masked]
Cc: [email-masked], [email-masked],  [email-masked], [email-masked], [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 15:04:57 -0500

See inline.

> Why would any intermediate proxy want to do this correlation 
> using information supplied by the home AAA?

An intermediate proxy when seeing Authentication/Authorization traffic can't
correlated it to a specific user when methods such as EAP are being used.

The only thing a intermediary can do is use class to correlate an accounting
stream with a authentication stream. But it can't correlate that to a
specific user.

So if iPass wants to limit how many times John logs in (and they do) then
they would not be able to do so when certain EAP methods are being used.

Or if iPass wants to correlate all the accounting records for John (and they
do) then they would not be able to do so when certain EAP methods are being
used.

Class will not be able to help here at all.

This is not about what is happening in the home network.  If it was then we
would agree with you. And we would not be proposing CUI.  But its not about
the home network.

> If it wants to group them itself, it can do so using its own 
> instances of Class (remember RFC 2865's requirement that 
> ordering among multiple instances of attributes of the same 
> type is to be preserved, that multiple instances of Class may 
> be present, and that if you added any Class attributes in 
> Accepts, that you should strip yours again before proxying 
> Accounting records to home home AAA *)?
> 
> Why would an intermediate care how a home AAA decides to 
> group sessions? The home AAA does the accept for each 
> individual session.  As long as the home AAA can match each 
> accept it sends to the subsequent accounting records /for 
> that session/ from the NAS, it can group them any way it 
> wants. CUI would be quite a convoluted way to inform 
> intermediate AAAs of such grouping.
> 
> And about billing: if an intermediate AAA doesn't trust a 
> home AAA's accepts, it shouldn't send requests there.
> 
> If an intermediate AAA wants to prove that the accounting 
> records it sent to the home AAA are legitimate, it can a the 
> one time Class generated by the home AAA, saying, this is 
> what I got from you, nobody could have generated it but you, 
> and I'm not sending you more minutes in Acct-Session-Time 
> than you've provided in your Session-Timeout, so please pay me now.

You cant make that assertion about class received by other entities down
stream.  To do that you would have to understand what is in the class
attribute. 

But nevertheless we are not looking for the "test" you propose.

> Really, at one point I was convinced that CUI had some use, 
> but each scenario I hear lately is covered by Class.
> 
> Cheers,
> 
> 
> Emile.
> 
> *) and if we have a (SHOULD/MUST) problem at the layer of 
> transferring multiple instanes of Class in an orderly 
> fashion, we shouldn't try to solve that on a different layer IMHO.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 20:06:11 +0000
From: Avi Lior <[email-masked]>
To: Emile van Bergen <[email-masked]>,  Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: Jari Arkko <[email-masked]>, 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>,  [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 15:04:56 -0500

Well, CUI is not needed by the home network.  It's needed by entities
outside the home network. Class can't be used by these.

We have given lots of examples, and we belive that it is understood that
intermediaries and visited network need CUI in certain business roaming
cases.

The authors of the draft understand Class and we are not trying to reinvent
this attribute.

Avi

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Monday, December 20, 2004 11:50 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Jari Arkko; 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Hi,
> 
> On Mon, Dec 20, 2004 at 10:34:30AM -0600, Nakhjiri 
> Madjid-MNAKHJI1 wrote:
> 
> > Can you explain it a bit more for the less sophisticated?
> 
> Well, a suggestion was made that a. CUI could be learned at 
> the Access-Accept, and b. that it would be a session 
> identifier to allow the /home/ AAA and the NAS to correlate 
> their accounting records.
> 
> To me, this exactly describes Class; the home AAA is the 
> first source of the accept after, and thus defines Class; and 
> it can use the Class received in accounting records to 
> correlate them with the unique access value it generated 
> earlier in Access-Accept.
> 
> The value can be either unique per login, or unique for a 
> certain ad-hoc identity that allows a number of minutes, or 
> volume during a certain timeslot.
> 
> At any rate, the entity that ultimately charges the user (the 
> home AAA, that vouches for the user's credentials) defines 
> it, and it's present in all accounting about this user.
> 
> So, the /only/ reason for CUI would be if some home AAA 
> wishes to accept a user, while expecting an intermediate 
> AAA's owner to bill the user, and it wants to convey the 
> entity to bill to the intermediate AAA.
> 
> That such a scheme with distinguishable CUIs can be easily 
> compromised 
> by a non-trusted NAS owner is conveniently ignored. 
> 
> I'm of the school of belief that you should only send an 
> accept for a user if you're willing to foot the bill for him. 
> And for all such circumstances, Class works fine, and cannot 
> be forged by the NAS owner or any intermediate proxy owner if 
> properly generated by the home AAA.
> 
> Kind regards,
> 
> 
> Emile.
> 
> > -----Original Message-----
> > From: Emile van Bergen [mailto:[email-masked]]
> > Sent: Saturday, December 18, 2004 12:19 PM
> > To: Jari Arkko
> > Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; 
> [email-masked]
> > Subject: Re: Scope of applicability for CUI
> > 
> > Hi,
> > 
> > On Sat, Dec 18, 2004 at 11:21:13AM +0200, Jari Arkko wrote:
> > 
> > > This also implies that the CUI is something that can be 
> learned very 
> > > late in the process, perhaps even as late as in the Access-Accept.
> > > 
> > > By the way, what would be the meaning of CUI for "pay as you go" 
> > > type of approaches, e.g., micropayments or the like over 
> EAP? There 
> > > might not be any billable user identity; the only thing 
> that could 
> > > be provided in those cases is some kind of a session 
> identifier so 
> > > that the home AAA and the NAS can correlate their accounting 
> > > records.
> > 
> > To paraphrase Henry Spencer: those that do not understand Class are 
> > condemned to reinvent it -- poorly.
> > 
> > Cheers,
> > 
> > 
> > Emile.
> > 
> > -- 
> > E-Advies - Emile van Bergen           [email-masked]      
> > tel. +31 (0)70 3906153           http://www.e-advies.nl    
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 17:56:17 +0000
Date: Mon, 20 Dec 2004 19:00:51 +0100
From: Emile van Bergen <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Scope of applicability for CUI
Mail-Followup-To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi,

On Sun, Dec 19, 2004 at 09:24:33AM +0200, [email-masked] wrote:

> > By the way, what would be the meaning of CUI for "pay as you go"
> > type of approaches, e.g., micropayments or the like over EAP?
> > There might not be any billable user identity; the only thing
> > that could be provided in those cases is some kind of a session
> > identifier so that the home AAA and the NAS can correlate their
> > accounting records.
> 
> Correct, it could provide a session identifier; or more correctly
> a temporary billable session identity.  I haven't thought of all of
> the implications.
> 
> Actually, taking a step back, if there is a billable user identity,
> which is still needed in the pay-as-you-go case, then the CUI can
> be used to track & correlate accounting records.  This would be useful
> in cases when the user connects and disconnects several times, but
> the 'session' is longer than just one of the connection times. 
> For example, if you in a hotel and fire-up WLAN in the morning, then
> in the afternoon, then in the evening.  The 'session' might be your
> entire stay.

Why would any intermediate proxy want to do this correlation using
information supplied by the home AAA?

If it wants to group them itself, it can do so using its own instances
of Class (remember RFC 2865's requirement that ordering among multiple
instances of attributes of the same type is to be preserved, that
multiple instances of Class may be present, and that if you added any
Class attributes in Accepts, that you should strip yours again before
proxying Accounting records to home home AAA *)?

Why would an intermediate care how a home AAA decides to group sessions?
The home AAA does the accept for each individual session.  As long as
the home AAA can match each accept it sends to the subsequent accounting
records /for that session/ from the NAS, it can group them any way it
wants. CUI would be quite a convoluted way to inform intermediate AAAs
of such grouping.

And about billing: if an intermediate AAA doesn't trust a home AAA's
accepts, it shouldn't send requests there.

If an intermediate AAA wants to prove that the accounting records it
sent to the home AAA are legitimate, it can a the one time Class
generated by the home AAA, saying, this is what I got from you, nobody
could have generated it but you, and I'm not sending you more minutes in
Acct-Session-Time than you've provided in your Session-Timeout, so
please pay me now.

Really, at one point I was convinced that CUI had some use, but each
scenario I hear lately is covered by Class.

Cheers,

Emile.

*) and if we have a (SHOULD/MUST) problem at the layer of transferring
multiple instanes of Class in an orderly fashion, we shouldn't try to
solve that on a different layer IMHO.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 16:45:45 +0000
Date: Mon, 20 Dec 2004 17:50:14 +0100
From: Emile van Bergen <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: Jari Arkko <[email-masked]>, 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI
Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, Jari Arkko <[email-masked]>, 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]

Hi,

On Mon, Dec 20, 2004 at 10:34:30AM -0600, Nakhjiri Madjid-MNAKHJI1 wrote:

> Can you explain it a bit more for the less sophisticated?

Well, a suggestion was made that a. CUI could be learned at the
Access-Accept, and b. that it would be a session identifier to allow the
/home/ AAA and the NAS to correlate their accounting records.

To me, this exactly describes Class; the home AAA is the first source of
the accept after, and thus defines Class; and it can use the Class
received in accounting records to correlate them with the unique access
value it generated earlier in Access-Accept.

The value can be either unique per login, or unique for a certain ad-hoc
identity that allows a number of minutes, or volume during a certain
timeslot.

At any rate, the entity that ultimately charges the user (the home AAA,
that vouches for the user's credentials) defines it, and it's present in
all accounting about this user.

So, the /only/ reason for CUI would be if some home AAA wishes to accept
a user, while expecting an intermediate AAA's owner to bill the user,
and it wants to convey the entity to bill to the intermediate AAA.

That such a scheme with distinguishable CUIs can be easily compromised 
by a non-trusted NAS owner is conveniently ignored. 

I'm of the school of belief that you should only send an accept for a
user if you're willing to foot the bill for him. And for all such
circumstances, Class works fine, and cannot be forged by the NAS owner
or any intermediate proxy owner if properly generated by the home AAA.

Kind regards,

Emile.

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]] 
> Sent: Saturday, December 18, 2004 12:19 PM
> To: Jari Arkko
> Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> Hi,
> 
> On Sat, Dec 18, 2004 at 11:21:13AM +0200, Jari Arkko wrote:
> 
> > This also implies that the CUI is something that can be learned
> > very late in the process, perhaps even as late as in the Access-Accept.
> > 
> > By the way, what would be the meaning of CUI for "pay as you go"
> > type of approaches, e.g., micropayments or the like over EAP?
> > There might not be any billable user identity; the only thing
> > that could be provided in those cases is some kind of a session
> > identifier so that the home AAA and the NAS can correlate their
> > accounting records.
> 
> To paraphrase Henry Spencer: those that do not understand Class are
> condemned to reinvent it -- poorly.
> 
> Cheers,
> 
> 
> Emile.
> 
> -- 
> E-Advies - Emile van Bergen           [email-masked]      
> tel. +31 (0)70 3906153           http://www.e-advies.nl    
-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 16:34:48 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Emile van Bergen'" <[email-masked]>, Jari Arkko <[email-masked]>
Cc: "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 10:34:30 -0600

Can you explain it a bit more for the less sophisticated?

Thanks,

Madjid

-----Original Message-----
From: Emile van Bergen [mailto:[email-masked]] 
Sent: Saturday, December 18, 2004 12:19 PM
To: Jari Arkko
Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; [email-masked]
Subject: Re: Scope of applicability for CUI

Hi,

On Sat, Dec 18, 2004 at 11:21:13AM +0200, Jari Arkko wrote:

> This also implies that the CUI is something that can be learned
> very late in the process, perhaps even as late as in the Access-Accept.
> 
> By the way, what would be the meaning of CUI for "pay as you go"
> type of approaches, e.g., micropayments or the like over EAP?
> There might not be any billable user identity; the only thing
> that could be provided in those cases is some kind of a session
> identifier so that the home AAA and the NAS can correlate their
> accounting records.

To paraphrase Henry Spencer: those that do not understand Class are
condemned to reinvent it -- poorly.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 16:31:11 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 10:30:44 -0600

Hi Jari,

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Saturday, December 18, 2004 3:21 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Avi Lior'; 'Nelson, David'; [email-masked]
Subject: Re: Scope of applicability for CUI

Nakhjiri Madjid-MNAKHJI1 wrote:
> Hi Avi,
> 
> I agree with most of what you are saying. I guess I know understand the point "EAP cannot be the only use case for CUI). I can think one example where CUI would not even work with EAP. The way I understand it, EAP-TTLS uses a model where a TTLS server that can be different from the AAAH of the client establishes a TLS session with the client. The purpose of TLS is to protect the user identity/ authentication. So in the early stage of EAP you need to use a pseudo identity. If the AAAH is the only place that understands that pseudo identity, then you are in trouble, because the TLS is established with the TTLS server and not with the AAAH. AAAH only comes in place when the client is authenticating. The TTLS server does not know the CUI. So in that case you can't even use CUI as an alias.

This is an interesting issue. But presumably *some* server
will eventually learn the true user identity. If this server
is the TTLS server, it can use CUI to inform the NAS. If this
server is someone else, that server and the TTLS server need
to communicate first so that the TTLS server can send the CUI
to the NAS.

Madjid>>I thought user-aliases were needed during EAP to locate the TTLS server (or AAAH server for the user), no?
Why would the TTLS server need to send the CUI to the NAS? 
The TTLS server knows which NAS the EAP signaling is coming from. The NAS knows which the user the request is coming from through L2 addressing methods. Did I miss something?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 15:56:44 +0000
Date: Mon, 20 Dec 2004 10:56:35 -0500
From: Barney Wolff <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: CUI multi-session

On Mon, Dec 20, 2004 at 11:19:22AM +0200, [email-masked] wrote:
> 
> One of the intended additional uses for CUI (at least in our roaming
> scenarios)
> at the home AAA is indeed to be able to help correlating related
> (shorter)
> accounting sessions into longer "user experienced session" -- e.g.
> something
> acct-multi-session-id could also be used for but extended to multiple
> disconnect & reconnect cases as well.

I will point out, again, that the home server does not need CUI to do
this, since Class has all the necessary properties and is supported now.
Further, I maintain that home servers SHOULD NOT use CUI for this as
unless the NAS/proxy has included a null CUI in the Access-Request there
is no reason to expect that CUI is supported.

The only justification for CUI as a new attribute is the case where the
NAS or proxy owner demands an identifier that can be tied to the home
user.

-- 
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 15:54:01 +0000
From: Avi Lior <[email-masked]>
To: [email-masked], Bernard Aboba <[email-masked]>
Cc: Avi Lior <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Mon, 20 Dec 2004 10:53:20 -0500

Hi Jari,

While I agree with your analysis, except that CUI is not needed by the home
network.  The home network can use other means - like class.  
CUI is intended to be used by entities not in the home network which can't
use the class attribute.

This is causing some folks to jump on us thinking that we don't understand
class and that we are trying to reinvent class.  Note only are the authors
classy, they also understand class very well.

See further inline....

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Saturday, December 18, 2004 4:46 AM
> To: Bernard Aboba
> Cc: Avi Lior; Adrangi, Farid; [email-masked]
> Subject: Re: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> Bernard Aboba wrote:
> 
> > With a VSA, if the NAS doesn't understand it, it can ignore it.  Is 
> > that true of CUI as well?  If this really is about the NAS, then I 
> > think the answer is yes.  The RADIUS Server can send CUI along with 
> > Class, and if the NAS doesn't support it, it can ignore it and the 
> > home server will get all the billing info it needs from the Class 
> > attribute.  This is backward compatible on the NAS (since 
> it doesn't 
> > need to be upgraded to support
> > CUI) as well as on the RADIUS server (who doesn't see a CUI 
> attribute it
> > didn't ask for).
> 
> I believe there are two "layers" that we need to distinguish 
> here. The most obvious layer is what happens at RADIUS. For 
> this layer the question "can we ignore the CUI" depends on 
> whether the CUI affects some of the subsequent RADIUS 
> messages. Is there a requirement for the CUI to be copied 
> back in Accounting-Requests? If yes, then the CUI needs to be 
> understood at least in that sense. But I forget what the base 
> RFCs say about copying unknown attributes to 
> Accounting-Requests. If there is no requirement for CUI to be 
> copied back, then we are assuming that the home network can 
> associate the access and accounting requests by other means.

Not every attribute received in an Access-Accept is copied to the Accounting
packets.

A NAS or a RADIUS proxy, that is complaint with the proposed RFC will place
CUI in the accounting packets.

A NAS or a RADIUS proxy that is not compliant with the proposed RFC will not
place the CUI in the accounting packets.

> But we also have a second layer, which is the billing and 
> policy processes. For the CUI to be useful, we are already 
> assuming that there is a need for the organizations to 
> correlate some billing information based on the CUI, or do 
> some policing based on the CUI (such as # of concurrent 
> sessions per CUI). Here we can see a few different cases:

Yes.

> o  Home network can't complete its billing/reconciliation
>     process without getting a CUI from the access network.
>     Here we MUST have support for the CUI in the access
>     network, or otherwise the two networks can't work together.
>     Fortunately this can be checked at the time the roaming
>     contract is signed.

No the home network does not need to get CUI.  Its not about the home
network. But it maybe helpful.

> o  Home network offers CUI for everyone, but does not
>     need it by itself. Support for CUI is optional,
>     and if the access network needs it they will upgrade
>     their equipment to support it.

Yes.
 
> o  Home network does not offer CUI to anyone. If the
>     access networks do not need it, no problem. If they
>     do, they can not work together with this home network.
>     Given that the usage of CUI is expected to be in
>     the billing and reconciliation process, we should
>     never get into the latter situation. However, the
>     access network may be unable to perform policy
>     operations that it wants to, if those operations
>     require knowledge of the CUI.

Yes.

So use of CUI whether it is there or not, and what it contains is all driven
by the business layer as you put it. 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 15:38:48 +0000
From: Avi Lior <[email-masked]>
To: [email-masked], Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Mon, 20 Dec 2004 10:38:28 -0500

Hi,

In EAP and in other cases the Authentication Server may be different then
the Authorization Server.  RADIUS allows for that.
 
But the final Access-Accept carries the authorization attributes, these are
provided by some AAA entity in the network that know the identity of the
user -- cause it provides authorization attributes for the user.  That's
when CUI will be typically set.  It may also be set by the Authentication
Server as well.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Saturday, December 18, 2004 4:21 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> > Hi Avi,
> > 
> > I agree with most of what you are saying. I guess I know understand 
> > the point "EAP cannot be the only use case for CUI). I can 
> think one 
> > example where CUI would not even work with EAP. The way I 
> understand 
> > it, EAP-TTLS uses a model where a TTLS server that can be different 
> > from the AAAH of the client establishes a TLS session with 
> the client. 
> > The purpose of TLS is to protect the user identity/ 
> authentication. So 
> > in the early stage of EAP you need to use a pseudo identity. If the 
> > AAAH is the only place that understands that pseudo 
> identity, then you 
> > are in trouble, because the TLS is established with the TTLS server 
> > and not with the AAAH. AAAH only comes in place when the client is 
> > authenticating. The TTLS server does not know the CUI. So 
> in that case 
> > you can't even use CUI as an alias.
> 
> This is an interesting issue. But presumably *some* server
> will eventually learn the true user identity. If this server
> is the TTLS server, it can use CUI to inform the NAS. If this 
> server is someone else, that server and the TTLS server need 
> to communicate first so that the TTLS server can send the CUI 
> to the NAS.
> 
> This also implies that the CUI is something that can be 
> learned very late in the process, perhaps even as late as in 
> the Access-Accept.
> 
> By the way, what would be the meaning of CUI for "pay as you 
> go" type of approaches, e.g., micropayments or the like over 
> EAP? There might not be any billable user identity; the only 
> thing that could be provided in those cases is some kind of a 
> session identifier so that the home AAA and the NAS can 
> correlate their accounting records.
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 14:39:09 +0000
content-class: urn:content-classes:message
Subject: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt
Date: Mon, 20 Dec 2004 16:38:31 +0200
From: "Romascanu, Dan \(Dan\)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E6A1.93A677E4
Content-Type: text/plain;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

At the request of the Operations and Management Area Director I reviewed =
draft-decnodder-radext-dynauth-client-mib-02.txt. Please find below my =
comments.=20

Regards,

Dan

1. The boilerplate does not conform with the latest recommendations =
referring to Intellectual Property notices. See =
http://www.ietf.org/ietf/1id-guidelines.txt for the mandatory notices.=20
2. The Introduction section contains un-expanded acronyms which are not =
public domain knowledge for the Internet community - CoA, NAS. =20
3. Section 5 in this document duplicates much of the similar section 5 =
in draft-decnodder-radext-dynauth-server-mib-02.txt. It may be better to =
avoid duplication by having the respective text be written only in one =
document and referred by the other.=20
4. Section 5, first paragraph - 'The RADIUS dynamic authorization =
extensions ... distinguishes...' - grammar problem
5.Is this MIB module implemented in conjunction with other MIB modules - =
for example those defined in RFC 2618 through 2621? If this is the case, =
this relationship should be discussed in one of the 'narrative' sections =
- probably in Section 5.=20
6. radiusMIB is already defined in other documents - see for example RFC =
2619 -  RADIUS-AUTH-SERVER-MIB - I suggest that it is imported from =
there.=20
7. What is the purpose of the radiusDynAuthClientIdentifier object? If =
this is about software versions, application names, etc. there are =
objects in other MIB modules already defining this - see for example RFC =
2737. If there is a something specific about a RADIUS dynamic =
authentication client identifier, some more information is needed.=20
8. DESCRIPTION clause of radiusDynAuthServerEntry. I suggest to say =
'representing one Dynamic...' instead of 'representing the Dynamic...'.
9. The DESCRIPTION clause of radiusDynAuthServerIndex should be clear in =
saying that this number is allocated by the agent implementing this MIB =
module, and unique in this context (and not for an admin domain)
10. Add REFERENCE clauses for objects defining NAS attributes from RFC =
2865, 2869, 3162 - from case to case
11. DESCRIPTION clause of radiusDynAuthClientRoundTripTime - this should =
be defined as the time between sending a Disconnect or CoA request and =
the reception of a corresponding Disconnect-reply/CoA-reply=20
12. what are the values of the objects in the radiusDynAuthServerEntry =
that depend on processing replies like radiusDynAuthClientRoundTripTime =
before a first reply is received from the server? For example what will =
be returned by an agent implementing this MIB module for =
radiusDynAuthClientRoundTripTime before a first reply is received and a =
meaningful round trip delay can be presented?=20
13. DESCRIPTION clause of  radiusDynAuthClientDisconPacketsDropped - I =
suggest to add '...by the client application' after 'silently =
discarded'.=20
14. same for radiusDynAuthClientCoAPacketsDropped
15. I suggest to add UNITS clauses to the counter objects - packets, =
retransmissions, etc.=20
16. Section 7, 4th paragraph - should be 'These' rather than 'this' =
because the phrase refers to the two objects above
17. Section 9.1 - I wonder if references to RFC 2618 through 2621 are =
really normative references. I do not see the strong dependence on these =
specifications that would justify it.
18. There is no IANA Consideration section. Even if no actions are =
required from IANA, such a section must be present and just mention =
this.=20

------_=_NextPart_001_01C4E6A1.93A677E4
Content-Type: text/html;
	charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dwindows-1255">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.6603.0">
<TITLE>Comments on =
draft-decnodder-radext-dynauth-client-mib-02.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P DIR=3DLTR><FONT SIZE=3D2 FACE=3D"Arial">At the request of the =
Operations and Management Area Director I reviewed =
draft-decnodder-radext-dynauth-client-mib-02.txt. Please find below my =
comments. </FONT></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Regards,</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 =
FACE=3D"Arial">Dan</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">1. The =
boilerplate does not conform with the latest recommendations referring =
to Intellectual Property notices. See <A =
HREF=3D"http://www.ietf.org/ietf/1id-guidelines.txt">http://www.ietf.org/=
ietf/1id-guidelines.txt</A></FONT></SPAN><SPAN LANG=3D"he"></SPAN><SPAN =
LANG=3D"he"><FONT SIZE=3D2 FACE=3D"Arial (Hebrew)"><SPAN DIR=3DRTL> =
</SPAN></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Arial">&lrm;for the mandatory notices. =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">2. The =
Introduction section contains un-expanded acronyms which are not public =
domain knowledge for the Internet community - CoA, NAS.&nbsp; =
</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">3. =
Section 5 in this document duplicates much of the similar section 5 =
in</FONT></SPAN><SPAN LANG=3D"he"> <FONT SIZE=3D2 =
FACE=3D"Arial">draft-decnodder-radext-dynauth-server-mib-02.txt. It may =
be better to avoid duplication by having the respective text be written =
only in one document and referred by the other. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">4. =
Section 5, first paragraph - 'The RADIUS dynamic authorization =
extensions ... distinguishes...' - grammar problem</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">5.Is =
this MIB module implemented in conjunction with other MIB modules - for =
example those defined in RFC 2618 through 2621? If this is the case, =
this relationship should be discussed in one of the 'narrative' sections =
- probably in Section 5. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">6. =
radiusMIB is already defined in other documents - see for example RFC =
2619 -&nbsp;</FONT> <FONT FACE=3D"Times New =
Roman">RADIUS-AUTH-SERVER-MIB - I suggest that it is imported from =
there.</FONT></SPAN><SPAN LANG=3D"he"></SPAN><SPAN LANG=3D"he"> =
</SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">7. What =
is the purpose of the</FONT> <FONT FACE=3D"Times New =
Roman">radiusDynAuthClientIdentifier object? If this is about software =
versions, application names, etc. there are objects in other MIB modules =
already defining this - see for example RFC 2737. If there is a =
something specific about a RADIUS dynamic authentication client =
identifier, some more information is needed. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">8. =
DESCRIPTION clause of radiusDynAuthServerEntry. I suggest to say =
'representing one Dynamic...' instead of 'representing the =
Dynamic...'.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">9. The =
DESCRIPTION clause of radiusDynAuthServerIndex should be clear in saying =
that this number is allocated by the agent implementing this MIB module, =
and unique in this context (and not for an admin =
domain)</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">10. Add =
REFERENCE clauses for objects defining NAS attributes from RFC 2865, =
2869, 3162</FONT></SPAN><SPAN LANG=3D"he"></SPAN><SPAN LANG=3D"he"> =
<FONT SIZE=3D2 FACE=3D"Arial (Hebrew)"><SPAN DIR=3DRTL>- =
</SPAN></FONT></SPAN><SPAN LANG=3D"en-us"></SPAN><SPAN LANG=3D"en-us"> =
<FONT SIZE=3D2 FACE=3D"Arial">&lrm;from case to case</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">11. =
DESCRIPTION clause of</FONT> <FONT FACE=3D"Times New =
Roman">radiusDynAuthClientRoundTripTime - this should be defined as the =
time between sending a Disconnect or CoA request</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">and the reception of a corresponding</FONT> <FONT =
FACE=3D"Times New Roman">Disconnect-reply/CoA-reply </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">12. =
what are the values of the objects in the radiusDynAuthServerEntry that =
depend on processing replies</FONT> <FONT SIZE=3D2 =
FACE=3D"Arial">like</FONT> <FONT FACE=3D"Times New =
Roman">radiusDynAuthClientRoundTripTime before a first reply is received =
from the server?</FONT> <FONT SIZE=3D2 FACE=3D"Arial">For example what =
will be returned by an agent implementing this MIB module for</FONT> =
<FONT FACE=3D"Times New Roman">radiusDynAuthClientRoundTripTime before a =
first reply is received and a meaningful round trip</FONT> <FONT =
SIZE=3D2 FACE=3D"Arial">delay can be presented? </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Arial">13. =
DESCRIPTION clause of</FONT>&nbsp;<FONT FACE=3D"Times New Roman"> =
radiusDynAuthClientDisconPacketsDropped - I suggest to add '...by the =
client application' after 'silently discarded'. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">14. =
same for radiusDynAuthClientCoAPacketsDropped</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">15. I =
suggest to add UNITS clauses to the counter objects - packets, =
retransmissions, etc. </FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">16. =
Section 7, 4th paragraph - should be 'These' rather than 'this' because =
the phrase refers to the two objects above</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">17. =
Section 9.1 - I wonder if references to RFC 2618 through 2621 are really =
normative references. I do not see the strong dependence on these =
specifications that would justify it.</FONT></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"en-us"><FONT FACE=3D"Times New Roman">18. =
There is no IANA Consideration section. Even if no actions are required =
from IANA, such a section must be present and just mention =
this.<B></B></FONT><B> </B></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

<P DIR=3DLTR><SPAN LANG=3D"he"></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E6A1.93A677E4--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 09:20:05 +0000
content-class: urn:content-classes:message
Subject: 
Date: Mon, 20 Dec 2004 11:19:22 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

John, Jari,
=20
> > By the way, what would be the meaning of CUI for "pay as you go"
> > type of approaches, e.g., micropayments or the like over EAP?
> > There might not be any billable user identity; the only thing
> > that could be provided in those cases is some kind of a session
> > identifier so that the home AAA and the NAS can correlate their
> > accounting records.
>=20
> Correct, it could provide a session identifier; or more correctly
> a temporary billable session identity.  I haven't thought of all of
> the implications.
>=20
> Actually, taking a step back, if there is a billable user identity,
> which is still needed in the pay-as-you-go case, then the CUI can
> be used to track & correlate accounting records.  This would be useful
> in cases when the user connects and disconnects several times, but
> the 'session' is longer than just one of the connection times.=20
> For example, if you in a hotel and fire-up WLAN in the morning, then
> in the afternoon, then in the evening.  The 'session' might be your
> entire stay.

One of the intended additional uses for CUI (at least in our roaming
scenarios)
at the home AAA is indeed to be able to help correlating related
(shorter)
accounting sessions into longer "user experienced session" -- e.g.
something
acct-multi-session-id could also be used for but extended to multiple
disconnect & reconnect cases as well.

/Jouni

>=20
> John
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 20 Dec 2004 08:26:16 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: Radius-Geopriv: User Identity Confidentiality
Date: Mon, 20 Dec 2004 09:25:06 +0100

hi jari, 

thanks for your feedback. please see my comments below: 

> Tschofenig Hannes wrote:
> 
> > [hannes] the first issue: it is true that user identity 
> > confidentiality also depends on the configuration of 
> certain protocols 
> > (particularly if protocols provide flexible mechanisms). in 
> any case, 
> > authentication and key exchange
> 
> Yes.
> 
> > protocols which offer public key based authentication are able to 
> > provide better user identity confidentiality than protocols 
> which only 
> > use symmetric keys. the latter protocols are only able to 
> use temporal identities.
> 
> Yes, but does that affect the level of privacy offered to the user?
i think so. with symmetric key cryptography there are built-in limitations.
no matter how could your configuration is you will never be able to fully
protect yourself against active adversaries. 

> Both approaches can certainly be made to fail, e.g., through 
> bad configuration or through protocols that don't take into 
> account all cases.

> 
> > [hannes] regarding the second issue: 'we should talk about location 
> > privacy rather than user identity confidentiality'
> > 
> > here is my reasoning: 
> > * we would like to avoid that the visited network obtains 
> the user's 
> > identity and its location information. the visited network will 
> > obviously always obtain the user's location information. hence, we 
> > should avoid that it receives the user's identity. within the 
> > radius-geopriv document we can
> 
> This is very reasonable.
> 
> > only address aspects which are within the scope of radius (or 
> > diameter) and certainly not within the scope of other protocols.
> 
> This is a good approach, but its kind of hard to draw the 
> line. EAP is strictly speaking another protocol, although its 
> carried in AAA; and many L2 protocol issues from a NAS will 
> be reflected in the AAA protocols in the same manner.

you are also right. 

> 
> > * i know that user identity confidentiality is a difficult 
> issue since 
> > you need to deal with a number of identities at different 
> layers and 
> > with different protocols. i think it is worth stating that 
> providing user id.
> > conf. within eap does not solve all issues. if you use ikev2 
> > afterwards and again reveal your true identity then you 
> have again lost.
> 
> Yes.
> 
> > i some sense this is not a problem for radius-geopriv, as 
> such, since 
> > you need to deal with this problem also if there is no 
> radius-geopriv extension.
> 
> Yes.
> 
> > with regard to location privacy (what information is distributed to 
> > other networks or entities by the home network) i tried to 
> say a few 
> > words in section 14.
> 
> I think that part was fine.
> 
> > jari, what should i do? 
> 
> Lets see if we can work on text:
> 
>     For the envisioned usage scenarios the network access 
> authentication
>     ...
>     their security requirements).  Instead the choice is often
>     predetermined by a given architecture.
> 
> =>
> 
>     For the envisioned usage scenarios, the identify of the 
> user or his
>     devices is tightly coupled to the transfer of location 
> information.
>     If the identity can be determined by the visited network or AAA
>     brokers, then it is possible to correlate location 
> information with
>     a particular user. As such, it allows the visited network and
>     brokers to learn movement patterns of users.
> 
>     The identity of the user can "leak" to the visited network or AAA
>     brokers in a number of ways:
> 
>     o  The user's device may employ a fixed MAC address, or 
> base its IP
>        address on such an address. This enables the correlation of the
>        particular device to its different locations. Techniques exist
>        to avoid the use of an IP address that is based on MAC address
>        [RFC 3041]. Some link layers make it possible to avoid MAC
>        addresses or change them dynamically.
> 
>     o  Network access authentication procedures such as PPP CHAP [RFC
>        1994] or EAP [RFC 3748] may reveal the user's identity 
> as a part
>        of the authentication procedure. Techniques exist to avoid
>        this problem in EAP, for instance by employing private Network
>        Access Identifiers (NAIs) in the EAP Identity Response message
>        [draft-ietf-radext-rfc2486bis-03.txt] and by method-specific
>        private identity exchange in the EAP method [16, 18, 19].
>        Support for identity privacy within CHAP is not available.
> 
>     o  AAA protocols may return information from the home network to
>        the visited in a manner that makes it possible to 
> either identify
>        the user or at least correlate his session with other sessions,
>        such as the use of static data in a Class attribute [RFC 2865]
>        or in some accounting attribute usage scenarios
>        [draft-ietf-radext-chargeable-user-id-00.txt].
> 
>     o  Mobility mechanisms may reveal some permanent identifier
>        (such as a home address) in cleartext in the packets relating
>        to mobility signaling.
> 
>     o  Application protocols may reveal other permanent identifiers.
> 
>     Note that to prevent the correlation of identities with location
>     information it is necessary to prevent leakage of identity
>     information from all sources, not just one.
> 
>     Unfortunately, most users are not educated about the importance of
>     identity confidentiality and there is a lack of support for it in
>     many protocols. This problem is made worse by the fact that the
>     users may be unable to choose particular protocols, as the choice
>     is often dictated by the type of network they wish to access, the
>     kind of equipment they have, or the type of authentication method
>     they are using.
> 
>     A scenario where the user is attached to the home network 
> is, from a
>     privacy point of view, simpler than a scenario where a user roams
>     into a visited network since the NAS and the home AAA are 
> in the same
>     administrative domain.  No direct relationship between the visited
>     and the home network operator may be available and some 
> AAA brokers
>     need to be consulted.  With subscription-based network 
> access as used
>     today the user has a contractual relationship with the 
> home network
>     provider which could allow higher privacy considerations to be
>     applied (including policy rules stored at the home 
> network itself for
>     the purpose of restricting further distribution).
> 
>     In many cases it is necessary to secure the transport of location
>     information along the RADIUS infrastructure.  Mechanism to achieve
>     this functionality are discussed in Section 15.
> 
> Does this work for you? Feel free to edit...

your text proposal looks great. thanks!

ciao
hannes

> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Dec 2004 18:13:52 +0000
Date: Sun, 19 Dec 2004 10:13:18 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [Issue] Comments to draft-ietf-radext-digest-auth-00.txt (fwd)

-------- Original Message --------
Subject: Comments to draft-ietf-radext-digest-auth-00.txt
Date: Wed, 15 Dec 2004 15:45:04 +0200
From: Miguel Garcia <[email-masked]>
To: Beck01, Wolfgang <[email-masked]>
CC: [email-masked]

Wolfgang:

I took a look at draft-ietf-radext-digest-auth-00.txt, based on the
comments that I posted to an earlier version of the draft. I still have
a few comments:

1) Section 4.1 has a table that maps RADIUS attributtes to Diameter SIP
app. AVPs. I think this table is no longer needed, since Diameter SIP
app imports (or will import in forthcoming version -05) the Digest-*
attributes from your draft.

Specifically, Diameter SIP app imports Digest-Method and Digest-URI from
your draft, so there is no mapping at all. Therefore, Table 1 in your
draft has to be removed.

2) We discussed an atypical case when a SIP request contains more than
one set of credentials, perhaps because the request traversed several
proxies and each one authenticated the user. We agree to add some
discussion, and the only text I found (correct me if I am wrong), is a
bit weak in my opinion:

    On reception of an HTTP-style request message, the RADIUS client
    looks for a (Proxy-)Authorization header where the realm directive
    matches its locally configured realm value.

I would suggest to add a bit more of descriptive text, it is never a bad
idea. I send you the text I added to the Diameter SIP app draft, you can
copy/adapt/modify if you want:

"There are situation where a SIP request traverses several proxies, and
each of the proxies request to authenticate the SIP UA. In this
situation, it is a valid scenario that a SIP request received at a SIP
server contains several sets of credentials. The 'realm' directive in
HTTP is the key that the Diameter client can use to determine which
credential is applicable. It may happen also that none of the realms are
of interests to the Diameter client, in which case the Diameter client
MUST consider that no credentials (of interest) were sent. In any case,
a Diameter client MUST send zero or exactly one credential to the
Diameter server. The Diameter client MUST choose the credential based on
the 'realm' directive in the Authorization/Proxy-Authorization header
field, and it MUST match the realm of the Diameter client."

3) We spoke that Digest-Response and Digest-Response-Auth attributes had
an artificial limit of 32 octets, and I proposed to avoid having any
limit. The current version of the draft indicates that these attributes
have a lenght >= 34 (32 octets + the length + the attribute type). This
allows future expansion if the size goes further than 32, but not if the
size decreases. While it is unlikely that new algorithms will decrease
this size, since I don't have a ball to guess the future, I still
propose to have this size unlimited, i.e., Length => 3.

4) I had another comment regarding the 'qop' parameter in HTTP Digest.
The problem is that this pararameter can contain several values, for
example, qop=auth,auth-int. The draft should indicate how to encode in
Radius this several parameters. I haven't found this described yet.

We had a discussion on the mailing list and I expressed my preference
for option b, that I repeat below:

   b) Each token is an attribute, thus, there might be multiple
      Digest-Qop attributes in a particular Radius/Diameter message.

I hope you can take these comments into account.

Regards,

           Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 19 Dec 2004 07:28:04 +0000
content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Sun, 19 Dec 2004 09:24:33 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Jari,

> This is an interesting issue. But presumably *some* server
> will eventually learn the true user identity. If this server
> is the TTLS server, it can use CUI to inform the NAS. If this
> server is someone else, that server and the TTLS server need
> to communicate first so that the TTLS server can send the CUI
> to the NAS.
>=20
> This also implies that the CUI is something that can be learned
> very late in the process, perhaps even as late as in the=20
> Access-Accept.

I agree with this analysis.
=20
> By the way, what would be the meaning of CUI for "pay as you go"
> type of approaches, e.g., micropayments or the like over EAP?
> There might not be any billable user identity; the only thing
> that could be provided in those cases is some kind of a session
> identifier so that the home AAA and the NAS can correlate their
> accounting records.

Correct, it could provide a session identifier; or more correctly
a temporary billable session identity.  I haven't thought of all of
the implications.

Actually, taking a step back, if there is a billable user identity,
which is still needed in the pay-as-you-go case, then the CUI can
be used to track & correlate accounting records.  This would be useful
in cases when the user connects and disconnects several times, but
the 'session' is longer than just one of the connection times.=20
For example, if you in a hotel and fire-up WLAN in the morning, then
in the afternoon, then in the evening.  The 'session' might be your
entire stay.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 18 Dec 2004 09:46:55 +0000
Date: Sat, 18 Dec 2004 11:46:20 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: Avi Lior <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: Re: backwards compatible introduction of NEW attribute such as CU I

Bernard Aboba wrote:

> With a VSA, if the NAS doesn't understand it, it can ignore it.  Is that
> true of CUI as well?  If this really is about the NAS, then I think the
> answer is yes.  The RADIUS Server can send CUI along with Class, and if
> the NAS doesn't support it, it can ignore it and the home server will get
> all the billing info it needs from the Class attribute.  This is backward
> compatible on the NAS (since it doesn't need to be upgraded to support
> CUI) as well as on the RADIUS server (who doesn't see a CUI attribute it
> didn't ask for).

I believe there are two "layers" that we need to distinguish here.
The most obvious layer is what happens at RADIUS. For this layer
the question "can we ignore the CUI" depends on whether the
CUI affects some of the subsequent RADIUS messages. Is there
a requirement for the CUI to be copied back in Accounting-Requests?
If yes, then the CUI needs to be understood at least in that
sense. But I forget what the base RFCs say about copying unknown
attributes to Accounting-Requests. If there is no requirement
for CUI to be copied back, then we are assuming that the home
network can associate the access and accounting requests by
other means.

But we also have a second layer, which is the billing and policy
processes. For the CUI to be useful, we are already assuming that
there is a need for the organizations to correlate some billing
information based on the CUI, or do some policing based on the
CUI (such as # of concurrent sessions per CUI). Here we can
see a few different cases:

o  Home network can't complete its billing/reconciliation
    process without getting a CUI from the access network.
    Here we MUST have support for the CUI in the access
    network, or otherwise the two networks can't work together.
    Fortunately this can be checked at the time the roaming
    contract is signed.

o  Home network offers CUI for everyone, but does not
    need it by itself. Support for CUI is optional,
    and if the access network needs it they will upgrade
    their equipment to support it.

o  Home network does not offer CUI to anyone. If the
    access networks do not need it, no problem. If they
    do, they can not work together with this home network.
    Given that the usage of CUI is expected to be in
    the billing and reconciliation process, we should
    never get into the latter situation. However, the
    access network may be unable to perform policy
    operations that it wants to, if those operations
    require knowledge of the CUI.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 18 Dec 2004 09:21:59 +0000
Date: Sat, 18 Dec 2004 11:21:13 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: 'Avi Lior' <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI

Nakhjiri Madjid-MNAKHJI1 wrote:
> Hi Avi,
> 
> I agree with most of what you are saying. I guess I know understand the point "EAP cannot be the only use case for CUI). I can think one example where CUI would not even work with EAP. The way I understand it, EAP-TTLS uses a model where a TTLS server that can be different from the AAAH of the client establishes a TLS session with the client. The purpose of TLS is to protect the user identity/ authentication. So in the early stage of EAP you need to use a pseudo identity. If the AAAH is the only place that understands that pseudo identity, then you are in trouble, because the TLS is established with the TTLS server and not with the AAAH. AAAH only comes in place when the client is authenticating. The TTLS server does not know the CUI. So in that case you can't even use CUI as an alias.

This is an interesting issue. But presumably *some* server
will eventually learn the true user identity. If this server
is the TTLS server, it can use CUI to inform the NAS. If this
server is someone else, that server and the TTLS server need
to communicate first so that the TTLS server can send the CUI
to the NAS.

This also implies that the CUI is something that can be learned
very late in the process, perhaps even as late as in the Access-Accept.

By the way, what would be the meaning of CUI for "pay as you go"
type of approaches, e.g., micropayments or the like over EAP?
There might not be any billable user identity; the only thing
that could be provided in those cases is some kind of a session
identifier so that the home AAA and the NAS can correlate their
accounting records.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 18 Dec 2004 06:37:36 +0000
content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Sat, 18 Dec 2004 08:33:26 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

> I agree. The intent of this draft was not to make the CUI=20
> broadly required.

I agree, it is just one tool for some deployment scenarios.
I don't think its useful for all deployments.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 23:12:36 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Mandating 3579 and 2486bis for CUI  was RE: Scope of applicab ility for CUI
Date: Fri, 17 Dec 2004 18:12:14 -0500

We could document other examples of usage. But I didn't think that that is
necessary. After all we are talking about one attribute. It is for the most
part tightly specified and we allow a free form specification for it (the
opaque option).

So if you insist we can put other usecases in...but that last thing I want
is to create more confusion, more debate.

But it is important for us not to tie this thing down to 3579 and 2846.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 5:27 PM
> To: [email-masked]
> Subject: RE: Mandating 3579 and 2486bis for CUI was RE: Scope 
> of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > Family members may have one username for example:
> [email-masked],
> > [email-masked] etc,, while the billing identity is 
> > [email-masked].  The billing identity may be required
> outside
> > the home network.
> 
> Snipping the other example use cases for the sake of brevity.
> 
> Great.  Specific use cases are far more helpful than 
> generalized posturing.
> 
> I can see that your examples may be of utility in certain 
> deployments. Given that some of these examples entail 
> semantics (i.e. required
> actions) at the NAS beyond the requirement to include the CUI 
> in future *-Request messages, it would be helpful if these 
> requirements were documented, somewhere.  The CUI draft may 
> be an obvious place, but it could be some other document.  In 
> the interests of global interoperability, it would be helpful 
> if anyone reading the RFC(s) on CUI could understand all the 
> standardized uses, and implement NAS firmware that 
> interoperates in a multi-vendor deployment.
> 
> All that I'm asking for, I guess, is full documentation of 
> the intended uses of the new attribute.  Undocumented uses 
> lead to poor interoperability.  Of course, undocumented uses 
> may also lead to product-specific competitive 
> differentiators.  We need to carefully weigh the interests of 
> multi-vendor interoperability in writing Standards Track RFCs.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 22:27:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Mandating 3579 and 2486bis for CUI  was RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 17:26:40 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> Family members may have one username for example:
[email-masked],
> [email-masked] etc,, while the billing identity is
> [email-masked].  The billing identity may be required
outside
> the home network.

Snipping the other example use cases for the sake of brevity.

Great.  Specific use cases are far more helpful than generalized
posturing.

I can see that your examples may be of utility in certain deployments.
Given that some of these examples entail semantics (i.e. required
actions) at the NAS beyond the requirement to include the CUI in future
*-Request messages, it would be helpful if these requirements were
documented, somewhere.  The CUI draft may be an obvious place, but it
could be some other document.  In the interests of global
interoperability, it would be helpful if anyone reading the RFC(s) on
CUI could understand all the standardized uses, and implement NAS
firmware that interoperates in a multi-vendor deployment.

All that I'm asking for, I guess, is full documentation of the intended
uses of the new attribute.  Undocumented uses lead to poor
interoperability.  Of course, undocumented uses may also lead to
product-specific competitive differentiators.  We need to carefully
weigh the interests of multi-vendor interoperability in writing
Standards Track RFCs.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 22:08:07 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Mandating 3579 and 2486bis for CUI  was RE: Scope of applicab ility for CUI
Date: Fri, 17 Dec 2004 17:07:46 -0500

David,

See my last line first then....

We can dream one up if you want. But I don't think that that is necessary.
That is my point.

Just because I am not proposing another usecase that doesn't mean the it
should be made to work only with 3579 and 2486.  That is my point and I
think that if you want to explicitly tie this to 3579 and 2486 you have to
justify that.  And the justification must show that it wont work otherwise.

But if I cave in I can give you an example where the username and CUI maybe
different.  And infact we have this implemented many many time in different
forms.

Family members may have one username for example: [email-masked],
[email-masked] etc,, while the billing identity is
[email-masked].  The billing identity may be required outside the
homenetwork.  

In wholesale scenario we have situations where you are serving enterprises
where we need to allocate ports based on enterprizes so we can have
[email-masked] and [email-masked] both with CUI west.example.com and
[email-masked] and [email-masked] both with CUI east.example.com.

The CUI can be used to bill to different cost centers or to limits ports
based on west.example.com and east.example.com

So it goes on.  Anyway there is no reason to limit the CUI use.

So yes I think we should simply "agree to disagree on this point".

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 4:35 PM
> To: [email-masked]
> Subject: RE: Mandating 3579 and 2486bis for CUI was RE: Scope 
> of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > Please demonstrate why this MUST ONLY work if the NAS only deployed
> EAP
> > AND 2486.
> 
> Unless we are using EAP/Anonymous authentication, please 
> explain why Chargeable-User-ID ought not to be *identical* to 
> User-Name?  I understand that an implementation *could* make 
> them arbitrarily different, but assuming that real 
> authentication using visible identity is taking place, why 
> would there be an over-riding *need* for these attributes to differ?  
> 
> Once someone explains the new use case where this makes any 
> sense, then we might want to add that use case to the scope 
> of applicability for CUI.  The argument that some operator 
> someday might come up with a good reason does not convince 
> me.  The fact that one *can* do something is never, IMHO, a 
> good reason that one *should* do it.  :-)
> 
> I'm beginning to suspect that we may need to simply "agree to 
> disagree" on this point.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 21:36:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Mandating 3579 and 2486bis for CUI  was RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 16:34:35 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> Please demonstrate why this MUST ONLY work if the NAS only deployed
EAP
> AND 2486.

Unless we are using EAP/Anonymous authentication, please explain why
Chargeable-User-ID ought not to be *identical* to User-Name?  I
understand that an implementation *could* make them arbitrarily
different, but assuming that real authentication using visible identity
is taking place, why would there be an over-riding *need* for these
attributes to differ? =20

Once someone explains the new use case where this makes any sense, then
we might want to add that use case to the scope of applicability for
CUI.  The argument that some operator someday might come up with a good
reason does not convince me.  The fact that one *can* do something is
never, IMHO, a good reason that one *should* do it.  :-)

I'm beginning to suspect that we may need to simply "agree to disagree"
on this point.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 21:10:52 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: Mandating 3579 and 2486bis for CUI  was RE: Scope of applicabilit y for CUI
Date: Fri, 17 Dec 2004 16:09:23 -0500

David,

David wrote:

> I object to the "for whatever reason" line of reasoning.

I object to making something mandatory for the sake of making something
mandatory.

The EAP usecase demonstartes the particallity and the need for CUI. But that
does not mean that that is the only need or use.

If there are no specific requirements to mandate a use of CUI to EAP and
2486bis then we should NOT mandate it. It is bad practice from a protocol
development point of view to create false dependencies.

Please demonstrate why this MUST ONLY work if the NAS only deployed EAP AND
2486.

Otherwise the text in the document is fine as is.  The draft only brings up
the EAP case and that is as far as it should go.

Avi.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 3:08 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi Lior writes...
> 
> > As a driving usecase for this work we noted that when certain EAP 
> > methods are used the identity of the user is hidden and mediating 
> > networks have no way to associate an 
> Authentication\Authorization and 
> > or Accounting events to a specific user or chargeable entity. CUI 
> > provides a mechanims whereby the home network can provide a 
> handle to 
> > the chargeable entity (without revealing the true identity), to the 
> > roaming partners and or mediating networks.
> 
> Yes, this is the justification for standardizing the CUI 
> attribute as a RADEXT WG work item. (And the *only* 
> justification, IMHO.)
> 
> > This does not mean that it is required when EAP is used.  
> Nor does it
> mean
> > that it can't be used in cases where EAP is not used.
> > 
> > It simply means that it is available to be used when it is 
> required by 
> > roaming partners - for whatever reason.
> 
> I object to the "for whatever reason" line of reasoning.  We 
> have justified the existence, usage and support requirement 
> for Chargeable-User-ID by a very specific use case.  Since it 
> is an "alias" for User-Name, and User-Name SHOULD always be 
> used in preference to Chargeable-User-ID, unless these 
> specific circumstances apply, why would it lead to greater 
> interoperability in RADIUS for this attribute to be generally 
> available for various undocumented uses?
> 
> I am generally opposed to "opaque carrier attributes" that 
> have the imprimatur of standardization, by being described in 
> a Standards Track RFC for a specific, well documented 
> purpose, but are then used for other, potentially 
> proprietary, purposes besides the explicitly documented one.  
> I am vaguely concerned that the Chargeable-User-ID might 
> become one of these, if its scope of use is not clearly and 
> concisely defined.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 20:29:18 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 14:27:47 -0600

Hi Avi,

I agree with most of what you are saying. I guess I know understand the point "EAP cannot be the only use case for CUI). I can think one example where CUI would not even work with EAP. The way I understand it, EAP-TTLS uses a model where a TTLS server that can be different from the AAAH of the client establishes a TLS session with the client. The purpose of TLS is to protect the user identity/ authentication. So in the early stage of EAP you need to use a pseudo identity. If the AAAH is the only place that understands that pseudo identity, then you are in trouble, because the TLS is established with the TTLS server and not with the AAAH. AAAH only comes in place when the client is authenticating. The TTLS server does not know the CUI. So in that case you can't even use CUI as an alias.

Madjid

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Friday, December 17, 2004 1:43 PM
To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; 'Nelson, David'; [email-masked]
Subject: RE: Scope of applicability for CUI

Hi Madjid,

Absolutely not. CUI and EAP usage should not be entertwined. EAP works fine
without CUI and CUI works fine with out EAP.

CUI allows mediating networks and visited networks to implement certain
business logic. For example:

As a driving usecase for this work we noted that when certain EAP methods
are used the identity of the user is hidden and mediating networks have no
way to associate an Authentication\Authorization and or Accounting events to
a specific user or chargeable entity.  CUI provides a mechanims whereby the
home network can provide a handle to the chargeable entity (without
revealing the true identity), to the roaming partners and or mediating
networks.

This does not mean that it is required when EAP is used.  Nor does it mean
that it can't be used in cases where EAP is not used.

It simply means that it is available to be used when it is required by
roaming partners - for whatever reason.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 12:23 PM
> To: 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi,
> 
> I don't understand CUI well, but I care about EAP. Doesn't 
> this mean the EAP server and the EAP authentication methods 
> must now support use of CUI as identity and be able to do the 
> conversions? 
> 
> Madjid
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Avi Lior
> Sent: Thursday, December 16, 2004 5:14 PM
> To: 'Nelson, David'; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> David,
> 
> Sorry for the short reply. I was rushed away. Let me expand.
> 
> We already mention in the document that CUI is useable when 
> EAP is used and in particular when EAP methods hide the user identity.
> 
> What I am opposed to is mandating that the only case for CUI 
> is tied to the use of EAP. Operationaly it does not depend on 
> EAP. There could be other uses in the future.  So the current 
> text in the draft is sufficient.
> 
> Avi
> 
> > -----Original Message-----
> > From: Nelson, David [mailto:[email-masked]]
> > Sent: Thursday, December 16, 2004 1:29 PM
> > To: [email-masked]
> > Subject: RE: Scope of applicability for CUI
> > 
> > 
> > 
> > Avi Lior writes...
> > 
> > > There maybe others that I am not aware of.
> > 
> > It's hard to design practical and interoperable protocols to
> > meet the requirements of unknown use cases -- so perhaps we 
> > can focus on the known ones.
> > 
> > > But these specific once are the once that we have seen
> > requests for. I
> > > believe these are mentioned in the draft as request by folks here.
> > 
> > OK.  Since User-Name re-write is considered "evil" in roaming
> > applications, because it changes the routing for RADIUS 
> > request traffic, can we assume that only addressing use case 
> > (B) is sufficient to meet the current needs?
> > 
> > If so, how is linking the use of CUI to the use of EAP
> > authentication inappropriate?
> > 
> > > > A) when the User-Name re-write feature (for accounting
> > > > purposes) obscures the original authentication identity, or
> > > >
> > > > B) when the RADIUS authentication method is EAP, allowing for a
> > > > "method internal" user identity for authentication, and an 
> > > > "anonymous" or "routing-only" value in User-Name.
> > > >
> > > > These use cases are further restricted to multi-party
> > (e.g. roaming
> > > > consortia) environments, because for deployments where
> > the NAS and
> > > > the Home RADIUS server belong to a single administrative
> > entity the
> > > > Class attribute has been seen to be sufficient.
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 20:10:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 15:07:36 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> As a driving usecase for this work we noted that when certain EAP
> methods are used the identity of the user is hidden and mediating=20
> networks have no way to associate an Authentication\Authorization=20
> and or Accounting events to a specific user or chargeable entity.=20
> CUI provides a mechanims whereby the home network can provide a=20
> handle to the chargeable entity (without revealing the true identity),
> to the roaming partners and or mediating networks.

Yes, this is the justification for standardizing the CUI attribute as a
RADEXT WG work item. (And the *only* justification, IMHO.)

> This does not mean that it is required when EAP is used.  Nor does it
mean
> that it can't be used in cases where EAP is not used.
>=20
> It simply means that it is available to be used when it is required by
> roaming partners - for whatever reason.

I object to the "for whatever reason" line of reasoning.  We have
justified the existence, usage and support requirement for
Chargeable-User-ID by a very specific use case.  Since it is an "alias"
for User-Name, and User-Name SHOULD always be used in preference to
Chargeable-User-ID, unless these specific circumstances apply, why would
it lead to greater interoperability in RADIUS for this attribute to be
generally available for various undocumented uses?

I am generally opposed to "opaque carrier attributes" that have the
imprimatur of standardization, by being described in a Standards Track
RFC for a specific, well documented purpose, but are then used for
other, potentially proprietary, purposes besides the explicitly
documented one.  I am vaguely concerned that the Chargeable-User-ID
might become one of these, if its scope of use is not clearly and
concisely defined.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 19:43:10 +0000
From: Avi Lior <[email-masked]>
To: 'Nakhjiri Madjid-MNAKHJI1' <[email-masked]>, Avi Lior <[email-masked]>, "'Nelson, David'" <[email-masked]>,  [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 14:42:37 -0500

Hi Madjid,

Absolutely not. CUI and EAP usage should not be entertwined. EAP works fine
without CUI and CUI works fine with out EAP.

CUI allows mediating networks and visited networks to implement certain
business logic. For example:

As a driving usecase for this work we noted that when certain EAP methods
are used the identity of the user is hidden and mediating networks have no
way to associate an Authentication\Authorization and or Accounting events to
a specific user or chargeable entity.  CUI provides a mechanims whereby the
home network can provide a handle to the chargeable entity (without
revealing the true identity), to the roaming partners and or mediating
networks.

This does not mean that it is required when EAP is used.  Nor does it mean
that it can't be used in cases where EAP is not used.

It simply means that it is available to be used when it is required by
roaming partners - for whatever reason.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 12:23 PM
> To: 'Avi Lior'; 'Nelson, David'; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> Avi,
> 
> I don't understand CUI well, but I care about EAP. Doesn't 
> this mean the EAP server and the EAP authentication methods 
> must now support use of CUI as identity and be able to do the 
> conversions? 
> 
> Madjid
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Avi Lior
> Sent: Thursday, December 16, 2004 5:14 PM
> To: 'Nelson, David'; [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> David,
> 
> Sorry for the short reply. I was rushed away. Let me expand.
> 
> We already mention in the document that CUI is useable when 
> EAP is used and in particular when EAP methods hide the user identity.
> 
> What I am opposed to is mandating that the only case for CUI 
> is tied to the use of EAP. Operationaly it does not depend on 
> EAP. There could be other uses in the future.  So the current 
> text in the draft is sufficient.
> 
> Avi
> 
> > -----Original Message-----
> > From: Nelson, David [mailto:[email-masked]]
> > Sent: Thursday, December 16, 2004 1:29 PM
> > To: [email-masked]
> > Subject: RE: Scope of applicability for CUI
> > 
> > 
> > 
> > Avi Lior writes...
> > 
> > > There maybe others that I am not aware of.
> > 
> > It's hard to design practical and interoperable protocols to
> > meet the requirements of unknown use cases -- so perhaps we 
> > can focus on the known ones.
> > 
> > > But these specific once are the once that we have seen
> > requests for. I
> > > believe these are mentioned in the draft as request by folks here.
> > 
> > OK.  Since User-Name re-write is considered "evil" in roaming
> > applications, because it changes the routing for RADIUS 
> > request traffic, can we assume that only addressing use case 
> > (B) is sufficient to meet the current needs?
> > 
> > If so, how is linking the use of CUI to the use of EAP
> > authentication inappropriate?
> > 
> > > > A) when the User-Name re-write feature (for accounting
> > > > purposes) obscures the original authentication identity, or
> > > >
> > > > B) when the RADIUS authentication method is EAP, allowing for a
> > > > "method internal" user identity for authentication, and an 
> > > > "anonymous" or "routing-only" value in User-Name.
> > > >
> > > > These use cases are further restricted to multi-party
> > (e.g. roaming
> > > > consortia) environments, because for deployments where
> > the NAS and
> > > > the Home RADIUS server belong to a single administrative
> > entity the
> > > > Class attribute has been seen to be sufficient.
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 17:23:26 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 11:23:05 -0600

Avi,

I don't understand CUI well, but I care about EAP. Doesn't this mean the EAP server and the EAP authentication methods must now support use of CUI as identity and be able to do the conversions? 

Madjid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Avi Lior
Sent: Thursday, December 16, 2004 5:14 PM
To: 'Nelson, David'; [email-masked]
Subject: RE: Scope of applicability for CUI

David,

Sorry for the short reply. I was rushed away. Let me expand.

We already mention in the document that CUI is useable when EAP is used and
in particular when EAP methods hide the user identity.

What I am opposed to is mandating that the only case for CUI is tied to the
use of EAP. Operationaly it does not depend on EAP. There could be other
uses in the future.  So the current text in the draft is sufficient.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 1:29 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> 
> Avi Lior writes...
> 
> > There maybe others that I am not aware of.
> 
> It's hard to design practical and interoperable protocols to 
> meet the requirements of unknown use cases -- so perhaps we 
> can focus on the known ones.
> 
> > But these specific once are the once that we have seen 
> requests for. I 
> > believe these are mentioned in the draft as request by folks here.
> 
> OK.  Since User-Name re-write is considered "evil" in roaming 
> applications, because it changes the routing for RADIUS 
> request traffic, can we assume that only addressing use case 
> (B) is sufficient to meet the current needs?
> 
> If so, how is linking the use of CUI to the use of EAP 
> authentication inappropriate?
> 
> > > A) when the User-Name re-write feature (for accounting
> > > purposes) obscures the original authentication identity, or
> > >
> > > B) when the RADIUS authentication method is EAP, allowing for a 
> > > "method internal" user identity for authentication, and an 
> > > "anonymous" or "routing-only" value in User-Name.
> > >
> > > These use cases are further restricted to multi-party 
> (e.g. roaming
> > > consortia) environments, because for deployments where 
> the NAS and 
> > > the Home RADIUS server belong to a single administrative 
> entity the 
> > > Class attribute has been seen to be sufficient.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 16:53:07 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: AW: backwards compatible introduction of NEW attribute such a s CU I
Date: Fri, 17 Dec 2004 11:52:48 -0500

Bernard,

> Assuming we can define what a RADIUS client and server need 
> to do in order to support "privacy" then we can write an 
> applicability statement for CUI that requires RFC 3579 and 
> "privacy" support as a precondition for CUI support.

I strongly disagree.  CUI should not require RFC 3579 and "privcy" support.
There is no justification to formally do this. I would agree with this only
if you can demonstrate that CUI will not work if 3579 was not being used
etc....

Even the flip side does not hunt. That is requiring CUI when 3579 is being
used. CUI is not required when 3579 is being used.  Second, the horses are
out of the barn.

> The way I think of it, NASes can already claim compliance to 
> RFC 3579 if they support EAP.  But we are talking about 
> something above and beyond that -- RFC 3579 plus RFC 2486bis 
> plus CUI.  So we can state that the CUI assumes support for 
> RFC 2486bis and RFC 3579, and then place requirements on 
> RADIUS servers that support all of that.

Absolutely not.  Use of CUI should remain generally optional. It is only
required when roaming partners determine that they need it.

We must not prevent the use of CUI when 3579 and 2486bis is not being used.

Avi.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 2:47 AM
> To: Nelson, David
> Cc: [email-masked]
> Subject: RE: AW: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> > 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.
> >
> > That sounds like a reasonable approach.  How would we effectively 
> > document this scope of applicability and interdependencies?
> 
> First off, we have to define what "privacy means".  The 
> logical place to do this is in RFC 2486bis.  I've failed an 
> issue relating to the perceived vagueness of the definition.
> 
> Assuming we can define what a RADIUS client and server need 
> to do in order to support "privacy" then we can write an 
> applicability statement for CUI that requires RFC 3579 and 
> "privacy" support as a precondition for CUI support.
> 
> > The other part of the question is when and how to require that the
> > RADIUS Clients (i.e. NASes), and Proxies support CUI?   Do we make a
> > similar assertion around NAS support for RFC 3579 and RFC 2486bis?
> 
> The way I think of it, NASes can already claim compliance to 
> RFC 3579 if they support EAP.  But we are talking about 
> something above and beyond that -- RFC 3579 plus RFC 2486bis 
> plus CUI.  So we can state that the CUI assumes support for 
> RFC 2486bis and RFC 3579, and then place requirements on 
> RADIUS servers that support all of that.
> 
> This way we're not trying to upgrade every RADIUS server and 
> NAS in the world, just the ones that already have enough 
> functionality to make CUI worthwhile.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 16:43:04 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Fri, 17 Dec 2004 11:42:50 -0500

I agree. The intent of this draft was not to make the CUI broadly required.

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 1:44 AM
> To: Avi Lior
> Cc: 'Nelson, David'; [email-masked]
> Subject: Re: Scope of applicability for CUI
> 
> 
> On Thu, Dec 16, 2004 at 06:14:09PM -0500, Avi Lior wrote:
> > 
> > We already mention in the document that CUI is useable when EAP is 
> > used and in particular when EAP methods hide the user identity.
> > 
> > What I am opposed to is mandating that the only case for 
> CUI is tied 
> > to the use of EAP. Operationaly it does not depend on EAP. 
> There could 
> > be other uses in the future.  So the current text in the draft is 
> > sufficient.
> 
> To me, the crucial issue is when support for CUI is 
> *required*.  I'm perfectly comfortable with people finding 
> other uses for CUI, in environments where it's already 
> supported or where all parties agree to support it.  I would 
> oppose making it a requirement for RADIUS compatibility in 
> "traditional" environments - but I don't think anyone so far 
> has done that.
> 
> If a particular proxy owner wants to demand CUI support as a 
> condition of doing business, it certainly has the right to do 
> so.  It may or may not be wise business policy.  That's for 
> the market to determine, if we are wise and make CUI support 
> strictly optional.
> 
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 16:38:48 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Fri, 17 Dec 2004 11:38:12 -0500

Bernard,

> With a VSA, if the NAS doesn't understand it, it can ignore 
> it.  Is that true of CUI as well?  If this really is about 
> the NAS, then I think the answer is yes.  The RADIUS Server 
> can send CUI along with Class, and if the NAS doesn't support 
> it, it can ignore it and the home server will get all the 
> billing info it needs from the Class attribute.  This is 
> backward compatible on the NAS (since it doesn't need to be 
> upgraded to support
> CUI) as well as on the RADIUS server (who doesn't see a CUI 
> attribute it didn't ask for).
> 

Exactly.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, December 17, 2004 2:57 AM
> To: Avi Lior
> Cc: Adrangi, Farid; [email-masked]
> Subject: RE: backwards compatible introduction of NEW 
> attribute such as CU I
> 
> 
> > This document is not addressing the needs of the home network. 
> > Business Requirements in the proxy and visited network are 
> driving the 
> > need for the CUI attribute.
> 
> That makes sense to me (and to quite a few others as well) it 
> seems. Perhaps we should ask the WG for consensus on this 
> point?  It certainly would make things a lot easier if there 
> was agreement on this (see below).
> 
> > CUI in an Access Accept.  This is no different then when the home 
> > network delivers a CISCO VSA when it knows that its partner 
> is using a 
> > CISCO NAS and requires the functionality provided by the VSA.
> 
> With a VSA, if the NAS doesn't understand it, it can ignore 
> it.  Is that true of CUI as well?  If this really is about 
> the NAS, then I think the answer is yes.  The RADIUS Server 
> can send CUI along with Class, and if the NAS doesn't support 
> it, it can ignore it and the home server will get all the 
> billing info it needs from the Class attribute.  This is 
> backward compatible on the NAS (since it doesn't need to be 
> upgraded to support
> CUI) as well as on the RADIUS server (who doesn't see a CUI 
> attribute it didn't ask for).
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 13:37:44 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: AW: Comments to draft-ietf-radext-digest-auth-00.txt
Date: Fri, 17 Dec 2004 14:37:06 +0100

Miguel,

You wrote:
> 
> I think my role is to highlight the differences and limits of both 
> drafts, it is up to the WG to decide whether the solution is to expand 
> the scope of the RADIUS draft to include authorization or not.
That's the point. The alternatives are:
A. limit radext-digest-auth to authentication
Pro: the draft is useful for other protocols, like HTTP or even TURN
(HTTP compatibility is a requirement of 3GPP2).
Con: a RADIUS/Diameter gateway is not possible as SIP-AOR is missing

B. extend radext-digest-auth with attributes relevant for SIP authorization
Pro: easy translation between RADIUS and Diameter
Con: no more compatibility with other protocols using digest authentication
(as SIP-AOR usage is mandatory)

A variation of A would be to put SIP authorization attributes into a separate
document. This document would reference radext-digest-auth and define RADIUS/Diameter
translation (which could be removed from radext-digest-auth).

A variation of B would be to define SIP-AOR and say "this attribute is MANDATORY
if the RADIUS client deals with SIP messages".

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 11:04:48 +0000
content-class: urn:content-classes:message
Subject: RE: [RFC2486bis] Issue 42: Definition of "Privacy"
Date: Fri, 17 Dec 2004 13:03:28 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard Aboba wrote:

> Sent: Friday, December 17, 2004 9:42 AM
> To: [email-masked]
> Subject: [RFC2486bis] Issue 42: Definition of "Privacy"
>=20
>=20
> Issue 42: Definition of "Privacy"
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> Date first submitted: December 16, 2004
> Reference:
> Document: RFC2486bis-03
> Comment type: T
> Priority: S
> Section: 2.3
> Rationale/Explanation of issue:
>=20
> The Abstract of this document states:
>=20
> "Enhancements include international character set and
> privacy support"
>=20
> However, Section 2.3 does not explicitly state what a privacy=20
> NAI looks like, only that the "username" portion of the NAI=20
> SHOULD be treated as opaque and that the NAI MAY be provided in=20
> abbreviated form.
>=20
> This has the potential to result in interoperability=20
> problems, since some implementations will embue userids such=20
> as "anonymous" with special properties, while others will not. =20
> It also makes it difficult for specifications such as CUI to=20
> define when "Privacy" is being requested.

Hmm... privacy is not a on/off feature, and I don't think this
document should treat it as such. For instance, you can use
pseudonyms (either one-time or at least changed frequently)
to provide better privacy than just sending the long-term
identifier, and CUI would be useful in such cases, too.

> Suggested fix:
>=20
> In Section 2.3, change:
>=20
> "  Interpretation of the "username" part of the NAI depends=20
>    on the realmin question.  Therefore, the "username" part=20
>    SHOULD be treated as opaque data when processed by nodes that=20
>    are not a part of the authoritative domain (in the sense of=20
>    Section 4) for that realm.
>=20
>    Where privacy is a concern, NAIs MAY be provided in an=20
>    abbreviated form by omitting the username portion.  This=20
>    is possible only when NAIs are used together with a=20
>    separate authentication method that can transfer the=20
>    username in a secure manner."
>=20
> To:
>=20
> "  Interpretation of the "username" part of the NAI depends=20
>    on the realm in question.  Therefore, the "username" part=20
>    SHOULD be treated as opaque data when processed by nodes that=20
>    are not a part of the authoritative domain (in the sense of=20
>    Section 4) for that realm.
>=20
>    Where it is desired that the username portion of the NAI=20
>    not be sent in the clear, an authentication method that=20
>    encrypts the NAI MUST be used, along with the "privacy"=20
>    NAI format, which omits the "username" portion entirely. =20
>    Note that since the "username" part of the NAI is considered=20
>    an opaque blob, if this is included, there is no way for
>    nodes not part of the authoritative domain to determine
>    that "privacy" is desired.

How about this?

   "In some situations NAIs are are used together with a
   separate authentication method that can transfer the username
   part in a more secure manner to increase privacy.  In this
   case, NAIs MAY be provided in an abbreviated form by omitting
   the username part.  Omitting the username part is RECOMMENDED
   over using a fixed username part, such as "anonymous", since
   it provides an unambiguous way to determine whether the
   username is intended to uniquely identify a single user."

Best regards,
Pasi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 10:10:06 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: Comments to draft-ietf-radext-digest-auth-00.txt
Date: Fri, 17 Dec 2004 11:09:25 +0100

Hi Miguel,

You wrote: 
> I took a look at draft-ietf-radext-digest-auth-00.txt, based on the 
> comments that I posted to an earlier version of the draft. I 
> still have 
> a few comments:
> 
> 1) Section 4.1 has a table that maps RADIUS attributtes to 
> Diameter SIP 
> app. AVPs. I think this table is no longer needed, since Diameter SIP 
> app imports (or will import in forthcoming version -05) the Digest-* 
> attributes from your draft.
> 
> Specifically, Diameter SIP app imports Digest-Method and 
> Digest-URI from 
> your draft, so there is no mapping at all. Therefore, Table 1 in your 
> draft has to be removed.

diameter-sip-app-05 has additional SIP-AOR and SIP-Method AVPs, which have
no counterpart in radext-digest-auth-00. I think you defined SIP-AOR and
SIP-Method to be able to authorize actions of users ("User 'User-Name' is
allowed to send messages with a method 'SIP-Method' and AOR SIP-AOR").

Should I add SIP-Method, SIP-AOR (HTTP-Method, SIP-AOR?) to radext-digest-auth-00?
On the other hand, why stop with method and aor; providers might by interested
in authorizazion by Content-Type or even SDP header contents.

> 
> 
> 2) We discussed an atypical case when a SIP request contains 
> more than 
> one set of credentials, perhaps because the request traversed several 
> proxies and each one authenticated the user. We agree to add some 
> discussion, and the only text I found (correct me if I am 
> wrong), is a 
> bit weak in my opinion:
> 
>     On reception of an HTTP-style request message, the RADIUS client
>     looks for a (Proxy-)Authorization header where the realm directive
>     matches its locally configured realm value.
> 
> I would suggest to add a bit more of descriptive text, it is 
> never a bad 
> idea. I send you the text I added to the Diameter SIP app 
> draft, you can 
> copy/adapt/modify if you want:
> 
> "There are situation where a SIP request traverses several 
> proxies, and 
> each of the proxies request to authenticate the SIP UA. In this 
> situation, it is a valid scenario that a SIP request received 
> at a SIP 
> server contains several sets of credentials. The 'realm' directive in 
> HTTP is the key that the Diameter client can use to determine which 
> credential is applicable. It may happen also that none of the 
> realms are 
> of interests to the Diameter client, in which case the 
> Diameter client 
> MUST consider that no credentials (of interest) were sent. In 
> any case, 
> a Diameter client MUST send zero or exactly one credential to the 
> Diameter server. The Diameter client MUST choose the 
> credential based on 
> the 'realm' directive in the Authorization/Proxy-Authorization header 
> field, and it MUST match the realm of the Diameter client."
> 
I will adapt and include this text.

> 3) We spoke that Digest-Response and Digest-Response-Auth 
> attributes had 
> an artificial limit of 32 octets, and I proposed to avoid having any 
> limit. The current version of the draft indicates that these 
> attributes 
> have a lenght >= 34 (32 octets + the length + the attribute 
> type). This 
> allows future expansion if the size goes further than 32, but 
> not if the 
> size decreases. While it is unlikely that new algorithms will 
> decrease 
> this size, since I don't have a ball to guess the future, I still 
> propose to have this size unlimited, i.e., Length => 3.
Ok.

> 4) I had another comment regarding the 'qop' parameter in 
> HTTP Digest. 
> The problem is that this pararameter can contain several values, for 
> example, qop=auth,auth-int. The draft should indicate how to 
> encode in 
> Radius this several parameters. I haven't found this described yet.
> 
> We had a discussion on the mailing list and I expressed my preference 
> for option b, that I repeat below:
> 
>    b) Each token is an attribute, thus, there might be multiple
>       Digest-Qop attributes in a particular Radius/Diameter message.
See section 3.2

"The RADIUS server MUST add Digest-Algorithm, Digest-Realm,
   SHOULD add one or more Digest-Qop and MAY add Digest-Domain,
   Digest-Opaque attributes to the Access-Challenge message.  If the
   server cannot choose a nonce, it replies with an Access-Reject
   message."

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany  

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 07:57:47 +0000
Date: Thu, 16 Dec 2004 23:57:27 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I

> This document is not addressing the needs of the home network.
> Business Requirements in the proxy and visited network are driving the need
> for the CUI attribute.

That makes sense to me (and to quite a few others as well) it seems.
Perhaps we should ask the WG for consensus on this point?  It certainly
would make things a lot easier if there was agreement on this (see below).

> CUI in an Access Accept.  This is no different then when the home network
> delivers a CISCO VSA when it knows that its partner is using a CISCO NAS and
> requires the functionality provided by the VSA.

With a VSA, if the NAS doesn't understand it, it can ignore it.  Is that
true of CUI as well?  If this really is about the NAS, then I think the
answer is yes.  The RADIUS Server can send CUI along with Class, and if
the NAS doesn't support it, it can ignore it and the home server will get
all the billing info it needs from the Class attribute.  This is backward
compatible on the NAS (since it doesn't need to be upgraded to support
CUI) as well as on the RADIUS server (who doesn't see a CUI attribute it
didn't ask for).

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 07:47:01 +0000
Date: Thu, 16 Dec 2004 23:46:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: AW: backwards compatible introduction of NEW attribute such as CU I

> 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.
>
> That sounds like a reasonable approach.  How would we effectively
> document this scope of applicability and interdependencies?

First off, we have to define what "privacy means".  The logical place to
do this is in RFC 2486bis.  I've failed an issue relating to the perceived
vagueness of the definition.

Assuming we can define what a RADIUS client and server need to do in order
to support "privacy" then we can write an applicability statement for CUI
that requires RFC 3579 and "privacy" support as a precondition for CUI
support.

> The other part of the question is when and how to require that the
> RADIUS Clients (i.e. NASes), and Proxies support CUI?   Do we make a
> similar assertion around NAS support for RFC 3579 and RFC 2486bis?

The way I think of it, NASes can already claim compliance to RFC 3579 if
they support EAP.  But we are talking about something above and beyond
that -- RFC 3579 plus RFC 2486bis plus CUI.  So we can state that the CUI
assumes support for RFC 2486bis and RFC 3579, and then place requirements
on RADIUS servers that support all of that.

This way we're not trying to upgrade every RADIUS server and NAS in the
world, just the ones that already have enough functionality to make CUI
worthwhile.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 07:42:00 +0000
Date: Thu, 16 Dec 2004 23:41:31 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: [RFC2486bis] Issue 42: Definition of "Privacy"

Issue 42: Definition of "Privacy"
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 16, 2004
Reference:
Document: RFC2486bis-03
Comment type: T
Priority: S
Section: 2.3
Rationale/Explanation of issue:

The Abstract of this document states:

"Enhancements include international character set and
privacy support"

However, Section 2.3 does not explicitly state what a privacy NAI looks
like, only that the "username" portion of the NAI SHOULD be treated as
opaque and that the NAI MAY be provided in abbreviated form.

This has the potential to result in interoperability problems, since some
implementations will embue userids such as "anonymous" with special
properties, while others will not.  It also makes it difficult for
specifications such as CUI to define when "Privacy" is being requested.

Suggested fix:

In Section 2.3, change:

"  Interpretation of the "username" part of the NAI depends on the realm
   in question.  Therefore, the "username" part SHOULD be treated as
   opaque data when processed by nodes that are not a part of the
   authoritative domain (in the sense of Section 4) for that realm.

   Where privacy is a concern, NAIs MAY be provided in an abbreviated
   form by omitting the username portion.  This is possible only when
   NAIs are used together with a separate authentication method that can
   transfer the username in a secure manner."

To:

"  Interpretation of the "username" part of the NAI depends on the realm
   in question.  Therefore, the "username" part SHOULD be treated as
   opaque data when processed by nodes that are not a part of the
   authoritative domain (in the sense of Section 4) for that realm.

   Where it is desired that the username portion of the NAI not
   be sent in the clear, an authentication method that encrypts
   the NAI MUST be used, along with the "privacy" NAI
   format, which omits the "username" portion entirely.  Note that
   since the "username" part of the NAI is considered an
   opaque blob, if this is included, there is no way for
   nodes not part of the authoritative domain to determine
   that "privacy" is desired.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 17 Dec 2004 06:45:49 +0000
Date: Fri, 17 Dec 2004 01:43:57 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: Re: Scope of applicability for CUI

On Thu, Dec 16, 2004 at 06:14:09PM -0500, Avi Lior wrote:
> 
> We already mention in the document that CUI is useable when EAP is used and
> in particular when EAP methods hide the user identity.
> 
> What I am opposed to is mandating that the only case for CUI is tied to the
> use of EAP. Operationaly it does not depend on EAP. There could be other
> uses in the future.  So the current text in the draft is sufficient.

To me, the crucial issue is when support for CUI is *required*.  I'm
perfectly comfortable with people finding other uses for CUI, in
environments where it's already supported or where all parties agree
to support it.  I would oppose making it a requirement for RADIUS
compatibility in "traditional" environments - but I don't think anyone
so far has done that.

If a particular proxy owner wants to demand CUI support as a condition
of doing business, it certainly has the right to do so.  It may or may
not be wise business policy.  That's for the market to determine, if we
are wise and make CUI support strictly optional.

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 23:14:45 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI
Date: Thu, 16 Dec 2004 18:14:09 -0500

David,

Sorry for the short reply. I was rushed away. Let me expand.

We already mention in the document that CUI is useable when EAP is used and
in particular when EAP methods hide the user identity.

What I am opposed to is mandating that the only case for CUI is tied to the
use of EAP. Operationaly it does not depend on EAP. There could be other
uses in the future.  So the current text in the draft is sufficient.

Avi

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 1:29 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> 
> Avi Lior writes...
> 
> > There maybe others that I am not aware of.
> 
> It's hard to design practical and interoperable protocols to 
> meet the requirements of unknown use cases -- so perhaps we 
> can focus on the known ones.
> 
> > But these specific once are the once that we have seen 
> requests for. I 
> > believe these are mentioned in the draft as request by folks here.
> 
> OK.  Since User-Name re-write is considered "evil" in roaming 
> applications, because it changes the routing for RADIUS 
> request traffic, can we assume that only addressing use case 
> (B) is sufficient to meet the current needs?
> 
> If so, how is linking the use of CUI to the use of EAP 
> authentication inappropriate?
> 
> > > A) when the User-Name re-write feature (for accounting
> > > purposes) obscures the original authentication identity, or
> > >
> > > B) when the RADIUS authentication method is EAP, allowing for a 
> > > "method internal" user identity for authentication, and an 
> > > "anonymous" or "routing-only" value in User-Name.
> > >
> > > These use cases are further restricted to multi-party 
> (e.g. roaming
> > > consortia) environments, because for deployments where 
> the NAS and 
> > > the Home RADIUS server belong to a single administrative 
> entity the 
> > > Class attribute has been seen to be sufficient.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 21:09:34 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Scope of applicability for CUI
Date: Thu, 16 Dec 2004 16:09:16 -0500

David,

> If so, how is linking the use of CUI to the use of EAP 
> authentication inappropriate?

Why is it necessary?

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 1:29 PM
> To: [email-masked]
> Subject: RE: Scope of applicability for CUI
> 
> 
> 
> Avi Lior writes...
> 
> > There maybe others that I am not aware of.
> 
> It's hard to design practical and interoperable protocols to 
> meet the requirements of unknown use cases -- so perhaps we 
> can focus on the known ones.
> 
> > But these specific once are the once that we have seen 
> requests for. I 
> > believe these are mentioned in the draft as request by folks here.
> 
> OK.  Since User-Name re-write is considered "evil" in roaming 
> applications, because it changes the routing for RADIUS 
> request traffic, can we assume that only addressing use case 
> (B) is sufficient to meet the current needs?
> 
> If so, how is linking the use of CUI to the use of EAP 
> authentication inappropriate?
> 
> > > A) when the User-Name re-write feature (for accounting
> > > purposes) obscures the original authentication identity, or
> > >
> > > B) when the RADIUS authentication method is EAP, allowing for a 
> > > "method internal" user identity for authentication, and an 
> > > "anonymous" or "routing-only" value in User-Name.
> > >
> > > These use cases are further restricted to multi-party 
> (e.g. roaming
> > > consortia) environments, because for deployments where 
> the NAS and 
> > > the Home RADIUS server belong to a single administrative 
> entity the 
> > > Class attribute has been seen to be sufficient.
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 20:59:15 +0000
Content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 12:58:43 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Greg Weber" <[email-masked]>
Cc: <[email-masked]>

Thanks so much Greg.  Will fix these in the next version.
BR,
Farid

> -----Original Message-----
> From: Greg Weber [mailto:[email-masked]]=20
> Sent: Thursday, December 16, 2004 12:27 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: Re: CUI - issues addressed in version 3
>=20
>=20
> >=20
> > Hi David, Bernard, Greg, Barney:
> >=20
> > First, thanks again for reviewing the draft and submitting issues
> > against versions 1 and 2. It would be great if you can let us know
> > whether or not version 03 addresses the issues.   =20
> >=20
> > Issues addressed in Version 3
> > =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
> > Issue 13 (Owner: David Mariblanca)
> > Issue 14 (Owner: Bernard Aboba)
> > Issue 18 (Owner: Greg Weber)
>=20
> Hi Farid,
> The current version of the draft addresses most of the editorial
> issues I mentioned for version -01.  Here are some exceptions:
>=20
> Section 2.1
>   "Access Accept message" -> "Access-Accept message"
>   "Accounting Requests" -> "Accounting-Request"
>   "User-Name (1)" -> "User-Name(1)" (two places)
> Section 5
>   "Event-Timestamp" -> "Event-Timestamp(55)"
>=20
> A couple other nits I see:
>=20
> Abstract
>   "identity a user" -> "identify a user"
> Section 2.1
>   "CUI attribute the CUI attribute" -> "CUI attribute, the=20
> CUI attribute"
>   Several occurances of multiple spaces between words, e.g.
>     "the  second  part  is  the" =20
> Normative References
>   Each non-IETF reference seems to be missing something, e.g.
>     '...Plan", , May 1997'
>  =20
> Greg
>=20
> > Issue 21 (Owner: Barney Wolff)
> > Issue 22 (Owner: Barney Wolff)=20
> >=20
> > The description of these issues can be found in in
> > http://www.drizzle.com/~aboba/RADEXT/#Issue%2014.
> >=20
> > Thanks for your help.
> >=20
> > BR,
> > Farid
> >=20
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 20:27:43 +0000
From: Greg Weber <[email-masked]>
Subject: Re: CUI - issues addressed in version 3
To: [email-masked] (Adrangi, Farid)
Date: Thu, 16 Dec 2004 15:26:51 -0500 (EST)
Cc: [email-masked]

> 
> Hi David, Bernard, Greg, Barney:
> 
> First, thanks again for reviewing the draft and submitting issues
> against versions 1 and 2. It would be great if you can let us know
> whether or not version 03 addresses the issues.    
> 
> Issues addressed in Version 3
> =============================
> Issue 13 (Owner: David Mariblanca)
> Issue 14 (Owner: Bernard Aboba)
> Issue 18 (Owner: Greg Weber)

Hi Farid,
The current version of the draft addresses most of the editorial
issues I mentioned for version -01.  Here are some exceptions:

Section 2.1
  "Access Accept message" -> "Access-Accept message"
  "Accounting Requests" -> "Accounting-Request"
  "User-Name (1)" -> "User-Name(1)" (two places)
Section 5
  "Event-Timestamp" -> "Event-Timestamp(55)"

A couple other nits I see:

Abstract
  "identity a user" -> "identify a user"
Section 2.1
  "CUI attribute the CUI attribute" -> "CUI attribute, the CUI attribute"
  Several occurances of multiple spaces between words, e.g.
    "the  second  part  is  the"  
Normative References
  Each non-IETF reference seems to be missing something, e.g.
    '...Plan", , May 1997'
  
Greg

> 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.
> 
> Thanks for your help.
> 
> BR,
> Farid
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 19:00:02 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 13:59:42 -0500

Barney,

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

The server doesn't care about CUI and the text needs to be reworded.

Farid and I are currently reworking the words.

Regarding binding issue:

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

So we agree with your statement in general.  The binding lifetime is part of
the requirement. But just to make it perfectly clear it is only relevant to
the opaque CUI format.

Your concerns are correct. The difference is that we belive that it is
really up to an SDO or the business relationship to nail down the issues you
serve up.

The reason we belive that we can't specify these issues is that each SDO
will have different requirements here. We are simply providing them with the
tools to do it.

So for example in the case of Opaque CUI. One SDO may say that a different
Opaque CUI will be generated at the start of a billing period.  Another SDO
may specify that the first 4 octets of the Opaque CUI will contain a
validity timestamp.

Also the 1:1 relationship is an SDO matter. We can say that it is 1:1 but I
don't think it is necessary.  The business agreement between roaming
partners will define the semantics.

See further inline:

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 2:17 AM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: Re: CUI - issues addressed in version 3
> 
> 
> 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.

We agree. We need to change the words here. The Home Network does not care
about CUI. The home network can always use class - even when trunctated and
even if only one is supported by the NAS. And, even when class is not used.
We have been doing this for years.  But this is not about the home network
as you point out.

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

Right!!!.

> > > 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 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 18:30:19 +0000
Content-class: urn:content-classes:message
Subject: RE: Scope of applicability for CUI
Date: Thu, 16 Dec 2004 13:29:03 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> There maybe others that I am not aware of.

It's hard to design practical and interoperable protocols to meet the
requirements of unknown use cases -- so perhaps we can focus on the
known ones.

> But these specific once are the once that we have seen requests for.
> I believe these are mentioned in the draft as request by folks here.

OK.  Since User-Name re-write is considered "evil" in roaming
applications, because it changes the routing for RADIUS request traffic,
can we assume that only addressing use case (B) is sufficient to meet
the current needs?

If so, how is linking the use of CUI to the use of EAP authentication
inappropriate?

> > A) when the User-Name re-write feature (for accounting
> > purposes) obscures the original authentication identity, or
> >
> > B) when the RADIUS authentication method is EAP, allowing for
> > a "method internal" user identity for authentication, and an
> > "anonymous" or "routing-only" value in User-Name.
> >
> > These use cases are further restricted to multi-party (e.g. roaming
> > consortia) environments, because for deployments where the
> > NAS and the Home RADIUS server belong to a single
> > administrative entity the Class attribute has been seen to be
> > sufficient.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 18:19:59 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Scope of applicability for CUI  (was: RE: AW: backwards compa tible introduction of NEW attribute such as CU I)
Date: Thu, 16 Dec 2004 13:19:45 -0500

David,

There maybe others that I am not aware of. But these specific once are the
once that we have seen requests for.  I believe these are mentioned in the
draft as request by folks here.

Avi.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 1:07 PM
> To: [email-masked]
> Subject: Scope of applicability for CUI (was: RE: AW: 
> backwards compatible introduction of NEW attribute such as CU I)
> 
> 
> Avi Lior writes...
> 
> > 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.
> 
> CUI is only *needed* when User-Name doesn't serve the 
> purpose.  What are the use cases when User-Name isn't 
> sufficient?  I think they are:
> 
> A) when the User-Name re-write feature (for accounting 
> purposes) obscures the original authentication identity, or 
> 
> B) when the RADIUS authentication method is EAP, allowing for 
> a "method internal" user identity for authentication, and an 
> "anonymous" or "routing-only" value in User-Name.
> 
> These use cases are further restricted to multi-party (e.g. roaming
> consortia) environments, because for deployments where the 
> NAS and the Home RADIUS server belong to a single 
> administrative entity the Class attribute has been seen to be 
> sufficient.
> 
> Are there any other relevant use cases?
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 18:10:35 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 13:10:26 -0500

You are right David.  I meant the SDO will choose which CUI type will be
used. One of those types is Opaque.  An SDO will define how to generate the
Opaque value and how long is the validity.  In fact some implemenation of
Opaque may include a timestamp value that declares how long this opaque is
good for.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 11:52 AM
> To: [email-masked]
> Subject: RE: CUI - issues addressed in version 3
> 
> 
> Avi Lior writes...
> 
> > -The SDO will define the format of the CUI; and
> > -When the CUI is an opaque value, it will define how long 
> it is valid
> for.
> 
> I thought that the CUI draft defined the *format* of the 
> Chargeable-User-ID attribute.  No?
> 
> Other SDOs are certainly free to specify or recommend the 
> values of CUI or lifetime, but I believe that the format 
> (syntax and semantics) of standard RADIUS attributes needs to 
> be defined in [Standards Track] RFCs.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 18:08:44 +0000
Content-class: urn:content-classes:message
Subject: Scope of applicability for CUI  (was: RE: AW: backwards compatible introduction of NEW attribute such as CU I)
Date: Thu, 16 Dec 2004 13:07:16 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

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

CUI is only *needed* when User-Name doesn't serve the purpose.  What are
the use cases when User-Name isn't sufficient?  I think they are:

A) when the User-Name re-write feature (for accounting purposes)
obscures the original authentication identity, or=20

B) when the RADIUS authentication method is EAP, allowing for a "method
internal" user identity for authentication, and an "anonymous" or
"routing-only" value in User-Name.

These use cases are further restricted to multi-party (e.g. roaming
consortia) environments, because for deployments where the NAS and the
Home RADIUS server belong to a single administrative entity the Class
attribute has been seen to be sufficient.

Are there any other relevant use cases?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 17:14:20 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Lothar Reith <[email-masked]>
Cc: "'Adrangi, Farid'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: AW: backwards compatible introduction of NEW attribute such a s CU I
Date: Thu, 16 Dec 2004 12:13:29 -0500

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:[email-masked]] 
> Sent: Thursday, December 16, 2004 10:23 AM
> To: Lothar Reith
> Cc: 'Adrangi, Farid'; [email-masked]'
> 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 [email-masked] 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 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 16:56:36 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Thu, 16 Dec 2004 11:56:23 -0500

Bernard,

See comments inlien

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 3:29 AM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: RE: backwards compatible introduction of NEW 
> attribute such as CUI
> 
> 
> Farid Adrangi wrote:
> 
> "We are currently working on -03 version of the CUI draft.  
> Here is a snippet on what we want to say about backward compatibility.
> 
> "
> ... Servers which do not understand the CUI attribute SHOULD 
> silently discard the attribute.
> 
> The NAS MAY include the CUI attribute with a null character 
> for its data field in the Access-Request message to indicate 
> its support for this attribute to the home RADIUS server.  In 
> cases where home RADIUS server cannot determine the NAS 
> support for the CUI, if the CUI is required for proper 
> billing, the home RADIUS server MUST reject the request by 
> sending an Access-Reject message including an Error-Cause 
> attribute [RFC3576] with value 402 (decimal), "Missing Attribute".
> 
> Otherwise, the home RADIUS server MUST send both the UserName 
> (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 UserName (1) 
> attribute.  That is, the UserName(1) attribute will be used 
> for routing and the CUI attribute will be used for identity 
> purposes. "
> 
> Before we get into developing a protocol (as suggested below) 
> to determine the CUI support, I would like to know why the 
> above paragraph does not address the backward compatibility problem."
> 
> 
> Here are some issues with the above approach:
> 
> a. An empty CUI attribute should be used instead of an 
> attribute with a NUL character for the Access-Request.

Assuming we still are going to do the advertizement part (under debate now).
2865 does not allow to send an empty string.

A String type must be 1-253 octets.

> b. RFC 2865 does not require servers to discard attributes 
> they don't understand; this is only a MAY.  So I don't think 
> you can make discard a SHOULD across the existing base of 
> RADIUS servers.  That said, if the use of CUI were restricted 
> only to use by NASes and servers that already support RFC 
> 3579 and "Privacy" then such language might be more reasonable.

I agree with the first two sentences.

I don't think we want to restrict CUI to only 3579 based implementations.  
Still, that doesn't mean that CUI is designed to be implemented in all
RADIUS deployements blindly.
Operators, SDOs, will call out for CUI when they need it's supplied
functionality in their network whether or not they are using 3579.

> c. If the RADIUS server needs information in the accounting 
> record why can't this be accomplished via use of the Class attribute?

This document is not addressing the needs of the home network.
Business Requirements in the proxy and visited network are driving the need
for the CUI attribute.
 
> d. My understanding is that the NAS is sending the empty CUI 
> attribute in order to signal the RADIUS Server that a CUI 
> attribute is expected in the Access Accept.  If this is 
> correct, then to maintain backward compatibility, the NAS 
> should only signal CUI support when the CUI is required.  For 
> example, the NAS might only signal CUI support if the client 
> sends a "Privacy" NAI, and in that case (and only that case) 
> will the NAS treat an Accept-Accept without CUI as an Access-Reject.

Again we are debating the need having the advertizement. But assuming we
need advertizement then, the bussiness relationship will determine whether
the NAS sends the the CUI advetizement or not.  So when two operators have a
roaming agreement. If they determine that the CUI is needed, they will
arrange for their AAA infrastructure to support the CUI or not.  This is why
I don't think we need the advertizement.

If the home network knows that its partner needs the CUI it will deliver the
CUI in an Access Accept.  This is no different then when the home network
delivers a CISCO VSA when it knows that its partner is using a CISCO NAS and
requires the functionality provided by the VSA.

> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 16:53:57 +0000
Content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 11:51:55 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> -The SDO will define the format of the CUI; and
> -When the CUI is an opaque value, it will define how long it is valid
for.

I thought that the CUI draft defined the *format* of the
Chargeable-User-ID attribute.  No?

Other SDOs are certainly free to specify or recommend the values of CUI
or lifetime, but I believe that the format (syntax and semantics) of
standard RADIUS attributes needs to be defined in [Standards Track]
RFCs.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 16:37:36 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 11:37:01 -0500

Hi John,

No. The lifetime of the CUI must be longer then the lifetime of the session.
Much longer.

But it would be defined by the SDO.

To summarize:
-The SDO will define the format of the CUI; and
-When the CUI is an opaque value, it will define how long it is valid for.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 15, 2004 11:13 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: CUI - issues addressed in version 3
> 
> 
> Farid & Barney,
> 
> > 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.
> 
> The lifetime will be determined by the home agent.  Other 
> SDOs are specifying values for the lifetime; however, perhaps 
> we could could include a default value that an operator or 
> SDO could override?
> 
> John
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 15:39:05 +0000
Content-class: urn:content-classes:message
Subject: RE: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Thu, 16 Dec 2004 10:37:30 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

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

That sounds like a reasonable approach.  How would we effectively
document this scope of applicability and interdependencies?  Perhaps
using something akin to the IEEE's Protocol Implementation Compliance
Statement (PICS)? =20

The other part of the question is when and how to require that the
RADIUS Clients (i.e. NASes), and Proxies support CUI?   Do we make a
similar assertion around NAS support for RFC 3579 and RFC 2486bis?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 15:23:32 +0000
Date: Thu, 16 Dec 2004 07:23:13 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Lothar Reith <[email-masked]>
cc: "'Adrangi, Farid'" <[email-masked]>, "[email-masked]'" <[email-masked]>
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 [email-masked] also a privacy NAI ? Or
> anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-privacy@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-will-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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 15:08:02 +0000
Date: Thu, 16 Dec 2004 17:05:56 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>, "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked]
Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00

Bernard Aboba wrote:

> Issue 11:     Jari Arkko indicates the issue is still open.

I'm still working on this one. Need to look at what Miguel
had and whats in the new -00 version.

> Issue 30:     Jari Arkko indicates the issue is still open.

Specifically, I said that I hadn't seen a response at the time.
But I checked the newest version and it includes a fix to issue
30 (thanks!). So I think you can mark this one closed.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 14:12:18 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Adrangi, Farid'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Thu, 16 Dec 2004 15:11:09 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E379.176BD5AC
Content-Type: text/plain

Bernard,

I just like to comment on your points c and d extracted from your most
recent mail sent today on this thread.

>Bernard wrote:
>c. If the RADIUS server needs information in the accounting record why
can't this be
>accomplished via use of the Class attribute?

Lothar: we gone through that loop already - My interpretation of the result:
because the home server may want to delegate to an intermediary some task
requiring some kind of identity awareness, but the intermediary is not
allowed to even interpret Class. Furthermore, I think overloading the Class
attribute with "identity" would be the wrong approach, simply because the
concepts of "Class" and "Identity" are very different. Class suggests
something applicaple to multiple identities, whereas "identity" suggests
uniqueness. Since this is a chargeable identity, it requires uniqueness,
(uniquely identifying the user) therefore "Class" may be the wrong concept.
Other arguments against the use of Class have been discussed, such as
limited support for Class attributes exceeding a certain length(truncating)
- which may be in contradiction to the uniqueness requirement.

Bernard wrote:
d. My understanding is that the NAS is sending the empty CUI attribute in
order to signal the RADIUS Server that a CUI attribute is expected in the
Access Accept.  If this is correct, then to maintain backward compatibility,
the NAS should only signal CUI support when the CUI is required.  For
example, the NAS might only signal CUI support if the client sends a
"Privacy" NAI, and in that case (and only that case) will the NAS treat an
Accept-Accept without CUI as an Access-Reject.

Lothar: This question relates to a  mail from Barney in thread: CUI issue 22

In there, Barney maintains it is the NAS owner which *requires* CUI
presence, whereas I had stated (and still maintain) my opinion  that it is
the home server operator who *requires* CUI presence. 

Meanwhile, I think the discussion about "who requires CUI presence" may be
rather useless because we do not seem to be able to agree on a coherent
interpretation of the term *require* (technically, business-wise, etc)

Let us rather discuss who initially determines the requirement for CUI
presence. This should make things clearer hopefully.

Many people seem to assume that the NAS may always be able to initially
determine the requirement for CUI presence, suggesting a CUI requirement
detection method which relies on being able to identify a "Privacy-NAI"
being presented by the user/authenticating peer and interpret it as a "user
initiated CUI-presence request".

Is that true for the roaming privacy application ?  And is a privacy NAI
well defined ? Is [email-masked] also a privacy NAI ? Or
anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-privacy@ex
ample.com ?

What about any other applications of CUI (besides roaming privacy) that
people may have in mind ?

By the way, it is interesting to see that your proposal d) may be
interpreted as capability negotiation - one could argue that the NAS acts as
master and negotiates with the Server (as slave) if the server supports CUI.
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. 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-will-chan
ge-the-accept-into-a-reject" .

Lothar

------_=_NextPart_001_01C4E379.176BD5AC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bernard,</FONT>
</P>

<P><FONT SIZE=3D2>I just like to comment on your points c and d =
extracted from your most recent mail sent today on this thread.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;Bernard wrote:</FONT>
<BR><FONT SIZE=3D2>&gt;c. If the RADIUS server needs information in the =
accounting record why can't this be</FONT>
<BR><FONT SIZE=3D2>&gt;accomplished via use of the Class =
attribute?</FONT>
</P>

<P><FONT SIZE=3D2>Lothar: we gone through that loop already - My =
interpretation of the result: because the home server may want to =
delegate to an intermediary some task requiring some kind of identity =
awareness, but the intermediary is not allowed to even interpret Class. =
Furthermore, I think overloading the Class attribute with =
&quot;identity&quot; would be the wrong approach, simply because the =
concepts of &quot;Class&quot; and &quot;Identity&quot; are very =
different. Class suggests something applicaple to multiple identities, =
whereas &quot;identity&quot; suggests uniqueness. Since this is a =
chargeable identity, it requires uniqueness, (uniquely identifying the =
user) therefore &quot;Class&quot; may be the wrong concept. Other =
arguments against the use of Class have been discussed, such as limited =
support for Class attributes exceeding a certain length(truncating) - =
which may be in contradiction to the uniqueness requirement.</FONT></P>

<P><FONT SIZE=3D2>Bernard wrote:</FONT>
<BR><FONT SIZE=3D2>d. My understanding is that the NAS is sending the =
empty CUI attribute in order to signal the RADIUS Server that a CUI =
attribute is expected in the Access Accept.&nbsp; If this is correct, =
then to maintain backward compatibility, the NAS should only signal CUI =
support when the CUI is required.&nbsp; For example, the NAS might only =
signal CUI support if the client sends a &quot;Privacy&quot; NAI, and =
in that case (and only that case) will the NAS treat an Accept-Accept =
without CUI as an Access-Reject.</FONT></P>

<P><FONT SIZE=3D2>Lothar: This question relates to a&nbsp; mail from =
Barney in thread: CUI issue 22</FONT>
</P>

<P><FONT SIZE=3D2>In there, Barney maintains it is the NAS owner which =
*requires* CUI presence, whereas I had stated (and still maintain) my =
opinion&nbsp; that it is the home server operator who *requires* CUI =
presence. </FONT></P>

<P><FONT SIZE=3D2>Meanwhile, I think the discussion about &quot;who =
requires CUI presence&quot; may be rather useless because we do not =
seem to be able to agree on a coherent interpretation of the term =
*require* (technically, business-wise, etc)</FONT></P>

<P><FONT SIZE=3D2>Let us rather discuss who initially determines the =
requirement for CUI presence. This should make things clearer =
hopefully.</FONT></P>

<P><FONT SIZE=3D2>Many people seem to assume that the NAS may always be =
able to initially determine the requirement for CUI presence, =
suggesting a CUI requirement detection method which relies on being =
able to identify a &quot;Privacy-NAI&quot; being presented by the =
user/authenticating peer and interpret it as a &quot;user initiated =
CUI-presence request&quot;.</FONT></P>

<P><FONT SIZE=3D2>Is that true for the roaming privacy application =
?&nbsp; And is a privacy NAI well defined ? Is [email-masked] =
also a privacy NAI ? Or =
anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-privac=
[email-masked] ?</FONT></P>

<P><FONT SIZE=3D2>What about any other applications of CUI (besides =
roaming privacy) that people may have in mind ?</FONT>
</P>

<P><FONT SIZE=3D2>By the way, it is interesting to see that your =
proposal d) may be interpreted as capability negotiation - one could =
argue that the NAS acts as master and negotiates with the Server (as =
slave) if the server supports CUI.&nbsp; 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. 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: =
&quot;CUI-attribute-presence-required-in-the-accept-message-otherwise-I-=
will-change-the-accept-into-a-reject&quot; .</FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E379.176BD5AC--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 12:32:38 +0000
Date: Thu, 16 Dec 2004 14:31:54 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "James M. Polk" <[email-masked]>
Cc: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Geopriv] Radius-Geopriv: Civic vs. geospatial  location	information

Hi James,

> Isn't that a configuration choice?
> 
> If different docs within Geopriv give a different "default" format to 
> use, this might lead to interoperability issues. This is the basis for 
> my concern and question below. I wasn't picking which made more sense in 
> usage, but wanted ot know if this interoperability issue was thought of.

I very much agree with you that having a different format/rules
can lead to interoperability problems, and that this is something
we should align across all Geopriv protocols and formats.

Regarding the configuration choice: yes, I believe this should
be a configuration choice. However, isn't this dictated to
a large extent by what is mandatory in the format? If geospatial
is mandatory, then presumably you have to have the data to fill
in?

In any case, I don't have a strong feeling about this. I prefer
maintaining consistency over other concerns. But the original
issue was that I could easily imagine that someone who sets up
an access point and its RADIUS might have just the civic information
but would need a special device and a visit to the location to
determine the geospatial location. If you already determined
that this is always going to be a requirement for PIDF-LO,
I'm fine with copying that to RADIUS attributes draft too.

--Jari

> At 08:25 AM 12/14/2004 +0200, Jari Arkko wrote:
> 
>> I can easily imagine a situation where you have just one
>> part of the information in an easy manner. For instance,
>> a plain old GPS system will only give you geospatial,
>> whereas configuration might just give you just the civil
>> location.
>>
>> --Jari
>>
>> James M. Polk wrote:
>>
>>> Hannes
>>> Don't forget that geospatial is mandatory to implement in PIDF-LO. 
>>> Civic is optional.
>>> I don't know what you want to do about consistency here.
>>> At 10:06 AM 12/13/2004 +0100, Tschofenig Hannes wrote:
>>>
>>>> hi all,
>>>>
>>>> currently the document says that civic location information MUST be
>>>> provided. Jari proposed to change the MUST into a SHOULD.
>>>>
>>>> we had a discussion on this issue during the geopriv meeting and i 
>>>> had the
>>>> impression that it is ok to change the MUST into a SHOULD.
>>>>
>>>> ciao
>>>> hannes
>>>>
>>>> _______________________________________________
>>>> Geopriv mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>> cheers,
>>> James
>>>                                *******************
>>>                 Truth is not to be argued... it is to be presented
>>> _______________________________________________
>>> Geopriv mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> cheers,
> James
> 
>                                *******************
>                 Truth is not to be argued... it is to be presented
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 12:07:44 +0000
content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 14:07:08 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Barney, Farid,

Some thoughts and comments inline.

Cheers,
	Jouni

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> Sent: 16. joulukuuta 2004 9:17
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: Re: CUI - issues addressed in version 3
>=20
> On Wed, Dec 15, 2004 at 04:47:32PM -0800, Adrangi, Farid wrote:
> >=20
> > It seems to me the advertisement capability generating more=20
> 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=20
> and simply say
> > this:
> >=20
> > "
> > In cases where the home RADIUS server cannot determine the=20
> NAS support
> > for the CUI, if the home RADIUS server requires the NAS=20
> support for CUI
> > for any reason (e.g., for billing or charging purposes),=20
> the home RADIUS
> > server MUST reject the request by sending an Access-Reject message
> > including an Error-Cause attribute [RFC3576] with value=20
> (to-be-defined)
> > (decimal), "CUI-Support-Undetermined".  Otherwise, if the=20
> authentication
> > is successful, the home RADIUS server MUST send both the=20
> User-Name (1)
> > attribute and the CUI attribute, with the understanding=20
> that if the NAS
> > supports the CUI attribute the CUI attribute will override=20
> the identity
> > portion the User-Name (1) attribute.  That is, the User-Name(1)
> > attribute will be used for routing and the CUI attribute=20
> will be used
> > for identity purposes.  When an Access-Accept without the=20
> CUI attribute
> > is received, if the NAS requires the CUI attribute to be=20
> present in the
> > Access-Accept, the NAS SHOULD treat the Access-Accept as a reject.
> > "
> >=20
> > Is this aligned with your thoughts?
>=20
> 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=20
> the routing
> problems that motivated a separate CUI.

I agree with Farid here that probably the whole advertising of CUI is
not
needed. The CUI is either required or not and the decision of requiring
CUI
should be defined by organizations utilizing CUI for their
business/deployment
models. If peer NAS/Proxy/Server doesn't understand CUI in a context of
the used
business/deployment model it should be considered broken?? (e.g that's
why
various organizations define RADIUS profiles for their use cases)
=20
> * Let's not claim that Class is unreliable, or truncated, but=20
> 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=20
> will be boxes
> upstream that suffer it.
>=20
> > > The vagueness is, I think, in whether there needs to be a 1:1=20
> > > relationship
> > > CUI<->real_user and if so over what period.  "Valid" does not=20
> > > capture the
> > > business requirement, which seems to be that the proxy/NAS=20
> > > owner demands
> > > to be able to recognize that two sessions were initiated by=20
> > > the same user,
> > > if I have understood things correctly.  Or perhaps I have it=20
> > > backwards,
> > > and the requirement is to be sure that two sessions were=20
> initiated by
> > > different users!
> >=20
> > IMO, even 1:1 relationship CUI<->real_user is also out of=20
> 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*. =20
> Standards bodies /
> > organizations like 3GPP and GSMA will be responsible for=20
> defining how
> > the CUI should be formatted and configured based on their security /
> > deployment requirements and business needs.
> > "
>=20
> 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=20
> not concerned
> with the value per se (that can always be configurable) but with its
> interpretation.  For example, if lifetime is 1 hour, does=20
> 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? =20
> Can a developer
> write a RADIUS server that will work in any application?

I really fail to see what is the problem here. CUI can change between
two authentications (or sessions how you want to see it), but should
that
be a problem? CUI may last over several RADIUS determined or user
determined sessions and the NAS/proxy should be prepared for that. CUI
is not identifying sessions per se. However, a backend billing
system may use CUI to combine several related RADIUS accounting session
into one longer "billed entity" for an user identified by CUI.

There are business/deployment models where the NAS/Proxy is required to
use CUI within the model the NAS/proxy owner wants to be part of. And
still the home network/server determines the lifetime of the CUI and the
mapping of the CUI<->real_user. Why should the NAS/proxy care about the
lifetime or mapping of the CUI -- if it just echoes CUI back or copies
CUI to some other "interoperator billing system data records" generated
in the visited network?

> If those demanding CUI have been specific enough to answer=20
> such questions,
> I've missed it.
>=20
> Barney
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 08:29:33 +0000
Date: Thu, 16 Dec 2004 00:29:02 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CUI

Farid Adrangi wrote:

"We are currently working on -03 version of the CUI draft.  Here is a
snippet on what we want to say about backward compatibility.

"
... Servers which do not understand the CUI attribute SHOULD silently
discard the attribute.

The NAS MAY include the CUI attribute with a null character for its data
field in the Access-Request message to indicate its support for this
attribute to the home RADIUS server.  In cases where home RADIUS server
cannot determine the NAS support for the CUI, if the CUI is required for
proper billing, the home RADIUS server MUST reject the request by sending
an Access-Reject message including an Error-Cause attribute [RFC3576] with
value 402 (decimal), "Missing Attribute".

Otherwise, the home RADIUS server MUST send both the UserName (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 UserName (1) attribute.  That is, the UserName(1) attribute
will be used for routing and the CUI attribute will be used for identity
purposes.
"

Before we get into developing a protocol (as suggested below) to determine
the CUI support, I would like to know why the above paragraph does not
address the backward compatibility problem."

Here are some issues with the above approach:

a. An empty CUI attribute should be used instead of an attribute with a
NUL character for the Access-Request.

b. RFC 2865 does not require servers to discard attributes they don't
understand; this is only a MAY.  So I don't think you can make discard
a SHOULD across the existing base of RADIUS servers.  That said, if the
use of CUI were restricted only to use by NASes and servers that already
support RFC 3579 and "Privacy" then such language might be more
reasonable.

c. If the RADIUS server needs information in the accounting record
why can't this be accomplished via use of the Class attribute?

d. My understanding is that the NAS is sending the empty CUI attribute in
order to signal the RADIUS Server that a CUI attribute is expected in the
Access Accept.  If this is correct, then to maintain backward
compatibility, the NAS should only signal CUI support when the
CUI is required.  For example, the NAS might only signal CUI support if
the client sends a "Privacy" NAI, and in that case (and only that case)
will the NAS treat an Accept-Accept without CUI as an Access-Reject.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 07:18:07 +0000
Date: Thu, 16 Dec 2004 02:17:23 -0500
From: Barney Wolff <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: Re: CUI - issues addressed in version 3

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 04:44:28 +0000
content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 06:42:55 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Sorry, I shouldn't operate a computer before coffee kicks in, I meant to =
say:

  The lifetime will be determined by the home network.

> > 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=20
> operator sets it
> > to y value through the dynamic configuration.
>=20
> The lifetime will be determined by the home agent.  Other SDOs are =
specifying
> values for the lifetime; however, perhaps we could could include a =
default
> value that an operator or SDO could override?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 04:33:48 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 15 Dec 2004 20:31:59 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

That's right.  I will add a line for Error-Cause attribue in the
attribute table in CUI draft -- as David proposed.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Wednesday, December 15, 2004 6:29 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: RE: backwards compatible introduction of NEW=20
> attribute such as CUI
>=20
>=20
> > RFC3576 does not indicate that the Error-Cause attribute=20
> may be used in
> > any commands other than CoA-Request, CoA-ACK and CoA-NAK.
>=20
> True, but RFC 3579 does allow the Error-Cause attribute in=20
> Access-Reject
> and Access-Challenge messages.  See Section 3.3.
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 04:33:13 +0000
content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Thu, 16 Dec 2004 06:12:51 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Farid & Barney,

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

The lifetime will be determined by the home agent.  Other SDOs are =
specifying
values for the lifetime; however, perhaps we could could include a =
default
value that an operator or SDO could override?

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 02:29:38 +0000
Date: Wed, 15 Dec 2004 18:29:12 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CUI

> RFC3576 does not indicate that the Error-Cause attribute may be used in
> any commands other than CoA-Request, CoA-ACK and CoA-NAK.

True, but RFC 3579 does allow the Error-Cause attribute in Access-Reject
and Access-Challenge messages.  See Section 3.3.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 16 Dec 2004 00:47:54 +0000
Content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Wed, 15 Dec 2004 16:47:32 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Hi Barney,
Thanks for the dialogue.  Please see my responses inline.
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Barney Wolff
> Sent: Wednesday, December 15, 2004 3:57 PM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: Re: CUI - issues addressed in version 3
>=20
>=20
> On Wed, Dec 15, 2004 at 03:18:02PM -0800, Adrangi, Farid wrote:
> >=20
> > > Issue 22 is about which party requires that CUI be present.  Given
> > > the business case claimed, it appears to be the NAS owner=20
> or proxy,
> > > not the server owner. =20
> >=20
> > 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=20
> the device
> > but rather it is required to be supported by the infrastructure as
> > driven by the business requirements.  If so, to make this=20
> clear in the
> > document, how about the following changes to the draft?=20
> >=20
> > 1) Add the following text to the end of the second=20
> paragraph in section
> > 1.1
> > "
> > The CUI support by RADIUS infrastructure is driven by the business
> > requirements between roaming entities, and hence it=20
> > should not be viewed as a technical or logical requirement for a
> > particular RADIUS device (i.e., NAS, proxy, server). =20
> > Therefore whether a RADIUS server/proxy or client accepts=20
> 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=20
> the existing
> > behavior of RFC 2865 as it states that RADIUS client or server MAY
> > ignore attributes with an unknown type.
> > "
> >=20
> > 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."
> >=20
> > Hope this provides a resolution to this both issue 21 and=20
> 22 -- if not,
> > please let me know. =20
> >=20
> > > 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.
>=20
> 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.
>=20

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=20
> > > 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?
> > >=20
> >=20
> > Maybe.  In general, I think how CUI is configured and=20
> formatted will be
> > determined by business decisions.  If so, how about we revise the
> > following paragraph in section 2.1 as below?
> >=20
> > Current paragraph:
> > "
> > The length of time for which the CUI is valid is outside of=20
> the scope of
> > this specification.  It is assumed to be deployment=20
> related.  It should
> > typically be long enough to serve some business needs and=20
> short enough
> > such that it minimizes the chance of revealing the true=20
> identity of the
> > user (either directly or indirectly).
> > "
> >=20
> > Revised paragraph:
> > "
> > The length of time for which the CUI is valid is outside of=20
> 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=20
> defining how
> > the CUI should be formatted and configured based on their=20
> security and
> > deployment requirements and business needs."
>=20
> The vagueness is, I think, in whether there needs to be a 1:1=20
> relationship
> CUI<->real_user and if so over what period.  "Valid" does not=20
> capture the
> business requirement, which seems to be that the proxy/NAS=20
> owner demands
> to be able to recognize that two sessions were initiated by=20
> the same user,
> if I have understood things correctly.  Or perhaps I have it=20
> backwards,
> and the requirement is to be sure that two sessions were initiated by
> different users!
>=20

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=20
> no guidance
> on what to do here.  Nor would it be pleasant if different=20
> standards bodies
> or worse, different NAS/proxy owners, came to different=20
> decisions on the
> required time period.  Does the server have enough information in the
> request to make the right choice?
>=20

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
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 23:56:56 +0000
Date: Wed, 15 Dec 2004 18:56:38 -0500
From: Barney Wolff <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
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.

> > 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 23:18:36 +0000
Content-class: urn:content-classes:message
Subject: RE: CUI - issues addressed in version 3
Date: Wed, 15 Dec 2004 15:18:02 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

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

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

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

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?=20

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=20
should not be viewed as a technical or logical requirement for a
particular RADIUS device (i.e., NAS, proxy, server). =20
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. =20

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

> Finally, the draft's advice on the lifetime of a CUI seems a=20
> 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?
>=20

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
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 21:21:18 +0000
From: Avi Lior <[email-masked]>
To: "'Congdon, Paul T (ProCurve)'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Wed, 15 Dec 2004 16:21:06 -0500

I belive yes it would be an interoperability issue.

> -----Original Message-----
> From: Congdon, Paul T (ProCurve) [mailto:[email-masked]] 
> Sent: Tuesday, December 14, 2004 6:20 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: RE: Issue 37: Merging of Filter Attributes
> 
> 
> 
> Would there be an interoperability issue if it was specified 
> that they can't re-order these, even though they are 
> different types?  Sounds like RFC 2865 only puts the re-order 
> restriction on attributes of the same type.
> 
> Paul
> 
> > -----Original Message-----
> > From: Bernard Aboba [mailto:[email-masked]]
> > Sent: Tuesday, December 14, 2004 3:16 PM
> > To: Congdon, Paul T (ProCurve)
> > Cc: [email-masked]
> > Subject: RE: Issue 37: Merging of Filter Attributes
> > 
> > I think the issue here is that RADIUS proxies could re-order
> > Filter-Id and NAS-Filter-Rule attributes relative to each other.
> > 
> > On Tue, 14 Dec 2004, Congdon, Paul T (ProCurve) wrote:
> > 
> > >
> > > I agree that if both of these attributes appear in the 
> packet, they
> > > should append one another.  Given that order is important 
> > (as seen in
> > > Issue 38), why wouldn't we want to indicate that a
> > NAS-Filter-Rule can
> > > also pre-pend the Filter-ID if it appears before the 
> Filter-ID?  It
> > > seems kind of limiting to only allow NAS-Filter-Rule to 
> follow the 
> > > Filter-ID.
> > >
> > > Consider the following text...
> > >
> > > "If both Filter-ID and NAS-Filter-Rule attributes are
> > included within
> > > an Access-Request or Access-Accept packet, the filters are
> > appended to
> > > one another.  If the filter specified by the
> > NAS-Filter-Rule attribute
> > > appears after the filter list specified by the Filter-ID 
> attribute,
> > > the filter is considered to be appended to the end of the 
> > filter list.
> > > If the filter specified by the NAS-Filter-Rule attribute appears
> > > before the filter list specified by the Filter-ID attribute, the 
> > > filter is pre-pended to the filter list.
> > >
> > > As a result, if either of the filters specify that a packet
> > is to be
> > > discarded, then the filter(s) specified by the other attribute can
> > > have no effect on the processing of that packet."
> > >
> > > Paul
> > 
> 
> --
> to unsubscribe send a message to 
> [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 20:46:43 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, [email-masked]
Cc: "'Beck01, Wolfgang'" <[email-masked]>
Subject: Table of attributes was issue 7:
Date: Wed, 15 Dec 2004 15:46:38 -0500

Missing table of attributes.

I agree with you Bernard.

I did mention this to Wolfgang and provided straw man table.  Having the
table is important because the are different conditions when attributes are
required in the various messages.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 20:41:07 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Wed, 15 Dec 2004 15:40:48 -0500

I agree with you David.

If CUI calls out for Error-Cause then we should put it in the table of
attributes.
  
> As to whether the inclusion of Error-Cause or some other form 
> of missing attribute indication in RADIUS Access-Reject 
> messages should be used as the basis of specifying a general 
> RADIUS capabilities negotiation protocol, IMHO, that's a 
> whole other matter.

Sure.

But Farid and I are leaning away from the need for having a capability
negotiation for CUI. See the latest thread.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 19:04:51 +0000
Date: Wed, 15 Dec 2004 14:03:42 -0500
From: Barney Wolff <[email-masked]>
To: Lothar Reith <[email-masked]>
Cc: "'Adrangi, Farid'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: CUI issue 22 (was AW: CUI - issues addressed in version 3

On Wed, Dec 15, 2004 at 12:13:45PM +0100, Lothar Reith wrote:
> Barney wrote:Adrangi, Farid
> 
> 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.  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.
> 
> Lothar:
> Interesting proposal to turn the whole logic upside down, but I tend to
> disagree.
> 
> Justification:
> 1) It is unclear how a NAS owner or Proxy can determine this "requirement".
> I say in some scenarious it is impossible, leading to an "always advertise"
> because the NAS owner "MAY require presence of CUI but cannot determine if
> he requires presence of CUI".

If the NAS owner or proxy owner doesn't know, how does the server owner?
See my response to 2.

> 2) it is unclear what Barney means with "presence of CUI". It could mean the
> NAS owner requires "presence of CUI in the Access-Accept", whereas the
> Server requires "presence of CUI in the RADIUS accounting messages". The
> whole backwards compatibility discussion is about these two presences not
> being the same thing, and about how the server can be assured that a CUI
> presented downstream to the NAS will also be presented upstream in the
> accounting messages. 

The server owner *never* needs CUI to know who the real user is.  The
server can always use Class.

> 3) it appears to me that a differing interpretation of the word "require"
> may be the root cause for Barney's perception that it is primarily the NAS
> owner who *requires* CUI presence. 
> 
> We have to ask ourself what Barney meant when stating "require that CUI be
> present".  Is it a "require to increase revenue" - or a "require to avoid
> loss", also is he talking about CUI presence in the Accept or CUI presence
> in the accounting messages or both.

I'm basing my inference that it's the NAS/proxy owner who has the requirement
on Blair Bullock's spirited defense of CUI.  He's iPass, I believe.

A NAS or proxy owner who gets CUI in the Accept can always ensure that it's
present in accounting requests - the NAS directly and the proxy by using
Class if necessary.

> In the roaming privacy application of CUI, the NAS owner requires CUI to
> make money from an inroaming privacy roamer. If he does not support or
> advertise CUI he may loose top line revenue, but he does not incur a bottom
> line damage because he just rejects the potential customer. End of story. No
> hard damage occured, except a soft damage of loosing potential revenue.

This is simply not true, no matter how often it's asserted.  You can't tell
me that the NAS owner is going to bill the actual user directly, *because
CUI has already been conceded to be an alias*.  The NAS owner is going to
bill the proxy owner, and the proxy owner is going to bill the home server
owner, who may or may not bill the actual user.

> For the Home Server, it is a much stronger requirement to have assurance of
> CUI Support when accepting (to pay for) the usage of a privacy roamer. If it
> turns out the NAS did not support CUI than he incurs a bottom line hard
> damage, because he has to pay the NAS-owner anyway for the usage that he
> authorized, but has no means to charge it back to the user.
>
> In summary: I beleive the only one who has a *strong requirement* for CUI
> presence *in the accounting messages* is the server.

No - see my response to 2 above.

> I agree thought with Barney's business case view, that the NAS owner in a
> hotspot requires CUI presence to be able to serve privacy roaming customers.
> But there is no issue with that "requirement", as the NAS owner is in full
> control of his destiny, if he wants to increase revenue by serving privacy
> roamers, he may just  "always advertise CUI" or "advertise CUI as determined
> to be required".

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

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 16:22:09 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 15 Dec 2004 11:21:14 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

A postscript ...

> In the absence of any RFC that
> includes the Error-Cause attribute in an "attribute usage table" that
> includes the traditional RADIUS Access-* commands, such usage is
> speculative, and non-standardized.

RFC3580 (also Informative) does indicate that the Error-Cause attribute
may appear in RADIUS messages used for 802.1X authentication and
authorization, without further describing how it is to be used.  It
apparently leaves the definition in RFC3576 unmodified.  This may be a
"foot in the door"...

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 16:09:30 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 15 Dec 2004 11:08:35 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> 3576 supports missing attribute indication.

Let's talk about RFC3576.

Section 1.1 Applicability says, in part:

   This protocol is being recommended for publication as an
   Informational RFC rather than as a standards-track RFC because of
   problems that cannot be fixed without creating incompatibilities with
   deployed implementations.  This includes security vulnerabilities, as
   well as semantic ambiguities resulting from the design of the
   Change-of-Authorization (CoA) commands.  While fixes are recommended,
   they cannot be made mandatory since this would be incompatible with
   existing implementations.

RFC3576 is an Informational document that was created without any IETF
Working Group review (it came into existence between the RADIUS and
RADEXT working group timeframes).

Given the RADEXT WG charter requirement to maintain backwards
compatibility, and assuming that document conflicts would be resolved in
favor of the Standards Track document over the Informational document,
we may need to look at the applicability and backwards compatibility
properties of attributes and commands from RFC3576 somewhat more
carefully, in proposing them as solutions to current RADEXT issues.

RFC3576 does not indicate that the Error-Cause attribute may be used in
any commands other than CoA-Request, CoA-ACK and CoA-NAK.  Nor does it
explicitly prohibit their use in other commands, such as Access-Request,
Access-Challenge, Access-Accept or Access-Reject.  It remains silent on
that matter, but given that RFC3576 avoids any attempt to update or
modify RFC2865, that seems appropriate.   In the absence of any RFC that
includes the Error-Cause attribute in an "attribute usage table" that
includes the traditional RADIUS Access-* commands, such usage is
speculative, and non-standardized.

That doesn't mean we can't re-use the Error-Cause attribute here, but it
does, IMHO, mean that the CUI document would need to explicitly call out
the allowed inclusion of the Error-Cause attribute in RADIUS
Access-Request, Access-Challenge, Access-Accept or Access-Reject
commands, in an appropriate "attribute usage table".

I guess I should submit this as a RADEXT Issue against the CUI draft.
I'll make a note to do that...

As to whether the inclusion of Error-Cause or some other form of missing
attribute indication in RADIUS Access-Reject messages should be used as
the basis of specifying a general RADIUS capabilities negotiation
protocol, IMHO, that's a whole other matter.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 15:42:55 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 15 Dec 2004 10:41:28 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> So make the advertizement a MUST or a SHOULD.  MAY maybe useless here.
> But perhaps I missed some discussion on this issue.

In RADEXT Issue 35, I suggest the use of SHOULD.  Others have
subsequently suggested the use of MUST.  I would not have any objection
to MUST.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 13:53:00 +0000
Date: Wed, 15 Dec 2004 05:52:28 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: Re: CUI - issues addressed in version 3

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

Looking through the mailing list, it appears your doubts were shared by
others, and therefore the issues you raised will need to be resolved for
this document to proceed.

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

Backward compatibility is a requirement of the RADEXT WG charter.  In the
case of documents that modify existing behavior rather than adding
totally new functionality, this boils down to whether existing RADIUS servers
behave the way that the draft wishes them to.  A survey of existing
implementations would appear to be required.

Assuming that it can be shown that the draft is backward compatible with
existing implementations, then I don't think RFC 2865 needs to be
modified.  It's just that the MAY is widely implemented.

If existing RADIUS servers *don't* behave that way, then the WG has a
major task ahead of it in introducing this (and other) new functionality,
because we are saying that RADIUS servers that could interact
with a NAS with CUI support need to be upgraded.

Note that a key question is the population of RADIUS servers that
need to be upgraded -- the scope of applicability of CUI. For example, if
the scope of CUI were limited to use with a package of significant new
functionality, or a block of older functionality, where it could be
demonstrated that existing RADIUS servers implementing that
functionality behave as desired.

In this particular case, the need for CUI appears to arise from "Privacy",
a feature that is only supported within EAP, but not within other forms of
access (VPN, Dialup, etc.) So it looks to me like we're only talking about
RADIUS servers supporting RFC 3579.

If this is the case, then it might be sufficient to demonstrate that
RADIUS servers supporting RFC 3579 and perhaps RFC 3580 behave as desired.
This is a different thing from demonstrating that all RADIUS servers supporting
RFC 2865 and 2866 behave as desired, since that would include RADIUS
servers only used for Dialup Access, installed in 1995, and using the old
Livingston code base.  RADIUS servers in that kind of deployment aren't
likely to be upgraded soon :)

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

Another issue is *when* CUI is required to be present.  My understanding
was that CUI was only required where user privacy was being used.
Otherwise, the User-Name attribute could be used instead.  If so, we're
restricting the use of CUI to a potential set of RADIUS servers
that might be more likely to be backward compatible, since we could be
requiring RFC 3579, 3580 *and* privacy support.

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 11:14:22 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Barney Wolff'" <[email-masked]>, "'Adrangi, Farid'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: CUI issue 22 (was AW: CUI - issues addressed in version 3
Date: Wed, 15 Dec 2004 12:13:45 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E297.24716CAE
Content-Type: text/plain

Barney wrote:Adrangi, Farid

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

Lothar:
Interesting proposal to turn the whole logic upside down, but I tend to
disagree.

Justification:
1) It is unclear how a NAS owner or Proxy can determine this "requirement".
I say in some scenarious it is impossible, leading to an "always advertise"
because the NAS owner "MAY require presence of CUI but cannot determine if
he requires presence of CUI".

2) it is unclear what Barney means with "presence of CUI". It could mean the
NAS owner requires "presence of CUI in the Access-Accept", whereas the
Server requires "presence of CUI in the RADIUS accounting messages". The
whole backwards compatibility discussion is about these two presences not
being the same thing, and about how the server can be assured that a CUI
presented downstream to the NAS will also be presented upstream in the
accounting messages. 

3) it appears to me that a differing interpretation of the word "require"
may be the root cause for Barney's perception that it is primarily the NAS
owner who *requires* CUI presence. 

We have to ask ourself what Barney meant when stating "require that CUI be
present".  Is it a "require to increase revenue" - or a "require to avoid
loss", also is he talking about CUI presence in the Accept or CUI presence
in the accounting messages or both.

In the roaming privacy application of CUI, the NAS owner requires CUI to
make money from an inroaming privacy roamer. If he does not support or
advertise CUI he may loose top line revenue, but he does not incur a bottom
line damage because he just rejects the potential customer. End of story. No
hard damage occured, except a soft damage of loosing potential revenue.

For the Home Server, it is a much stronger requirement to have assurance of
CUI Support when accepting (to pay for) the usage of a privacy roamer. If it
turns out the NAS did not support CUI than he incurs a bottom line hard
damage, because he has to pay the NAS-owner anyway for the usage that he
authorized, but has no means to charge it back to the user.

In summary: I beleive the only one who has a *strong requirement* for CUI
presence *in the accounting messages* is the server.

I agree thought with Barney's business case view, that the NAS owner in a
hotspot requires CUI presence to be able to serve privacy roaming customers.
But there is no issue with that "requirement", as the NAS owner is in full
control of his destiny, if he wants to increase revenue by serving privacy
roamers, he may just  "always advertise CUI" or "advertise CUI as determined
to be required".

Lothar

this email was sent as text only, if still received as HTML please let me
know.

------_=_NextPart_001_01C4E297.24716CAE
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>CUI issue 22 (was AW: CUI - issues addressed in version =
3</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Barney wrote:Adrangi, Farid</FONT>
</P>

<P><FONT SIZE=3D2>Issue 22 is about which party requires that CUI be =
present.&nbsp; Given the business case claimed, it appears to be the =
NAS owner or proxy, not the server owner.&nbsp; If that's so, the =
draft's suggestions on how to indicate support for CUI seem =
backwards.&nbsp; If the NAS or a proxy</FONT></P>

<P><FONT SIZE=3D2>*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.</FONT></P>

<P><FONT SIZE=3D2>Lothar:</FONT>
<BR><FONT SIZE=3D2>Interesting proposal to turn the whole logic upside =
down, but I tend to disagree.</FONT>
</P>

<P><FONT SIZE=3D2>Justification:</FONT>
<BR><FONT SIZE=3D2>1) It is unclear how a NAS owner or Proxy can =
determine this &quot;requirement&quot;. I say in some scenarious it is =
impossible, leading to an &quot;always advertise&quot; because the NAS =
owner &quot;MAY require presence of CUI but cannot determine if he =
requires presence of CUI&quot;.</FONT></P>

<P><FONT SIZE=3D2>2) it is unclear what Barney means with =
&quot;presence of CUI&quot;. It could mean the NAS owner requires =
&quot;presence of CUI in the Access-Accept&quot;, whereas the Server =
requires &quot;presence of CUI in the RADIUS accounting messages&quot;. =
The whole backwards compatibility discussion is about these two =
presences not being the same thing, and about how the server can be =
assured that a CUI presented downstream to the NAS will also be =
presented upstream in the accounting messages. </FONT></P>

<P><FONT SIZE=3D2>3) it appears to me that a differing interpretation =
of the word &quot;require&quot; may be the root cause for Barney's =
perception that it is primarily the NAS owner who *requires* CUI =
presence. </FONT></P>

<P><FONT SIZE=3D2>We have to ask ourself what Barney meant when stating =
&quot;require that CUI be present&quot;.&nbsp; Is it a &quot;require to =
increase revenue&quot; - or a &quot;require to avoid loss&quot;, also =
is he talking about CUI presence in the Accept or CUI presence in the =
accounting messages or both.</FONT></P>

<P><FONT SIZE=3D2>In the roaming privacy application of CUI, the NAS =
owner requires CUI to make money from an inroaming privacy roamer. If =
he does not support or advertise CUI he may loose top line revenue, but =
he does not incur a bottom line damage because he just rejects the =
potential customer. End of story. No hard damage occured, except a soft =
damage of loosing potential revenue.</FONT></P>

<P><FONT SIZE=3D2>For the Home Server, it is a much stronger =
requirement to have assurance of CUI Support when accepting (to pay =
for) the usage of a privacy roamer. If it turns out the NAS did not =
support CUI than he incurs a bottom line hard damage, because he has to =
pay the NAS-owner anyway for the usage that he authorized, but has no =
means to charge it back to the user.</FONT></P>

<P><FONT SIZE=3D2>In summary: I beleive the only one who has a *strong =
requirement* for CUI presence *in the accounting messages* is the =
server.</FONT></P>

<P><FONT SIZE=3D2>I agree thought with Barney's business case view, =
that the NAS owner in a hotspot requires CUI presence to be able to =
serve privacy roaming customers. But there is no issue with that =
&quot;requirement&quot;, as the NAS owner is in full control of his =
destiny, if he wants to increase revenue by serving privacy roamers, he =
may just&nbsp; &quot;always advertise CUI&quot; or &quot;advertise CUI =
as determined to be required&quot;.</FONT></P>
<BR>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

<P><FONT SIZE=3D2>this email was sent as text only, if still received =
as HTML please let me know.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E297.24716CAE--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 15 Dec 2004 08:17:46 +0000
Date: Wed, 15 Dec 2004 03:16:58 -0500
From: Barney Wolff <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
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.

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

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:58:59 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 14 Dec 2004 15:57:00 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Lothar Reith" <[email-masked]>, "Nelson, David" <[email-masked]>, "Barney Wolff" <[email-masked]>, "Congdon, Paul T \(ProCurve\)" <[email-masked]>

Interesting discussion!   Going forward, we agree that we should avoid
any solution that makes RADIUS more stateful.  That said, there seems to
be three viable options for handling backward compatibility in CUI
draft:

1) NAS always advertises CUI support

Then, we can simply replace the first sentence of the second paragraph
in section 2.1 with the following:

"
If the NAS supports CUI, it MUST include the CUI attribute with a null
character for its data field in the Access-Request message to indicate
its support for this attribute to the home RADIUS server.=20
"

Note: BTW,
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-exte
nsion-01.txt, section 2.2, introduces a solution for general capability
advertisement support for RADIUS.   =20

2) NAS may advertise CUI support (optional - implementation dependent)

The current text (i.e., second paragraph in section 2.1) in version -03
should suffice.

3) NAS never advertises CUI support=20

Then, we can simply remove the the first sentence of the second
paragraph in section 2.1.=20

Please also note that in options (2) and (3), the home RADIUS server may
have some other reliable methods to determine the NAS support for CUI.
But such methods or mechanisms are out of scope.

I'd prefer (2) or (3).  Your thoughts?

Farid

  =20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Congdon,=20
> Paul T (ProCurve)
> Sent: Tuesday, December 14, 2004 11:24 AM
> To: Barney Wolff
> Cc: Lothar Reith; Nelson, David; [email-masked]
> Subject: RE: backwards compatible introduction of NEW=20
> attribute such as CUI
>=20
>=20
>=20
> These are all good points... If the overhead isn't that significant to
> advertise each time, then I agree that the stateless benefits outweigh
> this potential optimization.
>=20
> Paul=20
>=20
> > -----Original Message-----
> > From: Barney Wolff [mailto:[email-masked]]=20
> > Sent: Tuesday, December 14, 2004 9:37 AM
> > To: Congdon, Paul T (ProCurve)
> > Cc: Lothar Reith; Nelson, David; [email-masked]
> > Subject: Re: backwards compatible introduction of NEW=20
> > attribute such as CUI
> >=20
> > On Tue, Dec 14, 2004 at 09:04:32AM -0800, Congdon, Paul T=20
> > (ProCurve) wrote:
> > > =20
> > > Instead of sending these 'advertised' attributes in every=20
> > Access-Request, why doesn't a NAS send a single=20
> > Access-Request for itself that advertises all the things it=20
> > needs to advertise once.  This 'self generated'=20
> > Access-Request could occur at start-up time or anytime=20
> > configuration changes such that new things need to be=20
> > advertised.  Perhaps a new attribute like 'NAS registration'=20
> > would be required to be included, followed by a list of=20
> > 'advertised' capabilities that the AS would 'remember' for this NAS.
> >=20
> > A while back, I said "keeping state is a terrible idea" and=20
> > didn't bother to explicate further.  This is why.  How is the=20
> > NAS to know when the server has rebooted or otherwise lost=20
> > state and the NAS needs to refresh it?
> >=20
> > Futhermore, in a proxy situation, which is how most things=20
> > seem to be run these days, how would the registration get to=20
> > the servers that need it?
> >=20
> > I'm firmly in the KISS camp, for RADIUS.  Diameter/RADIUS >>=20
> > 2 and let's keep it that way.
> >=20
> > Barney Wolff
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:26:25 +0000
Content-class: urn:content-classes:message
Subject: Radius Extensions for IEEE 802 design team phone call
Date: Tue, 14 Dec 2004 15:25:39 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: <[email-masked]>

I'd like to host some phone calls to discuss resolution of issues and to
progress the draft.  The first call will be Tuesday, December 21st at
8:00AM Pacific Time.  Dial-in parameters will be forthcoming.  Please
email me if you are interested in participating.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-02.txt

Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:20:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 14 Dec 2004 15:19:36 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

Would there be an interoperability issue if it was specified that they
can't re-order these, even though they are different types?  Sounds like
RFC 2865 only puts the re-order restriction on attributes of the same
type.

Paul

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]=20
> Sent: Tuesday, December 14, 2004 3:16 PM
> To: Congdon, Paul T (ProCurve)
> Cc: [email-masked]
> Subject: RE: Issue 37: Merging of Filter Attributes
>=20
> I think the issue here is that RADIUS proxies could re-order=20
> Filter-Id and NAS-Filter-Rule attributes relative to each other.
>=20
> On Tue, 14 Dec 2004, Congdon, Paul T (ProCurve) wrote:
>=20
> >
> > I agree that if both of these attributes appear in the packet, they=20
> > should append one another.  Given that order is important=20
> (as seen in=20
> > Issue 38), why wouldn't we want to indicate that a=20
> NAS-Filter-Rule can=20
> > also pre-pend the Filter-ID if it appears before the Filter-ID?  It=20
> > seems kind of limiting to only allow NAS-Filter-Rule to follow the=20
> > Filter-ID.
> >
> > Consider the following text...
> >
> > "If both Filter-ID and NAS-Filter-Rule attributes are=20
> included within=20
> > an Access-Request or Access-Accept packet, the filters are=20
> appended to=20
> > one another.  If the filter specified by the=20
> NAS-Filter-Rule attribute=20
> > appears after the filter list specified by the Filter-ID attribute,=20
> > the filter is considered to be appended to the end of the=20
> filter list. =20
> > If the filter specified by the NAS-Filter-Rule attribute appears=20
> > before the filter list specified by the Filter-ID attribute, the=20
> > filter is pre-pended to the filter list.
> >
> > As a result, if either of the filters specify that a packet=20
> is to be=20
> > discarded, then the filter(s) specified by the other attribute can=20
> > have no effect on the processing of that packet."
> >
> > Paul
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:15:52 +0000
Date: Tue, 14 Dec 2004 15:15:40 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
cc: [email-masked]
Subject: RE: Issue 37: Merging of Filter Attributes

I think the issue here is that RADIUS proxies could re-order Filter-Id and
NAS-Filter-Rule attributes relative to each other.

On Tue, 14 Dec 2004, Congdon, Paul T (ProCurve) wrote:

>
> I agree that if both of these attributes appear in the packet, they
> should append one another.  Given that order is important (as seen in
> Issue 38), why wouldn't we want to indicate that a NAS-Filter-Rule can
> also pre-pend the Filter-ID if it appears before the Filter-ID?  It
> seems kind of limiting to only allow NAS-Filter-Rule to follow the
> Filter-ID.
>
> Consider the following text...
>
> "If both Filter-ID and NAS-Filter-Rule attributes are included within an
> Access-Request or Access-Accept packet, the filters are appended to one
> another.  If the filter specified by the NAS-Filter-Rule attribute
> appears after the filter list specified by the Filter-ID attribute, the
> filter is considered to be appended to the end of the filter list.  If
> the filter specified by the NAS-Filter-Rule attribute appears before the
> filter list specified by the Filter-ID attribute, the filter is
> pre-pended to the filter list.
>
> As a result, if either of the filters specify that a packet is to be
> discarded, then the filter(s) specified by the other attribute can have
> no effect on the processing of that packet."
>
> Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:15:07 +0000
From: Avi Lior <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Tue, 14 Dec 2004 18:14:56 -0500

3576 supports missing attribute indication. The suggestion is not to =
have
something too specific such as missing CUI but more specific then =
missing
attribute.?=20

I fail to see, in the scope of Error-Cause what we would create that is
between missing cui and missing attribute.

I also have an issue with this.  If we send this new attribute back =
wouldn't
the RADIUS server have to recognize it. Only a compatible RADIUS Server
would be able to recognize this new attribute.=20

Also based on this text it seems to me in cases where CUI is needed by =
the
server we require the Client to send the CUI -- otherwise if the client
didn't send the CUI the request will be rejected.

So make the advertizement a MUST or a SHOULD.  MAY maybe useless here.  =
But
perhaps I missed some discussion on this issue.
=A0
> > > "
> > > ... Servers which do not understand the CUI attribute SHOULD
> > > silently discard the attribute.
> > >=A0
> > > The NAS MAY include the CUI attribute with a null=20
> character for its
> > > data field in the Access-Request message to indicate its=20
> > support for
> > > this attribute to the home RADIUS server.=A0 In cases where home
> > > RADIUS=A0server cannot determine the NAS support for the=20
> CUI, if the=20
> > > CUI is=A0required for proper billing, the home RADIUS server MUST =

> > > reject the=A0request by sending an Access-Reject message=20
> including an=20
> > > Error-Cause=A0attribute [RFC3576] with value 402 (decimal),=20
> "Missing=20
> > > Attribute".
> >=20
> > DBN:  Would it be preferable to create a new value of
> > Error-Cause to more specifically describe the=20
> > incompatibility?  While Missing-CUI might be too specific,=20
> > Missing Attribute is quite broad.
> >=20
>=20
> Yes, it would be.  I need to check RFC 3576 to find out the=20
> procedure for adding a new value to the Error-Cause. =20

Also please note the User-Name is not the only thing that is used for
routing requests in RADIUS.  We keep forgetting this in the text.  Here =
are
some snippets from 2865.

Alternatively, the choice of which
   server receives the forwarded request MAY be based on whatever other
   criteria the forwarding server is configured to use, such as Called-
   Station-Id (a "numbered realm").

Finally, User-Name is not required in an access-request and this RFC =
should
not change that.

We can for example have cause to use Called-Station-Id and CUI. So lets =
not
break existing deployements that could use CUI that don't use =
User-Name.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:10:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 38: Ordering of filter attributes
Date: Tue, 14 Dec 2004 15:10:00 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This makes sense to me.  I wonder if the relationship with Filter-ID
should also be mentioned here.=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, December 13, 2004 6:49 PM
> To: [email-masked]
> Subject: Issue 38: Ordering of filter attributes
>=20
> Issue 38: Ordering of Filter Attributes
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: December 13, 2004
> Reference:
> Document: Congdon-02
> Comment type: T
> Priority: S
> Section: 2.7
> Rationale/Explanation of issue:
> Section 2.7 does not state that NAS-Filter-Rule attributes=20
> shouldn't be reordered by RADIUS proxies. Since reordering=20
> can change the meaning of filter lists, reordering cannot be allowed.
>=20
> The addition of the following text is recommended:
>=20
> "If multiple NAS-Filter-Rule attributes are contained within=20
> an Access-Request or Access-Accept packet they MUST be in=20
> order and they MUST be consecutive attributes in the packet.=20
> RADIUS proxies MUST NOT reorder NAS-Filter-Rule attributes.
>=20
> The RADIUS server can return NAS-Filter-Rule attributes in an=20
> Access-Accept packet. Where more than one NAS-Filter-Rule=20
> attribute is included, it is assumed that the attributes are=20
> to be concatenated to form a single filter list."
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 23:09:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 14 Dec 2004 15:08:18 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

I agree that if both of these attributes appear in the packet, they
should append one another.  Given that order is important (as seen in
Issue 38), why wouldn't we want to indicate that a NAS-Filter-Rule can
also pre-pend the Filter-ID if it appears before the Filter-ID?  It
seems kind of limiting to only allow NAS-Filter-Rule to follow the
Filter-ID.

Consider the following text...

"If both Filter-ID and NAS-Filter-Rule attributes are included within an
Access-Request or Access-Accept packet, the filters are appended to one
another.  If the filter specified by the NAS-Filter-Rule attribute
appears after the filter list specified by the Filter-ID attribute, the
filter is considered to be appended to the end of the filter list.  If
the filter specified by the NAS-Filter-Rule attribute appears before the
filter list specified by the Filter-ID attribute, the filter is
pre-pended to the filter list.

As a result, if either of the filters specify that a packet is to be
discarded, then the filter(s) specified by the other attribute can have
no effect on the processing of that packet."

Paul

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, December 13, 2004 6:46 PM
> To: [email-masked]
> Subject: Issue 37: Merging of Filter Attributes
>=20
> Issue 37: Merging of Filter Attributes
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked] Date first=20
> submitted: December 13, 2004
> Reference:
> Document: Congdon-02
> Comment type: T
> Priority: S
> Section: 2.7
> Rationale/Explanation of issue:
> Section 2.7 does not state what happens if both Filter-ID and=20
> NAS-Filter-Rule attributes are included in an Access-Accept.
> How are the filters merged?
>=20
> Suggest the addition of the following text:
>=20
> "If both Filter-ID and NAS-Filter-Rule attributes are=20
> included within an Access-Request or Access-Accept packet,=20
> the filter specified by the NAS-Filter-Rule attribute is=20
> considered to be appended to the end of the filter list=20
> specified by the Filter-ID attribute.
>=20
> As a result, if the Filter-ID attribute specifies that a=20
> packet is to be discarded, then the filter specified by=20
> NAS-Filter-Rule can have no effect on the processing of that=20
> packet, since it will have already been discarded prior to=20
> examination by the filter specified in NAS-Filter-Rule."
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 19:38:40 +0000
Content-class: urn:content-classes:message
Subject: RE: open issues of draft-ietf-radext-digest-auth-00
Date: Tue, 14 Dec 2004 14:37:26 -0500
From: "Nelson, David" <[email-masked]>
To: "Wolfgang Beck" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> Issue 7
>=20
> My interpretation of the list discussion was that the consensus was to
> make
> the Message-Authenticator mandatory. I'll copy the relevant parts
> of section 3.1 and 3.2 of RfC3579, as Bernard proposed.
>=20
> I don't think that integrity protection of Access-Requests is really
> a big issue. Carrying HTTP Digest over unprotected RADIUS can't be
> worse than carrying it over unprotected HTTP or SIP. Digest-HA1 is the
> only
> exception, because a MITM can 'sign' arbitrary HTTP-style responses.
> Here is a proposal:
> - Message-Authenticator is optional
> - Digest-HA1 MUST be encrypted like User-Password, using a shared key.
> That means, Digest-HA1 can be used with MD5, AKAv1-MD5; reliance
> on IPSec is no longer needed (the requirement remains with sips /
> https where all attributes would have to be encrypted).

It may be confusion on my part, but it seems to me that the two
paragraphs above say different and conflicting things.  The first
paragraph says "Make inclusion of the Message-Authenticator attribute
mandatory within the scope of the Digest-Auth draft".  The second
paragraph says "Make the inclusion of Message-Authenticator optional
within the scope of the Digest-Auth draft, and specify an encrypted form
of the Digest-HA1 attribute".

Which is the resolution that will appear in the next revision of the
Digest-Auth draft?  If the WG has reached consensus on the first
paragraph, isn't that what must be chosen?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 19:24:53 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 14 Dec 2004 11:23:50 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Lothar Reith" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

These are all good points... If the overhead isn't that significant to
advertise each time, then I agree that the stateless benefits outweigh
this potential optimization.

Paul=20

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20
> Sent: Tuesday, December 14, 2004 9:37 AM
> To: Congdon, Paul T (ProCurve)
> Cc: Lothar Reith; Nelson, David; [email-masked]
> Subject: Re: backwards compatible introduction of NEW=20
> attribute such as CUI
>=20
> On Tue, Dec 14, 2004 at 09:04:32AM -0800, Congdon, Paul T=20
> (ProCurve) wrote:
> > =20
> > Instead of sending these 'advertised' attributes in every=20
> Access-Request, why doesn't a NAS send a single=20
> Access-Request for itself that advertises all the things it=20
> needs to advertise once.  This 'self generated'=20
> Access-Request could occur at start-up time or anytime=20
> configuration changes such that new things need to be=20
> advertised.  Perhaps a new attribute like 'NAS registration'=20
> would be required to be included, followed by a list of=20
> 'advertised' capabilities that the AS would 'remember' for this NAS.
>=20
> A while back, I said "keeping state is a terrible idea" and=20
> didn't bother to explicate further.  This is why.  How is the=20
> NAS to know when the server has rebooted or otherwise lost=20
> state and the NAS needs to refresh it?
>=20
> Futhermore, in a proxy situation, which is how most things=20
> seem to be run these days, how would the registration get to=20
> the servers that need it?
>=20
> I'm firmly in the KISS camp, for RADIUS.  Diameter/RADIUS >>=20
> 2 and let's keep it that way.
>=20
> Barney Wolff
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Envelope-to: [email-masked]
Delivery-date: Tue, 14 Dec 2004 18:10:08 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Issue 38: Ordering of filter attributes 
Date: Tue, 14 Dec 2004 13:21:38 -0500
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> Rationale/Explanation of issue:
> Section 2.7 does not state that NAS-Filter-Rule attributes shouldn't
> be reordered by RADIUS proxies. Since reordering can change the
> meaning of filter lists, reordering cannot be allowed.

  RFC 2865, Section 2.3 "Proxy", page 10:

---
   We now examine each step in more detail.
   ...
      ...                                             The forwarding
      server MUST NOT change the order of any attributes of the same
      type, including Proxy-State.
---

  Is this not already covered in the base RADIUS spec?

  I'm not opposing the idea that the text be included, though.  Maybe
a re-emphasis of RFC 2865 would be useful:

  "As per the requirements of RFC 2865, Section 2.3, if multiple
   NAS-Filter-Rule attributes are contained within an Access-Request
   or Access-Accept packet, they MUST be maintained in order.  The
   attributes MUST be consecutive attributes in the packet. RADIUS
   proxies MUST NOT reorder NAS-Filter-Rule attributes."

  The requirement that the attributes must be consecutive is not
covered by the general comments on attributes in RFC 2865, and should
be in a separate sentence from the ordering requirement.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:48:51 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Tue, 14 Dec 2004 18:46:54 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E204.E679DB4E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,

I agree that introducing a policy of "always advertise a capability
attribute"  has it's own issues, as you and Barney pointed out it =
requires
the server and/or the intermediary to keep state of NAS capabilities.

This may not scale well in a WLAN roaming scenario with intermediaries, =
as
it requires the intermediary to keep track of NAS capabilities and to =
proxy
this capability advertisement to all potential Servers when the =
capability
advertisement message is received, and to keep state in order to sync =
up a
Server which went down and came back online.=20

All servers with customers subscribed to roaming capability will =
receive
capability advertisements from all access points allowing in-roaming
visitors.

All home servers would have to keep state about all NASes which allow
roaming, unless the intermediary keeps this state and applies an always
advertise policy on behalf of a NAS when proxying.

If we want to maintain a stateless architecture, we either need to use =
the
"always advertise" policy or allow the NAS to leverage the state it =
already
keeps - sending a second access-request in response to the server =
rejecting
with a reject reason or capability attribute pointing to the lack of
advertisement of one or multiple supported but previously un-advertised
capability.

And yes, I love KISSes, but not too many.

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Dienstag, 14. Dezember 2004 18:20
An: [email-masked]
Betreff: RE: backwards compatible introduction of NEW attribute such as =
CUI

Paul Congdon writes...
=A0
> Instead of sending these 'advertised' attributes in every=20
> Access-Request, > why doesn't a NAS send a single Access-Request for=20
> itself that advertises > all the things it needs to advertise once.

I'm sure that method could be made to work.  However, it does make =
RADIUS
somewhat more statefull that it has been heretofore.  My thoughts on =
this
are that one more attribute in an Access-Request message is not a great =
deal
of overhead.  Given that many RADIUS transactions these days use =
EAP-TLS (or
some other X.509 Certificate based methods) the number of protocol =
octets
consumed by constant advertising becomes diminishingly small, compared =
to
the total authentication session data flow.

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E204.E679DB4E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>I agree that introducing a policy of &quot;always =
advertise a capability attribute&quot;&nbsp; has it's own issues, as =
you and Barney pointed out it requires the server and/or the =
intermediary to keep state of NAS capabilities.</FONT></P>

<P><FONT SIZE=3D2>This may not scale well in a WLAN roaming scenario =
with intermediaries, as it requires the intermediary to keep track of =
NAS capabilities and to proxy this capability advertisement to all =
potential Servers when the capability advertisement message is =
received, and to keep state in order to sync up a Server which went =
down and came back online. </FONT></P>

<P><FONT SIZE=3D2>All servers with customers subscribed to roaming =
capability will receive capability advertisements from all access =
points allowing in-roaming visitors.</FONT></P>

<P><FONT SIZE=3D2>All home servers would have to keep state about all =
NASes which allow roaming, unless the intermediary keeps this state and =
applies an always advertise policy on behalf of a NAS when =
proxying.</FONT></P>

<P><FONT SIZE=3D2>If we want to maintain a stateless architecture, we =
either need to use the &quot;always advertise&quot; policy or allow the =
NAS to leverage the state it already keeps - sending a second =
access-request in response to the server rejecting with a reject reason =
or capability attribute pointing to the lack of advertisement of one or =
multiple supported but previously un-advertised capability.</FONT></P>

<P><FONT SIZE=3D2>And yes, I love KISSes, but not too many.</FONT>
</P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Dienstag, 14. Dezember 2004 18:20</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: backwards compatible introduction of =
NEW attribute such as CUI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Paul Congdon writes...</FONT>
<BR><FONT SIZE=3D2>=A0</FONT>
<BR><FONT SIZE=3D2>&gt; Instead of sending these 'advertised' =
attributes in every </FONT>
<BR><FONT SIZE=3D2>&gt; Access-Request, &gt; why doesn't a NAS send a =
single Access-Request for </FONT>
<BR><FONT SIZE=3D2>&gt; itself that advertises &gt; all the things it =
needs to advertise once.</FONT>
</P>

<P><FONT SIZE=3D2>I'm sure that method could be made to work.&nbsp; =
However, it does make RADIUS somewhat more statefull that it has been =
heretofore.&nbsp; My thoughts on this are that one more attribute in an =
Access-Request message is not a great deal of overhead.&nbsp; Given =
that many RADIUS transactions these days use EAP-TLS (or some other =
X.509 Certificate based methods) the number of protocol octets consumed =
by constant advertising becomes diminishingly small, compared to the =
total authentication session data flow.</FONT></P>
<BR>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E204.E679DB4E--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:39:29 +0000
Date: Tue, 14 Dec 2004 12:36:58 -0500
From: Barney Wolff <[email-masked]>
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
Cc: Lothar Reith <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: backwards compatible introduction of NEW attribute such as CUI

On Tue, Dec 14, 2004 at 09:04:32AM -0800, Congdon, Paul T (ProCurve) wrote:
>  
> Instead of sending these 'advertised' attributes in every Access-Request, why doesn't a NAS send a single Access-Request for itself that advertises all the things it needs to advertise once.  This 'self generated' Access-Request could occur at start-up time or anytime configuration changes such that new things need to be advertised.  Perhaps a new attribute like 'NAS registration' would be required to be included, followed by a list of 'advertised' capabilities that the AS would 'remember' for this NAS.

A while back, I said "keeping state is a terrible idea" and didn't bother
to explicate further.  This is why.  How is the NAS to know when the
server has rebooted or otherwise lost state and the NAS needs to refresh
it?

Futhermore, in a proxy situation, which is how most things seem to be
run these days, how would the registration get to the servers that need it?

I'm firmly in the KISS camp, for RADIUS.  Diameter/RADIUS >> 2 and let's
keep it that way.

Barney Wolff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:37:36 +0000
Date: Tue, 14 Dec 2004 18:33:15 +0100
From: Nagi Reddy Jonnala <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: "Congdon, Paul T (ProCurve)" <[email-masked]>
CC: Lothar Reith <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: backwards compatible introduction of NEW attribute such as CUI

--------------5431CB07AF38D1389375B1F0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Your two ideas are interesting.

- Infact an Accounting-ON could have been used to send this attribute.
But for some networks, accounting is not mandatory. So we need a
mechanism to create a new message like "NAS registration". Also I can
guess one more application for this new message. Some stateful Radius
server/proxies currently don't know when to cleanup the "hanging
sessions" incase NAS crashes. May be this "NAS registration" message can
be used to know that the NAS has come up again.

But the question are the new message types are allowed in charter?

- Your second suggestions is to have some configuration on Radius server
about NAS. I believe this kind of information regarding the NAS already
exists in some implementation of Radius server. For instance a popular
Winows based  Radius server can differentiate whether NAS supports some
specific "set" of Vendor specific attributes or not. But this idea may
suffer when you have a long "varied" list of attributes.

"Congdon, Paul T (ProCurve)" wrote:

>
>
> Instead of sending these 'advertised' attributes in every
> Access-Request, why doesn't a NAS send a single Access-Request for
> itself that advertises all the things it needs to advertise once.
> This 'self generated' Access-Request could occur at start-up time or
> anytime configuration changes such that new things need to be
> advertised.  Perhaps a new attribute like 'NAS registration' would be
> required to be included, followed by a list of 'advertised'
> capabilities that the AS would 'remember' for this NAS.
> Paul
>
>      -------------------------------------------------------------
>      From: [email-masked]
>      [mailto:[email-masked]] On Behalf Of Lothar
>      Reith
>      Sent: Tuesday, December 14, 2004 5:35 AM
>      To: 'Nelson, David'; [email-masked]'
>      Subject: AW: backwards compatible introduction of NEW
>      attribute such as CUI
>
>      Dave,
>
>      apologies regarding the repeated use of HTML format, I have
>      now corrected the problem which made me believe I sent in
>      text only format, but infact it got converted to HTML.
>
>      I like to comment on your statement:
>
>      David Nelson wrote:
>      You seem to think the "supports CUI but did not advertise"
>      scenario is reasonable, and I disagree. I really can't
>      comment, other than to repeat myself."
>
>      I continue to believe that "supports CUI but did not
>      advertise" is a possible scenario.
>
>      It is IMO an implementation decision of the NAS manufacturer
>      to allow this or not, and a configuration decision of the
>      network access provider to adopt an always advertise policy
>      or not, unless the specification says "MUST advertise".
>
>      If you want to exclude this implementation decision and
>      configuration decision, than the text should say: if CUI is
>      supported, it MUST be advertised in all Access Request
>      Messages.
>
>      So far, this has nothing to do with capability negotiation.
>
>      Capability negotiation type functionality would only come
>      into play, when the NAS makes an additional implementation
>      decision complemented  by the network access operator making
>      a configuration decision to apply a "advertise only on as
>      needed basis" policy.
>
>      When such "advertise only on as needed basis" policy is in
>      place,  the NAS could on receipt of a Access-Reject with
>      failure cause "CUI-not-determined" delay sending the reject
>      message to the client, and rather send a second
>      access-request with the CUI-NUL attribute to the server,
>      hoping to get back an Access-Accept in time in order to be
>      able to proceed with accepting the user. Are you aware of
>      any standard which would be violated by such an
>      implementation specific behaviour of a NAS ?
>
>      Lothar
>
>
>      -----Urspr=FCngliche Nachricht-----
>      Von: [email-masked]
>      [mailto:[email-masked]]
>      Gesendet: Freitag, 10. Dezember 2004 17:41
>      An: [email-masked]
>      Betreff: RE: backwards compatible introduction of NEW
>      attribute such as CUI
>
>      Lothar Reith writes (still in HTML!)...
>
>      > to a) what would be "the appropriate helpdesk" in a WLAN
>      roaming
>      > scenario ?
>
>      This is an important question for those in the "roaming
>      consortium" business, as well as home ISPs, to answer.  I
>      remember the "bad old days" before seamless roaming for
>      cellular telephony. Only the brave and the technically savvy
>      were able to use roaming services effectively.  Today, I
>      expect to be able to dial 611 on my cell phone wherever I am
>      and get appropriate assistance. (Of course, talking to a
>      human still requires an Act of Congress -- but I digress
>      :-)  If WLAN roaming wants to be successful, IMHO, the
>      industry needs to make it as transparent as cellular
>      roaming.
>
>      > Also, should the error message say: did not support CUI or
>      perhaps
>      > supports CUI but did not advertise ?
>
>      You seem to think the "supports CUI but did not advertise"
>      scenario is reasonable, and I disagree. I really can't
>      comment, other than to repeat myself.
>
>      > A related question is if the server counts an
>      authentication request
>      > rejected due to missing knowledge about the NASes CUI
>      support as an
>      > unsuccessful login attempt with regards to security
>      thresholds ?
>
>      That is likely an implementation decision.  Personally, I
>      would tend to count it as "failed to meet policy
>      requirements" as apposed to "failed to authenticate".
>
>      --
>      to unsubscribe send a message to
>      [email-masked] with the word 'unsubscribe'
>      in a single line as the message text body.
>
>      archive: <http://psg.com/lists/radiusext/>
>

--------------5431CB07AF38D1389375B1F0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Your two ideas are interesting.
<p>- Infact an Accounting-ON could have been used to send this attribute.
But for some networks, accounting is not mandatory. So we need a mechanism
to create a new message like "NAS registration". Also I&nbsp;can guess
one more application for this new message. Some stateful Radius server/proxies
currently don't know when to cleanup the "hanging sessions" incase NAS&nbsp;crashes.
May be this "NAS&nbsp;registration" message can be used to know that the
NAS&nbsp;has come up again.
<p>But the question are the new message types are allowed in charter?
<p>- Your second suggestions is to have some configuration on Radius server
about NAS. I believe this kind of information regarding the NAS&nbsp;already
exists in some implementation of Radius server. For instance a popular
Winows based&nbsp; Radius server can differentiate whether NAS&nbsp;supports
some specific "set" of Vendor specific attributes or not. But this idea
may suffer when you have a long "varied" list of attributes.
<br>&nbsp;
<p>"Congdon, Paul T (ProCurve)" wrote:
<blockquote TYPE=CITE>&nbsp;
<div dir="ltr">&nbsp;</div>

<div dir="ltr"><span class=645535616-14122004><font face="Arial"><font color="#0000FF"><font size=-1>Instead
of sending these 'advertised' attributes in every Access-Request, why doesn't
a NAS send a single Access-Request for itself that advertises all the things
it needs to advertise once.&nbsp; This 'self generated' Access-Request
could occur at start-up time or anytime configuration changes such that
new things need to be advertised.&nbsp; Perhaps a new attribute like 'NAS
registration' would be required to be included, followed by a list of 'advertised'
capabilities that the AS would 'remember' for this NAS.</font></font></font></span></div>

<div dir="ltr"><span class=645535616-14122004></span></div>

<div dir="ltr"><span class=645535616-14122004><font face="Arial"><font color="#0000FF"><font size=-1>Paul&nbsp;</font></font></font></span></div>

<blockquote dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<div class="OutlookMessageHeader" lang="en-us" dir="ltr">
<hr tabIndex=-1><font face="Tahoma"><font size=-1><b>From:</b> [email-masked]
[<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>] <b>On Behalf Of </b>Lothar Reith</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Tuesday, December 14,
2004 5:35 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> 'Nelson, David'; [email-masked]'</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> AW: backwards compatible
introduction of NEW attribute such as CUI</font></font>
<br>&nbsp;</div>
<font size=-1>Dave,</font>
<p><font size=-1>apologies regarding the repeated use of HTML format, I
have now corrected the problem which made me believe I sent in text only
format, but infact it got converted to HTML.</font>
<p><font size=-1>I like to comment on your statement:</font>
<p><font size=-1>David Nelson wrote:</font>
<br><font size=-1>You seem to think the "supports CUI but did not advertise"
scenario is reasonable, and I disagree. I really can't comment, other than
to repeat myself."</font>
<p><font size=-1>I continue to believe that "supports CUI but did not advertise"
is a possible scenario.</font>
<p><font size=-1>It is IMO an implementation decision of the NAS manufacturer
to allow this or not, and a configuration decision of the network access
provider to adopt an always advertise policy or not, unless the specification
says "MUST advertise".</font>
<p><font size=-1>If you want to exclude this implementation decision and
configuration decision, than the text should say: if CUI is supported,
it MUST be advertised in all Access Request Messages.</font>
<p><font size=-1>So far, this has nothing to do with capability negotiation.</font>
<p><font size=-1>Capability negotiation type functionality would only come
into play, when the NAS makes an additional implementation decision complemented&nbsp;
by the network access operator making a configuration decision to apply
a "advertise only on as needed basis" policy.</font>
<p><font size=-1>When such "advertise only on as needed basis" policy is
in place,&nbsp; the NAS could on receipt of a Access-Reject with failure
cause "CUI-not-determined" delay sending the reject message to the client,
and rather send a second access-request with the CUI-NUL attribute to the
server, hoping to get back an Access-Accept in time in order to be able
to proceed with accepting the user. Are you aware of any standard which
would be violated by such an implementation specific behaviour of a NAS
?</font>
<p><font size=-1>Lothar</font>
<br>&nbsp;
<p><font size=-1>-----Urspr&uuml;ngliche Nachricht-----</font>
<br><font size=-1>Von: [email-masked] [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]</font>
<br><font size=-1>Gesendet: Freitag, 10. Dezember 2004 17:41</font>
<br><font size=-1>An: [email-masked]</font>
<br><font size=-1>Betreff: RE: backwards compatible introduction of NEW
attribute such as CUI</font>
<p><font size=-1>Lothar Reith writes (still in HTML!)...</font>
<p><font size=-1>> to a) what would be "the appropriate helpdesk" in a
WLAN roaming</font>
<br><font size=-1>> scenario ?</font>
<p><font size=-1>This is an important question for those in the "roaming
consortium" business, as well as home ISPs, to answer.&nbsp; I remember
the "bad old days" before seamless roaming for cellular telephony. Only
the brave and the technically savvy were able to use roaming services effectively.&nbsp;
Today, I expect to be able to dial 611 on my cell phone wherever I am and
get appropriate assistance. (Of course, talking to a human still requires
an Act of Congress -- but I digress :-)&nbsp; If WLAN roaming wants to
be successful, IMHO, the industry needs to make it as transparent as cellular
roaming.</font>
<p><font size=-1>> Also, should the error message say: did not support
CUI or perhaps</font>
<br><font size=-1>> supports CUI but did not advertise ?</font>
<p><font size=-1>You seem to think the "supports CUI but did not advertise"
scenario is reasonable, and I disagree. I really can't comment, other than
to repeat myself.</font>
<p><font size=-1>> A related question is if the server counts an authentication
request</font>
<br><font size=-1>> rejected due to missing knowledge about the NASes CUI
support as an</font>
<br><font size=-1>> unsuccessful login attempt with regards to security
thresholds ?</font>
<p><font size=-1>That is likely an implementation decision.&nbsp; Personally,
I would tend to count it as "failed to meet policy requirements" as apposed
to "failed to authenticate".</font>
<p><font size=-1>--</font>
<br><font size=-1>to unsubscribe send a message to [email-masked]
with the word 'unsubscribe' in a single line as the message text body.</font>
<p><font size=-1>archive: &lt;<a href="http://psg.com/lists/radiusext/" target="_blank">http://psg.com/lists/radiusext/</a>></font></blockquote>
</blockquote>
</html>

--------------5431CB07AF38D1389375B1F0--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:21:46 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 14 Dec 2004 12:20:14 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Paul Congdon writes...
=A0
> Instead of sending these 'advertised' attributes in every =
Access-Request, > why doesn't a NAS send a single Access-Request for =
itself that advertises > all the things it needs to advertise once.

I'm sure that method could be made to work.  However, it does make =
RADIUS somewhat more statefull that it has been heretofore.  My thoughts =
on this are that one more attribute in an Access-Request message is not =
a great deal of overhead.  Given that many RADIUS transactions these =
days use EAP-TLS (or some other X.509 Certificate based methods) the =
number of protocol octets consumed by constant advertising becomes =
diminishingly small, compared to the total authentication session data =
flow.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:13:19 +0000
Date: Tue, 14 Dec 2004 18:12:59 +0100
From: Nagi Reddy Jonnala <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: [email-masked]
Subject: Issue 42: Are the AVPs really "M"andatory in IEEE 802 draft

Issue 42:
Description of issue: Are the AVPs really "M"andatory in IEEE 802 draft
Submitter name: Nagi Reddy Jonnala
Submitter email address: [email-masked]
Date first submitted: Dec-14-2003
Reference:
Document: IEEE 802 extensions, Any other draft??
Comment type: T
Priority: 1
Section: Most of the AVPs have "M" bit enabled
Rationale/Explanation of issue:

All the AVPs have the "M" bit enabled which means that the  NAS MUST
understand the given attribute. I disagree with this. Having the default
value/action incase the RADIUS server doesn't return is already in
practice(for example locally configured interim interval, session
timeout). It is also true with some/all of the attributes mentioned in
this draft.  For instance, understanding Egress-VLANID should never be
madatory because the system might already have a default allowed set of
VLANIDs.

Requested change:

First alternative is:

Use the idea suggested by Bernard to advertise the Capabilities of "new"
attributes in Access-Request and I like this idea.

Second alternative is:

Don't make the AVP mandatory always. Let the RADIUS server(or
implementation) decide whether to enable/disable the "M" bit.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 17:05:13 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 14 Dec 2004 09:04:32 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4E1FE.FAEFC3F6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

=20
Instead of sending these 'advertised' attributes in every =
Access-Request, why doesn't a NAS send a single Access-Request for =
itself that advertises all the things it needs to advertise once.  This =
'self generated' Access-Request could occur at start-up time or anytime =
configuration changes such that new things need to be advertised.  =
Perhaps a new attribute like 'NAS registration' would be required to be =
included, followed by a list of 'advertised' capabilities that the AS =
would 'remember' for this NAS.
=20
Paul =20

________________________________

	From: [email-masked] =
[mailto:[email-masked]] On Behalf Of Lothar Reith
	Sent: Tuesday, December 14, 2004 5:35 AM
	To: 'Nelson, David'; [email-masked]'
	Subject: AW: backwards compatible introduction of NEW attribute such as =
CUI
=09
=09

	Dave,=20

	apologies regarding the repeated use of HTML format, I have now =
corrected the problem which made me believe I sent in text only format, =
but infact it got converted to HTML.

	I like to comment on your statement:=20

	David Nelson wrote:=20
	You seem to think the "supports CUI but did not advertise" scenario is =
reasonable, and I disagree. I really can't comment, other than to repeat =
myself."

	I continue to believe that "supports CUI but did not advertise" is a =
possible scenario.=20

	It is IMO an implementation decision of the NAS manufacturer to allow =
this or not, and a configuration decision of the network access provider =
to adopt an always advertise policy or not, unless the specification =
says "MUST advertise".

	If you want to exclude this implementation decision and configuration =
decision, than the text should say: if CUI is supported, it MUST be =
advertised in all Access Request Messages.

	So far, this has nothing to do with capability negotiation.=20

	Capability negotiation type functionality would only come into play, =
when the NAS makes an additional implementation decision complemented  =
by the network access operator making a configuration decision to apply =
a "advertise only on as needed basis" policy.

	When such "advertise only on as needed basis" policy is in place,  the =
NAS could on receipt of a Access-Reject with failure cause =
"CUI-not-determined" delay sending the reject message to the client, and =
rather send a second access-request with the CUI-NUL attribute to the =
server, hoping to get back an Access-Accept in time in order to be able =
to proceed with accepting the user. Are you aware of any standard which =
would be violated by such an implementation specific behaviour of a NAS =
?

	Lothar=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: [email-masked] [mailto:[email-masked]] =

	Gesendet: Freitag, 10. Dezember 2004 17:41=20
	An: [email-masked]=20
	Betreff: RE: backwards compatible introduction of NEW attribute such as =
CUI=20

	Lothar Reith writes (still in HTML!)...=20

	> to a) what would be "the appropriate helpdesk" in a WLAN roaming=20
	> scenario ?=20

	This is an important question for those in the "roaming consortium" =
business, as well as home ISPs, to answer.  I remember the "bad old =
days" before seamless roaming for cellular telephony. Only the brave and =
the technically savvy were able to use roaming services effectively.  =
Today, I expect to be able to dial 611 on my cell phone wherever I am =
and get appropriate assistance. (Of course, talking to a human still =
requires an Act of Congress -- but I digress :-)  If WLAN roaming wants =
to be successful, IMHO, the industry needs to make it as transparent as =
cellular roaming.

	> Also, should the error message say: did not support CUI or perhaps=20
	> supports CUI but did not advertise ?=20

	You seem to think the "supports CUI but did not advertise" scenario is =
reasonable, and I disagree. I really can't comment, other than to repeat =
myself.

	> A related question is if the server counts an authentication request=20
	> rejected due to missing knowledge about the NASes CUI support as an=20
	> unsuccessful login attempt with regards to security thresholds ?=20

	That is likely an implementation decision.  Personally, I would tend to =
count it as "failed to meet policy requirements" as apposed to "failed =
to authenticate".

	--=20
	to unsubscribe send a message to [email-masked] with =
the word 'unsubscribe' in a single line as the message text body.

	archive: <http://psg.com/lists/radiusext/>=20

------_=_NextPart_001_01C4E1FE.FAEFC3F6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>AW: backwards compatible introduction of NEW =
attribute such as CUI</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1476" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff=20
size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D645535616-14122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Instead of sending these 'advertised' =
attributes in every=20
Access-Request, why doesn't a NAS send a single Access-Request for =
itself that=20
advertises all the things it needs to advertise once.&nbsp; This 'self=20
generated' Access-Request could occur at start-up time or anytime =
configuration=20
changes such that new things need to be advertised.&nbsp; Perhaps a new=20
attribute like 'NAS registration'&nbsp;would be required to be included, =

followed by a list of 'advertised' capabilities that the AS would =
'remember' for=20
this NAS.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D645535616-14122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D645535616-14122004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Paul&nbsp; </FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [email-masked] =

  [mailto:[email-masked]] <B>On Behalf Of </B>Lothar=20
  Reith<BR><B>Sent:</B> Tuesday, December 14, 2004 5:35 AM<BR><B>To:</B> =

  'Nelson, David'; [email-masked]'<BR><B>Subject:</B> AW: =
backwards=20
  compatible introduction of NEW attribute such as =
CUI<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=3D2>Dave,</FONT> </P>
  <P><FONT size=3D2>apologies regarding the repeated use of HTML format, =
I have=20
  now corrected the problem which made me believe I sent in text only =
format,=20
  but infact it got converted to HTML.</FONT></P>
  <P><FONT size=3D2>I like to comment on your statement:</FONT> </P>
  <P><FONT size=3D2>David Nelson wrote:</FONT> <BR><FONT size=3D2>You =
seem to think=20
  the "supports CUI but did not advertise" scenario is reasonable, and I =

  disagree. I really can't comment, other than to repeat =
myself."</FONT></P>
  <P><FONT size=3D2>I continue to believe that "supports CUI but did not =

  advertise" is a possible scenario.</FONT> </P>
  <P><FONT size=3D2>It is IMO an implementation decision of the NAS =
manufacturer=20
  to allow this or not, and a configuration decision of the network =
access=20
  provider to adopt an always advertise policy or not, unless the =
specification=20
  says "MUST advertise".</FONT></P>
  <P><FONT size=3D2>If you want to exclude this implementation decision =
and=20
  configuration decision, than the text should say: if CUI is supported, =
it MUST=20
  be advertised in all Access Request Messages.</FONT></P>
  <P><FONT size=3D2>So far, this has nothing to do with capability=20
  negotiation.</FONT> </P>
  <P><FONT size=3D2>Capability negotiation type functionality would only =
come into=20
  play, when the NAS makes an additional implementation decision=20
  complemented&nbsp; by the network access operator making a =
configuration=20
  decision to apply a "advertise only on as needed basis" =
policy.</FONT></P>
  <P><FONT size=3D2>When such "advertise only on as needed basis" policy =
is in=20
  place,&nbsp; the NAS could on receipt of a Access-Reject with failure =
cause=20
  "CUI-not-determined" delay sending the reject message to the client, =
and=20
  rather send a second access-request with the CUI-NUL attribute to the =
server,=20
  hoping to get back an Access-Accept in time in order to be able to =
proceed=20
  with accepting the user. Are you aware of any standard which would be =
violated=20
  by such an implementation specific behaviour of a NAS ?</FONT></P>
  <P><FONT size=3D2>Lothar</FONT> </P><BR><BR>
  <P><FONT size=3D2>-----Urspr=FCngliche Nachricht-----</FONT> <BR><FONT =
size=3D2>Von:=20
  [email-masked] [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]=
etf.org</A>]=20
  </FONT><BR><FONT size=3D2>Gesendet: Freitag, 10. Dezember 2004 =
17:41</FONT>=20
  <BR><FONT size=3D2>An: [email-masked]</FONT> <BR><FONT =
size=3D2>Betreff:=20
  RE: backwards compatible introduction of NEW attribute such as =
CUI</FONT>=20
  </P><BR>
  <P><FONT size=3D2>Lothar Reith writes (still in HTML!)...</FONT> </P>
  <P><FONT size=3D2>&gt; to a) what would be "the appropriate helpdesk" =
in a WLAN=20
  roaming </FONT><BR><FONT size=3D2>&gt; scenario ?</FONT> </P>
  <P><FONT size=3D2>This is an important question for those in the =
"roaming=20
  consortium" business, as well as home ISPs, to answer.&nbsp; I =
remember the=20
  "bad old days" before seamless roaming for cellular telephony. Only =
the brave=20
  and the technically savvy were able to use roaming services =
effectively.&nbsp;=20
  Today, I expect to be able to dial 611 on my cell phone wherever I am =
and get=20
  appropriate assistance. (Of course, talking to a human still requires =
an Act=20
  of Congress -- but I digress :-)&nbsp; If WLAN roaming wants to be =
successful,=20
  IMHO, the industry needs to make it as transparent as cellular=20
  roaming.</FONT></P>
  <P><FONT size=3D2>&gt; Also, should the error message say: did not =
support CUI=20
  or perhaps </FONT><BR><FONT size=3D2>&gt; supports CUI but did not =
advertise=20
  ?</FONT> </P>
  <P><FONT size=3D2>You seem to think the "supports CUI but did not =
advertise"=20
  scenario is reasonable, and I disagree. I really can't comment, other =
than to=20
  repeat myself.</FONT></P>
  <P><FONT size=3D2>&gt; A related question is if the server counts an=20
  authentication request </FONT><BR><FONT size=3D2>&gt; rejected due to =
missing=20
  knowledge about the NASes CUI support&nbsp;as an </FONT><BR><FONT =
size=3D2>&gt;=20
  unsuccessful login attempt with regards to security thresholds =
?</FONT> </P>
  <P><FONT size=3D2>That is likely an implementation decision.&nbsp; =
Personally, I=20
  would tend to count it as "failed to meet policy requirements" as =
apposed to=20
  "failed to authenticate".</FONT></P><BR>
  <P><FONT size=3D2>--</FONT> <BR><FONT size=3D2>to unsubscribe send a =
message to=20
  [email-masked] with the word 'unsubscribe' in a single =
line as=20
  the message text body.</FONT></P>
  <P><FONT size=3D2>archive: &lt;<A =
href=3D"http://psg.com/lists/radiusext/"=20
  target=3D_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4E1FE.FAEFC3F6--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 15:27:57 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 39: Backward Compatibility of Filter Attributes
Date: Tue, 14 Dec 2004 10:27:21 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...

> A simpler way to handle backward compatibility would be to define a
> "Capabilities" attribute that would contain the Type values
> for all new attributes that the NAS supports.

I think this is a *great* idea.  I suggest that we name it the
Capabilities-Advertisement attribute.  It would also be useful (although
not absolutely required) to describe how to format a similar attribute
in the VSA space, for vendors that wish to advertise their VSA support
in a standardized fashion.  I assume that such a
VSA-Capabilities-Advertisement attribute would be handled similarly to
the VSA, in that it would include the vendor ID tag.=20

We might wish to use this approach in the CUI draft, where we are
currently debating the issue of capabilities advertisement.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 15:20:59 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 14 Dec 2004 10:19:58 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Lothar Reith writes...

>I like to comment on your statement:=20
> David Nelson wrote:=20
> You seem to think the "supports CUI but did not advertise" scenario is
> reasonable, and I disagree. I really can't comment, other than to =
repeat
> myself."
> I continue to believe that "supports CUI but did not advertise" is a
> possible scenario.

Possible, yes.  Reasonable, no.  In my opinion, of course.  :-)

> If you want to exclude this implementation decision and configuration
> decision, than the text should say: if CUI is supported, it MUST be
> advertised in all Access Request Messages.

I would not object to the "MUST" language.  However, I note that Bernard =
Aboba has proposed defining a new Capabilities-Advertisement attribute, =
which (presumably) contains a list of supported Attribute IDs (8-bit =
values).  It might be better to adopt a single =
Capabilities-Advertisement attribute now, given the requirements for =
capabilities advertisement in other documents under consideration as WG =
work items.

> When such "advertise only on as needed basis" policy is in =
place,=A0the NAS > could on receipt of a Access-Reject with failure =
cause "CUI-not-
> determined" delay sending the reject message to the client, and rather
> send a second access-request with the CUI-NUL attribute to the server,
> hoping to get back an Access-Accept in time in order to be able to =
proceed > with accepting the user. Are you aware of any standard which =
would be
> violated by such an implementation specific behaviour of a NAS ?

No, but IMHO, this optimization (of a few protocol message bytes) is =
needless complexity.  The "always advertise" approach is much simpler, =
and therefore easier to "get right", advancing multi-vendor =
interoperability.  Basically speaking, the KISS principle.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 13:48:14 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: Issue 6: Encryption
Date: Tue, 14 Dec 2004 14:47:39 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E1E3.7A148A2E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

resend in text only format:

Bernard, Wolfgang,=20

RFC 2868 also defines a SALT for encrypting an attribute, and I believe =
(and
hope) it is not broken, as apparently in this RFC the SALT is at the
beginning.

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Dienstag, 14. Dezember 2004 05:19
An: [email-masked]
Betreff: Re: Issue 6: Encryption

Wolfgang Beck said:

"Issue 6

To be honest, I did not find an RFC that describes how to encrypt =
individual
RADIUS attributes other than User-Password and Tunnel-Password."

RFC 2548 also defines encryption of the MPPE-Key attributes. However, =
the
use of the SALT field in that draft is broken -- the SALT if used, =
needs to
go at the beginning, not the end!

Putting it at the end is silly because a known plaintext attack =
compromises
the keystream, and then the attacker can continue the key stream =
guessing
various SALT values.  So the SALT has no security value at all in =
making the
stream cipher harder to crack.

Given the attacks on MD5-based stream ciphers (see RFC 3579 for =
details),
I'm not sure we'll be able to get any document using them past security
review.

If we really do need to encrypt an attribute, probably the way to go is =
to
use an AES-based wrap.

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1E3.7A148A2E
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: Issue 6: Encryption</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>resend in text only format:</FONT>
</P>

<P><FONT SIZE=3D2>Bernard, Wolfgang, </FONT>
</P>

<P><FONT SIZE=3D2>RFC 2868 also defines a SALT for encrypting an =
attribute, and I believe (and hope) it is not broken, as apparently in =
this RFC the SALT is at the beginning.</FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Dienstag, 14. Dezember 2004 05:19</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: Re: Issue 6: Encryption</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Wolfgang Beck said:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Issue 6</FONT>
</P>

<P><FONT SIZE=3D2>To be honest, I did not find an RFC that describes =
how to encrypt individual RADIUS attributes other than User-Password =
and Tunnel-Password.&quot;</FONT></P>

<P><FONT SIZE=3D2>RFC 2548 also defines encryption of the MPPE-Key =
attributes. However, the use of the SALT field in that draft is broken =
-- the SALT if used, needs to go at the beginning, not the =
end!</FONT></P>

<P><FONT SIZE=3D2>Putting it at the end is silly because a known =
plaintext attack compromises the keystream, and then the attacker can =
continue the key stream guessing various SALT values.&nbsp; So the SALT =
has no security value at all in making the stream cipher harder to =
crack.</FONT></P>

<P><FONT SIZE=3D2>Given the attacks on MD5-based stream ciphers (see =
RFC 3579 for details), I'm not sure we'll be able to get any document =
using them past security review.</FONT></P>

<P><FONT SIZE=3D2>If we really do need to encrypt an attribute, =
probably the way to go is to use an AES-based wrap.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E1E3.7A148A2E--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 13:36:48 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Tue, 14 Dec 2004 14:34:37 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E1E1.A7D50BE8
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Dave,

apologies regarding the repeated use of HTML format, I have now =
corrected
the problem which made me believe I sent in text only format, but =
infact it
got converted to HTML.

I like to comment on your statement:

David Nelson wrote:
You seem to think the "supports CUI but did not advertise" scenario is
reasonable, and I disagree. I really can't comment, other than to =
repeat
myself."

I continue to believe that "supports CUI but did not advertise" is a
possible scenario.

It is IMO an implementation decision of the NAS manufacturer to allow =
this
or not, and a configuration decision of the network access provider to =
adopt
an always advertise policy or not, unless the specification says "MUST
advertise".

If you want to exclude this implementation decision and configuration
decision, than the text should say: if CUI is supported, it MUST be
advertised in all Access Request Messages.

So far, this has nothing to do with capability negotiation.

Capability negotiation type functionality would only come into play, =
when
the NAS makes an additional implementation decision complemented  by =
the
network access operator making a configuration decision to apply a
"advertise only on as needed basis" policy.

When such "advertise only on as needed basis" policy is in place,  the =
NAS
could on receipt of a Access-Reject with failure cause =
"CUI-not-determined"
delay sending the reject message to the client, and rather send a =
second
access-request with the CUI-NUL attribute to the server, hoping to get =
back
an Access-Accept in time in order to be able to proceed with accepting =
the
user. Are you aware of any standard which would be violated by such an
implementation specific behaviour of a NAS ?

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Freitag, 10. Dezember 2004 17:41
An: [email-masked]
Betreff: RE: backwards compatible introduction of NEW attribute such as =
CUI

Lothar Reith writes (still in HTML!)...

> to a) what would be "the appropriate helpdesk" in a WLAN roaming=20
> scenario ?

This is an important question for those in the "roaming consortium"
business, as well as home ISPs, to answer.  I remember the "bad old =
days"
before seamless roaming for cellular telephony. Only the brave and the
technically savvy were able to use roaming services effectively.  =
Today, I
expect to be able to dial 611 on my cell phone wherever I am and get
appropriate assistance. (Of course, talking to a human still requires =
an Act
of Congress -- but I digress :-)  If WLAN roaming wants to be =
successful,
IMHO, the industry needs to make it as transparent as cellular roaming.

> Also, should the error message say: did not support CUI or perhaps=20
> supports CUI but did not advertise ?

You seem to think the "supports CUI but did not advertise" scenario is
reasonable, and I disagree. I really can't comment, other than to =
repeat
myself.

> A related question is if the server counts an authentication request=20
> rejected due to missing knowledge about the NASes CUI support=A0as an =

> unsuccessful login attempt with regards to security thresholds ?

That is likely an implementation decision.  Personally, I would tend to
count it as "failed to meet policy requirements" as apposed to "failed =
to
authenticate".

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1E1.A7D50BE8
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Dave,</FONT>
</P>

<P><FONT SIZE=3D2>apologies regarding the repeated use of HTML format, =
I have now corrected the problem which made me believe I sent in text =
only format, but infact it got converted to HTML.</FONT></P>

<P><FONT SIZE=3D2>I like to comment on your statement:</FONT>
</P>

<P><FONT SIZE=3D2>David Nelson wrote:</FONT>
<BR><FONT SIZE=3D2>You seem to think the &quot;supports CUI but did not =
advertise&quot; scenario is reasonable, and I disagree. I really can't =
comment, other than to repeat myself.&quot;</FONT></P>

<P><FONT SIZE=3D2>I continue to believe that &quot;supports CUI but did =
not advertise&quot; is a possible scenario.</FONT>
</P>

<P><FONT SIZE=3D2>It is IMO an implementation decision of the NAS =
manufacturer to allow this or not, and a configuration decision of the =
network access provider to adopt an always advertise policy or not, =
unless the specification says &quot;MUST advertise&quot;.</FONT></P>

<P><FONT SIZE=3D2>If you want to exclude this implementation decision =
and configuration decision, than the text should say: if CUI is =
supported, it MUST be advertised in all Access Request =
Messages.</FONT></P>

<P><FONT SIZE=3D2>So far, this has nothing to do with capability =
negotiation.</FONT>
</P>

<P><FONT SIZE=3D2>Capability negotiation type functionality would only =
come into play, when the NAS makes an additional implementation =
decision complemented&nbsp; by the network access operator making a =
configuration decision to apply a &quot;advertise only on as needed =
basis&quot; policy.</FONT></P>

<P><FONT SIZE=3D2>When such &quot;advertise only on as needed =
basis&quot; policy is in place,&nbsp; the NAS could on receipt of a =
Access-Reject with failure cause &quot;CUI-not-determined&quot; delay =
sending the reject message to the client, and rather send a second =
access-request with the CUI-NUL attribute to the server, hoping to get =
back an Access-Accept in time in order to be able to proceed with =
accepting the user. Are you aware of any standard which would be =
violated by such an implementation specific behaviour of a NAS =
?</FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Freitag, 10. Dezember 2004 17:41</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: backwards compatible introduction of =
NEW attribute such as CUI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Lothar Reith writes (still in HTML!)...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; to a) what would be &quot;the appropriate =
helpdesk&quot; in a WLAN roaming </FONT>
<BR><FONT SIZE=3D2>&gt; scenario ?</FONT>
</P>

<P><FONT SIZE=3D2>This is an important question for those in the =
&quot;roaming consortium&quot; business, as well as home ISPs, to =
answer.&nbsp; I remember the &quot;bad old days&quot; before seamless =
roaming for cellular telephony. Only the brave and the technically =
savvy were able to use roaming services effectively.&nbsp; Today, I =
expect to be able to dial 611 on my cell phone wherever I am and get =
appropriate assistance. (Of course, talking to a human still requires =
an Act of Congress -- but I digress :-)&nbsp; If WLAN roaming wants to =
be successful, IMHO, the industry needs to make it as transparent as =
cellular roaming.</FONT></P>

<P><FONT SIZE=3D2>&gt; Also, should the error message say: did not =
support CUI or perhaps </FONT>
<BR><FONT SIZE=3D2>&gt; supports CUI but did not advertise ?</FONT>
</P>

<P><FONT SIZE=3D2>You seem to think the &quot;supports CUI but did not =
advertise&quot; scenario is reasonable, and I disagree. I really can't =
comment, other than to repeat myself.</FONT></P>

<P><FONT SIZE=3D2>&gt; A related question is if the server counts an =
authentication request </FONT>
<BR><FONT SIZE=3D2>&gt; rejected due to missing knowledge about the =
NASes CUI support=A0as an </FONT>
<BR><FONT SIZE=3D2>&gt; unsuccessful login attempt with regards to =
security thresholds ?</FONT>
</P>

<P><FONT SIZE=3D2>That is likely an implementation decision.&nbsp; =
Personally, I would tend to count it as &quot;failed to meet policy =
requirements&quot; as apposed to &quot;failed to =
authenticate&quot;.</FONT></P>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E1E1.A7D50BE8--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 11:31:21 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: Issue 6: Encryption
Date: Tue, 14 Dec 2004 12:29:20 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4E1D0.2752B85A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bernard, Wolfgang,

RFC 2868 also defines a SALT for encrypting an attribute, and I believe =
(and
hope) it is not broken, as apparently in this RFC the SALT is at the
beginning.

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Dienstag, 14. Dezember 2004 05:19
An: [email-masked]
Betreff: Re: Issue 6: Encryption

Wolfgang Beck said:

"Issue 6

To be honest, I did not find an RFC that describes how to encrypt =
individual
RADIUS attributes other than User-Password and Tunnel-Password."

RFC 2548 also defines encryption of the MPPE-Key attributes. However, =
the
use of the SALT field in that draft is broken -- the SALT if used, =
needs to
go at the beginning, not the end!

Putting it at the end is silly because a known plaintext attack =
compromises
the keystream, and then the attacker can continue the key stream =
guessing
various SALT values.  So the SALT has no security value at all in =
making the
stream cipher harder to crack.

Given the attacks on MD5-based stream ciphers (see RFC 3579 for =
details),
I'm not sure we'll be able to get any document using them past security
review.

If we really do need to encrypt an attribute, probably the way to go is =
to
use an AES-based wrap.

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1D0.2752B85A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: Issue 6: Encryption</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bernard, Wolfgang,</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2868 also defines a SALT for encrypting an =
attribute, and I believe (and hope) it is not broken, as apparently in =
this RFC the SALT is at the beginning.</FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Dienstag, 14. Dezember 2004 05:19</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: Re: Issue 6: Encryption</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Wolfgang Beck said:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Issue 6</FONT>
</P>

<P><FONT SIZE=3D2>To be honest, I did not find an RFC that describes =
how to encrypt individual RADIUS attributes other than User-Password =
and Tunnel-Password.&quot;</FONT></P>

<P><FONT SIZE=3D2>RFC 2548 also defines encryption of the MPPE-Key =
attributes. However, the use of the SALT field in that draft is broken =
-- the SALT if used, needs to go at the beginning, not the =
end!</FONT></P>

<P><FONT SIZE=3D2>Putting it at the end is silly because a known =
plaintext attack compromises the keystream, and then the attacker can =
continue the key stream guessing various SALT values.&nbsp; So the SALT =
has no security value at all in making the stream cipher harder to =
crack.</FONT></P>

<P><FONT SIZE=3D2>Given the attacks on MD5-based stream ciphers (see =
RFC 3579 for details), I'm not sure we'll be able to get any document =
using them past security review.</FONT></P>

<P><FONT SIZE=3D2>If we really do need to encrypt an attribute, =
probably the way to go is to use an AES-based wrap.</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4E1D0.2752B85A--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 10:53:19 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, [email-masked]
Subject: RE: CUI - issues addressed in version 3  
Date: Tue, 14 Dec 2004 11:52:44 +0100

Hi Farid,
thanks for keeping track of these issues so carefully. Mine is fully covered by version 03.

David.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: lunes, 13 de diciembre de 2004 21:49
To: [email-masked]
Subject: CUI - issues addressed in version 3 

Hi David, Bernard, Greg, Barney:

First, thanks again for reviewing the draft and submitting issues
against versions 1 and 2. It would be great if you can let us know
whether or not version 03 addresses the issues.    

Issues addressed in Version 3
=============================
Issue 13 (Owner: David Mariblanca)
Issue 14 (Owner: Bernard Aboba)
Issue 18 (Owner: Greg Weber)
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.

Thanks for your help.

BR,
Farid

--
to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 06:25:59 +0000
Date: Tue, 14 Dec 2004 08:25:12 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "James M. Polk" <[email-masked]>
Cc: Tschofenig Hannes <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Geopriv] Radius-Geopriv: Civic vs. geospatial location	information

I can easily imagine a situation where you have just one
part of the information in an easy manner. For instance,
a plain old GPS system will only give you geospatial,
whereas configuration might just give you just the civil
location.

--Jari

James M. Polk wrote:
> Hannes
> 
> Don't forget that geospatial is mandatory to implement in PIDF-LO. Civic 
> is optional.
> 
> I don't know what you want to do about consistency here.
> 
> At 10:06 AM 12/13/2004 +0100, Tschofenig Hannes wrote:
> 
>> hi all,
>>
>> currently the document says that civic location information MUST be
>> provided. Jari proposed to change the MUST into a SHOULD.
>>
>> we had a discussion on this issue during the geopriv meeting and i had 
>> the
>> impression that it is ok to change the MUST into a SHOULD.
>>
>> ciao
>> hannes
>>
>> _______________________________________________
>> Geopriv mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 
> 
> cheers,
> James
> 
>                                *******************
>                 Truth is not to be argued... it is to be presented
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
> 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 04:19:16 +0000
Date: Mon, 13 Dec 2004 20:18:49 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Issue 6: Encryption

Wolfgang Beck said:

"Issue 6

To be honest, I did not find an RFC that describes how to
encrypt individual RADIUS attributes other than User-Password
and Tunnel-Password."

RFC 2548 also defines encryption of the MPPE-Key attributes.
However, the use of the SALT field in that draft is broken -- the SALT if
used, needs to go at the beginning, not the end!

Putting it at the end is silly because a known plaintext attack
compromises the keystream, and then the attacker can continue the key
stream guessing various SALT values.  So the SALT has no security value at
all in making the stream cipher harder to crack.

Given the attacks on MD5-based stream ciphers (see RFC 3579 for details),
I'm not sure we'll be able to get any document using them past security
review.

If we really do need to encrypt an attribute, probably the way to go is to
use an AES-based wrap.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 04:09:02 +0000
Date: Mon, 13 Dec 2004 20:08:34 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Issue 7:  Message-Authenticator?

Wolfgang Beck said:

"Issue 7

My interpretation of the list discussion was that the consensus was to
make the Message-Authenticator mandatory. I'll copy the relevant parts
of section 3.1 and 3.2 of RfC3579, as Bernard proposed.

I don't think that integrity protection of Access-Requests is really
a big issue. Carrying HTTP Digest over unprotected RADIUS can't be
worse than carrying it over unprotected HTTP or SIP. Digest-HA1 is the
only exception, because a MITM can 'sign' arbitrary HTTP-style responses.

Here is a proposal:
- Message-Authenticator is optional
- Digest-HA1 MUST be encrypted like User-Password, using a shared key.
That means, Digest-HA1 can be used with MD5, AKAv1-MD5; reliance
on IPSec is no longer needed (the requirement remains with sips /
https where all attributes would have to be encrypted)."

On Issue 7, Avi posted a proposal, so far the reaction seems to be
favorable.  But we will wait a bit longer before judging consensus.

In terms of the threats, Access-Request vulnerabilities generally are
of the DoS, dictionary attack and bidding down type.  Without a
Message-Authenticator, an attacker can send many Requests and try to do a
dictionary attack on the user password.  With the capabilities negotiation
features we're talking about, forging Access-Request messages can convince
the RADIUS server to lower the level of security (e.g. no filters, etc.).

In terms of encryption, there is again the issue of what encryption to
use.  The stream cipher used in RFC 2865, 2868 and 2548 is vulnerable to a
known plaintext attack a la WEP.  While the Request Authenticator space is
a lot larger in RADIUS, RADIUS password hygene is notoriously bad, and if
on top of that the Request Authenticator doesn't satisfy the global and
temporal uniqueness requirements of RFC 2865, then the Request
Authenticator could repeat with the same shared secret.  This allows
encrypted attributes to be decrypted.

So overall the problems with MD5-based keywrap are considerably more
serious than the concerns over cracking of HMAC-MD5, in that the attacks
have been documented.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 02:53:59 +0000
Date: Mon, 13 Dec 2004 18:53:31 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 41: Pruning the Filter Attribute Thicket

Issue 41: Pruning the Filter Attribute Thicket
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 2.7
Rationale/Explanation of issue:
The document currently defines a QoS-Filter-Rule attribute as
well as a NAS-Filter-Rule attribute. RFC 2865 already defines
a Filter-ID attribute which could support any type of filter
(deny/allow, QoS, etc.). We also have draft-lior-radius-redirection
which defines IP-Redirection-Id, IP-Redirection-Rule, HTTP-Redirection-Id
and HTTP-Redirection-Rule attributes.

Creating this many filter-related attributes is asking for trouble,
I think. How are we to merge all these capabilities together if
more than one capability are included in the same Access-Accept
packet? It is hard enough to figure this out just for Filter-Id
and NAS-Filter-Rule.

I think we need to unify these concepts. One potential resolution
is to define a single Filter-Rule syntax that can handle permit/deny,
QoS and redirection filtering at both layer 2 and layer 3.

One question is how the NAS can indicate what level of filtering
it supports assuming that extensions are supported at some point.
My proposal would be to specify the capabilities that we expect
all NAS devices to support in one attribute, then also define
extended attributes that can handle more than one capability.
However, we can then specify that only *one* type of filter
attribute (NAS-Filter-Rule, Extended-NAS-Filter-Rule, etc.) can
appear in a single packet, to simplify the merging problem.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 02:52:33 +0000
Date: Mon, 13 Dec 2004 18:51:35 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 40:  Support for Layer 2 filtering

Issue 40: Support for Layer 2 Filtering
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 2.7
Rationale/Explanation of issue:
The NAS-Filter-Rule syntax defined in RFC 3588 does not support Layer 2
filters. Since this is an IEEE 802 extensions document, support for
Layer 2 filtering seems important.
Suggest the following syntax:

action dir proto from src to dst [options]

here action is defined as in RFC 3588 (permit/deny),
dir is as in RFC 3588 (in/out).

In RFC 3588, Proto is defined as the IP protocol
number or "ip" to match any IP protocol. I'd suggest
addition of the Ethertype:<Type> keyword to enable
filtering on Ethertype.

Src and dest are defined in RFC 3588 to include address/mask
and port. Suggestion is that they be extended to include
MAC addresses.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 02:51:01 +0000
Date: Mon, 13 Dec 2004 18:50:49 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 39: Backward Compatibility of Filter Attributes

Issue 39: Backward Compatibility of Filter Attributes
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 1.3
Rationale/Explanation of issue:
I am not sure that use of a "M" andatory bit is the right way to
go for this document. This requires substantial changes
to RADIUS and will make it more difficult to deploy the IEEE 802
Extensions.

In the CUI document, it has been suggested that an empty CUI
attribute be used for the NAS to advertise CUI support within
the Access-Request.

This approach does not seem to work for this document, which
includes multiple attributes that might be considered mandatory,
such as security-related attributes such (e.g. NAS-Filter-Rule).

A simpler way to handle backward compatibility would be to define a
"Capabilities" attribute that would contain the Type values
for all new attributes that the NAS supports. Since one
Capabilities attribute can be 253 octets in size, up to 253
attributes could be advertised by the NAS in a single attribute.
That RADIUS server would then only include a NAS-Filter-Rule attribute
in an Access-Accept if support was advertised in the Capabilities
attribute.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 02:49:23 +0000
Date: Mon, 13 Dec 2004 18:49:03 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 38: Ordering of filter attributes

Issue 38: Ordering of Filter Attributes
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 2.7
Rationale/Explanation of issue:
Section 2.7 does not state that NAS-Filter-Rule attributes shouldn't
be reordered by RADIUS proxies. Since reordering can change the
meaning of filter lists, reordering cannot be allowed.

The addition of the following text is recommended:

"If multiple NAS-Filter-Rule attributes are contained within an
Access-Request or Access-Accept packet they MUST be in order
and they MUST be consecutive attributes in the packet. RADIUS
proxies MUST NOT reorder NAS-Filter-Rule attributes.

The RADIUS server can return NAS-Filter-Rule attributes in an
Access-Accept packet. Where more than one NAS-Filter-Rule
attribute is included, it is assumed that the attributes are
to be concatenated to form a single filter list."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 14 Dec 2004 02:47:18 +0000
Date: Mon, 13 Dec 2004 18:45:46 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 37: Merging of Filter Attributes

Issue 37: Merging of Filter Attributes
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: December 13, 2004
Reference:
Document: Congdon-02
Comment type: T
Priority: S
Section: 2.7
Rationale/Explanation of issue:
Section 2.7 does not state what happens if both Filter-ID and
NAS-Filter-Rule attributes are included in an Access-Accept.
How are the filters merged?

Suggest the addition of the following text:

"If both Filter-ID and NAS-Filter-Rule attributes are included
within an Access-Request or Access-Accept packet, the filter
specified by the NAS-Filter-Rule attribute is considered to
be appended to the end of the filter list specified by the
Filter-ID attribute.

As a result, if the Filter-ID attribute specifies that a
packet is to be discarded, then the filter specified by NAS-Filter-Rule
can have no effect on the processing of that packet, since
it will have already been discarded prior to examination by
the filter specified in NAS-Filter-Rule."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 20:49:14 +0000
Content-class: urn:content-classes:message
Subject: CUI - issues addressed in version 3  
Date: Mon, 13 Dec 2004 12:48:39 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Hi David, Bernard, Greg, Barney:

First, thanks again for reviewing the draft and submitting issues
against versions 1 and 2. It would be great if you can let us know
whether or not version 03 addresses the issues.   =20

Issues addressed in Version 3
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D
Issue 13 (Owner: David Mariblanca)
Issue 14 (Owner: Bernard Aboba)
Issue 18 (Owner: Greg Weber)
Issue 21 (Owner: Barney Wolff)
Issue 22 (Owner: Barney Wolff)=20

The description of these issues can be found in in
http://www.drizzle.com/~aboba/RADEXT/#Issue%2014.

Thanks for your help.

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 20:35:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00
Date: Mon, 13 Dec 2004 12:32:50 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

In fact, we had "SHOULD" in the previous version.  But there were some
concerns about it, so we changed it to "MAY"!  But, I am okay with
either, or even removing it entirely (i.e., no advertisement) as some
people suggested.
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of=20
> [email-masked]
> Sent: Friday, December 10, 2004 9:41 PM
> To: [email-masked]; [email-masked]
> Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00
>=20
>=20
> Hi David,
>=20
> This seems like a reasonable change. We can fix this in the=20
> next update.
>=20
> cheers,
> John
>=20
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of ext Nelson, David
> > Sent: 10 December, 2004 19:32
> > To: [email-masked]
> > Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
> >=20
> >=20
> > Description of issue: Use of Chargeable-User-ID attribute in
> > Access-Request Messages
> > Submitter name: Dave Nelson
> > Submitter email address: [email-masked]
> > Date first submitted: December 10, 2004
> > Reference: (N/A)
> > Document: draft-ietf-radext-chargeable-user-id-00.txt
> > Comment type: T
> > Priority: 1
> > Section: 2.1
> > Rationale/Explanation of issue:  Unless and until the RADEXT=20
> > WG decides
> > to enhance RADIUS to include Capabilities Negotiation (as it exists,
> > e.g. in PPP), we need to continue to rely on Capabilities=20
> > Advertisement.
> > Advertisement has been a standardized part of RADIUS, in the form of
> > "hint" attributes in Access-Request messages, since its inception.
> > There has been discussion on the mailing list that suggests we ought
> > define Capabilities Negotiation for new attributes that are=20
> considered
> > mandatory (or conditionally mandatory) such as=20
> Chargeable-User-ID.  In
> > order to drive this issue to a resolution, I am suggesting=20
> a change to
> > the draft to make Capabilities Advertisement a strong SHOULD.
> > Length description of problem:  (see above)
> >=20
> > Requested change: Change the following text in Section 2.1:
> > =20
> > From:
> >=20
> > "The NAS MAY include the CUI attribute with a null character for its
> > data field in the Access-Request message to indicate its support for
> > this attribute to the home RADIUS server.  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=20
> server MUST
> > reject the request by sending an Access-Reject message including an
> > Error-Cause attribute [RFC3576] with value (to-be-defined)=20
> (decimal),
> > "CUI-Support-Undetermined"."
> >=20
> > To:
> >=20
> > "The NAS SHOULD include the CUI attribute with a null=20
> > character for its
> > data field in the Access-Request message to indicate its support for
> > this attribute to the home RADIUS server, unless deployment specific
> > constraints dictate that the home RADIUS server has some=20
> > other reliable
> > means to determine that the NAS supports this attribute.  Such means
> > might include out-of-band configuration.  In cases where the=20
> > home RADIUS
> > server cannot determine the NAS support for the CUI, if the=20
> > home RADIUS
> > server requires the NAS support for CUI for any reason (e.g., for
> > billing or charging purposes), the home RADIUS server MUST=20
> reject the
> > request by sending an Access-Reject message including an Error-Cause
> > attribute [RFC3576] with value (to-be-defined) (decimal),
> > "CUI-Support-Undetermined"."
> >=20
> >=20
> > --
> > to unsubscribe send a message to [email-masked] with
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> >=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 20:11:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Radius-Geopriv: Civic vs. geospatial location information
Date: Mon, 13 Dec 2004 12:10:40 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Tschofenig Hannes" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

We also said that we can make all attributes / information-elements in
the draft optional.  Organization like GSMA, CDG, WFA will worry about
MUST/SHOULD. For example, GSMA IR61 and 3GPP CN4 specification require
only a subset of these attributes/information-elements.
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Tschofenig Hannes
> Sent: Monday, December 13, 2004 1:06 AM
> To: [email-masked]; [email-masked]
> Subject: Radius-Geopriv: Civic vs. geospatial location information
>=20
>=20
> hi all,=20
>=20
> currently the document says that civic location information MUST be
> provided. Jari proposed to change the MUST into a SHOULD.
>=20
> we had a discussion on this issue during the geopriv meeting=20
> and i had the
> impression that it is ok to change the MUST into a SHOULD.=20
>=20
> ciao
> hannes
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 16:01:27 +0000
Date: Mon, 13 Dec 2004 18:00:21 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: User Identity Confidentiality

Tschofenig Hannes wrote:

> [hannes] the first issue: it is true that user identity confidentiality also
> depends on the configuration of certain protocols (particularly if protocols
> provide flexible mechanisms). in any case, authentication and key exchange

Yes.

> protocols which offer public key based authentication are able to provide
> better user identity confidentiality than protocols which only use symmetric
> keys. the latter protocols are only able to use temporal identities. 

Yes, but does that affect the level of privacy offered to the user?
Both approaches can certainly be made to fail, e.g., through bad
configuration or through protocols that don't take into account
all cases.

> [hannes] regarding the second issue: 'we should talk about location privacy
> rather than user identity confidentiality'
> 
> here is my reasoning: 
> * we would like to avoid that the visited network obtains the user's
> identity and its location information. the visited network will obviously
> always obtain the user's location information. hence, we should avoid that
> it receives the user's identity. within the radius-geopriv document we can

This is very reasonable.

> only address aspects which are within the scope of radius (or diameter) and
> certainly not within the scope of other protocols. 

This is a good approach, but its kind of hard to draw the line. EAP is
strictly speaking another protocol, although its carried in AAA; and
many L2 protocol issues from a NAS will be reflected in the AAA protocols
in the same manner.

> * i know that user identity confidentiality is a difficult issue since you
> need to deal with a number of identities at different layers and with
> different protocols. i think it is worth stating that providing user id.
> conf. within eap does not solve all issues. if you use ikev2 afterwards and
> again reveal your true identity then you have again lost. 

Yes.

> i some sense this is not a problem for radius-geopriv, as such, since you
> need to deal with this problem also if there is no radius-geopriv extension.

Yes.

> with regard to location privacy (what information is distributed to other
> networks or entities by the home network) i tried to say a few words in
> section 14. 

I think that part was fine.

> jari, what should i do? 

Lets see if we can work on text:

    For the envisioned usage scenarios the network access authentication
    ...
    their security requirements).  Instead the choice is often
    predetermined by a given architecture.

=>

    For the envisioned usage scenarios, the identify of the user or his
    devices is tightly coupled to the transfer of location information.
    If the identity can be determined by the visited network or AAA
    brokers, then it is possible to correlate location information with
    a particular user. As such, it allows the visited network and
    brokers to learn movement patterns of users.

    The identity of the user can "leak" to the visited network or AAA
    brokers in a number of ways:

    o  The user's device may employ a fixed MAC address, or base its IP
       address on such an address. This enables the correlation of the
       particular device to its different locations. Techniques exist
       to avoid the use of an IP address that is based on MAC address
       [RFC 3041]. Some link layers make it possible to avoid MAC
       addresses or change them dynamically.

    o  Network access authentication procedures such as PPP CHAP [RFC
       1994] or EAP [RFC 3748] may reveal the user's identity as a part
       of the authentication procedure. Techniques exist to avoid
       this problem in EAP, for instance by employing private Network
       Access Identifiers (NAIs) in the EAP Identity Response message
       [draft-ietf-radext-rfc2486bis-03.txt] and by method-specific
       private identity exchange in the EAP method [16, 18, 19].
       Support for identity privacy within CHAP is not available.

    o  AAA protocols may return information from the home network to
       the visited in a manner that makes it possible to either identify
       the user or at least correlate his session with other sessions,
       such as the use of static data in a Class attribute [RFC 2865]
       or in some accounting attribute usage scenarios
       [draft-ietf-radext-chargeable-user-id-00.txt].

    o  Mobility mechanisms may reveal some permanent identifier
       (such as a home address) in cleartext in the packets relating
       to mobility signaling.

    o  Application protocols may reveal other permanent identifiers.

    Note that to prevent the correlation of identities with location
    information it is necessary to prevent leakage of identity
    information from all sources, not just one.

    Unfortunately, most users are not educated about the importance of
    identity confidentiality and there is a lack of support for it in
    many protocols. This problem is made worse by the fact that the
    users may be unable to choose particular protocols, as the choice
    is often dictated by the type of network they wish to access, the
    kind of equipment they have, or the type of authentication method
    they are using.

    A scenario where the user is attached to the home network is, from a
    privacy point of view, simpler than a scenario where a user roams
    into a visited network since the NAS and the home AAA are in the same
    administrative domain.  No direct relationship between the visited
    and the home network operator may be available and some AAA brokers
    need to be consulted.  With subscription-based network access as used
    today the user has a contractual relationship with the home network
    provider which could allow higher privacy considerations to be
    applied (including policy rules stored at the home network itself for
    the purpose of restricting further distribution).

    In many cases it is necessary to secure the transport of location
    information along the RADIUS infrastructure.  Mechanism to achieve
    this functionality are discussed in Section 15.

Does this work for you? Feel free to edit...

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 15:22:59 +0000
Date: Mon, 13 Dec 2004 17:22:22 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Geopriv] Radius-Geopriv: Method field

Tschofenig Hannes wrote:
> hi all, 
> 
> the method field determines how the location information was obtained.
> radius-geopriv reuses the list defined in pidf-lo. 
> 
> jari suggested to make the list a bit more technology independent. henning
> proposes to reference to the pdif-lo registry for the method. 
> 
> james winterbottom also suggested to change the listed values of the method
> field. 
>  
> my suggestion is that the geopriv-radius document should be aligned with
> pidf-lo. if there are some changes to the listed values in pdif-lo then we
> should update radius-geopriv as well. 

OK.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 15:19:44 +0000
Date: Mon, 13 Dec 2004 17:18:41 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Location Types

Tschofenig Hannes wrote:

> during the geopriv working group meeting we had a chance to discuss this
> issue and allison proposed to create a separate draft which contains the
> registry to avoid the dependency on the rpid draft.
> 
> we followed this suggestion and submit a draft which defines a registry for
> these location types. see
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-regist
> ry-00.txt. 
> 
> the next radius-geopriv version will reference this document. 

Great!

I have read your document, and it looks ready. Just one
minor nit in the IANA considerations section:

>    Usage of these tokens is not limited to XML.  However, it is expected
>    that XML imposes the most restrictions on the allowable syntax and
>    thus all tokens must conform to the rules for XML Names.

I wonder how the IANA is going to evaluate this (or do they need to?).
How about putting in a reference to where XML Names are defined, or
possibly including an ABNF on allowable syntax?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:44:03 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Method field
Date: Mon, 13 Dec 2004 10:06:14 +0100

hi all, 

the method field determines how the location information was obtained.
radius-geopriv reuses the list defined in pidf-lo. 

jari suggested to make the list a bit more technology independent. henning
proposes to reference to the pdif-lo registry for the method. 

james winterbottom also suggested to change the listed values of the method
field. 
 
my suggestion is that the geopriv-radius document should be aligned with
pidf-lo. if there are some changes to the listed values in pdif-lo then we
should update radius-geopriv as well. 

furthermore, we need to reference the pdif-lo registry with regard to the
method field. 

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:21:14 +0000
Date: Mon, 13 Dec 2004 11:20:14 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Tschofenig Hannes <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Radius-Geopriv: Time-to-Live field

Tschofenig Hannes wrote:
> hi all, 
> 
> jari commented that the draft currently lacks a clear definition of the term
> 'Time-to-Live'. 
> 
> this element was introduced with the geopriv requirements document (see rfc
> 3693).  
> 
> interestingly pdif-lo (see <draft-ietf-geopriv-pidf-lo-03.txt>) does not
> contain this field. 
> 
> hence, we have two options: 
> a) remove the field to align radius-geopriv with pdif-lo
> b) add a reference to the geopriv requirements document  
> 
> i suggest (after looking at the 'definition' of rfc 3693) to remove the
> field from the draft to have a better alignment with pdif-lo.  

This was not my original thought, but I'm fine with
this resolution. The less complex the protocol is,
the better...

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:09:24 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: User Identity Confidentiality
Date: Mon, 13 Dec 2004 10:06:15 +0100

hi all, 
hi jari,

jari provided input to the section about user identity confidentiality and
listed a few references that should replace some paragraphs. 

here is jari's comment:

>    One way to ensure that the visited network and intermediate networks
>    are incapable to learn the user identity is to use EAP methods that
>    hide the user's identity either actively or passively.  Some EAP
>    methods (such as [16]) protect the user's identity against passive
>    adversaries by utilizing temporal identities.  In some cases the
>    visited network is still able to retrieve the plaintext identity of
>    the user and user identity confidentiality is only provided against
>    eavesdroppers at the wireless link.  Depending on the movement
>    patters of the user, the network topology and available roaming
>    agreements it is possible that a AAA broker is able to see both the
>    plaintext user identity and subsequent temporal identities.
>    Associating location information and the user identity is possible in
>    these cases.
> 
>    It is assumed that the true username is not carried within the
>    initial EAP-Identity Request/Response message exchange.  Support for
>    username privacy is supported with [17].
> 
>    For stronger security and privacy protection active user identity
>    confidentiality is highly suggested.  EAP methods such as [18] or
>    [19] provide such a protection.
> 
>    Unfortunately, most users are not educated about the importance of
>    user identity confidentiality and many EAP methods do not provide
>    active user identity confidentiality.  User identity confidentiality
>    is often treated as an exotic feature which mainly aims to prevent
>    eavesdroppers on the wireless link to learn the user identity of the
>    attached users.  Awareness for this threat type does often not exist.
>    In many cases it is even not possible for users to freely select
>    their favorite authentication and key exchange protocol (based on
>    their security requirements).  Instead the choice is often
>    predetermined by a given architecture.

[jari]
There seems to be several problems with the above text. First of all, I do
not necessarily agree that [18] and [19] provide better identity privacy
than [16] and [17]. The privacy results depend highly on configuration in
all of the cases. For instance, [16] says that clients can refuse to give a
cleartext identity. Depending on configuration and back-end side
implementation, this is possible in some networks and not possible in some
others. Similarly, [18] depends highly on the configuration of the trusted
public key/CA.
If it is the single server's key then you are very safe. If its the Verisign
general purpose CA, anyone with a web side cert can get you to reveal your
identity.

The second issue is that this is IMHO the wrong document to talk about
identity privacy. You should talk about location privacy, but identity
privacy is a larger subject than something that EAP methods can do. For
instance, we have identity privacy problems at the MAC, EAP, PPP, IP, ND,
and application layers.

[hannes] jari suggests to remove the above text and associated references.

[hannes] the first issue: it is true that user identity confidentiality also
depends on the configuration of certain protocols (particularly if protocols
provide flexible mechanisms). in any case, authentication and key exchange
protocols which offer public key based authentication are able to provide
better user identity confidentiality than protocols which only use symmetric
keys. the latter protocols are only able to use temporal identities. 

[hannes] regarding the second issue: 'we should talk about location privacy
rather than user identity confidentiality'

here is my reasoning: 
* we would like to avoid that the visited network obtains the user's
identity and its location information. the visited network will obviously
always obtain the user's location information. hence, we should avoid that
it receives the user's identity. within the radius-geopriv document we can
only address aspects which are within the scope of radius (or diameter) and
certainly not within the scope of other protocols. 
* i know that user identity confidentiality is a difficult issue since you
need to deal with a number of identities at different layers and with
different protocols. i think it is worth stating that providing user id.
conf. within eap does not solve all issues. if you use ikev2 afterwards and
again reveal your true identity then you have again lost. 

i some sense this is not a problem for radius-geopriv, as such, since you
need to deal with this problem also if there is no radius-geopriv extension.

with regard to location privacy (what information is distributed to other
networks or entities by the home network) i tried to say a few words in
section 14. 
 
jari, what should i do? 

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:08:35 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Time-to-Live field
Date: Mon, 13 Dec 2004 10:06:14 +0100

hi all, 

jari commented that the draft currently lacks a clear definition of the term
'Time-to-Live'. 

this element was introduced with the geopriv requirements document (see rfc
3693).  

interestingly pdif-lo (see <draft-ietf-geopriv-pidf-lo-03.txt>) does not
contain this field. 

hence, we have two options: 
a) remove the field to align radius-geopriv with pdif-lo
b) add a reference to the geopriv requirements document  

i suggest (after looking at the 'definition' of rfc 3693) to remove the
field from the draft to have a better alignment with pdif-lo.  

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:08:09 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Civic vs. geospatial location information
Date: Mon, 13 Dec 2004 10:06:13 +0100

hi all, 

currently the document says that civic location information MUST be
provided. Jari proposed to change the MUST into a SHOULD.

we had a discussion on this issue during the geopriv meeting and i had the
impression that it is ok to change the MUST into a SHOULD. 

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:07:53 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: radius-geopriv wglc comments
Date: Mon, 13 Dec 2004 10:06:13 +0100

hi all, 

we have received a number of comments during the wglc on the radius-geopriv
document. thanks to the reviewers. 

in order to move forward with the document we have started to address the
raised issues. i will send mails on the individual issues to both, the
geopriv and the radiusext mailing list. 

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:07:37 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Location Types
Date: Mon, 13 Dec 2004 10:06:13 +0100

hi all, 

the draft version currently defines its own list of location types. jari
proposed to reuse the same registration as provided in
draft-ietf-simple-rpid-04.txt. i was already in contact with henning to
align the rpid location-type values with the geopriv-radius draft. 

during the geopriv working group meeting we had a chance to discuss this
issue and allison proposed to create a separate draft which contains the
registry to avoid the dependency on the rpid draft.

we followed this suggestion and submit a draft which defines a registry for
these location types. see
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-location-types-regist
ry-00.txt. 

the next radius-geopriv version will reference this document. 

additionally it was suggested to have more than one location type being set
(as used in the rpid draft). i think that this makes sense. 

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 13 Dec 2004 09:07:21 +0000
From: Tschofenig Hannes <[email-masked]>
To: [email-masked], [email-masked]
Subject: Radius-Geopriv: Note Well
Date: Mon, 13 Dec 2004 10:06:15 +0100

hi all, 

jari noted that the note well attribute should contain a URL reference. a
radius attribute is too short to carry a privacy relevant freetext. 

randall added that the reference should be expanded when it leaves the
radius network. 

i think it is a good idea to incorporate their proposals.

ciao
hannes

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 12 Dec 2004 16:44:01 +0000
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: open issues of draft-ietf-radext-digest-auth-00
Date: Sun, 12 Dec 2004 17:42:37 +0100
From: [email-masked] (Wolfgang Beck)

Issue 3
can't see what is missing in draft-ietf-digest-auth-00

Issue 5
3- replaced type String with Text were diameter-sip-app expects UTF-8
values
4- see Section 2.18
5- added indication where (not) to use quotes
6- Section "RADIUS Client Behaviour" now explain which
Authorization header a RADIUS client has to choose
7- removed the 32 octet limit in relevant attributes
8- mixing of nonce generation modes is no longer allowed, see last
paragraph of section "Overview"
9,10- removed the text about rejection of unsupported attributes
11- draft now requiers one Digest-Qop attribute per qop token

the reference to diameter-sip-app was moved to "Informative References"

Issue 6

To be honest, I did not find an RfC that describes how to
encrypt individual RADIUS attributes other than User-Password
and Tunnel-Password.

Issue 7

My interpretation of the list discussion was that the consensus was to make
the Message-Authenticator mandatory. I'll copy the relevant parts
of section 3.1 and 3.2 of RfC3579, as Bernard proposed.

I don't think that integrity protection of Access-Requests is really
a big issue. Carrying HTTP Digest over unprotected RADIUS can't be
worse than carrying it over unprotected HTTP or SIP. Digest-HA1 is the only
exception, because a MITM can 'sign' arbitrary HTTP-style responses.
Here is a proposal:
- Message-Authenticator is optional
- Digest-HA1 MUST be encrypted like User-Password, using a shared key.
That means, Digest-HA1 can be used with MD5, AKAv1-MD5; reliance
on IPSec is no longer needed (the requirement remains with sips /
https where all attributes would have to be encrypted).

Issue 11

To Jari: what is missing ?

Issue 30

To Jari: what is missing ?

Wolfgang

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 12 Dec 2004 04:01:27 +0000
Date: Sun, 12 Dec 2004 05:59:45 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Issue 7: Message Authenticator

Bernard Aboba wrote:

> In the meantime, are you saying that the Message-Authenticator attribute
> MUST be included in any message (Request, Challenge, Accept/Reject) containing
> attributes defined in this document, and that a RADIUS client or server
> receiving a message with the attribute MUST check it and MUST silently discard
> a packet that fails the check?

I think that is what needs to be done.

> I'm ok with this, assuming that the appropriate text can be developed and
> posted.

I'm OK with this too.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 22:33:54 +0000
Date: Sat, 11 Dec 2004 14:33:21 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Issue 7: Message Authenticator

Avi Lior said:

"Based on the comments received on this issue.
-It is important to have some sort of authenticator.
-Message Authenticator(80) is not busted - HMAC-MD5
-Digest Authentication is based on MD5 anyway.

I propose that we make Message-Authenticator(80) mandatory to protect the
Access-Requests."

I think you're making the case that improving the security beyond
MD5/Message-Authenticator is a bigger project than can be taken on in this
document, given the completion dates envisaged by 3GPP2 (e.g. yesterday).

Part of the issue is defining the goals of a more extended effort.  So
far, the goal that has been most mentioned is to enable RADIUS to achieve
FIPS compliance.  However, that is not a short-term goal since NIST has
not provided us with a list of required changes to RADIUS.  It is
conceivable that achieving FIPS certification for RADIUS might require
the removal of all MD5 usage from the RADIUS protocol (including zero'ing
out of the Response Authenticator field), and definition
of new authentication mechanisms and attributes for not involving MD5.

Those changes would in turn bring up backward compatibility issues which
would take some time to resolve.  So it's hard to get a handle on the
work required to achieve FIPS compliance at this time, although it
could be quite substantial.

In the meantime, are you saying that the Message-Authenticator attribute
MUST be included in any message (Request, Challenge, Accept/Reject) containing
attributes defined in this document, and that a RADIUS client or server
receiving a message with the attribute MUST check it and MUST silently discard
a packet that fails the check?

I'm ok with this, assuming that the appropriate text can be developed and
posted.  It might help to cite RFC 3579 text relating to
Message-Authentocator.   For example, in Section 3.1:

"     Therefore the Message-Authenticator attribute MUST be used to
      protect all Access-Request, Access-Challenge, Access-Accept, and
      Access-Reject packets containing an EAP-Message attribute.

      Access-Request packets including EAP-Message attribute(s) without
      a Message-Authenticator attribute SHOULD be silently discarded by
      the RADIUS server.  A RADIUS server supporting the EAP-Message
      attribute MUST calculate the correct value of the
      Message-Authenticator and MUST silently discard the packet if it
      does not match the value sent.  A RADIUS server not supporting the
      EAP-Message attribute MUST return an Access-Reject if it receives
      an Access-Request containing an EAP-Message attribute.

      Access-Challenge, Access-Accept, or Access-Reject packets
      including EAP-Message attribute(s) without a Message-Authenticator
      attribute SHOULD be silently discarded by the NAS.  A NAS
      supporting the EAP-Message attribute MUST calculate the correct
      value of the Message-Authenticator and MUST silently discard the
      packet if it does not match the value sent."

Section 3.2:

"3.2.  Message-Authenticator

      This attribute MAY be used to authenticate and integrity-protect
      Access-Requests in order to prevent spoofing.  It MAY be used in
      any Access-Request.  It MUST be used in any Access-Request,
      Access-Accept, Access-Reject or Access-Challenge that includes an
      EAP-Message attribute.

      A RADIUS server receiving an Access-Request with a
      Message-Authenticator attribute present MUST calculate the correct
      value of the Message-Authenticator and silently discard the packet
      if it does not match the value sent.

      A RADIUS client receiving an Access-Accept, Access-Reject or
      Access-Challenge with a Message-Authenticator attribute present
      MUST calculate the correct value of the Message-Authenticator and
      silently discard the packet if it does not match the value sent.

      This attribute is not required in Access-Requests which include
      the User-Password attribute, but is useful for preventing attacks
      on other types of authentication.  This attribute is intended to
      thwart attempts by an attacker to setup a "rogue" NAS, and perform
      online dictionary attacks against the RADIUS server.  It does not
      afford protection against "offline" attacks where the attacker
      intercepts packets containing (for example) CHAP challenge and
      response, and performs a dictionary attack against those packets
      offline."

BTW, I should also mention that the document is missing the traditional
"Table of Attributes" which states what packets various attributes can be
included in.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 08:23:55 +0000
Date: Sat, 11 Dec 2004 00:23:48 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review:  RFC 3576 MIBs

This is a request for review of the RFC 3576 MIB documents, prior to
considering these documents for adoption as RADEXT WG work items.

The documents are available for inspection here:
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-02.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-02.txt

Please post your review to the RADEXT WG mailing list
([email-masked]) using the format described on the RADEXT Issues
list:

http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 08:22:29 +0000
Date: Sat, 11 Dec 2004 00:22:23 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review:  RADIUS Redirection

This is a request for review of "RADIUS Redirection", prior to
considering this document for adoption as a RADEXT WG work item.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Please post your review to the RADEXT WG mailing list
([email-masked]) using the format described on the RADEXT Issues
list:

http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 08:21:36 +0000
Date: Sat, 11 Dec 2004 00:21:03 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Request for Review:  RADIUS Extensions for IEEE 802

This is a request for review of "RADIUS Extensions for IEEE 802", prior to
considering this document for adoption as a RADEXT WG work item.

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-02.txt

Please post your review to the RADEXT WG mailing list
([email-masked]) using the format described on the RADEXT Issues
list:

http://www.drizzle.com/~aboba/RADEXT/

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 05:41:33 +0000
content-class: urn:content-classes:message
Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00
Date: Sat, 11 Dec 2004 07:41:03 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi David,

This seems like a reasonable change. We can fix this in the next update.

cheers,
John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Nelson, David
> Sent: 10 December, 2004 19:32
> To: [email-masked]
> Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
>=20
>=20
> Description of issue: Use of Chargeable-User-ID attribute in
> Access-Request Messages
> Submitter name: Dave Nelson
> Submitter email address: [email-masked]
> Date first submitted: December 10, 2004
> Reference: (N/A)
> Document: draft-ietf-radext-chargeable-user-id-00.txt
> Comment type: T
> Priority: 1
> Section: 2.1
> Rationale/Explanation of issue:  Unless and until the RADEXT=20
> WG decides
> to enhance RADIUS to include Capabilities Negotiation (as it exists,
> e.g. in PPP), we need to continue to rely on Capabilities=20
> Advertisement.
> Advertisement has been a standardized part of RADIUS, in the form of
> "hint" attributes in Access-Request messages, since its inception.
> There has been discussion on the mailing list that suggests we ought
> define Capabilities Negotiation for new attributes that are considered
> mandatory (or conditionally mandatory) such as Chargeable-User-ID.  In
> order to drive this issue to a resolution, I am suggesting a change to
> the draft to make Capabilities Advertisement a strong SHOULD.
> Length description of problem:  (see above)
>=20
> Requested change: Change the following text in Section 2.1:
> =20
> From:
>=20
> "The NAS MAY include the CUI attribute with a null character for its
> data field in the Access-Request message to indicate its support for
> this attribute to the home RADIUS server.  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"."
>=20
> To:
>=20
> "The NAS SHOULD include the CUI attribute with a null=20
> character for its
> data field in the Access-Request message to indicate its support for
> this attribute to the home RADIUS server, unless deployment specific
> constraints dictate that the home RADIUS server has some=20
> other reliable
> means to determine that the NAS supports this attribute.  Such means
> might include out-of-band configuration.  In cases where the=20
> home RADIUS
> server cannot determine the NAS support for the CUI, if the=20
> 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"."
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 05:40:32 +0000
content-class: urn:content-classes:message
Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00
Date: Sat, 11 Dec 2004 07:39:46 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Thanks David, we'll get these addressed in the next update.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Nelson, David
> Sent: 10 December, 2004 20:17
> To: [email-masked]
> Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
>=20
>=20
> Description of issue: Editorial Nits
> Submitter name: Dave Nelson
> Submitter email address: [email-masked]
> Date first submitted: December 10, 2004
> Reference: (N/A)
> Document: draft-ietf-radext-chargeable-user-id-00.txt
> Comment type: E
> Priority: 1
> Section: <various>
>=20
> Requested changes:
>=20
> (1) /s/Chargeable User Identity/Chargeable-User-ID/
>=20
> This conforms to standard practice for RADIUS attribute name format.
>=20
> (2) Section 2.  Since RFC3576 is referenced in Section 2.1,=20
> it probably
> ought to be added to the list of RFCs in Section 2.
>=20
> (3) Section 2.1.  On page 6 the value of CUI-Type field "05 -=20
> reserved"
> should probably be "05-FF - reserved".
>=20
> (4) Section 4.  The IANA Considerations should also include:
>=20
>     -- a new value to be assigned for Error-Case attribute [RFC3576]
>=20
>     -- a mechanism for registering new values of CUI-Type (this
> document)
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 11 Dec 2004 02:58:07 +0000
Date: Fri, 10 Dec 2004 18:57:30 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00

> This version should address all the issues mentioned in
> http://www.drizzle.com/~aboba/RADEXT. I propose to mark those issues
> as closed.

A few words about process in the RADEXT WG:

a. Issues can be submitted by anyone, by putting [Issue] in the subject
line and using the format described on the RADEXT WG Issues Page, at
http://www.drizzle.com/~aboba/RADEXT/

It is expected that Issue submissions will include specific
recommendations on how the issue is to be addressed.  The burden is on the
submitter to describe what needs to be changed, rather than on the editor
to imagine what how the problem might be fixed.

b. The expectation is that the editor and other interested people will
respond to the issue posting with alternative resolutions, or perhaps an
argument as to why the Issue should be rejected.

c. After WG discussion has petered out, the Editor will make a specific
proposal as how to resolve the issue.  This will include the proposed
resolution text in its entirety.

d. In the next revision of the draft, the Editor will make the approved
changes.

In this particular case, we have asked the submitters to verify that their
issues have been closed.  Here are the results:

Issues 3 & 4: No answer from Miguel Garcia
Issue 5:      Issue known to be *not* closed (Miguel still working on it)
              Proposal to move the RADIUS/Diameter text to the Diameter
              document and remove normative reference on Diameter (Issue
              34)
Issue 6:      Peter McCann indicates that issue is not completely closed.
Issue 7:      Proposal from Avi Lior (Message-Authenticator) on the table.
Issue 8:      Jun indicates this issue is closed.
Issue 11:     Jari Arkko indicates the issue is still open.
Issue 30:     Jari Arkko indicates the issue is still open.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 21:16:25 +0000
Date: Fri, 10 Dec 2004 13:15:50 -0800
To: "Beck01, Wolfgang" <[email-masked]>, [email-masked]
From: Jun Wang <[email-masked]>
Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00
Cc: ac Mahendran <[email-masked]>, Avi Lior <[email-masked]>

Hi Wolfgang,

Thank you for the edits. My issue #8 and other issues were resolved by this 
version.

Jun Wang

At 12:56 PM 12/10/2004 +0100, Beck01, Wolfgang wrote:
>Hello,
>
>draft-ietf-radext-digest-auth-00 (successor of draft-sterman-aaa-sip-04)
>is now available
>(http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-00.txt).
>
>This version should address all the issues mentioned in
>http://www.drizzle.com/~aboba/RADEXT. I propose to mark those issues
>as closed.
>
>Wolfgang
>
>--
>T-Systems
>Internet Platforms
>+49 6151 937 2863
>Am Kavalleriesand 3
>64295 Darmstadt
>Germany
>
>--
>to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 18:17:20 +0000
Content-class: urn:content-classes:message
Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
Date: Fri, 10 Dec 2004 13:16:30 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Description of issue: Editorial Nits
Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: December 10, 2004
Reference: (N/A)
Document: draft-ietf-radext-chargeable-user-id-00.txt
Comment type: E
Priority: 1
Section: <various>

Requested changes:

(1) /s/Chargeable User Identity/Chargeable-User-ID/

This conforms to standard practice for RADIUS attribute name format.

(2) Section 2.  Since RFC3576 is referenced in Section 2.1, it probably
ought to be added to the list of RFCs in Section 2.

(3) Section 2.1.  On page 6 the value of CUI-Type field "05 - reserved"
should probably be "05-FF - reserved".

(4) Section 4.  The IANA Considerations should also include:

    -- a new value to be assigned for Error-Case attribute [RFC3576]

    -- a mechanism for registering new values of CUI-Type (this
document)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 17:41:21 +0000
Content-class: urn:content-classes:message
Subject: Issue -- draft-ieft-radext-chargeable-user-id-00
Date: Fri, 10 Dec 2004 12:31:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Description of issue: Use of Chargeable-User-ID attribute in
Access-Request Messages
Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: December 10, 2004
Reference: (N/A)
Document: draft-ietf-radext-chargeable-user-id-00.txt
Comment type: T
Priority: 1
Section: 2.1
Rationale/Explanation of issue:  Unless and until the RADEXT WG decides
to enhance RADIUS to include Capabilities Negotiation (as it exists,
e.g. in PPP), we need to continue to rely on Capabilities Advertisement.
Advertisement has been a standardized part of RADIUS, in the form of
"hint" attributes in Access-Request messages, since its inception.
There has been discussion on the mailing list that suggests we ought
define Capabilities Negotiation for new attributes that are considered
mandatory (or conditionally mandatory) such as Chargeable-User-ID.  In
order to drive this issue to a resolution, I am suggesting a change to
the draft to make Capabilities Advertisement a strong SHOULD.
Length description of problem:  (see above)

Requested change: Change the following text in Section 2.1:
=20
From:

"The NAS MAY include the CUI attribute with a null character for its
data field in the Access-Request message to indicate its support for
this attribute to the home RADIUS server.  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"."

To:

"The NAS SHOULD include the CUI attribute with a null character for its
data field in the Access-Request message to indicate its support for
this attribute to the home RADIUS server, unless deployment specific
constraints dictate that the home RADIUS server has some other reliable
means to determine that the NAS supports this attribute.  Such means
might include out-of-band configuration.  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"."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 16:42:20 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Fri, 10 Dec 2004 11:41:02 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Lothar Reith writes (still in HTML!)...

> to a) what would be "the appropriate helpdesk" in a WLAN roaming
> scenario ?

This is an important question for those in the "roaming consortium" =
business, as well as home ISPs, to answer.  I remember the "bad old =
days" before seamless roaming for cellular telephony. Only the brave and =
the technically savvy were able to use roaming services effectively.  =
Today, I expect to be able to dial 611 on my cell phone wherever I am =
and get appropriate assistance. (Of course, talking to a human still =
requires an Act of Congress -- but I digress :-)  If WLAN roaming wants =
to be successful, IMHO, the industry needs to make it as transparent as =
cellular roaming.

> Also, should the error message say: did not support CUI or perhaps
> supports CUI but did not advertise ?=20

You seem to think the "supports CUI but did not advertise" scenario is =
reasonable, and I disagree. I really can't comment, other than to repeat =
myself.

> A related question is if the server counts an authentication request
> rejected due to missing knowledge about the NASes CUI support=A0as an
> unsuccessful login attempt with regards to security thresholds ?

That is likely an implementation decision.  Personally, I would tend to =
count it as "failed to meet policy requirements" as apposed to "failed =
to authenticate".

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 16:27:09 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Fri, 10 Dec 2004 17:26:32 +0100

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DED5.027DCA18
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,

let me add a few points to stimulate discussion at this important =
junction.

to a) what would be "the appropriate helpdesk" in a WLAN roaming =
scenario ?=20
a1) the telephone number of the home service provider ? He did nothing
wrong.
a2) the telephone number of the mediator ?  He should be ashamed to =
have a
contractual relation with an access-network provider not supporting CUI =
;)
a3) the network access provider ? How to find out his number lets say =
in an
airport, in order to complain that he does not appropriately facilitate
roaming privacy or some other application of CUI ?=20

Also, should the error message say: did not support CUI or perhaps =
supports
CUI but did not advertise ?

A related question is if the server counts an authentication request
rejected due to missing knowledge about the NASes CUI support  as an
unsuccessfull login attempt with regards to security thresholds ?=20

Lothar

-----Urspr=FCngliche Nachricht-----
Von: Reith, Lothar [HAHN:NGD:EXCH]=20
Gesendet: Mittwoch, 8. Dezember 2004 21:46
An: 'Nelson, David'; [email-masked]'
Betreff: AW: backwards compatible introduction of NEW attribute such as =
CUI

David,

good point.

I like to add to your list:
(d): print a readable text message to the user (human) that may =
stimulate a
user reaction leading to a successfull authentication in an unmodified =
or
modified second attempt.

By the way:
b) is what I had proposed in the first place. This would allow a NAS to
advertise CUI on an as needed basis. After all, initially CUI =
advertisement
may be superfluous in 99,9999999999% of all cases.=20

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Mittwoch, 8. Dezember 2004 20:47
An: [email-masked]
Betreff: RE: backwards compatible introduction of NEW attribute such as =
CUI

Farid Adrangi writes...

> One possibility is to add a new value indicating Missing-CUI-Support
to
> Error-Cause attribute defined in RFC3576.   We most likely need to
define
> specific values for other attributes (e.g., RADIUS location
attributes) as
> Lothar pointed out.  Another possibility is to use the error-code
defined
> in draft-zorn-radius-err-msg-01.txt.  But, The draft is not a WG item
so
> and I am not sure if we can use it for our purpose at this point.
What
> is your thought on this?

I think we should back up and decide what function the error reporting =
is
intended to serve.  What component is the ultimate consumer of the
information?

Is the intent to:

(a) print a readable text message to the user (human) that will =
stimulate an
informed call to the appropriate help desk,  or

(b) instruct the NAS to perform a different form of authentication =
request,
or include different attributes, or

(c) stimulate the NAS to perform an automatic, on-line, firmware =
upgrade to
acquire the missing, but desired, functionality?

If the desire is (a), a simple, printable message that describes the
authentication policy conditions that are not being met (in layman's
terms) would be appropriate.

If the desire is (b), I offer two further observations.  (1) If the NAS
supported the desired attribute (and was configured to provide it) it =
would
probably have done so in the first instance.  Unassisted corrective =
action
is unlikely. (2) If we are talking about introducing PPP-style
capabilities/option negotiation, I still think that is a slippery slope =
and
a substantial effort to get it right and obtain interoperability.

If the desire is (c) I'd like to buy one, please.  :-)

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4DED5.027DCA18
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>let me add a few points to stimulate discussion at =
this important junction.</FONT>
</P>

<P><FONT SIZE=3D2>to a) what would be &quot;the appropriate =
helpdesk&quot; in a WLAN roaming scenario ? </FONT>
<BR><FONT SIZE=3D2>a1) the telephone number of the home service =
provider ? He did nothing wrong.</FONT>
<BR><FONT SIZE=3D2>a2) the telephone number of the mediator ?&nbsp; He =
should be ashamed to have a contractual relation with an access-network =
provider not supporting CUI ;)</FONT></P>

<P><FONT SIZE=3D2>a3) the network access provider ? How to find out his =
number lets say in an airport, in order to complain that he does not =
appropriately facilitate roaming privacy or some other application of =
CUI ? </FONT></P>

<P><FONT SIZE=3D2>Also, should the error message say: did not support =
CUI or perhaps supports CUI but did not advertise ?</FONT>
</P>

<P><FONT SIZE=3D2>A related question is if the server counts an =
authentication request rejected due to missing knowledge about the =
NASes CUI support&nbsp; as an unsuccessfull login attempt with regards =
to security thresholds ? </FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: Reith, Lothar [HAHN:NGD:EXCH] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Mittwoch, 8. Dezember 2004 21:46</FONT>
<BR><FONT SIZE=3D2>An: 'Nelson, David'; [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Betreff: AW: backwards compatible introduction of =
NEW attribute such as CUI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>good point.</FONT>
</P>

<P><FONT SIZE=3D2>I like to add to your list:</FONT>
<BR><FONT SIZE=3D2>(d): print a readable text message to the user =
(human) that may stimulate a user reaction leading to a successfull =
authentication in an unmodified or modified second attempt.</FONT></P>

<P><FONT SIZE=3D2>By the way:</FONT>
<BR><FONT SIZE=3D2>b) is what I had proposed in the first place. This =
would allow a NAS to advertise CUI on an as needed basis. After all, =
initially CUI advertisement may be superfluous in 99,9999999999% of all =
cases. </FONT></P>
<BR>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Mittwoch, 8. Dezember 2004 20:47</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: backwards compatible introduction of =
NEW attribute such as CUI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Farid Adrangi writes...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; One possibility is to add a new value indicating =
Missing-CUI-Support</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>&gt; Error-Cause attribute defined in =
RFC3576.&nbsp;&nbsp; We most likely need to</FONT>
<BR><FONT SIZE=3D2>define</FONT>
<BR><FONT SIZE=3D2>&gt; specific values for other attributes (e.g., =
RADIUS location</FONT>
<BR><FONT SIZE=3D2>attributes) as</FONT>
<BR><FONT SIZE=3D2>&gt; Lothar pointed out.&nbsp; Another possibility =
is to use the error-code</FONT>
<BR><FONT SIZE=3D2>defined</FONT>
<BR><FONT SIZE=3D2>&gt; in draft-zorn-radius-err-msg-01.txt.&nbsp; But, =
The draft is not a WG item</FONT>
<BR><FONT SIZE=3D2>so</FONT>
<BR><FONT SIZE=3D2>&gt; and I am not sure if we can use it for our =
purpose at this point.</FONT>
<BR><FONT SIZE=3D2>What</FONT>
<BR><FONT SIZE=3D2>&gt; is your thought on this?</FONT>
</P>

<P><FONT SIZE=3D2>I think we should back up and decide what function =
the error reporting is intended to serve.&nbsp; What component is the =
ultimate consumer of the information?</FONT></P>

<P><FONT SIZE=3D2>Is the intent to:</FONT>
</P>

<P><FONT SIZE=3D2>(a) print a readable text message to the user (human) =
that will stimulate an informed call to the appropriate help =
desk,&nbsp; or</FONT></P>

<P><FONT SIZE=3D2>(b) instruct the NAS to perform a different form of =
authentication request, or include different attributes, or</FONT>
</P>

<P><FONT SIZE=3D2>(c) stimulate the NAS to perform an automatic, =
on-line, firmware upgrade to acquire the missing, but desired, =
functionality?</FONT></P>

<P><FONT SIZE=3D2>If the desire is (a), a simple, printable message =
that describes the authentication policy conditions that are not being =
met (in layman's</FONT></P>

<P><FONT SIZE=3D2>terms) would be appropriate.</FONT>
</P>

<P><FONT SIZE=3D2>If the desire is (b), I offer two further =
observations.&nbsp; (1) If the NAS supported the desired attribute (and =
was configured to provide it) it would probably have done so in the =
first instance.&nbsp; Unassisted corrective action is unlikely. (2) If =
we are talking about introducing PPP-style capabilities/option =
negotiation, I still think that is a slippery slope and a substantial =
effort to get it right and obtain interoperability.</FONT></P>

<P><FONT SIZE=3D2>If the desire is (c) I'd like to buy one, =
please.&nbsp; :-)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DED5.027DCA18--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 15:39:21 +0000
Content-class: urn:content-classes:message
Subject: RE: Issues List Revision, draft-ietf-radext-digest-auth-00
Date: Fri, 10 Dec 2004 10:36:29 -0500
From: "Nelson, David" <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>, <[email-masked]>

Wolfgang Beck writes...

> This version should address all the issues mentioned in
> http://www.drizzle.com/~aboba/RADEXT. I propose to mark those issues
> as closed.

It would be helpful if you could identify the relevant sections of text
in=20
draft-ietf-radext-digest-auth-00 that resolve each of the open issues.
A general assertion that all issues are addressed places the burden on
the commenters to search for the potential resolution in the revised
draft.  Providing pointers would be appreciated.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 11:57:16 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00
Date: Fri, 10 Dec 2004 12:56:14 +0100

Hello,

draft-ietf-radext-digest-auth-00 (successor of draft-sterman-aaa-sip-04)
is now available
(http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-00.txt).

This version should address all the issues mentioned in
http://www.drizzle.com/~aboba/RADEXT. I propose to mark those issues
as closed.

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 10 Dec 2004 01:01:16 +0000
Date: Thu, 9 Dec 2004 19:00:20 -0600
From: Pete McCann <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Issues List Revision

Hi,

I went back to review the status of Issue 6.  It looks to me like it
is all ok in draft-ietf-radext-digest-auth-00.txt except for the
security related issue.  The proposed resolution from Wolfgang is ok
with me but I don't see the promised reference to the security
considerations.

One additional comment inserted into Wolfgang's text below...

Wolfgang Beck wrote:

> > The following is confusing:
> >
> > 3.1  RADIUS Client Behaviour
> >
> >    A RADIUS client without an encrypted or otherwise secured connection
> >    to its RADIUS server only accepts unsecured connections from its
> >    HTTP-style clients (or else the clients would have a false sense of
> >    security).
> >
> > It is not quite clear what is meant by "encrypted or otherwise
> > secured", because there are several different security mechanisms
> > available in RADIUS, including the hop-by-hop message authenticator
> > and the shared-key method of obfuscating individual attributes.  I
>
> "encrypted" ~ eg. IPSEC or proprietary tunnel technology
> "otherwise secured" ~ eg. RADIUS client and server are in a closed MPLS
> VPN.

Can you make it clear in this text that the shared-key method for
encrypting individual attributes is not acceptable in this case?

> > assume this would not be adequate to provide the protection you are
> > looking for.  Also, what counts as an "unsecured connection" from an
> > HTTP-style client?  Do you mean one that doesn't use either TLS or
> > IPSec?
>
> Yes. I'll insert a reference to the security considerations section,
> which has this paragraph:
>   "HTTP-style clients can use TLS with server side certificates together
>    with HTTP-Digest authentication.  IPSec can be used in a similar way.
>    TLS or IPSec secure the connection while Digest Authentication
>    authenticates the user.  If a RADIUS client accepts such connections,
>    it MUST have a secure connection to the RADIUS server."
> 
> > Maybe this paragraph is adequately covered by the security
> > considerations (or should be) and could be deleted.
>
> I disagree. If a SIP client wants the signalling to be secure,
> it uses sips: URLs. All SIP proxies along the way must use TLS
> connections to forward requests with sips: URLs. I don't think
> the SIP proxies (=RADIUS clients) should expose parts of the SIP
> message by using a unencrypted RADIUS messages in this case.
> 
> As this is part of the client behaviour, I put it into that section.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Dec 2004 23:53:32 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: [draft-ietf-radext-digest-auth-00 - ISSUE 7] Message Authenticato r
Date: Thu, 9 Dec 2004 18:52:34 -0500 

Based on the comments received on this issue.
-It is important to have some sort of authenticator.
-Message Authenticator(80) is not busted - HMAC-MD5
-Digest Authentication is based on MD5 anyway.

I propose that we make Message-Authenticator(80) mandatory to protect the
Access-Requests.

------------------------------------------------
Avi Lior                                    
Bridgewater Systems Corporation                
Phone :  (613) 591-9104 x6417
Cell    :  (613) 297-2177
E-mail : mailto:[email-masked]
www.bridgewatersystems.com 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Dec 2004 19:18:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Version 03 of CUI
Date: Thu, 9 Dec 2004 11:17:58 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Sorry, I forgot that the work was accepted as a WG item :-)  I changed
the name and resubmitted the draft.  Here is the new link to the draft:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i
d-00.txt
BR,
Farid

> -----Original Message-----
> From: Adrangi, Farid=20
> Sent: Thursday, December 09, 2004 10:27 AM
> To: [email-masked]'
> Subject: Version 03 of CUI
>=20
>=20
> Hi all,
> 03 version of CUI has been submitted. It does yet appear in=20
> I-D repository, but you can find it here:
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
> geable-user-id-03.txt.
>=20
> This version includes resolutions to issues 13 (David=20
> Mariblanca), 14 (Bernard Aboba), 18 (Greg Weber), 21 (Barney=20
> Wolff), and 22 (Barney Wolff) in RADIUS issues tracker=20
> (http://www.drizzle.com/~aboba/RADEXT/#Issue%2014). =20
>=20
> Thanks to all reviewers - we appreciate your feedback and guidance.
>=20
> BR,
> Farid
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Dec 2004 18:27:26 +0000
Content-class: urn:content-classes:message
Subject: Version 03 of CUI
Date: Thu, 9 Dec 2004 10:26:53 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Hi all,
03 version of CUI has been submitted. It does yet appear in I-D
repository, but you can find it here:
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-use
r-id-03.txt.

This version includes resolutions to issues 13 (David Mariblanca), 14
(Bernard Aboba), 18 (Greg Weber), 21 (Barney Wolff), and 22 (Barney
Wolff) in RADIUS issues tracker
(http://www.drizzle.com/~aboba/RADEXT/#Issue%2014). =20

Thanks to all reviewers - we appreciate your feedback and guidance.

BR,
Farid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 09 Dec 2004 11:05:31 +0000
content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Thu, 9 Dec 2004 13:03:42 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

David,

> (a) print a readable text message to the user (human) that will
> stimulate an informed call to the appropriate help desk,  or
>=20
> (b) instruct the NAS to perform a different form of authentication
> request, or include different attributes, or
>=20
> (c) stimulate the NAS to perform an automatic, on-line,=20
> firmware upgrade
> to acquire the missing, but desired, functionality?
>=20
> If the desire is (a), a simple, printable message that describes the
> authentication policy conditions that are not being met (in layman's
> terms) would be appropriate.
>=20
> If the desire is (b), I offer two further observations.  (1) If the =
NAS
> supported the desired attribute (and was configured to provide it) it
> would probably have done so in the first instance.  Unassisted
> corrective action is unlikely. (2) If we are talking about introducing
> PPP-style capabilities/option negotiation, I still think that is a
> slippery slope and a substantial effort to get it right and obtain
> interoperability.
>=20
> If the desire is (c) I'd like to buy one, please.  :-)

I think a) is definately the case, b) may be applicable if the NAS can =
support
'classic' authentication mechanisms and CUI authentication.   However, =
if the
NAS does not support CUI, then the proper outcome would be a).

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 20:47:12 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: backwards compatible introduction of NEW attribute such as CU I
Date: Wed, 8 Dec 2004 21:46:30 +0100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DD66.FECB1EC6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

David,

good point.

I like to add to your list:
(d): print a readable text message to the user (human) that may =
stimulate a
user reaction leading to a successfull authentication in an unmodified =
or
modified second attempt.

By the way:
b) is what I had proposed in the first place. This would allow a NAS to
advertise CUI on an as needed basis. After all, initially CUI =
advertisement
may be superfluous in 99,9999999999% of all cases.=20

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Mittwoch, 8. Dezember 2004 20:47
An: [email-masked]
Betreff: RE: backwards compatible introduction of NEW attribute such as =
CUI

Farid Adrangi writes...

> One possibility is to add a new value indicating Missing-CUI-Support
to
> Error-Cause attribute defined in RFC3576.   We most likely need to
define
> specific values for other attributes (e.g., RADIUS location
attributes) as
> Lothar pointed out.  Another possibility is to use the error-code
defined
> in draft-zorn-radius-err-msg-01.txt.  But, The draft is not a WG item
so
> and I am not sure if we can use it for our purpose at this point.
What
> is your thought on this?

I think we should back up and decide what function the error reporting =
is
intended to serve.  What component is the ultimate consumer of the
information?

Is the intent to:

(a) print a readable text message to the user (human) that will =
stimulate an
informed call to the appropriate help desk,  or

(b) instruct the NAS to perform a different form of authentication =
request,
or include different attributes, or

(c) stimulate the NAS to perform an automatic, on-line, firmware =
upgrade to
acquire the missing, but desired, functionality?

If the desire is (a), a simple, printable message that describes the
authentication policy conditions that are not being met (in layman's
terms) would be appropriate.

If the desire is (b), I offer two further observations.  (1) If the NAS
supported the desired attribute (and was configured to provide it) it =
would
probably have done so in the first instance.  Unassisted corrective =
action
is unlikely. (2) If we are talking about introducing PPP-style
capabilities/option negotiation, I still think that is a slippery slope =
and
a substantial effort to get it right and obtain interoperability.

If the desire is (c) I'd like to buy one, please.  :-)

--
to unsubscribe send a message to [email-masked] with =
the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4DD66.FECB1EC6
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>good point.</FONT>
</P>

<P><FONT SIZE=3D2>I like to add to your list:</FONT>
<BR><FONT SIZE=3D2>(d): print a readable text message to the user =
(human) that may stimulate a user reaction leading to a successfull =
authentication in an unmodified or modified second attempt.</FONT></P>

<P><FONT SIZE=3D2>By the way:</FONT>
<BR><FONT SIZE=3D2>b) is what I had proposed in the first place. This =
would allow a NAS to advertise CUI on an as needed basis. After all, =
initially CUI advertisement may be superfluous in 99,9999999999% of all =
cases. </FONT></P>
<BR>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Mittwoch, 8. Dezember 2004 20:47</FONT>
<BR><FONT SIZE=3D2>An: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: backwards compatible introduction of =
NEW attribute such as CUI</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Farid Adrangi writes...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; One possibility is to add a new value indicating =
Missing-CUI-Support</FONT>
<BR><FONT SIZE=3D2>to</FONT>
<BR><FONT SIZE=3D2>&gt; Error-Cause attribute defined in =
RFC3576.&nbsp;&nbsp; We most likely need to</FONT>
<BR><FONT SIZE=3D2>define</FONT>
<BR><FONT SIZE=3D2>&gt; specific values for other attributes (e.g., =
RADIUS location</FONT>
<BR><FONT SIZE=3D2>attributes) as</FONT>
<BR><FONT SIZE=3D2>&gt; Lothar pointed out.&nbsp; Another possibility =
is to use the error-code</FONT>
<BR><FONT SIZE=3D2>defined</FONT>
<BR><FONT SIZE=3D2>&gt; in draft-zorn-radius-err-msg-01.txt.&nbsp; But, =
The draft is not a WG item</FONT>
<BR><FONT SIZE=3D2>so</FONT>
<BR><FONT SIZE=3D2>&gt; and I am not sure if we can use it for our =
purpose at this point.</FONT>
<BR><FONT SIZE=3D2>What</FONT>
<BR><FONT SIZE=3D2>&gt; is your thought on this?</FONT>
</P>

<P><FONT SIZE=3D2>I think we should back up and decide what function =
the error reporting is intended to serve.&nbsp; What component is the =
ultimate consumer of the information?</FONT></P>

<P><FONT SIZE=3D2>Is the intent to:</FONT>
</P>

<P><FONT SIZE=3D2>(a) print a readable text message to the user (human) =
that will stimulate an informed call to the appropriate help =
desk,&nbsp; or</FONT></P>

<P><FONT SIZE=3D2>(b) instruct the NAS to perform a different form of =
authentication request, or include different attributes, or</FONT>
</P>

<P><FONT SIZE=3D2>(c) stimulate the NAS to perform an automatic, =
on-line, firmware upgrade to acquire the missing, but desired, =
functionality?</FONT></P>

<P><FONT SIZE=3D2>If the desire is (a), a simple, printable message =
that describes the authentication policy conditions that are not being =
met (in layman's</FONT></P>

<P><FONT SIZE=3D2>terms) would be appropriate.</FONT>
</P>

<P><FONT SIZE=3D2>If the desire is (b), I offer two further =
observations.&nbsp; (1) If the NAS supported the desired attribute (and =
was configured to provide it) it would probably have done so in the =
first instance.&nbsp; Unassisted corrective action is unlikely. (2) If =
we are talking about introducing PPP-style capabilities/option =
negotiation, I still think that is a slippery slope and a substantial =
effort to get it right and obtain interoperability.</FONT></P>

<P><FONT SIZE=3D2>If the desire is (c) I'd like to buy one, =
please.&nbsp; :-)</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DD66.FECB1EC6--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 19:49:18 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 8 Dec 2004 14:47:29 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Farid Adrangi writes...

> One possibility is to add a new value indicating Missing-CUI-Support
to
> Error-Cause attribute defined in RFC3576.   We most likely need to
define
> specific values for other attributes (e.g., RADIUS location
attributes) as
> Lothar pointed out.  Another possibility is to use the error-code
defined
> in draft-zorn-radius-err-msg-01.txt.  But, The draft is not a WG item
so
> and I am not sure if we can use it for our purpose at this point.
What
> is your thought on this?

I think we should back up and decide what function the error reporting
is intended to serve.  What component is the ultimate consumer of the
information?

Is the intent to:

(a) print a readable text message to the user (human) that will
stimulate an informed call to the appropriate help desk,  or

(b) instruct the NAS to perform a different form of authentication
request, or include different attributes, or

(c) stimulate the NAS to perform an automatic, on-line, firmware upgrade
to acquire the missing, but desired, functionality?

If the desire is (a), a simple, printable message that describes the
authentication policy conditions that are not being met (in layman's
terms) would be appropriate.

If the desire is (b), I offer two further observations.  (1) If the NAS
supported the desired attribute (and was configured to provide it) it
would probably have done so in the first instance.  Unassisted
corrective action is unlikely. (2) If we are talking about introducing
PPP-style capabilities/option negotiation, I still think that is a
slippery slope and a substantial effort to get it right and obtain
interoperability.

If the desire is (c) I'd like to buy one, please.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 19:13:07 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 8 Dec 2004 11:12:37 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi David, all

Revisiting this issue ...

> > > Error-Cause=A0attribute [RFC3576] with value 402 (decimal),=20
> "Missing=20
> > > Attribute".
> >=20
> > DBN:  Would it be preferable to create a new value of=20
> > Error-Cause to more specifically describe the=20
> > incompatibility?  While Missing-CUI might be too specific,=20
> > Missing Attribute is quite broad.
> >=20
>=20

One possibility is to add a new value indicating Missing-CUI-Support to =
Error-Cause attribute defined in RFC3576.   We most likely need to =
define specific values for other attributes (e.g., RADIUS location =
attributes) as Lothar pointed out.  Another possibility is to use the =
error-code defined in draft-zorn-radius-err-msg-01.txt.  But, The draft =
is not a WG item so and I am not sure if we can use it for our purpose =
at this point.   What is your thought on this?

BR,
Farid=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 18:35:02 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 8 Dec 2004 10:34:05 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Lothar Reith" <[email-masked]>
Cc: <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DD54.7F65A6E3
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Lothar,
Thanks.  Please see my comments inline.
BR,
Farid

	other comments:=20
	- in your draft text-snippet, I would recommend to totally drop
or replace the part-sentence: "if the CUI is required for proper
billing"=20

	with:=20
	"if the home RADIUS server considers CUI support of the NAS to
be required for any reason, for example for billing or charging
purposes" =20

	FA:  Agree.  Good suggestion.

	- another Question similar to David's question raised earlier:
How shall a NAS determine from the error cause value 402 (decimal),
"Missing Attribute", if the missing attribute is the CUI attribute or
some other attribute such as GEOPRIV ?=20

	FA:  Yes I have already agreed with David's point. =20

	Question: Instead of allocating a new error code for every new
attribute, would it not be better to adopt a general approach, which
allows to include the missing attribute(s)in a Reject message with error
cause 402 ? This may even allow to include multiple NEW attributes such
as CUI and GEOPRIV in the event that the home network requires both.
Also, we would not need another error cause for every new attribute of
this kind, let alone error codes for combined missings, or a precedence
setting which attribute is to be preferred to be indicated in the error
cause if multiple attributes are missing.=20

	FA: one possibility is to use error-code attribute defined in
draft-zorn-radius-err-msg-01.txt -- what do you think?=20

	Farid wrote as part of the snippet:=20
	 if the NAS supports the CUI attribute the CUI attribute will
override the identity portion the UserName (1) attribute.  =20

	Lothar: what exactly means "override the identity portion of the
UserName" ? Do you mean it in the sense of "overwrite", that the CUI
will be combined with the realm portion of the NAI ? =20

	FA: No.  it means that the UserName(1) attribute will be used
for routing and the CUI attribute will be used for identity purposes.=20

	 In this context, maybe it would be usefull to clarify the
significance of the identifier which we refer to as CUI or
Chargeable-user-identity, i.e. if the home-network provider should
always be able to resolve a CUI, or if it is allowed that he also
requires other information present in the RADIUS accounting data (such
as the realm portion of the NAI) to be able to resolve the CUI to the
identity of the user.=20

	Farid wrote:=20
	Before we get into developing a protocol (as suggested below) to
determine the CUI support, I would like to know why the above paragraph
does not address the backward compatibility problem.=20

	Lothar:=20
	- I agree, that the text adresses the backward compatibility
problem.=20

	I hope that the choosen approach of "always advertise" will be
widely adopted - I still have some concern regarding the following
"chicken and egg" problem: Users will not see CUI benefits (in
particular roaming-privacy) until a critical mass of
network-access-providers adopts CUI with always advertise policy.
Network-access-operators may hesitate to introduce an always-advertise
CUI policy before seeing any evidence that a critical mass of users is
requesting it.=20

	FA: BTW, the text (the snippet that I sent you) does not say
"always advertise".  The NAS MAY advertise ....

	=20

	=20

	Lothar=20

------_=_NextPart_001_01C4DD54.7F65A6E3
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D290281218-08122004><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Lothar,</FONT></SPAN></DIV>
<DIV><SPAN class=3D290281218-08122004><FONT face=3DArial color=3D#0000ff =

size=3D2>Thanks.&nbsp; Please see my comments =
inline.</FONT></SPAN></DIV>
<DIV><SPAN class=3D290281218-08122004><FONT face=3DArial color=3D#0000ff =

size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D290281218-08122004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <P><FONT size=3D2>other comments:</FONT> <BR><FONT size=3D2>- in your =
draft=20
  text-snippet, I would recommend to totally drop or replace the =
part-sentence:=20
  "if the CUI is required for proper billing" </FONT></P>
  <P><FONT size=3D2>with:</FONT> <BR><FONT size=3D2>"if the home RADIUS =
server=20
  considers CUI support of the NAS to be required for any reason, for =
example=20
  for billing or charging purposes"&nbsp;<SPAN =
class=3D290281218-08122004><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D290281218-08122004><SPAN=20
  class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>FA:&nbsp;</FONT>&nbsp;<FONT face=3DArial=20
  color=3D#0000ff>Agree.&nbsp; Good =
suggestion.</FONT></SPAN></SPAN></FONT></P>
  <P><FONT size=3D2>- another Question similar to David's question =
raised=20
  earlier:&nbsp;&nbsp; How shall a NAS determine from the error cause =
value 402=20
  (decimal), "Missing Attribute", if the missing attribute is the CUI =
attribute=20
  or some other attribute such as GEOPRIV ?<SPAN =
class=3D290281218-08122004><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>FA: </FONT>&nbsp;<FONT face=3DArial =
color=3D#0000ff>Yes I have=20
  already agreed with David's point.&nbsp; </FONT></SPAN></FONT></P>
  <P><FONT size=3D2>Question: Instead of allocating a new error code for =
every new=20
  attribute, would it not be better to adopt a general approach, which =
allows to=20
  include the missing attribute(s)in a Reject message with error cause =
402 ?=20
  This may even allow to include multiple NEW attributes such as CUI and =
GEOPRIV=20
  in the event that the home network requires both. Also, we would not =
need=20
  another error cause for every new attribute of this kind, let alone =
error=20
  codes for combined missings, or a precedence setting which attribute =
is to be=20
  preferred to be indicated in the error cause if multiple attributes =
are=20
  missing.<SPAN class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>FA: </FONT><FONT face=3DArial color=3D#0000ff>one =
possibility is to=20
  use error-code attribute defined in draft-zorn-radius-err-msg-01.txt =
-- what=20
  do you think?&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>Farid wrote as part of the snippet:</FONT> <BR><FONT =

  size=3D2>&nbsp;if the NAS supports the CUI attribute the CUI attribute =
will=20
  override the identity portion the UserName (1) =
attribute.</FONT>&nbsp;<SPAN=20
  class=3D290281218-08122004><FONT face=3DArial color=3D#0000ff=20
  size=3D2>&nbsp;</FONT></SPAN><SPAN =
class=3D290281218-08122004>&nbsp;</SPAN></P>
  <P><FONT size=3D2>Lothar: what exactly means "override the identity =
portion of=20
  the UserName" ? Do you mean it in the sense of "overwrite", that the =
CUI will=20
  be combined with the realm portion of the NAI ?&nbsp;<SPAN=20
  class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D290281218-08122004>FA:=20
  No.&nbsp; it means that the UserName(1) attribute will be used for =
routing and=20
  the CUI attribute will be used for identity purposes.<FONT=20
  face=3D"Times New Roman" =
color=3D#000000>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D290281218-08122004>&nbsp;</SPAN>In =
this context,=20
  maybe it would be usefull to clarify the significance of the =
identifier which=20
  we refer to as CUI or Chargeable-user-identity, i.e. if the =
home-network=20
  provider should always be able to resolve a CUI, or if it is allowed =
that he=20
  also requires other information present in the RADIUS accounting data =
(such as=20
  the realm portion of the NAI) to be able to resolve the CUI to the =
identity of=20
  the user.<SPAN class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>Farid wrote:</FONT> <BR><FONT size=3D2>Before we get =
into=20
  developing a protocol (as suggested below) to determine the CUI =
support, I=20
  would like to know why the above paragraph does not address the =
backward=20
  compatibility problem. </FONT></P>
  <P><FONT size=3D2>Lothar: </FONT><BR><FONT size=3D2>- I agree, that =
the text=20
  adresses the backward compatibility problem. </FONT></P>
  <P><FONT size=3D2>I hope that the choosen approach of "always =
advertise" will be=20
  widely adopted - I still have some concern regarding the following =
"chicken=20
  and egg" problem: Users will not see CUI benefits (in particular=20
  roaming-privacy) until a critical mass of network-access-providers =
adopts CUI=20
  with always advertise policy.&nbsp; Network-access-operators may =
hesitate to=20
  introduce an always-advertise CUI policy before seeing any evidence =
that a=20
  critical mass of users is requesting it.<SPAN =
class=3D290281218-08122004><FONT=20
  face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D290281218-08122004><FONT face=3DArial=20
  color=3D#0000ff>FA: BTW, the text (the snippet that I sent =
you)&nbsp;does not=20
  say&nbsp;"always advertise".&nbsp; The NAS MAY advertise=20
  ....</FONT></SPAN></FONT></P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D290281218-08122004></SPAN></FONT>&nbsp;</P>
  <P><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D290281218-08122004></SPAN></FONT>&nbsp;</P>
  <P><FONT size=3D2>Lothar</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4DD54.7F65A6E3--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 15:34:58 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Wed, 8 Dec 2004 10:32:50 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Lothar Reith writes...

> Therefore, the "always advertise CUI" policy will have to be=20
> implemented forever/until migrating to DIAMETER.
> - The same may apply to other new proposed attributes, such as=20
> GeoPriv, etc etc

The requirement to advertise attribute support capabilities in this way =
is limited to a special class of attributes.  Attributes that may be =
required to be present in an Access-Request message (as "hints") in =
order for the RADIUS server to comply with its configured policy profile =
for the user, or group of users, is already covered.  If the required =
attributes are not present, an Access-Reject is sent.  Attributes that =
describe service provisioning are also covered, because NASes MUST treat =
an Access-Accept containing attributes describing unsupported services =
as an Access-Reject.  The case where explicit advertisement is required =
is the non-service describing attributes such as CUI.

Yes, it would be very convenient if RADIUS had the concept of =
"Mandatory" attributes that we find in Diameter.  That is one good =
reason to consider migrating to Diameter deployment.

> From the perspective of the RADIUS server, he may well need=20
> absolute assurance that the NAS supports CUI, before he sends an=20
> access-accept with a NAI that is insufficient for identification=20
> of the user.

"Absolute assurance" is a strong term.  There is nothing that prevents =
malicious or defective NAS firmware from advertising support for CUI but =
not actually supporting it.  Therefore, the best that can be achieved in =
a protocol such as this is "relative assurance" based on implicit trust =
that the NASes your business partners, and their consortium members, are =
utilizing are reliable.=20

> Question: Instead of allocating a new error code for every new=20
> attribute, would it not be better to adopt a general approach,=20
> which allows to include the missing attribute(s)in a Reject message
> with error cause 402 ?

True capabilities negotiation (e.g. as we find in PPP and similar =
protocols) might be a nice thing.  It is not clear to me that this =
enhancement is within the scope of the RADEXT charter or that there is =
consensus in the WG that RADIUS should be enhanced in such a substantial =
fashion.  Perhaps another reason to eventually migrate to Diameter?
=20
> I still have some concern regarding the following "chicken and egg"=20
> problem: Users will not see CUI benefits (in particular =
roaming-privacy)
> until a critical mass of network-access-providers adopts CUI with =
always=20
> advertise policy.=A0 Network-access-operators may hesitate to =
introduce an=20
> always-advertise CUI policy before seeing any evidence that a critical =

> mass of users is requesting it.

This is true of any protocol extension.  It would be true of =
capabilities negotiation.  IMHO, we should only be working on extensions =
to RADIUS that meet a demand in the market, and will therefore achieve =
some reasonable level of quick deployment.  There's little reason to =
standardize enhancements that vendors will not implement.  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 14:02:57 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: backwards compatible introduction of NEW attribute such as CU I
Date: Wed, 8 Dec 2004 15:01:56 +0100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DD2E.7A2C599C
Content-Type: text/plain

Farid,

you wrote:
1) the new attribute is not mandatory.  2) The suggested CUI advertisement
in Access-Request is optional.

Lothar:
okay, I acknowledge that there may be multiple definitions of mandatory and
that I may have misused the term. I did not mean to say that the CUI shall
be a mandatory attribute and therefore must be present in all RADIUS
access-request messages. In the opposite my intention was to avoid that the
CUI-Null attribute will have to be sent in ALL access-request messages as
part of an "always advertise CUI capability" policy.

-  I can not see how a home RADIUS server can implicitly determine CUI
support of a NAS from an "unknown" access provider, and how he can sometime
determine that all NASes are upgraded. Therefore, the "always advertise CUI"
policy will have to be implemented forever/until migrating to DIAMETER.

- The same may apply to other new proposed attributes, such as GeoPriv, etc
etc

other comments:
- in your draft text-snippet, I would recommend to totally drop or replace
the part-sentence: "if the CUI is required for proper billing" 
with:
"if the home RADIUS server considers CUI support of the NAS to be required
for any reason, for example for billing or charging purposes" 

Justification: There is a good reason that the C in CUI stands for
chargeable, because charging means more than just billing. For example,  a
chargeable user identity may be required to be able to charge a malicious
user in court. Regulation in the country of the home network operator and/or
in the country of the visited network may very well mandate to never grant
access without the ability to identify the user after the fact if he did
something malicious.

That is what I meant when previously using the term "mandatory". From the
perspective of the RADIUS server, he may well need absolute assurance that
the NAS supports CUI, before he sends an access-accept with a NAI that is
insufficient for identification of the user.   Otherwise the home network
operator may not only risk the ability to collect end-user payment for the
usage, but may even be in violation of local laws.  

- another Question similar to David's question raised earlier:   How shall a
NAS determine from the error cause value 402 (decimal), "Missing Attribute",
if the missing attribute is the CUI attribute or some other attribute such
as GEOPRIV ?

Question: Instead of allocating a new error code for every new attribute,
would it not be better to adopt a general approach, which allows to include
the missing attribute(s)in a Reject message with error cause 402 ? This may
even allow to include multiple NEW attributes such as CUI and GEOPRIV in the
event that the home network requires both. Also, we would not need another
error cause for every new attribute of this kind, let alone error codes for
combined missings, or a precedence setting which attribute is to be
preferred to be indicated in the error cause if multiple attributes are
missing.

Farid wrote as part of the snippet:
 if the NAS supports the CUI attribute the CUI attribute will override the
identity portion the UserName (1) attribute.

Lothar: what exactly means "override the identity portion of the UserName" ?
Do you mean it in the sense of "overwrite", that the CUI will be combined
with the realm portion of the NAI ? In this context, maybe it would be
usefull to clarify the significance of the identifier which we refer to as
CUI or Chargeable-user-identity, i.e. if the home-network provider should
always be able to resolve a CUI, or if it is allowed that he also requires
other information present in the RADIUS accounting data (such as the realm
portion of the NAI) to be able to resolve the CUI to the identity of the
user.

Farid wrote:
Before we get into developing a protocol (as suggested below) to determine
the CUI support, I would like to know why the above paragraph does not
address the backward compatibility problem. 

Lothar: 
- I agree, that the text adresses the backward compatibility problem. 

I hope that the choosen approach of "always advertise" will be widely
adopted - I still have some concern regarding the following "chicken and
egg" problem: Users will not see CUI benefits (in particular
roaming-privacy) until a critical mass of network-access-providers adopts
CUI with always advertise policy.  Network-access-operators may hesitate to
introduce an always-advertise CUI policy before seeing any evidence that a
critical mass of users is requesting it.

Lothar

------_=_NextPart_001_01C4DD2E.7A2C599C
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: backwards compatible introduction of NEW attribute such as =
CUI</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Farid,</FONT>
</P>

<P><FONT SIZE=3D2>you wrote:</FONT>
<BR><FONT SIZE=3D2>1) the new attribute is not mandatory.&nbsp; 2) The =
suggested CUI advertisement in Access-Request is optional.</FONT>
</P>

<P><FONT SIZE=3D2>Lothar:</FONT>
<BR><FONT SIZE=3D2>okay, I acknowledge that there may be multiple =
definitions of mandatory and that I may have misused the term. I did =
not mean to say that the CUI shall be a mandatory attribute and =
therefore must be present in all RADIUS access-request messages. In the =
opposite my intention was to avoid that the CUI-Null attribute will =
have to be sent in ALL access-request messages as part of an =
&quot;always advertise CUI capability&quot; policy.</FONT></P>

<P><FONT SIZE=3D2>-&nbsp; I can not see how a home RADIUS server can =
implicitly determine CUI support of a NAS from an &quot;unknown&quot; =
access provider, and how he can sometime determine that all NASes are =
upgraded. Therefore, the &quot;always advertise CUI&quot; policy will =
have to be implemented forever/until migrating to DIAMETER.</FONT></P>

<P><FONT SIZE=3D2>- The same may apply to other new proposed =
attributes, such as GeoPriv, etc etc</FONT>
</P>

<P><FONT SIZE=3D2>other comments:</FONT>
<BR><FONT SIZE=3D2>- in your draft text-snippet, I would recommend to =
totally drop or replace the part-sentence: &quot;if the CUI is required =
for proper billing&quot; </FONT></P>

<P><FONT SIZE=3D2>with:</FONT>
<BR><FONT SIZE=3D2>&quot;if the home RADIUS server considers CUI =
support of the NAS to be required for any reason, for example for =
billing or charging purposes&quot; </FONT></P>

<P><FONT SIZE=3D2>Justification: There is a good reason that the C in =
CUI stands for chargeable, because charging means more than just =
billing. For example,&nbsp; a chargeable user identity may be required =
to be able to charge a malicious user in court. Regulation in the =
country of the home network operator and/or in the country of the =
visited network may very well mandate to never grant access without the =
ability to identify the user after the fact if he did something =
malicious.</FONT></P>

<P><FONT SIZE=3D2>That is what I meant when previously using the term =
&quot;mandatory&quot;. From the perspective of the RADIUS server, he =
may well need absolute assurance that the NAS supports CUI, before he =
sends an access-accept with a NAI that is insufficient for =
identification of the user.&nbsp;&nbsp; Otherwise the home network =
operator may not only risk the ability to collect end-user payment for =
the usage, but may even be in violation of local laws.&nbsp; =
</FONT></P>

<P><FONT SIZE=3D2>- another Question similar to David's question raised =
earlier:&nbsp;&nbsp; How shall a NAS determine from the error cause =
value 402 (decimal), &quot;Missing Attribute&quot;, if the missing =
attribute is the CUI attribute or some other attribute such as GEOPRIV =
?</FONT></P>

<P><FONT SIZE=3D2>Question: Instead of allocating a new error code for =
every new attribute, would it not be better to adopt a general =
approach, which allows to include the missing attribute(s)in a Reject =
message with error cause 402 ? This may even allow to include multiple =
NEW attributes such as CUI and GEOPRIV in the event that the home =
network requires both. Also, we would not need another error cause for =
every new attribute of this kind, let alone error codes for combined =
missings, or a precedence setting which attribute is to be preferred to =
be indicated in the error cause if multiple attributes are =
missing.</FONT></P>

<P><FONT SIZE=3D2>Farid wrote as part of the snippet:</FONT>
<BR><FONT SIZE=3D2>&nbsp;if the NAS supports the CUI attribute the CUI =
attribute will override the identity portion the UserName (1) =
attribute.</FONT>
</P>

<P><FONT SIZE=3D2>Lothar: what exactly means &quot;override the =
identity portion of the UserName&quot; ? Do you mean it in the sense of =
&quot;overwrite&quot;, that the CUI will be combined with the realm =
portion of the NAI ? In this context, maybe it would be usefull to =
clarify the significance of the identifier which we refer to as CUI or =
Chargeable-user-identity, i.e. if the home-network provider should =
always be able to resolve a CUI, or if it is allowed that he also =
requires other information present in the RADIUS accounting data (such =
as the realm portion of the NAI) to be able to resolve the CUI to the =
identity of the user.</FONT></P>

<P><FONT SIZE=3D2>Farid wrote:</FONT>
<BR><FONT SIZE=3D2>Before we get into developing a protocol (as =
suggested below) to determine the CUI support, I would like to know why =
the above paragraph does not address the backward compatibility =
problem. </FONT></P>

<P><FONT SIZE=3D2>Lothar: </FONT>
<BR><FONT SIZE=3D2>- I agree, that the text adresses the backward =
compatibility problem. </FONT>
</P>

<P><FONT SIZE=3D2>I hope that the choosen approach of &quot;always =
advertise&quot; will be widely adopted - I still have some concern =
regarding the following &quot;chicken and egg&quot; problem: Users will =
not see CUI benefits (in particular roaming-privacy) until a critical =
mass of network-access-providers adopts CUI with always advertise =
policy.&nbsp; Network-access-operators may hesitate to introduce an =
always-advertise CUI policy before seeing any evidence that a critical =
mass of users is requesting it.</FONT></P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DD2E.7A2C599C--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 08 Dec 2004 08:01:47 +0000
Date: Wed, 8 Dec 2004 00:01:02 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Request Advancement of draft-ietf-radext-rfc2486bis-03.txt

This is a note to request that the IESG consider "The Network Access
Identifier" draft-ietf-radext-rfc2486bis-03.txt as an IETF Proposed
Standard (recycled).  The document is available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-03.txt

This document represents a revision of RFC 2486 in order to handle user
privacy and internationalization as well as a number of errata.

The document has completed two RADEXT WG Last Calls and has been reviewed
by the RADEXT WG Chairs.  The issues raised during WG discussion are
described in detail here:

http://www.drizzle.com/~aboba/RADEXT/

In the last WG last call, 4 issues were raised, all of which were editorial:
Issues 19, 20, 32 and 33.

The document has not been controversial and there has been no threat of
appeal.  3GPP has included this document in its dependency list.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 21:19:35 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 7 Dec 2004 13:19:14 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Hi David, all
Thanks.  Please see my response inline.
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Tuesday, December 07, 2004 12:45 PM
> To: [email-masked]
> Subject: RE: backwards compatible introduction of NEW=20
> attribute such as CUI
>=20
>=20
> Farid Adrangi writes...
> =A0=A0
> > We are currently working on -03 version of the CUI draft.=A0 Here=20
> > is a snippet on what we want to say about backward compatibility.
> >=A0
> > "
> > ... Servers which do not understand the CUI attribute SHOULD=20
> > silently discard the attribute.
> >=A0
> > The NAS MAY include the CUI attribute with a null character for =
its=A0
> > data field in the Access-Request message to indicate its=20
> support for=20
> > this attribute to the home RADIUS server.=A0 In cases where home=20
> > RADIUS=A0server cannot determine the NAS support for the CUI, if the =

> > CUI is=A0required for proper billing, the home RADIUS server MUST=20
> > reject the=A0request by sending an Access-Reject message including =
an=20
> > Error-Cause=A0attribute [RFC3576] with value 402 (decimal), "Missing =

> > Attribute".
>=20
> DBN:  Would it be preferable to create a new value of=20
> Error-Cause to more specifically describe the=20
> incompatibility?  While Missing-CUI might be too specific,=20
> Missing Attribute is quite broad.
>=20

Yes, it would be.  I need to check RFC 3576 to find out the procedure =
for adding a new value to the Error-Cause. =20

> > Otherwise, the home RADIUS server MUST send both the UserName=20
> > (1)=A0attribute and the CUI attribute, with the understanding that =
if=20
> > the NAS supports the CUI attribute the CUI attribute will override=20
> > the=A0identity portion the UserName (1) attribute.
>=20
> DBN:  I think you want to qualify this MUST statement with=20
> "if the authentication is successful".  That is probably=20
> understood from context, but added clarity may be helpful.
>=20
Yes. Good point.

> >=A0That is, the=A0UserName(1) attribute will be used for routing=20
> and the CUI
> > attribute will be used for identity purposes.
> >"
> >
> > Before we get into developing a protocol (as=A0suggested below)=A0to =

> > determine the CUI support, I would like to know why the above
> > paragraph does not address the backward compatibility problem.=A0
>=20
> DBN: IMHO, it does.
>=20
> DBN:  Editorial nits:  "UserName (1)" is User-Name (1)". Do=20
> you want to use the text "CUI attribute" or do you want to=20
> spell out a standard format RADIUS attribute name. e.g.=20
> "Chargeable-User-ID (tba)"?
> =A0
Will change to User-Name(1).  CUI is shorter, but I am okay with using =
Chargeable-User-ID instead.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 20:46:05 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 7 Dec 2004 15:44:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Farid Adrangi writes...
=A0=A0
> We are currently working on -03 version of the CUI draft.=A0 Here=20
> is a snippet on what we want to say about backward compatibility.
>=A0
> "
> ... Servers which do not understand the CUI attribute SHOULD=20
> silently discard the attribute.
>=A0
> The NAS MAY include the CUI attribute with a null character for its=A0
> data field in the Access-Request message to indicate its support for=20
> this attribute to the home RADIUS server.=A0 In cases where home=20
> RADIUS=A0server cannot determine the NAS support for the CUI, if the=20
> CUI is=A0required for proper billing, the home RADIUS server MUST=20
> reject the=A0request by sending an Access-Reject message including an=20
> Error-Cause=A0attribute [RFC3576] with value 402 (decimal), "Missing=20
> Attribute".

DBN:  Would it be preferable to create a new value of Error-Cause to =
more specifically describe the incompatibility?  While Missing-CUI might =
be too specific, Missing Attribute is quite broad.

> Otherwise, the home RADIUS server MUST send both the UserName=20
> (1)=A0attribute and the CUI attribute, with the understanding that if=20
> the NAS supports the CUI attribute the CUI attribute will override=20
> the=A0identity portion the UserName (1) attribute.

DBN:  I think you want to qualify this MUST statement with "if the =
authentication is successful".  That is probably understood from =
context, but added clarity may be helpful.

>=A0That is, the=A0UserName(1) attribute will be used for routing and =
the CUI
> attribute will be used for identity purposes.
>"
>
> Before we get into developing a protocol (as=A0suggested below)=A0to=20
> determine the CUI support, I would like to know why the above
> paragraph does not address the backward compatibility problem.=A0

DBN: IMHO, it does.

DBN:  Editorial nits:  "UserName (1)" is User-Name (1)". Do you want to =
use the text "CUI attribute" or do you want to spell out a standard =
format RADIUS attribute name. e.g. "Chargeable-User-ID (tba)"?
=A0

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 20:37:11 +0000
Date: Tue, 7 Dec 2004 12:37:04 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Re: Issues List Revision

The RADEXT WG Status Page and Issues List is available at:

http://www.drizzle.com/~aboba/RADEXT/

On Tue, 7 Dec 2004, Bernard Aboba wrote:

> I've gone and updated the RADEXT WG Issues list.  Please send email to me
> if your issue is not on the list, or if the status of the issue isn't
> accurate.
>
> BTW, we still don't have email describing the status of most of the open
> issues with the RADIUS Digest draft.  Without an indication to the
> contrary, I'm assuming that open issues still remain unresolved.
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 20:35:52 +0000
Date: Tue, 7 Dec 2004 12:35:32 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issues List Revision

I've gone and updated the RADEXT WG Issues list.  Please send email to me
if your issue is not on the list, or if the status of the issue isn't
accurate.

BTW, we still don't have email describing the status of most of the open
issues with the RADIUS Digest draft.  Without an indication to the
contrary, I'm assuming that open issues still remain unresolved.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 20:08:21 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI  (was: re: Minutes of the RADEXT WG Meeting at IETF-61
Date: Tue, 7 Dec 2004 12:07:25 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: "David Kessens" <[email-masked]>, "Bert Wijnen" <[email-masked]>, "Bernard Aboba" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4DC98.5EAC145F
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Lothar, all
=20
Couple of quick points,  1) the new attribute is not mandatory.  2) The
suggested CUI advertisement in Access-Request is optional.
=20
We are currently working on -03 version of the CUI draft.  Here is a
snippet on what we want to say about backward compatibility.
=20
"
... Servers which do not understand the CUI attribute SHOULD silently
discard the attribute.
=20
The NAS MAY include the CUI attribute with a null character for its data
field in the Access-Request message to indicate its support for this
attribute to the home RADIUS server.  In cases where home RADIUS server
cannot determine the NAS support for the CUI, if the CUI is required for
proper billing, the home RADIUS server MUST reject the request by
sending an Access-Reject message including an Error-Cause attribute
[RFC3576] with value 402 (decimal), "Missing Attribute".
Otherwise, the home RADIUS server MUST send both the UserName (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 UserName (1) attribute.  That is, the UserName(1) attribute
will be used for routing and the CUI attribute will be used for identity
purposes.
=20
"
Before we get into developing a protocol (as suggested below) to
determine the CUI support, I would like to know why the above paragraph
does not address the backward compatibility problem.  =20
=20
BR,
Farid
=20
=20
=20

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Lothar Reith
	Sent: Tuesday, December 07, 2004 4:19 AM
	To: 'Nelson, David'; [email-masked]'
	Cc: 'David Kessens'; 'Bert Wijnen'; 'Bernard Aboba'
	Subject: backwards compatible introduction of NEW attribute such
as CUI (was: re: Minutes of the RADEXT WG Meeting at IETF-61
=09
=09

	David,=20

	in your minutes you wrote (excerpt):=20
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
	Farid Adrangi: Chargeable User identity=20
	(draft-adrangi-radius-chargeable-user-identity-02.txt)=20
	------------------------------------------------------=20

	Farid went through current issues.  Issues 13, 14 and 15 are
addressed in the most recent draft.  There are two open issues: (a)
backward=20

	compatibility and (b) the lack of general capability negotiation
mechanism in RADIUS.  We could send a "hint" attribute in the Access-
Request message as indication of CUI feature support.

=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20

	As pointed out earlier, using an approach of "always send a
hint" attribute in all Access-Request messages may be prohibitively
expensive, in particular when this approach is used as precedence for
advertising support of a new attribute in ALL access-request messages
sent, even for the case when only once in a billion times this
information is actually used.

	The backwards compatibility issue with CUI - your issue a)above
- is just one example of the general problem which you referred to as
issue b): lack of general capability negotiation mechanism in RADIUS.

	I would like to propose a solution for a) and for a subset of
b), and therefore I would like to formulate issue c) below which I
consider to be the most critical subset of your issue b:

	issue c) lack of a backwards compatible server-initiated method
which allows a server to verify (challenge) if a NAS supports a new
RADIUS attribute referred to as "NEW", which is considered by the server
to be a mandatory attribute, i.e. the Server requires assurance that the
NAS will not ignore the NEW attribute when present in an Access-Accept.

	An example of "NEW" is "CUI". A good example of issue c) is the
CUI backwards compatibility issue described above in issue a).  It is
essential to the operation of CUI, that the server can trust the NAS
will support CUI functionality and include a received CUI in the
accounting messages - otherwise the home network operator would loose
money.

	My proposal to overcome issue c) is as follows (revised from an
earlier proposal I made in the context of CUI):=20

	Before including a new mandatory attribute "NEW" into an
access-accept message a server may want to challenge the NAS in order to
verify if the NAS supports that particular new attribute "NEW". This
"Challenge" can be done implicitly (reject with a hint) or explicitly
(challenge with a hint).

	Implicit challenge:=20
	1) on receipt of an access-request which does not include a
Null-NEW attribute, but where the server would only send an
access-accept if assured that the NAS supports NEW, the Server may
respond with an Access-Reject message which includes the Null-NEW
attribute as elaboration on the cause of the failure, implicitly
signalling: I may have accepted if a Null-NEW attribute had been present
in the access-request. On receipt of an access-reject with a Null-NEW
attribute, the NAS should resend the access-accept but this time include
the Null-NEW attribute, in order to confirm support of the NEW
attribute.

	I believe this behaviour should be in line with Bernard's below
earlier comment.=20

	Bernard wrote in response to one of my earlier proposals which
suggested re-interpreting an Access-Reject as an Access-Accept:

	"Changing the semantics of the Access-Reject is somewhat tricky
since the goal of that message is to deny service.  As a result, RFC
2865 discourages inclusion of service-definition attributes within an
Access-Reject, and subsequent RFCs have only included attributes that
provide elaboration on the failure or its causes:  EAP-Message,
Reply-Message, etc." and "Interpreting an Access-Reject as an
Access-Accept is explicitly forbidden by RFC 2865.  We don't want to go
down that road."

	Alternatively perhaps an explicit challenge may be used as
follows:=20
	2) on receipt of an access-request message which does not
include a Null-NEW attribute, but where the server would only send an
access-accept if assured that the NAS supports NEW, the Server may
respond with an Access-Challenge message which includes the Null-NEW
attribute. A NAS which supports an attribute NEW MUST on receipt of a
Null-NEW attribute in an access-challenge message include a Null-NEW
attribute in the subsequent ACCESS-Request message in order to confirm
support of NEW attribute to the challenging Server.

	I would like to note that it is up to the server if he requires
an explicit assurance. If the server knows via some other way that the
NAS supports the attribute NEW - then he does not need to challenge the
NAS to provide confirmation of attribute support. Also, if the NAS is
prepared to take a risk...

	As always, comments welcome...=20

	Lothar=20

------_=_NextPart_001_01C4DC98.5EAC145F
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>Hi=20
Lothar, all</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>Couple=20
of quick points,&nbsp; 1) the new attribute is not mandatory.&nbsp; 2) =
The=20
suggested CUI advertisement in Access-Request is =
optional.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>We are=20
currently working on -03 version of the CUI draft.&nbsp; Here is a =
snippet on=20
what we want to say about backward compatibility.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004>"</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>...=20
Servers which do not understand the CUI attribute SHOULD silently =
discard the=20
attribute.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>The=20
NAS MAY include the CUI attribute with a null character for =
its&nbsp;data field=20
in the Access-Request message to indicate its support for this attribute =
to the=20
home RADIUS server.&nbsp; In cases where home RADIUS&nbsp;server cannot=20
determine the NAS support for the CUI, if the CUI is&nbsp;required for =
proper=20
billing, the home RADIUS server MUST reject the&nbsp;request by sending =
an=20
Access-Reject message including an Error-Cause&nbsp;attribute [RFC3576] =
with=20
value 402 (decimal), "Missing Attribute".<BR>Otherwise, the home RADIUS =
server=20
MUST send both the UserName (1)&nbsp;attribute and the CUI attribute, =
with the=20
understanding that if the NAS supports the CUI attribute the CUI =
attribute will=20
override the&nbsp;identity portion the UserName (1) attribute.&nbsp; =
That is,=20
the&nbsp;UserName(1) attribute will be used for routing and the CUI =
attribute=20
will be used for identity purposes.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004>"</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D500194219-07122004>Before=20
we get into developing a protocol (as&nbsp;suggested below)&nbsp;to =
determine=20
the CUI support, I would like to know why the above paragraph does not =
address=20
the backward compatibility problem.&nbsp;&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004>BR,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004>Farid</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D500194219-07122004></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Lothar Reith<BR><B>Sent:</B> Tuesday, December 07, 2004 =
4:19=20
  AM<BR><B>To:</B> 'Nelson, David'; =
[email-masked]'<BR><B>Cc:</B>=20
  'David Kessens'; 'Bert Wijnen'; 'Bernard Aboba'<BR><B>Subject:</B> =
backwards=20
  compatible introduction of NEW attribute such as CUI (was: re: Minutes =
of the=20
  RADEXT WG Meeting at IETF-61<BR><BR></FONT></DIV>
  <P><FONT size=3D2>David,</FONT> </P>
  <P><FONT size=3D2>in your minutes you wrote (excerpt): =
</FONT><BR><FONT=20
  =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
  <BR><FONT size=3D2>Farid Adrangi: Chargeable User identity</FONT> =
<BR><FONT=20
  size=3D2>(draft-adrangi-radius-chargeable-user-identity-02.txt)</FONT> =
<BR><FONT=20
  size=3D2>------------------------------------------------------</FONT> =
</P>
  <P><FONT size=3D2>Farid went through current issues.&nbsp; Issues 13, =
14 and 15=20
  are addressed in the most recent draft.&nbsp; There are two open =
issues: (a)=20
  backward </FONT></P>
  <P><FONT size=3D2>compatibility and (b) the lack of general capability =

  negotiation mechanism in RADIUS.&nbsp; We could send a "hint" =
attribute in the=20
  Access- Request message as indication of CUI feature =
support.</FONT></P>
  <P><FONT=20
  =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
  </P>
  <P><FONT size=3D2>As pointed out earlier, using an approach of "always =
send a=20
  hint" attribute in all Access-Request messages may be prohibitively =
expensive,=20
  in particular when this approach is used as precedence for advertising =
support=20
  of a new attribute in ALL access-request messages sent, even for the =
case when=20
  only once in a billion times this information is actually =
used.</FONT></P>
  <P><FONT size=3D2>The backwards compatibility issue with CUI - your =
issue=20
  a)above - is just one example of the general problem which you =
referred to as=20
  issue b): lack of general capability negotiation mechanism in=20
  RADIUS.</FONT></P>
  <P><FONT size=3D2>I would like to propose a solution for a) and for a =
subset of=20
  b), and therefore I would like to formulate issue c) below which I =
consider to=20
  be the most critical subset of your issue b:</FONT></P>
  <P><FONT size=3D2>issue c) lack of a backwards compatible =
server-initiated=20
  method which allows a server to verify (challenge) if a NAS supports a =
new=20
  RADIUS attribute referred to as "NEW", which is considered by the =
server to be=20
  a mandatory attribute, i.e. the Server requires assurance that the NAS =
will=20
  not ignore the NEW attribute when present in an =
Access-Accept.</FONT></P>
  <P><FONT size=3D2>An example of "NEW" is "CUI". A good example of =
issue c) is=20
  the CUI backwards compatibility issue described above in issue =
a).&nbsp; It is=20
  essential to the operation of CUI, that the server can trust the NAS =
will=20
  support CUI functionality and include a received CUI in the accounting =

  messages - otherwise the home network operator would loose =
money.</FONT></P>
  <P><FONT size=3D2>My proposal to overcome issue c) is as follows =
(revised from=20
  an earlier proposal I made in the context of CUI): </FONT></P>
  <P><FONT size=3D2>Before including a new mandatory attribute "NEW" =
into an=20
  access-accept message a server may want to challenge the NAS in order =
to=20
  verify if the NAS supports that particular new attribute "NEW". This=20
  "Challenge" can be done implicitly (reject with a hint) or explicitly=20
  (challenge with a hint).</FONT></P>
  <P><FONT size=3D2>Implicit challenge:</FONT> <BR><FONT size=3D2>1) on =
receipt of=20
  an access-request which does not include a Null-NEW attribute, but =
where the=20
  server would only send an access-accept if assured that the NAS =
supports NEW,=20
  the Server may respond with an Access-Reject message which includes =
the=20
  Null-NEW attribute as elaboration on the cause of the failure, =
implicitly=20
  signalling: I may have accepted if a Null-NEW attribute had been =
present in=20
  the access-request. On receipt of an access-reject with a Null-NEW =
attribute,=20
  the NAS should resend the access-accept but this time include the =
Null-NEW=20
  attribute, in order to confirm support of the NEW =
attribute.</FONT></P>
  <P><FONT size=3D2>I believe this behaviour should be in line with =
Bernard's=20
  below earlier comment.</FONT> </P>
  <P><FONT size=3D2>Bernard wrote in response to one of my earlier =
proposals which=20
  suggested re-interpreting an Access-Reject as an =
Access-Accept:</FONT></P>
  <P><FONT size=3D2>"Changing the semantics of the Access-Reject is =
somewhat=20
  tricky since the goal of that message is to deny service.&nbsp; As a =
result,=20
  RFC 2865 discourages inclusion of service-definition attributes within =
an=20
  Access-Reject, and subsequent RFCs have only included attributes that =
provide=20
  elaboration on the failure or its causes:&nbsp; EAP-Message, =
Reply-Message,=20
  etc." and "Interpreting an Access-Reject as an Access-Accept is =
explicitly=20
  forbidden by RFC 2865.&nbsp; We don't want to go down that =
road."</FONT></P>
  <P><FONT size=3D2>Alternatively perhaps an explicit challenge may be =
used as=20
  follows:</FONT> <BR><FONT size=3D2>2) on receipt of an access-request =
message=20
  which does not include a Null-NEW attribute, but where the server =
would only=20
  send an access-accept if assured that the NAS supports NEW, the Server =
may=20
  respond with an Access-Challenge message which includes the Null-NEW=20
  attribute. A NAS which supports an attribute NEW MUST on receipt of a =
Null-NEW=20
  attribute in an access-challenge message include a Null-NEW attribute =
in the=20
  subsequent ACCESS-Request message in order to confirm support of NEW =
attribute=20
  to the challenging Server.</FONT></P>
  <P><FONT size=3D2>I would like to note that it is up to the server if =
he=20
  requires an explicit assurance. If the server knows via some other way =
that=20
  the NAS supports the attribute NEW - then he does not need to =
challenge the=20
  NAS to provide confirmation of attribute support. Also, if the NAS is =
prepared=20
  to take a risk...</FONT></P>
  <P><FONT size=3D2>As always, comments welcome...</FONT> </P>
  <P><FONT size=3D2>Lothar </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4DC98.5EAC145F--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 15:14:31 +0000
Content-class: urn:content-classes:message
Subject: RE: backwards compatible introduction of NEW attribute such as CUI
Date: Tue, 7 Dec 2004 10:11:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Lothar Reith writes (in HTML format!)...=20

As pointed out earlier, using an approach of "always send a hint"
attribute in all Access-Request messages may be prohibitively expensive,
...

DBN: I understand that this assertion has been made on the list.  In the
minutes I was simply reporting a brief summary of the discussion at the
meeting.  As a side note, I have never been convinced about the
"prohibitive expense" of including an attribute, especially a short one,
in an Access-Request message, given the popular practice of including
all sorts of "hint" attributes in Access-Accept messages (this would be
just one more) and the small percentage increase in packet size.

Before including a new mandatory attribute "NEW" into an access-accept
message a server may want to challenge the NAS in order to verify if the
NAS supports that particular new attribute "NEW".

DBN:  Be careful.  The only attribute that RADIUS considers "mandatory"
is the Service-Type. Introducing the concept of mandatory attributes
into RADIUS, as the concept exists in Diameter, is a substantial
undertaking.

This "Challenge" can be done implicitly (reject with a hint) or
explicitly (challenge with a hint).

DBN: As Bernard Aboba has previously stated, we don't want to use
Access-Reject as a negotiation method.  It's a slippery slope, and it
has all sorts of backwards compatibility problems.

I believe this behaviour should be in line with Bernard's below earlier
comment.

DBN: I respectfully disagree.

Alternatively perhaps an explicit challenge may be used as follows:=20
2) on receipt of an access-request message which does not include a
Null-NEW attribute, but where the server would only send an
access-accept if assured that the NAS supports NEW, the Server may
respond with an Access-Challenge message which includes the Null-NEW
attribute. A NAS which supports an attribute NEW MUST on receipt of a
Null-NEW attribute in an access-challenge message include a Null-NEW
attribute in the subsequent ACCESS-Request message in order to confirm
support of NEW attribute to the challenging Server.

DBN:  This method might be made to work.  There are backwards
compatibility issues here too.  What happens when the RADIUS client has
no idea what the inclusion of a NEW attribute in the Access-Challenge
message means?  Should the client treat the Access-Challenge as an
Access-Reject?  Should it send a new Access-Request without the NEW
attribute (which it doesn't understand)?  Will the server respond with
yet another Access-Challenge?  Will this cause an endless loop?  :-)

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 12:19:46 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Cc: "'David Kessens'" <[email-masked]>, "'Bert Wijnen'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Subject: backwards compatible introduction of NEW attribute such as CUI  ( was: re: Minutes of the RADEXT WG Meeting at IETF-61
Date: Tue, 7 Dec 2004 13:19:11 +0100 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4DC56.F54A7AF6
Content-Type: text/plain

David,

in your minutes you wrote (excerpt): 
============================================================================
=======
Farid Adrangi: Chargeable User identity
(draft-adrangi-radius-chargeable-user-identity-02.txt)
------------------------------------------------------

Farid went through current issues.  Issues 13, 14 and 15 are addressed in
the most recent draft.  There are two open issues: (a) backward 
compatibility and (b) the lack of general capability negotiation mechanism
in RADIUS.  We could send a "hint" attribute in the Access- Request message
as indication of CUI feature support.
============================================================================
==========

As pointed out earlier, using an approach of "always send a hint" attribute
in all Access-Request messages may be prohibitively expensive, in particular
when this approach is used as precedence for advertising support of a new
attribute in ALL access-request messages sent, even for the case when only
once in a billion times this information is actually used.

The backwards compatibility issue with CUI - your issue a)above - is just
one example of the general problem which you referred to as issue b): lack
of general capability negotiation mechanism in RADIUS.

I would like to propose a solution for a) and for a subset of b), and
therefore I would like to formulate issue c) below which I consider to be
the most critical subset of your issue b:

issue c) lack of a backwards compatible server-initiated method which allows
a server to verify (challenge) if a NAS supports a new RADIUS attribute
referred to as "NEW", which is considered by the server to be a mandatory
attribute, i.e. the Server requires assurance that the NAS will not ignore
the NEW attribute when present in an Access-Accept.

An example of "NEW" is "CUI". A good example of issue c) is the CUI
backwards compatibility issue described above in issue a).  It is essential
to the operation of CUI, that the server can trust the NAS will support CUI
functionality and include a received CUI in the accounting messages -
otherwise the home network operator would loose money.

My proposal to overcome issue c) is as follows (revised from an earlier
proposal I made in the context of CUI): 

Before including a new mandatory attribute "NEW" into an access-accept
message a server may want to challenge the NAS in order to verify if the NAS
supports that particular new attribute "NEW". This "Challenge" can be done
implicitly (reject with a hint) or explicitly (challenge with a hint).

Implicit challenge:
1) on receipt of an access-request which does not include a Null-NEW
attribute, but where the server would only send an access-accept if assured
that the NAS supports NEW, the Server may respond with an Access-Reject
message which includes the Null-NEW attribute as elaboration on the cause of
the failure, implicitly signalling: I may have accepted if a Null-NEW
attribute had been present in the access-request. On receipt of an
access-reject with a Null-NEW attribute, the NAS should resend the
access-accept but this time include the Null-NEW attribute, in order to
confirm support of the NEW attribute.
I believe this behaviour should be in line with Bernard's below earlier
comment.

Bernard wrote in response to one of my earlier proposals which suggested
re-interpreting an Access-Reject as an Access-Accept:
"Changing the semantics of the Access-Reject is somewhat tricky since the
goal of that message is to deny service.  As a result, RFC 2865 discourages
inclusion of service-definition attributes within an Access-Reject, and
subsequent RFCs have only included attributes that provide elaboration on
the failure or its causes:  EAP-Message, Reply-Message, etc." and
"Interpreting an Access-Reject as an Access-Accept is explicitly forbidden
by RFC 2865.  We don't want to go down that road."

Alternatively perhaps an explicit challenge may be used as follows:
2) on receipt of an access-request message which does not include a Null-NEW
attribute, but where the server would only send an access-accept if assured
that the NAS supports NEW, the Server may respond with an Access-Challenge
message which includes the Null-NEW attribute. A NAS which supports an
attribute NEW MUST on receipt of a Null-NEW attribute in an access-challenge
message include a Null-NEW attribute in the subsequent ACCESS-Request
message in order to confirm support of NEW attribute to the challenging
Server.

I would like to note that it is up to the server if he requires an explicit
assurance. If the server knows via some other way that the NAS supports the
attribute NEW - then he does not need to challenge the NAS to provide
confirmation of attribute support. Also, if the NAS is prepared to take a
risk...

As always, comments welcome...

Lothar 

------_=_NextPart_001_01C4DC56.F54A7AF6
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>backwards compatible introduction of NEW attribute such as CUI  =
(was: re: Minutes of the RADEXT WG Meeting at IETF-61</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>David,</FONT>
</P>

<P><FONT SIZE=3D2>in your minutes you wrote (excerpt): </FONT>
<BR><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
<BR><FONT SIZE=3D2>Farid Adrangi: Chargeable User identity</FONT>
<BR><FONT =
SIZE=3D2>(draft-adrangi-radius-chargeable-user-identity-02.txt)</FONT>
<BR><FONT =
SIZE=3D2>------------------------------------------------------</FONT>
</P>

<P><FONT SIZE=3D2>Farid went through current issues.&nbsp; Issues 13, =
14 and 15 are addressed in the most recent draft.&nbsp; There are two =
open issues: (a) backward </FONT></P>

<P><FONT SIZE=3D2>compatibility and (b) the lack of general capability =
negotiation mechanism in RADIUS.&nbsp; We could send a &quot;hint&quot; =
attribute in the Access- Request message as indication of CUI feature =
support.</FONT></P>

<P><FONT =
SIZE=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>
</P>

<P><FONT SIZE=3D2>As pointed out earlier, using an approach of =
&quot;always send a hint&quot; attribute in all Access-Request messages =
may be prohibitively expensive, in particular when this approach is =
used as precedence for advertising support of a new attribute in ALL =
access-request messages sent, even for the case when only once in a =
billion times this information is actually used.</FONT></P>

<P><FONT SIZE=3D2>The backwards compatibility issue with CUI - your =
issue a)above - is just one example of the general problem which you =
referred to as issue b): lack of general capability negotiation =
mechanism in RADIUS.</FONT></P>

<P><FONT SIZE=3D2>I would like to propose a solution for a) and for a =
subset of b), and therefore I would like to formulate issue c) below =
which I consider to be the most critical subset of your issue =
b:</FONT></P>

<P><FONT SIZE=3D2>issue c) lack of a backwards compatible =
server-initiated method which allows a server to verify (challenge) if =
a NAS supports a new RADIUS attribute referred to as &quot;NEW&quot;, =
which is considered by the server to be a mandatory attribute, i.e. the =
Server requires assurance that the NAS will not ignore the NEW =
attribute when present in an Access-Accept.</FONT></P>

<P><FONT SIZE=3D2>An example of &quot;NEW&quot; is &quot;CUI&quot;. A =
good example of issue c) is the CUI backwards compatibility issue =
described above in issue a).&nbsp; It is essential to the operation of =
CUI, that the server can trust the NAS will support CUI functionality =
and include a received CUI in the accounting messages - otherwise the =
home network operator would loose money.</FONT></P>

<P><FONT SIZE=3D2>My proposal to overcome issue c) is as follows =
(revised from an earlier proposal I made in the context of CUI): =
</FONT>
</P>

<P><FONT SIZE=3D2>Before including a new mandatory attribute =
&quot;NEW&quot; into an access-accept message a server may want to =
challenge the NAS in order to verify if the NAS supports that =
particular new attribute &quot;NEW&quot;. This &quot;Challenge&quot; =
can be done implicitly (reject with a hint) or explicitly (challenge =
with a hint).</FONT></P>

<P><FONT SIZE=3D2>Implicit challenge:</FONT>
<BR><FONT SIZE=3D2>1) on receipt of an access-request which does not =
include a Null-NEW attribute, but where the server would only send an =
access-accept if assured that the NAS supports NEW, the Server may =
respond with an Access-Reject message which includes the Null-NEW =
attribute as elaboration on the cause of the failure, implicitly =
signalling: I may have accepted if a Null-NEW attribute had been =
present in the access-request. On receipt of an access-reject with a =
Null-NEW attribute, the NAS should resend the access-accept but this =
time include the Null-NEW attribute, in order to confirm support of the =
NEW attribute.</FONT></P>

<P><FONT SIZE=3D2>I believe this behaviour should be in line with =
Bernard's below earlier comment.</FONT>
</P>

<P><FONT SIZE=3D2>Bernard wrote in response to one of my earlier =
proposals which suggested re-interpreting an Access-Reject as an =
Access-Accept:</FONT></P>

<P><FONT SIZE=3D2>&quot;Changing the semantics of the Access-Reject is =
somewhat tricky since the goal of that message is to deny =
service.&nbsp; As a result, RFC 2865 discourages inclusion of =
service-definition attributes within an Access-Reject, and subsequent =
RFCs have only included attributes that provide elaboration on the =
failure or its causes:&nbsp; EAP-Message, Reply-Message, etc.&quot; and =
&quot;Interpreting an Access-Reject as an Access-Accept is explicitly =
forbidden by RFC 2865.&nbsp; We don't want to go down that =
road.&quot;</FONT></P>

<P><FONT SIZE=3D2>Alternatively perhaps an explicit challenge may be =
used as follows:</FONT>
<BR><FONT SIZE=3D2>2) on receipt of an access-request message which =
does not include a Null-NEW attribute, but where the server would only =
send an access-accept if assured that the NAS supports NEW, the Server =
may respond with an Access-Challenge message which includes the =
Null-NEW attribute. A NAS which supports an attribute NEW MUST on =
receipt of a Null-NEW attribute in an access-challenge message include =
a Null-NEW attribute in the subsequent ACCESS-Request message in order =
to confirm support of NEW attribute to the challenging =
Server.</FONT></P>

<P><FONT SIZE=3D2>I would like to note that it is up to the server if =
he requires an explicit assurance. If the server knows via some other =
way that the NAS supports the attribute NEW - then he does not need to =
challenge the NAS to provide confirmation of attribute support. Also, =
if the NAS is prepared to take a risk...</FONT></P>

<P><FONT SIZE=3D2>As always, comments welcome...</FONT>
</P>

<P><FONT SIZE=3D2>Lothar </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4DC56.F54A7AF6--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 07 Dec 2004 11:17:10 +0000
Date: Tue, 07 Dec 2004 13:14:20 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: Re: REMINDER: RADEXT WG last call on RFC 2486bis-02

Hi Glen and thanks for your review. I have
addressed both of your comments. The diffs
and a new version are at:

   http://www.arkko.com/publications/nai/naibisdiff.html
   http://www.arkko.com/publications/nai/naibis.txt

I have submitted the -03 to the I-D directories;
it should appear there shortly.

Bernard, you should register these as new issues
and mark them as solved in -03.

--Jari

Glen Zorn (gwz) wrote:
> Description of issue: Misspelled word
> Submitter name: Glen Zorn
> Submitter email address: [email-masked]
> Date first submitted: 30 Nov 2004
> Document: draft-ietf-radext-rfc2486bis-02.txt
> Comment type: E
> Priority: 1
> Section: 3
> Rationale/Explanation of issue: grammatical error
> Lengthy description of problem: "For instance, some EAP methods
> apply a method-specific pseudonyms in the username part of the NAI."
> 
> 
> Requested change: CHANGE
> "For instance, some EAP methods apply a method-specific pseudonyms
> in the username part of the NAI." 
> TO EITHER 
> "For instance, some EAP methods apply method-specific pseudonyms in
> the username part of the NAI." 
> OR 
> "For instance, some EAP methods apply a method-specific pseudonym in
> the username part of the NAI."
> 
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Dec 2004 18:29:02 +0000
Content-class: urn:content-classes:message
Subject: Minutes of the RADEXT WG Meeting at IETF-61
Date: Mon, 6 Dec 2004 13:27:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: "David Kessens" <[email-masked]>, "Bert Wijnen" <[email-masked]>, "Bernard Aboba" <[email-masked]>

Please reply to the list (ASAP) with any errors or omissions.

Minutes of RADEXT WG meeting at IETF61
Monday November 8, 2004, 9:00AM-11:30AM
Hilton Washington, Military Room

Chairs: Preliminaries
---------------------------------------------

The Co-chairs presented the agenda. All slides are available from
http://www.drizzle.com/~aboba/RADEXT/IETF61/

Blue sheets were circulated.

Document status:
- Having completed WGLC
  - 2486bis
  - SIP authentication
- Requiring review
  - GEOPRIV WG has requested us to review the RADIUS Extensions=20
    for GEOPRIV (and some people are doing that already). Preferably
    this should be stable by December due to 3GPP deadlines. Will go =20
    to GEOPRIV WGLC soon.
- IPv6 MIB revisions will go to WGLC once we get the submissions
- Two documents being evaluated as potential WG work items
  - Chargeable user identities
  - RFC 3576 MIBs

Milestones:
- Some documents are pretty much ready, and some have been worked
  on for a long time -- we should move fast on those.
- If something doesn't move, we interpret that as a lack of
  interest and drop it. So authors, please keep moving them.

Jari Arkko: draft-ietf-radext-rfc2486bis-01.txt
----------------------------------------------

Overview
- Passed WGLC
- All issues raised in WGLC have been resolved
- Three new issues brought up since then
  - Better examples (#16)
  - Bernard's review and editorial nits (#15)
  - Josh's editorial nit (#17 part 1)
  - Suffix vs. prefix for the home realm (#17 part 2)
- All have been addressed, except last one
  - It was discussed extensively in EAP WG early in this work
  - Prefix approach works better with unmodified AAA nodes

Next steps:
- Will submit -02 as soon as submission opens again
- Jari thinks it's ready to go to IESG
- This is one of the 3GPP R6 dependencies marked as "critical", so it=20
  should be stable (approved by IESG) by December
- There is one reference to an internet-draft, but that's already in=20
  RFC editor queue, so it's not a problem

Wolfgang Back: RADIUS Extensions for Digest Authentication
(draft-sterman-aaa-sip-04.txt)
----------------------------------------------------------

This is now a WG item, but missed deadline for renaming it. Trying to=20
align the draft with the Diameter application (ietf-aaa-diameter-sip).=20

Response-Auth:
- Could not be calculated by RADIUS client alone, so we added a new
  attribute.
- Comment: MD5 might not be acceptable anymore.
- Response: This draft is not actually using MD5, just providing=20
  support for HTTP digest (which uses MD5).

Message-Authenticator:
- This is a good thing to do, but RFC3579 is Informational
- Added in -04 as "MAY"=20

What's a "secure connection"?
- Added some clarifications
- Question: What exactly is a secure connection (IPsec, MPLS VPN, ...),
  and should we rely on the operator getting this right?
- Comment: IPsec is used in RFC3579, so using it here should not be=20
  a problem.=20
- Comment: It's important that the RADIUS client/server knows that=20
  IPsec was used.
- Comment: The distinction is that this ID requires application to=20
  know that IPSec is being used.  That requirement is not in RFC3579.
- Comment:  RADIUS includes other means to hide attributes besides
IPSec.
  Other documents specify this.=20

IANA allocation
- IANA request has been submitted long ago, but received no decision
  yet.
- Comment: It's probably been lost; resend it and CC the Chairs.

Review
- Chairs: We need people to check -04 and say that it's OK.=20
  Silence does not mean WG consensus.
- Chairs: We may need a security review, too, considering the issues=20
  discussed today.  The chairs will contact the Security ADs to solicit=20
  reviewers.

Farid Adrangi: Carrying Location Objects in RADIUS
(draft-ietf-geopriv-radius-lo-01.txt)=20
--------------------------------------------------

Farid presented the history, motivation and overview of the draft
(see the slides). The goal is to convey location information to the=20
home AAA server while taking privacy into consideration. This will=20
support location-based authorization, taxation, location-based services,
a mid-session method for transfer. It is based on the CoA RFC and
reuses existing GEOPRIV work as much as possible.

- Question: What exactly does "not sharing the location information"
  mean, e.g., can RADIUS proxy forward it? Or how the home AAA server
  can use it?
- Response: The policy rules are intended for the home AAA server,=20
  and the policy is mostly about passing the information beyond the AAA
  infrastructure.

- Question: About retention: ISPs store accounting records for several
  years (because they're required to), so how the does the=20
  "retention-expires" work in this case?
- Response:  Most likely the entities are assumed to have business=20
  relationships and contracts that deal with some of these issues.

- Question: Should the users be setting their own location privacy
  policies?
- Response:  This is mostly between operators and based on operators'
  policy (if an operator needs the location for authorization and=20
  accounting).

- Question: So this is not about customers, it's about operators?
- Response: Yes.=20

- Comment: The location of the NAS often does not have anything to do=20
  with the location of the user.   The document supports both,=20
  and in case of wireless, the radio range is limited.
- Comment: Restricting this to only NAS location would simplify the
  draft and improve understandability.
- Comment: The location of the user is important.

- Question: Where does the NAS gets the location information?
- Response: NAS or AAA proxies are configured with this information.

There was discussion about alternative solutions. Since NASes don't in
general move, why this could not be solved by some other approach?
A table mapping NAS-Identifier to location at home AAA server does
not scale in roaming situations (consider 100,000 APs and 10,000 home
AAA networks). It's probably better to have this information in one
place and send it to home AAA server where it's actually used.

Chairs: We've had good discussion here, please continue it on the
mailing list.

Bernard Aboba (on behalf of Paul Congdon): 802.1 Support Attributes
(draft-congdon-radext-ieee802-02.txt)
-------------------------------------------------------------------

- Missed the ID update deadline
- Not many changes to the previous version
- Added VLAN-Name attribute
- There as been interest from Trusted Computing Group (TCG)
  in referencing RADIUS attribute documents, most likely this one=20
  and the bandwidth draft.
- Work has been slow, a new author should accelerate things
- Some people are interested in new Layer 2 filter attributes
- Is NIST ever going to speak up about key management attributes?
- Paul Congdon would like to get a "design team" to work on this draft,
  please contact him to volunteer
- Question: Does this document replace RFC3580?
- Response: No, it adds attributes for 802 stuff that was not covered
  by 3580, but explicitly stating this might help.

- Comment:  Some have expressed an interest in working on a RFC3580-like
  document for IPsec VPNs, "RADIUS usage guidelines for IPsec/IKE/IKEv2
  stuff". This would not necessarily define any new attributes, but at=20
  least clarify how existing ones should be used. Anyone interested=20
  should contact Pasi Eronen.

Farid Adrangi: Chargeable User identity
(draft-adrangi-radius-chargeable-user-identity-02.txt)
------------------------------------------------------

Farid went through current issues.  Issues 13, 14 and 15 are addressed
in the most recent draft.  There are two open issues: (a) backward=20
compatibility and (b) the lack of general capability negotiation
mechanism in RADIUS.  We could send a "hint" attribute in the Access-
Request message as indication of CUI feature support.

There was some discussion about why this draft is needed. The main
reason seems to be that currently User-Name is overloaded for both=20
routing and identification. The Class attribute works for two parties,
but not so well for multiple parties (like roaming clearinghouses).
It seems that the draft needs a better explanation of the problem=20
being solved.

Glen Zorn volunteered to send a paragraph clarifying the problem=20
statement to the list.

- Question: Clarification about the different identity type prefixes?
  It seems that the document defines a new number space, but does not=20
  say how numbers get added to that space.

Chairs: We would like more than two people to read this, and say on=20
the mailing list that they like it and would like it to be WG item.

Farid Adrangi: RADIUS Redirection
(draft-lior-radius-redirection-01.txt)
--------------------------------------

No activity.

Chairs: Please review and comment upon the draft.
=20

Farid Adrangi: Bandwidth Capability
(draft-adrangi-radius-bandwidth-capability-01.txt)              =20
--------------------------------------------------

In previous versions of the draft, there was some confusion about what
exactly NAS should do with these attributes, e.g. what kind of algorithm
it should apply to actually doing something about the traffic, or=20
reserving something, or something.

Farid presented the idea of having a general framework that would allow
different types of actions. =20

- Comment: A general framework without any concrete mechanisms is not
  useful. =20
- Response: The draft would define one or two concrete mechanisms as
  well, but allow others to define more in the future.

- Comment: This ID uses structured attributes, which are not very=20
  nice in RADIUS. Having separate attributes might be better from=20
  RADIUS point of view.
- Response: We are running out of RADIUS Attribute ID space.
- Comment: It's not clear that this is imminent, and when we do run
  out, there have been several proposals made on how do extend the ID=20
  space.  We could pursue one of those proposals, as needed.

- Comment: There's probably overlap with QoS-Filter-Rule attribute in
the=20
 802.1 LAN Attributes draft.=20

- Question: What is the relationship to Diameter QoS application draft.

- Comment: Having something very simple would probably be better than
  something complex and general.

Jari Arkko (on behalf of David Mariblanca): EAP lower layer attributes
(draft-mariblanca-aaa-eap-lla-01.txt)
----------------------------------------------------------------------

Jari presented the approach (see slides).

- Question: Do we want to just know the physical layer used to carry
EAP,
  or tell the difference between what kind of service the user is
  using?
- Response: The main goal was to tell the difference between 802.1X and
  IKEv2 cases, and allow policies like "this user can use 1X but not=20
  IKEv2".

-Comment: Using Service-Type or some other attribute  might be more=20
 appropriate.

Chairs: It seems that several people are interested in NAS-Port-Type
  and/or Service-Type usages.  It would be good if they can get together
  and review the alternatives.  Volunteers: Glen Zorn, Pasi Eronen,=20
  Jari Arkko.=20

Chairs: MIB work
----------------

RADIUS and RADIUS Accounting MIBs. An IPv6 MIB update was intended for
this meeting, but was delayed. The work is straightforward. MIB doctor=20
review and input will be sought for the MIB updates, once the drafts are
available.

RFC3576 MIB. (draft-decnodder-radext-dynauth-server-mib-01.txt)
Murtaza Chiba was not present.  We should proceed with this work, as it
is in the charter.  Will seek volunteers to review the current draft,
and
seek MIB Doctor review, as well.

The meeting ended about 11:00AM.

------------------------------------------------------

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 06 Dec 2004 16:57:51 +0000
Date: Mon, 6 Dec 2004 08:57:10 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Slides from IETF 61 RADEXT WG meeting

are available here:
http://www.drizzle.com/~aboba/IETF61/IETF61-RADEXT.zip

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 01 Dec 2004 06:44:28 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: REMINDER: RADEXT WG last call on RFC 2486bis-02
Date: Tue, 30 Nov 2004 22:44:00 -0800

Description of issue: Grammar problem
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 30 Nov 2004
Document: draft-ietf-radext-rfc2486bis-02.txt
Comment type: E
Priority: 2
Section: Appendix B.
Rationale/Explanation of issue: Possible grammar problem
Lengthy description of problem: The sentence "Thanks [...] for Farid
Adrangi and others for suggesting mediating network representation
in NAIs." just doesn't sound right.

Requested change: CHANGE
"Thanks to Glen Zorn for many useful discussions of this problem
space, and for Farid Adrangi and others for suggesting mediating
network representation in NAIs."
TO
"Thanks to Glen Zorn for many useful discussions of this problem
space, and to Farid Adrangi and others for suggesting the
representation of mediating networks in NAIs."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 01 Dec 2004 04:46:32 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: REMINDER: RADEXT WG last call on RFC 2486bis-02
Date: Tue, 30 Nov 2004 20:45:57 -0800

Description of issue: Misspelled word
Submitter name: Glen Zorn
Submitter email address: [email-masked]
Date first submitted: 30 Nov 2004
Document: draft-ietf-radext-rfc2486bis-02.txt
Comment type: E
Priority: 1
Section: 3
Rationale/Explanation of issue: grammatical error
Lengthy description of problem: "For instance, some EAP methods
apply a method-specific pseudonyms in the username part of the NAI."

Requested change: CHANGE
"For instance, some EAP methods apply a method-specific pseudonyms
in the username part of the NAI." 
TO EITHER 
"For instance, some EAP methods apply method-specific pseudonyms in
the username part of the NAI." 
OR 
"For instance, some EAP methods apply a method-specific pseudonym in
the username part of the NAI."

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>