Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Dec 2004 17:16:10 +0000 Date: Fri, 31 Dec 2004 09:15:02 -0800 (PST) From: Bernard Aboba To: john.loughney@nokia.com cc: radiusext@ops.ietf.org Subject: RE: Consensus on CUI Usage and Applicability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sure. On Fri, 31 Dec 2004 john.loughney@nokia.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 31 Dec 2004 07:04:00 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on CUI Usage and Applicability Date: Fri, 31 Dec 2004 09:03:09 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4325E6@esebe056.ntc.nokia.com> Thread-Topic: Consensus on CUI Usage and Applicability Thread-Index: AcTuxOH6X4mYL/u/RaSUGjKMpYMJPAAQc4kA From: To: , 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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba > Sent: 31 December, 2004 01:10 > To: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 30 Dec 2004 23:10:35 +0000 Date: Thu, 30 Dec 2004 15:09:37 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Consensus on CUI Usage and Applicability Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 29 Dec 2004 23:09:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI version -01 Date: Wed, 29 Dec 2004 15:08:53 -0800 Message-ID: Thread-Topic: CUI version -01 Thread-Index: AcTt+118+n8Y7/KPTGCnZClO6PMcUw== From: "Adrangi, Farid" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 22:54:09 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Thu, 23 Dec 2004 17:53:29 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:jari.arkko@piuha.net] > Sent: Thursday, December 23, 2004 4:06 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > 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 "1245@anisp.countryY" -- 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 21:42:10 +0000 Date: Thu, 23 Dec 2004 16:41:42 -0500 From: Barney Wolff To: Jari Arkko Cc: Avi Lior , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041223214142.GA10711@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 "1245@anisp.countryY" -- 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 21:06:31 +0000 Message-ID: <41CB3323.1070508@piuha.net> Date: Thu, 23 Dec 2004 23:05:39 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 "1245@anisp.countryY" -- 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 20:13:49 +0000 Date: Thu, 23 Dec 2004 15:13:32 -0500 From: Barney Wolff To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041223201332.GA1594@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Thu, Dec 23, 2004 at 02:28:22PM -0500, Alan DeKok wrote: > Barney Wolff 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 20:03:01 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: Season's Greetings. Date: Thu, 23 Dec 2004 15:02:46 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E92A.5F369F50" 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:avi@bridgewatersystems.com www.bridgewatersystems.com ------_=_NextPart_001_01C4E92A.5F369F50 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
To = all on the=20 RADIUSEXT list.
 
I = would like to wish=20 you and yours a very happy and healthy holiday season and a happy and = healthy=20 new year.
 
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.
 
I am = proud to be=20 associated with the folks on this list.
 
Cheers and please be=20 safe,
 
Avi
 

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

Avi=20 Lior          &nb= sp;           &nb= sp;           &nb= sp;=20
Bridgewater Systems=20 Corporation          &= nbsp;    =20
Phone :  (613) 591-9104 x6417

Cell    : =20 (613) 297-2177
E-mail : mailto:avi@bridgewatersystems.com<= /P>

www.bridgewatersystems.com 

 
 
------_=_NextPart_001_01C4E92A.5F369F50-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 19:54:29 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Thu, 23 Dec 2004 14:53:55 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Wednesday, December 22, 2004 4:39 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 19:16:28 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Date: Thu, 23 Dec 2004 14:28:22 -0500 Message-Id: <20041223192823.F142C16CC3@mail.nitros9.org> Barney Wolff 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 17:18:09 +0000 Message-ID: From: Avi Lior To: "'jari.arkko@piuha.net'" , Barney Wolff , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Thu, 23 Dec 2004 12:17:44 -0500 MIME-Version: 1.0 Content-Type: text/plain 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 12345@west.example.com 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:jari.arkko@piuha.net] > Sent: Thursday, December 23, 2004 8:25 AM > To: Barney Wolff; Nelson, David > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 16:34:48 +0000 Date: Thu, 23 Dec 2004 11:34:11 -0500 From: Barney Wolff To: Jari Arkko Cc: Alan DeKok , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041223163411.GA67928@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 15:40:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Thu, 23 Dec 2004 10:39:33 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19048@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTo8tBmPFh0OnGjQMGU0kjjkSNczgAEjiZQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 13:25:08 +0000 Message-ID: <41CAC710.6030802@piuha.net> Date: Thu, 23 Dec 2004 15:24:32 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Barney Wolff , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 13:16:47 +0000 Message-ID: <41CAC516.3070703@piuha.net> Date: Thu, 23 Dec 2004 15:16:06 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 23 Dec 2004 13:15:57 +0000 Message-ID: <41CAC4CF.10505@piuha.net> Date: Thu, 23 Dec 2004 15:14:55 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Emile van Bergen Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 23:13:28 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Date: Wed, 22 Dec 2004 18:25:20 -0500 Message-Id: <20041222232520.DDFF216FCD@mail.nitros9.org> Avi Lior 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 21:40:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 16:39:22 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19046@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcToaogxfqdPHWuFQJWknWKUmysPRwAAJ8aw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 21:09:49 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 16:09:23 -0500 MIME-Version: 1.0 Content-Type: text/plain David , See inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, December 22, 2004 3:01 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 20:01:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 15:00:32 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19043@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcToV56EUdAzB+YCS5icS5lEkm/1XQABJdtA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 19:21:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 14:20:59 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19042@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcToV56EUdAzB+YCS5icS5lEkm/1XQAAf7BA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 19:06:22 +0000 Message-ID: From: Avi Lior To: 'John Schnizlein' , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 14:06:08 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:jschnizl@cisco.com] > Sent: Wednesday, December 22, 2004 1:45 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 18:54:12 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 13:54:01 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi David, See comments inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, December 22, 2004 11:56 AM > To: radiusext@ops.ietf.org > 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 122345@example.com > > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 18:46:00 +0000 Message-Id: <4.3.2.7.2.20041222133926.026de918@wells.cisco.com> Date: Wed, 22 Dec 2004 13:45:22 -0500 To: Avi Lior From: John Schnizlein Subject: RE: Scope of applicability for CUI Cc: radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 16:57:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 11:56:29 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19041@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcToQZ4G/9Hr4lAOT6e2rw+4PwjJXAAAFCsQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 16:35:05 +0000 Message-ID: From: Avi Lior To: 'Alan DeKok' , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 11:34:49 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Alan, See comments inline. > -----Original Message----- > From: Alan DeKok [mailto:aland@ox.org] > Sent: Wednesday, December 22, 2004 11:26 AM > To: radiusext@ops.ietf.org > Subject: Re: Scope of applicability for CUI > > > "Nelson, David" 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 (Joe@example.com) and for franks session (frank@example.com) 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 16:16:47 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 11:16:31 -0500 MIME-Version: 1.0 Content-Type: text/plain David, See inline, > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Wednesday, December 22, 2004 10:15 AM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 16:14:25 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Date: Wed, 22 Dec 2004 11:25:55 -0500 Message-Id: <20041222162555.7B25716CC3@mail.nitros9.org> "Nelson, David" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 15:15:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 10:14:57 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1903E@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpYFrDazLuG1zR9KSJt48LsonuAAAfeqAAA2bBLAAFgImIA== From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 13:04:58 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550604E97A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , radiusext@ops.ietf.org Cc: bwijnen@lucent.com Subject: RE: review of draft-decnodder-radext-dynauth-server-mib-02.txt Date: Wed, 22 Dec 2004 14:04:19 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E826.BF453D66" 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:dromasca@avaya.com] Sent: Wednesday, December 22, 2004 10:35 To: radiusext@ops.ietf.org Cc: bwijnen@lucent.com 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 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" review of draft-decnodder-radext-dynauth-server-mib-02.txt
Thanks for your review Dan!
 
Bert
-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, December 22, 2004 10:35
To: radiusext@ops.ietf.org
Cc: bwijnen@lucent.com
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 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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 09:35:42 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E809.80954A07" Subject: review of draft-decnodder-radext-dynauth-server-mib-02.txt Date: Wed, 22 Dec 2004 11:34:58 +0200 Message-ID: Thread-Topic: review of draft-decnodder-radext-dynauth-server-mib-02.txt Thread-Index: AcToCYB+Ek9895I/Twi7zUScUEGu+Q== From: "Romascanu, Dan \(Dan\)" To: Cc: 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 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 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 ::=3D { = radiusMIB 3 }

is not good. We'd rather see:

radiusDynamicAuthorization OBJECT IDENTIFIER ::=3D { = 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_01C4E809.80954A07-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 04:28:47 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 06:27:43 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D0958CD@esebe056.ntc.nokia.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpYFrDazLuG1zR9KSJt48LsonuAAAfeqAAA2bBLA= From: To: , 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 > temp-user-id-4732875092384082309480923@example.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 04:18:36 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Wed, 22 Dec 2004 06:16:09 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432532@esebe056.ntc.nokia.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpcxPLhmyR72TQICeWZMuRsU47gANt9ew From: To: , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 22 Dec 2004 02:56:01 +0000 Date: Tue, 21 Dec 2004 21:55:28 -0500 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041222025528.GA22608@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 > temp-user-id-4732875092384082309480923@example.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 23:16:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 18:16:19 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1903D@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnsQluXXlipWKYT3GFhj9VHQ2cUwAAXeXA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 23:01:16 +0000 Message-ID: From: Avi Lior To: 'Bikramjit Singh' , 'Alan DeKok' , "'radiusext@ops.ietf.org'" Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 18:00:42 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E7B0.E5B98EA0" 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:BSingh@Nomadix.com] Sent: Tuesday, December 21, 2004 3:53 PM To: 'Alan DeKok'; 'radiusext@ops.ietf.org' 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/joe@D.com 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org ] On Behalf Of Alan DeKok Sent: Tuesday, December 21, 2004 12:09 PM To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Avi Lior 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: > ------_=_NextPart_001_01C4E7B0.E5B98EA0 Content-Type: text/html Message
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:BSingh@Nomadix.com]
Sent: Tuesday, December 21, 2004 3:53 PM
To: 'Alan DeKok'; 'radiusext@ops.ietf.org'
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/joe@D.com 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok
Sent: Tuesday, December 21, 2004 12:09 PM
To: radiusext@ops.ietf.org
Subject: Re: Scope of applicability for CUI

Avi Lior <avi@bridgewatersystems.com> 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E7B0.E5B98EA0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:46:31 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:46:13 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 5:35 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:36:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:34:52 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1903A@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnqu/ZoqCf7n0+SZm9Lm/3lHh6XgAASg2A From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:20:20 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Avi Lior , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:20:00 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 4:50 PM > To: Avi Lior; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:18:19 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:17:55 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 5:07 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:07:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:07:16 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19039@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnqEmvT9TBaQqESSa45zfYuRF5IQAAK1iA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 22:03:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 17:02:10 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19038@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpYFrDazLuG1zR9KSJt48LsonuAAAfeqA From: "Nelson, David" To: 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 temp-user-id-4732875092384082309480923@example.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:59:03 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:58:47 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 4:48 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:57:17 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI Date: Tue, 21 Dec 2004 16:56:59 -0500 MIME-Version: 1.0 Content-Type: text/plain David, Opaque value was used in Diameter. Also, see inline. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 4:46 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:50:22 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:49:59 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19037@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpiKtqpsuN42BT7GFognbXO+miQAALgMg From: "Nelson, David" To: "Avi Lior" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:48:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:47:56 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19036@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnpYFrDazLuG1zR9KSJt48LsonuAAAQVJw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:45:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI Date: Tue, 21 Dec 2004 16:45:31 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19035@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Transparency (e.g. NAS visibility of) CUI Thread-Index: AcTnpSoEsbVaGFQyQkSpFGuNTtm8wgAADeWA From: "Nelson, David" To: > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:43:33 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:43:17 -0500 MIME-Version: 1.0 Content-Type: text/plain > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 4:15 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:39:57 +0000 Message-ID: From: Avi Lior To: 'Alan DeKok' , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:39:39 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aland@ox.org] > Sent: Tuesday, December 21, 2004 3:09 PM > To: radiusext@ops.ietf.org > Subject: Re: Scope of applicability for CUI > > > Avi Lior 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:39:38 +0000 Date: Tue, 21 Dec 2004 16:39:07 -0500 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041221213907.GA6885@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:38:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Transparency (e.g. NAS visibility of) CUI Date: Tue, 21 Dec 2004 16:37:57 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19034@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Transparency (e.g. NAS visibility of) CUI Thread-Index: AcTnmPSVfuOcsPpxSkGKMi7zDtT/7wABkPTgAADaV9AAAGJJAA== From: "Nelson, David" To: Oh, yeah... the template. Sorry. :-( Description of issue: The transparency (e.g. NAS visibility) of CUI Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:36:42 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Issue: Transparency (e.g. NAS visibility of) CUI Date: Tue, 21 Dec 2004 16:36:16 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Tuesday, December 21, 2004 4:23 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:24:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue: Transparency (e.g. NAS visibility of) CUI Date: Tue, 21 Dec 2004 16:23:09 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19033@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue: Transparency (e.g. NAS visibility of) CUI Thread-Index: AcTnmPSVfuOcsPpxSkGKMi7zDtT/7wABkPTgAADaV9A= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:18:11 +0000 Message-ID: From: Avi Lior To: 'Emile van Bergen' , Avi Lior Cc: Jari Arkko , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:17:56 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Emile, > -----Original Message----- > From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] > Sent: Tuesday, December 21, 2004 3:14 PM > To: Avi Lior > Cc: Jari Arkko; radiusext@ops.ietf.org > 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:openradius-radextwg@e-advies.nl] > > > Sent: Monday, December 20, 2004 5:36 PM > > > To: Jari Arkko > > > Cc: Avi Lior; radiusext@ops.ietf.org > > > 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 emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:16:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 16:14:52 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19032@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTnmPSVfuOcsPpxSkGKMi7zDtT/7wABkPTg From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 21:00:55 +0000 Message-ID: <89680B404BA1DD419E6D93B28B41899B02D198AE@01MAIL> From: Bikramjit Singh To: 'Alan DeKok' , "'radiusext@ops.ietf.org'" Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 12:52:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E79F.0828FFDC" 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/joe@D.com 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok Sent: Tuesday, December 21, 2004 12:09 PM To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Avi Lior 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4E79F.0828FFDC Content-Type: text/html Content-Transfer-Encoding: quoted-printable 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/joe@D.com 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org] On Behalf Of Alan DeKok
Sent: Tuesday, December 21, 2004 12:09 PM
To: radiusext@ops.ietf.org
Subject: Re: Scope of applicability for CUI

Avi Lior <avi@bridgewatersystems.com> 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 = radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the = message text body.
archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E79F.0828FFDC-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 20:08:56 +0000 Date: Tue, 21 Dec 2004 21:13:33 +0100 From: Emile van Bergen To: Avi Lior Cc: Jari Arkko , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041221201332.GB3804@host.e-advies.nl> Mail-Followup-To: Avi Lior , Jari Arkko , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i 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:openradius-radextwg@e-advies.nl] > > Sent: Monday, December 20, 2004 5:36 PM > > To: Jari Arkko > > Cc: Avi Lior; radiusext@ops.ietf.org > > 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 emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 19:57:02 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Date: Tue, 21 Dec 2004 15:08:46 -0500 Message-Id: <20041221200847.F2F0816CC3@mail.nitros9.org> Avi Lior 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 17:22:06 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Emile van Bergen'" Cc: Jari Arkko , "'Avi Lior'" , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 11:21:32 -0600 MIME-Version: 1.0 Content-Type: text/plain 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:openradius-radextwg@e-advies.nl] Sent: Monday, December 20, 2004 10:50 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: Jari Arkko; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org 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:emile@e-advies.nl] > Sent: Saturday, December 18, 2004 12:19 PM > To: Jari Arkko > Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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 emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 17:01:32 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550604E819@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Romascanu, Dan (Dan)" , radiusext@ops.ietf.org Subject: RE: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt Date: Tue, 21 Dec 2004 18:00:22 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E77E.8EF79102" 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:dromasca@avaya.com] Sent: Monday, December 20, 2004 15:39 To: radiusext@ops.ietf.org Cc: bwijnen@lucent.com 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 = =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" Comments on draft-decnodder-radext-dynauth-client-mib-02.txt
Thanks for the review Dan.
 
Let me add w.r.t. point 6
 
We do not like the idea of doing a separate subtree for each technology.
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 I'd like to see a document similar
to  RFC3737.
 
Bert
 
 -----Original Message-----
From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Monday, December 20, 2004 15:39
To: radiusext@ops.ietf.org
Cc: bwijnen@lucent.com
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.

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.

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

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.

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.

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.

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

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?

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

14. same for radiusDynAuthClientCoAPacketsDropped

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

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.

------_=_NextPart_001_01C4E77E.8EF79102-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 17:01:09 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550604E818@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: radiusext@ops.ietf.org Subject: Checks on draft-decnodder-radext-dynauth-server-mib-02.txt Date: Tue, 21 Dec 2004 18:00:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" --- 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 17:01:04 +0000 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550604E817@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: radiusext@ops.ietf.org Subject: Checks on draft-decnodder-radext-dynauth-client-mib-02.txt Date: Tue, 21 Dec 2004 18:00:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" ---- 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 21 Dec 2004 15:57:51 +0000 Message-ID: From: Avi Lior To: 'Emile van Bergen' , Jari Arkko Cc: Avi Lior , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Tue, 21 Dec 2004 10:56:43 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Emile, I think we agree overall. See comments inline. > -----Original Message----- > From: Emile van Bergen [mailto:openradius-radextwg@e-advies.nl] > Sent: Monday, December 20, 2004 5:36 PM > To: Jari Arkko > Cc: Avi Lior; radiusext@ops.ietf.org > 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 emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 22:31:26 +0000 Date: Mon, 20 Dec 2004 23:35:55 +0100 From: Emile van Bergen To: Jari Arkko Cc: Avi Lior , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041220223555.GA29692@host.e-advies.nl> Mail-Followup-To: Jari Arkko , Avi Lior , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i 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 emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 20:31:17 +0000 Message-ID: <41C7366B.20109@piuha.net> Date: Mon, 20 Dec 2004 22:30:35 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Avi Lior Cc: Emile van Bergen , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 20:06:18 +0000 Message-ID: From: Avi Lior To: Nakhjiri Madjid-MNAKHJI1 , "'jari.arkko@piuha.net'" Cc: 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 15:04:56 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:Madjid.Nakhjiri@motorola.com] > Sent: Monday, December 20, 2004 11:31 AM > To: 'jari.arkko@piuha.net' > Cc: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > Subject: RE: Scope of applicability for CUI > > > Hi Jari, > > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net] > Sent: Saturday, December 18, 2004 3:21 AM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 20:06:15 +0000 Message-ID: From: Avi Lior To: Emile van Bergen , john.loughney@nokia.com Cc: jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, avi@bridgewatersystems.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 15:04:57 -0500 MIME-Version: 1.0 Content-Type: text/plain 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 emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 20:06:11 +0000 Message-ID: From: Avi Lior To: Emile van Bergen , Nakhjiri Madjid-MNAKHJI1 Cc: Jari Arkko , 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 15:04:56 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:openradius-radextwg@e-advies.nl] > Sent: Monday, December 20, 2004 11:50 AM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: Jari Arkko; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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:emile@e-advies.nl] > > Sent: Saturday, December 18, 2004 12:19 PM > > To: Jari Arkko > > Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; > radiusext@ops.ietf.org > > 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 emile@e-advies.nl > > tel. +31 (0)70 3906153 http://www.e-advies.nl > -- > E-Advies - Emile van Bergen emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 17:56:17 +0000 Date: Mon, 20 Dec 2004 19:00:51 +0100 From: Emile van Bergen To: john.loughney@nokia.com Cc: jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, avi@bridgewatersystems.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041220180051.GD28090@host.e-advies.nl> Mail-Followup-To: john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, avi@bridgewatersystems.com, dnelson@enterasys.com, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Hi, On Sun, Dec 19, 2004 at 09:24:33AM +0200, john.loughney@nokia.com 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 emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 16:45:45 +0000 Date: Mon, 20 Dec 2004 17:50:14 +0100 From: Emile van Bergen To: Nakhjiri Madjid-MNAKHJI1 Cc: Jari Arkko , 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041220165014.GA28090@host.e-advies.nl> Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 , Jari Arkko , 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i 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:emile@e-advies.nl] > Sent: Saturday, December 18, 2004 12:19 PM > To: Jari Arkko > Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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 emile@e-advies.nl > tel. +31 (0)70 3906153 http://www.e-advies.nl -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 16:34:48 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Emile van Bergen'" , Jari Arkko Cc: "'Avi Lior'" , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 10:34:30 -0600 MIME-Version: 1.0 Content-Type: text/plain Can you explain it a bit more for the less sophisticated? Thanks, Madjid -----Original Message----- From: Emile van Bergen [mailto:emile@e-advies.nl] Sent: Saturday, December 18, 2004 12:19 PM To: Jari Arkko Cc: Nakhjiri Madjid-MNAKHJI1; 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org 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 emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 16:31:11 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'jari.arkko@piuha.net'" Cc: "'Avi Lior'" , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 10:30:44 -0600 MIME-Version: 1.0 Content-Type: text/plain Hi Jari, -----Original Message----- From: Jari Arkko [mailto:jari.arkko@piuha.net] Sent: Saturday, December 18, 2004 3:21 AM To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 15:56:44 +0000 Date: Mon, 20 Dec 2004 10:56:35 -0500 From: Barney Wolff To: jouni.korhonen@teliasonera.com Cc: radiusext@ops.ietf.org Subject: Re: CUI multi-session Message-ID: <20041220155634.GA73090@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Mon, Dec 20, 2004 at 11:19:22AM +0200, jouni.korhonen@teliasonera.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 15:54:01 +0000 Message-ID: From: Avi Lior To: jari.arkko@piuha.net, Bernard Aboba Cc: Avi Lior , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Mon, 20 Dec 2004 10:53:20 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:jari.arkko@piuha.net] > Sent: Saturday, December 18, 2004 4:46 AM > To: Bernard Aboba > Cc: Avi Lior; Adrangi, Farid; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 15:38:48 +0000 Message-ID: From: Avi Lior To: jari.arkko@piuha.net, Nakhjiri Madjid-MNAKHJI1 Cc: 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Mon, 20 Dec 2004 10:38:28 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:jari.arkko@piuha.net] > Sent: Saturday, December 18, 2004 4:21 AM > To: Nakhjiri Madjid-MNAKHJI1 > Cc: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 14:39:09 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E6A1.93A677E4" Subject: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt Date: Mon, 20 Dec 2004 16:38:31 +0200 Message-ID: Thread-Topic: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt Thread-Index: AcTmoZOeFLoRD+xxRuqJw7IK05YlaA== From: "Romascanu, Dan \(Dan\)" To: Cc: 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 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.

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

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

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.

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

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.

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

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?

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

14. = same for radiusDynAuthClientCoAPacketsDropped

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

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.

------_=_NextPart_001_01C4E6A1.93A677E4-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 09:20:05 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: Date: Mon, 20 Dec 2004 11:19:22 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A31DF0391@FITMS201MB.tcad.telia.se> Thread-Index: AcTmdP4gCuLXAnhbSlq9Ugx5m9jPOw== From: To: , , Cc: , , 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 20 Dec 2004 08:26:16 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B51A@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: jari.arkko@piuha.net Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: RE: Radius-Geopriv: User Identity Confidentiality Date: Mon, 20 Dec 2004 09:25:06 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Dec 2004 18:13:52 +0000 Date: Sun, 19 Dec 2004 10:13:18 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: [Issue] Comments to draft-ietf-radext-digest-auth-00.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII -------- Original Message -------- Subject: Comments to draft-ietf-radext-digest-auth-00.txt Date: Wed, 15 Dec 2004 15:45:04 +0200 From: Miguel Garcia To: Beck01, Wolfgang CC: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 19 Dec 2004 07:28:04 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Sun, 19 Dec 2004 09:24:33 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D43250D@esebe056.ntc.nokia.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTk4yRgUUX1W9aGTlKf+VAJkkDxAAAt/E5Q From: To: , Cc: , , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Dec 2004 09:46:55 +0000 Message-ID: <41C3FC6C.7030600@piuha.net> Date: Sat, 18 Dec 2004 11:46:20 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: Avi Lior , "Adrangi, Farid" , radiusext@ops.ietf.org Subject: Re: backwards compatible introduction of NEW attribute such as CU I Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Dec 2004 09:21:59 +0000 Message-ID: <41C3F689.4030200@piuha.net> Date: Sat, 18 Dec 2004 11:21:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Nakhjiri Madjid-MNAKHJI1 Cc: 'Avi Lior' , "'Nelson, David'" , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 18 Dec 2004 06:37:36 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Sat, 18 Dec 2004 08:33:26 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432505@esebe056.ntc.nokia.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTkV7sAHb+GYR/8SGi386moLeTUcwAc6BLQ From: To: , Cc: , > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 23:12:36 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org 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 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Friday, December 17, 2004 5:27 PM > To: radiusext@ops.ietf.org > 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: > papabear@example.com, > > mamabear@example.com etc,, while the billing identity is > > thebearfamily@example.com. 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 22:27:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Mandating 3579 and 2486bis for CUI was RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 17:26:40 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19023@MAANDMBX2.ets.enterasys.com> Thread-Topic: Mandating 3579 and 2486bis for CUI was RE: Scope of applicability for CUI Thread-Index: AcTkhQ0+H0Bia1UDR6+M5o2LMMcbCgAAQJkQ From: "Nelson, David" To: Avi Lior writes... > Family members may have one username for example: papabear@example.com, > mamabear@example.com etc,, while the billing identity is > thebearfamily@example.com. 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 22:08:07 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org 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 MIME-Version: 1.0 Content-Type: text/plain 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: papabear@example.com, mamabear@example.com etc,, while the billing identity is thebearfamily@example.com. 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 joe@example.com and frank@example.com both with CUI west.example.com and sally@example.com and ann@example.com 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:dnelson@enterasys.com] > Sent: Friday, December 17, 2004 4:35 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 21:36:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Mandating 3579 and 2486bis for CUI was RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 16:34:35 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19021@MAANDMBX2.ets.enterasys.com> Thread-Topic: Mandating 3579 and 2486bis for CUI was RE: Scope of applicability for CUI Thread-Index: AcTkfPAARXFdTRZNSlS/kVCpdaiOgAAAb1aA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 21:10:52 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: Mandating 3579 and 2486bis for CUI was RE: Scope of applicabilit y for CUI Date: Fri, 17 Dec 2004 16:09:23 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Friday, December 17, 2004 3:08 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 20:29:18 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 14:27:47 -0600 MIME-Version: 1.0 Content-Type: text/plain 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:avi@bridgewatersystems.com] Sent: Friday, December 17, 2004 1:43 PM To: Nakhjiri Madjid-MNAKHJI1; Avi Lior; 'Nelson, David'; radiusext@ops.ietf.org 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:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 17, 2004 12:23 PM > To: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior > Sent: Thursday, December 16, 2004 5:14 PM > To: 'Nelson, David'; radiusext@ops.ietf.org > 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:dnelson@enterasys.com] > > Sent: Thursday, December 16, 2004 1:29 PM > > To: radiusext@ops.ietf.org > > 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 > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 20:10:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 15:07:36 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19020@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTkcMyg1WDocaQzQrKz6o3LhOyriQAACUHQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 19:43:10 +0000 Message-ID: From: Avi Lior To: 'Nakhjiri Madjid-MNAKHJI1' , Avi Lior , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 14:42:37 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:Madjid.Nakhjiri@motorola.com] > Sent: Friday, December 17, 2004 12:23 PM > To: 'Avi Lior'; 'Nelson, David'; radiusext@ops.ietf.org > 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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior > Sent: Thursday, December 16, 2004 5:14 PM > To: 'Nelson, David'; radiusext@ops.ietf.org > 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:dnelson@enterasys.com] > > Sent: Thursday, December 16, 2004 1:29 PM > > To: radiusext@ops.ietf.org > > 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 > > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > > a single line as the message text body. > > archive: > > > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 17:23:26 +0000 Message-ID: From: Nakhjiri Madjid-MNAKHJI1 To: "'Avi Lior'" , "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 11:23:05 -0600 MIME-Version: 1.0 Content-Type: text/plain 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Avi Lior Sent: Thursday, December 16, 2004 5:14 PM To: 'Nelson, David'; radiusext@ops.ietf.org 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:dnelson@enterasys.com] > Sent: Thursday, December 16, 2004 1:29 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 16:53:07 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: AW: backwards compatible introduction of NEW attribute such a s CU I Date: Fri, 17 Dec 2004 11:52:48 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aboba@internaut.com] > Sent: Friday, December 17, 2004 2:47 AM > To: Nelson, David > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 16:43:04 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Avi Lior Cc: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Fri, 17 Dec 2004 11:42:50 -0500 MIME-Version: 1.0 Content-Type: text/plain I agree. The intent of this draft was not to make the CUI broadly required. > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Friday, December 17, 2004 1:44 AM > To: Avi Lior > Cc: 'Nelson, David'; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 16:38:48 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Avi Lior Cc: "Adrangi, Farid" , radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Fri, 17 Dec 2004 11:38:12 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:aboba@internaut.com] > Sent: Friday, December 17, 2004 2:57 AM > To: Avi Lior > Cc: Adrangi, Farid; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 13:37:44 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE00@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: radiusext@ops.ietf.org Subject: AW: AW: Comments to draft-ietf-radext-digest-auth-00.txt Date: Fri, 17 Dec 2004 14:37:06 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 11:04:48 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [RFC2486bis] Issue 42: Definition of "Privacy" Date: Fri, 17 Dec 2004 13:03:28 +0200 Message-ID: <125EA890549C8641A72F3809CB80DCCD16FE30@esebe056.ntc.nokia.com> Thread-Topic: [RFC2486bis] Issue 42: Definition of "Privacy" Thread-Index: AcTkDRmr/TOkwWslSeiBpB60ysW00gAEPDDQ From: To: , Bernard Aboba wrote: > Sent: Friday, December 17, 2004 9:42 AM > To: radiusext@ops.ietf.org > Subject: [RFC2486bis] Issue 42: Definition of "Privacy" >=20 >=20 > Issue 42: Definition of "Privacy" > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 10:10:06 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FDFF@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: radiusext@ops.ietf.org Subject: AW: Comments to draft-ietf-radext-digest-auth-00.txt Date: Fri, 17 Dec 2004 11:09:25 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 07:57:47 +0000 Date: Thu, 16 Dec 2004 23:57:27 -0800 (PST) From: Bernard Aboba To: Avi Lior cc: "Adrangi, Farid" , radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 07:47:01 +0000 Date: Thu, 16 Dec 2004 23:46:46 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: AW: backwards compatible introduction of NEW attribute such as CU I Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 07:42:00 +0000 Date: Thu, 16 Dec 2004 23:41:31 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: [RFC2486bis] Issue 42: Definition of "Privacy" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 42: Definition of "Privacy" Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 17 Dec 2004 06:45:49 +0000 Date: Fri, 17 Dec 2004 01:43:57 -0500 From: Barney Wolff To: Avi Lior Cc: "'Nelson, David'" , radiusext@ops.ietf.org Subject: Re: Scope of applicability for CUI Message-ID: <20041217064357.GA87958@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 23:14:45 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Scope of applicability for CUI Date: Thu, 16 Dec 2004 18:14:09 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Thursday, December 16, 2004 1:29 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 21:09:34 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" Cc: "'radiusext@ops.ietf.org'" Subject: RE: Scope of applicability for CUI Date: Thu, 16 Dec 2004 16:09:16 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Thursday, December 16, 2004 1:29 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 20:59:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 12:58:43 -0800 Message-ID: Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjrZZwc4YGhyoeRy+TeaD2xuDAxAABGB+w From: "Adrangi, Farid" To: "Greg Weber" Cc: Thanks so much Greg. Will fix these in the next version. BR, Farid > -----Original Message----- > From: Greg Weber [mailto:gdweber@cisco.com]=20 > Sent: Thursday, December 16, 2004 12:27 PM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 20:27:43 +0000 From: Greg Weber Message-Id: <200412162026.PAA06327@cisco.com> Subject: Re: CUI - issues addressed in version 3 To: farid.adrangi@intel.com (Adrangi, Farid) Date: Thu, 16 Dec 2004 15:26:51 -0500 (EST) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit > > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 19:00:02 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 13:59:42 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:barney@databus.com] > Sent: Thursday, December 16, 2004 2:17 AM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 18:30:19 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Scope of applicability for CUI Date: Thu, 16 Dec 2004 13:29:03 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19017@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI Thread-Index: AcTjnALwTAsNOxpdS6al5AR4ArNGngAACNKw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 18:19:59 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org 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 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Thursday, December 16, 2004 1:07 PM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 18:10:35 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 13:10:26 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:dnelson@enterasys.com] > Sent: Thursday, December 16, 2004 11:52 AM > To: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 18:08:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19016@MAANDMBX2.ets.enterasys.com> Thread-Topic: Scope of applicability for CUI (was: RE: AW: backwards compatible introduction of NEW attribute such as CU I) Thread-Index: AcTjkwWMYD/ioHbDQa2u617q0HyxuAABVIOQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 17:14:20 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , Lothar Reith Cc: "'Adrangi, Farid'" , "'radiusext@ops.ietf.org'" Subject: RE: AW: backwards compatible introduction of NEW attribute such a s CU I Date: Thu, 16 Dec 2004 12:13:29 -0500 MIME-Version: 1.0 Content-Type: text/plain Bernard, Lothar, I stated this in another email but I want to do it here as well. I don't think that CUI should be tied down to 3579. I think business drivers should determine whether or not CUI is used. Furthermore: Barney's issue 22 raised the question "who needs the CUI?" Barney later answers this question "it is the NAS owner which *requires* CUI presence" Lothar "statead (and still maintain) my opinion that it is the home server operator who *requires* CUI presence." I don't agree with Lothar at all. Barney is absolutely correct. In fact this statement by Barney reflects the driver for CUI: "the NAS owner only requires CUI if iPass won't do business without it. That's not a technical requirement, or a logical requirement, but it is, perhaps, a statement about the real world." The home network doesn't need CUI. CUI provides the following capabilities: -it allows correlation of mulitple access-request/access-accepts to the same user. -it allows correlation of accounting sessions to the same user. The home network can do the above correlation without the need for CUI. Since it knows the identity of the user it can correlate multiple access-request to that user and thus can prevent multiple logons. The home network can use class to correlate accounting information to the same user. In order for Proxies to perform the same operations they need CUI. This is what iPass requires to do business and other intermediaries. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, December 16, 2004 10:23 AM > To: Lothar Reith > Cc: 'Adrangi, Farid'; 'radiusext@ops.ietf.org' > Subject: Re: AW: backwards compatible introduction of NEW > attribute such as CU I > > > > Is that true for the roaming privacy application ? And is > a privacy > > NAI well defined ? Is anonymous@example.com also a privacy NAI ? Or > > > anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-priv > > acy@ex > > ample.com ? > > One of the tasks for RFC 2486bis was to add privacy support > to RFC 2486. Are you claiming that the draft does not define > this service? My understanding was that "Privacy" in RFC > 2486bis is defined as an NAI without a user-id portion. > While I realize that there are RADIUS servers that treat user > "anonymous" differently, this is not universally implemented > (or even specified) so it will not interoperate. > > > My proposal has been the other way round. But perhaps your proposal > > fits more easily with the backwards compatibility > requirement of both > > the server and the NAS. > > The problem with requiring that the RADIUS server *always* > send CUI is that no existing RADIUS servers do this. > However, if we restrict the applicability of CUI, then it may > be reasonable to expect that a RADIUS server that implements > RFC 3579 and "Privacy" as defined in RFC 2486bis will be > upgraded to also support CUI. CUI support therefore becomes > part of the "Privacy" functionality package. > > > It requires however that the NAS is ALWAYS able to > INITIALLY DETERMINE > > the requirement for CUI presence. This means it may > ultimately have to > > rely on the end user presenting an identity which can be > identified by > > the NAS as Request to one of the upstream sever(s) saying: > > > "CUI-attribute-presence-required-in-the-accept-message-otherwise-I-wil > > l-chan > > ge-the-accept-into-a-reject" . > > Yes. And I think defining that sufficiently well is the task > of RFC 2486bis. > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 16:56:36 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Thu, 16 Dec 2004 11:56:23 -0500 MIME-Version: 1.0 Content-Type: text/plain Bernard, See comments inlien > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, December 16, 2004 3:29 AM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 16:53:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 11:51:55 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19015@MAANDMBX2.ets.enterasys.com> Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjjc4NxDBzqrxbQXSg6yLmAAX6KgAAQ+OQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 16:37:36 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , farid.adrangi@intel.com, barney@databus.com Cc: radiusext@ops.ietf.org Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 11:37:01 -0500 MIME-Version: 1.0 Content-Type: text/plain 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: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, December 15, 2004 11:13 PM > To: farid.adrangi@intel.com; barney@databus.com > Cc: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 15:39:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: AW: backwards compatible introduction of NEW attribute such as CU I Date: Thu, 16 Dec 2004 10:37:30 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19011@MAANDMBX2.ets.enterasys.com> Thread-Topic: AW: backwards compatible introduction of NEW attribute such as CU I Thread-Index: AcTjg3QCdNYiDu3/Q22q2hfmn8G00gAALzww From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 15:23:32 +0000 Date: Thu, 16 Dec 2004 07:23:13 -0800 (PST) From: Bernard Aboba To: Lothar Reith cc: "'Adrangi, Farid'" , "'radiusext@ops.ietf.org'" Subject: Re: AW: backwards compatible introduction of NEW attribute such as CU I Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is that true for the roaming privacy application ? And is a privacy NAI > well defined ? Is anonymous@example.com also a privacy NAI ? Or > anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 15:08:02 +0000 Message-ID: <41C1A454.3050805@piuha.net> Date: Thu, 16 Dec 2004 17:05:56 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba , "Beck01, Wolfgang" Cc: radiusext@ops.ietf.org Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 14:12:18 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201B6915B@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" , "'Adrangi, Farid'" Cc: "'radiusext@ops.ietf.org'" Subject: AW: backwards compatible introduction of NEW attribute such as CU I Date: Thu, 16 Dec 2004 15:11:09 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E379.176BD5AC" 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 anonymous@example.com 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 AW: backwards compatible introduction of NEW attribute such as = CUI

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 anonymous@example.com = also a privacy NAI ? Or = anonymous-class-requesting-extra-short-CUI-lifetime-for-increased-privac= y@example.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-change-the-accept-into-a-reject" .

Lothar

------_=_NextPart_001_01C4E379.176BD5AC-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 12:32:38 +0000 Message-ID: <41C1803A.5050301@piuha.net> Date: Thu, 16 Dec 2004 14:31:54 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "James M. Polk" Cc: Tschofenig Hannes , radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] Radius-Geopriv: Civic vs. geospatial location information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 >>>> Geopriv@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/geopriv >>> >>> >>> cheers, >>> James >>> ******************* >>> Truth is not to be argued... it is to be presented >>> _______________________________________________ >>> Geopriv mailing list >>> Geopriv@ietf.org >>> 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 12:07:44 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 14:07:08 +0200 Message-ID: <07B14A720C46C344AC96AAA64F5D6A313BECBC@FITMS201MB.tcad.telia.se> Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjQsWg1XfPx8dWR7iTm8Nvy/sgFQAFqzkA From: To: , Cc: Barney, Farid, Some thoughts and comments inline. Cheers, Jouni > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Barney Wolff > Sent: 16. joulukuuta 2004 9:17 > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 08:29:33 +0000 Date: Thu, 16 Dec 2004 00:29:02 -0800 (PST) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CUI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 07:18:07 +0000 Date: Thu, 16 Dec 2004 02:17:23 -0500 From: Barney Wolff To: "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: Re: CUI - issues addressed in version 3 Message-ID: <20041216071723.GA81859@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Wed, Dec 15, 2004 at 04:47:32PM -0800, Adrangi, Farid wrote: > > It seems to me the advertisement capability generating more heat than > light! Actually, I am not sure if the advertisement capability is > really required as I stated in my previous e-mail (on a different > thread). What if we remove the advertisment capability and simply say > this: > > " > In cases where the home RADIUS server cannot determine the NAS support > for the CUI, if the home RADIUS server requires the NAS support for CUI > for any reason (e.g., for billing or charging purposes), the home RADIUS > server MUST reject the request by sending an Access-Reject message > including an Error-Cause attribute [RFC3576] with value (to-be-defined) > (decimal), "CUI-Support-Undetermined". Otherwise, if the authentication > is successful, the home RADIUS server MUST send both the User-Name (1) > attribute and the CUI attribute, with the understanding that if the NAS > supports the CUI attribute the CUI attribute will override the identity > portion the User-Name (1) attribute. That is, the User-Name(1) > attribute will be used for routing and the CUI attribute will be used > for identity purposes. When an Access-Accept without the CUI attribute > is received, if the NAS requires the CUI attribute to be present in the > Access-Accept, the NAS SHOULD treat the Access-Accept as a reject. > " > > Is this aligned with your thoughts? The last part is. For the server, I cannot understand the case where the server's owner demands CUI but the NAS/Proxy owners did not: the server can always use Class*. Sending back User-Name risks the routing problems that motivated a separate CUI. * Let's not claim that Class is unreliable, or truncated, but somehow CUI will avoid such problems. Anyway, it's the server that gets to put in the first Class attribute, so if truncation is a problem it will be boxes upstream that suffer it. > > The vagueness is, I think, in whether there needs to be a 1:1 > > relationship > > CUI<->real_user and if so over what period. "Valid" does not > > capture the > > business requirement, which seems to be that the proxy/NAS > > owner demands > > to be able to recognize that two sessions were initiated by > > the same user, > > if I have understood things correctly. Or perhaps I have it > > backwards, > > and the requirement is to be sure that two sessions were initiated by > > different users! > > IMO, even 1:1 relationship CUI<->real_user is also out of scope. For > clarify maybe the paragraph should be rephrased as below: > " > The CUI format (i.e., User-Identity types listed above) and > configuration (e.g., CUI lifetime) will be determined based on > business/deployment decisions by the *home network*. Standards bodies / > organizations like 3GPP and GSMA will be responsible for defining how > the CUI should be formatted and configured based on their security / > deployment requirements and business needs. > " This doesn't fly, if it is the NAS/proxy owner that's requiring CUI. Surely the binding lifetime is part of that requirement. I'm not concerned with the value per se (that can always be configurable) but with its interpretation. For example, if lifetime is 1 hour, does that mean from one session start to the next, or from session end to the next session start, or simply that the binding can change each hour of the day, so might change between sessions starting at 09:59 and 10:01? Can a developer write a RADIUS server that will work in any application? If those demanding CUI have been specific enough to answer such questions, I've missed it. Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 04:44:28 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 06:42:55 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432498@esebe056.ntc.nokia.com> Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjAhDaYjBr1bJ6QlWyOPYza3BmyAAAKzfAAAig07AAARDIkA== From: To: , , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 04:33:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 15 Dec 2004 20:31:59 -0800 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTjFxnU7ccRCxfKTt+BHRJt/r3d/AAEMaAw From: "Adrangi, Farid" To: "Bernard Aboba" , "Nelson, David" Cc: 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Wednesday, December 15, 2004 6:29 PM > To: Nelson, David > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 04:33:13 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Thu, 16 Dec 2004 06:12:51 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D432497@esebe056.ntc.nokia.com> Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjAhDaYjBr1bJ6QlWyOPYza3BmyAAAKzfAAAig07A= From: To: , Cc: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 02:29:38 +0000 Date: Wed, 15 Dec 2004 18:29:12 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CUI Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 16 Dec 2004 00:47:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Wed, 15 Dec 2004 16:47:32 -0800 Message-ID: Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTjAhDaYjBr1bJ6QlWyOPYza3BmyAAAKzfA From: "Adrangi, Farid" To: "Barney Wolff" Cc: Hi Barney, Thanks for the dialogue. Please see my responses inline. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Barney Wolff > Sent: Wednesday, December 15, 2004 3:57 PM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > Subject: Re: CUI - issues addressed in version 3 >=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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 23:56:56 +0000 Date: Wed, 15 Dec 2004 18:56:38 -0500 From: Barney Wolff To: "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: Re: CUI - issues addressed in version 3 Message-ID: <20041215235638.GA51337@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 23:18:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: CUI - issues addressed in version 3 Date: Wed, 15 Dec 2004 15:18:02 -0800 Message-ID: Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcTifnVT3/yBEplSTz2gpRwbiI1C+wAe/wrw From: "Adrangi, Farid" To: "Barney Wolff" Cc: Hi Barney, Thanks so much for quick attention on this. Please see responses/suggestions inline. BR, Farid > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Wednesday, December 15, 2004 12:17 AM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 21:21:18 +0000 Message-ID: From: Avi Lior To: "'Congdon, Paul T (ProCurve)'" , Bernard Aboba Cc: radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes Date: Wed, 15 Dec 2004 16:21:06 -0500 MIME-Version: 1.0 Content-Type: text/plain I belive yes it would be an interoperability issue. > -----Original Message----- > From: Congdon, Paul T (ProCurve) [mailto:paul.congdon@hp.com] > Sent: Tuesday, December 14, 2004 6:20 PM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org > 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:aboba@internaut.com] > > Sent: Tuesday, December 14, 2004 3:16 PM > > To: Congdon, Paul T (ProCurve) > > Cc: radiusext@ops.ietf.org > > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 20:46:43 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , radiusext@ops.ietf.org Cc: "'Beck01, Wolfgang'" Subject: Table of attributes was issue 7: Date: Wed, 15 Dec 2004 15:46:38 -0500 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 20:41:07 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Wed, 15 Dec 2004 15:40:48 -0500 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 19:04:51 +0000 Date: Wed, 15 Dec 2004 14:03:42 -0500 From: Barney Wolff To: Lothar Reith Cc: "'Adrangi, Farid'" , "'radiusext@ops.ietf.org'" Subject: Re: CUI issue 22 (was AW: CUI - issues addressed in version 3 Message-ID: <20041215190342.GB28736@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 16:22:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 15 Dec 2004 11:21:14 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1900B@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTiMvLP8QLTcHpfTqeQl/F8d+XXUwAif2CQAAEp9IA= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 16:09:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 15 Dec 2004 11:08:35 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1900A@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTiMvLP8QLTcHpfTqeQl/F8d+XXUwAif2CQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 15:42:55 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 15 Dec 2004 10:41:28 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19009@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTiMvLP8QLTcHpfTqeQl/F8d+XXUwAiUGwQ From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 13:53:00 +0000 Date: Wed, 15 Dec 2004 05:52:28 -0800 (PST) From: Bernard Aboba To: Barney Wolff cc: "Adrangi, Farid" , radiusext@ops.ietf.org Subject: Re: CUI - issues addressed in version 3 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 11:14:22 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201B68A7C@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Barney Wolff'" , "'Adrangi, Farid'" Cc: "'radiusext@ops.ietf.org'" Subject: CUI issue 22 (was AW: CUI - issues addressed in version 3 Date: Wed, 15 Dec 2004 12:13:45 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E297.24716CAE" 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 CUI issue 22 (was AW: CUI - issues addressed in version = 3

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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 15 Dec 2004 08:17:46 +0000 Date: Wed, 15 Dec 2004 03:16:58 -0500 From: Barney Wolff To: "Adrangi, Farid" Cc: radiusext@ops.ietf.org Subject: Re: CUI - issues addressed in version 3 Message-ID: <20041215081657.GA95772@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:58:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 14 Dec 2004 15:57:00 -0800 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTiA9TxZGlnFRXXT7upcjkoGYLMVQADeIrQAAf8IsA= From: "Adrangi, Farid" To: Cc: "Lothar Reith" , "Nelson, David" , "Barney Wolff" , "Congdon, Paul T \(ProCurve\)" 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Congdon,=20 > Paul T (ProCurve) > Sent: Tuesday, December 14, 2004 11:24 AM > To: Barney Wolff > Cc: Lothar Reith; Nelson, David; radiusext@ops.ietf.org > 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:barney@databus.com]=20 > > Sent: Tuesday, December 14, 2004 9:37 AM > > To: Congdon, Paul T (ProCurve) > > Cc: Lothar Reith; Nelson, David; radiusext@ops.ietf.org > > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:26:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Radius Extensions for IEEE 802 design team phone call Date: Tue, 14 Dec 2004 15:25:39 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A83C@cacexc07.americas.cpqcorp.net> Thread-Topic: Radius Extensions for IEEE 802 design team phone call Thread-Index: AcTiM63VY4G2IvEqQDiwRIm2rDdJVw== From: "Congdon, Paul T (ProCurve)" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:20:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 37: Merging of Filter Attributes Date: Tue, 14 Dec 2004 15:19:36 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A83B@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue 37: Merging of Filter Attributes Thread-Index: AcTiMt53Gl3YePktRzC4Og+AQxSH6wAAG8yw From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" Cc: 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:aboba@internaut.com]=20 > Sent: Tuesday, December 14, 2004 3:16 PM > To: Congdon, Paul T (ProCurve) > Cc: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:15:52 +0000 Date: Tue, 14 Dec 2004 15:15:40 -0800 (PST) From: Bernard Aboba To: "Congdon, Paul T (ProCurve)" cc: radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:15:07 +0000 Message-ID: From: Avi Lior To: "Adrangi, Farid" , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Tue, 14 Dec 2004 18:14:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:10:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 38: Ordering of filter attributes Date: Tue, 14 Dec 2004 15:10:00 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A838@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue 38: Ordering of filter attributes Thread-Index: AcThh8OchsrfHYiXSGCTIbLsoqHbggAqatWw From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , This makes sense to me. I wonder if the relationship with Filter-ID should also be mentioned here.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, December 13, 2004 6:49 PM > To: radiusext@ops.ietf.org > Subject: Issue 38: Ordering of filter attributes >=20 > Issue 38: Ordering of Filter Attributes > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 23:09:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 37: Merging of Filter Attributes Date: Tue, 14 Dec 2004 15:08:18 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A837@cacexc07.americas.cpqcorp.net> Thread-Topic: Issue 37: Merging of Filter Attributes Thread-Index: AcThh1ojyncqXt7AQxOQXp9SpGdRiQAp/rHg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, December 13, 2004 6:46 PM > To: radiusext@ops.ietf.org > Subject: Issue 37: Merging of Filter Attributes >=20 > Issue 37: Merging of Filter Attributes > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' in=20 > a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 19:38:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: open issues of draft-ietf-radext-digest-auth-00 Date: Tue, 14 Dec 2004 14:37:26 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19003@MAANDMBX2.ets.enterasys.com> Thread-Topic: open issues of draft-ietf-radext-digest-auth-00 Thread-Index: AcTgaf/wHEfgCRHfR+CqdAgoSn9fXwBqVsHg From: "Nelson, David" To: "Wolfgang Beck" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 19:24:53 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 14 Dec 2004 11:23:50 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A82C@cacexc07.americas.cpqcorp.net> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTiA9TxZGlnFRXXT7upcjkoGYLMVQADeIrQ From: "Congdon, Paul T (ProCurve)" To: "Barney Wolff" Cc: "Lothar Reith" , "Nelson, David" , 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:barney@databus.com]=20 > Sent: Tuesday, December 14, 2004 9:37 AM > To: Congdon, Paul T (ProCurve) > Cc: Lothar Reith; Nelson, David; radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 18:10:08 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Issue 38: Ordering of filter attributes Date: Tue, 14 Dec 2004 13:21:38 -0500 Message-Id: <20041214182138.C867F16CC3@mail.nitros9.org> Bernard Aboba 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:48:51 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201B6881A@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: AW: backwards compatible introduction of NEW attribute such as CU I Date: Tue, 14 Dec 2004 18:46:54 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E204.E679DB4E" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Dienstag, 14. Dezember 2004 18:20 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4E204.E679DB4E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: backwards compatible introduction of NEW attribute such as = CUI

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.

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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Dienstag, 14. Dezember 2004 18:20
An: radiusext@ops.ietf.org
Betreff: RE: backwards compatible introduction of = NEW attribute such as CUI


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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E204.E679DB4E-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:39:29 +0000 Date: Tue, 14 Dec 2004 12:36:58 -0500 From: Barney Wolff To: "Congdon, Paul T (ProCurve)" Cc: Lothar Reith , "Nelson, David" , radiusext@ops.ietf.org Subject: Re: backwards compatible introduction of NEW attribute such as CUI Message-ID: <20041214173658.GA46297@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:37:36 +0000 Message-ID: <41BF23DB.C066D59C@alcatel.be> Date: Tue, 14 Dec 2004 18:33:15 +0100 From: Nagi Reddy Jonnala Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: "Congdon, Paul T (ProCurve)" CC: Lothar Reith , "Nelson, David" , radiusext@ops.ietf.org Subject: Re: backwards compatible introduction of NEW attribute such as CUI Content-Type: multipart/alternative; boundary="------------5431CB07AF38D1389375B1F0" --------------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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar > Reith > Sent: Tuesday, December 14, 2004 5:35 AM > To: 'Nelson, David'; 'radiusext@ops.ietf.org' > 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: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] > Gesendet: Freitag, 10. Dezember 2004 17:41 > An: radiusext@ops.ietf.org > 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 > radiusext-request@ops.ietf.org with the word 'unsubscribe' > in a single line as the message text body. > > archive: > --------------5431CB07AF38D1389375B1F0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith
Sent: Tuesday, December 14, 2004 5:35 AM
To: 'Nelson, David'; 'radiusext@ops.ietf.org'
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üngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]
Gesendet: Freitag, 10. Dezember 2004 17:41
An: radiusext@ops.ietf.org
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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.

archive: <http://psg.com/lists/radiusext/>

--------------5431CB07AF38D1389375B1F0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:21:46 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 14 Dec 2004 12:20:14 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19002@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTh4hX3U9g0NtMTTmulAxY3/Zow0wAG9OwAAACZzhA= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:13:19 +0000 Message-ID: <41BF1F1B.C7738BA5@alcatel.be> Date: Tue, 14 Dec 2004 18:12:59 +0100 From: Nagi Reddy Jonnala Reply-To: Nagi_Reddy.Jonnala@alcatel.be Organization: Alcatel Telecom MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issue 42: Are the AVPs really "M"andatory in IEEE 802 draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Issue 42: Description of issue: Are the AVPs really "M"andatory in IEEE 802 draft Submitter name: Nagi Reddy Jonnala Submitter email address: nagi_reddy.jonnala@alcatel.be 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 17:05:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E1FE.FAEFC3F6" Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 14 Dec 2004 09:04:32 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA554824E8A825@cacexc07.americas.cpqcorp.net> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTh4hX3U9g0NtMTTmulAxY3/Zow0wAG9OwA From: "Congdon, Paul T (ProCurve)" To: "Lothar Reith" , "Nelson, David" , 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: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith Sent: Tuesday, December 14, 2004 5:35 AM To: 'Nelson, David'; 'radiusext@ops.ietf.org' 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Freitag, 10. Dezember 2004 17:41=20 An: radiusext@ops.ietf.org=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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: =20 ------_=_NextPart_001_01C4E1FE.FAEFC3F6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: backwards compatible introduction of NEW = attribute such as CUI
 
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.  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.  Perhaps a new=20 attribute like 'NAS registration' would be required to be included, = followed by a list of 'advertised' capabilities that the AS would = 'remember' for=20 this NAS.
 
Paul 

From: owner-radiusext@ops.ietf.org = [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar=20 Reith
Sent: Tuesday, December 14, 2004 5:35 AM
To: = 'Nelson, David'; 'radiusext@ops.ietf.org'
Subject: AW: = backwards=20 compatible introduction of NEW attribute such as = CUI

Dave,

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.

I like to comment on your statement:

David Nelson wrote:
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."

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

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.

So far, this has nothing to do with capability=20 negotiation.

Capability negotiation type functionality would only = come into=20 play, when the NAS makes an additional implementation decision=20 complemented  by the network access operator making a = configuration=20 decision to apply a "advertise only on as needed basis" = policy.

When such "advertise only on as needed basis" policy = is in=20 place,  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 ?

Lothar



-----Urspr=FCngliche Nachricht-----
Von:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.i= etf.org]=20
Gesendet: Freitag, 10. Dezember 2004 = 17:41=20
An: radiusext@ops.ietf.org
Betreff:=20 RE: backwards compatible introduction of NEW attribute such as = CUI=20


Lothar Reith writes (still in HTML!)...

> to a) what would be "the appropriate helpdesk" = in a WLAN=20 roaming
> scenario ?

This is an important question for those in the = "roaming=20 consortium" business, as well as home ISPs, to answer.  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. =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 :-)  If WLAN roaming wants to be = successful,=20 IMHO, the industry needs to make it as transparent as cellular=20 roaming.

> Also, should the error message say: did not = support CUI=20 or perhaps
> supports CUI but did not = advertise=20 ?

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.

> A related question is if the server counts an=20 authentication request
> rejected due to = missing=20 knowledge about the NASes CUI support as an
>=20 unsuccessful login attempt with regards to security thresholds = ?

That is likely an implementation decision.  = Personally, I=20 would tend to count it as "failed to meet policy requirements" as = apposed to=20 "failed to authenticate".


--
to unsubscribe send a = message to=20 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as=20 the message text body.

archive: <http://psg.com/lists/radiusext/>=20

------_=_NextPart_001_01C4E1FE.FAEFC3F6-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 15:27:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 39: Backward Compatibility of Filter Attributes Date: Tue, 14 Dec 2004 10:27:21 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FFF@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 39: Backward Compatibility of Filter Attributes Thread-Index: AcThiAFVjylUz7M5TPKqOBylATb+FAAaI4yw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 15:20:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 14 Dec 2004 10:19:58 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FFE@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTh4eCLU5JSKYmUSxG7hW/Rd4hiGgADRBkw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 13:48:14 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201B68657@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" , "'radiusext@ops.ietf.org'" Subject: AW: Issue 6: Encryption Date: Tue, 14 Dec 2004 14:47:39 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E1E3.7A148A2E" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Dienstag, 14. Dezember 2004 05:19 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4E1E3.7A148A2E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Issue 6: Encryption

resend in text only format:

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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Dienstag, 14. Dezember 2004 05:19
An: radiusext@ops.ietf.org
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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1E3.7A148A2E-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 13:36:48 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201B6863B@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: AW: backwards compatible introduction of NEW attribute such as CU I Date: Tue, 14 Dec 2004 14:34:37 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E1E1.A7D50BE8" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Freitag, 10. Dezember 2004 17:41 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4E1E1.A7D50BE8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Freitag, 10. Dezember 2004 17:41
An: radiusext@ops.ietf.org
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=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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1E1.A7D50BE8-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 11:31:21 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201AF3A96@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Bernard Aboba'" , "'radiusext@ops.ietf.org'" Subject: AW: Issue 6: Encryption Date: Tue, 14 Dec 2004 12:29:20 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4E1D0.2752B85A" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Dienstag, 14. Dezember 2004 05:19 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4E1D0.2752B85A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: Issue 6: Encryption

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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Dienstag, 14. Dezember 2004 05:19
An: radiusext@ops.ietf.org
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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4E1D0.2752B85A-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 10:53:19 +0000 Message-ID: <1AB3D30B989BF141BBD5C70057B2EF7C092E5EB0@eestqnt105.es.eu.ericsson.se> From: "David Mariblanca (ML/EEM)" To: "'Adrangi, Farid'" , radiusext@ops.ietf.org Subject: RE: CUI - issues addressed in version 3 Date: Tue, 14 Dec 2004 11:52:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Hi Farid, thanks for keeping track of these issues so carefully. Mine is fully covered by version 03. David. -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org]On Behalf Of Adrangi, Farid Sent: lunes, 13 de diciembre de 2004 21:49 To: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 06:25:59 +0000 Message-ID: <41BE8748.9020104@piuha.net> Date: Tue, 14 Dec 2004 08:25:12 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: "James M. Polk" Cc: Tschofenig Hannes , radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] Radius-Geopriv: Civic vs. geospatial location information Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 >> Geopriv@ietf.org >> https://www1.ietf.org/mailman/listinfo/geopriv > > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > > _______________________________________________ > Geopriv mailing list > Geopriv@ietf.org > https://www1.ietf.org/mailman/listinfo/geopriv > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 04:19:16 +0000 Date: Mon, 13 Dec 2004 20:18:49 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Issue 6: Encryption Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 04:09:02 +0000 Date: Mon, 13 Dec 2004 20:08:34 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Issue 7: Message-Authenticator? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 02:53:59 +0000 Date: Mon, 13 Dec 2004 18:53:31 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 41: Pruning the Filter Attribute Thicket Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 41: Pruning the Filter Attribute Thicket Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 02:52:33 +0000 Date: Mon, 13 Dec 2004 18:51:35 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 40: Support for Layer 2 filtering Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 40: Support for Layer 2 Filtering Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 02:51:01 +0000 Date: Mon, 13 Dec 2004 18:50:49 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 39: Backward Compatibility of Filter Attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 39: Backward Compatibility of Filter Attributes Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 02:49:23 +0000 Date: Mon, 13 Dec 2004 18:49:03 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 38: Ordering of filter attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 38: Ordering of Filter Attributes Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 14 Dec 2004 02:47:18 +0000 Date: Mon, 13 Dec 2004 18:45:46 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 37: Merging of Filter Attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 37: Merging of Filter Attributes Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 20:49:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: CUI - issues addressed in version 3 Date: Mon, 13 Dec 2004 12:48:39 -0800 Message-ID: Thread-Topic: CUI - issues addressed in version 3 Thread-Index: AcThVR/rzZDpH00qTNO2L2zMlsMKVg== From: "Adrangi, Farid" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 20:35:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00 Date: Mon, 13 Dec 2004 12:32:50 -0800 Message-ID: Thread-Topic: Issue -- draft-ieft-radext-chargeable-user-id-00 Thread-Index: AcTe3iUeTl0A7ZbHSzCH7FvyTz6IDwAZc5UgAIOJj+A= From: "Adrangi, Farid" To: , , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of=20 > john.loughney@nokia.com > Sent: Friday, December 10, 2004 9:41 PM > To: dnelson@enterasys.com; radiusext@ops.ietf.org > 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: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Nelson, David > > Sent: 10 December, 2004 19:32 > > To: radiusext@ops.ietf.org > > 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: dnelson@enterasys.com > > 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 radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > >=20 >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 20:11:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Radius-Geopriv: Civic vs. geospatial location information Date: Mon, 13 Dec 2004 12:10:40 -0800 Message-ID: Thread-Topic: Radius-Geopriv: Civic vs. geospatial location information Thread-Index: AcTg81d844f3UKP/TMO6UQN98eyC4AAW4hLw From: "Adrangi, Farid" To: "Tschofenig Hannes" Cc: , 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: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Tschofenig Hannes > Sent: Monday, December 13, 2004 1:06 AM > To: radiusext@ops.ietf.org; geopriv@ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 16:01:27 +0000 Message-ID: <41BDBC95.8010000@piuha.net> Date: Mon, 13 Dec 2004 18:00:21 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Tschofenig Hannes Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Radius-Geopriv: User Identity Confidentiality Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 15:22:59 +0000 Message-ID: <41BDB3AE.6070001@piuha.net> Date: Mon, 13 Dec 2004 17:22:22 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Tschofenig Hannes Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: [Geopriv] Radius-Geopriv: Method field Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 15:19:44 +0000 Message-ID: <41BDB2D1.6010809@piuha.net> Date: Mon, 13 Dec 2004 17:18:41 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Tschofenig Hannes Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Radius-Geopriv: Location Types Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:44:03 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B030@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: Method field Date: Mon, 13 Dec 2004 10:06:14 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:21:14 +0000 Message-ID: <41BD5ECE.8030203@piuha.net> Date: Mon, 13 Dec 2004 11:20:14 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Tschofenig Hannes Cc: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Re: Radius-Geopriv: Time-to-Live field Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 ) 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:09:24 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B037@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: User Identity Confidentiality Date: Mon, 13 Dec 2004 10:06:15 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:08:35 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B02F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: Time-to-Live field Date: Mon, 13 Dec 2004 10:06:14 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 ) 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:08:09 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B02C@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: Civic vs. geospatial location information Date: Mon, 13 Dec 2004 10:06:13 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:07:53 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B02D@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: radius-geopriv wglc comments Date: Mon, 13 Dec 2004 10:06:13 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:07:37 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B02E@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: Location Types Date: Mon, 13 Dec 2004 10:06:13 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 13 Dec 2004 09:07:21 +0000 Message-ID: <2A8DB02E3018D411901B009027FD3A3F0550B036@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: radiusext@ops.ietf.org, geopriv@ietf.org Subject: Radius-Geopriv: Note Well Date: Mon, 13 Dec 2004 10:06:15 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 12 Dec 2004 16:44:01 +0000 To: radiusext@ops.ietf.org cc: aboba@internaut.com, jari.arkko@piuha.net Subject: open issues of draft-ietf-radext-digest-auth-00 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <9977.1102869757.1@big3> Date: Sun, 12 Dec 2004 17:42:37 +0100 From: wolfgang.beck01@t-online.de (Wolfgang Beck) Message-ID: <1CdWoS-0nRmGe0@fwd09.sul.t-online.com> 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 12 Dec 2004 04:01:27 +0000 Message-ID: <41BBC231.6030404@piuha.net> Date: Sun, 12 Dec 2004 05:59:45 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Issue 7: Message Authenticator Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 22:33:54 +0000 Date: Sat, 11 Dec 2004 14:33:21 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Issue 7: Message Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 08:23:55 +0000 Date: Sat, 11 Dec 2004 00:23:48 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for Review: RFC 3576 MIBs Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 (radext@ops.ietf.org) using the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 08:22:29 +0000 Date: Sat, 11 Dec 2004 00:22:23 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for Review: RADIUS Redirection Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 (radext@ops.ietf.org) using the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 08:21:36 +0000 Date: Sat, 11 Dec 2004 00:21:03 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Request for Review: RADIUS Extensions for IEEE 802 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 (radext@ops.ietf.org) using the format described on the RADEXT Issues list: http://www.drizzle.com/~aboba/RADEXT/ -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 05:41:33 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00 Date: Sat, 11 Dec 2004 07:41:03 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4323C8@esebe056.ntc.nokia.com> Thread-Topic: Issue -- draft-ieft-radext-chargeable-user-id-00 Thread-Index: AcTe3iUeTl0A7ZbHSzCH7FvyTz6IDwAZc5Ug From: To: , Hi David, This seems like a reasonable change. We can fix this in the next update. cheers, John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Nelson, David > Sent: 10 December, 2004 19:32 > To: radiusext@ops.ietf.org > 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: dnelson@enterasys.com > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 05:40:32 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue -- draft-ieft-radext-chargeable-user-id-00 Date: Sat, 11 Dec 2004 07:39:46 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D4323C7@esebe056.ntc.nokia.com> Thread-Topic: Issue -- draft-ieft-radext-chargeable-user-id-00 Thread-Index: AcTe3iUeTl0A7ZbHSzCH7FvyTz6IDwABF5oAABhRzWA= From: To: , Thanks David, we'll get these addressed in the next update. John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Nelson, David > Sent: 10 December, 2004 20:17 > To: radiusext@ops.ietf.org > Subject: Issue -- draft-ieft-radext-chargeable-user-id-00 >=20 >=20 > Description of issue: Editorial Nits > Submitter name: Dave Nelson > Submitter email address: dnelson@enterasys.com > Date first submitted: December 10, 2004 > Reference: (N/A) > Document: draft-ietf-radext-chargeable-user-id-00.txt > Comment type: E > Priority: 1 > Section: >=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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 11 Dec 2004 02:58:07 +0000 Date: Fri, 10 Dec 2004 18:57:30 -0800 (PST) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 21:16:25 +0000 Message-Id: <5.2.0.9.2.20041210130944.00b79a60@qcmail1.qualcomm.com> Date: Fri, 10 Dec 2004 13:15:50 -0800 To: "Beck01, Wolfgang" , radiusext@ops.ietf.org From: Jun Wang Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00 Cc: ac Mahendran , Avi Lior Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 radiusext-request@ops.ietf.org with >the word 'unsubscribe' in a single line as the message text body. >archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 18:17:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue -- draft-ieft-radext-chargeable-user-id-00 Date: Fri, 10 Dec 2004 13:16:30 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FF4@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue -- draft-ieft-radext-chargeable-user-id-00 Thread-Index: AcTe3iUeTl0A7ZbHSzCH7FvyTz6IDwABF5oA From: "Nelson, David" To: Description of issue: Editorial Nits Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com Date first submitted: December 10, 2004 Reference: (N/A) Document: draft-ietf-radext-chargeable-user-id-00.txt Comment type: E Priority: 1 Section: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 17:41:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Issue -- draft-ieft-radext-chargeable-user-id-00 Date: Fri, 10 Dec 2004 12:31:56 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FF3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue -- draft-ieft-radext-chargeable-user-id-00 Thread-Index: AcTe3iUeTl0A7ZbHSzCH7FvyTz6IDw== From: "Nelson, David" To: Description of issue: Use of Chargeable-User-ID attribute in Access-Request Messages Submitter name: Dave Nelson Submitter email address: dnelson@enterasys.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 16:42:20 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Fri, 10 Dec 2004 11:41:02 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FF2@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTe1RIjAEUWbZ9uQIGHQ0F8+sazDgAADScw From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 16:27:09 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201AF32D7@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: AW: backwards compatible introduction of NEW attribute such as CU I Date: Fri, 10 Dec 2004 17:26:32 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DED5.027DCA18" 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'; 'radiusext@ops.ietf.org' 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Mittwoch, 8. Dezember 2004 20:47 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4DED5.027DCA18 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AW: backwards compatible introduction of NEW attribute such as = CUI

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

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 ?

Lothar

-----Urspr=FCngliche Nachricht-----
Von: Reith, Lothar [HAHN:NGD:EXCH]
Gesendet: Mittwoch, 8. Dezember 2004 21:46
An: 'Nelson, David'; 'radiusext@ops.ietf.org'
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.


Lothar




-----Urspr=FCngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Mittwoch, 8. Dezember 2004 20:47
An: radiusext@ops.ietf.org
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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4DED5.027DCA18-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 15:39:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issues List Revision, draft-ietf-radext-digest-auth-00 Date: Fri, 10 Dec 2004 10:36:29 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FF1@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issues List Revision, draft-ietf-radext-digest-auth-00 Thread-Index: AcTer3W3VUQhOVxnRaiLBKT5sefHeAAHga4g From: "Nelson, David" To: "Beck01, Wolfgang" , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 11:57:16 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FDF7@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: Re: Issues List Revision, draft-ietf-radext-digest-auth-00 Date: Fri, 10 Dec 2004 12:56:14 +0100 MIME-Version: 1.0 Content-Type: text/plain 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 10 Dec 2004 01:01:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16824.62756.58185.218046@gargle.gargle.HOWL> Date: Thu, 9 Dec 2004 19:00:20 -0600 From: Pete McCann To: Bernard Aboba Cc: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Dec 2004 23:53:32 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org Subject: [draft-ietf-radext-digest-auth-00 - ISSUE 7] Message Authenticato r Date: Thu, 9 Dec 2004 18:52:34 -0500 MIME-Version: 1.0 Content-Type: text/plain 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:avi@bridgewatersystems.com www.bridgewatersystems.com -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Dec 2004 19:18:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Version 03 of CUI Date: Thu, 9 Dec 2004 11:17:58 -0800 Message-ID: Thread-Topic: Version 03 of CUI Thread-Index: AcTeHKgG4it4PJeqRPyJ+Fp6V79IMAABs+pA From: "Adrangi, Farid" To: 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: 'radiusext@ops.ietf.org' > 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Dec 2004 18:27:26 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Version 03 of CUI Date: Thu, 9 Dec 2004 10:26:53 -0800 Message-ID: Thread-Topic: Version 03 of CUI Thread-Index: AcTeHKgG4it4PJeqRPyJ+Fp6V79IMA== From: "Adrangi, Farid" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 09 Dec 2004 11:05:31 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Thu, 9 Dec 2004 13:03:42 +0200 Message-ID: <3CF661B1787ABF41A869BE20108F8D6D43238A@esebe056.ntc.nokia.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93wAAGk4AAAAVfuQAAtvFoQAAFUUKAAIFvgsA== From: To: , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 20:47:12 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201A8B5C3@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" Subject: AW: backwards compatible introduction of NEW attribute such as CU I Date: Wed, 8 Dec 2004 21:46:30 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD66.FECB1EC6" 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = Gesendet: Mittwoch, 8. Dezember 2004 20:47 An: radiusext@ops.ietf.org 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 radiusext-request@ops.ietf.org with = the word 'unsubscribe' in a single line as the message text body. archive: ------_=_NextPart_001_01C4DD66.FECB1EC6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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.


Lothar




-----Urspr=FCngliche Nachricht-----
Von: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.= ietf.org]
Gesendet: Mittwoch, 8. Dezember 2004 20:47
An: radiusext@ops.ietf.org
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 = radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single = line as the message text body.

archive: <http://psg.com/lists/radiusext/>

------_=_NextPart_001_01C4DD66.FECB1EC6-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 19:49:18 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 8 Dec 2004 14:47:29 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FE4@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93wAAGk4AAAAVfuQAAtvFoQAAFUUKA= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 19:13:07 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 8 Dec 2004 11:12:37 -0800 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93wAAGk4AAAAVfuQAAtvFoQ From: "Adrangi, Farid" To: "Nelson, David" Cc: , 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 18:35:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD54.7F65A6E3" Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 8 Dec 2004 10:34:05 -0800 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTdLn6lTcUfwNqcSEaGF2LwYJkT5wAIvtiQ From: "Adrangi, Farid" To: "Lothar Reith" Cc: 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 Message
Hi=20 Lothar,
Thanks.  Please see my comments = inline.
BR,
Farid

other comments:
- 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"

with:
"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"  

FA:  Agree.  Good = suggestion.

- another Question similar to David's question = raised=20 earlier:   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 ? 

FA:  Yes I have=20 already agreed with David's point. 

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. 

FA: one = possibility is to=20 use error-code attribute defined in draft-zorn-radius-err-msg-01.txt = -- what=20 do you think? 

Farid wrote as part of the snippet:
 if the NAS supports the CUI attribute the CUI attribute = will=20 override the identity portion the UserName (1) = attribute.   

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 ?  

FA:=20 No.  it means that the UserName(1) attribute will be used for = routing and=20 the CUI attribute will be used for identity purposes. 

 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. 

Farid wrote:
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.

Lothar:
- I agree, that = the text=20 adresses the backward compatibility problem.

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

FA: BTW, the text (the snippet that I sent = you) does not=20 say "always advertise".  The NAS MAY advertise=20 ....

 

 

Lothar

------_=_NextPart_001_01C4DD54.7F65A6E3-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 15:34:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Wed, 8 Dec 2004 10:32:50 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FE2@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTdLt9mGhr7yNBOQEewFeeZ+SeDygACONug From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 14:02:57 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201A8B3C4@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Adrangi, Farid'" Cc: "'radiusext@ops.ietf.org'" Subject: RE: backwards compatible introduction of NEW attribute such as CU I Date: Wed, 8 Dec 2004 15:01:56 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DD2E.7A2C599C" 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 RE: backwards compatible introduction of NEW attribute such as = CUI

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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 08 Dec 2004 08:01:47 +0000 Date: Wed, 8 Dec 2004 00:01:02 -0800 (PST) From: Bernard Aboba To: iesg@ietf.org cc: ietf-secretary@ietf.org, radiusext@ops.ietf.org Subject: Request Advancement of draft-ietf-radext-rfc2486bis-03.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 21:19:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 7 Dec 2004 13:19:14 -0800 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93wAAGk4AAAAVfuQA== From: "Adrangi, Farid" To: "Nelson, David" Cc: Hi David, all Thanks. Please see my response inline. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, December 07, 2004 12:45 PM > To: radiusext@ops.ietf.org > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 20:46:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 7 Dec 2004 15:44:37 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FDE@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93wAAGk4AA= From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 20:37:11 +0000 Date: Tue, 7 Dec 2004 12:37:04 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Issues List Revision Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 20:35:52 +0000 Date: Tue, 7 Dec 2004 12:35:32 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issues List Revision Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 20:08:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC98.5EAC145F" 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 Message-ID: Thread-Topic: backwards compatible introduction of NEW attribute such as CUI (was: re: Minutes of the RADEXT WG Meeting at IETF-61 Thread-Index: AcTcVw2SMmCLvmcEScSJcGXfnY+sBQAPc93w From: "Adrangi, Farid" To: "Lothar Reith" , "Nelson, David" Cc: "David Kessens" , "Bert Wijnen" , "Bernard Aboba" , 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: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Lothar Reith Sent: Tuesday, December 07, 2004 4:19 AM To: 'Nelson, David'; 'radiusext@ops.ietf.org' 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 Message
Hi=20 Lothar, all
 
Couple=20 of quick points,  1) the new attribute is not mandatory.  2) = The=20 suggested CUI advertisement in Access-Request is = optional.
 
We are=20 currently working on -03 version of the CUI draft.  Here is a = snippet on=20 what we want to say about backward compatibility.
 
"
...=20 Servers which do not understand the CUI attribute SHOULD silently = discard the=20 attribute.
 
The=20 NAS MAY include the CUI attribute with a null character for = its data field=20 in the Access-Request message to indicate its support for this attribute = to the=20 home RADIUS server.  In cases where home RADIUS server cannot=20 determine the NAS support for the CUI, if the CUI is required for = proper=20 billing, the home RADIUS server MUST reject the request by sending = an=20 Access-Reject message including an Error-Cause attribute [RFC3576] = with=20 value 402 (decimal), "Missing Attribute".
Otherwise, the home RADIUS = server=20 MUST send both the UserName (1) attribute and the CUI attribute, = with the=20 understanding that if the NAS supports the CUI attribute the CUI = attribute will=20 override the identity portion the UserName (1) attribute.  = That is,=20 the UserName(1) attribute will be used for routing and the CUI = attribute=20 will be used for identity purposes.
 
"
Before=20 we get into developing a protocol (as suggested below) to = determine=20 the CUI support, I would like to know why the above paragraph does not = address=20 the backward compatibility problem.  
 
BR,
Farid
 
 
 
-----Original Message-----
From:=20 owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] = On=20 Behalf Of Lothar Reith
Sent: Tuesday, December 07, 2004 = 4:19=20 AM
To: 'Nelson, David'; = 'radiusext@ops.ietf.org'
Cc:=20 'David Kessens'; 'Bert Wijnen'; 'Bernard Aboba'
Subject: = backwards=20 compatible introduction of NEW attribute such as CUI (was: re: Minutes = of the=20 RADEXT WG Meeting at IETF-61

David,

in your minutes you wrote (excerpt): =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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 =
(draft-adrangi-radius-chargeable-user-identity-02.txt) =
------------------------------------------------------ =

Farid went through current issues.  Issues 13, = 14 and 15=20 are addressed in the most recent draft.  There are two open = issues: (a)=20 backward

compatibility and (b) the lack of general capability = negotiation mechanism in RADIUS.  We could send a "hint" = attribute in the=20 Access- Request message as indication of CUI feature = support.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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=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.

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.

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:

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.

An example of "NEW" is "CUI". A good example of = issue c) is=20 the CUI backwards compatibility issue described above in issue = a).  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.

My proposal to overcome issue c) is as follows = (revised from=20 an earlier proposal I made in the context of CUI):

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

Implicit challenge:
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.

I believe this behaviour should be in line with = Bernard's=20 below earlier comment.

Bernard wrote in response to one of my earlier = proposals which=20 suggested re-interpreting an Access-Reject as an = Access-Accept:

"Changing the semantics of the Access-Reject is = somewhat=20 tricky since the goal of that message is to deny service.  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:  EAP-Message, = Reply-Message,=20 etc." and "Interpreting an Access-Reject as an Access-Accept is = explicitly=20 forbidden by RFC 2865.  We don't want to go down that = road."

Alternatively perhaps an explicit challenge may be = used as=20 follows:
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.

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

As always, comments welcome...

Lothar

------_=_NextPart_001_01C4DC98.5EAC145F-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 15:14:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: backwards compatible introduction of NEW attribute such as CUI Date: Tue, 7 Dec 2004 10:11:56 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FD4@MAANDMBX2.ets.enterasys.com> Thread-Topic: backwards compatible introduction of NEW attribute such as CUI Thread-Index: AcTcVwCmNTgEqyhVTk6AxPDe80kpaQAFXbMA From: "Nelson, David" To: 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 12:19:46 +0000 Message-ID: <7D410981F5D6214FA120DD2CF6E7546201A8AD6A@zfrac103-int2.europe.nortel.com> From: "Lothar Reith" To: "'Nelson, David'" , "'radiusext@ops.ietf.org'" 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 Date: Tue, 7 Dec 2004 13:19:11 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4DC56.F54A7AF6" 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 backwards compatible introduction of NEW attribute such as CUI = (was: re: Minutes of the RADEXT WG Meeting at IETF-61

David,

in your minutes you wrote (excerpt):
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

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-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 07 Dec 2004 11:17:10 +0000 Message-ID: <41B5908C.5020301@piuha.net> Date: Tue, 07 Dec 2004 13:14:20 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: gwz@cisco.com Cc: 'Bernard Aboba' , radiusext@ops.ietf.org Subject: Re: REMINDER: RADEXT WG last call on RFC 2486bis-02 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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: gwz@cisco.com > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Dec 2004 18:29:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Minutes of the RADEXT WG Meeting at IETF-61 Date: Mon, 6 Dec 2004 13:27:37 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E18FD0@MAANDMBX2.ets.enterasys.com> Thread-Topic: Minutes of the RADEXT WG Meeting at IETF-61 Thread-Index: AcTbwUQrvi5596QDT7mALuWCHW7N3w== From: "Nelson, David" To: Cc: "David Kessens" , "Bert Wijnen" , "Bernard Aboba" 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 06 Dec 2004 16:57:51 +0000 Date: Mon, 6 Dec 2004 08:57:10 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Slides from IETF 61 RADEXT WG meeting Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII are available here: http://www.drizzle.com/~aboba/IETF61/IETF61-RADEXT.zip -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Dec 2004 06:44:28 +0000 Message-Id: <200412010644.iB16i0Yr006268@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" , Subject: RE: REMINDER: RADEXT WG last call on RFC 2486bis-02 Date: Tue, 30 Nov 2004 22:44:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcTXEHQR6Fd4e+AxQEK+p4jwWveTDgAX21NA Description of issue: Grammar problem Submitter name: Glen Zorn Submitter email address: gwz@cisco.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 01 Dec 2004 04:46:32 +0000 Message-Id: <200412010445.iB14jwA5000410@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" Cc: Subject: RE: REMINDER: RADEXT WG last call on RFC 2486bis-02 Date: Tue, 30 Nov 2004 20:45:57 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcTXEHQR6Fd4e+AxQEK+p4jwWveTDgATrGtA Description of issue: Misspelled word Submitter name: Glen Zorn Submitter email address: gwz@cisco.com 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 radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: