Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 27 Apr 2005 21:47:05 +0000 Message-Id: <200504272146.j3RLkipR011477@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Blumenthal, Uri'" , "'Bernard Aboba'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Wed, 27 Apr 2005 14:46:38 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcVK7ACUotYD3bjETgycjROMFLjGYQAVrEWgAAsaRnA= Blumenthal, Uri supposedly scribbled: >>> "EAP server" is what "eap peer" and "aaa" share. >> >> An EAP server can exist on the authenticator when there is no AAA >> server present. It is a distinct entity from the EAP peer. It is >> not "shared" between the EAP peer and AAA server. > > In theory EAP server is a distinct entity and can be anywhere, in > practice it's a part of AAA most of the time. Why are we arguing > about this? I thought we were talking about architecture; and further, discussing components which might or might not be utilized in that architecture. Maybe it's just me, but I think that it's a good idea to understand how those components actually work (as opposed to how we might wish or imagine they work, or the direction in which marketeers might be pushing them). If a building architect thought that a brick was part of a girder, he would design a pretty strange building and misconceptions in networking can easily lead to similar results. For example, there was a recent thread on a different list in which someone was worried about security problems if a 4th party (!) was introduced into an EAP conversation. There are not 3 or 4 or 17 parties in an EAP exchange, there are exactly 2; there are also (logically) 2 parties in a RADIUS exchange, and those sets are disjoint. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 27 Apr 2005 21:26:31 +0000 Message-Id: <200504272126.j3RLPxb4023713@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" Cc: "'Blumenthal, Uri'" , , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Wed, 27 Apr 2005 14:25:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcVK7az+B8gHtO7zTr+ZdPa5n+Z1wAAAjLUQ Bernard Aboba supposedly scribbled: >> "EAP server" is what "eap peer" and "aaa" share. > > An EAP server can exist on the authenticator when there is no AAA > server present. I'd actually go a bit further and claim that the distinction between the authenticator and the EAP "server" is one of convenience & that they are logically the same entity. > It is a distinct entity from the EAP peer. It is > not "shared" between the EAP peer and AAA server. > >> Oh and we _are_ talking EAPv2, right? > > The only version of EAP that I'm familiar with is defined in RFC 3748. > > Maybe this entire discussion has been about some *other* version of > EAP? Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 27 Apr 2005 18:32: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: L2 NAS-Filter-Rule syntax choices Date: Wed, 27 Apr 2005 11:31:32 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482401DD6EBE@cacexc07.americas.cpqcorp.net> Thread-Topic: L2 NAS-Filter-Rule syntax choices Thread-Index: AcVLN/Z+JHWi0LafQzqnQF9ztClNCwAHmtYQ From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" Cc: There are two strategies for this: 1. We anticipate working with whatever general capabilities advertisement mechanism is defined for Radius. I think this particular application points out the need for some level of granularity around what is advertised. 2. We are also specifying that for NAS devices that understand the attribute, but are not capable of supporting it are, by default, to treat the Access-Accept as an Access-Reject. We are also recommending that this default action and behavior be something NAS devices can configure differently if so desired. It is fairly common these days to have some simple levels of L2 filtering as well as L3 filtering in switches and access points. Paul=20 > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Wednesday, April 27, 2005 7:47 AM > To: Congdon, Paul T (ProCurve) > Cc: radiusext@ops.ietf.org > Subject: Re: L2 NAS-Filter-Rule syntax choices >=20 > > The belief is the current proposal covers all bases and is still=20 > > usable, but perhaps specifies more than many NAS devices could=20 > > actually implement or are interested in supporting. >=20 > Question: how do you know whether a particular NAS device=20 > supports all of the syntax covered in the NAS-Filter-Rule? =20 > For example, a layer 2 switch might only support layer 2=20 > filters, or a NAS might only support layer 3 filters. A=20 > unified syntax makes sense, but allowing layer 2 and layer 3=20 > filters to be included in one attribute implies that devices=20 > have to implement both layer 2 and layer 3 filters. If a=20 > device only supports part of the syntax, there is no easy way=20 > for it to advertise that. >=20 > Or is support for both layer 2 and layer 3 filtering common=20 > enough at this point that we don't need to worry about this? >=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, 27 Apr 2005 14:46:48 +0000 Date: Wed, 27 Apr 2005 07:46:39 -0700 (PDT) From: Bernard Aboba To: "Congdon, Paul T (ProCurve)" cc: radiusext@ops.ietf.org Subject: Re: L2 NAS-Filter-Rule syntax choices Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The belief is the current proposal covers all bases and is still usable, > but perhaps specifies more than many NAS devices could actually > implement or are interested in supporting. Question: how do you know whether a particular NAS device supports all of the syntax covered in the NAS-Filter-Rule? For example, a layer 2 switch might only support layer 2 filters, or a NAS might only support layer 3 filters. A unified syntax makes sense, but allowing layer 2 and layer 3 filters to be included in one attribute implies that devices have to implement both layer 2 and layer 3 filters. If a device only supports part of the syntax, there is no easy way for it to advertise that. Or is support for both layer 2 and layer 3 filtering common enough at this point that we don't need to worry about this? -- to 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, 27 Apr 2005 14:41:54 +0000 Date: Wed, 27 Apr 2005 07:41:37 -0700 (PDT) From: Bernard Aboba To: Pasi.Eronen@nokia.com cc: farid.adrangi@intel.com, radiusext@ops.ietf.org Subject: RE: [Issue 297] Review of Identity Selection -12 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Since draft-adrangi-eap-network-discovery-12 does not even have > a reference to RFC 2607, I don't think any "Updates" header > is needed... RFC 2607 specifies RADIUS proxy behavior in roaming. This document specifies the behavior of RADIUS proxies that handle EAP messages. Moreoever, the document implicitly assumes a model by which requests are routed (source routing). These additions affect the behavior of RADIUS proxies. Between this document and RFC 2486bis, many proxies will need to be modified. I'm suggesting that we explicitly acknowledge the changes by including an Updates: header. Another alternative would be to remove the material relating to proxy behavior, and put it in a separate document within RADEXT WG. That document could expand on the required changes in more depth (such as the expected handling of source routed 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, 27 Apr 2005 14:25: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: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Wed, 27 Apr 2005 10:23:16 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032300@MAANDMBX2.ets.enterasys.com> Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAANgA/AAB4/mtA= From: "Nelson, David" To: Cc: , , Glen Zorn writes... > I may not trust the government of the United States, but it has > authorized me (through the issuance of a passport) to leave the > country and return. I'm not sure this is an apt example of your point. I rather suspect that your distrust of the Federal government extends to areas other than whether or not the agency that issued you a passport has the authority to do so. :-) In terms of the trust needed for enforcement of authorization, in your example it is the trust relationship that various customs agents have with the US government (among others) that allows them to validate your passport and grant you passage. In general, I think that concept of authorization without any form of trust relationship is pretty useless. -- to 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, 27 Apr 2005 05:44:12 +0000 Date: Tue, 26 Apr 2005 22:43:05 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Blumenthal, Uri'" , radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > "EAP server" is what "eap peer" and "aaa" share. An EAP server can exist on the authenticator when there is no AAA server present. It is a distinct entity from the EAP peer. It is not "shared" between the EAP peer and AAA server. > Oh and we _are_ talking EAPv2, right? The only version of EAP that I'm familiar with is defined in RFC 3748. Maybe this entire discussion has been about some *other* version of EAP? -- to 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, 27 Apr 2005 03:43:50 +0000 Message-Id: <200504270343.j3R3h0b4009558@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Blumenthal, Uri'" , "'Bernard Aboba'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 26 Apr 2005 20:42:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAANgA/A Blumenthal, Uri supposedly scribbled: >>> It was my understanding that while EAP is between the client >>> (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP >>> method* that runs on top of EAP is between the client and RADIUS >>> server. >> >> No. Can we just _get it_ once and for all? AAA & EAP are _different_ >> and _separate_ things: there is no part of EAP that is "between" the >> EAP peer and any AAA entity. > > What about EAP methods that run between the EAP client and EAP server? > Are you saying that EAP _method_ does not terminate in an EAP server, > or that EAP server is not usually [within and part of] a AAA server? No, but this is an implementation detail: it is by no means necessary to have _any_ AAA infrastructure to deploy EAP. AAA makes it more convenient, scale better, etc., but it's not necessary, nor is EAP "part of" AAA. > "EAP server" is what "eap peer" and "aaa" share. > Oh and we _are_ talking EAPv2, right? I don't know what that is. > > >>> This tunnel created by EAP method can be considered as "trust >>> between the client and AAA", >> >> See above. > > See above. I consider EAP server running inside AAA server. If others > (besides Glen and Bernard) on this list disagree with this perception > - I invite them to speak up please. > > >>> and RADIUS between NAS and AAA (however it is >>> accomplished) is "trust between NAS and AAA". >>> >>> And yes, many find convenient to connect authorization decision to >>> some extra information about the supplicant - such as its posture >>> evaluation (Cisco NAC, Microsoft NAP, etc). Such information would >>> naturally be carried in TLVs as part of EAP inner method exchange. >> >> Or more rationally (gasp!) in a subsequent _authorization_ protocol >> exchange. > > Kindly explain how "authorization" doesn't include trust of the > authorizing entity. I may not trust the government of the United States, but it has authorized me (through the issuance of a passport) to leave the country and return. > Also, it may be news for you - but [at least > some] people want authentication combined with authorization: i.e. if > I get a set of keys, it means that (a) the AAA authenticated me OK, > _and_ (b) that the server implicitly authorized me to communicate > with the given NAS. It's not news to me at all -- it's the same old RADIUS story. > > That authorization is dependent on host posture evaluation. I thought > it was Cisco that proposed it in their NAC architecture? Perhaps you > can/should shed some light on this? I thought this was a standards discussion; if you want to talk about NAC (or any other proprietary Cisco stuff), I suggest that you talk to your account manager -- I'm sure that he or she would love to extol its wonders. > > >>> Yes it seems to go way beyond the original purpose of EAP, but then >>> it does seem to address the today's need. >> >> If one has a sore toe, shooting oneself in the foot may seem to >> satisfy "today's need"; in the long run, however, it will probably >> turn out to be counterproductive. > > I'm simply describing what I perceive as today's reality. You may > intensely dislike it - it's your free choice. Looks like the market > is moving the above-described way. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 26 Apr 2005 23:43:13 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: L2 NAS-Filter-Rule syntax choices Date: Tue, 26 Apr 2005 16:42:48 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482401DD6EB6@cacexc07.americas.cpqcorp.net> Thread-Topic: L2 NAS-Filter-Rule syntax choices Thread-Index: AcVKuV6eGfR0jn95QYyQF3+y0d0z9Q== From: "Congdon, Paul T (ProCurve)" To: We are working on -04 of the 802 extensions draft and have added in a syntax for L2 filters for the NAS-Filter-Rule attribute. I'd like some feedback from the group on if we are going in the right direction before posting -04 for review. The current proposal is trying to balance usability with extensibility. It provides two ways to express a L2 frame; one for Ethernet encapsulation and another for everything else. We expect that the vast majority of the time (maybe 99%) a L2 frame will be encapsulated with Ethernet type encapsulation. The Ethernet encapsulation syntax in the attribute specifies the Ethertype and addresses as seen in the following example: deny in l2:ether2:0x806 from 00-10-A4-23-19-C0 to any This would block all ARP packets from a particular host. The key words are l2:ether2[:value]. A second, more extensible, yet harder to use, syntax is also defined to cover all other cases. It uses the OID format defined in RFC2895 for protocol definitions. For example: deny in l2:0.0.0.2.0.0.0.240 This would block all NetBIOS over LLC traffic. We should be able to define all L2 protocols using this format. The belief is the current proposal covers all bases and is still usable, but perhaps specifies more than many NAS devices could actually implement or are interested in supporting. Alternatives to the current scheme include: 1. defining additional key words like 'ether2' for other encapsulations like SNAP, LLC, IPX-Raw, etc.. 2. Drop the rmon_str syntax and just support ether2 3. only use the rmon_str syntax 4. others? Let me know what you think 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, 26 Apr 2005 22:33:54 +0000 Date: Tue, 26 Apr 2005 15:33:23 -0700 (PDT) From: Bernard Aboba To: David B Harrington cc: "'Blumenthal, Uri'" , gwz@cisco.com, radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Why are we spending so much time discussing EAP, if the AD has told > the WG that EAP should not be used, and that the IESG is unlikely to > approve a solution using EAP? > > dbh Perhaps because the ISMS WG charter talks about RADIUS support? Just a thought :) -- to 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, 26 Apr 2005 22:26:52 +0000 Date: Tue, 26 Apr 2005 15:26:39 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Avi Lior'" , john.loughney@nokia.com, farid.adrangi@intel.com, radiusext@ops.ietf.org, dnelson@enterasys.com Subject: RE: Issue 83: CUI and re-authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > This is just in case the NAS changed the value of CUI. It should > > never do this. But to be complete that clause says what will > happen. > > Maybe this stuff could actually be explained in the draft? That is the optimal way to get the point across, I think. -- to 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, 26 Apr 2005 22:26:25 +0000 Date: Tue, 26 Apr 2005 15:25:46 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Blumenthal, Uri'" , radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > If one has a sore toe, shooting oneself in the foot may seem to > satisfy "today's need"; in the long run, however, it will probably > turn out to be counterproductive. "Probably". I sense a window large enough for an elephant to walk through :) -- to 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, 26 Apr 2005 19:08: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: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 26 Apr 2005 15:07:14 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322FB@MAANDMBX2.ets.enterasys.com> Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAACLjdQAAFWx2A= From: "Nelson, David" To: , "Blumenthal, Uri" , , "Bernard Aboba" Cc: , , Dave Harrington writes... > Why are we spending so much time discussing EAP, if the AD has told > the WG that EAP should not be used, and that the IESG is unlikely to > approve a solution using EAP? I don't know. But I'll offer the somewhat pedantic clarification that the AD told ISMS that EAP was out of scope because of the EAP applicability statement. There exists the finite possibility that the EAP WG will decide to modify its applicability statement. -- to 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, 26 Apr 2005 19:05: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: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 26 Apr 2005 15:03:33 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322FA@MAANDMBX2.ets.enterasys.com> Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZAABd9VwAADRxYA From: "Nelson, David" To: "Blumenthal, Uri" , , "Bernard Aboba" Cc: , , Uri Blumenthal writes... > I consider EAP server running inside AAA server. If others > (besides Glen and Bernard) on this list disagree with this perception - > I invite them to speak up please. I agree that is most often the case, in practice. The EAP server is packaged as part of the RADIUS or Diameter server software distribution. >From a protocol definition perspective, however, the EAP server and AAA server are distinct entities. Any interaction (API) between these entities is outside the scope of the EAP, RADIUS or Diameter RFCs. Any security analysis of those protocols cannot take into account the AAA server to EAP server API, as it is implementation specific. -- to 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, 26 Apr 2005 16:13:42 +0000 Message-Id: <200504261604.j3QG4D54002538@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Avi Lior'" , , , Cc: , Subject: RE: Issue 83: CUI and re-authentication Date: Tue, 26 Apr 2005 09:04:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcVKdJljFj29Q202Q8acSo4/QX6oKAABNFoQ Avi Lior <> supposedly scribbled: > Hi John, > >> 1) the CUI may change during reauthentication, but the home server >> doesn't need to check if it has changed. > > The home network is the only entity that can change the value of the > CUI. > Note that the value of the CUI is opaque to the NAS. > > During reauthentication it may want to change the value of CUI. This > could happen because local policy states that change CUI on the 1st > of every month. So if the session spans midnight it may change the > CUI. > > >> 2) if the home server does check and notice that it has changed, >> then it should send an Access-Reject. > > This is just in case the NAS changed the value of CUI. It should > never do this. But to be complete that clause says what will happen. Maybe this stuff could actually be explained in the draft? > > >> -----Original Message----- >> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] >> Sent: Tuesday, April 26, 2005 2:54 AM >> To: farid.adrangi@intel.com; aboba@internaut.com >> Cc: radiusext@ops.ietf.org; dnelson@enterasys.com >> Subject: RE: Issue 83: CUI and re-authentication >> >> >> Farid, >> >> I edited your text somewhat: >> >> When reauthenticating, a NAS that supports CUI MUST include the CUI >> attribute with the value of CUI received in a previous Access-Accept. >> >> Upon receiving a non-nul CUI in an Access-Request the home RADIUS >> server MAY verify that the value of CUI matches the the CUI from the >> previous Access-Accept If the verification fails, then the RADIUS >> server SHOULD respond with an Access-Reject message. >> >> During reauthentication, upon receiving an Access-Accept, the value >> of the CUI maybe different from the previously received CUI for that >> session. The NAS MUST use this value on all subsequent accounting >> messages for that session. >> >> But I am confused by this; you are stating that >> >> 1) the CUI may change during reauthentication, but the home server >> doesn't need to check if it has changed. >> 2) if the home server does check and notice that it has changed, >> then it should send an Access-Reject. >> >> What is the purpose of this, if checking is optional? A MAY followed >> by a SHOULD is not really create deterministic behavior. Can you >> explain in a bit more detail what kind of behavior you are trying to >> get? >> >> John >> >> >>> -----Original Message----- >>> From: owner-radiusext@ops.ietf.org >>> [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Adrangi, >>> Farid Sent: 26 April, 2005 07:12 To: Bernard Aboba >>> Cc: radiusext@ops.ietf.org; Nelson, David >>> Subject: RE: Issue 83: CUI and re-authentication >>> >>> >>> No. The "Validation" means that the RADIUS server checks to see if >>> the CUI value is the same as the one that was sent in the previous >>> Access-Accept. However, the RADIUS server does not require >>> to do this >>> validation. >>> Thanks, >>> Farid >>> >>>> -----Original Message----- >>>> From: Bernard Aboba [mailto:aboba@internaut.com] >>>> Sent: Monday, April 25, 2005 6:50 PM >>>> To: Adrangi, Farid >>>> Cc: radiusext@ops.ietf.org; Nelson, David >>>> Subject: RE: Issue 83: CUI and re-authentication >>>> >>>> >>>> Presumably, by "validated" you mean that the CUI presented is >>>> associated with the subsequently authenticated identity. >>>> >>>> On Mon, 25 Apr 2005, Adrangi, Farid wrote: >>>> >>>>> Good point Bernard! Avi and I just discussed this, and our >>>>> current thinking is to add something like below to the draft: >>>>> >>>>> " >>>>> When re-authenticating, a NAS that supports CUI MUST include the >>>>> CUI attribute with the value of CUI received in a previous >>>>> Access-Accept. >>>>> >>>>> Upon receiving a non-nul CUI in an Access-Request the home RADIUS >>>>> server MAY validate the value of CUI and if the validation fails, >>>>> then the RADIUS server SHOULD respond with an Access-Reject >>>>> message. >>>>> >>>>> During reauthentication, upon receiving an Access-Accept, the >>>>> value of the CUI maybe different from the previously received CUI >>>>> for that session. The NAS MUST use this value on all subsequent >>>>> accounting messages for that session. " >>>>> >>>>> Does this work for you, all? >>>>> >>>>> Thanks, >>>>> Farid >>>>> >>>>>> -----Original Message----- >>>>>> From: owner-radiusext@ops.ietf.org >>>>>> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba >>>>>> Sent: Friday, April 22, 2005 7:33 PM >>>>>> To: radiusext@ops.ietf.org >>>>>> Subject: Issue 83: CUI and re-authentication >>>>>> >>>>>> >>>>>> Issue 83: CUI and re-authentication Submitter name: Bernard >>>>>> Aboba Submitter email address: aboba@internaut.com Date first >>>>>> submitted: April 22, 2005 Reference: >>>>>> Document: CUI-04 >>>>>> Comment type: T >>>>>> Priority: S >>>>>> Section: Various >>>>>> Rationale/Explanation of issue: >>>>>> >>>>>> The document does not state how CUI is used with an >>>>>> Access-Request that occurs due to re-authentication. For >>>>>> example, in the original authentication, the CUI attribute was >>>>>> provided within the Access-Accept, and subsequently within >>>>>> Accounting-Request packets >>>> (interim). Let us >>>>>> assume that a Session-Timeout attribute was sent with >>>>>> Termination-Action=RADIUS. >>>>>> >>>>>> What happens at the expiration of the Session-Timeout value? >>>>>> Does the NAS send an Access-Request containing a CUI attribute >>>>>> to the >>>> RADIUS server >>>>>> with the currently used CUI, or does it send an empty CUI >>>>>> attribute? It seems more appropriate for it to send the >>>>>> currently used CUI, since that does not require the RADIUS >>>>>> server to keep state. I presume that the User-Name and EAP >>>>>> re-authentication elements are handled the same way (e.g. >>>>>> User-Name includes "@realm" privacy 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: >>> >> >> -- >> to unsubscribe send a message to >> radiusext-request@ops.ietf.org with the word 'unsubscribe' in a >> single line as the message text body. >> archive: Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 26 Apr 2005 15:27:57 +0000 Message-ID: From: Avi Lior To: "'john.loughney@nokia.com'" , farid.adrangi@intel.com, aboba@internaut.com Cc: radiusext@ops.ietf.org, dnelson@enterasys.com Subject: RE: Issue 83: CUI and re-authentication Date: Tue, 26 Apr 2005 11:26:45 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi John, > 1) the CUI may change during reauthentication, but the home > server doesn't need > to check if it has changed. The home network is the only entity that can change the value of the CUI. Note that the value of the CUI is opaque to the NAS. During reauthentication it may want to change the value of CUI. This could happen because local policy states that change CUI on the 1st of every month. So if the session spans midnight it may change the CUI. > 2) if the home server does check and notice that it has > changed, then it should > send an Access-Reject. This is just in case the NAS changed the value of CUI. It should never do this. But to be complete that clause says what will happen. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, April 26, 2005 2:54 AM > To: farid.adrangi@intel.com; aboba@internaut.com > Cc: radiusext@ops.ietf.org; dnelson@enterasys.com > Subject: RE: Issue 83: CUI and re-authentication > > > Farid, > > I edited your text somewhat: > > When reauthenticating, a NAS that supports CUI MUST include > the CUI attribute with the value of CUI received in a > previous Access-Accept. > > Upon receiving a non-nul CUI in an Access-Request the home > RADIUS server MAY verify that the value of CUI matches the > the CUI from the previous Access-Accept If the verification > fails, then the RADIUS server SHOULD > respond with an Access-Reject message. > > During reauthentication, upon receiving an Access-Accept, > the value of the CUI maybe different from the previously > received CUI for that session. The NAS MUST use this value > on all subsequent accounting messages for that session. > > But I am confused by this; you are stating that > > 1) the CUI may change during reauthentication, but the home > server doesn't need > to check if it has changed. > 2) if the home server does check and notice that it has > changed, then it should > send an Access-Reject. > > What is the purpose of this, if checking is optional? A MAY > followed by a SHOULD is not really create deterministic > behavior. Can you explain in a bit more detail what kind of > behavior you are trying to get? > > John > > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Adrangi, Farid > > Sent: 26 April, 2005 07:12 > > To: Bernard Aboba > > Cc: radiusext@ops.ietf.org; Nelson, David > > Subject: RE: Issue 83: CUI and re-authentication > > > > > > No. The "Validation" means that the RADIUS server checks to > see if the > > CUI value is the same as the one that was sent in the previous > > Access-Accept. However, the RADIUS server does not require > > to do this > > validation. > > Thanks, > > Farid > > > > > -----Original Message----- > > > From: Bernard Aboba [mailto:aboba@internaut.com] > > > Sent: Monday, April 25, 2005 6:50 PM > > > To: Adrangi, Farid > > > Cc: radiusext@ops.ietf.org; Nelson, David > > > Subject: RE: Issue 83: CUI and re-authentication > > > > > > > > > Presumably, by "validated" you mean that the CUI presented is > > > associated > > > with the subsequently authenticated identity. > > > > > > On Mon, 25 Apr 2005, Adrangi, Farid wrote: > > > > > > > Good point Bernard! Avi and I just discussed this, and > > our current > > > > thinking is to add something like below to the draft: > > > > > > > > " > > > > When re-authenticating, a NAS that supports CUI MUST > > include the CUI > > > > attribute with the value of CUI received in a previous > > > Access-Accept. > > > > > > > > Upon receiving a non-nul CUI in an Access-Request the home > > > RADIUS server > > > > MAY validate the value of CUI and if the validation > > fails, then the > > > > RADIUS server SHOULD respond with an Access-Reject message. > > > > > > > > During reauthentication, upon receiving an Access-Accept, > > > the value of > > > > the CUI maybe different from the previously received > CUI for that > > > > session. The NAS MUST use this value on all subsequent > accounting > > > > messages for that session. " > > > > > > > > Does this work for you, all? > > > > > > > > Thanks, > > > > Farid > > > > > > > > > -----Original Message----- > > > > > From: owner-radiusext@ops.ietf.org > > > > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of > Bernard Aboba > > > > > Sent: Friday, April 22, 2005 7:33 PM > > > > > To: radiusext@ops.ietf.org > > > > > Subject: Issue 83: CUI and re-authentication > > > > > > > > > > > > > > > Issue 83: CUI and re-authentication > > > > > Submitter name: Bernard Aboba > > > > > Submitter email address: aboba@internaut.com > > > > > Date first submitted: April 22, 2005 > > > > > Reference: > > > > > Document: CUI-04 > > > > > Comment type: T > > > > > Priority: S > > > > > Section: Various > > > > > Rationale/Explanation of issue: > > > > > > > > > > The document does not state how CUI is used with an > > > > > Access-Request that occurs due to re-authentication. For > > > > > example, in the original authentication, the CUI > attribute was > > > > > provided within the Access-Accept, > > > > > and subsequently within Accounting-Request packets > > > (interim). Let us > > > > > assume that a Session-Timeout attribute was sent with > > > > > Termination-Action=RADIUS. > > > > > > > > > > What happens at the expiration of the Session-Timeout value? > > > > > Does the NAS send an Access-Request containing a CUI > attribute > > > > > to the > > > RADIUS server > > > > > with the currently used CUI, or does it send an empty CUI > > > > > attribute? It seems more appropriate for it to send the > > > > > currently used CUI, since that > > > > > does not require the RADIUS server to keep state. I presume > > > > > that the User-Name and EAP re-authentication elements are > > > > > handled the same > > > > > way (e.g. User-Name includes "@realm" privacy 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: > > > > -- > to 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, 26 Apr 2005 15:13:32 +0000 Message-Id: <200504261513.j3QFD354016485@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Blumenthal, Uri'" , "'Bernard Aboba'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 26 Apr 2005 08:12:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcVKA/EutFC4CQPDTBibwgAvJMlsPQAZMRpQAAEf3ZA= Blumenthal, Uri supposedly scribbled: > It was my understanding that while EAP is between the client > (supplicant) and NAS, and RADIUS is between NAS and AAA, *EAP method* > that runs on top of EAP is between the client and RADIUS server. No. Can we just _get it_ once and for all? AAA & EAP are _different_ and _separate_ things: there is no part of EAP that is "between" the EAP peer and any AAA entity. > > This tunnel created by EAP method can be considered as "trust between > the client and AAA", See above. > and RADIUS between NAS and AAA (however it is > accomplished) is "trust between NAS and AAA". > > And yes, many find convenient to connect authorization decision to > some extra information about the supplicant - such as its posture > evaluation (Cisco NAC, Microsoft NAP, etc). Such information would > naturally be carried in TLVs as part of EAP inner method exchange. Or more rationally (gasp!) in a subsequent _authorization_ protocol exchange. > Yes it seems to go way beyond the original purpose of EAP, but then > it does seem to address the today's need. If one has a sore toe, shooting oneself in the foot may seem to satisfy "today's need"; in the long run, however, it will probably turn out to be counterproductive. > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Bernard Aboba > Sent: Monday, April 25, 2005 10:02 PM > To: Glen Zorn (gwz) > Cc: radiusext@ops.ietf.org; eap@frascone.com; isms@ietf.org > Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party > > Martin Soukup said: > >> The use of RADIUS itself without a defined extension such as EAP-TLS >> or EAP-PEAP over RADIUS cannot securely pass attributes between >> entities. Note that the defined EAP-TLS (or other EAP mechanisms) >> over RADIUS provides for secure attribute passing between entities >> even through proxies. > > In response to which, Glen Zorn spake thusly: > >> I thought that I was passing familiar w/EAP-TLS (and even more so >> w/PEAP), but I am completely unaware of such capabilities. Would you >> mind explaining how this is achieved, given that RADIUS & EAP are >> completely different protocols? > > I also was unaware of the ability of EAP-TLS to transmit RADIUS > attributes between the EAP peer and server. I had always thought > RADIUS was a protocol only spoken between a NAS and a RADIUS server, > and that EAP-TLS didn't support transmission of TLVs. But I guess > this is a somewhat old fashioned point of view. > > Perhaps this is referring to EAP-TLS "extended" via the following? > http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application -ext > ension-01.txt > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 26 Apr 2005 14:43:18 +0000 Date: Tue, 26 Apr 2005 07:43:08 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: [eap] Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Tue, 26 Apr 2005 02:07:53 -0400 From: Yoshihiro Ohba To: Bernard Aboba Subject: Re: [eap] Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Hi Bernard, I have EAP peer implementation (Open Diameter libeap) and I can answer to the 1st question. On Mon, Apr 25, 2005 at 08:46:25AM -0700, Bernard Aboba wrote: > RFC 2486bis specifies how the NAI is internationalized. In the > development of this document, some questions have arisen about the > behavior of existing EAP peers and RADIUS proxies. In order to understand > how existing implementations function, we need implementers to volunteer > the answer to several questions: > > 1. How is internationalization supported on your EAP peer implementation? > > Does your EAP peer implementation support formating of the realm > portion in IDN, or does it enable entering of UTF-8, or perhaps just plain > ASCII? When an EAP Request/Identity is received, the peer silently discards the message if it contains a non-UTF-8 string. When an EAP Response/Identity is going to be sent, the peer checks the contents of the identity passed from an application (the application can use any UTF-8 string as identity) and silently discards the message instead of sending it, if it contains a non-UTF-8 string. The peer silently discards EAP Request/Identity if it contains a non-UTF-8 string. These may be too restrictive (as it accepts only UTF-8 string) and I may change my implementation to allow more flexibility. Hope this helps, Yoshihiro Ohba > > 2. How is internationalization supported on your RADIUS proxy > implementation?. > > How does your implementation support internationalization within the realm > table? Are realm table entries stored in IDN, UTF-8, or something else? > How are comparisons done between the realm in the NAI and the realm stored > in the realm table? > > Please respond by May 2, 2005. > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap -- to 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, 26 Apr 2005 14:25:46 +0000 Date: Tue, 26 Apr 2005 07:24:49 -0700 (PDT) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org, "Nelson, David" Subject: RE: Issue 83: CUI and re-authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII OK. You might clarify that in the document. On Mon, 25 Apr 2005, Adrangi, Farid wrote: > No. The "Validation" means that the RADIUS server checks to see if the > CUI value is the same as the one that was sent in the previous > Access-Accept. However, the RADIUS server does not require to do this > validation. > Thanks, > Farid > > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com] > > Sent: Monday, April 25, 2005 6:50 PM > > To: Adrangi, Farid > > Cc: radiusext@ops.ietf.org; Nelson, David > > Subject: RE: Issue 83: CUI and re-authentication > > > > > > Presumably, by "validated" you mean that the CUI presented is > > associated with the subsequently authenticated identity. -- to 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, 26 Apr 2005 06:58:40 +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: 2486bis internationalization and ! syntax Date: Tue, 26 Apr 2005 09:55:57 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D167F5D@esebe100.NOE.Nokia.com> Thread-Topic: Issue: 2486bis internationalization and ! syntax Thread-Index: AcVJRq/2uoBIaONSTFqboeRQytXq8wA5jg2Q From: To: , Hi Jari, I agree with Bernard that before deciding on a solution, we need to better understand what the current implementations are doing. I think that 1) might be preferable, if this is more in-line with what current proxies are doing. John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Jari Arkko > Sent: 25 April, 2005 06:26 > To: radiusext@ops.ietf.org > Subject: Issue: 2486bis internationalization and ! syntax >=20 >=20 > Issue 4 is about the interaction between internationzalition > an the ! transformation within NAIs. Basically you may change >=20 > user@homerealm.example.net >=20 > to >=20 > homerealm.example.net!user@otherrealm.example.net >=20 > and back, under certain exceptional AAA routing conditions, > i.e., when the local network can route/roam your request back > to the right place. >=20 > Now, what makes this interesting is that the usernamepart is > in UTF-8 and realmpart is an IDN in ASCII. Here there are > multiple resolutions of the issue. >=20 > #1: This transformation is an exceptional case where proxies > will perform some mapping from one character set to another. >=20 > Where such transformations are done, an attempt > to transform a string that can't be mapped to IDN (e.g. illegal > DNS name) should result in an error. From the user's point > of view this would be a similar error as you get when the domain > you are trying to give is unknown. Correct use of the this > transformation should not result in this error, given that the > string you put in from the '!' should have originally been a > realm name. >=20 > One drawback of this is that in order for the proxy to map UTF-8 > to ASCII, it needs to understand the codepoints. This means in > practise that a proxy with a today's codepoint data is unable to > do the transformation for something that uses a newer codepoint. > New codepoints are often defined but my understanding is that > they are for quite special and small languages. Given this and > the exceptional nature of the ! usage this may be acceptable. >=20 > #2: Realmpart needs to be converted to IDNA if and when a DNS > query needs to be sent. However, only Diameter defines how DNS > queries can be used to locate AAA servers; RADIUS implementations > do not support this. >=20 > It has been suggested that in order to "optimize for the=20 > common case" that > the entire string could be left in UTF-8, obviating the need for=20 > conversions > between UTF-8 and IDNA until a DNS query needed to be sent. Since > RADIUS implementations do not send such queries, they would=20 > not need to > do the conversion at all. Within a Diameter agent, the conversion > could be delayed until it is required, at which time it might > conceivably fail. >=20 > One problem with this is that existing nde that does the > query would be unable to do a UTF-8 query but would be > able to do an IDN query. Oh well, there isn't much Diameter > usage that would be hit with this... >=20 > And there seems to be another more serious problem. Namely, even > if RADIUS doesn't do DNS queries, it still stores and compares > strings. If someone has already put in a rule or entry for an > international DNS name, he has been able to do so already in > RFC 2486, because IDNs are really legal DNS names. And he > likely didn't use UTF-8, because that would have been illegal > as a NAI. Now, if we suddenly start sending the IDNs as UTF-8 > instead, this will break existing usage. All that is needed for > this scenario to apply is someone who (a) has an international > DNS name and (b) has a RADIUS server. What's the likelihood > of this? >=20 > My conclusion: problems in approach #2 seem more likely > to appear in common cases, so my preference is #1. What > do others think? >=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, 26 Apr 2005 06:58:06 +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 83: CUI and re-authentication Date: Tue, 26 Apr 2005 09:54:22 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D167F59@esebe100.NOE.Nokia.com> Thread-Topic: Issue 83: CUI and re-authentication Thread-Index: AcVKAjOZw4wGabvbRXGXlpQIAt7s1QAEgjCwAAX0AOA= From: To: , Cc: , Farid, I edited your text somewhat: When reauthenticating, a NAS that supports CUI MUST include the CUI attribute with the value of CUI received in a previous Access-Accept. Upon receiving a non-nul CUI in an Access-Request the home RADIUS = server MAY verify that the value of CUI matches the the CUI from the previous Access-Accept If the verification fails, then the RADIUS server SHOULD=20 respond with an Access-Reject message. During reauthentication, upon receiving an Access-Accept, the value of the CUI maybe different from the previously received CUI for that session. The NAS MUST use this value on all subsequent accounting messages for that session. But I am confused by this; you are stating that=20 1) the CUI may change during reauthentication, but the home server = doesn't need=20 to check if it has changed.=20 2) if the home server does check and notice that it has changed, then it = should send an Access-Reject.=20 What is the purpose of this, if checking is optional? A MAY followed by = a SHOULD is not really create deterministic behavior. Can you explain in a bit = more detail what kind of behavior you are trying to get? John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Adrangi, Farid > Sent: 26 April, 2005 07:12 > To: Bernard Aboba > Cc: radiusext@ops.ietf.org; Nelson, David > Subject: RE: Issue 83: CUI and re-authentication >=20 >=20 > No. The "Validation" means that the RADIUS server checks to see if the > CUI value is the same as the one that was sent in the previous > Access-Accept. However, the RADIUS server does not require=20 > to do this > validation. > Thanks, > Farid >=20 > > -----Original Message----- > > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > > Sent: Monday, April 25, 2005 6:50 PM > > To: Adrangi, Farid > > Cc: radiusext@ops.ietf.org; Nelson, David > > Subject: RE: Issue 83: CUI and re-authentication > >=20 > >=20 > > Presumably, by "validated" you mean that the CUI presented is=20 > > associated > > with the subsequently authenticated identity. > >=20 > > On Mon, 25 Apr 2005, Adrangi, Farid wrote: > >=20 > > > Good point Bernard! Avi and I just discussed this, and=20 > our current > > > thinking is to add something like below to the draft: > > > > > > " > > > When re-authenticating, a NAS that supports CUI MUST=20 > include the CUI > > > attribute with the value of CUI received in a previous=20 > > Access-Accept. > > > > > > Upon receiving a non-nul CUI in an Access-Request the home=20 > > RADIUS server > > > MAY validate the value of CUI and if the validation=20 > fails, then the > > > RADIUS server SHOULD respond with an Access-Reject message. > > > > > > During reauthentication, upon receiving an Access-Accept,=20 > > the value of > > > the CUI maybe different from the previously received CUI for that > > > session. The NAS MUST use this value on all subsequent accounting > > > messages for that session. > > > " > > > > > > Does this work for you, all? > > > > > > Thanks, > > > Farid > > > > > > > -----Original Message----- > > > > From: owner-radiusext@ops.ietf.org > > > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > > > > Sent: Friday, April 22, 2005 7:33 PM > > > > To: radiusext@ops.ietf.org > > > > Subject: Issue 83: CUI and re-authentication > > > > > > > > > > > > Issue 83: CUI and re-authentication > > > > Submitter name: Bernard Aboba > > > > Submitter email address: aboba@internaut.com > > > > Date first submitted: April 22, 2005 > > > > Reference: > > > > Document: CUI-04 > > > > Comment type: T > > > > Priority: S > > > > Section: Various > > > > Rationale/Explanation of issue: > > > > > > > > The document does not state how CUI is used with an > > > > Access-Request that > > > > occurs due to re-authentication. For example, in the original > > > > authentication, the CUI attribute was provided within the > > > > Access-Accept, > > > > and subsequently within Accounting-Request packets=20 > > (interim). Let us > > > > assume that a Session-Timeout attribute was sent with > > > > Termination-Action=3DRADIUS. > > > > > > > > What happens at the expiration of the Session-Timeout value? > > > > Does the NAS > > > > send an Access-Request containing a CUI attribute to the=20 > > RADIUS server > > > > with the currently used CUI, or does it send an empty CUI > > > > attribute? It > > > > seems more appropriate for it to send the currently used CUI, > > > > since that > > > > does not require the RADIUS server to keep state. I presume > > > > that the User-Name and EAP re-authentication elements are > > > > handled the same > > > > way (e.g. User-Name includes "@realm" privacy NAI). > > > > > > > > -- > > > > to unsubscribe send a message to=20 > > radiusext-request@ops.ietf.org with > > > > the word 'unsubscribe' in a single line as the message=20 > 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: Tue, 26 Apr 2005 04:13: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: Issue 83: CUI and re-authentication Date: Mon, 25 Apr 2005 21:12:15 -0700 Message-ID: Thread-Topic: Issue 83: CUI and re-authentication Thread-Index: AcVKAjOZw4wGabvbRXGXlpQIAt7s1QAEgjCw From: "Adrangi, Farid" To: "Bernard Aboba" Cc: , "Nelson, David" No. The "Validation" means that the RADIUS server checks to see if the CUI value is the same as the one that was sent in the previous Access-Accept. However, the RADIUS server does not require to do this validation. Thanks, Farid > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Monday, April 25, 2005 6:50 PM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org; Nelson, David > Subject: RE: Issue 83: CUI and re-authentication >=20 >=20 > Presumably, by "validated" you mean that the CUI presented is=20 > associated > with the subsequently authenticated identity. >=20 > On Mon, 25 Apr 2005, Adrangi, Farid wrote: >=20 > > Good point Bernard! Avi and I just discussed this, and our current > > thinking is to add something like below to the draft: > > > > " > > When re-authenticating, a NAS that supports CUI MUST include the CUI > > attribute with the value of CUI received in a previous=20 > Access-Accept. > > > > Upon receiving a non-nul CUI in an Access-Request the home=20 > RADIUS server > > MAY validate the value of CUI and if the validation fails, then the > > RADIUS server SHOULD respond with an Access-Reject message. > > > > During reauthentication, upon receiving an Access-Accept,=20 > the value of > > the CUI maybe different from the previously received CUI for that > > session. The NAS MUST use this value on all subsequent accounting > > messages for that session. > > " > > > > Does this work for you, all? > > > > Thanks, > > Farid > > > > > -----Original Message----- > > > From: owner-radiusext@ops.ietf.org > > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > > > Sent: Friday, April 22, 2005 7:33 PM > > > To: radiusext@ops.ietf.org > > > Subject: Issue 83: CUI and re-authentication > > > > > > > > > Issue 83: CUI and re-authentication > > > Submitter name: Bernard Aboba > > > Submitter email address: aboba@internaut.com > > > Date first submitted: April 22, 2005 > > > Reference: > > > Document: CUI-04 > > > Comment type: T > > > Priority: S > > > Section: Various > > > Rationale/Explanation of issue: > > > > > > The document does not state how CUI is used with an > > > Access-Request that > > > occurs due to re-authentication. For example, in the original > > > authentication, the CUI attribute was provided within the > > > Access-Accept, > > > and subsequently within Accounting-Request packets=20 > (interim). Let us > > > assume that a Session-Timeout attribute was sent with > > > Termination-Action=3DRADIUS. > > > > > > What happens at the expiration of the Session-Timeout value? > > > Does the NAS > > > send an Access-Request containing a CUI attribute to the=20 > RADIUS server > > > with the currently used CUI, or does it send an empty CUI > > > attribute? It > > > seems more appropriate for it to send the currently used CUI, > > > since that > > > does not require the RADIUS server to keep state. I presume > > > that the User-Name and EAP re-authentication elements are > > > handled the same > > > way (e.g. User-Name includes "@realm" privacy NAI). > > > > > > -- > > > to unsubscribe send a message to=20 > 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, 26 Apr 2005 02:01:40 +0000 Date: Mon, 25 Apr 2005 19:01:31 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: radiusext@ops.ietf.org, eap@frascone.com, isms@ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Martin Soukup said: > The use of RADIUS itself without a defined extension such as EAP-TLS > or EAP-PEAP over RADIUS cannot securely pass attributes between > entities. Note that the defined EAP-TLS (or other EAP mechanisms) > over RADIUS provides for secure attribute passing between entities > even through proxies. In response to which, Glen Zorn spake thusly: > I thought that I was passing familiar w/EAP-TLS (and even more so > w/PEAP), but I am completely unaware of such capabilities. Would > you mind explaining how this is achieved, given that RADIUS & EAP > are completely different protocols? I also was unaware of the ability of EAP-TLS to transmit RADIUS attributes between the EAP peer and server. I had always thought RADIUS was a protocol only spoken between a NAS and a RADIUS server, and that EAP-TLS didn't support transmission of TLVs. But I guess this is a somewhat old fashioned point of view. Perhaps this is referring to EAP-TLS "extended" via the following? http://www.ietf.org/internet-drafts/draft-funk-tls-inner-application-extension-01.txt -- to 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, 26 Apr 2005 01:50:10 +0000 Date: Mon, 25 Apr 2005 18:49:31 -0700 (PDT) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org, "Nelson, David" Subject: RE: Issue 83: CUI and re-authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Presumably, by "validated" you mean that the CUI presented is associated with the subsequently authenticated identity. On Mon, 25 Apr 2005, Adrangi, Farid wrote: > Good point Bernard! Avi and I just discussed this, and our current > thinking is to add something like below to the draft: > > " > When re-authenticating, a NAS that supports CUI MUST include the CUI > attribute with the value of CUI received in a previous Access-Accept. > > Upon receiving a non-nul CUI in an Access-Request the home RADIUS server > MAY validate the value of CUI and if the validation fails, then the > RADIUS server SHOULD respond with an Access-Reject message. > > During reauthentication, upon receiving an Access-Accept, the value of > the CUI maybe different from the previously received CUI for that > session. The NAS MUST use this value on all subsequent accounting > messages for that session. > " > > Does this work for you, all? > > Thanks, > Farid > > > -----Original Message----- > > From: owner-radiusext@ops.ietf.org > > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > > Sent: Friday, April 22, 2005 7:33 PM > > To: radiusext@ops.ietf.org > > Subject: Issue 83: CUI and re-authentication > > > > > > Issue 83: CUI and re-authentication > > Submitter name: Bernard Aboba > > Submitter email address: aboba@internaut.com > > Date first submitted: April 22, 2005 > > Reference: > > Document: CUI-04 > > Comment type: T > > Priority: S > > Section: Various > > Rationale/Explanation of issue: > > > > The document does not state how CUI is used with an > > Access-Request that > > occurs due to re-authentication. For example, in the original > > authentication, the CUI attribute was provided within the > > Access-Accept, > > and subsequently within Accounting-Request packets (interim). Let us > > assume that a Session-Timeout attribute was sent with > > Termination-Action=RADIUS. > > > > What happens at the expiration of the Session-Timeout value? > > Does the NAS > > send an Access-Request containing a CUI attribute to the RADIUS server > > with the currently used CUI, or does it send an empty CUI > > attribute? It > > seems more appropriate for it to send the currently used CUI, > > since that > > does not require the RADIUS server to keep state. I presume > > that the User-Name and EAP re-authentication elements are > > handled the same > > way (e.g. User-Name includes "@realm" privacy 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, 25 Apr 2005 23:45:49 +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 83: CUI and re-authentication Date: Mon, 25 Apr 2005 16:45:16 -0700 Message-ID: Thread-Topic: Issue 83: CUI and re-authentication Thread-Index: AcVHrNyoifKDYWU6S/2AoftAtbhnVwCQwb9A From: "Adrangi, Farid" To: "Bernard Aboba" , Cc: "Nelson, David" Good point Bernard! Avi and I just discussed this, and our current thinking is to add something like below to the draft: " When re-authenticating, a NAS that supports CUI MUST include the CUI attribute with the value of CUI received in a previous Access-Accept. Upon receiving a non-nul CUI in an Access-Request the home RADIUS server MAY validate the value of CUI and if the validation fails, then the RADIUS server SHOULD respond with an Access-Reject message. During reauthentication, upon receiving an Access-Accept, the value of the CUI maybe different from the previously received CUI for that session. The NAS MUST use this value on all subsequent accounting messages for that session. " Does this work for you, all? Thanks, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, April 22, 2005 7:33 PM > To: radiusext@ops.ietf.org > Subject: Issue 83: CUI and re-authentication >=20 >=20 > Issue 83: CUI and re-authentication > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: April 22, 2005 > Reference: > Document: CUI-04 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: >=20 > The document does not state how CUI is used with an=20 > Access-Request that > occurs due to re-authentication. For example, in the original > authentication, the CUI attribute was provided within the=20 > Access-Accept, > and subsequently within Accounting-Request packets (interim). Let us > assume that a Session-Timeout attribute was sent with > Termination-Action=3DRADIUS. >=20 > What happens at the expiration of the Session-Timeout value? =20 > Does the NAS > send an Access-Request containing a CUI attribute to the RADIUS server > with the currently used CUI, or does it send an empty CUI=20 > attribute? It > seems more appropriate for it to send the currently used CUI,=20 > since that > does not require the RADIUS server to keep state. I presume > that the User-Name and EAP re-authentication elements are=20 > handled the same > way (e.g. User-Name includes "@realm" privacy NAI). >=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, 25 Apr 2005 20:18:21 +0000 Message-ID: <426D5078.4020501@cisco.com> Date: Mon, 25 Apr 2005 13:18:00 -0700 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issue: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Description of issue: VSAs for Session-Identification Submitter name: Murtaza S. Chiba Submitter email address: mchiba@cisco.com Date first submitted: April 25th 2005 Reference: URL to e-mail describing problem, if available Document: RFC3576 Comment type: E Priority: 1 Section: 3 Rationale/Explanation of issue: Some VSAs could be used for Session-Identification in addition to any authorization purpose. Length description of problem In section 3 under Session Identification attributes, Vendor-Specific attributes are not mentioned. This should be left to a vendor to decide which attributes designate session identification and which designate authorization in the case where ambiguity is clearly eliminated. That is a subtype and/or contents readily distinguish between session identification and authorization. Also in section 3.3 Note 3 mentions that the VSA is only for authorization. This too should be changed to allow for session identification. Requested change: Section 3: Please add VSA to the list under "Session identification attributes" the following text Vendor-Specific 26 [RFC2865] The Vendor Specific attribute used for Session Identification purposes. Section 3.3: Modify note 3. from "When included within a CoA-Request, these attributes represent an authorization change request" to "When included within a CoA-Request, these attributes MAY represent an authorization change requests" Thanks, Murtaza -- to 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, 25 Apr 2005 17:29:21 +0000 Message-Id: <200504251729.j3PHT254017150@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Martin Soukup'" , "'Thierry Moreau'" , "'Bernard Aboba'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Mon, 25 Apr 2005 10:28:56 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C54981.9B1F8470" Thread-Index: AcVJlvONKqR4Qo7bQGet8WrhlnyAXQAJFy3g This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C54981.9B1F8470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The use of RADIUS itself without a defined extension such as EAP-TLS or EAP-PEAP over RADIUS cannot securely pass attributes between entities. Note that the defined EAP-TLS (or other EAP mechanisms) over RADIUS provides for secure attribute passing between entities even through proxies. I thought that I was passing familiar w/EAP-TLS (and even more so w/PEAP), but I am completely unaware of such capabilities. Would you mind explaining how this is achieved, given that RADIUS & EAP are completely different protocols? Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Thierry Moreau > Sent: April 22, 2005 1:56 PM > To: Bernard Aboba > Cc: radiusext@ops.ietf.org; isms@ietf.org; eap@frascone.com > Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party > > > Thanks for these explanations. > > See comments in-line below. > > > > Bernard Aboba wrote: > > [... explanations about end-to-end (NAS to server) and current RADIUS > protocols ...] > > > > > Are you proposing creating a new RADIUS security model that > would only > > be used by ISMS? That seems like a lot of work for little overall > > benefit to the RADIUS community. > > > > I did assume that an implementation-specific attribute to the RADIUS > Access-Accept packet would pass unmodified through a RADIUS > proxy, which > in fact is a matter of proxy policy (RFC2865 , section 2.3). > With this > erroneous assumption, I thought I was proposing an > implementation-specific use of existing RADIUS protocol > facility. I did > not expect any "benefit to the RADIUS community". > > > > > > > Rather than designing a new version of RADIUS to meet its needs, it > > seems more profitable for ISMS to either figure out how to use the > > protocol as it exists today, or to summarize its > requirements for new > > work and ask that it be chartered outside of ISMS. > > > > Point well taken. I just looked at RFC3576, abstract reproduced below > > "This document describes a currently deployed extension > to the Remote > Authentication Dial In User Service (RADIUS) protocol, allowing > dynamic changes to a user session, as implemented by > network access > server products. This includes support for disconnecting > users and > changing authorizations applicable to a user session." > > Unfortunately, the security section of RFC3576 raises a number of > concerns. E.g. the following sentence: "It is RECOMMENDED > that IPsec be > employed to afford better security." > > Again, thanks for your comments. > > -- > > - Thierry Moreau > > CONNOTECH Experts-conseils inc. > 9130 Place de Montgolfier > Montreal, Qc > Canada H2M 2A1 > > Tel.: (514)385-5691 > Fax: (514)385-5900 > > web site: http://www.connotech.com > e-mail: thierry.moreau@connotech.com > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > ------=_NextPart_000_0087_01C54981.9B1F8470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [eap] RE: [Isms] RADIUS is not a trusted third = party
The use of RADIUS itself = without a defined=20 extension such as EAP-TLS or EAP-PEAP over RADIUS cannot securely pass=20 attributes between entities. Note that the defined EAP-TLS (or other EAP = mechanisms) over RADIUS provides for secure attribute passing between = entities=20 even through proxies. 
 
I thought that I was passing familiar = w/EAP-TLS (and=20 even more so w/PEAP), but I am completely unaware of such = capabilities. =20 Would you mind explaining how this is achieved, given that RADIUS & = EAP are=20 completely different protocols?

Martin.

> -----Original Message-----
>=20 From: isms-bounces@lists.ietf.org
> [mailto:isms-bounces@lists.iet= f.org]=20 On Behalf Of Thierry Moreau
> Sent: April = 22, 2005=20 1:56 PM
> To: Bernard Aboba =
> Cc: radiusext@ops.ietf.org; isms@ietf.org; = eap@frascone.com=20
> Subject: Re: [eap] RE: [Isms] RADIUS is not a = trusted=20 third party
>
>=20
> Thanks for these explanations. =
>
> See comments in-line = below.=20
>
>
>=20
> Bernard Aboba wrote:
>=20
> [... explanations about end-to-end (NAS = to server)=20 and current RADIUS
> protocols ...] =
>
> >
> >=20 Are you proposing creating a new RADIUS security model that =
> would only
> > be used by = ISMS? =20 That seems like a lot of work for little overall
>=20 > benefit to the RADIUS community.
> = >=20
>
> I did = assume that an=20 implementation-specific attribute to the RADIUS
>=20 Access-Accept packet would pass unmodified through a RADIUS =
> proxy, which
> in fact is a = matter of=20 proxy policy (RFC2865 , section 2.3).
> = With this=20
> erroneous assumption, I thought I was = proposing an=20
> implementation-specific use of existing = RADIUS=20 protocol
> facility. I did
> not expect any "benefit to the RADIUS community". =
>
> >
> >=20
> > Rather than designing a new version = of RADIUS=20 to meet its needs, it
> > seems more = profitable=20 for ISMS to either figure out how to use the
> >=20 protocol as it exists today, or to summarize its
>=20 requirements for new
> > work and ask = that it be=20 chartered outside of ISMS.
> > =
>
> Point well taken. I just = looked at=20 RFC3576, abstract reproduced below
> =
>     "This document describes a = currently=20 deployed extension
> to the Remote =
>     Authentication Dial In User = Service (RADIUS)=20 protocol, allowing
>     dynamic=20 changes to a user session, as implemented by
>=20 network access
>     = server=20 products.  This includes support for disconnecting
> users and
>    =20 changing authorizations applicable to a user session."
>
> Unfortunately, the security = section of=20 RFC3576 raises a number of
> concerns. E.g. = the=20 following sentence: "It is RECOMMENDED
> = that IPsec=20 be
> employed to afford better = security."=20
>
> Again, thanks for = your=20 comments.
>
> = --=20
>
> - Thierry=20 Moreau
>
> = CONNOTECH=20 Experts-conseils inc.
> 9130 Place de=20 Montgolfier
> Montreal, Qc
> Canada   H2M 2A1
>=20
> Tel.: (514)385-5691
>=20 Fax:  (514)385-5900
>
> web site: http://www.connotech.com
> e-mail:=20 thierry.moreau@connotech.com
> =
>
>=20 _______________________________________________
>=20 Isms mailing list
> = Isms@lists.ietf.org=20
> https://www1.ietf.org/mailman/listinfo/isms =
>
>

------=_NextPart_000_0087_01C54981.9B1F8470-- -- to 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, 25 Apr 2005 17:14:15 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Date: Mon, 25 Apr 2005 13:11:09 -0400 Message-Id: <20050425171109.9D00D16DD6@mail.nitros9.org> Bernard Aboba wrote: > 1. How is internationalization supported on your EAP peer implementation? The implementation enables internationalization, but doesn't fully support it.[1] > Does your EAP peer implementation support formating of the realm > portion in IDN, or does it enable entering of UTF-8, or perhaps just plain > ASCII? It enables entering UTF-8 text. > 2. How is internationalization supported on your RADIUS proxy > implementation?. The implementation enables internationalization, but doesn't fully support it.[1] > How does your implementation support internationalization within the realm > table? Are realm table entries stored in IDN, UTF-8, or something else? They are stored as NUL terminated C strings.[2] > How are comparisons done between the realm in the NAI and the realm stored > in the realm table? strcmp() Notes: [1] If your file editor will write UTF-8 strings to the configuration files, FreeRADIUS will read them and use them. But it will not print them as the appropriate UTF-8 glyphs in it's output or log files. Instead, it will print non-ASCII characters as octal-encoded strings. e.g "\303\301" [2] The RADIUS client, server and EAP peer treat the strings as opaque tokens for internal processing. Therefore UTF-8 text may be entered, or any other non-ASCII data, so long as it does not contain a NUL (zero) character. 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: Mon, 25 Apr 2005 16:00:30 +0000 Date: Mon, 25 Apr 2005 09:00:18 -0700 (PDT) From: Bernard Aboba To: Martin Soukup cc: "'Thierry Moreau'" , radiusext@ops.ietf.org, isms@ietf.org, eap@frascone.com Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The use of RADIUS itself without a defined extension such as EAP-TLS or > EAP-PEAP over RADIUS cannot securely pass attributes between entities. Note > that the defined EAP-TLS (or other EAP mechanisms) over RADIUS provides for > secure attribute passing between entities even through proxies. EAP does not affect how RADIUS attributes are passed, nor does it enable the passing of RADIUS attributes between the EAP peer and server. So as far as RADIUS attributes are concerned, what EAP method is used, or whether EAP is used does not affect RADIUS security, except that an EAP-Message attribute is included in the messages. Also, EAP-TLS does not permit passing of TLVs between the peer and server; this is only allowed in tunneled mechanisms such as EAP-TTLS and PEAP. -- to 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, 25 Apr 2005 15:54:49 +0000 Date: Mon, 25 Apr 2005 08:54:39 -0700 (PDT) From: Bernard Aboba To: Jari Arkko cc: radiusext@ops.ietf.org Subject: Re: Issue: 2486bis internationalization and ! syntax Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > One problem with this is that existing code that does the > query would be unable to do a UTF-8 query but would be > able to do an IDN query. Oh well, there isn't much Diameter > usage that would be hit with this... > > And there seems to be another more serious problem. Namely, even > if RADIUS doesn't do DNS queries, it still stores and compares > strings. If someone has already put in a rule or entry for an > international DNS name, he has been able to do so already in > RFC 2486, because IDNs are really legal DNS names. And he > likely didn't use UTF-8, because that would have been illegal > as a NAI. Now, if we suddenly start sending the IDNs as UTF-8 > instead, this will break existing usage. All that is needed for > this scenario to apply is someone who (a) has an international > DNS name and (b) has a RADIUS server. What's the likelihood > of this? > > My conclusion: problems in approach #2 seem more likely > to appear in common cases, so my preference is #1. What > do others think? I think that we need to understand more about how existing EAP peer and RADIUS proxy implementations function with respect to internationalization. For example, do existing EAP peer implementations allow the user to enter UTF-8? How do existing RADIUS proxy implementations enter the realm table and how do they compare it against the realm in the NAI? I've put out an implementation survey that may help us answer these questions. -- to 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, 25 Apr 2005 15:44:19 +0000 Date: Mon, 25 Apr 2005 08:43:30 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Implementation Survey: How does your EAP peer/RADIUS proxy handle internationalization? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RFC 2486bis specifies how the NAI is internationalized. In the development of this document, some questions have arisen about the behavior of existing EAP peers and RADIUS proxies. In order to understand how existing implementations function, we need implementers to volunteer the answer to several questions: 1. How is internationalization supported on your EAP peer implementation? Does your EAP peer implementation support formating of the realm portion in IDN, or does it enable entering of UTF-8, or perhaps just plain ASCII? 2. How is internationalization supported on your RADIUS proxy implementation?. How does your implementation support internationalization within the realm table? Are realm table entries stored in IDN, UTF-8, or something else? How are comparisons done between the realm in the NAI and the realm stored in the realm table? Please respond by May 2, 2005. -- to 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, 25 Apr 2005 05:59:12 +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: 2486bis internationalization and unassigned codepoints Date: Mon, 25 Apr 2005 08:57:33 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D167DCD@esebe100.NOE.Nokia.com> Thread-Topic: Issue: 2486bis internationalization and unassigned codepoints Thread-Index: AcVJTKu87Vc8q4htS4mktHq56TsB/wADvn5g From: To: , Hi Jari, This seems reasonable to me. John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Jari Arkko > Sent: 25 April, 2005 06:25 > To: radiusext@ops.ietf.org > Subject: Issue: 2486bis internationalization and unassigned codepoints >=20 >=20 > At IETF-62, this presentation outlined the i18n issue: >=20 > http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext_nai.ppt >=20 > Subproblems 1 and 2 are OK. Subproblems 3 and 4 are still open. >=20 > 3 is really about what to do with unassigned codepoints. My current > thinking is that a username with a particular character X=20 > will not be=20 > entered > into the Radius server's database unless X is supported the > Unicode and software versions of the server's admin UI. > The same for the client end and user's UI. Therefore, I think > what we need to say is that the all the i18n mapping and > checking operations happen only at the client (when entering > a NAI), and when entering this particular user's subscription > at the server side. And nothing in between should do this > under normal circumstances, they should just be passing > bytes along, not checking whether those bytes form unassigned > or assigned code points. This ensures that an old proxy doesn't > prevent your new username from being used. >=20 > Does this work for everyone? >=20 > --Jari >=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, 25 Apr 2005 03:26:04 +0000 Message-ID: <426C633C.5000405@piuha.net> Date: Mon, 25 Apr 2005 06:25:48 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issue: 2486bis internationalization and ! syntax Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Issue 4 is about the interaction between internationzalition an the ! transformation within NAIs. Basically you may change user@homerealm.example.net to homerealm.example.net!user@otherrealm.example.net and back, under certain exceptional AAA routing conditions, i.e., when the local network can route/roam your request back to the right place. Now, what makes this interesting is that the usernamepart is in UTF-8 and realmpart is an IDN in ASCII. Here there are multiple resolutions of the issue. #1: This transformation is an exceptional case where proxies will perform some mapping from one character set to another. Where such transformations are done, an attempt to transform a string that can't be mapped to IDN (e.g. illegal DNS name) should result in an error. From the user's point of view this would be a similar error as you get when the domain you are trying to give is unknown. Correct use of the this transformation should not result in this error, given that the string you put in from the '!' should have originally been a realm name. One drawback of this is that in order for the proxy to map UTF-8 to ASCII, it needs to understand the codepoints. This means in practise that a proxy with a today's codepoint data is unable to do the transformation for something that uses a newer codepoint. New codepoints are often defined but my understanding is that they are for quite special and small languages. Given this and the exceptional nature of the ! usage this may be acceptable. #2: Realmpart needs to be converted to IDNA if and when a DNS query needs to be sent. However, only Diameter defines how DNS queries can be used to locate AAA servers; RADIUS implementations do not support this. It has been suggested that in order to "optimize for the common case" that the entire string could be left in UTF-8, obviating the need for conversions between UTF-8 and IDNA until a DNS query needed to be sent. Since RADIUS implementations do not send such queries, they would not need to do the conversion at all. Within a Diameter agent, the conversion could be delayed until it is required, at which time it might conceivably fail. One problem with this is that existing nde that does the query would be unable to do a UTF-8 query but would be able to do an IDN query. Oh well, there isn't much Diameter usage that would be hit with this... And there seems to be another more serious problem. Namely, even if RADIUS doesn't do DNS queries, it still stores and compares strings. If someone has already put in a rule or entry for an international DNS name, he has been able to do so already in RFC 2486, because IDNs are really legal DNS names. And he likely didn't use UTF-8, because that would have been illegal as a NAI. Now, if we suddenly start sending the IDNs as UTF-8 instead, this will break existing usage. All that is needed for this scenario to apply is someone who (a) has an international DNS name and (b) has a RADIUS server. What's the likelihood of this? My conclusion: problems in approach #2 seem more likely to appear in common cases, so my preference is #1. What do others think? -- to 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, 25 Apr 2005 03:25:17 +0000 Message-ID: <426C62F5.5060509@piuha.net> Date: Mon, 25 Apr 2005 06:24:37 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Issue: 2486bis internationalization and unassigned codepoints Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At IETF-62, this presentation outlined the i18n issue: http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext_nai.ppt Subproblems 1 and 2 are OK. Subproblems 3 and 4 are still open. 3 is really about what to do with unassigned codepoints. My current thinking is that a username with a particular character X will not be entered into the Radius server's database unless X is supported the Unicode and software versions of the server's admin UI. The same for the client end and user's UI. Therefore, I think what we need to say is that the all the i18n mapping and checking operations happen only at the client (when entering a NAI), and when entering this particular user's subscription at the server side. And nothing in between should do this under normal circumstances, they should just be passing bytes along, not checking whether those bytes form unassigned or assigned code points. This ensures that an old proxy doesn't prevent your new username from being used. Does this work for everyone? --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, 23 Apr 2005 02:33:39 +0000 Date: Fri, 22 Apr 2005 19:33:09 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 83: CUI and re-authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 83: CUI and re-authentication Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: April 22, 2005 Reference: Document: CUI-04 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: The document does not state how CUI is used with an Access-Request that occurs due to re-authentication. For example, in the original authentication, the CUI attribute was provided within the Access-Accept, and subsequently within Accounting-Request packets (interim). Let us assume that a Session-Timeout attribute was sent with Termination-Action=RADIUS. What happens at the expiration of the Session-Timeout value? Does the NAS send an Access-Request containing a CUI attribute to the RADIUS server with the currently used CUI, or does it send an empty CUI attribute? It seems more appropriate for it to send the currently used CUI, since that does not require the RADIUS server to keep state. I presume that the User-Name and EAP re-authentication elements are handled the same way (e.g. User-Name includes "@realm" privacy 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: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 22 Apr 2005 15:25:25 +0000 Date: Fri, 22 Apr 2005 08:25:05 -0700 (PDT) From: Bernard Aboba To: Julien Bournelle cc: "Nelson, David" , isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I'm wondering if an operator will let its EAP authenticator directly > contact EAP server from other operators using redirect functionality of > Diameter. As I understand it, proxy bypass is being considered by TERENA primarily to eliminate excessive latency in trans-continental roaming. More info on the "trust fabric" of EduRoam NG is available here: http://www.terena.nl/tech/task-forces/tf-mobility/ http://www.eduroam.org/docs/eduroam-article.pdf http://www.eduroam.org/wiki/NextGeneration?v=ina http://www.lab.telin.nl/~arjan/pub/tnc05-ea-eertink.pdf http://www.es.net/raf/ESnet-RAF-WP.html -- to 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, 22 Apr 2005 14:53:13 +0000 Date: Fri, 22 Apr 2005 07:52:58 -0700 (PDT) From: Bernard Aboba To: Thierry Moreau cc: "Blumenthal, Uri" , isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Is it concievable to design end-to-end security (i.e. from NAS to RADIUS > server through any intermediate RADIUS proxies) with an > implementation-specific attribute to the RADIUS Access-Accept packet? Diameter CMS enabled the creation of attributes that could be sent between the RADIUS server and NAS without being revealed to an intermediate proxy. Therefore it could be said that it enabled "end-to-end" trust, something that was already possible within Diameter in other ways (re-direct). Since re-direct needed to be supported anyway and also solved the problem, that was the direction that was taken once it became clear that there was not enough interest in Diameter CMS to continue the work. Note that Re-direct-based trust is built on the following elements: 1. Support for DNS discovery of RADIUS servers within a domain. This allows the RADIUS client to discover which RADIUS server it needs to talk to. 2. Support for certificate-based authentication. For inter-domain purposes, this is handled via TLS within Diameter. This allows a Diameter client to contact an arbitrary Diameter server and mutually authenticate to it, provided that the certificate chain can be validated. With TLS it is possible to create application-specific trust chains, something that is much more difficult within IKE, so that the trust anchor for Diameter (e.g. certificates signed by a roaming consortium CA) need not be the same as for other applications (e.g. Verisign certificate for a Web server). It is conceivable to add support for both of these elements to RADIUS, but of these, element #2 is more difficult. RADIUS over IPsec is defined in RFC 3579, but it is not deployed for inter-domain usage. To address the limitations, RADIUS over TLS (RADSEC) has now been defined and is shipping. My understanding is that it is being considered for deployment within large inter-continental roaming networks (e.g. TERENA). More info on RADSEC is available here: http://www.terena.nl/mail-archives/mobility/msg01225.html http://www.open.com.au/radiator/radsec-whitepaper.pdf > This requires a pre-shared secret key between the RADIUS server (or more > precisely an implementation-specific server co-located with the RADIUS > server) and the application-specific component co-located with the > RADIUS NAS. Are you proposing creating a new RADIUS security model that would only be used by ISMS? That seems like a lot of work for little overall benefit to the RADIUS community. > The security implication of RADIUS proxies has been noticed in isms > mailing list early on. Perhaps it has been overlooked at some point in > the discussion. Rather than designing a new version of RADIUS to meet its needs, it seems more profitable for ISMS to either figure out how to use the protocol as it exists today, or to summarize its requirements for new work and ask that it be chartered outside of ISMS. -- to 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, 22 Apr 2005 14:34:08 +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: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Fri, 22 Apr 2005 10:33:02 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322DC@MAANDMBX2.ets.enterasys.com> Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party Thread-Index: AcVGoE72do1f9de2Q8WQrAZhTXLhGgApmOJg From: "Nelson, David" To: "John Vollbrecht" Cc: , , John Vollbrecht writes ... [mailto:jrv@umich.edu] > The question I am wondering about is whether the RADIUS server could be > a trusted third party if it is directly connected to the NAS. In that > case it has credentials with all parties. However the credentials are > of quite different form - I am wondering if the form of credentials or > the relationship between the credentials makes a difference in whether > it can act effectively as a trusted third party. My first guess is > that it could (especially if RADIUS had stronger hashing) but I am not > sure. > What is your thought? I suspect there are cases in which a single (non-proxy) RADIUS server could act as a trusted third party, but that would depend on the extent to which the RADIUS server and the EAP server were considered a single entity. I think the issue is whether all parties can [directly] validate the bindings of authenticated identity to keys. When one set of bindings is created via the EAP session between the EAP peer and EAP server and another set of bindings is created via the RADIUS authentication and authorization exchanges between the RADIUS server and the NAS, there is certainly the opportunity for the parties to have disjoint sets of key bindings. -- to 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, 22 Apr 2005 04:51:51 +0000 Date: Thu, 21 Apr 2005 21:51:29 -0700 (PDT) From: Bernard Aboba To: "Blumenthal, Uri" cc: "Nelson, David" , isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Yet NAS takes "go/no-go" decision from RADIUS, and takes the keys to > talk to the client... If this is not trust - what is it? There is no IETF standard defining how keys are provided within RADIUS for exactly that reason -- there is no trust relationship defined when a proxy is present. The "Housley Criteria" described in RFC 4017 do not allow disclosure of keys to additional parties. The problem does not exist in Diameter EAP, which enables keys to be provided directly without access by proxies. -- to 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, 22 Apr 2005 03:00:59 +0000 Date: Thu, 21 Apr 2005 19:59:46 -0700 (PDT) From: Bernard Aboba To: "Nelson, David" cc: isms@ietf.org, eap@frascone.com, radiusext@ops.ietf.org Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I think there is a subtle difference between a "trusted third party" and > a RADIUS server which may have bi-lateral trust relationships with > various parties. Yes. Where RADIUS proxies are present there is no trust relationship between the NAS and RADIUS server. This is in contrast to Diameter, where such a relationship can be established via re-direct. The distinction is important in a number of cases. In Kerberos, the KDC is able to provide a ticket to any principal because it has a shared secret that it shares with that principle. Within RADIUS this is not possible. A RADIUS server cannot provide the user with a ticket to a NAS because it may not have a trust relationship with that NAS. Note that at one point, there was a proposal for integration of RADIUS with Kerberos. That proposal did in fact enable RADIUS to become a true trusted third party. The proposal seemed practical. However, the AAA WG went with another proposal (Diameter CMS) which it turned out that noone wanted to implement. Among other things, the proposal enabled a RADIUS server to send a key to a NAS that could not be viewed by intervening proxies. In retrospect, the IETF may have missed an important opportunity. For a trip down memory lane, look here: http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt -- to 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, 21 Apr 2005 18:32:24 +0000 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: , , , John Vollbrecht From: John Vollbrecht Subject: Re: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Thu, 21 Apr 2005 14:31:31 -0400 To: "Nelson, David" Nice explanation David. I have clarifying question below - On Apr 21, 2005, at 11:37 AM, Nelson, David wrote: > Apler Yegin writes... > >> I guess the AAA protocol that runs between the NAS and AAA server is a >> "wire" as you said, but the AAA server is the trusted third party. > Does >> this make sense? > > I think there is a subtle difference between a "trusted third party" > and > a RADIUS server which may have bi-lateral trust relationships with > various parties. The RADIUS server will always have a trust > relationship with its enrolled Radius clients, via the shared secret. > Those clients may be NASes or they may be RADIUS proxy servers. RADIUS > trust is always hop-by-hop. > > Strictly speaking, the RADIUS server has a trust relationship with the > human user only when the native RADIUS password database is used as the > source of authentication credentials. Most often, the RADIUS server > relies on some other authentication service (e.g. Active Directory, > LDAP, NIS, etc.). One tends to think of this as a single entity, and > for certain purposes this is fine. For other purposes, we need to > retain the distinction. > > The host (e.g. via a machine certificate) may also have a trust > relationship, but once again this relationship is typically with an EAP > server "attached" to the Radius server, which may in turn rely on other > authentication services. The question I am wondering about is whether the RADIUS server could be a trusted third party if it is directly connected to the NAS. In that case it has credentials with all parties. However the credentials are of quite different form - I am wondering if the form of credentials or the relationship between the credentials makes a difference in whether it can act effectively as a trusted third party. My first guess is that it could (especially if RADIUS had stronger hashing) but I am not sure. What is your thought? > A more typical example of a "trusted third party" is a Kerberos KDC > which does in fact directly share credentials with all enrolled > principals (human users, hosts or applications). > > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap > > -- to 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, 21 Apr 2005 15:38:56 +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: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Thu, 21 Apr 2005 11:37:31 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322D6@MAANDMBX2.ets.enterasys.com> Thread-Topic: [eap] RE: [Isms] RADIUS is not a trusted third party Thread-Index: AcVGeu4LuIyGq08NS52QCNwpTEVr1wAC1QGw From: "Nelson, David" To: , , Apler Yegin writes... > I guess the AAA protocol that runs between the NAS and AAA server is a > "wire" as you said, but the AAA server is the trusted third party. Does > this make sense? I think there is a subtle difference between a "trusted third party" and a RADIUS server which may have bi-lateral trust relationships with various parties. The RADIUS server will always have a trust relationship with its enrolled Radius clients, via the shared secret. Those clients may be NASes or they may be RADIUS proxy servers. RADIUS trust is always hop-by-hop. Strictly speaking, the RADIUS server has a trust relationship with the human user only when the native RADIUS password database is used as the source of authentication credentials. Most often, the RADIUS server relies on some other authentication service (e.g. Active Directory, LDAP, NIS, etc.). One tends to think of this as a single entity, and for certain purposes this is fine. For other purposes, we need to retain the distinction. The host (e.g. via a machine certificate) may also have a trust relationship, but once again this relationship is typically with an EAP server "attached" to the Radius server, which may in turn rely on other authentication services. A more typical example of a "trusted third party" is a Kerberos KDC which does in fact directly share credentials with all enrolled principals (human users, hosts or applications). -- to 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, 21 Apr 2005 04:57:47 +0000 Date: Wed, 20 Apr 2005 21:57:07 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Reminder to draft authors and editors: new boilerplate Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear WG, Just as a reminder, there's new boilerplate available for the updated BCP 78 and 79 about IETF rights in contributions and IPR considerations Please make sure that you're familiar with the new versions, and start to use the new boilerplate. The new format will be mandatory next month sometime, so please start preparing for the changes now, as you get ready to submit new drafts of documents. If you're using xml2rfc, there's a new version of the tool which provides this now (1.29). http://xml.resource.org/ -- to 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, 20 Apr 2005 17:11:16 +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 : [RADIUS location attributes] support of a location identifier in location-information attribute Date: Wed, 20 Apr 2005 19:10:33 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB02602236299@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [RADIUS location attributes] support of a location identifier in location-information attribute Thread-Index: AcVEANjta9RnaIwQTpuXPphMo6tWtABySzTA From: "MORAND Lionel RD-CORE-ISS" To: "Tschofenig Hannes" , Cc: Hi Hannes, I precise that it would be not necessary to define the exact format of = the information contained in the Location-Info field. By manual = configuration, the sender will know how to fill this field and the = receiver will know how to process the received information. I insist on = the fact that such a mechanism would be useful between a NAS and a = RADIUS server from the same administrative domain if the RADIUS client = was not able to provide explicit location information, that is likely = to be frequent ;) BR, Lionel > -----Message d'origine----- > De : Tschofenig Hannes [mailto:hannes.tschofenig@siemens.com]=20 > Envoy=E9 : lundi 18 avril 2005 12:22 > =C0 : MORAND Lionel RD-CORE-ISS; avi@bridgewatersystems.com > Cc : radiusext@ops.ietf.org > Objet : AW: [RADIUS location attributes] support of a=20 > location identifier in location-information attribute >=20 >=20 > hi lionel,=20 >=20 > i remember that you have proposed this feature already once.=20 >=20 > is someone else in favor of this approach?=20 > i don't want to add new functionality based the opinion of a=20 > few individuals only (particularly if the functionality is=20 > not really necessary). >=20 > ciao > hannes >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: MORAND Lionel RD-CORE-ISS > > [mailto:lionel.morand@francetelecom.com]=20 > > Gesendet: Montag, 18. April 2005 10:34 > > An: Tschofenig Hannes; avi@bridgewatersystems.com > > Cc: radiusext@ops.ietf.org > > Betreff: [RADIUS location attributes] support of a location=20 > > identifier in location-information attribute > >=20 > >=20 > > Hi Hannes, > >=20 > > The actuel design of the location-information attribute > > allows to convey > > location objects as defined by GEOPRIV, either civic or geospatial > > location information. > > I agree that this fulfil the GEOPRIV requirements but what=20 > about some > > "location ID" that could be sent to the AAA server to=20 > > retrieve location > > info? I mean that the location info attribute may convey=20 > > either explicit > > ("self-explicit") location information or any identifier if=20 > there is a > > mean for the receiver to extract explicit information from=20 > > this ID, such > > as the CellID in GSM.=20 > > Moreover, it could be seen as a complement of the global design: > > 1)if the NAS is not able to provide an explicit location,=20 > the NAS can > > provide the local RADIUS server with the location ID (any identifier > > related to the access network) in the location-information=20 > attribute; > > 2)the local RADIUS server performs the mapping between=20 > identifier and > > location; > > 3)the local server inserts the extracted information in a new > > location-information attribute in the Access-Request sent to=20 > > the remote > > RADIUS server. > >=20 > > It is therefore proposed to allocate a new code value (2),=20 > defined for=20 > > location identifiers carried in location-information attributes. > >=20 > > Lionel > >=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: Wed, 20 Apr 2005 01:05:20 +0000 Message-Id: <200504200105.j3K158b4026188@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Martin Soukup'" , "'Alper Yegin'" , "'Tschofenig Hannes'" , "'Sam Hartman'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 19 Apr 2005 18:05:08 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0105_01C5450A.536B7D30" Thread-Index: AcVFQf0DNcDTzu21TECheNQntFb3/QAAj+3w This is a multi-part message in MIME format. ------=_NextPart_000_0105_01C5450A.536B7D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I definitely look at RADIUS as a trusted third party:=20 Parties involved:=20 - authenticating entity (user/application)=20 - authenticator/policy enforcement point (device)=20 - authoritative authentication source/policy decision point (RADIUS) In order for a "trusted third party" in the technical sense to exist, the other two parties need to a) know about its existence and b) trust it. Does the "authenticating entity" know about the RADIUS server? =20 Martin.=20 > -----Original Message-----=20 > From: Alper Yegin [mailto:alper.yegin@samsung.com]=20 > Sent: April 19, 2005 8:29 PM=20 > To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20 > Soukup, Martin [CAR:5K50:EXCH]=20 > Cc: isms@ietf.org; radiusext@ops.ietf.org; eap@frascone.com=20 > Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party=20 >=20 >=20 > Glen,=20 >=20 > > > what is radius for you? (you write that it is not a trusted third=20 > > > party.)=20 > >=20 > > It's not. From the point of view of authentication protocols (PAP,=20 > > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires":=20 >=20 > What happens when we look at this picture from the=20 > "authorization" perspective? "Host-to-NAS authorization for=20 > the network access service" is dynamically generated from=20 > "host-to-AAA server" authorization and "AAA server to client=20 > (NAS)" authorization. Wouldn't this constitute a 3-party model?=20 >=20 > Alper=20 >=20 >=20 > > the=20 > > operation of the auth protocols should be exactly the same=20 > as if they=20 > > terminated in the AAA client, instead of elsewhere. Basically, the=20 > > purpose of AAA (again, from the POV of an authentication=20 > > protocol) is simply scaling. BTW, a lot of misery has been=20 > caused by=20 > > the erroneous belief that EAP is (or can be) a three-party=20 > > authentication protocol: it isn't, and can't be. It could=20 > _carry_ a=20 > > three-party protocol (like Kerberos), but EAP in itself is=20 > a two-party=20 > > protocol.=20 > >=20 > > > why do you care that only one party knows that radius is used? it=20 > > > could also be diameter.=20 > > >=20 > > > i would like to better understand why some people dislike the aaa=20 > > > architecture (radius, diameter).=20 > >=20 > > I think that the misunderstanding mentioned above might=20 > have something=20 > > to do with it...=20 > >=20 > > >=20 > > > ciao=20 > > > hannes=20 > > >=20 > > >=20 > > >> -----Urspr=FCngliche Nachricht-----=20 > > >> Von: isms-bounces@lists.ietf.org=20 > > >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman=20 > > >> Gesendet: Freitag, 15. April 2005 19:34=20 > > >> An: Martin Soukup=20 > > >> Cc: isms@ietf.org=20 > > >> Betreff: [Isms] RADIUS is not a trusted third party=20 > > >>=20 > > >>=20 > > >>>>>>> "Martin" =3D=3D Martin Soukup writes:=20 > > >>=20 > > >> Martin> RADIUS "Access-Accept" indicates a successful=20 > > >> Martin> authenthentication response for a user.=20 > > >>=20 > > >> Martin> The Access-Accept already returns a=20 > > "Session-Timeout",=20 > > >> Martin> defined as "Sets the maximum number of seconds of > > service=20 > > >> Martin> to be provided to the user before the session=20 > > >> Martin> terminates. This attribute value becomes the per-user=20 > > >> Martin> "absolute timeout."".=20 > > >>=20 > > >> This only tells the SNMP engine talking to the RADIUS server the=20 > > >> timeout. You need to tell the other side of the exchange the > > >> timeout too.=20 > > >>=20 > > >> Remember that RADIUS is a callout service; it is not a trusted=20 > > third=20 > > >> party. In other words, in a particular SNMP authentication, only=20 > > one=20 > > >> of the parties will know that RADIUS is being used.=20 > > >>=20 > > >>=20 > > >> _______________________________________________=20 > > >> Isms mailing list=20 > > >> Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20 > > >>=20 > > >=20 > > > _______________________________________________=20 > > > Isms mailing list=20 > > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms=20 > >=20 > > Hope this helps,=20 > >=20 > > ~gwz=20 > >=20 > > Why is it that most of the world's problems can't be solved=20 > by simply=20 > > listening to John Coltrane? -- Henry Gabriel=20 > > _______________________________________________=20 > > eap mailing list=20 > > eap@frascone.com=20 > > http://mail.frascone.com/mailman/listinfo/eap=20 >=20 >=20 >=20 >=20 ------=_NextPart_000_0105_01C5450A.536B7D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [eap] RE: [Isms] RADIUS is not a trusted third = party
I definitely look at RADIUS = as a trusted=20 third party:

Parties involved:

- authenticating entity (user/application) =
- authenticator/policy enforcement point (device) =
- authoritative authentication source/policy decision point=20 (RADIUS)  

In order=20 for a "trusted third party" in the technical sense to exist, the other = two=20 parties need to a) know about its existence and b) trust it.  = Does the=20 "authenticating entity" know=20 about the RADIUS server? 

Martin.

> -----Original Message-----
>=20 From: Alper Yegin [mailto:alper.yegin@samsung.com]=20
> Sent: April 19, 2005 8:29 PM =
> To: gwz@cisco.com; 'Tschofenig Hannes'; 'Sam Hartman';=20
> Soukup, Martin [CAR:5K50:EXCH] =
> Cc: isms@ietf.org; radiusext@ops.ietf.org; = eap@frascone.com=20
> Subject: RE: [eap] RE: [Isms] RADIUS is not a = trusted=20 third party
>
>=20
> Glen,
> =
> > > what is radius for you? (you write that it is = not a=20 trusted third
> > > party.) =
> >
> > It's not.  = >From the=20 point of view of authentication protocols (PAP,
>=20 > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": =
>
> What happens when = we look at=20 this picture from the
> "authorization" = perspective?=20 "Host-to-NAS authorization for
> the = network access=20 service" is dynamically generated from
> = "host-to-AAA=20 server" authorization and "AAA server to client
>=20 (NAS)" authorization. Wouldn't this constitute a 3-party model? =
>
> Alper
>=20
>
> > = the=20
> > operation of the auth protocols should be = exactly the=20 same
> as if they
> >=20 terminated in the AAA client, instead of elsewhere.  Basically, the =
> > purpose of AAA (again, from the POV = of an=20 authentication
> > protocol) is simply=20 scaling.  BTW, a lot of misery has been
> caused=20 by
> > the erroneous belief that EAP is = (or can=20 be) a three-party
> > authentication = protocol: it=20 isn't, and can't be.  It could
> = _carry_ a=20
> > three-party protocol (like = Kerberos), but EAP=20 in itself is
> a two-party
> > protocol.
> > =
> > > why do you care that only one party knows that = radius is=20 used? it
> > > could also be = diameter.=20
> > >
> > = > i would=20 like to better understand why some people dislike the aaa =
> > > architecture (radius, diameter). =
> >
> > I think that the=20 misunderstanding mentioned above might
> = have=20 something
> > to do with it... =
> >
> > > =
> > > ciao
> > > = hannes=20
> > >
> > = >=20
> > >> -----Urspr=FCngliche = Nachricht-----=20
> > >> Von: isms-bounces@lists.ietf.org=20
> > >> [mailto:isms-bounces@lists.iet= f.org]=20 Im Auftrag von Sam Hartman
> > >> = Gesendet:=20 Freitag, 15. April 2005 19:34
> > = >> An:=20 Martin Soukup
> > >> Cc:=20 isms@ietf.org
> > >> Betreff: = [Isms] RADIUS=20 is not a trusted third party
> > = >>=20
> > >>
> = >=20 >>>>>>> "Martin" =3D=3D Martin Soukup=20 <msoukup@nortel.com> writes:
> >=20 >>
> > = >>    =20 Martin> RADIUS "Access-Accept" indicates a successful =
> > >>     Martin> = authenthentication=20 response for a user.
> > >> =
> > >>     Martin> The = Access-Accept=20 already returns a
> > = "Session-Timeout",=20
> > >>     Martin> = defined=20 as "Sets the maximum number of seconds of
> = >=20 service
> > = >>    =20 Martin> to be provided to the user before the session =
> > >>     Martin> = terminates. This=20 attribute value becomes the per-user
> > = >>     Martin> "absolute timeout."". =
> > >>
> = > >>=20 This only tells the SNMP engine talking to the RADIUS server the=20
> > >> timeout.  You need to = tell the=20 other side of the exchange the
> > = >>=20 timeout too.
> > >> =
> > >> Remember that RADIUS is a callout service; = it is not a=20 trusted
> > third
>=20 > >> party.  In other words, in a particular SNMP = authentication,=20 only
> > one
> >=20 >> of the parties will know that RADIUS is being used. =
> > >>
> > = >>=20
> > >>=20 _______________________________________________
>=20 > >> Isms mailing list
> > = >>=20 Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms =
> > >>
> > = >=20
> > >=20 _______________________________________________
>=20 > > Isms mailing list
> > >=20 Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms =
> >
> > Hope this = helps,=20
> >
> > = ~gwz=20
> >
> > Why is = it that most=20 of the world's problems can't be solved
> = by=20 simply
> >   listening to John = Coltrane?=20 -- Henry Gabriel
> >=20 _______________________________________________
>=20 > eap mailing list
> > = eap@frascone.com=20
> > http://mail.frascone.com/mailman/listinfo/eap =
>
>
>=20
>

------=_NextPart_000_0105_01C5450A.536B7D30-- -- to 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, 20 Apr 2005 00:58:14 +0000 Message-Id: <200504200057.j3K0vhpR011434@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Alper Yegin'" , "'Tschofenig Hannes'" , "'Sam Hartman'" , "'Martin Soukup'" Cc: , , Subject: RE: [eap] RE: [Isms] RADIUS is not a trusted third party Date: Tue, 19 Apr 2005 17:57:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcVFQDWipq6remVqRn2sribJZkhV9wAAud7g Alper Yegin <> supposedly scribbled: > Glen, >=20 >>> what is radius for you? (you write that it is not a trusted third >>> party.) >>=20 >> It's not. From the point of view of authentication protocols (PAP, >> CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": >=20 > What happens when we look at this picture from the "authorization" > perspective? "Host-to-NAS authorization for the network access > service"=20 > is dynamically generated from "host-to-AAA server" authorization and > "AAA server to client (NAS)" authorization. Wouldn't this constitute > a 3-party model?=20 I'm pretty sure that both Sam & I were just talking about authentication. In any case, could you expound a bit? I don't actually know what you're talking about. What do "Host-to-NAS authorization for the network access service", "host-to-AAA server authorization" and "AAA server to client (NAS) authorization" mean? Are you saying that somehow the host authorizes the NAS to provide it network access? >=20 > Alper >=20 >=20 >> the >> operation of the auth protocols should be exactly the same as if they >> terminated in the AAA client, instead of elsewhere. Basically, the >> purpose of AAA (again, from the POV of an authentication >> protocol) is simply scaling. BTW, a lot of misery has been caused by >> the erroneous belief that EAP is (or can be) a three-party >> authentication protocol: it isn't, and can't be. It could _carry_ a >> three-party protocol (like Kerberos), but EAP in itself is a >> two-party protocol.=20 >>=20 >>> why do you care that only one party knows that radius is used? it >>> could also be diameter.=20 >>>=20 >>> i would like to better understand why some people dislike the aaa >>> architecture (radius, diameter). >>=20 >> I think that the misunderstanding mentioned above might have >> something to do with it...=20 >>=20 >>>=20 >>> ciao >>> hannes >>>=20 >>>=20 >>>> -----Urspr=FCngliche Nachricht----- >>>> Von: isms-bounces@lists.ietf.org >>>> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman >>>> Gesendet: Freitag, 15. April 2005 19:34 >>>> An: Martin Soukup >>>> Cc: isms@ietf.org >>>> Betreff: [Isms] RADIUS is not a trusted third party >>>>=20 >>>>=20 >>>>>>>>> "Martin" =3D=3D Martin Soukup writes: >>>>=20 >>>> Martin> RADIUS "Access-Accept" indicates a successful >>>> Martin> authenthentication response for a user. >>>>=20 >>>> Martin> The Access-Accept already returns a "Session-Timeout", >>>> Martin> defined as "Sets the maximum number of seconds of >>>> service Martin> to be provided to the user before the session >>>> Martin> terminates. This attribute value becomes the per-user >>>> Martin> "absolute timeout."". >>>>=20 >>>> This only tells the SNMP engine talking to the RADIUS server the >>>> timeout. You need to tell the other side of the exchange the >>>> timeout too.=20 >>>>=20 >>>> Remember that RADIUS is a callout service; it is not a trusted >>>> third party. In other words, in a particular SNMP authentication, >>>> only one of the parties will know that RADIUS is being used. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Isms mailing list >>>> Isms@lists.ietf.org >>>> https://www1.ietf.org/mailman/listinfo/isms >>>>=20 >>>=20 >>> _______________________________________________ >>> Isms mailing list >>> Isms@lists.ietf.org >>> https://www1.ietf.org/mailman/listinfo/isms >>=20 >> Hope this helps, >>=20 >> ~gwz >>=20 >> Why is it that most of the world's problems can't be solved by simply >> listening to John Coltrane? -- Henry Gabriel >> _______________________________________________ >> eap mailing list >> eap@frascone.com >> http://mail.frascone.com/mailman/listinfo/eap >=20 >=20 > _______________________________________________ > eap mailing list > eap@frascone.com > http://mail.frascone.com/mailman/listinfo/eap Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 19 Apr 2005 09:01:49 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C544BA.A3077A2F" Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Date: Tue, 19 Apr 2005 11:34:43 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D167750@esebe100.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Thread-Index: AcVD/9Rmim5rW+UuSPeKcgZyO1kqwQAAMA7AAAB4jXAAAC928AAA3IvrACzITcA= From: To: , , Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C544BA.A3077A2F Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable So, a few points: =20 This draft should say that because Diameter Base inherits the RADIUS = code space, this is applicable for Diameter. Section 4.1 of RFC 3588 says: AVP Code The AVP Code, combined with the Vendor-Id field, identifies the attribute uniquely. AVP numbers 1 through 255 are reserved for backward compatibility with RADIUS, without setting the Vendor-Id field. AVP numbers 256 and above are used for Diameter, which are allocated by IANA (see Section 11.1). Maybe some text should be added so readers know that. =20 Some text about using NASREQ for protocol translation could be added, in = addition to what is there already. Additionally, I think that the IANA considerations should also request = that IANA update the Diameter registry with this info as well. John -----Original Message----- From: ext [mailto:jouni.korhonen@teliasonera.com] Sent: 18 April, 2005 14:16 To: Loughney John (Nokia-NRC/Helsinki); lionel.morand@francetelecom.com; = jari.arkko@kolumbus.fi Cc: aaa-wg@merit.edu; radiusext@ops.ietf.org Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in = Diameter Hi John, Lionel & Jari, I would assume that the concerns are because in 3GPP we do also have the Diameter-Diameter case without any translation. The text below and the draft does not address that case. Cheers, Jouni -----Original Message----- From: owner-radiusext@ops.ietf.org on behalf of = john.loughney@nokia.com Sent: Mon 4/18/2005 1:42 PM To: lionel.morand@francetelecom.com; jari.arkko@kolumbus.fi Cc: aaa-wg@merit.edu; radiusext@ops.ietf.org Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes = in Diameter Hi Lionel, > The following statement is not enough? > > 8. Diameter RADIUS Interoperability > > In deployments where RADIUS clients talk with DIAMETER servers or > DIAMETER clients talk with RADIUS servers then a translation agent > will be deployed and operate in accordance to the NASREQ > specification [14]. That was what I was wondering. Some of the people who queried me about = this thought it wasn't enough; that's why I am checking with the rest of the WG. 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: < http://psg.com/lists/radiusext/> ------_=_NextPart_001_01C544BA.A3077A2F Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in = Diameter
So, a=20 few points:
 
This=20 draft should say that because Diameter Base inherits the RADIUS code = space, this=20 is applicable
for=20 Diameter.  Section 4.1 of RFC 3588 says:
   AVP Code
      The AVP Code, combined with the Vendor-Id field, identifies the
      attribute uniquely.  AVP numbers 1 through 255 are reserved for
      backward compatibility with RADIUS, without setting the Vendor-Id
      field.  AVP numbers 256 and above are used for Diameter, which are
      allocated by IANA (see Section 11.1).
Maybe some text should be added so readers know that.  =

Some text about using NASREQ =
for protocol translation could be added, in addition to what is there =
already.
Additionally, I think that the =
IANA considerations should also request that IANA update the Diameter =
registry
with this info as =
well.
John
 -----Original=20 Message-----
From: ext=20 [mailto:jouni.korhonen@teliasonera.com]
Sent: 18 April, 2005 = 14:16
To: Loughney John (Nokia-NRC/Helsinki);=20 lionel.morand@francetelecom.com; jari.arkko@kolumbus.fi
Cc:=20 aaa-wg@merit.edu; radiusext@ops.ietf.org
Subject: RE: RE : = [AAA-WG]:=20 Support for Geopriv RADIUS attributes in = Diameter

Hi John, Lionel & Jari,

I would assume = that the=20 concerns are because in 3GPP we do also
have the Diameter-Diameter = case=20 without any translation. The text
below and the draft does not = address that=20 case.

Cheers,
      =20 Jouni


-----Original Message-----
From:  =20 owner-radiusext@ops.ietf.org on behalf of=20 john.loughney@nokia.com
Sent:   Mon 4/18/2005 1:42=20 PM
To:     lionel.morand@francetelecom.com;=20 jari.arkko@kolumbus.fi
Cc:     = aaa-wg@merit.edu;=20 = radiusext@ops.ietf.org
Subject:      &nb= sp;=20 RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in = Diameter
Hi=20 Lionel,

> The following statement is not = enough?
>
>=20 8.  Diameter RADIUS = Interoperability
>
>    In=20 deployments where RADIUS clients talk with DIAMETER servers=20 or
>    DIAMETER clients talk with RADIUS servers = then a=20 translation agent
>    will be deployed and = operate in=20 accordance to the NASREQ
>    specification=20 [14].

That was what I was wondering.  Some of the people = who=20 queried me about this
thought it wasn't enough; that's why I am = checking=20 with the rest of the
WG.

John

--
to unsubscribe = send a=20 message to radiusext-request@ops.ietf.org with
the word = 'unsubscribe' in a=20 single line as the message text body.
archive: <http://psg.com/lists/radiusext/<= /A>>

------_=_NextPart_001_01C544BA.A3077A2F-- -- to 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, 18 Apr 2005 12:35:38 +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 : [RADIUS location attributes] Minor comment on Operator-type attribute Date: Mon, 18 Apr 2005 14:35:00 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026021F120A@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [RADIUS location attributes] Minor comment on Operator-type attribute Thread-Index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEwHzYCEcAAHUyVoAAGHv8jAAFh9PA= From: "MORAND Lionel RD-CORE-ISS" To: , , Cc: Hi Youni, Yes of course! I just want to align the name of this attribute with the = provided definition: Operator-Type: The Operator-Type field is four octets and identifies the namespace associated with the Operator-Name attribute. It is then a namespace that is indicated in this attribute and not an = operator type. According to this proposal, I would propose the following revisions: Change 1: 5.1 Operator-Namespace Attribute This attribute identifies the namespace in which the operator name provided in the Operator-Name attribute is uniquely = identified. The attribute value is a four octet integer. This document defines three values for this attribute: - The value 1 (GSM), which can be used to indicate operator names = based on GSMA TADIG codes. The TADIG Working Group within the GSM = Association is the authority responsible for issuing unique Operator-Name values for operators of this namespace. - The value 2 (CDMA), which can be used to indicate operator names = based on the Home Network Identifier (HNI). The HNI is the concatenation of the 3-digit Mobile Country Code (MCC) and 3-digit Mobile Network Code (MNC). The IMSI Oversight Council (IOC) is the authority responsible for issuing unique Operator-Name values for operators of this namespace. - The value 3 (REALM), which can be used to indicate operator names = based on any registered domain name. The Internet Assigned Numbers Authority (IANA) or registered delegate is the authority responsible for issuing unique Operator-Name values for operators of this = namespace. Additional values require an IANA registration and MUST be associated = with an organization responsible for assigning/managing the operator = names. Change 2: 9.1 Operator-Namespace Attribute The Operator-Namespace attribute SHOULD be sent in Access-Request, = and Accounting-Request packets where the Acc-Status-Type is set to Start, Interim, or Stop. If this attribute is present, the Operator-Name attribute MUST also be present in the packet. A summary of the Operator-Type Attribute is shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Operator-Namespace +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Operator-Type (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: To Be Assigned by IANA - Operator-Namespace Length: 6 Operator-Namespace: The Operator-Namespace field is four octets and identifies the namespace associated with the Operator-Name attribute. # Namespace --- --------- 1 GSM 2 CDMA 3 REALM Change 3: Replace "Operator-Type" by "Operator-Namespace" in the whole = text. BR, Lionel > -----Message d'origine----- > De : jouni.korhonen@teliasonera.com=20 > [mailto:jouni.korhonen@teliasonera.com]=20 > Envoy=E9 : lundi 18 avril 2005 13:54 > =C0 : MORAND Lionel RD-CORE-ISS; Hannes.Tschofenig@siemens.com;=20 > avi@bridgewatersystems.com > Cc : radiusext@ops.ietf.org > Objet : RE: [RADIUS location attributes] Minor comment on=20 > Operator-type attribute >=20 >=20 >=20 > Lionel, >=20 > Just for my clarification.. Your proposed change would still=20 > allow delegating the control and management of certain=20 > namespace to the some organization of choice e.g. to GSMA, right? >=20 > Cheers, > Jouni >=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org on behalf of MORAND Lionel=20 > RD-CORE-ISS > Sent: Mon 4/18/2005 11:45 AM > To: Hannes Tschofenig; avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org > Subject: [RADIUS location attributes] Minor comment on=20 > Operator-type attribute > Hi Hannes, >=20 > As explained during the last RADEXT meeting, I would prefer=20 > to remove the wording "Operator-Type" and replace by=20 > "Operator-Namespace". This attrbute doesn't define anymore=20 > the operator's type but in which namespace its name is=20 > defined. I wouldn't like to see any confusion between the=20 > name used by an operator (e.g. France Telecom) and the=20 > operator's type (ISP, telco, mobile, fixed, or whatever). >=20 > Lionel >=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 >=20 >=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: Mon, 18 Apr 2005 11:54:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: [RADIUS location attributes] Minor comment on Operator-type attribute Date: Mon, 18 Apr 2005 14:53:44 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A31FE8C20@FITMS201MB.tcad.telia.se> Thread-Topic: [RADIUS location attributes] Minor comment on Operator-type attribute thread-index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEwHzYCEcAAHUyVoAAGHv8j From: To: , , Cc: Lionel, Just for my clarification.. Your proposed change would still allow delegating the control and management of certain namespace to the some organization of choice e.g. to GSMA, right? Cheers, Jouni -----Original Message----- From: owner-radiusext@ops.ietf.org on behalf of MORAND Lionel = RD-CORE-ISS Sent: Mon 4/18/2005 11:45 AM To: Hannes Tschofenig; avi@bridgewatersystems.com Cc: radiusext@ops.ietf.org Subject: [RADIUS location attributes] Minor comment on Operator-type = attribute Hi Hannes, As explained during the last RADEXT meeting, I would prefer to remove the wording "Operator-Type" and replace by "Operator-Namespace". This attrbute doesn't define anymore the operator's type but in which namespace its name is defined. I wouldn't like to see any confusion between the name used by an operator (e.g. France Telecom) and the operator's type (ISP, telco, mobile, fixed, or whatever). Lionel -- to 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, 18 Apr 2005 11:16:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Date: Mon, 18 Apr 2005 14:15:49 +0300 Message-ID: <07B14A720C46C344AC96AAA64F5D6A31FE8C1D@FITMS201MB.tcad.telia.se> Thread-Topic: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter thread-index: AcVD/9Rmim5rW+UuSPeKcgZyO1kqwQAAMA7AAAB4jXAAAC928AAA3Ivr From: To: , , Cc: , Hi John, Lionel & Jari, I would assume that the concerns are because in 3GPP we do also have the Diameter-Diameter case without any translation. The text below and the draft does not address that case. Cheers, Jouni -----Original Message----- From: owner-radiusext@ops.ietf.org on behalf of john.loughney@nokia.com Sent: Mon 4/18/2005 1:42 PM To: lionel.morand@francetelecom.com; jari.arkko@kolumbus.fi Cc: aaa-wg@merit.edu; radiusext@ops.ietf.org Subject: RE: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in = Diameter Hi Lionel, > The following statement is not enough? >=20 > 8. Diameter RADIUS Interoperability >=20 > In deployments where RADIUS clients talk with DIAMETER servers or > DIAMETER clients talk with RADIUS servers then a translation agent > will be deployed and operate in accordance to the NASREQ > specification [14]. That was what I was wondering. Some of the people who queried me about = this thought it wasn't enough; that's why I am checking with the rest of the WG. 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: Mon, 18 Apr 2005 10:48: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: RE : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Date: Mon, 18 Apr 2005 13:42:20 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D0D8CE3@esebe100.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Thread-Index: AcVD/9Rmim5rW+UuSPeKcgZyO1kqwQAAMA7AAAB4jXAAAC928A== From: To: , Cc: , Hi Lionel, > The following statement is not enough? >=20 > 8. Diameter RADIUS Interoperability >=20 > In deployments where RADIUS clients talk with DIAMETER servers or > DIAMETER clients talk with RADIUS servers then a translation agent > will be deployed and operate in accordance to the NASREQ > specification [14]. That was what I was wondering. Some of the people who queried me about = this thought it wasn't enough; that's why I am checking with the rest of the WG. 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: Mon, 18 Apr 2005 10:37:22 +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 : [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Date: Mon, 18 Apr 2005 12:37:02 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026021F1150@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Thread-Index: AcVD/9Rmim5rW+UuSPeKcgZyO1kqwQAAMA7AAAB4jXA= From: "MORAND Lionel RD-CORE-ISS" To: , Cc: , Hi John, The following statement is not enough? 8. Diameter RADIUS Interoperability In deployments where RADIUS clients talk with DIAMETER servers or DIAMETER clients talk with RADIUS servers then a translation agent will be deployed and operate in accordance to the NASREQ specification [14]. > -----Message d'origine----- > De : owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] De la part de=20 > john.loughney@nokia.com > Envoy=E9 : lundi 18 avril 2005 12:24 > =C0 : jari.arkko@kolumbus.fi > Cc : aaa-wg@merit.edu; radiusext@ops.ietf.org > Objet : RE: [AAA-WG]: Support for Geopriv RADIUS attributes=20 > in Diameter >=20 >=20 > Hi Jari, >=20 > > I'd prefer the NASREQ approach. >=20 > I think that would be reasonable. Do you think that this=20 > should be written-up=20 > anywhere? Should I try to supply some text for the geopriv draft? >=20 > John >=20 > > john.loughney@nokia.com wrote: > >=20 > > >Hi all, > > > > > >I've gotten some queries, off-list, about how 3GPP should > > handle the location > > >AVPs that are defined in: > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius > > -lo-02.txt > > > > > >3GPP has defined the Wa interface, which is based on > > Diameter, that will > > >interwork with RADIUS and will carry the RADIUS AVPs. =20 > Would standard=20 > > >NASREQ rules apply here (Diameter would just re-use the > > RADIUS codes), or > > >should these AVPs also be defined in a seperate Diameter draft? > > > > > >The draft above is quite weak on how these attributes should > > be handled > > >in Diameter, so I wanted to see what both the AAA WG and RADEXT WG > > >thought. > > > > > >John > > > > > > =20 > > > > >=20 > > =20 > >=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: Mon, 18 Apr 2005 10:24:51 +0000 Message-ID: From: Tschofenig Hannes To: MORAND Lionel RD-CORE-ISS , avi@bridgewatersystems.com Cc: radiusext@ops.ietf.org Subject: AW: [RADIUS location attributes] support of a location identifier in location-information attribute Date: Mon, 18 Apr 2005 12:22:12 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi lionel,=20 i remember that you have proposed this feature already once.=20 is someone else in favor of this approach?=20 i don't want to add new functionality based the opinion of a few = individuals only (particularly if the functionality is not really necessary). ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: MORAND Lionel RD-CORE-ISS=20 > [mailto:lionel.morand@francetelecom.com]=20 > Gesendet: Montag, 18. April 2005 10:34 > An: Tschofenig Hannes; avi@bridgewatersystems.com > Cc: radiusext@ops.ietf.org > Betreff: [RADIUS location attributes] support of a location=20 > identifier in location-information attribute >=20 >=20 > Hi Hannes, >=20 > The actuel design of the location-information attribute=20 > allows to convey > location objects as defined by GEOPRIV, either civic or geospatial > location information. > I agree that this fulfil the GEOPRIV requirements but what about some > "location ID" that could be sent to the AAA server to=20 > retrieve location > info? I mean that the location info attribute may convey=20 > either explicit > ("self-explicit") location information or any identifier if there is = a > mean for the receiver to extract explicit information from=20 > this ID, such > as the CellID in GSM.=20 > Moreover, it could be seen as a complement of the global design: > 1)if the NAS is not able to provide an explicit location, the NAS can > provide the local RADIUS server with the location ID (any identifier > related to the access network) in the location-information attribute; > 2)the local RADIUS server performs the mapping between identifier and > location; > 3)the local server inserts the extracted information in a new > location-information attribute in the Access-Request sent to=20 > the remote > RADIUS server. >=20 > It is therefore proposed to allocate a new code value (2), defined = for > location identifiers carried in location-information attributes. >=20 > Lionel >=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, 18 Apr 2005 10:24:50 +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: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Date: Mon, 18 Apr 2005 13:23:48 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D0D8CC8@esebe100.NOE.Nokia.com> Thread-Topic: [AAA-WG]: Support for Geopriv RADIUS attributes in Diameter Thread-Index: AcVD/9Rmim5rW+UuSPeKcgZyO1kqwQAAMA7A From: To: Cc: , Hi Jari, > I'd prefer the NASREQ approach. I think that would be reasonable. Do you think that this should be = written-up=20 anywhere? Should I try to supply some text for the geopriv draft? John > john.loughney@nokia.com wrote: >=20 > >Hi all, > > > >I've gotten some queries, off-list, about how 3GPP should=20 > handle the location=20 > >AVPs that are defined in: > > > >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius > -lo-02.txt > > > >3GPP has defined the Wa interface, which is based on=20 > Diameter, that will > >interwork with RADIUS and will carry the RADIUS AVPs. Would standard > >NASREQ rules apply here (Diameter would just re-use the=20 > RADIUS codes), or > >should these AVPs also be defined in a seperate Diameter draft? > > > >The draft above is quite weak on how these attributes should=20 > be handled > >in Diameter, so I wanted to see what both the AAA WG and RADEXT WG=20 > >thought. > > > >John > > > > =20 > > >=20 > =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: Mon, 18 Apr 2005 10:19:27 +0000 Message-ID: From: Tschofenig Hannes To: MORAND Lionel RD-CORE-ISS , avi@bridgewatersystems.com Cc: radiusext@ops.ietf.org Subject: AW: [RADIUS location attributes] Minor comment on Operator-type a ttribute Date: Mon, 18 Apr 2005 12:16:46 +0200 MIME-Version: 1.0 Content-Type: text/plain hi lionel, i like your proposal. thanks. ciao hannes > Hi Hannes, > > As explained during the last RADEXT meeting, I would prefer to remove > the wording "Operator-Type" and replace by "Operator-Namespace". This > attrbute doesn't define anymore the operator's type but in which > namespace its name is defined. I wouldn't like to see any confusion > between the name used by an operator (e.g. France Telecom) and the > operator's type (ISP, telco, mobile, fixed, or whatever). > > Lionel > -- to 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, 18 Apr 2005 10:10: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: Support for Geopriv RADIUS attributes in Diameter Date: Mon, 18 Apr 2005 13:05:49 +0300 Message-ID: <1AA39B75171A7144A73216AED1D7478D0D8CB8@esebe100.NOE.Nokia.com> Thread-Topic: Support for Geopriv RADIUS attributes in Diameter Thread-Index: AcVD/jF/zpFyItByRKWYLWFTCOhPZQ== From: To: , Hi all, I've gotten some queries, off-list, about how 3GPP should handle the = location=20 AVPs that are defined in: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-02.txt 3GPP has defined the Wa interface, which is based on Diameter, that will interwork with RADIUS and will carry the RADIUS AVPs. Would standard NASREQ rules apply here (Diameter would just re-use the RADIUS codes), = or should these AVPs also be defined in a seperate Diameter draft? The draft above is quite weak on how these attributes should be handled in Diameter, so I wanted to see what both the AAA WG and RADEXT WG=20 thought. 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: Mon, 18 Apr 2005 08:45: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: [RADIUS location attributes] Minor comment on Operator-type attribute Date: Mon, 18 Apr 2005 10:45:40 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026021F107D@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [RADIUS location attributes] Minor comment on Operator-type attribute Thread-Index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEwHzYCEcAAHUyVoA== From: "MORAND Lionel RD-CORE-ISS" To: "Hannes Tschofenig" , Cc: Hi Hannes, As explained during the last RADEXT meeting, I would prefer to remove the wording "Operator-Type" and replace by "Operator-Namespace". This attrbute doesn't define anymore the operator's type but in which namespace its name is defined. I wouldn't like to see any confusion between the name used by an operator (e.g. France Telecom) and the operator's type (ISP, telco, mobile, fixed, or whatever). Lionel -- to 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, 18 Apr 2005 08:34: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: [RADIUS location attributes] support of a location identifier in location-information attribute Date: Mon, 18 Apr 2005 10:33:34 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026021F105C@FTRDMEL2.rd.francetelecom.fr> Thread-Topic: [RADIUS location attributes] support of a location identifier in location-information attribute Thread-Index: AcTE+2bf+xE2cxhKTVmGRCyXJej64wBqQwEwHzYCEcA= From: "MORAND Lionel RD-CORE-ISS" To: "Hannes Tschofenig" , Cc: Hi Hannes, The actuel design of the location-information attribute allows to convey location objects as defined by GEOPRIV, either civic or geospatial location information. I agree that this fulfil the GEOPRIV requirements but what about some "location ID" that could be sent to the AAA server to retrieve location info? I mean that the location info attribute may convey either explicit ("self-explicit") location information or any identifier if there is a mean for the receiver to extract explicit information from this ID, such as the CellID in GSM.=20 Moreover, it could be seen as a complement of the global design: 1)if the NAS is not able to provide an explicit location, the NAS can provide the local RADIUS server with the location ID (any identifier related to the access network) in the location-information attribute; 2)the local RADIUS server performs the mapping between identifier and location; 3)the local server inserts the extracted information in a new location-information attribute in the Access-Request sent to the remote RADIUS server. It is therefore proposed to allocate a new code value (2), defined for location identifiers carried in location-information attributes. Lionel -- to 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, 17 Apr 2005 19:49:18 +0000 Date: Sun, 17 Apr 2005 12:48:55 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Tschofenig Hannes'" , "'Sam Hartman'" , "'Martin Soukup'" , isms@ietf.org, radiusext@ops.ietf.org Subject: RE: [Isms] RADIUS is not a trusted third party Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > It's not. From the point of view of authentication protocols (PAP, > CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the > operation of the auth protocols should be exactly the same as if > they terminated in the AAA client, instead of elsewhere. Basically, > the purpose of AAA (again, from the POV of an authentication > protocol) is simply scaling. BTW, a lot of misery has been caused > by the erroneous belief that EAP is (or can be) a three-party > authentication protocol: it isn't, and can't be. It could _carry_ a > three-party protocol (like Kerberos), but EAP in itself is a > two-party protocol. > > > why do you care that only one party knows that radius is > > used? it could also be diameter. > > > > i would like to better understand why some people dislike the aaa > > architecture (radius, diameter). > > I think that the misunderstanding mentioned above might have > something to do with it... As Glen said, EAP is a two-party protocol (run between EAP peer and server). RADIUS is also a two party protocol (between the authenticator and server). The system may also include a protocol run between the peer and authenticator (the Secure Association Protocol). An application has the flexibility to define new AAA attributes (e.g. Diameter EAP); to define requirements with respect to EAP methods (e.g. RFC 4017); and to define the Secure Association Protocol (e.g. 802.11i 4-way handshake). This flexibility is both a blessing and a curse. It is a blessing in that there is a lot of flexibility available to meet requirements if they are well defined. It is a curse because a key management application needs to do considerable work in defining and analyzing the security properties of the system in order to meet the security requirements described in RFC 4017 (the Housley Criteria). To enable analysis, the specification needs to detail the required AAA protocol and EAP method properties as well as to define the security properties of the Secure Association Protocol. The best existing example of this to date is probably IEEE 802.11i, but even that effort left out some important pieces. Note that the ISMS charter explicitly mentions RADIUS support: "Version 3 of the Simple Network Management Protocol (SNMPv3) was elevated to Internet Standard in late 2002 and added security to the previous versions of the protocol. Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. This is due primarily to two synchronization problems. The first is the addition of yet another authentication system specific to SNMPv3 that needs to be maintained across all networking devices. Most of these devices already contain local accounts and/or the ability to negotiate with authentication servers (e.g. RADIUS servers). However, SNMPv3 does not make use of these authentication mechanisms, and this causes additional synchronization burdens. The second issue found with deploying SNMPv3 is that distributing and maintaining View-based Access Control Model (VACM) rules is also difficult in large-scale environments." -- to 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, 17 Apr 2005 18:11:34 +0000 Message-Id: <200504171809.j3HI9spR022495@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Tschofenig Hannes'" , "'Sam Hartman'" , "'Martin Soukup'" Cc: , , Subject: RE: [Isms] RADIUS is not a trusted third party Date: Sun, 17 Apr 2005 11:09:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thread-Index: AcVDQB38XlEUMWIdSW+oZx+4HW0FIAAM+0kg Tschofenig Hannes <> supposedly scribbled: > hi sam, >=20 > you have intentionally chosen a provocative title for your mail. >=20 > you write: >=20 > " >> Remember that RADIUS is a callout service; it is not a trusted third >> party. In other words, in a particular SNMP authentication, only one >> of the parties will know that RADIUS is being used. " >=20 > what is a "callout service"? > what is radius for you? (you write that it is not a trusted third > party.)=20 It's not. From the point of view of authentication protocols (PAP, CHAP, EAP, etc.), both RADIUS and Diameter are just "wires": the operation of the auth protocols should be exactly the same as if they terminated in the AAA client, instead of elsewhere. Basically, the purpose of AAA (again, from the POV of an authentication protocol) is simply scaling. BTW, a lot of misery has been caused by the erroneous belief that EAP is (or can be) a three-party authentication protocol: it isn't, and can't be. It could _carry_ a three-party protocol (like Kerberos), but EAP in itself is a two-party protocol. > why do you care that only one party knows that radius is > used? it could also be diameter. =20 >=20 > i would like to better understand why some people dislike the aaa > architecture (radius, diameter).=20 I think that the misunderstanding mentioned above might have something to do with it... >=20 > ciao > hannes >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: isms-bounces@lists.ietf.org >> [mailto:isms-bounces@lists.ietf.org] Im Auftrag von Sam Hartman >> Gesendet: Freitag, 15. April 2005 19:34 >> An: Martin Soukup >> Cc: isms@ietf.org >> Betreff: [Isms] RADIUS is not a trusted third party >>=20 >>=20 >>>>>>> "Martin" =3D=3D Martin Soukup writes: >>=20 >> Martin> RADIUS "Access-Accept" indicates a successful >> Martin> authenthentication response for a user. >>=20 >> Martin> The Access-Accept already returns a "Session-Timeout", >> Martin> defined as "Sets the maximum number of seconds of service >> Martin> to be provided to the user before the session >> Martin> terminates. This attribute value becomes the per-user >> Martin> "absolute timeout."". >>=20 >> This only tells the SNMP engine talking to the RADIUS server the >> timeout. You need to tell the other side of the exchange the >> timeout too.=20 >>=20 >> Remember that RADIUS is a callout service; it is not a trusted third >> party. In other words, in a particular SNMP authentication, only one >> of the parties will know that RADIUS is being used. >>=20 >>=20 >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >>=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 15 Apr 2005 23:25:10 +0000 Date: Fri, 15 Apr 2005 16:24:40 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I see IPv6 attributes there, but not 64-bit *integers*. All of the existing 64 and 128-bit attributes are unsigned values. Here is a summary: Attribute RFC Size --------- --- ---- ARAP-Password RFC 2869 128 bits (4 32-bit quantities) NAS-IPv6-Address RFC 3162 128 bits Framed-Interface-Id RFC 3162 64 bits Login-IPv6-Host RFC 3162 128 bits As Avi mentioned, the bandwidth values would also be unsigned. So I think there is precedent for this. -- to 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, 15 Apr 2005 19:32:54 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt Cc: radiusext@ops.ietf.org Date: Fri, 15 Apr 2005 15:29:30 -0400 Message-Id: <20050415192930.7848016D00@mail.nitros9.org> Bernard Aboba wrote: > 64-bit attributes are already supported in existing RADIUS RFCs such as > RFC 3162. ? I see IPv6 attributes there, but not 64-bit *integers*. > I don't think you need a 64-bit processor to handle a 64-bit RADIUS > attribute. You will need a 64-bit aware compiler at least. Again, my concerns aren't show-stoppers, they're nit-picks. I just want to be clear that 64-bit integer support is *new*. > I think this makes sense. We should add this to "issues and fixes" > It will be trickier for RADIUS servers to require Message-Authenticator > for legacy applications, of course. I agree. Thanks. 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: Fri, 15 Apr 2005 17:46:22 +0000 Date: Fri, 15 Apr 2005 10:45:44 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: radiusext@ops.ietf.org Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > I'm not opposed to 64-bit attributes, but introducing them is a > major change to RADIUS. 64-bit attributes are already supported in existing RADIUS RFCs such as RFC 3162. > Not all platforms support 64-bit operations, > making *full* implementation of 64-bit attributes problematic. I don't think you need a 64-bit processor to handle a 64-bit RADIUS attribute. > My preference for the "issues & fixes" draft is to STRONGLY suggest > that all new implementations always add Message-Authenticator to the > packet. This avoids a number of attack vectors. I think this makes sense. We should add this to "issues and fixes" It will be trickier for RADIUS servers to require Message-Authenticator for legacy applications, of course. -- to 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, 15 Apr 2005 16:41:01 +0000 From: "Alan DeKok" To: Bernard Aboba Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt Cc: radiusext@ops.ietf.org Date: Fri, 15 Apr 2005 12:37:32 -0400 Message-Id: <20050415163732.D1F3D16CC4@mail.nitros9.org> Bernard Aboba wrote: > [BA] One thing to keep in mind is that bandwidth increases an order of > magnitude every 3 years. 10 terrabits might seem like a lot, but we are > at 10 Gbps now, and increasing by 3 orders of magnitude will only take a > decade. So my recommendation is to look at a 64-bit attribute. I'm not opposed to 64-bit attributes, but introducing them is a major change to RADIUS. Not all platforms support 64-bit operations, making 8full* implementation of 64-bit attributes problematic. That being said, hardware is cheap enough & compilers are smart enough that 64-bit support shouldn't be too problematic. > [BA] Are you saying that Message-Authenticator is required in an > Access-Request including bandwidth attributes? Today we require > Message-Authenticator for use with EAP & Digest, but not with legacy > mechanisms (PAP, CHAP). I guess this draft won't be used along with > legacy mechanisms, so perhaps this would be ok. My preference for the "issues & fixes" draft is to STRONGLY suggest that all new implementations always add Message-Authenticator to the packet. This avoids a number of attack vectors. 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: Fri, 15 Apr 2005 15:59:47 +0000 Date: Fri, 15 Apr 2005 08:59:36 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Re: Review of draft-lior-radius-bandwidth-capability-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > think of alternative scales such as Kbps, as well as a 64-bit > value instead of 32-bits. We agree. The bandwidth attribute should be specified as an integer in units of Kbps. This will give us 2^31 Kbps which is 2^34 bps or 10,000 Gbps. There is no need to send extra bits. We can even increase one order of magnitude by making it an unsigned integer. If need be we can also specify Kbytes instead of Kilobits. [BA] One thing to keep in mind is that bandwidth increases an order of magnitude every 3 years. 10 terrabits might seem like a lot, but we are at 10 Gbps now, and increasing by 3 orders of magnitude will only take a decade. So my recommendation is to look at a 64-bit attribute. > Also, the explanations of the attributes in Section 3 are > minimal. The RADIUS tradition is to explain the usage of the > attribute here (see RFC 2865) rather than writing a large > "architecture" section. Section 2 is not an architecture section. It defines the behavior. Section 3 describes the attributes. Having said that, we could trim back on the behavior and boaster up the attribute description. But please note that the attributes in by themselves are very simple. It's the behavior that is complex in this case. [BA] I guess I don't understand why the behavior is so complex. As I understand it, the goal here is to specify egress & ingress bandwidth limits for a client. Now those limits can be changed via RFC 3576, but this is a static adjustment, rather than a closed loop control system, correct? We agree that we need a better description here. We will take that as an action item to tighten that part of the protocol. [BA] My preference would be for the attribute to represent the rate negotiated with the client. For example, with 802.11g it might be anything from 1 Mbps to 54 Mbps. Or for Ethernet, anything from 10 Mbps to 10 Gbps. Note that the rate can change, so that the value in an Accounting Interim might be different from the value in the Accounting Start or STOP. No actually. We need to provide both the granted bandwidth and the measured octets in/out. [BA] So the value in the Access-Accept is merely being echo'd in the Accounting records? If so, that makes sense. Actually we messed up that section somewhat. We only need one value - either would work. [BA] OK. And really that value is a nice to have. Mid session changes to bandwidth are allowed (using COA) and MAY cause Acct Stop followed by Acct Start. [BA] Yes, an RFC 3576 CoA-Request can cause that. Having a reason in the Terminate Cause to indicate "session continue" helps the back systems understand that the session is not really going away. This may help some folks realize that the arrival of the Stop is not the end of the session. [BA] Can't Acct-Multi-Session-Id be used for that? For example, RFC 3580 suggests that this be used to link together sessions created as a result of a handoff. MITM lowering the values in the Access-Request potentially cause the operator to request lower bandwidth for the user. To protect against that we need to integrity protect the Access-Request. [BA] Are you saying that Message-Authenticator is required in an Access-Request including bandwidth attributes? Today we require Message-Authenticator for use with EAP & Digest, but not with legacy mechanisms (PAP, CHAP). I guess this draft won't be used along with legacy mechanisms, so perhaps this would be ok. MITM uping the request bandwidth causing a user to be billed for bandwidth that they didn't ask for. RADIUS already protects against this. -- to 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, 15 Apr 2005 15:26:04 +0000 Date: Fri, 15 Apr 2005 08:25:25 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on Digest Authentication Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG last call on the Digest Authentication draft prior to sending the document to the IESG for consideration as a Proposed Standard. Prior to showing up on the IETF Archive, the document is available for review here: http://www.drizzle.com/~aboba/RADEXT/draft-ietf-radext-digest-auth-02.txt Once it is posted to the IETF archive, the document will be available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-02.txt RADEXT WG last call will last until Friday, May 6, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the Issues 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: Wed, 13 Apr 2005 10:18:33 +0000 Message-ID: From: Avi Lior To: radiusext@ops.ietf.org, Bernard Aboba Cc: Avi Lior , "'Bari, Farooq'" , "'Adrangi, Farid'" , "'Congdon, Paul T (ProCurve)'" Subject: My replies to Bernards Comments Date: Wed, 13 Apr 2005 06:17:52 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Bernard, Thank you for taking the time to read and review the Bandwidth draft. Please see our comments inline. snip > Section 3 > > The Ingress and Egress Bandwidth attributes are defined as 32 > bit values expressing Bytes per second. Is this really the > right way to express bandwidth? This attribute has been > implemented in Metro Ethernet networks where bandwidth of 10+ > Gbps is available, and we are seeing an order of magnitude > increase every 3 years. I'd suggest that we might want to > think of alternative scales such as Kbps, as well as a 64-bit > value instead of 32-bits. We agree. The bandwidht attribute should be specified as an integer in units of Kbps. This will give us 2^31 Kbps which is 2^34 bps or 10,000 Gbps. There is no need to send extra bits. We can even increase one order of magnitude by making it an unsigned integer. If need be we can also specify Kbytes instead of Kilobits. > Also, the explanations of the attributes in Section 3 are > minimal. The RADIUS tradition is to explain the usage of the > attribute here (see RFC 2865) rather than writing a large > "architecture" section. Section 2 is not an architecture section. It defines the behavior. Section 3 describes the attributes. Having said that, we could trim back on the behavior and boaster up the attribute description. But please note that the attributes in by themselves are very simple. It's the behavior that is complex in this case. > While I'm fairly clear about the usage of the bw attributes > in Access-Accept, CoA-Request and Accounting-Request packets, > I am not as clear about the meaning in an Access-Request. In > that situation "bandwidth available" seems unclear to me. Is > this a measurement of the negotiated rate? Of the "slot > time" available to a station? Of the available throughput? > There are highly transient measurements. If we are looking > for flow data then there are better ways to get it. We agree that we need a better description here. We will take that as an action item to tighten that part of the protocol. > Similarly, in Accounting-Request packets I can see echoing the bw > values from the Access-Accept. But a dynamic measurement seems > redundant since we already support attributes for octets in/out. No actually. We need to provide both the granted bandwidth and the measured octets in/out. This is because if the user requests a certain bandwidth and that bandwidth is allocated then even though the user did not use the bandwidth, the operator may still want to bill them for the requested bandwidth. The operator is billing the user for providing the pipe. In fact many operators bill the user based solely on the bandwidth capability and not how much bandwidth they actually use. > Note 1 : If Ingress-Bandwidth appears alone in an Access-Request > packet then the NAS is indicating that it only supports > symmetric > bandwidth allocation. Therefore, Egress bandwidth SHOULD NOT > appear in the corresponding Access-Accept packet. > Note 2 : Bandwidth-Profile-Id MUST NOT appear in a RADIUS packet > that contains either or both of Ingress-Bandwidth or > Egress-Bandwidth attributes. > > The Note 1 seems to imply that putting bw attributes in an > Access-Request is for capability negotiation. Yes it is signalling that its only capable of doing symmetric. We are just trying to be complete here since there could be a case where a device is only capable of doing symmetric. > > Section 5 > > Why does this document require new vlues for Acct-Terminate-Cause? Actually we messed up that section somewhat. We only need one value - either would work. And really that value is a nice to have. Mid session changes to bandwidth are allowed (using COA) and MAY cause Acct Stop followed by Acct Start. Having a reason in the Terminate Cause to indicate "session continue" helps the back systems understand that the session is not really going away. This may help some folks realize that the arrival of the Stop is not the end of the session. Other SDOs have been including a VSA for that purpose -- for example a MIP handoff creates Stop Start records. It helps mediation process when this type of information is included. > Section 6 > > Surely there must be *some* security implications of these > attributes, no? It would be nice to get help here. Some things that come to mind: MITM lowering the values in the Access-Request potentially cause the operator to request lower bandwidth for the user. To protect against that we need to integrity protect the Access-Request. MITM uping the request bandwidth causing a user to be billed for bandwidth that they didn't ask for. RADIUS already protects against this. > -- > to 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, 12 Apr 2005 23:51:43 +0000 Date: Tue, 12 Apr 2005 19:51:25 -0400 From: Barney Wolff To: Greg Weber Cc: radiusext@ops.ietf.org Subject: Re: [q] CUI-04: NAS controlled? Message-ID: <20050412235125.GA21427@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.8i On Tue, Apr 12, 2005 at 07:30:19PM -0400, Greg Weber wrote: > > >From draft-ietf-radext-chargeable-user-id-04.txt Section 2.1: > > If a home RADIUS server that supports the CUI attribute receives an > Access-Request packet containing a CUI (set to nul or otherwise), it > MUST include the CUI attribute in the Access-Accept packet. > Otherwise, if the Access-Request packet does not contain a CUI, the > home RADIUS server MUST NOT include the CUI attribute in the > Access-Accept packet. > > Looking at the last sentence, that seems to mean that the server > cannot ever send CUI unless the NAS hints that it's desired. > Is that the intent? As you point out in the draft, the NAS can > ignore CUI if it doesn't understand it. It may be desirable to > not have the NAS send CUI in every request- even if the NAS > understands how to handle CUI. This seems to be an unnecessary > restriction on the server. We've been over this. 2865 allows ignoring unknown attributes, but does not mandate it. Since CUI is strictly for the benefit of the sender of the Access-Request, if the NAS or proxy doesn't demand it, the server has no reason to send it. -- Barney Wolff http://www.databus.com/bwresume.pdf I never met a computer I didn't like. -- to 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, 12 Apr 2005 23:30:34 +0000 From: Greg Weber Message-Id: <200504122330.TAA27214@cisco.com> Subject: [q] CUI-04: NAS controlled? To: radiusext@ops.ietf.org Date: Tue, 12 Apr 2005 19:30:19 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit >From draft-ietf-radext-chargeable-user-id-04.txt Section 2.1: If a home RADIUS server that supports the CUI attribute receives an Access-Request packet containing a CUI (set to nul or otherwise), it MUST include the CUI attribute in the Access-Accept packet. Otherwise, if the Access-Request packet does not contain a CUI, the home RADIUS server MUST NOT include the CUI attribute in the Access-Accept packet. Looking at the last sentence, that seems to mean that the server cannot ever send CUI unless the NAS hints that it's desired. Is that the intent? As you point out in the draft, the NAS can ignore CUI if it doesn't understand it. It may be desirable to not have the NAS send CUI in every request- even if the NAS understands how to handle CUI. This seems to be an unnecessary restriction on the server. Comments? Greg -- to 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, 12 Apr 2005 23:23:18 +0000 From: Greg Weber Message-Id: <200504122322.TAA26960@cisco.com> Subject: [Issue] Editorial cmts on CUI-04 To: radiusext@ops.ietf.org Date: Tue, 12 Apr 2005 19:22:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Editorial comments on CUI-04 Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: April 12, 2005 Reference: n/a Document: draft-ietf-radext-chargeable-user-id-04.txt Comment type: E Priority: 1 Section: various Rationale/Explanation of issue: Some editorial nits by section (S=Section, P=Paragraph) S1P5: "subscriber" and "user" seem to be used interchangably. Unless you mean something different by "subscriber", I suggest there would be less potential for confusion is you use "user" consistently. Otherwise, please explain the difference in meaning. S1.1P3: "Therfore" -> "Therefore" S2P1: There aren't really any references to or dependencies on RFC3576. Why not just remove this reference? S2.1P2: "may not choose to send" -> "may choose not to send" S2.2: In the ASCII art, the bit position numbers are not lined up with the diagram (off by one column). S4: The Diameter Considerations sections seems to place requirements on other documents. Isn't CUI available to Diameter applications as a RADIUS attribute? Why does another attribute need to be defined? Maybe the text of this section can be removed & just say that there are no particular Diameter considerations. S6P2: "clients)outside" -> "clients) outside" -- to 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, 12 Apr 2005 13:11:10 +0000 Date: Tue, 12 Apr 2005 06:10:07 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: [AAA-WG]: issue with expected response calculation (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII ---------- Forwarded message ---------- Date: Tue, 12 Apr 2005 14:26:05 +0200 From: Jo Hermans To: aaa-wg@merit.edu Subject: [AAA-WG]: issue with expected response calculation I have a problem with paragraph 8.5.6.1 in draft-ietf-aaa-diameter-sip-app-07 , 3th paragraph ("Please note that the expected response ...") The draft mentions that the expected response calculation can't be done when the SIP UA has sent a expected response based on client nonces. It then mentions that this is the case when the qop-parameter is present in the client request. That last part I don't understand. I though that H(A1) is dependent on the algorithm, not qop. Qop has only influence on the A2 and digest, which are both calculated in the Diameter Client (SIP Server). See also < http://danforsberg.info:8080/draft-ietf-aaa-diameter-sip/issue40> But even then I don't understand. I think that the Diameter Server does has the client-nonces available (they're in the SIP-Authorization AVP, and were used to calculate the request digest !)), and is able to calculate a H(A1). Even if MD5-sess was used, it could still calculate H(A1). MD5-sess also has the added advantage that H(A1) could only be used once, which is also the reason why draft-sterman-aaa-sip-04.txt doesn't want to use MD5 unless the message is protected against eavesdropping. I agree that if qop is missing and algorithm is MD5, client-nonces aren't used at all (backwards compatibility with RFC2069). H(A1) might be stored inside the Diameter Client (SIP server) when it's first received, and reused later on. Is it this that the draft is alluding to ? -- Jo Hermans "Eagles may soar, but weasels aren't sucked into jet engines" -- to 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, 10 Apr 2005 17:45:42 +0000 Date: Sun, 10 Apr 2005 10:45:36 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: REMINDER: RADEXT WG Last Call on Chargeable UserId Draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is a reminder about a RADEXT WG last call in progress on the Chargeable UserId Draft prior to sending the document to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-04.txt RADEXT WG last call will last until Monday, April 18, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the Issues 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: Sun, 10 Apr 2005 17:43:47 +0000 Date: Sun, 10 Apr 2005 10:43:07 -0700 (PDT) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Any last comments on draft-adrangi-eap-network-discovery-12.txt? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII The -12 version of the EAP Network Discovery document is now available on the IETF archive at: http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-12.txt This document has requested publication as an Informational RFC via the RFC editor individual submissino route. Unless we hear any comments by Monday, April 18, 2005 we are going to assume this document has completed review and we will inform the IESG of that. So if you any remaining issues, please post them to the EAP WG mailing list (eap@frascone.com). Note: there appears to be an IPR claim related to this document: http://www.ietf.org/ietf/IPR/telecom-italia-ipr-wlan-access.txt -- to 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, 07 Apr 2005 22:07:25 +0000 From: "Alan DeKok" To: Avi Lior Cc: Bikramjit Singh , radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Date: Thu, 07 Apr 2005 18:03:57 -0400 Message-Id: <20050407220357.BE62317120@mail.nitros9.org> Avi Lior wrote: > I don't know what you mean by close in the network. So a typical case where > this happens is when there is a NAS in the DMZ zone and a RADIUS is > internal. I understand. In that case, the NAT box which the RADIUS server sees as the NAS is "closer" to the RADIUS box than the real NAS. 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, 07 Apr 2005 19:16:18 +0000 Message-ID: From: Avi Lior To: 'Alan DeKok' , Bikramjit Singh Cc: radiusext@ops.ietf.org Subject: RE: When to Access-Reject vs. Silently Discard Date: Thu, 7 Apr 2005 15:16:05 -0400 MIME-Version: 1.0 Content-Type: text/plain Alan, I don't know what you mean by close in the network. So a typical case where this happens is when there is a NAS in the DMZ zone and a RADIUS is internal. > -----Original Message----- > From: Alan DeKok [mailto:aland@ox.org] > Sent: Thursday, April 07, 2005 2:56 PM > To: Bikramjit Singh > Cc: radiusext@ops.ietf.org > Subject: Re: When to Access-Reject vs. Silently Discard > > > Bikramjit Singh wrote: > > [Bik] Isn't this condition also true if there is NAT in the middle? > > And you have provisioned the RADIUS client with the publicly known > > external address. > > In which case, the NAS isn't "close" in the network to the > RADIUS server. > > NAT & RADIUS don't interact well. > > 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: Thu, 07 Apr 2005 18:59:38 +0000 From: "Alan DeKok" To: Bikramjit Singh Cc: radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Date: Thu, 07 Apr 2005 14:56:04 -0400 Message-Id: <20050407185604.60DDE17120@mail.nitros9.org> Bikramjit Singh wrote: > [Bik] Isn't this condition also true if there is NAT in the middle? And you > have provisioned the RADIUS client with the publicly known external address. In which case, the NAS isn't "close" in the network to the RADIUS server. NAT & RADIUS don't interact well. 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, 07 Apr 2005 18:42:59 +0000 Message-ID: <89680B404BA1DD419E6D93B28B41899B031749B7@01mail.nomadix.com> From: Bikramjit Singh To: 'Alan DeKok' , 'Bernard Aboba' Cc: "'Glen Zorn (gwz)'" , "'radiusext@ops.ietf.org'" Subject: RE: When to Access-Reject vs. Silently Discard Date: Thu, 7 Apr 2005 11:34:32 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53BA0.70AEFED0" 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_01C53BA0.70AEFED0 Content-Type: text/plain The only times I can see (NAS-IP-Address != source IP) for local NASes are buggy implementations, or security breaches. Is there another case that text is trying to address, that I'm missing? [Bik] Isn't this condition also true if there is NAT in the middle? And you have provisioned the RADIUS client with the publicly known external address. There are some implementations like that.. Thanks -Bik ------_=_NextPart_001_01C53BA0.70AEFED0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: When to Access-Reject vs. Silently Discard

  The only times I can see (NAS-IP-Address !=3D = source IP) for local
NASes are buggy implementations, or security = breaches.  Is there
another case that text is trying to address, that = I'm missing?

[Bik] Isn't this condition also true if there is NAT = in the middle? And you have provisioned the RADIUS client with the = publicly known external address. There are some implementations like = that..

Thanks

-Bik

------_=_NextPart_001_01C53BA0.70AEFED0-- -- to 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, 07 Apr 2005 18:42:36 +0000 Date: Thu, 7 Apr 2005 11:42:03 -0700 (PDT) From: Bernard Aboba To: Alan DeKok cc: "Glen Zorn (gwz)" , radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > The only times I can see (NAS-IP-Address != source IP) for local > NASes are buggy implementations, or security breaches. Is there > another case that text is trying to address, that I'm missing? That's about it. > If it's a buggy implementation, upgrade. If it's a security breach, > an Access-Reject is wrong: the NAS should be de-listed from the known > clients, to avoid an attacker using the trust relationship to gain > knowledge about users. Certainly the NAS should be delisted, but presumably that will not occur automatically, but as the result of administrator action responding to an appropriate alert. -- to 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, 07 Apr 2005 18:11:23 +0000 From: "Alan DeKok" To: gwz@cisco.com Cc: radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Date: Thu, 07 Apr 2005 14:07:50 -0400 Message-Id: <20050407180750.AB39F17120@mail.nitros9.org> "Glen Zorn (gwz)" wrote: > > We "know" it's the right NAS, because it has the right source IP > > and shared secret, which is the only way to identify any NAS. > > But it's not a _user_ authentication or authorization problem, > either; it's neither fish nor fowl. From the point of view of the RADIUS server, it's just more information in the packet. It doesn't know about "users", and doesn't need to. e.g. MAC address authentication. If the RADIUS server doesn't like something in the packet it gets from a trusted NAS, it sends an Access-Reject. I'm not sure how the issue of "NAS authorized for realms" is any different than any other case. 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, 07 Apr 2005 17:26:46 +0000 From: "Alan DeKok" To: Bernard Aboba Cc: "Glen Zorn (gwz)" , radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Date: Thu, 07 Apr 2005 13:23:03 -0400 Message-Id: <20050407172303.6F615170F5@mail.nitros9.org> Bernard Aboba wrote: > > Sending Access-Reject when (NAS-IP-Address != source IP) would > > break a LOT of deployments. And it's a SHOULD, not a MUST. > > This is only something for a local proxy, not an intermediate proxy or a > server. Assuming that it's only a local proxy why would this break > deployments? If the NAS is actually a NAS, and not a proxying server, and if the NAS is close (in the network) to the RADIUS server, then this restriction can make sense. It's difficult to administer in practice, however, given the skill-set and knowledge I've seen. That restriction would be turned off in many deployments I've seen, because it's too easy to get wrong, and it has little to no value. To back up: If you're worried that the NAS will impersonate another one via NAS-IP-Address, why are you listening to it at all? The only times I can see (NAS-IP-Address != source IP) for local NASes are buggy implementations, or security breaches. Is there another case that text is trying to address, that I'm missing? If it's a buggy implementation, upgrade. If it's a security breach, an Access-Reject is wrong: the NAS should be de-listed from the known clients, to avoid an attacker using the trust relationship to gain knowledge about users. 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, 07 Apr 2005 04:32:13 +0000 Date: Wed, 6 Apr 2005 21:31:32 -0700 (PDT) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Alan DeKok'" , radiusext@ops.ietf.org Subject: RE: When to Access-Reject vs. Silently Discard Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Sending Access-Reject when (NAS-IP-Address != source IP) would > break a LOT of deployments. And it's a SHOULD, not a MUST. This is only something for a local proxy, not an intermediate proxy or a server. Assuming that it's only a local proxy why would this break deployments? -- to 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, 07 Apr 2005 01:21:19 +0000 Message-Id: <200504070120.j371Kh3S019502@sj-core-4.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Alan DeKok'" , Subject: RE: When to Access-Reject vs. Silently Discard Date: Wed, 6 Apr 2005 18:20:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Thread-Index: AcU6yxJRRVlupPNjQ4CQQc3GqzE9KgARCPwg Alan DeKok <> supposedly scribbled: > Avi Lior wrote: >> In the RADIUS Digest thread (Issue 79) when the Server detects that >> the NAS is trying to authenticate a realm for which it is not >> authorized we need to "reject" the authentication. This can be >> done by either Access-Reject or >> Silently Discarding the packet. SO the question is which one is >> correct? > > I would back up, and say when do we discard, versus send reject? > > - attempted security breaches (bad Message-Authenticator, unknown > client) result in the packet being discarded. Right. > > - failed authentication or authorization results in Access-Reject > (bad password, not permitted to use requested services, etc) Right. > >> Its not clear: for example if Message-Authenticator(80) does not >> validate (as per 3579) we silently discard. When we detect a lying >> NAS again as per 3579 we generate an Access-Reject: "Where a match >> is not found, an >> Access-Reject SHOULD be >> sent, and an error SHOULD be logged." > > Sending Access-Reject when (NAS-IP-Address != source IP) would > break a LOT of deployments. And it's a SHOULD, not a MUST. Yes, that is way broken, IMHO. > > > For the case of a NAS authenticating for a realm it's not > authorized to use, we need to ask if it's a security problem or > failed authorization. The answer to that question will tell us how > to handle this case. > > My $0.02 is that if the packet contains a valid > Message-Authenticator, then an Access-Reject should be sent, AND an > error message logged saying that the NAS is misconfigured, or may be > compromised. We "know" it's the right NAS, because it has the right > source IP and shared secret, which is the only way to identify any > NAS. But it's not a _user_ authentication or authorization problem, either; it's neither fish nor fowl. > > If the packet doesn't contain a Message-Authenticator, then the > answer is more complex. > > In this case, I believe that the packet does contain > Message-Authenticator. > > Alan DeKok. Hope this helps, ~gwz Why is it that most of the world's problems can't be solved by simply listening to John Coltrane? -- Henry Gabriel -- to 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, 06 Apr 2005 19:03:35 +0000 Message-ID: From: Avi Lior To: 'Alan DeKok' , radiusext@ops.ietf.org Cc: "'Beck01, Wolfgang'" , "Salowey, Joe" Subject: RE: When to Access-Reject vs. Silently Discard Date: Wed, 6 Apr 2005 15:02:56 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Alan, Okay I agree with your $0.02. So we should do a reject in RADIUS Digest in this case. > -----Original Message----- > From: Alan DeKok [mailto:aland@ox.org] > Sent: Wednesday, April 06, 2005 1:03 PM > To: radiusext@ops.ietf.org > Subject: Re: When to Access-Reject vs. Silently Discard > > > Avi Lior wrote: > > In the RADIUS Digest thread (Issue 79) when the Server detects that > > the NAS is trying to authenticate a realm for which it is > not authorized we need to > > "reject" the authentication. This can be done by either > Access-Reject or > > Silently Discarding the packet. SO the question is which one is > > correct? > > I would back up, and say when do we discard, versus send reject? > > - attempted security breaches (bad Message-Authenticator, unknown > client) result in the packet being discarded. > > - failed authentication or authorization results in Access-Reject > (bad password, not permitted to use requested services, etc) > > > Its not clear: for example if Message-Authenticator(80) does not > > validate (as per 3579) we silently discard. When we detect > a lying NAS again as per > > 3579 we generate an Access-Reject: "Where a match is not found, an > > Access-Reject SHOULD be > > sent, and an error SHOULD be logged." > > Sending Access-Reject when (NAS-IP-Address != source IP) > would break a LOT of deployments. And it's a SHOULD, not a MUST. > > > For the case of a NAS authenticating for a realm it's not > authorized to use, we need to ask if it's a security problem > or failed authorization. The answer to that question will > tell us how to handle this case. > > My $0.02 is that if the packet contains a valid > Message-Authenticator, then an Access-Reject should be sent, > AND an error message logged saying that the NAS is > misconfigured, or may be compromised. We "know" it's the > right NAS, because it has the right source IP and shared > secret, which is the only way to identify any NAS. > > If the packet doesn't contain a Message-Authenticator, then > the answer is more complex. > > In this case, I believe that the packet does contain > Message-Authenticator. > > 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, 06 Apr 2005 17:06:35 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: When to Access-Reject vs. Silently Discard Date: Wed, 06 Apr 2005 13:02:55 -0400 Message-Id: <20050406170255.5607B17127@mail.nitros9.org> Avi Lior wrote: > In the RADIUS Digest thread (Issue 79) when the Server detects that the NAS > is trying to authenticate a realm for which it is not authorized we need to > "reject" the authentication. This can be done by either Access-Reject or > Silently Discarding the packet. SO the question is which one is correct? I would back up, and say when do we discard, versus send reject? - attempted security breaches (bad Message-Authenticator, unknown client) result in the packet being discarded. - failed authentication or authorization results in Access-Reject (bad password, not permitted to use requested services, etc) > Its not clear: for example if Message-Authenticator(80) does not validate > (as per 3579) we silently discard. When we detect a lying NAS again as per > 3579 we generate an Access-Reject: "Where a match is not found, an > Access-Reject SHOULD be > sent, and an error SHOULD be logged." Sending Access-Reject when (NAS-IP-Address != source IP) would break a LOT of deployments. And it's a SHOULD, not a MUST. For the case of a NAS authenticating for a realm it's not authorized to use, we need to ask if it's a security problem or failed authorization. The answer to that question will tell us how to handle this case. My $0.02 is that if the packet contains a valid Message-Authenticator, then an Access-Reject should be sent, AND an error message logged saying that the NAS is misconfigured, or may be compromised. We "know" it's the right NAS, because it has the right source IP and shared secret, which is the only way to identify any NAS. If the packet doesn't contain a Message-Authenticator, then the answer is more complex. In this case, I believe that the packet does contain Message-Authenticator. 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, 06 Apr 2005 16:30:45 +0000 Message-ID: From: Avi Lior To: "'radiusext@ops.ietf.org'" Subject: When to Access-Reject vs. Silently Discard Date: Wed, 6 Apr 2005 12:29:57 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53AC5.DF0210B0" 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_01C53AC5.DF0210B0 Content-Type: text/plain Hi, In the RADIUS Digest thread (Issue 79) when the Server detects that the NAS is trying to authenticate a realm for which it is not authorized we need to "reject" the authentication. This can be done by either Access-Reject or Silently Discarding the packet. SO the question is which one is correct? Its not clear: for example if Message-Authenticator(80) does not validate (as per 3579) we silently discard. When we detect a lying NAS again as per 3579 we generate an Access-Reject: "Where a match is not found, an Access-Reject SHOULD be sent, and an error SHOULD be logged." So is there are rule that can express the correct thing to do? ------------------------------------------------ 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_01C53AC5.DF0210B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Message
Hi,
 
In = the RADIUS Digest=20 thread (Issue 79) when the Server detects that the NAS is trying to = authenticate=20 a realm for which it is not authorized we need to "reject" the=20 authentication.   This can be done by either Access-Reject or = Silently=20 Discarding the packet.  SO the question is which one is=20 correct?
 
Its = not clear: =20 for example if Message-Authenticator(80) does not validate (as per = 3579) we=20 silently discard.  When we detect a lying NAS again as per 3579 we = generate=20 an Access-Reject:   "Where a match is not found, an = Access-Reject=20 SHOULD be
 sent, and an error SHOULD be logged."
So =
is there are rule that can express the correct thing to =
do?
 

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

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_01C53AC5.DF0210B0-- -- to 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, 05 Apr 2005 07:37:24 +0000 Message-ID: <42523EDF.3010807@nokia.com> Date: Tue, 05 Apr 2005 10:31:43 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: aboba@internaut.com, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: Re: AW: AW: Issue 79; digest-auth realm validation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Wolfgang: Yeap, understood now. The Message-Authenticator will help definitely. Then I believe your compromising considerations are right. /Miguel Beck01, Wolfgang wrote: > >>So you basically stop in the RADIUS server processing further >>requests that come from the same RADIUS client? > > yes. > >>How do you identify the RADIUS client, is it by its IP address? > > yes, and by a shared secret. But I am not sure whether current RADIUS > server APIs support this. > > >>What I am trying to avoid is that this "compromise" prevents >>that RADIUS server to process legitimate requests coming from a RADIUS >>client just because an attacker wrote a forged RADIUS request to preclude that >>client to be operating anymore. > > This would be a quite effective DoS attack. But Message-Authenticator is mandatory > now and should make forging RADIUS requests much harder. > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany -- 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: Mon, 04 Apr 2005 22:18: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 79; digest-auth realm validation Date: Mon, 4 Apr 2005 15:21:55 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6904F0DA3C@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Issue 79; digest-auth realm validation Thread-Index: AcU5XOKQWuLi30GjSaeZYtMjgaS/qgABp0xQ From: "Salowey, Joe" To: "Avi Lior" , "Nelson, David" , Cc: "Beck01, Wolfgang" =20 > -----Original Message----- > From: Avi Lior [mailto:avi@bridgewatersystems.com]=20 > Sent: Monday, April 04, 2005 2:22 PM > To: 'Nelson, David'; radiusext@ops.ietf.org > Cc: Salowey, Joe; 'Beck01, Wolfgang' > Subject: RE: Issue 79; digest-auth realm validation >=20 > I agree with you David. Then perhaps not using shoulds or=20 > may. Even better > saying: >=20 > "A RADIUS MUST check if the RADIUS=20 > client is authorized to > serve users of the realm mentioned in the Digest-Realm=20 > attribute. If > the RADIUS client is not authorized, the RADIUS server sends an > Access-Reject. Other actions taken by the RADIUS server=20 > are out of scope of this document however, the RADIUS server=20 > should notify the operator and may take additional=20 > action such as rejecting all future > requests from this client, until some management action tells it to > do so again. " >=20 > Note above I use Access-Reject but it may still be better to=20 > silently discard. >=20 [Joe] I'm okay with this wording. I'm also open to the silent discard behavior if enough people really prefer that. =20 > > -----Original Message----- > > From: Nelson, David [mailto:dnelson@enterasys.com] > > Sent: Monday, April 04, 2005 4:53 PM > > To: radiusext@ops.ietf.org > > Subject: RE: Issue 79; digest-auth realm validation > >=20 > >=20 > > Avi Lior writes... > >=20 > > > I think that the actions such as informing the operator is=20 > > > informative text and not normative text and therefore we=20 > should use=20 > > > lowercase "SHOULD". > >=20 > > Two comments: First, which parts of an RFC are typically considered=20 > > informative? The various "Considerations" > > sections? Others? Second, I don't think that using lower case to=20 > > indicate informative usage is a good idea, as it leads to confusion. > > =20 > > > Note that the IMO the whole discussion should be included in the > > security > > > section. > >=20 > > I guess that depends on whether one wishes to include a solution to=20 > > the issues/concerns within the body of the specification,=20 > or simply to=20 > > lament about the lack of (inability to provide) a solution in the=20 > > Security Considerations section. :-) > >=20 > >=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 >=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, 04 Apr 2005 21:22:36 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Cc: "'Salowey, Joe'" , "'Beck01, Wolfgang'" Subject: RE: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 17:22:22 -0400 MIME-Version: 1.0 Content-Type: text/plain I agree with you David. Then perhaps not using shoulds or may. Even better saying: "A RADIUS MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server sends an Access-Reject. Other actions taken by the RADIUS server are out of scope of this document however, the RADIUS server should notify the operator and may take additional action such as rejecting all future requests from this client, until some management action tells it to do so again. " Note above I use Access-Reject but it may still be better to silently discard. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, April 04, 2005 4:53 PM > To: radiusext@ops.ietf.org > Subject: RE: Issue 79; digest-auth realm validation > > > Avi Lior writes... > > > I think that the actions such as informing the operator is > > informative text and not normative text and therefore we should > > use lowercase "SHOULD". > > Two comments: First, which parts of an RFC are typically > considered informative? The various "Considerations" > sections? Others? Second, I don't think that using lower case > to indicate informative usage is a good idea, as it leads to > confusion. > > > Note that the IMO the whole discussion should be included in the > security > > section. > > I guess that depends on whether one wishes to include a > solution to the issues/concerns within the body of the > specification, or simply to lament about the lack of > (inability to provide) a solution in the Security > 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: > -- to 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, 04 Apr 2005 20:54:04 +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 79; digest-auth realm validation Date: Mon, 4 Apr 2005 16:53:28 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010322A3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 79; digest-auth realm validation Thread-Index: AcU5Vw0jgHRLjlDGRTC8NSTsKQe1RgAAGkmw From: "Nelson, David" To: Avi Lior writes... > I think that the actions such as informing the operator is=20 > informative text and not normative text and therefore we should=20 > use lowercase "SHOULD". Two comments: First, which parts of an RFC are typically considered informative? The various "Considerations" sections? Others? Second, I don't think that using lower case to indicate informative usage is a good idea, as it leads to confusion. =20 > Note that the IMO the whole discussion should be included in the security > section. I guess that depends on whether one wishes to include a solution to the issues/concerns within the body of the specification, or simply to lament about the lack of (inability to provide) a solution in the Security 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: Mon, 04 Apr 2005 20:43:50 +0000 Message-ID: From: Avi Lior To: "'Salowey, Joe'" , "Beck01, Wolfgang" , aboba@internaut.com Cc: radiusext@ops.ietf.org Subject: RE: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 16:43:24 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi, See comments inline. > -----Original Message----- > From: Salowey, Joe [mailto:jsalowey@cisco.com] > Sent: Monday, April 04, 2005 1:09 PM > To: Beck01, Wolfgang; aboba@internaut.com > Cc: radiusext@ops.ietf.org > Subject: RE: Issue 79; digest-auth realm validation > > > > > > -----Original Message----- > > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > > Sent: Monday, April 04, 2005 1:52 AM > > To: aboba@internaut.com; Salowey, Joe > > Cc: radiusext@ops.ietf.org > > Subject: Re: Issue 79; digest-auth realm validation > > > > Here's a complete text proposal: > > > > The RADIUS server MUST check if the user identified by the > > User-Name > > attribute > > o is authorized to access the protection space defined by the > > Digest-URI and Digest-Realm attributes, > > o is authorized to use the URI included in the SIP-AOR > > attribute, if > > this attribute is present. > > If any of those checks fails, the RADIUS server MUST send an > > Access-Reject. > > > > Correlation between User-Name and SIP-AOR AVP values is > > required just > > to avoid that any user can register or misuse a SIP-AOR > > allocated to > > another user. > > > > A RADIUS server MUST check if the RADIUS client is authorized to > > serve users of the realm mentioned in the Digest-Realm > > attribute. If > > the RADIUS client is not authorized, the RADIUS server sends an > > Access-Reject. The RADIUS server considers this client as > > compromised. It notifies the operator and rejects all future > > requests from this client, until some management action > tells it to > > do so again. > > > > Please send me a note if you have objections/additions about > > this text so we can close the issue. > > [Joe] As Avi mentioned in a previous message this gets a bit > complicated in a case where you have proxies under different > administrative control. In this case the AAA server that > perfroms the digest auth may not have detailed information > about the client to realm authorization. In this case one of > the intermediate proxies could be resposible for the > authorization check. It might also be worthwile to warn > about the use of the digest-HA1 attribute and MD5 (vs. > MD5-SESS) algorithm in the security considerations. Also I > suppose that the action to reject is up to the operator. Here > are some suggested revisions: > > "A RADIUS server in the RADIUS proxy chain MUST check if > the RADIUS > client is authorized to > serve users of the realm mentioned in the Digest-Realm > attribute. If > the RADIUS client is not authorized, the RADIUS server sends an > Access-Reject. The RADIUS server should consider this client as > compromised. It SHOULD notify the operator and MAY take > additional > action such as rejecting all future > requests from this client, until some management action tells it to > do so again. " So you intend that servers in the proxy chain to the check? If yes that is not always possible. Some servers are truly pass through. Instead of sending an Access Reject I think we should silently discard. However, the penalty of doing so is that the Client will never know why and its not receiving an Access-Accept or Access-Reject and if it is simply a misconfigured client it will turn off that RADIUS server. Also note that no one is proposing to use put in a reason in the Access-Reject as to why we are rejecting. I think that the actions such as informing the operator is informative text and not normative text and therefore we should use lowercase "SHOULD". Note that the IMO the whole discussion should be included in the security section. > In the security considerations section: > > "When used with the MD5 algorithm the digest-HA1 attribute contains > a hash value that can be used by an attacker in a dictionary > attack against the user's password. This mechanism should only be > used in environments where there is sufficient trust in > intermediate > RADIUS proxies and RADIUS client requests can be validated against > their authorized realm. " > > > > > > Wolfgang > > > > -- > > T-Systems > > Next Generation IP Services and Systems > > +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: Mon, 04 Apr 2005 17:06: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: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 10:08:42 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6904F0D875@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: Issue 79; digest-auth realm validation Thread-Index: AcU49Bt/IJHVbhhmTCmNhPjS4kHR4gAQOeVA From: "Salowey, Joe" To: "Beck01, Wolfgang" , Cc: =20 > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]=20 > Sent: Monday, April 04, 2005 1:52 AM > To: aboba@internaut.com; Salowey, Joe > Cc: radiusext@ops.ietf.org > Subject: Re: Issue 79; digest-auth realm validation >=20 > Here's a complete text proposal: >=20 > The RADIUS server MUST check if the user identified by the=20 > User-Name > attribute > o is authorized to access the protection space defined by the > Digest-URI and Digest-Realm attributes, > o is authorized to use the URI included in the SIP-AOR=20 > attribute, if > this attribute is present. > If any of those checks fails, the RADIUS server MUST send an > Access-Reject. >=20 > Correlation between User-Name and SIP-AOR AVP values is=20 > required just > to avoid that any user can register or misuse a SIP-AOR=20 > allocated to > another user. >=20 > A RADIUS server MUST check if the RADIUS client is authorized to > serve users of the realm mentioned in the Digest-Realm=20 > attribute. If > the RADIUS client is not authorized, the RADIUS server sends an > Access-Reject. The RADIUS server considers this client as > compromised. It notifies the operator and rejects all future > requests from this client, until some management action tells it to > do so again. >=20 > Please send me a note if you have objections/additions about=20 > this text so we can close the issue. [Joe] As Avi mentioned in a previous message this gets a bit complicated in a case where you have proxies under different administrative control. In this case the AAA server that perfroms the digest auth may not have detailed information about the client to realm authorization. In this case one of the intermediate proxies could be resposible for the authorization check. It might also be worthwile to warn about the use of the digest-HA1 attribute and MD5 (vs. MD5-SESS) algorithm in the security considerations. Also I suppose that the action to reject is up to the operator. Here are some suggested revisions: "A RADIUS server in the RADIUS proxy chain MUST check if the RADIUS=20 client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server sends an Access-Reject. The RADIUS server should consider this client as compromised. It SHOULD notify the operator and MAY take additional=20 action such as rejecting all future requests from this client, until some management action tells it to do so again. " In the security considerations section: "When used with the MD5 algorithm the digest-HA1 attribute contains a hash value that can be used by an attacker in a dictionary attack against the user's password. This mechanism should only be=20 used in environments where there is sufficient trust in intermediate=20 RADIUS proxies and RADIUS client requests can be validated against=20 their authorized realm. " >=20 > Wolfgang >=20 > -- > T-Systems > Next Generation IP Services and Systems > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany=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: Mon, 04 Apr 2005 17:04:24 +0000 Message-ID: From: Avi Lior To: "'Beck01, Wolfgang'" , aboba@internaut.com, jsalowey@cisco.com Cc: radiusext@ops.ietf.org Subject: RE: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 13:03:52 -0400 MIME-Version: 1.0 Content-Type: text/plain Hi Wolfgang, See inline: > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > Sent: Monday, April 04, 2005 4:52 AM > To: aboba@internaut.com; jsalowey@cisco.com > Cc: radiusext@ops.ietf.org > Subject: Re: Issue 79; digest-auth realm validation > > > Here's a complete text proposal: > > The RADIUS server MUST check if the user identified by the > User-Name > attribute > o is authorized to access the protection space defined by the > Digest-URI and Digest-Realm attributes, > o is authorized to use the URI included in the SIP-AOR > attribute, if > this attribute is present. > If any of those checks fails, the RADIUS server MUST send an > Access-Reject. > > Correlation between User-Name and SIP-AOR AVP values is > required just > to avoid that any user can register or misuse a SIP-AOR > allocated to > another user. > > A RADIUS server MUST check if the RADIUS client is authorized to > serve users of the realm mentioned in the Digest-Realm > attribute. If > the RADIUS client is not authorized, the RADIUS server sends an > Access-Reject. The RADIUS server considers this client as > compromised. It notifies the operator and rejects all future > requests from this client, until some management action tells it to > do so again. I think if the realm check fails, IMO RADIUS should silently-discard and log/report. I don't think it should ignore any further traffic from that client. After all, it may not be the client that is compromized but rather another RADIUS Client in the proxy chain. Anyway, whether we ingnore traffic or not will really depend on how RADIUS is being deployed here and should therefore be a deployment issue. > Please send me a note if you have objections/additions about > this text so we can close the issue. > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +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: Mon, 04 Apr 2005 14:23:10 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FEA1@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aboba@internaut.com, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: AW: AW: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 16:22:33 +0200 MIME-Version: 1.0 Content-Type: text/plain > So you basically stop in the RADIUS server processing further > requests that come from the same RADIUS client? yes. > How do you identify the RADIUS client, is it by its IP address? yes, and by a shared secret. But I am not sure whether current RADIUS server APIs support this. > > What I am trying to avoid is that this "compromise" prevents > that RADIUS server to process legitimate requests coming from a RADIUS > client just because an attacker wrote a forged RADIUS request to preclude that > client to be operating anymore. This would be a quite effective DoS attack. But Message-Authenticator is mandatory now and should make forging RADIUS requests much harder. Wolfgang -- T-Systems Next Generation IP Services and Systems +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: Mon, 04 Apr 2005 13:13:40 +0000 Message-ID: <42513A01.2050804@nokia.com> Date: Mon, 04 Apr 2005 15:58:41 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: aboba@internaut.com, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: Re: AW: Issue 79; digest-auth realm validation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit So you basically stop in the RADIUS server processing further requests that come from the same RADIUS client? How do you identify the RADIUS client, is it by its IP address? What I am trying to avoid is that this "compromise" prevents that RADIUS server to process legitimate requests coming from a RADIUS client just because an attacker wrote a forged RADIUS request to preclude that client to be operating anymore. If you can avoid this case I am fine, otherwise, I have a problem with it. /Miguel Beck01, Wolfgang wrote: > Miguel wrote: > >>I have a question: >> >>What is the intention of this text: >> >> "The RADIUS server considers this client as >> compromised. " >> >>What is this consideration? Is it that the RADIUS server marks >>"something" as "not being able to use the HTTP or SIP service >>any longer"? > > "something" -- the RADIUS client that sent a Digest-Realm with a > realm it is not allowed to speak for. > Joe's reasoning was that this can be a sign of compromised > RADIUS client. If a RADIUS client is compromised, it's better > not to process any requests from it until the situation has > been resolved. > > So your proposal would be just to drop the reject the request > with the offending Digest-Realm attribute? > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +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: -- 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: Mon, 04 Apr 2005 11:51:16 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE9F@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: Miguel.An.Garcia@nokia.com Cc: aboba@internaut.com, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: AW: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 13:50:52 +0200 MIME-Version: 1.0 Content-Type: text/plain Miguel wrote: > I have a question: > > What is the intention of this text: > > "The RADIUS server considers this client as > compromised. " > > What is this consideration? Is it that the RADIUS server marks > "something" as "not being able to use the HTTP or SIP service > any longer"? "something" -- the RADIUS client that sent a Digest-Realm with a realm it is not allowed to speak for. Joe's reasoning was that this can be a sign of compromised RADIUS client. If a RADIUS client is compromised, it's better not to process any requests from it until the situation has been resolved. So your proposal would be just to drop the reject the request with the offending Digest-Realm attribute? Wolfgang -- T-Systems Next Generation IP Services and Systems +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: Mon, 04 Apr 2005 09:29:46 +0000 Message-ID: <42510776.8030305@nokia.com> Date: Mon, 04 Apr 2005 12:23:02 +0300 From: Miguel Garcia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) MIME-Version: 1.0 To: "Beck01, Wolfgang" CC: aboba@internaut.com, jsalowey@cisco.com, radiusext@ops.ietf.org Subject: Re: Issue 79; digest-auth realm validation Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I have a question: What is the intention of this text: "The RADIUS server considers this client as compromised. " What is this consideration? Is it that the RADIUS server marks "something" as "not being able to use the HTTP or SIP service any longer"? I hope it does not mean that the RADIUS server marks the user in a black list or something similar. I hope also that we can focus on the technical aspects of the protocol, and leave the issue of alarms, sirens, urgent e-mails and alike for the designers of products. I am not referring to this other paragraph: "It notifies the operator and rejects all future requests from this client, until some management action tells it to do so again." /Miguel Beck01, Wolfgang wrote: > Here's a complete text proposal: > > The RADIUS server MUST check if the user identified by the User-Name > attribute > o is authorized to access the protection space defined by the > Digest-URI and Digest-Realm attributes, > o is authorized to use the URI included in the SIP-AOR attribute, if > this attribute is present. > If any of those checks fails, the RADIUS server MUST send an > Access-Reject. > > Correlation between User-Name and SIP-AOR AVP values is required just > to avoid that any user can register or misuse a SIP-AOR allocated to > another user. > > A RADIUS server MUST check if the RADIUS client is authorized to > serve users of the realm mentioned in the Digest-Realm attribute. If > the RADIUS client is not authorized, the RADIUS server sends an > Access-Reject. The RADIUS server considers this client as > compromised. It notifies the operator and rejects all future > requests from this client, until some management action tells it to > do so again. > > Please send me a note if you have objections/additions about this text so > we can close the issue. > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +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: > -- 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: Mon, 04 Apr 2005 08:53:02 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE9E@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: aboba@internaut.com, jsalowey@cisco.com Cc: radiusext@ops.ietf.org Subject: Re: Issue 79; digest-auth realm validation Date: Mon, 4 Apr 2005 10:52:11 +0200 MIME-Version: 1.0 Content-Type: text/plain Here's a complete text proposal: The RADIUS server MUST check if the user identified by the User-Name attribute o is authorized to access the protection space defined by the Digest-URI and Digest-Realm attributes, o is authorized to use the URI included in the SIP-AOR attribute, if this attribute is present. If any of those checks fails, the RADIUS server MUST send an Access-Reject. Correlation between User-Name and SIP-AOR AVP values is required just to avoid that any user can register or misuse a SIP-AOR allocated to another user. A RADIUS server MUST check if the RADIUS client is authorized to serve users of the realm mentioned in the Digest-Realm attribute. If the RADIUS client is not authorized, the RADIUS server sends an Access-Reject. The RADIUS server considers this client as compromised. It notifies the operator and rejects all future requests from this client, until some management action tells it to do so again. Please send me a note if you have objections/additions about this text so we can close the issue. Wolfgang -- T-Systems Next Generation IP Services and Systems +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: Sat, 02 Apr 2005 17:58:35 +0000 Date: Sat, 2 Apr 2005 09:57:38 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RADEXT WG Last Call on Chargeable UserId Draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII This is an announcement of RADEXT WG last call on the Chargeable UserId Draft prior to sending the document to the IESG for consideration as a Proposed Standard. The document is available here: http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-04.txt RADEXT WG last call will last until Monday, April 18, 2005. Please send comments to the RADEXT WG mailing list (radiusext@ops.ietf.org) in the Issues 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: Fri, 01 Apr 2005 21:57:44 +0000 Date: Fri, 1 Apr 2005 13:57:29 -0800 (PST) From: Bernard Aboba To: "Salowey, Joe" cc: "Beck01, Wolfgang" , radiusext@ops.ietf.org Subject: RE: Issue 79; digest-auth realm validation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > [Joe] I agree that the case that is interesting is when the RADIUS > server supports RADIUS clients that support different realms. I don't > see how it is possible that a RADIUS client will never see HTTP-style > requests from other realms, but perhaps I am missing something. Yes, I don't see this either. Unless this document is attempting to modify existing RADIUS proxy behavior, a proxy will automatically forward an Access-Request containing a User-Name attribute with an NAI as it would any other Access-Request. So if the User-Name contains "jsalowey@cisco.com" and that proxy is set up with a route to cisco.com then it will forward the Access-Request to the indicated RADIUS server. > [Joe] It seems that the compromised RADIUS client can pretend to be > providing service for a different realm which in turn allows it to > obtain the Digest-HA1 for users in another realm. Both of these > exposures are different than the ones you mention. Yes, I agree this appears possible. > [Joe] I believe it helps to mitigate the exposures above. I am most > concerned about the exposure of Digest-HA1 when the Digest-algorithm MD5 > is used. There may be other issues, but that depends on what clients > expect from a realm. In fact, these attacks have already been carried out by Web servers and have been used to compromise credentials via offline dictionary attacks. So they are quite real. -- to 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, 01 Apr 2005 21:44:35 +0000 Date: Fri, 1 Apr 2005 13:43:56 -0800 (PST) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: AW: AW: [Issue] Review of draft-ietf-radext-digest-auth-01.txt, o verview section Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Yes, that would be helpful. On Thu, 24 Mar 2005, Beck01, Wolfgang wrote: > > > Wolfgang wrote: > > > [mapping of HTTP Authentication parameters into RADIUS attributes] > > > We are still in an Overview Section here, so I think that being vague > > > doesn't hurt too much. > > > > Bernard wrote: > > I found myself trying to get more details early on. Much of > > the material in Section 3 seems to be at the right level so > > some of it (a few paragraphs) could be moved up. > > Can you agree with exchanging Section 2 (attributes) and > Section 3 (Detailed Description)? Then, you get the details > before jumping into the attributes, but the Overview Section > would not be laden with details. > > > Wolfgang > > -- > T-Systems > Next Generation IP Services and Systems > +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, 01 Apr 2005 18:45:27 +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: Minutes of the RADEXT session at IETF62 Date: Fri, 1 Apr 2005 13:44:15 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103228D@MAANDMBX2.ets.enterasys.com> Thread-Topic: Minutes of the RADEXT session at IETF62 Thread-Index: AcU26s3Unr0fFPrZRm6MuzGYD2EICg== From: "Nelson, David" To: Please review these minutes and reply to the list with any errors or = omissions. Minutes of the RADEXT WG session at IETF62 Wednesday, March 9, 2005 1530 - 1730 Hilton Minneapolis Rochester Room Notes taken by Paul Condgon and John Vollbrecht and edited by Dave = Nelson. =20 Agenda: = http://www.drizzle.com/~aboba/IETF62/radext/ietf62_radext-agenda.ppt Slides: http://www.drizzle.com/~aboba/IETF62/radext/ Issues Tracker: http://www.drizzle.com/~aboba/RADEXT =20 1. Agenda Bashing: The published agenda was set for 2.5 hours but we = were switched into a 2.0 hour session slot. Agenda will be reshuffled to = fit in 2 hours because few wanted to cut short the dinner hour. Will = start the capabilities discovery discussion at a fixed time. 2. Document status was covered=20 =20 3. Milestones need to be updated on web site. Proposed revision is: - Done=A0=A0 RFC 2486bis submitted as a Proposed Standard RFC - May 05=A0=A0RADIUS digest auth draft submitted as a Proposed Standard = RFC - Jun 05=A0=A0Updates to RFC 2618-2621 RADIUS MIBs submitted for = publication - Jul 05 RADIUS CUI draft submitted as a Proposed Standard RFC - Dec 05=A0=A0RFC 3576 MIBs submitted as an Informational RFC - Dec 05=A0=A0RADIUS design guidelines submitted as an Informational RFC - Jul 06=A0(W)LAN attributes draft submitted as a Proposed Standard RFC - Sep 06=A0=A0RADIUS issues and fixes draft submitted as an = Informational RFC - Dec 06=A0=A0RADIUS Prepaid draft submitted as a Proposed Standard RFC =20 4. Jari Arkko on 2486bis status - updated NAI. draft-ietf-radext-rfc2486bis-05.txt -- Document has been sent to IESG and has a single issue. Some minor = modifications a have been made. -- Extended to use international characters, but UTF-8 is a problem. = Needs to be made clear in the ABNF. =20 -- Issue 18n includes a question about unassigned code points. Should = they be prohibited or allowed? Approach is to prohibit them from a = specification perspective.=20 -- Related issue with ! syntax. Unclear what to do and we need the = help of internationalization gurus. Username part may have different = rules from IDN part of the NAI. -- Chairs will solicit consultation from an expert in = internationalization issues. -- Conversation to be moved to list. 5. Wolfgang Beck on auth digest draft draft-ietf-radext-digest-auth-01.txt =20 -- There are several security design alternatives; encryption per = RFC2868, wait for draft-zorn-radius-encattr or mandate IPSec if RADIUS = client supports TLS. Concern about the draft-zorn... being "late" (now = an individual submission). Wolfgang believes the IPSec solution is the = only viable option. =20 -- Concern about encrypted RADIUS attributes not providing the same = level of protection as TLS (or IPSec). It was pointed out that most = operators already protect their RADIUS traffic, but there is some debate = about this. =20 -- Other misc. changes in the works regarding alignment with = diameter-sip-app, digest-Qop, multiple authorization, and document = re-arranging.=20 -- There is a comment that the parameters being included in the SIP-AOR = are not properly discussed in the draft. 6. Avi Lior on the CUI draft draft-ietf-radext-chargeable-user-id-03.txt =20 -- All issues in the tracker have been addressed to date. One issues = raised recently, but not in the tracker yet. Resolution has been agreed = on the list. Requesting that the document move to WG last call. 7. Dave Nelson on the base MIBs Revision draft-nelson-rfc2618bis-00.txt draft-nelson-rfc2619bis-00.txt draft-nelson-rfc2620bis-00.txt draft-nelson-rfc2621bis-00.txt =20 -- Asked to update the current set of four MIBs. There are now four = drafts that update, but not obsolete the existing RFCs. =20 -- Added support for IPv4/IPv6 textual conventions. Using the SMI = AUGMENTS syntax to perform the update and non-obsolesce of the existing = objects.=20 -- To advance these, there will need to be updates to the boilerplates.=20 -- Has been some informal MIB Doctor review and will be requesting = formal review and recommend they become WG documents. =20 -- Dan Romascanu doesn't believe that the boilerplate needs to be = updated. Dave Harrington is the one who made this assertion, in his = slides at IETF60/58. This is only related to the Standards Track MIBs. = The AD wasn't clear what the procedure is. =20 -- Glen Zorn would like to see the current Standard Track MIBs move to = Draft Standard status. We need to understand what all is implied by = taking this action. 8. Greg Webber on the RFC3576 MIBs=20 draft-decnodder-radext-dynauth-client-mib-03.txt draft-decnodder-radext-dynauth-server-mib-03.txt -- This adds support for the new extensions in 3675. Addresses = IPv6/IPv6 textual conventions. =20 -- Four issues are noted: 31, 44, 45, 48. Various changes to support = the resolution of these issues.=20 -- Proposed to make these a WG item. The WG seems to agree. Validate = on the list. 9. Mauricio Sanchez on the IEEE 802 Attributes draft-congdon-radext-ieee802-03.txt =20 -- Avi Lior and Farid Adrangi have contributed to this as well and = should be noted as authors. =20 -- Because of overlap, the draft-lior-redirection draft has been merged = in and some changes to the format were made. The redirection draft was = dropped.=20 =20 -- NAS-Filter-Rule supports L2 filters now and supports a flush action. -- 802.11i Key attributes were removed to avoid NIST issues. It was = noted that all 802.11 attributes were pulled and they shouldn't have = been.=20 -- The dropping of the Key attributes is a concern by Glen Zorn. Since = NIST has a bad track record of responding in a predictable timeframe, we = don't want to create a dependency.=20 -- Key attributes were copied for Key space so the code points already = exist, so therefore some of these already exist.=20 -- Several issues have been addressed: 37, 38, 39.=20 -- Will bring back non-key related attributes for 802.11. -- The TNC of the TCG is interested in these attributes, so is 3GPP. = John Vollbrecht will present on the TCG/TNC in the EAP WG tomorrow. -- Next steps involve incorporating the capabilities discovery direction = of the group, more formatting of NAS-Filter-Rule and its syntax, improve = document flow, considering a title change.=20 -- Other SDOs depend on this, so rapid progress is necessary.=20 -- Question about the extended attribute usage being removed. Glen Zorn = is happy about this. =20 -- Question about accounting records used on redirect. There is a stop = and start used, but could there be a single record? Avi Lior believes = it is possible to do this and an Interim should be used. 10. Dave Nelson on Management Authorization Attributes draft-nelson-radius-management-authorization-01.txt=20 =20 -- Currently two attributes for management; CLI, privileged and = non-privileged. The draft would like to extend this for SNMP and HTTP = management. Would like the extend the privilege levels, support SSH, = create a label for policy scope, leverage split horizon views of = management, and do this on a per-command basis (parity with TACACS+)... = a lot of improvements. =20 -- The design is to add a Framed-Management service type and a = Management-Access-ID (label), Management-Protocol, = Non-Framed-Management-Command and operation, Management-Context for = logging and human consumption.=20 -- Today Enterasys uses VSA and believe that there is value in = multi-vendor environment so would like to open them up. Would like to = ask that this become a WG item. Poll of the room indicated about six to = eight interested parties. Will validate on the list. =20 -- Glen Zorn questions the wisdom of using RADIUS accounting for an = audit log of command line changes because of the size of Radius logs - = perhaps syslog would be better. =20 -- Unclear how this works with SNMP. The idea is it would leverage the = ISMS WG work. The ISMS group should certainly review this and an action = was taken to put them in the loop. =20 -- The ISMS scope, however, does not cover management access control.=20 -- Dave Perkins asks if some of the other functionality is to provide = parity with TACACS+. Yes, some of this is going to address that, but = there is also the goal of addressing other management interfaces other = than CLI. Dave Perkins points out that it is hard to do = command-by-command authorization because you need to understand the = level within the CLI you are operating at. Greg Weber indicated that = the Management-Context attribute is defined to address this. 11. Avi Lior on Prepaid Extensions draft-lior-radius-prepaid-extensions-07.txt=20 =20 -- Now at draft 7. During IETF60 they were at draft 5. A number of = changes identified in the slides.=20 -- Interesting complexities defined to transfer prepaid credit from the = NAS to the device. -- The goal is to be similar to Diameter Credit Control, but integration = will be hard to do. There are differences between Quotas in the two = schemes; one is a delta the other is absolute. More thought needed = here.=20 -- Is the draft dependent on RFC3576? No, according to Avi Lior, but = some disagreement on this. Any dependency can be taken out, but it = would be good to have it in. 12. Avi Lior on Bandwidth Parameters draft-lior-bandwidth-capability-00.txt=20 =20 -- Draft has been thrashing about. The current draft strives towards = simplicity with a simple set of attribute with reasonable tightness.=20 -- There are ingress and egress bandwidth attributes, and a Bandwidth-ID = for labels (similar to Filter-ID). Can use either of these, but not = both at the same time.=20 -- There is a capability to advertise, select and confirm bandwidth = usage. Ability to update these dynamically as well. Mutual agreement = among the parties? -- Reporting via start/stop or interim and the NAS decides which way it = wants to do this. -- Bernard claims this draft has grown way out of scope. Need = discussion on what is the appropriate set of functionality=20 =20 -- Question about the Bandwidth-Profile-ID and what are the scalability = issues? Should it be part of the Filter-Rule attributes? Avi Lior = believes it would be a bad idea to overload Filter-Rule with bandwidth = as well. 13. Dave Nelson on RADIUS Issues and Fixes =20 -- Kicking off a discussion on problems and points of confusion in = existing RADIUS RFCs. Not to be used for new functionality. Goal is an = informational RFC.=20 -- Glen Zorn questions how we fix problems if we can't add new = functionality. Dave Nelson recommends that we document the issues and = then consider fixes that might require a re-charter, i.e. a normative = change to existing RADIUS RFCs, on a case-by-case basis. =20 -- Slides presented list a large number of current issues and = clarifications to be addressed. =20 -- Next steps are to get discussion on the issues and begin a draft. = Dave will kick off as editor but would like someone else to take over at = some point soon. 14. Greg Weber on RADIUS usage in L2PVN WG draft-ietf-l2vpn-radius-pe-discovery-01.txt=20 =20 -- A current working group item in this group. How to provision = customer equipment as it joins a provider network and determine the set = of interconnected pseudo-wires. =20 -- This is not a traditional use of RADIUS because it is authenticating = equipment not users, but still using User-Name to identify the customer = equipment.=20 -- Accounting hasn't been addressed much yet. Looking into scalability = concerns. There is a big question around how 'zero-touch' can be = supported? Would like to get customer equipment with credentials so it = could do something like 802.1X. This is really how devices are being = provisioned and authenticated into the network.=20 -- Are there any dependencies? No objective to do this. Does RADEXT = really need to look at this other than provide expertise review?=20 -- There is some concern about using complex and formatted radius = attributes with structure as this proposes. There is a general concern = about how to represent complex attributes such as NAS-Filter-Rule in 802 = extensions. 15. Jari Arkko on Policy Decisions for Multiple Services draft-arkko-radext-multi-service-decisions-01.txt=20 -- Work from EAP lower layer efforts. A single subscription can have = access to multiple services and providers may have to apply policies on = how to allow access.=20 -- This is only a problem in roaming environments. How to identify = virtual services links such as PANA or IPSec. What is the NAS-Port-Type = for these? It might be better for NAS-Port-Type to represent the = physical port and use something else to represent the virtualized or = higher-layer. Unclear that tunnel-type would be a good option either. = Perhaps the combination of NAS-Port-Type and Tunnel-Type to describe = this.=20 -- Several issues with how to use tunnel attributes for these virtual = services in the slide. Should there be a definition of something new or = a clarification of how to use existing attributes? It was pointed out = that this is somewhat like the management attributes being defined = because of using Radius in new ways. This advocates creating new = attributes for this. -- What happens if the NAS "lies"? -- Several people are interested in the problem, but no-one has a = solution yet. Next steps are to put this document into the pre-working = group item review list. 16. Avi Lior on RADIUS Location Attributes (GEOPRIV WG) draft-ietf-geopriv-radius-lo-02.txt -- A number of GeoPriv issues were discussed from the slides=20 -- One particular resolution is to add a capability attribute.=20 -- Dave Nelson points out that this is another space where guidance on = structured attributes would help=20 -- Jari Arkko comments on Issue 70. He believes it is a requirement = that a policy must be followed if the client demands it, but there is no = link layer that advertises the clients demands. Somehow it would be = good if the client could tell the NAS that it didn't want the = information to be transferred.=20 -- All the GeoPriv wants to do is be able to advertise location, but = there are requirements to advertise additional objects that are location = related. There is a proposal to have an additional type of location = information beyond civic and geographical to allow this information to = be advertised. This issue has been raised in the GeoPriv WG=20 -- There is a question about which device has location information about = what entities and what is advertised? There is location of NAS and of = end-user which are separate. How would a NAS get location information = of the user? Avi points out the goals are to get user location = information, and if the user can't do this or there is no channel to = communicate this, the NAS may use other information to represent the = user's location with reduced capability. -- This discussion was taken offline to the list. 17. Avi Lior on RADIUS Capability Exchange=20 -- There has been a lot of discussion around NASes advertising their = capabilities and this draft attempts to capture this and the = requirements for capability advertisement.=20 -- There are cases where the home AAA server needs to know what the NAS = is capability of to properly provision services and policies (e.g. = prepaid)=20 -- There are cases where the NAS would like to tell the AAA server that = it needs to see certain attributes.=20 -- There are cases where the AAA server would like to get something = specific from the NAS.=20 -- There are issues with how to represent granularity of the = capabilities.=20 -- This mechanism is really necessary to implement mandatory attribute = requirements.=20 -- A question is if this implies that the server needs to be stateful, = and now does the NAS need to advertise this in every access request? = The goal would be to keep the server stateless. If the info is small it = might not be a problem to include in each exchange.=20 -- What are the scenarios for capability exchange seen in Diameter?=20 -- Glen Zorn believes the exchange makes more sense when there is a = persistent session between the NAS and server. The NAS support won't = change session to session, but if we don't want the Radius server to = keep NAS state then how will it understand the capabilities? The = concept of a permanent session between the NAS and the server is really = about keeping state.=20 -- Jari Arkko points out that we are really doing both policy and = capability advertisement. End-of-meeting. Regards, =A0 Dave =A0 David B. Nelson Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01810-1008 Phone: (978) 684-1330=A0=20 E-mail: dnelson@enterasys.com =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: Fri, 01 Apr 2005 00:14:20 +0000 Message-ID: <424C921C.6090205@cisco.com> Date: Thu, 31 Mar 2005 16:13:16 -0800 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Review of draft-chiba-radius-dynauthor-ext-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, Since we are on the topic of adding items to the WG. I would like to propose that this draft be considered as well. Some views/comments inline. Bernard Aboba wrote: > RFC 3576 introduced the concept of dynamic authorization to RADIUS, where > a session that had previously been authorized can be terminated or > modified by an exchange initiated by the RADIUS server. > > In order to be able to utilize the facilities introduced in RFC 3576, it > is necessary for the server initiating a CoA or Disconnect-Request to have > kept state on the session it is looking to modify. This includes > recording the NAS with which the session was initiated (NAS-IP-Address, > NAS-Identifier, NAS-IPv6-Address) as well as the session itself > (User-Name, NAS-Port, Framed-IP-Address, Called-Station-Id, > Calling-Station-Id, Acct-Session-Id, Acct-Multi-Session-Id, NAS-Port-Type, > NAS-Port-Id, Originating-Line-Info, Framed-Interface-Id, > Framed-IPv6-Prefix). > > However, since RADIUS Accounting packets may be lost, it is possible for > the state on the server to have gotten out of sync. For example, an > accounting server may not receive an Accounting STOP, and therefore may > think that a session continues when in fact it had ended. It is also > possible for an Accounting Start or Interim message to be lost in which > case the server may not be aware that it had started (until a subsequent > Interim or STOP message is received). > > In these circumstances, it is possible for a server initiating a CoA or > Disconnect-Request to receive an error message in response, indicating > that the session did not exist. > > Where this occurs, how can the server resynchronize its state? Note that > to achieve the resynchronization it may not be sufficient just to retrieve > the current state of the NAS that responded with an error; the session > may have moved elsewhere, and that Accounting message may have been lost > too (e.g. the server knows of no other session on another NAS with the > same multi-session-id). > > In order to address this problem, the document introduces a Query-Select > attribute, enabling a server to query for sessions of a given type. > > The query syntax is quite general, allowing a number of attributes to be > returned based on whether the service or expression matching. > > Since modern NAS devices can be very large, supporting hundreds of > sessions, it does seem necessary to be able to support selective queries, > since a complete dump of NAS session state could easily exceed the maximum > RADIUS packet size of 4096 octets. > Besides the above being an excellent justification, it should be noted that, modern networks now include elements such as the web portal. These elements use state information other than the traditional "billable" state that is found in Accounting-Requests. > However, the query syntax introduces an entirely new "URI"-based model for > RADIUS service types, which has no precedent within previous RADIUS > documents. The query syntax also appears to be more complex than is > required to solve the problem as stated above. Many NAS devices remain > short of resources, so that they cannot support complex queries such > as is proposed here. > The URI based model proposed provides a degree of flexibility and is not intended to be used for complex querying. > For example, in order to attempt to locate the sessions of a given user, > an equality query for the User-Name attribute would be sufficient. The > same could be said of other session attributes; there is no need to do > other types of comparisons on such session identifiers. > Agreed. The draft however proposes to give the ability to drill down to a specific detail. For example, many devices now support the notion of 'services' that may be deployed for a given session, with each 'service' affecting a partial/complete data-flow for a given session. For instance, an MP3 'service' would be treated differently from a data 'service' which would itself be treated differently from a video-on-demand 'service'. Service Providers are now looking at opportunities to generate revenue by providing QoS guarantees on these different 'services' with policies in effect to guarantee SLAs. In order to do this, a greater detail of state information is required besides a need to gain more current information than can be gotten from interim updates. Also, these 'services' themselves may be comprised of multiple feature sets that may individually need to be targetted. With all of the above considerations, the draft attempts to provide a flexible querying mechanism. Hopefully, we can agree on a limited scope for this and the authors would definitely appreciate all feedback. > The other element this document introduces is the Authorization-Command. > attribute. The only value of this attribute used is "Query-Only", used > for the query functionality described earlier. > > Since there are already multiple RADIUS command codes defined for resource > querying (23 = Resource-Query-Request, 24 = Resource-Query-Response) it is > not clear why this new attribute is needed. RFC 2882 describes these > commands, but does not provide details on their functionality, and as a > result, it is not clear that whether the functionality provided in this > document already exists. > Besides Resource Querying there is a need to start/stop 'services' on demand. The Authorization-Command would eventually include all use cases. > RFC 3575 includes the following language relating to allocation of new > RADIUS command codes: > > Packet > Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an > IETF RFC, but are reserved until a specification is provided for > them. This is being done to avoid interoperability problems with > software that implements non-standard RADIUS extensions that are or > have been in use on the Internet. Because a new Packet Type has > considerable impact on interoperability, a new Packet Type Code > requires IESG Approval. The intention is that any allocation will be > accompanied by a published RFC. Type Codes 52-249 should be > allocated first; when these are exhausted, Type Codes 14-20, 35-39, > 46-49 may be allocated. For a list of Type Codes, see Appendix A. > > And Service-Type values: > > The exception to this policy is > the Service-Type attribute (6), whose values define new modes of > operation for RADIUS. Values 1-16 of the Service-Type attribute have > been allocated. Allocation of new Service-Type values are by IETF > Consensus. The intention is that any allocation will be accompanied > by a published RFC. > > Between command codes and Service-Type values, it seems to me that the > functionality required in this document can be covered, so that allocating > a new Authorization-Command attribute is not necessary or desirable. > As RADIUS has been adopted for the more recent use cases, beyond that of the original dial world, its values now represent a mixed bag of loosely coupled information. In its original form it was used to denote the type of connection allowed for the user. In more recent times its been used for indicating resource management command "Authorize-Only" and in the RFC3576 a complete behaviour has been encoded(send Access-Request). Hence, it was felt that a new attribute would better serve the draft if its contents had clearly related values. Regards, Murtaza > -- > to 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: