Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 Jul 2006 22:48:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: Status of draft-lior-radius-prepaid-extensions? Date: Mon, 31 Jul 2006 15:48:14 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CD10@xmb-sjc-215.amer.cisco.com> Thread-Topic: Status of draft-lior-radius-prepaid-extensions? Thread-Index: Aca082d9fg+iYnkLTSqqdsPEz5n0Kg== From: "Glen Zorn \(gwz\)" To: DKIM-Signature: a=rsa-sha1; q=dns; l=307; t=1154386105; x=1155250105; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:Status=20of=20draft-lior-radius-prepaid-extensions?; X=v=3Dcisco.com=3B=20h=3DKEHNfrW8QqMjt/4XvXlZQt/tvUk=3D; b=W2sWpbJYVAQTUkRrP/WkAcSrNGo0/OQTi9+xzDxpstuWIJqKFxlSg/gFN4gCHdrpQoxoYv0O cGbjY0u4eweqEILjrtyiJGJtP3Uu6rZZi+XPOXsGc5ekmXXXPSPOVGju; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Hi. I'm just wondering if this is going to be adopted as a WG item, published as an individual submission or ? Given that there are apparently at least a couple of independent, interoperable implementations it seems a bit silly to let it die on the vine... ~ gwz The Color Brown is a trademark. -- to unsubscribe send a message to radiusext-request@ops.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, 31 Jul 2006 21:58: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: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Mon, 31 Jul 2006 14:57:11 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262551CD0F@xmb-sjc-215.amer.cisco.com> Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: Acakalzk8e/LPlTAT0q7ARGaun4hVwQf7mWw From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=2886; t=1154383049; x=1155247049; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Consensus=20Call=3A=20=20=22Sense=20of=20the=20Room=22=20at=20RA DEXT=20WG=20meeting=20at=20IETF=2066; X=v=3Dcisco.com=3B=20h=3DXmpMGUqBE2WqvZa6PyxBCSUpcOA=3D; b=Y1zhfnYUvN2CPBg5V4OG/2ghnGmK8ETuwrpbOItHsSEZtu2hoyU9NsCy904A46NM0QVmfsYp wq5Bfm+ijognPKvpTqMp6HtF9ruZ7O4R9fk0uTiGie5DP+Wb9XkOwvYN; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled: > At the RADEXT WG meeting at IETF 66, we took a "sense of the room" > with respect to what the WG should do with respect to the exhaustion > of the =20 > RADIUS standard attribute space. A consensus appeared to emerge.=20 > We=20 > would now like to confirm that consensus on the RADEXT WG mailing > list.=20 >=20 > In your reply to this message, please state whether you support the > consensus described below, or whether you disagree with it (and if > so, how). =20 Sorry for the tardiness of my reply. >=20 > The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: >=20 > * Exhaustion of the RADIUS standard attribute space is a problem that > should be solved.=20 I do not agree with this; as I've pointed out ad nauseam, this problem = was already solved some years ago in Diameter. The current problem is = that some folks don't want to accept the solution (though, strangely = enough, those same folks seem to be in a rush to turn RADIUS into = Diameter (again)). > * RADEXT WG is the place to solve the problem. If the first statement garners consensus, I can't think of any other = place to do it. > * The attribute exhaustion problem should be the focus -- not adding > other capabilities to RADIUS (such as support for the Diameter data > types). =20 I think that the attribute exhaustion problem should definitely be the = focus of the solution for the attribute exhaustion problem ;-). = Seriously, I think that one you solve that problem, the solutions to a = bunch of other problems will pretty much just fall out. >=20 > In reviewing the potential solutions to the problem, the people > present at the meeting appeared to strongly favor a RADIUS extension > approach such as that outlined by Lior & Li (RADIUS attribute > extension), over the current proposals for adding Diameter AVP > support to RADIUS (Wolff & Weber and Mitton proposals). =20 Agree strongly. > Some of the > reasoning behind this was that adding support for Diameter AVP > parsing and dictionary support would involve a substantial portion of > the effort to develop a Diameter server, whereas simply adding > support for an extended space vwould involve less effort, and would > therefore be more likely to be deployed. =20 >=20 > This consensus, if it is confirmed on the mailing list, has > implications for the Design Guidelines document. If the RADIUS > attribute space is extended without changing the RADIUS protocol in > other ways, then Design Guidelines document needs only to focus on > guidelines for the RADIUS protocol. Thus, the Design Guidelines > effort is considerably simplified. =20 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: Thu, 27 Jul 2006 17:00:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 13:00:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939D@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxAAAG/iN AAAGEboAACrY7Q From: "Nelson, David" To: , David Harrington writes... > We separated the security and transport mappings from the message > format in the RFC3411 architecture; SNMPv3 refers to a message format. It also implies the only version with any real security. > Please do not bind these concepts unnecessarily in your RADIUS > proposal. I think we can simplify the naming, as Dan suggests, and refer to SNMP over SSH. We can add a statement in the security considerations section that strongly recommends use only with SNMP versions that have real security, i.e. v3 (and higher). > I can envision an SNMPv4 message processing model that uses an XML > message encoding to improve compatibility with netconf and with data > models from other SDOs. Good luck with that! :-) =20 > I do not see a technical engineering reason to limit the RADIUS > authorization to SNMPv3 over SSH, as compared to SNMP over SSH. Right, but I think it might be fodder for 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: Thu, 27 Jul 2006 16:08:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Thu, 27 Jul 2006 12:08:16 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcaxU+p7BvrYxGjrRsuTecazVZeRSwAQsGuw From: "Avi Lior" To: "Hannes Tschofenig" Cc: "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" , , I know, but AAA and Liberty Alliance perform different functions and probably have different performance requirements. But you are probably right. My developers will have to cave one day. The question is, will they kill me first or will I manage to survive.=20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Thursday, July 27, 2006 4:08 AM > To: Avi Lior > Cc: Glen Zorn (gwz); David Harrington; Eliot Lear;=20 > isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Avi, >=20 > your developers might need to get used to XML sooner or later=20 > anyway based on the excitement for Liberty Alliance nowadays.=20 > The functionality of the asserting party in SAML is very=20 > close to what a AA(A) does today. >=20 > Ciao > Hannes >=20 > Avi Lior wrote: > > Hi Hannes, > >=20 > > When I wrote the word "assertion" I was thinking a SAML assertion. > >=20 > > A word of caution though, everytime I mention XML to my AAA=20 > developers=20 > > they conspire to kill me. > >=20 > > XML, parsing strings etc are performance killers for a AAA server. > >=20 > > =20 > >=20 > >=20 > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: Wednesday, July 26, 2006 4:55 AM > >>To: Avi Lior > >>Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; isms@ietf.org;=20 > >>radiusext@ops.ietf.org > >>Subject: Re: Follow up on Authorize Only issue (was RE:=20 > >>[Isms] ISMS session > >> > >>Hi Avi, > >> > >>I like the idea of using some information to tie the authentication=20 > >>and the authorization process/exchange together. In fact we=20 > discussed=20 > >>this at the last IETF meeting when David gave his presentation. > >> > >>I suggested to use an existing mechanism to accomplish this=20 > binding,=20 > >>namely SAML. I can elaborate a bit more about the details=20 > if someone=20 > >>case about it. > >> > >>Ciao > >>Hannes > >> > >>Avi Lior wrote: > >> > >>>I proably did not make myself clear....or maybe I did and I > >> > >>am missing > >> > >>>something. > >>> > >>>When the NAS sends the Access-Request Auth-Only message I > >> > >>agree that > >> > >>>it MUST contain Message-Authenticator(80) etc... > >>> > >>>What I meant is that it would be nice if there was a token or an=20 > >>>assertion that came from the place that did authenticate > >> > >>the user to > >> > >>>indicate in a cryptographic way that this user was authenticated. > >>> > >>>The AAA server can use that token to verify that the user was=20 > >>>authenticated by an entity that it trusts. Like a=20 > kerberose ticket. > >>> > >>> > >>> > >>> > >>> > >>>>-----Original Message----- > >>>>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > >>>>Sent: Tuesday, July 25, 2006 3:47 PM > >>>>To: Avi Lior; David Harrington; Eliot Lear > >>>>Cc: isms@ietf.org; radiusext@ops.ietf.org > >>>>Subject: RE: Follow up on Authorize Only issue (was RE:=20 > >>>>[Isms] ISMS session > >>>> > >>>>Avi Lior supposedly scribbled: > >>>> > >>>> > >>>> > >>>>>Hi, > >>>>> > >>>>>If I was specifying how this is done: > >>>>> > >>>>>It would be nice if the AAA client could return some sort > >>>> > >>>>of token to > >>>> > >>>> > >>>>>the AAA server to assert that the user has been > >> > >>authenticated by an > >> > >>>>>entity that it trusts. The token can be generated by the > >>>>>Authentication Server. =20 > >>>>> > >>>>>We need this assertion to make sure we deliver the=20 > correct profile. > >>>> > >>>>I disagree: the fact that the message is being sent by an=20 > >>>>authenticated client at all says that the user has been > >> > >>authenticated > >> > >>>>elsewhere. Note that safety requires the inclusion of a > >> > >>MAC (either > >> > >>>>the Message-Authenticator or preferably the=20 > >>>>Message-Authentication-Code Attribute) in the Access-Request. > >>>> > >>>>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: > >>> > >>> > >> > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in 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: Thu, 27 Jul 2006 15:29:54 +0000 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 18:29:42 +0300 Message-ID: Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxAAAG/iNA= From: "Romascanu, Dan \(Dan\)" To: "Nelson, David" , , =20 =20 > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com]=20 > Sent: Thursday, July 27, 2006 6:15 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] Summary of Authorize Only issue >=20 > Dave Harrington writes... >=20 > > I think "SNMP over SSH" would be appropriate. I do not see=20 > a reason to=20 > > limit it to SNMPv3. >=20 > That's fine by me, if that's the consensus. In the past,=20 > I've been encouraged to omit support for v1 and v2c in I-Ds,=20 > as those versions have been deprecated. The comment was from=20 > Bert Wijnen, in relation to protocol selection attributes I'd=20 > included for v1 and v2c in the NAS-Management draft. >=20 I believe that that recommendation was correct and continues to stand. The name does not bother me too much, as SNMPv3 is the only standard version of SNMP but defining special attributes or features for v1 and v2c should need some strong argumentation.=20 Dan -- to unsubscribe send a message to radiusext-request@ops.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, 27 Jul 2006 15:15:28 +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: [Isms] Summary of Authorize Only issue Date: Thu, 27 Jul 2006 11:14:53 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939B@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/AAAsddQAAmTqxA From: "Nelson, David" To: , Dave Harrington writes... > I think "SNMP over SSH" would be appropriate. I do not see a reason to > limit it to SNMPv3. That's fine by me, if that's the consensus. In the past, I've been encouraged to omit support for v1 and v2c in I-Ds, as those versions have been deprecated. The comment was from Bert Wijnen, in relation to protocol selection attributes I'd included for v1 and v2c in the NAS-Management draft. > > > > (b) Some other authentication mechanism/service > > provides initial authentication (and no > > authorization) of SNMPv3 over SSH. >=20 > Whether the other services provides authorization or not is > immaterial. Perhaps immaterial to RADIUS requirements, per se, but certainly not immaterial to the security considerations for SNMP over SSH as a whole. > > (c) Some other authentication mechanism/service > > provides initial authentication (and no > > authorization) of SNMPv3 over SSH. RADIUS > > provides base-service authorization of > > SNMPv3 over SSH (but no authentication). >=20 > I'm not sure anybody has asked for this combination, but I suppose we > don't need to rule it out. Included for completeness. Wes H. has indicated, in a separate post, that this might be useful. > I would like to make sure everybody understands that the NAS is the > managed device, not only edge devices providing network access > services; Every SNMP-manageable device in the network might be > considered a NAS in this scenario. Yes. In "RADIUS-speak", the terms "NAS" and "RADIUS Client" are often used interchangeably. In this use case, it would probably be desirable to favor the term "RADIUS Client", for added clarity. > Educate me. Why primarily the password authentication? Because this is the RADIUS authentication method most commonly used for SSH deployments today, I believe. > Does this imply a (plaintext) password? Yes, although RADIUS encrypts that password on the wire, on a hop-by-hop basis, using the shared secret. > Other authentication mechanisms might be preferable to passwords; > I assume RADIUS supports a wide range of authentication mechanisms. No, it does not. The existing RADIUS authentication methods are: -- password -- textual challenge / response -- CHAP (MD5 Digest) -- EAP (basically any EAP method) -- HTTP Digest (newly added) We already know that EAP is not permissible for use with network management authentication, because of its narrow applicability statement. Practically speaking, that leaves us with password and CHAP. I believe most of the current SSH usage of RADIUS for network management uses password. > I think there are three extended SNMP use cases that involve RADIUS =20 > (c) RADIUS does not perform authentication or > base-service authorization. > Some other authentication mechanism/service > provides initial authentication and presumably > base service authorization for SNMP over whatever > secure transport, such as SNMP using USM over UDP, > or SNMP using USM and TCP/IPv6, or SNMP using Kerberos > and SCTP, or SNMP using 802.1AE and Ethernet. > The access control subsystem requests from RADIUS > ONLY the granular access control authorization > associated with the otherwise-authenticated user. > (e.g., hey RADIUS, which group is this guy in?) Juergen S., in a separate post, suggests that the two be collapsed into one. I'll ponder this a bit and propose something that attempts to address both suggestions. =20 > Who sets the policy the RADIUS server will enforce? The system administrator. > i.e., how does the RADIUS server know which attributes contain > security-sensitive information related to a user? That is an implementation detail of the RADIUS Server, and not an on-the-wire protocol issue. I suggest that the document include implementation guidance on this issue, perhaps in the security considerations section, and that the protocol be designed so as to provide sufficient information for an implementation to be capable of accomplishing this goal. It would certainly be possible to make a (non-exhaustive) list of sensitive attributes, much as we make a list of sensitive objects in the security considerations section of MIBs. -- to unsubscribe send a message to radiusext-request@ops.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, 27 Jul 2006 10:54:59 +0000 Message-ID: <44C87454.9020007@gmx.net> Date: Thu, 27 Jul 2006 10:07:48 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Avi Lior CC: "Glen Zorn (gwz)" , David Harrington , Eliot Lear , isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Avi, your developers might need to get used to XML sooner or later anyway based on the excitement for Liberty Alliance nowadays. The functionality of the asserting party in SAML is very close to what a AA(A) does today. Ciao Hannes Avi Lior wrote: > Hi Hannes, > > When I wrote the word "assertion" I was thinking a SAML assertion. > > A word of caution though, everytime I mention XML to my AAA developers > they conspire to kill me. > > XML, parsing strings etc are performance killers for a AAA server. > > > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Wednesday, July 26, 2006 4:55 AM >>To: Avi Lior >>Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; >>isms@ietf.org; radiusext@ops.ietf.org >>Subject: Re: Follow up on Authorize Only issue (was RE: >>[Isms] ISMS session >> >>Hi Avi, >> >>I like the idea of using some information to tie the >>authentication and the authorization process/exchange >>together. In fact we discussed this at the last IETF meeting >>when David gave his presentation. >> >>I suggested to use an existing mechanism to accomplish this >>binding, namely SAML. I can elaborate a bit more about the >>details if someone case about it. >> >>Ciao >>Hannes >> >>Avi Lior wrote: >> >>>I proably did not make myself clear....or maybe I did and I >> >>am missing >> >>>something. >>> >>>When the NAS sends the Access-Request Auth-Only message I >> >>agree that >> >>>it MUST contain Message-Authenticator(80) etc... >>> >>>What I meant is that it would be nice if there was a token or an >>>assertion that came from the place that did authenticate >> >>the user to >> >>>indicate in a cryptographic way that this user was authenticated. >>> >>>The AAA server can use that token to verify that the user was >>>authenticated by an entity that it trusts. Like a kerberose ticket. >>> >>> >>> >>> >>> >>>>-----Original Message----- >>>>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >>>>Sent: Tuesday, July 25, 2006 3:47 PM >>>>To: Avi Lior; David Harrington; Eliot Lear >>>>Cc: isms@ietf.org; radiusext@ops.ietf.org >>>>Subject: RE: Follow up on Authorize Only issue (was RE: >>>>[Isms] ISMS session >>>> >>>>Avi Lior supposedly scribbled: >>>> >>>> >>>> >>>>>Hi, >>>>> >>>>>If I was specifying how this is done: >>>>> >>>>>It would be nice if the AAA client could return some sort >>>> >>>>of token to >>>> >>>> >>>>>the AAA server to assert that the user has been >> >>authenticated by an >> >>>>>entity that it trusts. The token can be generated by the >>>>>Authentication Server. >>>>> >>>>>We need this assertion to make sure we deliver the correct profile. >>>> >>>>I disagree: the fact that the message is being sent by an >>>>authenticated client at all says that the user has been >> >>authenticated >> >>>>elsewhere. Note that safety requires the inclusion of a >> >>MAC (either >> >>>>the Message-Authenticator or preferably the >>>>Message-Authentication-Code Attribute) in the Access-Request. >>>> >>>>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: >>> >>> >> > > -- > to 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, 27 Jul 2006 08:04:35 +0000 Date: Thu, 27 Jul 2006 10:03:47 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: [Isms] Summary of Authorize Only issue Message-ID: <20060727080347.GB27196@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Wed, Jul 26, 2006 at 03:56:04PM -0400, Nelson, David wrote: > (2) There are two extended SNMP over SSH use cases: > > (a) RADIUS provides initial authentication and > authorization of SNMPv3 over SSH, base-service > authorization, and (optionally) granular access > control authorization. > > (b) Some other authentication mechanism/service > provides initial authentication (and no > authorization) of SNMPv3 over SSH. RADIUS > provides base-service authorization and > (optionally) granular access control > authorization. > > Note that "granular access control" means a mapping to the VACM or some > other Access Control Subsystem. > > These use cases are currently out of scope for the ISMS WG charter, but > might be added at a later date. Note that the reference "these use cases" is somewhat ambiguous. I assume you refer to (2a) and (2b). But even with this interpretation, it is only the optional part which is out of scope for the ISMS WG. Personally, I consider provisioning of SNMP access control mappings via RADIUS authorization a functionality which is totally independent of authentication and base-service authorization. So perhaps (2a) and (2b) should be combined into an SNMP access control provisioning use case: (2) There is an SNMP access control provisioning use case: RADIUS provides authorization information to be used by SNMP access control models, for example by providing a mapping of securityName to securityGroup, for use with the VACM. An example of such an attribute is Management-Policy-ID, conceptually similar to Filter-ID. Due to the strict separation of access control from authentication in the SNMP architecture, this requires that RADIUS provides an Authorize Only service for SNMP usage. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, 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: Wed, 26 Jul 2006 20:19:54 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: Summary of Authorize Only issue Date: Wed, 26 Jul 2006 16:19:32 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021939A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Summary of Authorize Only issue Thread-Index: Acaw7+IqQclqiKSMT+eqChmbGAxJygAADkig From: "Nelson, David" To: , Bernard Aboba writes... > For this to be successful, the RADIUS server needs to know what=20 > service is being requested by the NAS, so that it can limit the=20 > attributes to those relevant to that service (or refuse to=20 > authorize the service). The service cannot be characterized by > saying it is "authorize-only" -- that is merely a particular=20 > (authorize-only) mode of a particular service which needs to > be specified by the NAS. I agree (100%). =20 > >In any of the use cases, it is important that the NAS, i.e. > >the RADIUS Client, be able to communicate the kind of service > >being sought via hint attributes to the RADIUS Server, in the > >Access-Request message. >=20 > Service-Type is not a "hint".=20 It is when it appears in an Access-Request message. This is the context of the foregoing paragraph. > A RADIUS client that receives=20 > an Access-Accept with an unknown Service-Type does not treat=20 > the attribute as a "hint" -- it treats it as an Access-Reject.=20 > This is mandatory behavior in RFC 2865. I agree, when it appears in an Access-Accept message. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Jul 2006 20:12:59 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: Summary of Authorize Only issue Date: Wed, 26 Jul 2006 13:12:46 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >(4) RADIUS Servers SHOULD exercise appropriate policy enforcement in >terms of providing any NAS with attributes that might disclose security >sensitive information related to a user, e.g. keys, unless that user has >been successfully authenticated to the RADIUS Server via the NAS in >question. This affects RADIUS Server behavior during any Authorize Only >service provisioning. For this to be successful, the RADIUS server needs to know what service is being requested by the NAS, so that it can limit the attributes to those relevant to that service (or refuse to authorize the service). The service cannot be characterized by saying it is "authorize-only" -- that is merely a particular (authorize-only) mode of a particular service which needs to be specified by the NAS. >In any of the use cases, it is important that the NAS, i.e. the RADIUS >Client, be able to communicate the kind of service being sought via hint >attributes to the RADIUS Server, in the Access-Request message. Service-Type is not a "hint". A RADIUS client that receives an Access-Accept with an unknown Service-Type does not treat the attribute as a "hint" -- it treats it as an Access-Reject. This is mandatory behavior in RFC 2865. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Jul 2006 20:03:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 16:03:22 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219399@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIAAJia2AAABScO A= From: "Nelson, David" To: , Avi Lior writes... > But 3576 and WG decided not to go there. Unless I'm mistaken, RFC 3576 was not the work product of any WG. It occurred after the RADIUS WG closed, and prior to the RADEXT WG opening. > In hindsight, Authorize/Authetnication/Callcheck/etc should have used an > attribute specifically for that purpose. Perhaps. > The lesson is that we should be learning is not to overload attributes. I agree. =20 > I think introducing another Authorize-Only semantic is bad as well. I > think that saying that Authorize-Only is only a 3576 think flies in the > nature of all RADIUS RFCs. There are potential disadvantages, primarily in terms of how existing RADIUS servers are implemented, but I don't see this as quite so much of a problem. > Finally, in view of the overloading of Service-Type, the use of > NAS-Port-Type to provide a context for the type of service being > requested is not ideal but it does work. IMHO, overloading NAS-Port-Type is as bad as, if not worse than, overloading Service-Type. Overloading is overloading. Overloading is bad. ;-) -- to unsubscribe send a message to radiusext-request@ops.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, 26 Jul 2006 19:56: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: Summary of Authorize Only issue Date: Wed, 26 Jul 2006 15:56:04 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219398@MABOSEVS2.ets.enterasys.com> Thread-Topic: Summary of Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplgAAGe8/A= From: "Nelson, David" To: , Let me see if I can summarize the discussion so far, and if folks agree that I've summarized accurately. (1) There are three basic SNMP over SSH use cases: (a) RADIUS provides initial authentication and=20 base-service authorization of SNMPv3 over SSH. (b) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. (c) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. RADIUS provides base-service authorization of SNMPv3 over SSH (but no authentication). Note that "base-service" authorization means that the SSH server in the NAS is allowed to provide connectivity via SSH to the SNMPv3 engine of the NAS. In case (1a) we require the existing RADIUS authentication methods, primarily the password authentication, plus some attributes to authorize the service, such as Service-Type =3D Framed-Management, and Framed-Management-Protocol =3D SNMPv3-over-SSH. In case (1b) there are no requirements for RADIUS. In case (1c) we require the ability for RADIUS to provide an Authorize Only service for SNMP usage. The provisioning attributes are the same as for case (1a). We have seen a considerable amount of discussion on the mailing list of the issues and properties of an Authorize Only service in RADIUS. Many of those discussions focus on potential solutions, but I've restricted this posting to requirements.=20 (2) There are two extended SNMP over SSH use cases: (a) RADIUS provides initial authentication and=20 authorization of SNMPv3 over SSH, base-service authorization, and (optionally) granular access control authorization. (b) Some other authentication mechanism/service=20 provides initial authentication (and no authorization) of SNMPv3 over SSH. RADIUS provides base-service authorization and=20 (optionally) granular access control authorization. Note that "granular access control" means a mapping to the VACM or some other Access Control Subsystem. These use cases are currently out of scope for the ISMS WG charter, but might be added at a later date. In case (2a) the additional RADIUS requirement is for an attribute to authorize granular access control, for example by providing a mapping of securityName to securityGroup, for use with the VACM. An example of such an attribute is Management-Policy-ID, conceptually similar to Filter-ID. In case (2b) the additional requirements for RADIUS include those of case (2a) plus the ability for RADIUS to provide an Authorize Only service for SNMP usage. (3) The basic RADIUS trust model dictates that if a NAS, that possess a valid shared secret with a RADIUS Server, is compromised, nothing in the RADIUS protocol can mitigate that breach, at least in terms of the services to which the NAS mediates access. (4) RADIUS Servers SHOULD exercise appropriate policy enforcement in terms of providing any NAS with attributes that might disclose security sensitive information related to a user, e.g. keys, unless that user has been successfully authenticated to the RADIUS Server via the NAS in question. This affects RADIUS Server behavior during any Authorize Only service provisioning. In any of the use cases, it is important that the NAS, i.e. the RADIUS Client, be able to communicate the kind of service being sought via hint attributes to the RADIUS Server, in the Access-Request message. This has implications on the use of the Service-Type in Authorize Only operations, in which it would otherwise be used as a hint of the requested service, and not the request authentication method. It is also important that the RADIUS Server be able to specify the provisioning of SNMPv3 over SSH service to the NAS in the Access-Accept message. Does this accurately summarize the consensus on this issue? Especially in terms of requirements that ISMS has of RADEXT? Please advise, with suggestions for improvement. -- to unsubscribe send a message to radiusext-request@ops.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, 26 Jul 2006 19:55:36 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 15:55:43 -0400 Message-ID: Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIAAJia2A From: "Avi Lior" To: "Glen Zorn \(gwz\)" , "Nelson, David" Cc: , I agree with Glen.... If the using Service-Type to convey Authorize-Only was a mistake that mistake was made a long time before 3576. During 3576 I did bring up the issue of putting Authorize-Only in service type. My concern then was exaclty what we are facing today. It becomes hard for us to express both that we want to Authenticate or Authorize or and what service this applies to. But 3576 and WG decided not to go there. In hindsight, Authorize/Authetnication/Callcheck/etc should have used an attribute specifically for that purpose. The lesson is that we should be learning is not to overload attributes. I think introducing another Authorize-Only semantic is bad as well. I think that saying that Authorize-Only is only a 3576 think flies in the nature of all RADIUS RFCs. Finally, in view of the overloading of Service-Type, the use of NAS-Port-Type to provide a context for the type of service being requested is not ideal but it does work.=20 Avi > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz) > Sent: Wednesday, July 26, 2006 11:27 AM > To: Nelson, David > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: [Isms] RE: Follow up on Authorize Only issue >=20 > Nelson, David supposedly scribbled: >=20 > > Glen Zorn writes... > >=20 > >>> If this attribute is used for its intended purpose, to allow the=20 > >>> RADIUS server to know what service to provision, then it=20 > cannot also=20 > >>> be used to indicate authorize-only mode. > >=20 > >> Too late, it already is. > >=20 > > Yes, for the Dynamic RADIUS Change of Authorization use case, as=20 > > specified in RFC 3576. It has no formally specified usage outside=20 > > 3576, that I recall. We need not use that method for the "general" > > authorization only case. We could devise a new method, such as the=20 > > Asserted-Identity attribute, and relegate the Service-Type =3D=20 > > "Authorize Only" usage to CoA only. >=20 > We could, but it seems like a waste of attribute space since=20 > the value if any would of necessity be identical to that=20 > carried by the User-Name Attribute. > =20 > >=20 > > I tend to agree with Jeff that this portion if RFC 3576 was=20 > probably a=20 > > "mistake". >=20 > Perhaps, but if so, it lines up very well with the original=20 > definition of the Service-Type Attribute. In fact, I can't=20 > find any trace of the architectural purity imputed to the=20 > Attribute by Jeff: only some of the values of Service-Type=20 > are related to service as he has defined it. Although I=20 > wasn't involved (except as a critic ;-) with the development=20 > of RFC 3576 either, it would make perfect sense to me to add=20 > a value of "Authorize Only" to an Attribute that already had=20 > values of "Authenticate Only" & "Call Check" defined, the=20 > latter being purely authorizational in character. >=20 > > I can say that as I had nothing to do with that document. =20 > Whether it=20 > > was or wasn't, we are not obligated to carry > > that particular usage into other areas of application for RADIUS. =20 > >=20 > >=20 > >=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 >=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: Wed, 26 Jul 2006 18:21:12 +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: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 14:20:54 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219397@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawgwAKGpWILpcdSoqs2LPrH++pYQAXEplg From: "Nelson, David" To: , Juergen Schoenwaelder writes... =20 > Given our current charter, I like to see the RADIUS document we are > chartered to produce focus on the RADIUS SSH user authentication and > RADIUS authorization of the SSH SNMP subsystem. We'll omit any discussion of "fine grained" access control, i.e. anything other than whether the SSH server should offer to make a connection to the SNMP engine, in the -01 version. > Note that this does of course not impact the RADEXT document which > may define all attributes needed to address all the RADIUS related=20 > ISMS requirements. OK, thanks. > I actually like to encourage people to write a document which=20 > explains how VACM can utilize RADIUS to provision the security=20 > name to group name mapping and to post such a document as an=20 > individual draft. I also think that would be useful, and predict that folks are likely to implement such a scheme, whether ISMS takes it up or not. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 26 Jul 2006 18:18:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 11:18:21 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3BF5@xmb-sjc-215.amer.cisco.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawkV/xhIdQshPITY6tHkixAtQnrAASOKSgAAD36qA= From: "Glen Zorn \(gwz\)" To: "Avi Lior" , "Hannes Tschofenig" Cc: "David Harrington" , "Eliot Lear" , , DKIM-Signature: a=rsa-sha1; q=dns; l=4384; t=1153937903; x=1154801903; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DEvtPMlNbcxEdOSYlFBdUnxJo5Vs=3D; b=fmckMKsI0sMKqbFW9gKAfV1cGR7VsRGVCUp54HBWsV9WBW1P6hkela/uprE3936ManPGEh6M YVMbpMVVOMpBPRRhhjsBwBf02kH9jlysdX0SML9fGk0nQis8l8swxX9/; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Avi Lior supposedly scribbled: > Hi Hannes, >=20 > When I wrote the word "assertion" I was thinking a SAML assertion. In order for this to have any meaning at all, the source of this = assertion would need to be trusted by both the RADIUS client and = server. This seems to imply a bunch of new keys, at a minimum, unless = you don't care to authenticate the token/assertion/whatever (in which = case why bother?). In addition, the token/assertion/whatever would need = to be somehow delivered from something, somewhere in a secure fashion to = the RADIUS client for forwarding to the RADIUS server. Aside from those = minor nits (modifying both the RADIUS entities to receive, transmit & = understand the token/assertion/whatever & more than likely the = SSH/Kerberos/whatever entities to actually generate & deliver the = token/assertion/whatever), I think this is a great idea. >=20 > A word of caution though, everytime I mention XML to my AAA > developers they conspire to kill me.=20 Good people & wise! >=20 > XML, parsing strings etc are performance killers for a AAA server. >=20 >=20 >=20 >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Wednesday, July 26, 2006 4:55 AM >> To: Avi Lior >> Cc: Glen Zorn (gwz); David Harrington; Eliot Lear; isms@ietf.org; >> radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only >> issue (was RE: [Isms] ISMS session=20 >>=20 >> Hi Avi, >>=20 >> I like the idea of using some information to tie the authentication >> and the authorization process/exchange together. In fact we discussed >> this at the last IETF meeting when David gave his presentation. >>=20 >> I suggested to use an existing mechanism to accomplish this binding, >> namely SAML. I can elaborate a bit more about the details if someone >> case about it.=20 >>=20 >> Ciao >> Hannes >>=20 >> Avi Lior wrote: >>> I proably did not make myself clear....or maybe I did and I am >>> missing something.=20 >>>=20 >>> When the NAS sends the Access-Request Auth-Only message I agree that >>> it MUST contain Message-Authenticator(80) etc... >>>=20 >>> What I meant is that it would be nice if there was a token or an >>> assertion that came from the place that did authenticate the user=20 >>> to indicate in a cryptographic way that this user was authenticated. >>>=20 >>> The AAA server can use that token to verify that the user was >>> authenticated by an entity that it trusts. Like a kerberose ticket. >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >>>> Sent: Tuesday, July 25, 2006 3:47 PM >>>> To: Avi Lior; David Harrington; Eliot Lear >>>> Cc: isms@ietf.org; radiusext@ops.ietf.org >>>> Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] >>>> ISMS session=20 >>>>=20 >>>> Avi Lior supposedly scribbled: >>>>=20 >>>>=20 >>>>> Hi, >>>>>=20 >>>>> If I was specifying how this is done: >>>>>=20 >>>>> It would be nice if the AAA client could return some sort >>>>=20 >>>> of token to >>>>=20 >>>>> the AAA server to assert that the user has been authenticated by >>>>> an entity that it trusts. The token can be generated by the >>>>> Authentication Server.=20 >>>>>=20 >>>>> We need this assertion to make sure we deliver the correct >>>>> profile.=20 >>>>=20 >>>> I disagree: the fact that the message is being sent by an >>>> authenticated client at all says that the user has been >>>> authenticated elsewhere. Note that safety requires the inclusion >>>> of a MAC (either the Message-Authenticator or preferably the >>>> Message-Authentication-Code Attribute) in the Access-Request. >>>>=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 >>>>=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: 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, 26 Jul 2006 18:09:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 14:09:37 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawO89aduzcpUlvQ765NRtR82tFEwAoBKug From: "Avi Lior" To: "Jeffrey Hutzelman" , "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" Cc: , Hi Jeffrey. =20 > -----Original Message----- > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]=20 > Sent: Tuesday, July 25, 2006 6:43 PM > To: Avi Lior; Glen Zorn (gwz); David Harrington; Eliot Lear > Cc: isms@ietf.org; radiusext@ops.ietf.org; Jeffrey Hutzelman > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 >=20 >=20 > On Tuesday, July 25, 2006 05:40:00 PM -0400 Avi Lior=20 > wrote: >=20 > > I proably did not make myself clear....or maybe I did and I=20 > am missing=20 > > something. > > > > When the NAS sends the Access-Request Auth-Only message I=20 > agree that=20 > > it MUST contain Message-Authenticator(80) etc... > > > > What I meant is that it would be nice if there was a token or an=20 > > assertion that came from the place that did authenticate=20 > the user to=20 > > indicate in a cryptographic way that this user was authenticated. > > > > The AAA server can use that token to verify that the user was=20 > > authenticated by an entity that it trusts. Like a kerberose ticket. >=20 > First, the user was authenticated by the NAS. That is all=20 > the RADIUS server needs to know. The RADIUS server provides=20 > service to the NAS, not the user, and the NAS has asked for=20 > information about what the user is allowed to do. Either the=20 > RADIUS server is willing to give that information to the NAS=20 > or it is not, but it is the NAS that is making the request,=20 > not the user. I don't have a problem with that. But it would be better if the NAS can prove to the AAA server that the user was authenticated. Normally it is the AAA that authenticates the user and provides authorization attributes. >=20 > RADIUS servers provide authentication as a _service_ to the=20 > NAS, not as a means of determining whether the NAS is=20 > legitimate or should be given information. A NAS that is not=20 > interested in that service should not be required to use it=20 > in order to make use of the other services that the RADIUS=20 > server can provide, such as provisioning and accounting. =20 > Once again, the RADIUS server's relationship is with the NAS,=20 > not the user. Not true. Normally the RADIUS server (in particular the home RADIUS server) owns the user. Therefore it has a trust relationship with the user. The mechanism for that trust relationship is a credential (password or shared key) known only to those two parties. The RADIUS server trusts the NAS directly or via a trust chain. The trust mechanism is a shared secret or in the case of a trust chain, a set of trust secrets. >=20 > Secondly, as I already said, the sort of token you describe=20 > simply does not exist for most authentication mechanisms. A=20 > Kerberos ticket is not cryptographic proof that a user has=20 > authenticated. It is an encrypted message from the Kerberos=20 > server to a particular service, and is useless to anyone=20 > else. And, it's not a message saying "this user authenticated".=20 > It's a message telling the service the keys it needs to know=20 > in order to conduct an exchange with a user and determine=20 > whether that user is real. Well if that token did exist then it will be useful to use it.=20 I stand corrected on Kerberose. However, there are tokens that are used for single-sign-on that do prove the authenticity of the token holder. Why can't something like that be used? =20 >=20 > Thirdly, as I've also said before, this is a serious=20 > abstraction violation.=20 > Even if every service had such a magic cookie, what you're=20 > suggesting would require defining what it is, for RADIUS, for=20 > every authentication mechanism that might be used by a NAS=20 > using authorize-only. What magic token are you going to use=20 > for TLS? What about USM? GSS-spkm? SSH public key?=20 > one-time passwords? SSH host-based public key? NTLM? =20 > IPsec? How about the Frobozz protocol I referred to in an=20 > earlier message? You don't even know how that works, so=20 > you'd basically guarantee that when I get a NAS that supports=20 > the Frobozz protocol, I can't use it until I define an=20 > extension to the RADIUS protocol and upgrade my server. Perhaps I missled you and I am sorry. So let me clarify... First and foremost I am in favour of supporting the scheme that a NAS ought to be able to peform an Authorize-Only to a AAA sever regardless if that AAA server has authenticated the user or not. There are a huge security issues but so be it. Those security issue can be managed in many ways. The scheme is useful!!! The second part of my email was about one method of managing that security. Again, I would not want to mandate that method and mandate that that would be the only way to design such a system. In general my philosophy is that the IETF should build tools. Some of these tools can be dangerous if not used properly. The IETF should provide its wisdom on how one may use these tools and identify the risks as best it can. =20 >=20 > -- Jeff >=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, 26 Jul 2006 17:41:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Wed, 26 Jul 2006 13:41:49 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcawkV/xhIdQshPITY6tHkixAtQnrAASOKSg From: "Avi Lior" To: "Hannes Tschofenig" Cc: "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" , , Hi Hannes, When I wrote the word "assertion" I was thinking a SAML assertion. A word of caution though, everytime I mention XML to my AAA developers they conspire to kill me. XML, parsing strings etc are performance killers for a AAA server. =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Wednesday, July 26, 2006 4:55 AM > To: Avi Lior > Cc: Glen Zorn (gwz); David Harrington; Eliot Lear;=20 > isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Avi, >=20 > I like the idea of using some information to tie the=20 > authentication and the authorization process/exchange=20 > together. In fact we discussed this at the last IETF meeting=20 > when David gave his presentation. >=20 > I suggested to use an existing mechanism to accomplish this=20 > binding, namely SAML. I can elaborate a bit more about the=20 > details if someone case about it. >=20 > Ciao > Hannes >=20 > Avi Lior wrote: > > I proably did not make myself clear....or maybe I did and I=20 > am missing=20 > > something. > >=20 > > When the NAS sends the Access-Request Auth-Only message I=20 > agree that=20 > > it MUST contain Message-Authenticator(80) etc... > >=20 > > What I meant is that it would be nice if there was a token or an=20 > > assertion that came from the place that did authenticate=20 > the user to=20 > > indicate in a cryptographic way that this user was authenticated. > >=20 > > The AAA server can use that token to verify that the user was=20 > > authenticated by an entity that it trusts. Like a kerberose ticket. > >=20 > >=20 > >=20 > >=20 > >>-----Original Message----- > >>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > >>Sent: Tuesday, July 25, 2006 3:47 PM > >>To: Avi Lior; David Harrington; Eliot Lear > >>Cc: isms@ietf.org; radiusext@ops.ietf.org > >>Subject: RE: Follow up on Authorize Only issue (was RE:=20 > >>[Isms] ISMS session > >> > >>Avi Lior supposedly scribbled: > >> > >> > >>>Hi, > >>> > >>>If I was specifying how this is done: > >>> > >>>It would be nice if the AAA client could return some sort > >> > >>of token to > >> > >>>the AAA server to assert that the user has been=20 > authenticated by an=20 > >>>entity that it trusts. The token can be generated by the > >>>Authentication Server. =20 > >>> > >>>We need this assertion to make sure we deliver the correct profile. > >> > >>I disagree: the fact that the message is being sent by an=20 > >>authenticated client at all says that the user has been=20 > authenticated=20 > >>elsewhere. Note that safety requires the inclusion of a=20 > MAC (either=20 > >>the Message-Authenticator or preferably the=20 > >>Message-Authentication-Code Attribute) in the Access-Request. > >> > >>Hope this helps, > >> > >>~gwz > >> > >>Why is it that most of the world's problems can't be solved=20 > by simply > >> listening to John Coltrane? -- Henry Gabriel > >> > >=20 > >=20 > > -- > > to unsubscribe send a message to=20 > radiusext-request@ops.ietf.org with=20 > > the word 'unsubscribe' in 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: Wed, 26 Jul 2006 15:27: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: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 08:26:38 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625025F3ACC@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMIAB6ENIA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=2111; t=1153927616; x=1154791616; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=CfzLecCuCUZnMCr0rQ/fP9Ij8SuYhMVV17B0Vinm3cpEIlgOXDuwmKFrTJcy5edofItXqcoR KjIXc/s7Ni/YEYOYc1/Z9kyZoeeH1F54sFM5skbSV2KXFJyY3JynvHBB; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >>> If this attribute is used for its intended purpose, to allow the >>> RADIUS server to know what service to provision, then it cannot also >>> be used to indicate authorize-only mode. >=20 >> Too late, it already is. >=20 > Yes, for the Dynamic RADIUS Change of Authorization use case, as > specified in RFC 3576. It has no formally specified usage outside > 3576, that I recall. We need not use that method for the "general" > authorization only case. We could devise a new method, such as the > Asserted-Identity attribute, and relegate the Service-Type =3D > "Authorize Only" usage to CoA only. =20 We could, but it seems like a waste of attribute space since the value = if any would of necessity be identical to that carried by the User-Name = Attribute. =20 >=20 > I tend to agree with Jeff that this portion if RFC 3576 was probably > a "mistake". =20 Perhaps, but if so, it lines up very well with the original definition = of the Service-Type Attribute. In fact, I can't find any trace of the = architectural purity imputed to the Attribute by Jeff: only some of the = values of Service-Type are related to service as he has defined it. = Although I wasn't involved (except as a critic ;-) with the development = of RFC 3576 either, it would make perfect sense to me to add a value of = "Authorize Only" to an Attribute that already had values of = "Authenticate Only" & "Call Check" defined, the latter being purely = authorizational in character. > I can say that as I had nothing to do with that > document. Whether it was or wasn't, we are not obligated to carry > that particular usage into other areas of application for RADIUS. =20 >=20 >=20 >=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: Wed, 26 Jul 2006 11:45:56 +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: [Isms] RE: Follow up on Authorize Only issue Date: Wed, 26 Jul 2006 07:45:29 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560412031@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQAA4edMI= From: "Nelson, David" To: , Glen Zorn writes... =20 > > If this attribute is used for its intended purpose, to allow the > > RADIUS server to know what service to provision, then it=20 > > cannot also be used to indicate authorize-only mode. > Too late, it already is. Yes, for the Dynamic RADIUS Change of Authorization use case, as = specified in RFC 3576. It has no formally specified usage outside 3576, = that I recall. We need not use that method for the "general" = authorization only case. We could devise a new method, such as the = Asserted-Identity attribute, and relegate the Service-Type =3D = "Authorize Only" usage to CoA only. I tend to agree with Jeff that this portion if RFC 3576 was probably a = "mistake". I can say that as I had nothing to do with that document. = Whether it was or wasn't, we are not obligated to carry that particular = usage into other areas of application for RADIUS. =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, 26 Jul 2006 09:22:20 +0000 Message-ID: <44C72DEA.1070406@gmx.net> Date: Wed, 26 Jul 2006 10:55:06 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: Avi Lior CC: "Glen Zorn (gwz)" , David Harrington , Eliot Lear , isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Avi, I like the idea of using some information to tie the authentication and the authorization process/exchange together. In fact we discussed this at the last IETF meeting when David gave his presentation. I suggested to use an existing mechanism to accomplish this binding, namely SAML. I can elaborate a bit more about the details if someone case about it. Ciao Hannes Avi Lior wrote: > I proably did not make myself clear....or maybe I did and I am missing > something. > > When the NAS sends the Access-Request Auth-Only message I agree that it > MUST contain Message-Authenticator(80) etc... > > What I meant is that it would be nice if there was a token or an > assertion that came from the place that did authenticate the user to > indicate in a cryptographic way that this user was authenticated. > > The AAA server can use that token to verify that the user was > authenticated by an entity that it trusts. Like a kerberose ticket. > > > > >>-----Original Message----- >>From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >>Sent: Tuesday, July 25, 2006 3:47 PM >>To: Avi Lior; David Harrington; Eliot Lear >>Cc: isms@ietf.org; radiusext@ops.ietf.org >>Subject: RE: Follow up on Authorize Only issue (was RE: >>[Isms] ISMS session >> >>Avi Lior supposedly scribbled: >> >> >>>Hi, >>> >>>If I was specifying how this is done: >>> >>>It would be nice if the AAA client could return some sort >> >>of token to >> >>>the AAA server to assert that the user has been authenticated by an >>>entity that it trusts. The token can be generated by the >>>Authentication Server. >>> >>>We need this assertion to make sure we deliver the correct profile. >> >>I disagree: the fact that the message is being sent by an >>authenticated client at all says that the user has been >>authenticated elsewhere. Note that safety requires the >>inclusion of a MAC (either the Message-Authenticator or >>preferably the Message-Authentication-Code Attribute) in the >>Access-Request. >> >>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: > > -- to unsubscribe send a message to radiusext-request@ops.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, 26 Jul 2006 07:13:39 +0000 Date: Wed, 26 Jul 2006 09:13:17 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: [Isms] RE: Follow up on Authorize Only issue Message-ID: <20060726071317.GA6315@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Tue, Jul 25, 2006 at 05:12:10PM -0400, Nelson, David wrote: > We've had this discussion many months ago. My opinion hasn't changed. > I think that providing a way for RADIUS to provision group membership > information that can be used to map into any Access Control Subsystem > ought to be part of the work. Especially if it does not actually affect > the architectural model, and is accomplished in an implementation > dependent fashion. My understanding is that the concept of a group name is specific to VACM. The ASIs into the ACM subsystem do not carry such a thing as a group name. As such, mappings of security names to group names is VACM specific and clearly happens within VACM from an architectural point of view. While I do see interest in addressing this VACM security name to group name mapping issue, I do indeed see this work item in conflict with the current ISMS charter: : Work on new access control models or centralized administration of : View-based Access Control Model (VACM) rules and mappings is outside : the scope of the working group. Given our current charter, I like to see the RADIUS document we are chartered to produce focus on the RADIUS SSH user authentication and RADIUS authorization of the SSH SNMP subsystem. Another document detailing how RADIUS can be used by VACM to obtain security name to group name mappings might be written and become a WG item in the future once we have completed our current work items and we can re-charter and take on new work. Note that this does of course not impact the RADEXT document which may define all attributes needed to address all the RADIUS related ISMS requirements. I actually like to encourage people to write a document which explains how VACM can utilize RADIUS to provision the security name to group name mapping and to post such a document as an individual draft. But as explained above, this work can't become an official WG work item under the current charter. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, 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: Wed, 26 Jul 2006 04:54:53 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 21:54:37 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597F90@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawNqj0VI8mXqEYRz+vSD8qD7tJdgAOIchQ From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" , , DKIM-Signature: a=rsa-sha1; q=dns; l=1587; t=1153889682; x=1154753682; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=qSX9uegmeSmBSS09oKQYhl2IQguZ9/FPdYUzbgPvqXDrwkxzP+4gVhAjyJ5sC5c/3cjt5lb/ 0Cika4ehIh/KLs7EA84TGahB/SozvpFraDANJ+GU+KFuF1M710UqH6X6; Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 02:20:49 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Actually, no, at least in current usage an authentication type >> _always_ has an associated attribute, which can be seen as something >> that the server doesn't understand. >=20 > Is there a requirement that a server reject a request which contains > any attributes it doesn't understand?=20 >=20 >=20 >=20 >>> A RADIUS server which supports authorize-only will >>> probably want to return success for the request using that feature, >>> but still must return failure for requests using methods it doesn't >>> understand. To make the distinction, you need an affirmative >>> indication from the client that it wants authorize-only; >>=20 >> Is that not provided by the Service-Type of Authorize-Only? >=20 > Not if you want to use Service-Type to actually indicate the service > type,=20 > instead of overloading it to mean something else. As I understand > it, this=20 > attribute is _supposed_ to indicate the type of service the NAS is > providing to the user, and overloading it to mean something else was a > mistake. If this attribute is used for its intended purpose, to > allow the=20 > RADIUS server to know what service to provision, then it cannot also > be=20 > used to indicate authorize-only mode. Too late, it already is. 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, 26 Jul 2006 04:34:53 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 21:33:56 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597F79@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawOMAr3oPpsfszR46FFBYYv5ru/gAM7sZQ From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=1799; t=1153888439; x=1154752439; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=ObhMTwqu9X9VG2wrjKiHlEVyjha9qEjauP/hS63ZbJ1VU+iBfwPVT5NW1THH1fkiXhLf5OTX pz0BgELiMUQ3NdVHNFXgoBq68WvoQLu36P6hzqvVptSibnrdVB1dB1h9; Authentication-Results: sj-dkim-6.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 02:16:41 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Don't quite understand this either: if a server doesn't recognize the >> postulated Asserted-Identity Attribute, it seems that as far as it is >> concerned there will be no credential-bearing attribute in the >> message. So just omitting any credential-bearing attribute (along >> with the addition of the other stuff we've been talking about) >> should get just the same response from a legacy server, right? >=20 >> From a _legacy_ server, yes. The concern is about how this would >> affect > handling of some new authentication method invented in the future.=20 > Suppose there is a new method that requires a "Frobozz" attribute, > and we have a client that sends a request using that method. A > server which supports "Frobozz" will respond correctly, as will a > server that does not support either "Frobozz" or authorize-only. =20 >=20 >=20 > However, a server that supports authorize-only but does _not_ support > "Frobozz" will believe the client intended authorize-only, and will > return a successful response on that basis, without verifying the > user's identity. =20 > That's the situation which we need an "Asserted-Identity" attribute > to avoid. The _contents_ of such an attribute are irrelevant; the > important thing is an affirmative indication that the client meant > authorize-only and not some unknown "Frobozz". =20 OK, one more time: that seems to be what a Service-Type of = Authorize-Only would do.... >=20 > -- Jeff 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, 25 Jul 2006 21:39: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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Tue, 25 Jul 2006 17:40:00 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOAALYSREAAEBHdg From: "Avi Lior" To: "Glen Zorn \(gwz\)" , "David Harrington" , "Eliot Lear" Cc: , I proably did not make myself clear....or maybe I did and I am missing something. When the NAS sends the Access-Request Auth-Only message I agree that it MUST contain Message-Authenticator(80) etc... What I meant is that it would be nice if there was a token or an assertion that came from the place that did authenticate the user to indicate in a cryptographic way that this user was authenticated. The AAA server can use that token to verify that the user was authenticated by an entity that it trusts. Like a kerberose ticket. > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20 > Sent: Tuesday, July 25, 2006 3:47 PM > To: Avi Lior; David Harrington; Eliot Lear > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Avi Lior supposedly scribbled: >=20 > > Hi, > >=20 > > If I was specifying how this is done: > >=20 > > It would be nice if the AAA client could return some sort=20 > of token to=20 > > the AAA server to assert that the user has been authenticated by an=20 > > entity that it trusts. The token can be generated by the > > Authentication Server. =20 > >=20 > > We need this assertion to make sure we deliver the correct profile. >=20 > I disagree: the fact that the message is being sent by an=20 > authenticated client at all says that the user has been=20 > authenticated elsewhere. Note that safety requires the=20 > inclusion of a MAC (either the Message-Authenticator or=20 > preferably the Message-Authentication-Code Attribute) in the=20 > Access-Request. =20 >=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 >=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, 25 Jul 2006 21:20:57 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:20:49 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597DA4@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawKjxGE7hbmDSbTJiMrvL6nM9eFQABZXKg From: "Glen Zorn \(gwz\)" To: "Jeffrey Hutzelman" , "Nelson, David" , , DKIM-Signature: a=rsa-sha1; q=dns; l=2842; t=1153862450; x=1154726450; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=RVnPzzFl5J/oodGIc/kOZ/eYv2Y+Iy1FZW+ZxXYIe4wvUvrdGKjmu0qxTKhICGYnltcczAY/ Ssc41MlAgn9f4VJbylDEnioKlX4Ipj5EmRbN6qEMHZrjZ5K0OI3d0sI8; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Jeffrey Hutzelman supposedly scribbled: > On Tuesday, July 25, 2006 01:10:57 PM -0700 "Glen Zorn (gwz)" > wrote: >=20 >> Aside from the fact that "Authorize Only" is hardly an authentication >> method >=20 > It's not an authentication method, but it fills that role in the > protocol.=20 > Ordinarily, the RADIUS server must have some means of verifying the > user's identity, because the NAS is counting on it to do that. The > authentication method is simply the answer to the question "what is > that means?". What we're doing is defining a new possible answer, > which is "there is none; the NAS is not counting on you to verify the > user's identity, so you don't have to do it". =20 >=20 > Now, you've suggested that the way to represent that answer is simply > by not including the attributes required for some other method. The > problem with that is that such a request is indistinguishable to the > RADIUS server from a request using an authentication method it does > not understand. =20 Actually, no, at least in current usage an authentication type _always_ = has an associated attribute, which can be seen as something that the = server doesn't understand. > A RADIUS server which supports authorize-only will > probably want to return success for the request using that feature, > but still must return failure for requests using methods it doesn't > understand. To make the distinction, you need an affirmative > indication from the client that it wants authorize-only;=20 Is that not provided by the Service-Type of Authorize-Only? > that is, > that it is not depending on the RADIUS server to verify the user's > identity. =20 >=20 >=20 >>>> I must note, BTW, that if you are trying to restrict what >>>> information the RADIUS server gives out because you don't trust the >>>> NAS, then giving out informaton based on what service the NAS >>>> claims it is providing, or what port type the NAS claims the user >>>> came in on, is kind of silly. >>=20 >> What's actually silly is talking about untrusted NASen at all: if a >> RADIUS client that has a valid shared secret has been compromised, >> life is pretty much over anyway. >=20 > Not necessarily. With the kinds of authentication mechanisms which > make authorize-only RADIUS attractive, a NAS never gains the ability > to impersonate a user. So, the service that NAS is providing > probably has big problems, but the users' passwords haven't been > compromised, and neither have other RADIUS clients. The compromised > device can be turned off, and the problem is gone. =20 >=20 >=20 > -- Jeff 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, 25 Jul 2006 21:16:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:16:41 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D9F@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAAAAHrdoAAB3X8Q From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=2176; t=1153862202; x=1154726202; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=aGQy48QN+hyclNVLIOSxwp5MIueCM0JLTx/G7ct6NzyouWM+Poo74tCyZa7DfLp8lz6ykn7g B2eXrqKRQs46J4UCbykRdS463g3SLONX/IIAtwGkXeO+MhL2vX1OmniT; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David supposedly scribbled: > Glen Zorn writes... >=20 >> Aside from the fact that "Authorize Only" is hardly an authentication >> method, ... >=20 > It's been described as the "null" authentication method, purely from > a conceptual viewpoint.=20 >=20 >> ... it seems a bit silly to define a new attribute to indicate that >> other attributes are missing. The absence of User-Password, etc. >> would seem to be enough to implicitly select authorize-only... >=20 > Well, the new attribute need not be empty. I could contain an > identity string, for auditing purposes.=20 >=20 > I think that the use of User-Name to contain the auditing information > (as you posited in a separate post) is problematic. =20 Not sure I really understand this. > I also think > that omitting the User-Name as the only way to signal Authorize Only > is also problematic. =20 If User-Name is omitted, how do you know who is being authorized? > The problems I see are with existing RADIUS > server implementations. Since the _presence_ of a particular kind of > credential-bearing attribute has always selected the authentication > method, I'm concerned about the backwards compatibility aspects of > simply omitting any such. Perhaps others have thoughts on this?=20 Don't quite understand this either: if a server doesn't recognize the = postulated Asserted-Identity Attribute, it seems that as far as it is = concerned there will be no credential-bearing attribute in the message. = So just omitting any credential-bearing attribute (along with the = addition of the other stuff we've been talking about) should get just = the same response from a legacy server, right? =20 ... >=20 >> What's actually silly is talking about untrusted NASen at all: if a >> RADIUS client that has a valid shared secret has been compromised, >> life is pretty much over anyway. >=20 > I think we have rough consensus on that point. That's gratifying to hear! 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, 25 Jul 2006 21:12:23 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 17:12:10 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219392@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4AAAJfPAAADsW/wAAF4ZB A= From: "Nelson, David" To: , Dave Harrington writes... > But "provisioning SNMP parameters" explicitly does not include mapping > to the access control subsytem; ... I don't read that in the charter. You apparently read it between the lines. Defining a new Access Control Subsystem or making changes to VACM is explicitly out of scope. > ...that is a separate issue that is out of scope for the WG, > and should be dealt with in a separate document when such a > document is included in a subsequent ISMS charter. We've had this discussion many months ago. My opinion hasn't changed. I think that providing a way for RADIUS to provision group membership information that can be used to map into any Access Control Subsystem ought to be part of the work. Especially if it does not actually affect the architectural model, and is accomplished in an implementation dependent fashion. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 21:00:21 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 17:00:08 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219391@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawLBuXrLWYKJWrQ52hW7eVCGZAcQAACy5Q From: "Nelson, David" To: , Jeff Hutzelman writes... > If the RADIUS server wishes to log the NAS's request, it's welcome to do > so, but what information is relevant to that that's not a necessary part > of the request? I think I've added some unintentional confusion. Indeed, the "user name" is necessary in the access request so that the server can perform the profile lookup. Someone had suggested on the list that additional information _might_ be provided as an outcome of authentication that could be additionally passed along for auditing purposes. I think the example was given of a Kerberos ticket. Now I don't know if that makes any sense, and the suggestion wasn't accompanied by a detailed use case. So, maybe the auditing suggestion is a red herring. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 20:50:31 +0000 Message-ID: From: "Bernard Aboba" To: isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 13:50:10 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >What's actually silly is talking about untrusted NASen at all: if a RADIUS >client that has a valid >shared secret has been compromised, life is pretty >much over anyway. There is still the 'cascading vulnerabilty' problem. That is, compromise of a single NAS should not imply compromise of other services, NASes or users. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 20:33:37 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 16:33:14 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219390@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAAAAHrdoA== From: "Nelson, David" To: , Glen Zorn writes... > Aside from the fact that "Authorize Only" is hardly an authentication > method, ... It's been described as the "null" authentication method, purely from a conceptual viewpoint. > ... it seems a bit silly to define a new attribute to indicate that > other attributes are missing. The absence of User-Password, etc. would > seem to be enough to implicitly select authorize-only... Well, the new attribute need not be empty. I could contain an identity string, for auditing purposes. I think that the use of User-Name to contain the auditing information (as you posited in a separate post) is problematic. I also think that omitting the User-Name as the only way to signal Authorize Only is also problematic. The problems I see are with existing RADIUS server implementations. Since the _presence_ of a particular kind of credential-bearing attribute has always selected the authentication method, I'm concerned about the backwards compatibility aspects of simply omitting any such. Perhaps others have thoughts on this?=20 I believe that the presence of User-Name already has a well defined semantics. I am concerned that the omission of User-Name may have muddled semantics, given RFC 3576 implementations. In RFC 3576 the Service-Type of Authorize Only in an Access-Request provides that signal. We wish to use a Service-Type of Framed-Management (or some such) in the ISMS use case, so we need another attribute to signal Authorize Only. > What's actually silly is talking about untrusted NASen at all: if a RADIUS > client that has a valid shared secret has been compromised, life is pretty > much over anyway. I think we have rough consensus on that point. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Jul 2006 20:11:35 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 13:10:57 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D2A@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQAAM/vAA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , , DKIM-Signature: a=rsa-sha1; q=dns; l=1951; t=1153858258; x=1154722258; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=p1tNetYLfGSERllqFxrWtRYOeE4+UDQy2Gz+uHxcBEMhGsn4JqPVDM3SCDsXIZLs1b5Cxv1i 4DAl+Fa/P1peGzILzF3SW3f+p5Th5yDRkP5vACOwksuJEmidjSW+NeN/; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David supposedly scribbled: > Jeffrey Hutzelman writes... >=20 >> Overloading Service-Type in this way was almost certainly a mistake; >> ... >=20 > Perhaps. >=20 >> ...as you note, it prevents the attribute for being used for its >> intended purpose, ... >=20 > In this case, providing a service hint. >=20 >> I think this is up to radext to fix; possibilities I can think of are >> defining an "authorize-only" authentication mechanism, or defininig >> a new attribute which carries the value that Service-Type would have >> had.=20 >=20 > One suggestion that comes to mind is to create a new attribute called > Asserted-Identity, which could be empty. In RADIUS, the > authentication method is implicitly selected by the inclusion of the > corresponding credential-bearing attribute(s), such as User-Password, > CHAP-Password, EAP-Message, etc. Asserted-Identity could be the > attribute which selects the Authorize Only authentication method. =20 Aside from the fact that "Authorize Only" is hardly an authentication = method, it seems a bit silly to define a new attribute to indicate that = other attributes are missing. The absence of User-Password, etc. would = seem to be enough to implicitly select authorize-only... =20 >=20 >> I must note, BTW, that if you are trying to restrict what >> information the RADIUS server gives out because you don't trust the >> NAS, then giving out informaton based on what service the NAS claims >> it is providing, or what port type the NAS claims the user came in >> on, is kind of silly. What's actually silly is talking about untrusted NASen at all: if a = RADIUS client that has a valid shared secret has been compromised, life = is pretty much over anyway. ... 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, 25 Jul 2006 19:59:25 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 12:59:16 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D1C@xmb-sjc-215.amer.cisco.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAAQzacA= From: "Glen Zorn \(gwz\)" To: "Nelson, David" , , DKIM-Signature: a=rsa-sha1; q=dns; l=477; t=1153857558; x=1154721558; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20[Isms]=20RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3Dj5JHVHOkk4k+d3Gjk+Lsn4+lNFg=3D; b=CIauXJd4fFcXH8B3npHRsp06F8M+laJNTK6McTkf+ylSU1UIIGIqoys30QlRwjFhAiMQ/Z1I 2SReONVKEQrT3IIkJ0IxjMO5lnJNyzEPEIjDyw/dRWnDHHhnv7oOZPqF; Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David supposedly scribbled: ... >=20 > There was also a suggestion on the list that the NAS convey the > asserted identity to the RADIUS Server for audit purposes. This > could be accomplished by a (new) Asserted-Identity attribute. =20 How would this be different than the User-Name attribute? ~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, 25 Jul 2006 19:47:15 +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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Tue, 25 Jul 2006 12:46:42 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB262502597D07@xmb-sjc-215.amer.cisco.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOAALYSREA== From: "Glen Zorn \(gwz\)" To: "Avi Lior" , "David Harrington" , "Eliot Lear" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=913; t=1153856804; x=1154720804; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session; X=v=3Dcisco.com=3B=20h=3DEvtPMlNbcxEdOSYlFBdUnxJo5Vs=3D; b=fxUoPuQCxPbQfmVGBRMUcKpa0f7wjQWdK7ZwlIKuX1p9o4BpbEX3Ymm6sXjxiCxiMvPIu/os Nrhe4Eh54ttiSl1q/Jbl8aZ9CuUFHToSgUvD0xP5eQEHceayZ5/QTxy/; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Avi Lior supposedly scribbled: > Hi, >=20 > If I was specifying how this is done: >=20 > It would be nice if the AAA client could return some sort of token to > the AAA server to assert that the user has been authenticated by an > entity that it trusts. The token can be generated by the > Authentication Server. =20 >=20 > We need this assertion to make sure we deliver the correct profile. I disagree: the fact that the message is being sent by an authenticated = client at all says that the user has been authenticated elsewhere. Note = that safety requires the inclusion of a MAC (either the = Message-Authenticator or preferably the Message-Authentication-Code = Attribute) in the Access-Request. =20 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, 25 Jul 2006 18:48:59 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:48:41 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938F@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQAADcQ4AAAJfPAA== From: "Nelson, David" To: , David Harrington writes... > Ergo, I believe SSHSM should never use the "authorize-only"=20 > feature. I'm more that a little fuzzy on the architecture, the ASIs, etc., so please bear with me. I agree that the Access Control Subsystem will be the ultimate consumer of the "fine granularity" authorization, such as that provided by Management-Policy-ID, or a similar attribute. It is my understanding, and please correct me if I miss some details, that the Transport Mapping Subsystem (e.g. the SSN server) has the responsibility of enforcing "coarse granularity" authorization, i.e. whether a SNMP subsystem may be spawned by the SSH server. It also has the responsibility to pass along the securityName to the Access Control Subsystem. Given that any additional authorization information that comes during an integrated RADIUS authentication and authorization also needs to be passed along with the securityName, that implies some participation by the Transport Mapping Subsystem. In the case where RADIUS is only used for authorization, it could be argued that it is the responsibility of the Access Control subsystem to obtain that information. I suppose the interface would be implementation dependent. This needs to be described somewhere. If not in the RADIUS Usage for SSHSM document, then where? -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 18:38:23 +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: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:38:03 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938E@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawGC5Cd0U7Vo4FQ1iCsDPCDN/k2gAACYzQ From: "Nelson, David" To: , Jeffrey Hutzelman writes... > Overloading Service-Type in this way was almost certainly a=20 > mistake; ... Perhaps. > ...as you note, it prevents the attribute for being used for=20 > its intended purpose, ... In this case, providing a service hint. > I think this is up to radext to fix; possibilities I can think of are > defining an "authorize-only" authentication mechanism, or defininig a new > attribute which carries the value that Service-Type would have had. One suggestion that comes to mind is to create a new attribute called Asserted-Identity, which could be empty. In RADIUS, the authentication method is implicitly selected by the inclusion of the corresponding credential-bearing attribute(s), such as User-Password, CHAP-Password, EAP-Message, etc. Asserted-Identity could be the attribute which selects the Authorize Only authentication method.=20 > I must note, BTW, that if you are trying to restrict what information the > RADIUS server gives out because you don't trust the NAS, then giving out > informaton based on what service the NAS claims it is providing, or what > port type the NAS claims the user came in on, is kind of silly. Right. But providing hints in the Access-Request message is still necessary for the RADIUS server to make an informed policy decision as to which service to provision, from among those allowed for the user, and to put the corresponding attributes in the Access-Accept message. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 18:12:45 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 14:12:23 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021938D@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: AcawCJM86A/wvy5pRVmxgK2lskkwkwACzVKQ From: "Nelson, David" To: , Bernard Aboba writes... > Does the Service-Type of "Framed-Management" imply=20 > authorization-only? No. It could equally be used when RADIUS is providing both authentication and authorization. > Or is it possible for authentication to be requested=20 > as well? Yes. > For example, what attributes are used in existing SSH=20 > implementations acting as a RADIUS client? I rather suspect that existing implementations either ignore the Service-Type (i.e. authenticate only) or expect something like NAS-Prompt. There is an issue to be worked out, and that it how does the NAS signal to the RADIUS Server that it is seeking Authorize Only service specifically for SSHSM? The existing Authorize only usage in RFC 3576 suggests that: The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. So it seems clear that the Access-Request message, in the SSHSM Authorize Only usage, should contain; Service-Type =3D Authorize Only Message-Authenticator Plus various forms of ID attributes, such as NAS-IP-Address, NAS-Identifier, etc. But what else? It would be typical to include: Service-Type =3D Framed-Management Framed-Management-Protocol =3D SNMPv3 as hints, however, the value of Service-Type conflicts. Perhaps simply including:=20 Framed-Management-Protocol =3D SNMPv3 is a sufficient hint to the RADIUS Server, along with Service-Type =3D Authorize Only, to indicate the SSHSM Authorize Only use case. I would fully expect that the Access-Accept message would contain: Service-Type =3D Framed-Management Framed-Management-Protocol =3D SNMPv3 Message-Authenticator Plus what ever else might be desired. There was also a suggestion on the list that the NAS convey the asserted identity to the RADIUS Server for audit purposes. This could be accomplished by a (new) Asserted-Identity attribute. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Jul 2006 16:37:09 +0000 Message-ID: From: "Bernard Aboba" To: dnelson@enterasys.com, isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 09:36:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >Actually, in the NAS-Management draft we >recommend that the Service-Type attribute be "Framed-Management" and the >(new) Framed-Management-Protocol attribute be "SNMPv3". I think that >this is much cleaner than overloading the NAS-Port-Type. This makes sense. >Right. For those deployments that are using non-RADIUS authentication >today, the SSHSM usage of RADIUS will likely be for authorization only. Does the Service-Type of "Framed-Management" imply authorization-only? Or is it possible for authentication to be requested as well? For example, what attributes are used in existing SSH implementations acting as a RADIUS client? -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 16:09:49 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: [Isms] RE: Follow up on Authorize Only issue cc: isms@ietf.org, radiusext@ops.ietf.org Date: Tue, 25 Jul 2006 12:00:40 -0400 Message-Id: <20060725160040.0FF9516CBC@mail.nitros9.org> "Nelson, David" wrote: > Uh, something like that. Actually, in the NAS-Management draft we > recommend that the Service-Type attribute be "Framed-Management" and the > (new) Framed-Management-Protocol attribute be "SNMPv3". I think that > this is much cleaner than overloading the NAS-Port-Type. I agree. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Jul 2006 14:52:40 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 10:52:09 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219388@MABOSEVS2.ets.enterasys.com> Thread-Topic: [Isms] RE: Follow up on Authorize Only issue Thread-Index: Acavoie27VuWp27ORNiJlGtWCEHqwAAVG2UQ From: "Nelson, David" To: , Bernard Aboba writes... > Typically this is handled by utilization of a unique Service-Type > or NAS-Port-Type value. The RADIUS policy engine then selects the=20 > attribute set to be returned based on these values. The values of NAS-Port-Type are (almost exclusively) related to media type: 0 Async 1 Sync 2 ISDN Sync 3 ISDN Async V.120 4 ISDN Async V.110 5 Virtual 6 PIAFS 7 HDLC Clear Channel 8 X.25 9 X.75 10 G.3 Fax 11 SDSL - Symmetric DSL 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase Modulation 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone 14 IDSL - ISDN Digital Subscriber Line 15 Ethernet 16 xDSL - Digital Subscriber Line of unknown type 17 Cable 18 Wireless - Other 19 Wireless - IEEE 802.11 20 Token-Ring =20 21 FDDI =20 22 Wireless - CDMA2000=20 23 Wireless - UMTS =20 24 Wireless - 1X-EV =20 25 IAPP =20 26 FTTP - Fiber to the Premises =20 27-29 Unassigned 30 PPPoA - PPP over ATM =20 31 PPPoEoA - PPP over Ethernet over ATM=20 32 PPPoEoE - PPP over Ethernet over Ethernet =20 33 PPPoEoVLAN - PPP over Ethernet over VLAN =20 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ=20 While there have been proposals to over-load NAS-Port-Type with application layer protocol information, I think this is not a good idea. > As far as I know there is no specification for SSH authentication > support within RADIUS so I'm not sure if this is true or not. That is one of the issues that we have addressed in the NAS-Management draft. ( http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-03.txt ) SSH implementations use RADIUS today for authentication, with or without a formal specification. What is lacking is a set of authorization attributes targeted at SSH, SNMP over SSH, and similar use cases. > For example, as I understand it SSH can support authentication=20 > mechanisms such as Kerberos which are not supported in RADIUS. SSH authentication support indeed extends beyond RADIUS. > In this case it sounds like the NAS-Port-Type might be "SSH" but the > Service-Type might be "SNMP". Uh, something like that. Actually, in the NAS-Management draft we recommend that the Service-Type attribute be "Framed-Management" and the (new) Framed-Management-Protocol attribute be "SNMPv3". I think that this is much cleaner than overloading the NAS-Port-Type. Once could argue that a generic service such as Framed-Management, with subsidiary attributes such as Framed-Management-Protocol, is "too much". One could flatten all the combinations into a set of new service types. I think that the approach in the NAS-Management draft is more in line with traditional RADIUS usages (e.g. Service-Type =3D Framed, and Framed-Protocol =3D PPP). > I think this depends on whether RADIUS can support all the required > authentication methods. If not, then either that support needs to=20 > be added to RADIUS or only authorization will be available. Right. For those deployments that are using non-RADIUS authentication today, the SSHSM usage of RADIUS will likely be for authorization only. The goal of the ISMS WG is to re-use existing AAA infrastructures. Where RADIUS is already in use, it would naturally be used for both authentication and authorization. Where it is not already in use, it may be used only for authorization. =20 > Question: In the case where SSH is used, do you just need SSH=20 > attributes, or are SNMP attributes required there as well? This is addressed in the NAS-Management draft. Provisioning of "plain" SSH, SNMPv3 over SSH, and other protocol combinations are described. So, yes, more than a single attribute (or single service provisioning description) is necessary. -- to unsubscribe send a message to radiusext-request@ops.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, 25 Jul 2006 13:26:38 +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: Follow up on Authorize Only issue Date: Tue, 25 Jul 2006 09:26:32 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue Thread-Index: Acaun5F+OBZSd5h4St+Z8HXTGLTFlwBTfM4g From: "Avi Lior" To: "Bernard Aboba" , Cc: , Well I am not exactly against using an Authorize Only in this way. I do recognize that there is a severe security issue. However, I still think designers need to be aware of the issues and design appropriately. We in the IETF need to make sure that designers are aware of the security risk of a particular feature. That is afterall what the Security section is about. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Sunday, July 23, 2006 5:31 PM > To: aland@nitros9.org > Cc: isms@ietf.org; radiusext@ops.ietf.org > Subject: Re: Follow up on Authorize Only issue >=20 > >A compromised NAS can leverage this requested feature to obtain that=20 > >information more readily. Right now, if the NAS hasn't had=20 > a user log=20 > >in through it, it can get those credentials only through a=20 > brute force=20 > >attack on the password. The server *should* be able to catch that=20 > >attack, mitigating the vulnerability. >=20 > Right. >=20 > > > If this is allowed, it should follow the principle of "least=20 > > > privilege", only providing the attributes relevant to SSH. > > > >Which means that the Access-Request has to be recognizable=20 > as for SSH=20 > >in this use-case. This means an attribute or value specifically for=20 > >this purpose. The RADIUS server can then key off of that special=20 > >request, and return a limited response. >=20 > Right. For example an additional Service-Type value of "SSH"=20 > could be allocated One concern would be whether an attacker=20 > could use this Service-Type with any NAS-Port-Type, in order=20 > to retrieve attributes relevant to that NAS-Port-Type. To=20 > prevent this, one possibility is to add NAS-Port-Type values=20 > of "SSH" and "ISMS" (since different attributes might be=20 > returned for a straight SSH or SSH-protected ISMS session)=20 > and only allow Service-Type=3D"SSH" to be used with those=20 > NAS-Port-Type values; all other NAS-Port-Type values would=20 > result in an Access-Reject. >=20 > >The use case should also enumerate the possible attributes=20 > and values=20 > >needed in the Access-Accept, and state explicitely that=20 > responding with=20 > >any other attributes or values may result in security=20 > violations. i.e.=20 > >Other attributes and values SHOULD NOT be sent in the Access-Accept. >=20 > Makes sense. >=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: Tue, 25 Jul 2006 04:24:14 +0000 Message-ID: From: "Bernard Aboba" To: ietfdbh@comcast.net, isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: [Isms] RE: Follow up on Authorize Only issue Date: Mon, 24 Jul 2006 21:23:35 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >OK. If RADIUS supports this, we can probably ask for specific >attributes or attribute sets. Typically this is handled by utilization of a unique Service-Type or NAS-Port-Type value. The RADIUS policy engine then selects the attribute set to be returned based on these values. >There are multiple possible proposals on the ISMS table, and we are >trying to determine what RADIUS can or cannot provide for us. > >We know that RADIUS can provide SSH-related attributes when the user >connects to the NAS using an SSH session and RADIUS provides the >authentication. As far as I know there is no specification for SSH authentication support within RADIUS so I'm not sure if this is true or not. For example, as I understand it SSH can support authentication mechanisms such as Kerberos which are not supported in RADIUS. >We know that the RADIUS server might be able to provide SNMP-related >attributes when the user connects to the NAS using an SSH transport >and RADIUS provides the authentication. In this case it sounds like the NAS-Port-Type might be "SSH" but the Service-Type might be "SNMP". >We do not need "authorize-only" support for those situations, since >RADIUS would be doing the authentication. I think this depends on whether RADIUS can support all the required authentication methods. If not, then either that support needs to be added to RADIUS or only authorization will be available. >The authentication might have been provided via Kerberos >or TLS or SNMPv3's USM, but RADIUS is not involved in the >authentication, only the (later) authorization. In this case you might have a Service-Type of "SNMP" and a NAS-Port-Type of "SNMP". >The attributes we want to see are >specific to SNMP, or to Network Management via SNMP/Netconf/CLI, etc. > >If RADIUS supports it, the RADIUS client may be able to identify that >the request is associated wih an SNMP engine, so the server can return >only SNMP-related attributes. A Service-Type of "SNMP" with a NAS-Port-Type of "SNMP" could be used to indicate this. Question: In the case where SSH is used, do you just need SSH attributes, or are SNMP attributes required there as well? In other words, how is SSH for SNMP distinguished from plain old SSH? -- to unsubscribe send a message to radiusext-request@ops.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, 24 Jul 2006 22:03:46 +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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Mon, 24 Jul 2006 18:03:35 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcavVaJ/o21kG28KT+62RlLcOC0YOAAAUmRQAAVawOA= From: "Avi Lior" To: "David Harrington" , "Eliot Lear" Cc: "Nelson, David" , , Hi, If I was specifying how this is done: It would be nice if the AAA client could return some sort of token to the AAA server to assert that the user has been authenticated by an entity that it trusts. The token can be generated by the Authentication Server. We need this assertion to make sure we deliver the correct profile. Even if we don't have this type of interaction I still think that we should support Authorize-Only for this type of transaction. Since this can be used in cases where the NAS is absolutely trusted or there are other means to secure the NAS/AAA -- eg in a closed system. > -----Original Message----- > From: David Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Monday, July 24, 2006 4:01 PM > To: 'Eliot Lear' > Cc: Avi Lior; 'Nelson, David'; isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Hi Eliot, >=20 > The ISMS concern is that some operators want to use=20 > authentication mechanisms other than RADIUS to authenticate=20 > the SNMP principal (which may or may not be a human user),=20 > but would like to be able to use a RADIUS server to provide=20 > information about what "SNMP-policy" (think SNMP-specific=20 > FilterID) the SNMP agent should apply regarding "which SNMP=20 > operations to what SNMP data sets" the already-authenticated=20 > "user" is permitted.=20 >=20 > And they would like to get the SNMP-policy without having to=20 > perform another authentication of the principal via the=20 > RADIUS server, since requiring that might force the operators=20 > to store the principal's authentication credentials at the=20 > SNMP agent or require the realtime intervention of a human=20 > being. The "NAS" has already done an authentication and does=20 > not want to waste resources doing yet another one. >=20 > We only want this "authorize-only" service to be performed at=20 > the request of an authenticated/trusted RADIUS client. If the=20 > AAA trust for an ISMS-related client is compromised, the=20 > situation should be identical to that of any other=20 > compromised AAA client - all bets are off concerning the=20 > behavior of the RADIUS client. =20 >=20 > Who provides the hints that identify which set of attributes=20 > should be returned in a request-accept? The AAA client? If=20 > the AAA client is compromised, who provides the hints that=20 > identify which set of attributes should be returned? >=20 > dbh >=20 > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Monday, July 24, 2006 3:16 PM > > To: David Harrington > > Cc: 'Avi Lior'; 'Nelson, David'; isms@ietf.org; > radiusext@ops.ietf.org > > Subject: Re: Follow up on Authorize Only issue (was RE:=20 > > [Isms] ISMS session > >=20 > > Dave, > > > Hi, > > > > > > Let me point out that authorize only is being requested for use > with > > > SNMP. The NAS is effectively the SNMP agent, and the RADIUS=20 > > > interaction is to determine which data the already authenticated=20 > > > principal should be allowed to access. > > > > > > If the NAS is compromised, then the SNMP agent is=20 > compromised, and=20 > > > within the scope of the managed entity, you are probably already=20 > > > toast, with or without support from RADIUS. And if the SNMP agent > is > > > compromised, then an attacker probably doesn't much care what > RADIUS > > > has to say about accessing the SNMP MIB. > > > =20 > >=20 > > I've lost the plot just a little here. I thought the concern was=20 > > beyond the scope of the managed entity but the broader=20 > service area of=20 > > the radius server. > >=20 > > Eliot > >=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: Sun, 23 Jul 2006 21:31:31 +0000 Message-ID: From: "Bernard Aboba" To: aland@nitros9.org Cc: isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: Re: Follow up on Authorize Only issue Date: Sun, 23 Jul 2006 14:31:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed >A compromised NAS can leverage this requested feature to obtain >that information more readily. Right now, if the NAS hasn't had a >user log in through it, it can get those credentials only through a >brute force attack on the password. The server *should* be able to >catch that attack, mitigating the vulnerability. Right. > > If this is allowed, it should follow the principle of "least privilege", > > only providing the attributes relevant to SSH. > >Which means that the Access-Request has to be recognizable as for >SSH in this use-case. This means an attribute or value specifically >for this purpose. The RADIUS server can then key off of that special >request, and return a limited response. Right. For example an additional Service-Type value of "SSH" could be allocated One concern would be whether an attacker could use this Service-Type with any NAS-Port-Type, in order to retrieve attributes relevant to that NAS-Port-Type. To prevent this, one possibility is to add NAS-Port-Type values of "SSH" and "ISMS" (since different attributes might be returned for a straight SSH or SSH-protected ISMS session) and only allow Service-Type="SSH" to be used with those NAS-Port-Type values; all other NAS-Port-Type values would result in an Access-Reject. >The use case should also enumerate the possible attributes and >values needed in the Access-Accept, and state explicitely that >responding with any other attributes or values may result in security >violations. i.e. Other attributes and values SHOULD NOT be sent in >the Access-Accept. Makes sense. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 23 Jul 2006 16:02:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue Date: Sun, 23 Jul 2006 09:02:01 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250259749B@xmb-sjc-215.amer.cisco.com> Thread-Topic: Follow up on Authorize Only issue Thread-Index: AcatXDtdLUyDubsZS5mYy7NB27+YngBErYwQ From: "Glen Zorn \(gwz\)" To: "Bernard Aboba" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=1751; t=1153670523; x=1154534523; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DgYUCFFU2lrC1AfD+49l4JpczLFs=3D; b=D7rhSGItymYOuz6XgSOOBnoycpvDMjHY3jiVtXhsg0fdydjH67/Fl1/PyU3QjoJnZQjBeFSg Q/KqZRlAcM/I/TaXdlc1y126A2IqdJYCuuIoyVANAZkXyklS0tC26xAT; Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Bernard Aboba <> supposedly scribbled: > The security implications of unrestricted access to *any* user > attributes are fairly severe.=20 I agree, but apparently not severe enough to warrant changing the way = RADIUS handles CHAP at any time over, oh , the last 10 years. >=20 > For example, should a NAS be able to retrieve the Tunnel-Password > attribute of any user, regardless of whether they are connected?=20 Of course not, but there are arguably lots of things that shouldn't be = yet are: the point is that allowing Authorize-Only in this case actually = doesn't open any new security holes. >=20 > There are also VSAs that contain sensitive information. >=20 > The Call-Check Service typically provides very little information in > the Access-Accept (all that is needed is whether to accept or reject > the call) so there is minimal leakage. =20 >=20 > If this is allowed, it should follow the principle of "least > privilege", only providing the attributes relevant to SSH.=20 >=20 >=20 >=20 >=20 >> For the SSHSM usage case, the question is whether it is an >> unacceptable security risk for a trusted NAS to be able to obtain >> authorization information about a user that is not actually >> "present" at the NAS? OK, this is becoming slightly absurd. I am not a cryptographer, but I = do know that one of the cardinal assumptions of secret-key cryptography = is that the secret key stays secret. This "trusted NAS" should not be = trusted because the secret has been compromised; if the secret is no = longer a secret, all bets are off.=20 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: Sat, 22 Jul 2006 15:27:14 +0000 From: "Alan DeKok" To: "Bernard Aboba" Subject: Re: Follow up on Authorize Only issue cc: isms@ietf.org, radiusext@ops.ietf.org Date: Sat, 22 Jul 2006 11:17:37 -0400 Message-Id: <20060722151737.B478C16E1E@mail.nitros9.org> "Bernard Aboba" wrote: > For example, should a NAS be able to retrieve the Tunnel-Password attribute > of any user, regardless of whether they are connected? i.e. A compromised NAS can leverage this requested feature to obtain that information more readily. Right now, if the NAS hasn't had a user log in through it, it can get those credentials only through a brute force attack on the password. The server *should* be able to catch that attack, mitigating the vulnerability. For users who have logged in through a compromised NAS, nearly all hope for security is lost. > If this is allowed, it should follow the principle of "least privilege", > only providing the attributes relevant to SSH. Which means that the Access-Request has to be recognizable as for SSH in this use-case. This means an attribute or value specifically for this purpose. The RADIUS server can then key off of that special request, and return a limited response. The use case should also enumerate the possible attributes and values needed in the Access-Accept, and state explicitely that responding with any other attributes or values may result in security violations. i.e. Other attributes and values SHOULD NOT be sent in the Access-Accept. 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: Sat, 22 Jul 2006 06:58:22 +0000 Message-ID: From: "Bernard Aboba" To: isms@ietf.org, radiusext@ops.ietf.org Bcc: Subject: RE: Follow up on Authorize Only issue Date: Fri, 21 Jul 2006 23:57:53 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The security implications of unrestricted access to *any* user attributes are fairly severe. For example, should a NAS be able to retrieve the Tunnel-Password attribute of any user, regardless of whether they are connected? There are also VSAs that contain sensitive information. The Call-Check Service typically provides very little information in the Access-Accept (all that is needed is whether to accept or reject the call) so there is minimal leakage. If this is allowed, it should follow the principle of "least privilege", only providing the attributes relevant to SSH. >For the SSHSM usage case, the question is whether it is an >unacceptable security risk for a trusted NAS to be able to obtain >authorization information about a user that is not actually >"present" at the NAS? -- to unsubscribe send a message to radiusext-request@ops.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, 21 Jul 2006 21:29:02 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue Date: Fri, 21 Jul 2006 14:27:47 -0700 Message-ID: Thread-Topic: Follow up on Authorize Only issue Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1JsgAZJeE4AAAavUIA== From: "Joseph Salowey \(jsalowey\)" To: "Nelson, David" , , DKIM-Signature: a=rsa-sha1; q=dns; l=1205; t=1153517329; x=1154381329; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue; X=v=3Dcisco.com=3B=20h=3DObZ73vujEK3pOnVK5sX7aGBdRmQ=3D; b=lcXQGZYhHEpGogR4VQcF0UrnZIgeHKDr+VygJBOHaHo4ZZZRsfFRea6U7ux+fntN6KT+8SXG B1m1wXHRqEBwjh3yK55mqYpM6qqLgcDXC/9fKZA/NeBzMIxh9T09jOm7; Authentication-Results: sj-dkim-1.cisco.com; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com verified; ); I agree with Avi, Glen and Alan. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Friday, July 21, 2006 1:44 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue >=20 > > For the SSHSM usage case, the question is whether it is an=20 > > unacceptable security risk for a trusted NAS to be able to obtain=20 > > authorization information about a user that is not actually=20 > "present"=20 > > at the NAS? >=20 > My interpretation is that three respondents (Glen, Alan, Avi)=20 > believe that the answer is "no". The existing RADIUS trust=20 > model collapses if the NAS has been compromised and does=20 > nefarious or foolish things. >=20 > I'd like to determine if we have consensus on this position. If you > *have* an opinion on this issue, please *respond* whether you=20 > agree or disagree with this assertion. >=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: Fri, 21 Jul 2006 20:44:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue Date: Fri, 21 Jul 2006 16:43:47 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219381@MABOSEVS2.ets.enterasys.com> Thread-Topic: Follow up on Authorize Only issue Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1JsgAZJeE4A= From: "Nelson, David" To: , > For the SSHSM usage case, the question is whether it=20 > is an unacceptable security risk for a trusted NAS to be=20 > able to obtain authorization information about a user that > is not actually "present" at the NAS? My interpretation is that three respondents (Glen, Alan, Avi) believe that the answer is "no". The existing RADIUS trust model collapses if the NAS has been compromised and does nefarious or foolish things. I'd like to determine if we have consensus on this position. If you *have* an opinion on this issue, please *respond* whether you agree or disagree with this assertion. -- to unsubscribe send a message to radiusext-request@ops.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, 21 Jul 2006 18:45:09 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Date: Fri, 21 Jul 2006 14:44:52 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIAAkCaXsA== From: "Avi Lior" To: "Nelson, David" , , David, I agree with Glen and Alan. NAS is within the trust boundary of AAA. =20 If you comprise the NAS you are done. It can leak information, modify accounting, disallow or allow services that are not authorized. > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, July 18, 2006 6:10 PM > To: isms@ietf.org; radiusext@ops.ietf.org > Subject: RE: Follow up on Authorize Only issue (was RE:=20 > [Isms] ISMS session >=20 > Avi Lior writes... > =20 > > I am having trouble understanding "user that is not=20 > actually present". >=20 > In the proposed use case, the NAS could request, from a=20 > RADIUS server, authorization information for a user that it=20 > asserts is present, but is not. The RADIUS server cannot=20 > tell, since no user credentials are presented. Well behaved=20 > NASes won't do this. One might argue that all trusted NASes=20 > will be well behaved, but that makes certain threat model assumptions. >=20 > Why would a (compromised) NAS want to do this? Well, leaking=20 > authorization information on various user accounts may help=20 > an attacker select high value target accounts.=20 >=20 > The only standardized scenario for non-authenticated=20 > authorization RADIUS is call check. The assumption is that=20 > the PSTN is a reliable source of the telephone number(s), the=20 > NAS is trusted and non-compromised, and the user will=20 > typically be authenticated once the session is initiated. =20 > Thus, the risk is relatively low. >=20 > For Dynamic RADIUS, RFC 3576 requires a State attribute,=20 > which can only have come from a previous successful authentication. >=20 > In this particular ISMS use case, SNMP service is authorized=20 > based on the assertion of identity of the user by the NAS,=20 > without the RADIUS server ever having performed an=20 > authentication, and without the benefit of the resultant=20 > State attribute. Thus, the risk is potentially higher. >=20 > The questions at hand are whether the risk is high enough to=20 > be of serious concern, and whether or not it can be mitigated? >=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: Thu, 20 Jul 2006 17:52:51 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Issues & fixes (was Re: Tagged attibutes ) cc: radiusext@ops.ietf.org Date: Thu, 20 Jul 2006 13:43:25 -0400 Message-Id: <20060720174325.1CC2816E4A@mail.nitros9.org> "Nelson, David" wrote: > I respectfully disagree. RFC 2868 also says: ... > Both the ASCII art and the sentence "If the Tag field is unused, it MUST > be zero (0x00)." tell me that that Tag Field is not optional. It is > always present in these attributes, and if it is not used it is set to > zero, rather than omitted. I agree, and that doesn't invalidate my earlier comments. The Tunnel-Type attribute overloads the "integer" types previously defined in RFC 2865. The intent was that older RADIUS servers can treat the 4 octets of "tag + value" as a 32-bit integer, for full compatibility. So for "integer" types, the requirement that they be 4 octets means that the tag field MUST be present, and MUST be zero if unused. Let's look at another attribute: 3.3. Tunnel-Client-Endpoint ... A summary of the Tunnel-Client-Endpoint Attribute format is shown below. The fields are transmitted from left to right. 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 | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. If the value of the Tag field is greater than 0x00 and less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of several alternatives) this attribute pertains. If the Tag field is greater than 0x1F, it SHOULD be interpreted as the first byte of the following String field. ... i.e. there is NO requirement here that the tag be set to zero if it's unused. This is because this attribute is overloading the "text/string" types previously defined in RFC 2865. As many older servers treat the attributes as C strings, a requirement to always put a tag of 0 for "no tag" would mean breaking backwards compatibility with those servers. The original question starting this was about Tunnel-Private-Group-Id, which is also "tag + string". If a RADIUS server *always* puts a tag of zero for "no tag", then there are other servers out there, and probably clients, which will interpret that attribute as being an empty string. > Now, I realize that it is possible to omit the Tag Field and parse the > packet correctly when the first octet of the value field is not a Tag > and is greater than 0x1F or less than 0x00. I think that RFC 2868 is > internally inconsistent in this regard and that we should indeed address > this issue in the Issues & Fixes document. I don't see any inconsistency in RFC 2868. I see that the requirement to be backwards compatible is more important than the requirement to always put a tag in a "string" attribute. 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, 20 Jul 2006 15:44:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: Issues & fixes (was Re: Tagged attibutes ) Date: Thu, 20 Jul 2006 11:44:13 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021937C@MABOSEVS2.ets.enterasys.com> Thread-Topic: Issues & fixes (was Re: Tagged attibutes ) Thread-Index: AcasEJT0InH98VseTK2REpqM78dngQAAZaBQ From: "Nelson, David" To: Alan DeKok writes... > > So we know what to do if the tag is greater then 0.=20 > > But what do we do it it is equal to zero? >=20 > My opinion is that the tag should be suppressed, and not > put into the attribute. I respectfully disagree. RFC 2868 also says: A summary of the Tunnel-Type Attribute format is shown below. The fields are transmitted from left to right. 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 | Tag | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 64 for Tunnel-Type Length Always 6. Tag The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the Tag field is unused, it MUST be zero (0x00). Both the ASCII art and the sentence "If the Tag field is unused, it MUST be zero (0x00)." tell me that that Tag Field is not optional. It is always present in these attributes, and if it is not used it is set to zero, rather than omitted. Now, I realize that it is possible to omit the Tag Field and parse the packet correctly when the first octet of the value field is not a Tag and is greater than 0x1F or less than 0x00. I think that RFC 2868 is internally inconsistent in this regard and that we should indeed address this issue in the Issues & Fixes document. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 Jul 2006 15:23:29 +0000 From: "Alan DeKok" To: Tomasz Wolniewicz Subject: Issues & fixes (was Re: Tagged attibutes ) cc: radiusext@ops.ietf.org Date: Thu, 20 Jul 2006 11:13:48 -0400 Message-Id: <20060720151348.D4A7716E3E@mail.nitros9.org> Tomasz Wolniewicz wrote (edited): > I have recently got hit by a VLAN setting problem and lack of > interoperability between ZZZ Radius server and 3COM access-point. > As it turned out, it seems that the access-point does not handle tagged > attributes. On the other hand ZZZ does a strange thing when one > does not specify the tag. I looked at RFC 2868 and found out that it is > impossible to tell who gets things wrong. The RFC says: > > 3.6. Tunnel-Private-Group-ID > > .... > .... > > The Tag field is one octet in length and is intended to provide a > means of grouping attributes in the same packet which refer to the > same tunnel. If the value of the Tag field is greater than 0x00 > and less than or equal to 0x1F, it SHOULD be interpreted as > indicating which tunnel (of several alternatives) this attribute > pertains. If the Tag field is greater than 0x1F, it SHOULD be > interpreted as the first byte of the following String field. > > So we know what to do if the tag is greater then 0. But what do we do it > it is equal to zero? My opinion is that the tag should be suppressed, and not put into the attribute. > the RFC does not say that it MUST NOT be equal to zero. FreeRadius > seems to handle tags equal to zero well, but if you try to set a tag > to zero in the configuration, the FreeRadius will simply send an > untagged value. ZZZ, however sets the tag to 0 and there seems > to be no way to make it to send an untagged value. If the other server sends a tag with value zero, the client SHOULD ignore it. > My 3COM AP obviously has a problem that it does not handle tags greater > then 0 but with those equal to 0 things are not so clear. It would appear then that the problem mainly lies with the AP, which implements support for tagged attributes... so long as they don't have a tag. If the other RADIUS server can't be made to suppress the tag of zero, then there is an interoperability problem. > So my point is - don't you think that RFC 2868 should be fixed as well > and that such a thing would fit into the draft that you are co-authoring? We could mention it in the "issues and fixes" document. Client implementations that support tagged attributes, but don't support the tag in those attributes are... odd. 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, 19 Jul 2006 04:10:14 +0000 From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) cc: isms@ietf.org, radiusext@ops.ietf.org Date: Wed, 19 Jul 2006 00:00:44 -0400 Message-Id: <20060719040044.8779416E3C@mail.nitros9.org> "Glen Zorn \(gwz\)" wrote: > OK, yeah, but I didn't say anything about guesses: in that scenario, the > compromised NAS has saved valid credentials from previous = > authentications & used them for nefarious purposes. It could also save authorization parameters, for precisely the same reason. > I hope that the issue is not divulging the contents of RADIUS attributes > but something a bit more serious, like authorizing an imposter. A compromised NAS can authorize anyone it chooses for any purpose. If the threat we're trying to avoid is a compromised NAS, then there is little point in doing more security analysis. The NAS is *inside* of the RADIUS trust boundary, with all of the side-effects that result. If the threat we're trying to avoid is someone fooling a trusted NAS into leaking information about users, then that situation is somewhat more managable. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jul 2006 23:55:10 +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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 16:54:42 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250253CEA1@xmb-sjc-215.amer.cisco.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaqvR+mdBpto3TzRp6ZPN3WTSHcqQABzy2g From: "Glen Zorn \(gwz\)" To: Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=2005; t=1153266883; x=1154130883; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session=20summary)=20; X=v=3Dcisco.com=3B=20h=3DCjpP+uhlnMxVEplGPhlYMpJKjW8=3D; b=jqI+104b1X1c3GUrrdZT5YXzCJJewPX/rE+CmUq6AHlVruZzXqh+nDdGO8xtag2sZvtnVVj/ p/diFYciulz8+wu5oNjcoks8DJGR/+9OvAwmiYxFBbcXK8/qeWQvyui5; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); aland@nitros9.org supposedly scribbled: > "Glen Zorn \(gwz\)" wrote: >> The risk I mention above has never seemed to bother anyone, at least >> not enough to fix it; >=20 > True. I think the concern here is that the user has not been > authenticated. In the above scenario, the bad guesses=20 OK, yeah, but I didn't say anything about guesses: in that scenario, the = compromised NAS has saved valid credentials from previous = authentications & used them for nefarious purposes. > have been > rejected, and no additional information leaks from the RADIUS server > to the NAS. If the user is authenticated, then information about the > user can, and should be sent from the server to the NAS. =20 >=20 > I could rephrase the original question as: what information can the > RADIUS server send to the NAS about the user, if the user was not > authenticated through RADIUS? =20 >=20 > For privacy and security, I think the answer is "none". For useful > networks, I think "authorize only" is pretty safe.=20 >=20 > If we look at another threat scenairo: A user is authenticated > through RADIUS, and RADIUS returns authorization parameters in the > Access-Accept. Since the contents of RADIUS packets aren't > encrypted, anyone who can see that traffic can see all of the users > authorization. So the information could be construed as public. =20 >=20 > In that case, there's little additional risk in sending that > information, again unencrypted, to a NAS without authenticating the > user. =20 >=20 > If the traffic *is* encrypted, then the previous analysis doesn't > apply...=20 I hope that the issue is not divulging the contents of RADIUS attributes = but something a bit more serious, like authorizing an imposter. >=20 > 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: Tue, 18 Jul 2006 22:54:28 +0000 From: "Alan DeKok" To: "Glen Zorn \(gwz\)" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) cc: isms@ietf.org, radiusext@ops.ietf.org Date: Tue, 18 Jul 2006 18:45:05 -0400 Message-Id: <20060718224505.BAF5216E3C@mail.nitros9.org> "Glen Zorn \(gwz\)" wrote: > The risk I mention above has never seemed to bother anyone, at least not > enough to fix it; True. I think the concern here is that the user has not been authenticated. In the above scenario, the bad guesses have been rejected, and no additional information leaks from the RADIUS server to the NAS. If the user is authenticated, then information about the user can, and should be sent from the server to the NAS. I could rephrase the original question as: what information can the RADIUS server send to the NAS about the user, if the user was not authenticated through RADIUS? For privacy and security, I think the answer is "none". For useful networks, I think "authorize only" is pretty safe. If we look at another threat scenairo: A user is authenticated through RADIUS, and RADIUS returns authorization parameters in the Access-Accept. Since the contents of RADIUS packets aren't encrypted, anyone who can see that traffic can see all of the users authorization. So the information could be construed as public. In that case, there's little additional risk in sending that information, again unencrypted, to a NAS without authenticating the user. If the traffic *is* encrypted, then the previous analysis doesn't apply... Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jul 2006 22:35: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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 15:34:40 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250253CE18@xmb-sjc-215.amer.cisco.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIAAARjBkA== From: "Glen Zorn \(gwz\)" To: "Nelson, David" Cc: , DKIM-Signature: a=rsa-sha1; q=dns; l=1330; t=1153262082; x=1154126082; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20Follow=20up=20on=20Authorize=20Only=20issue=20(was=20RE=3A=20[Is ms]=20ISMS=20session=20summary); X=v=3Dcisco.com=3B=20h=3DCjpP+uhlnMxVEplGPhlYMpJKjW8=3D; b=VUEEyTK54yHOA3X3eZkd/nUSi7Wibrb9x3cJBxmtCouO9wwUwpoCuCi5JXtyfa69EA52H5pb cp3tDr4C2W2k7E7YHUdSBwIv0Lx8y3T4lfy7KK5OSu19Vvdp2q5J7sbu; Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Nelson, David supposedly scribbled: ... >=20 > In this particular ISMS use case, SNMP service is authorized based on > the assertion of identity of the user by the NAS, without the RADIUS > server ever having performed an authentication, and without the > benefit of the resultant State attribute. Thus, the risk is > potentially higher. =20 Actually, the same risk has always been present in RADIUS, because of = the way that PPP CHAP (&, for that matter, the MD5-Challenge EAP method) = is implemented. The RADIUS server in the CHAP case generally has no = idea whether the user is actually present or not: the NAS presents the = server with a self-generated challenge and a response that may or may = not be a replay; without saving every challenge-response pair, the = server cannot know if the response is fresh or not. =20 >=20 > The questions at hand are whether the risk is high enough to be of > serious concern, and whether or not it can be mitigated?=20 The risk I mention above has never seemed to bother anyone, at least not = enough to fix it; I don't know why we should be obsessing over it now. ... 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, 18 Jul 2006 22:10:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 18:10:20 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219379@MABOSEVS2.ets.enterasys.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfAAAp4gIA= From: "Nelson, David" To: , Avi Lior writes... =20 > I am having trouble understanding "user that is not actually present". In the proposed use case, the NAS could request, from a RADIUS server, authorization information for a user that it asserts is present, but is not. The RADIUS server cannot tell, since no user credentials are presented. Well behaved NASes won't do this. One might argue that all trusted NASes will be well behaved, but that makes certain threat model assumptions. Why would a (compromised) NAS want to do this? Well, leaking authorization information on various user accounts may help an attacker select high value target accounts.=20 The only standardized scenario for non-authenticated authorization RADIUS is call check. The assumption is that the PSTN is a reliable source of the telephone number(s), the NAS is trusted and non-compromised, and the user will typically be authenticated once the session is initiated. Thus, the risk is relatively low. For Dynamic RADIUS, RFC 3576 requires a State attribute, which can only have come from a previous successful authentication. In this particular ISMS use case, SNMP service is authorized based on the assertion of identity of the user by the NAS, without the RADIUS server ever having performed an authentication, and without the benefit of the resultant State attribute. Thus, the risk is potentially higher. The questions at hand are whether the risk is high enough to be of serious concern, and whether or not it can be mitigated? -- to unsubscribe send a message to radiusext-request@ops.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, 18 Jul 2006 21:29:41 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Tue, 18 Jul 2006 17:29:29 -0400 Message-ID: Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcaoRVG02UdoqaT/Tk6lTHErEnDykgCRXPfA From: "Avi Lior" To: , "Nelson, David" Cc: , Hi > >=20 > > For the SSHSM usage case, the question is whether it is an=20 > > unacceptable security risk for a trusted NAS to be able to obtain=20 > > authorization information about a user that is not actually=20 > "present" at the NAS? >=20 > This probably needs more thought and discussion. >=20 I am having trouble understanding "..user that is not actually present" Why are we sending authorization attributes to a NAS where the user is not actually present. I have seen scenarios where we push authorization attributes to a NAS and hence that creates a Session for a user using COA for example.=20 >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=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: Sat, 15 Jul 2006 19:29:55 +0000 Date: Sat, 15 Jul 2006 21:29:20 +0200 From: Juergen Schoenwaelder To: "Nelson, David" Cc: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Message-ID: <20060715192920.GA6906@boskop.local> Reply-To: j.schoenwaelder@iu-bremen.de Mail-Followup-To: "Nelson, David" , isms@ietf.org, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.10i On Thu, Jul 13, 2006 at 04:59:18PM -0400, Nelson, David wrote: > > In an Access-Accept message, the NAS is trusted to have authorization > information for the user because (a) the NAS is trusted and (b) the user > is present at the NAS, so the NAS has a "need to know". The concerns > with Authorize Only operations, that do not have a previous successful > RADIUS authentication as a prerequisite, is that when the user is not > present at the NAS, the NAS does not have a "need to know" the user's > authorization status. Information might be leaked to a NAS about users, > that the NAS would not otherwise be entitled to have. Thanks, I think I understand this. Now I wonder how other AAA systems which I have been told to support authorize only deal with this issue. Can someone please explain? > IN RFC 3576, the requirement for a previous RADIUS authentication is met > by requiring a server State attribute t be in the Access-Request > message, which provides that binding for Authorize Only operation. If I understand this correctly, then you have (a) the NAS is trusted and (b) the user was previously present at the NAS here. Correct? > The only form of RADIUS operation that currently provides authorization > information on a "user" without user credentials is the call check > operation. In these cases the actual user is not identified, but rather > the user's phone number (or similar network address information). > > For the SSHSM usage case, the question is whether it is an unacceptable > security risk for a trusted NAS to be able to obtain authorization > information about a user that is not actually "present" at the NAS? This probably needs more thought and discussion. Thanks for discussing this issue and writing things up in a way that I seem to understand. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, 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, 15 Jul 2006 17:47:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Is there interest in Radius MIB notifications? Date: Sat, 15 Jul 2006 10:46:28 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_00B4_01C6A775.8032C160"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: Thread-Topic: Is there interest in Radius MIB notifications? Thread-Index: AcalMdW+EibiU2/xRgqG6jr14oRcpQAfuYEgAH/YvPA= From: "Sanchez, Mauricio (ProCurve)" To: "Carl Kalbfleisch" , This is a multi-part message in MIME format. ------=_NextPart_000_00B4_01C6A775.8032C160 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'd be interested in seeing this progress. MS > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Carl Kalbfleisch > Sent: Wednesday, July 12, 2006 5:55 AM > To: radiusext@ops.ietf.org > Subject: Is there interest in Radius MIB notifications? > > > Hi, > > Our customers desire SNMP Notifications when the "state" of > the radius server that the client is using changes. IE, when > timeouts occur send a notification and then when responses > are received again send another notification. > > Is there general interest/demand for this? > > Essentially I am planning an enterprise extension to the > Radius Authentication and Accounting Client MIBs which are > defined in draft-ietf-radext-rfc2618bis-04.txt and > draft-ietf-radext-rfc2620bis-04.txt > > Carl > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > ------=_NextPart_000_00B4_01C6A775.8032C160 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDcxNTAxNDQxM1owIwYJ KoZIhvcNAQkEMRYEFIr4tJ6cNVdfvaJkhlhdTthr9S2YMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgCpP7al89rTkZveCaY/iqjHPBQ9Owp1qis0zCZIrP358ep5rn7Qz/HankwXZa+gf y2qHte2l7S11HI8EbxP/IUyH+iV8mP1DZww+PogYslrI+Af3Jx1cKZiDwWoIYjKL9RB3xkA5dM4W ScCGfloSVgt0BiwGbJzQ8wid7iX2h+V2AAAAAAAA ------=_NextPart_000_00B4_01C6A775.8032C160-- -- to unsubscribe send a message to radiusext-request@ops.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, 14 Jul 2006 18:38:03 +0000 From: "Alan DeKok" To: isms@ietf.org, radiusext@ops.ietf.org Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Fri, 14 Jul 2006 14:28:46 -0400 Message-Id: <20060714182846.285A716CBC@mail.nitros9.org> "Alan DeKok" wrote: > If the server had some auditing capability for Authorize-Only > requests, an admin could correlate that information with > authentication performed by non-RADIUS servers. That would mitigate > the concerns over the RADIUS server not performing the authorization. ^^^^^^^^^^^^^ "authentication". 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, 14 Jul 2006 18:31:24 +0000 From: "Alan DeKok" To: "Nelson, David" Subject: Re: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) cc: isms@ietf.org, radiusext@ops.ietf.org Date: Fri, 14 Jul 2006 14:22:10 -0400 Message-Id: <20060714182210.3735F16CBC@mail.nitros9.org> "Nelson, David" wrote: > For the SSHSM usage case, the question is whether it is an unacceptable > security risk for a trusted NAS to be able to obtain authorization > information about a user that is not actually "present" at the NAS? i.e. "present" as in "the RADIUS server performed the authentication, and verified that the user is present". Is there any *other* authentication credentials that can be sent to the RADIUS server, to mitigate the issue? e.g. A kerberos ticket? The RADIUS server could either validate the kerberos ticket itself, or log the ticket for later auditing. If it's too hard to send the ticket, maybe a hash of the ticket, or ticket ID (I'm not sure if this is available or useful in Kerberos..) If the server had some auditing capability for Authorize-Only requests, an admin could correlate that information with authentication performed by non-RADIUS servers. That would mitigate the concerns over the RADIUS server not performing the authorization. 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, 14 Jul 2006 18:23:27 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: WGLC comments for draft-ietf-geopriv-radius-lo-07 Date: Fri, 14 Jul 2006 20:22:57 +0200 Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1E29A@SEHAN021MB.tcad.telia.se> Thread-Topic: WGLC comments for draft-ietf-geopriv-radius-lo-07 Thread-Index: AcanSQk2YbqenFx9SEOgiAMLnOh71gAJsiQA From: To: , , Hi, Thanks Pasi for the detailed review. One comment on the TADIG codes. See below: =20 [snip] > I do have a couple of minor and mostly editorial comments, though: >=20 > 1) Section 5.1 says: >=20 > "GSM (0): >=20 > This namespace 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 of this type." >=20 > The GSM system uses many different codes to identify operators in > different contexts; thus, this probably should be called "GSM_TADIG" > or just "TADIG". Also, we need a reference (any kind of reference is > better than none), expand the acronym, and specify how the value is > encoded. >=20 > Suggested text: >=20 > TADIG (0): > =20 > This namespace can be used to indicate operator names based on > Transferred Account Data Interchange Group (TADIG) codes defined in > [NNN]. TADIG codes are assigned by the TADIG Working Group within > the GSM Association. The TADIG code consists of five uppercase > ASCII characters. The TADIG code consists of 3 character country code and 2 character operator/company code. The latter can actually be alphanumeric. E.g. one of ours is FINV1. So it might be better to state this. For example: The TADIG Code consists of two fields, with a total length of five ASCII characters consisting of a three-character country code and a two-character aplhanumeric operator (or company) ID. > [NNN] GSM Association, "TADIG Naming Conventions, Version 4.1",=20 > GSM Association Official Document TD.13, June 2006. >=20 > (The document is not currently on the GSMA web site, but it is > classified "Unrestricted". I talked with Jouni Korhonen about this and > he promised to find out if it could be made more easily available.) [snap] > Best regards, > Pasi Cheers, Jouni >=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: Fri, 14 Jul 2006 13:28:39 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: WGLC comments for draft-ietf-geopriv-radius-lo-07 Date: Fri, 14 Jul 2006 16:25:55 +0300 Message-ID: Thread-Topic: WGLC comments for draft-ietf-geopriv-radius-lo-07 Thread-Index: AcanSQk2YbqenFx9SEOgiAMLnOh71g== From: To: , This document has been around for a long time, and we really should get it out. I think there are some parts of the document that are unnecessarily complex and/or inelegant, but I understand that they're a result of a long process of making the document acceptable to various constituencies. Since my objections would be of the "it could be nicer" type rather than "it doesn't work", I won't complain them now. Let's get this out; it's good enough. I do have a couple of minor and mostly editorial comments, though: 1) Section 5.1 says: "GSM (0): This namespace 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 of this type." The GSM system uses many different codes to identify operators in different contexts; thus, this probably should be called "GSM_TADIG" or just "TADIG". Also, we need a reference (any kind of reference is better than none), expand the acronym, and specify how the value is encoded. Suggested text: TADIG (0): =20 This namespace can be used to indicate operator names based on Transferred Account Data Interchange Group (TADIG) codes defined in [NNN]. TADIG codes are assigned by the TADIG Working Group within the GSM Association. The TADIG code consists of five uppercase ASCII characters. [NNN] GSM Association, "TADIG Naming Conventions, Version 4.1",=20 GSM Association Official Document TD.13, June 2006. (The document is not currently on the GSMA web site, but it is classified "Unrestricted". I talked with Jouni Korhonen about this and he promised to find out if it could be made more easily available.) 2) Another comment about Section 5.1: "CDMA (1): The CDMA operator namespace 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 type." No no no... the Mobile Country Code (MCC) and Mobile Network Code (MNC) are defined in E.212, and ITU-T is the authority for MCCs. IMSI Oversight Council is the national authority for assigning MNCs within the US country codes; other countries have their own authorities. The E.212 numbering and MCC/MNC are not specific to CDMA; GSM, UMTS and other systems use them as well. And the text needs to say how they're encoded in the field (as many protocols use something weird such as BCD for MCC/MNC). Suggested rephrasing: E212 (1): =20 The E212 namespace can be used to indicate operator names based on the Mobile Country Code (MCC) and Mobile Network Code (MNC) defined in [NNN]. The MCC/MCC values are assigned by the Telecommunications Standardization Bureau (TSB) within the ITU-T and designated administrators in different countries. The E212 value consists of three ASCII digits containing the MCC, followed by two or three ASCII digits containing the MNC. [NNN] ITU-T, "The international identification plan for mobile terminals and mobile users", ITU-T Recommendation E.212 (05/2004), May 2004. 3) Yet another comment about Section 5.1: "ITU (3): The ITU operator namespace can be used to indicate operator names based on ITU Carrier codes. The Telecommunication Standardization Bureau (TSB) within the ITU-T is the authority responsible for the repository. Each national regulatory authority is responsible for issuing unique Operator-Name values for operators of this type." This is really badly named, because ITU is the authority for so many different namespaces. There's no reference (M.1400). And because ICC is unique only within a country, M.1400 uses them together with a country code (the three-letter alphanumeric code from ISO 3166). Suggested rephrasing: ICC (3): The ICC namespace can be used to indicate operator names based on ITU Carrier Codes (ICC) defined in [NNN]. ICC values are assigned by national regulatory authorities and are coordinated by the Telecommunication Standardization Bureau (TSB) within the ITU-T. When using the ICC namespace, the attribute consists of three uppercase ASCII characters containing a three-letter alphabetic country code as defined in [MMM], followed by one to six uppercase alphanumeric ASCII characters containing the ICC itself. =20 [NNN] ITU-T, "Designations for interconnections among operators' networks", ITU-T Recommendation M.1400 (01/2004), 2004. =20 [MMM] ISO, "Codes for the representation of names of countries and their subdivisions - Part 1: Country codes", ISO 3166-1:1997. 4) Section 5.3: "The format of the data is described in Section 3.1 of [4] whereby the first 8 bits (i.e., the code for this DHCP option) are not included." Hmm... shouldn't we also skip the length and "what" fields? 5) Section 5.4: "The RFC 3825 Location Configuration Information (LCI) format defined in Section 2 of RFC 3825 starting with bit 17 (i.e., the code for the DHCP option and the length field is not included.)." RFC 3825 Section 2 numbers bits from 0, so it's really "starting with bit 16". But "starting with the third octet (i.e. [...])" would be less ambiguous. 6) Section 5.5 says that "The Basic-Policy-Rules attribute MUST be sent in an Access-Accept, an Access-Challenge, an Access-Request, an Access-Reject and an Accounting-Request message if location information is transmitted with this exchange. If authorization policy rules are available to the RADIUS client then the Access-Request MUST carry the Basic- Policy-Rules attribute to to the RADIUS server." This paragraph is very difficult to understand; I'd suggest some rephrasing (almost the same text appears also in Section 5.6, and equally unclear). 7) Section 5.6 says "The full ruleset SHOULD be fetched using Transport Layer Security (TLS)." Is this trying to say that "The=20 URI SHOULD use the "https" scheme?" or something else? 8) Section 5.7: "The Value field is four octets. Every bit of the two octets MUST be set to 0." What about the other two of the four octets? :) 9) Section 5.8: "The Value field is at least 8 octets in length" Not "at least", since the total attribute length is exactly 10,=20 not at least 10. 10) Section 6, the second table suggests that "Location-Info-Required" is an attribute; isn't it an Error-Cause value? 11) Section 7: Hmm... I wonder if the AVP Flag rules are really right. For example, is it really necessary to set the "M" bit for Challenge-Capable? If the NAS is upgraded before the AAA server, the M bit would cause the AAA server to reject the request (and the NAS has to re-send the request without this AVP); but in this case, perhaps just ignoring the AVP might be a better idea? Other attributes are less clear; at least Operator-Name looks reasonably safe to=20 ignore (suggesting that maybe the "M" bit should be in MAY column); the location information/policies are less clear. (Although I'm not sure if the word "clear" can really apply to any=20 text about Diameter mandatory AVPs :-) 12) Section 8.3, req 1: "The same civic location information format is used in PIDF-LO [16] and this document." It looks similar, but it's not exactly the same format, right? 13) Section 11.1: "new values to the Operator-Namespaces will be assigned after Expert Review by the Geopriv working group or its designated successor." According to RFC 2434, "Expert Review" means review by a designated expert, and that's a person (appointed by the AD), not a working group. But maybe the intent was to say that the designated expert should consult the Geopriv WG? Same applies to Section 11.2 as well. Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 13 Jul 2006 21:00: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: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Date: Thu, 13 Jul 2006 16:59:18 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219368@MABOSEVS2.ets.enterasys.com> Thread-Topic: Follow up on Authorize Only issue (was RE: [Isms] ISMS session summary) Thread-Index: AcamoMmNnAEnI466RJyA/LWJ66zJ9QAG1Jsg From: "Nelson, David" To: Cc: Juergen Quittek writes... > Finally, the WG discussed RADIUS integration of the SSH security model. > There seems to be different positions in the security community about > whether or not 'authorization only' requests harmonize or dis-harmonize > with the Kerberos architecture. We had a lunchtime meeting today to discuss this issue, with Jeff Hutzelman, Bernard Aboba, Russ Housley and myself. The problem turns out to be more with the RADIUS architecture and the trust models than an issue with the Kerberos architecture. This issue was not brought up in RADEXT on Monday, and the issues that were brought up in RADEXT on this point seem to have been addressed. The remaining issue, in a nutshell, with the desired Authorize Only usage is as follows. In RADIUS, Access-Request messages can be authenticated by two means, the user credentials, e.g. User-Password or CHAP-Password, or Message-Authenticator. All of these are based on the RADIUS client and server sharing a secret. One major difference between the user credentials and the Message-Authenticator is that that former provide proof to the RADIUS server that the given user is "present" at the NAS. The latter only provides proof to the RADIUS server that the NAS is trusted. =20 In an Access-Accept message, the NAS is trusted to have authorization information for the user because (a) the NAS is trusted and (b) the user is present at the NAS, so the NAS has a "need to know". The concerns with Authorize Only operations, that do not have a previous successful RADIUS authentication as a prerequisite, is that when the user is not present at the NAS, the NAS does not have a "need to know" the user's authorization status. Information might be leaked to a NAS about users, that the NAS would not otherwise be entitled to have. IN RFC 3576, the requirement for a previous RADIUS authentication is met by requiring a server State attribute t be in the Access-Request message, which provides that binding for Authorize Only operation. The only form of RADIUS operation that currently provides authorization information on a "user" without user credentials is the call check operation. In these cases the actual user is not identified, but rather the user's phone number (or similar network address information). For the SSHSM usage case, the question is whether it is an unacceptable security risk for a trusted NAS to be able to obtain authorization information about a user that is not actually "present" at the NAS? -- to unsubscribe send a message to radiusext-request@ops.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, 13 Jul 2006 18:22:42 +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: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Thu, 13 Jul 2006 14:22:45 -0400 Message-ID: Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: Acal4kckj6EcxVPAQ82x7sPAyQ1bzwAxj72g From: "Avi Lior" To: "Alan DeKok" , "Emile van Bergen" Cc: "Bernard Aboba" , Alan, I am not trying to defend my draft. But I do not think that RADEXT should be making a choice because OpenDiameter has implmeneted a particular work. This is NOT how we should be making decisions. =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Alan DeKok > Sent: Wednesday, July 12, 2006 2:26 PM > To: Emile van Bergen > Cc: Bernard Aboba; radiusext@ops.ietf.org > Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG=20 > meeting at IETF 66 >=20 > Emile van Bergen wrote: > > Agreed, however, the inner length field in the Lior proposal seems=20 > > redundant, and instead of using attribute 26, vendor 0, I think its=20 > > better to allocate a separate attribute >=20 > I agree. After seeing this discussion go around in circles=20 > for a long time, I think enough is enough. >=20 > Therefore, I'm happy to announce that FreeRADIUS now has an=20 > implementation of the Extended-Attribute from=20 > draft-wolff-radext-ext-attribute-00.txt. For code, see the=20 > CVS instructions on www.freeradius.org/development.html >=20 > We'll reference the "Diameter-Encoded RADIUS Attributes" as=20 > DERA's, to distinguish them from RADIUS or proper Diameter AVP's. >=20 > * Extended-Attribute is attribute 192, because it's in the > "Experimental" space from RFC 2865. Changing this to an IANA > allocated number will mean editing 2 lines of text. > * The implementation can handle both the Extended-Attribute and > Ascend's pseudo-VSA at attribute 192, simultaneously in=20 > one packet. > * Data types supported include integer, date, IP address, IFID, IPv6 > address, IPv6 prefix, text and string (limited to 240 bytes or so) > * Diameter-style VSA's via the "V" bit are fully supported, and are > in a separate attribute space from RADIUS VSA's > * no tag, encryption, or grouping is currently supported > * no Diameter AVP flags other than "V" are supported > (i.e. they're forbidden) > * Each DERA must be in it's own Extended-Attribute > (i.e. no concatenation, as of yet) > * DERA attributes of less than 256 are forbidden, as they should be > encoded as RADIUS attributes > * DERA attributes of 256..32767 are forbidden, as they have meaning > within Diameter, and RADIUS servers cannot properly deal with them > * DERA's are arbitrarily assigned the attribute space 32768..65535. > * Outside of the RADIUS marshalling/unmarshalling code, nothing else > in the server is aware that the attributes are encoded in any > special way. > * The new attributes are indistinguishable (other than by name)=20 > from existing RADIUS attributes to existing deployments > * the RADIUS client included with FreeRADIUS has full support for > DERA's in all RADIUS packets, with no code changes to the client. > * less than 400 lines of code, limited to a packet handling library > * can be easily extended to support multiple Diameter-style AVP's > in one or more Extended-Attribute. > * with a little more work, can be extended to support text/string > DERA's with more than 240 bytes of data. >=20 > The initial implementation exists. Let's see if we can=20 > have multiple inter-operable implementations. >=20 > "Rough consensus and running code" has not been making progress. > Let's try "running code and rough consensus". >=20 > Alan DeKok. >=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: Thu, 13 Jul 2006 16:06:10 +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: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Thu, 13 Jul 2006 12:06:40 -0400 Message-ID: Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: AcakaoG9oHQR8cygRcGAeujUfSLfpAA3/oew From: "Avi Lior" To: "Bernard Aboba" , I support this consensus.=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, July 10, 2006 5:45 PM > To: radiusext@ops.ietf.org > Subject: Consensus Call: "Sense of the Room" at RADEXT WG=20 > meeting at IETF 66 >=20 > At the RADEXT WG meeting at IETF 66, we took a "sense of the=20 > room" with respect to what the WG should do with respect to=20 > the exhaustion of the=20 > RADIUS standard attribute space. A consensus appeared to=20 > emerge. We=20 > would now like to confirm that consensus on the RADEXT WG=20 > mailing list. >=20 > In your reply to this message, please state whether you=20 > support the consensus described below, or whether you=20 > disagree with it (and if so, how). >=20 > The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: >=20 > * Exhaustion of the RADIUS standard attribute space is a=20 > problem that should be solved. > * RADEXT WG is the place to solve the problem. > * The attribute exhaustion problem should be the focus -- not=20 > adding other capabilities to RADIUS (such as support for the=20 > Diameter data types). >=20 > In reviewing the potential solutions to the problem, the=20 > people present at the meeting appeared to strongly favor a=20 > RADIUS extension approach such as that outlined by Lior & Li=20 > (RADIUS attribute extension), over the current proposals for=20 > adding Diameter AVP support to RADIUS (Wolff & Weber and=20 > Mitton proposals). Some of the reasoning behind this was=20 > that adding support for Diameter AVP parsing and dictionary=20 > support would involve a substantial portion of the effort to=20 > develop a Diameter server, whereas simply adding support for=20 > an extended space vwould involve less effort, and would=20 > therefore be more likely to be deployed. >=20 > This consensus, if it is confirmed on the mailing list, has=20 > implications for the Design Guidelines document. If the=20 > RADIUS attribute space is extended without changing the=20 > RADIUS protocol in other ways, then Design Guidelines=20 > document needs only to focus on guidelines for the RADIUS=20 > protocol. Thus, the Design Guidelines effort is considerably=20 > simplified. >=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: Thu, 13 Jul 2006 15:18:46 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair , radext chair Subject: Protocol Action: 'RADIUS Attributes for Virtual LAN and Priority Support' to Proposed Standard Message-Id: Date: Thu, 13 Jul 2006 11:18:17 -0400 The IESG has approved the following document: - 'RADIUS Attributes for Virtual LAN and Priority Support ' as a Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-vlan-06.txt Technical Summary This document describes Virtual LAN (VLAN) and re-prioritization attributes that may prove useful for provisioning of access to IEEE 802 local area networks with the Remote Authentication Dialin User Service (RADIUS). The attributes defined in this document provide support within RADIUS analogous to the management variables supported in IEEE-802.1Q and MIB objects defined in RFC 4363. Working Group Summary There have been 3 WGLCs on the document, the initial one was part of the IEEE 802 attributes document, and the last two as a standalone document. Discussion on the document related to the use of the Tag Indication field, details of the User-Priority-Table attribute and per-user vs. per-port provisioning. Protocol Quality David Kessens has reviewed this document for the IESG. -- to unsubscribe send a message to radiusext-request@ops.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, 13 Jul 2006 12:51:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: paradox Date: Thu, 13 Jul 2006 05:51:02 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB2625024D9F86@xmb-sjc-215.amer.cisco.com> Thread-Topic: paradox Thread-Index: AcalHIvQAYVCoQKhTdueu0L+yBH7OgBXM8RQ From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=2715; t=1152795065; x=1153659065; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20paradox; X=v=3Dcisco.com=3B=20h=3Do5wsf6BR3aunX3djzC+R3qJ0ZBQ=3D; b=kFDKnS2Kc6cqLNCXowrlq883adAITod/+qyY3s6O8IsQPUHMcpIXvfjCzbuPBoB4VoIBv4EX Z7GsawV2Mr7tPAoL1GN5aHnmRN96it0Y62LSCUF243/objJVv08qdcso; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff <> supposedly scribbled: > On Tue, Jul 11, 2006 at 10:28:52AM -0700, Glen Zorn (gwz) wrote: >>=20 >>>> Just to be clear, I don't think I've claimed that there is a >>>> document, just that there are known methods that (slightly >>>> extended) to deal with the problem. Off the top of my head, RFC >>>> 2868 specifies an (admittedly unsophisticated) method to group >>>> related attributes together using "tags". Although that document >>>> only uses tags to group attributes of different types, I don't see >>>> why a similar technique would not work with attributes of the same >>>> type with the addition of the rule that all instances of the same >>>> attribute with the same tag be concatenated in order. A problem >>>> would arise if you wanted to group long attributes with others but >>>> I didn't think that we were talking about that... >>>=20 >>> Well yes, I suppose that would work, for long attributes restricted >>> to ASCII printable strings. >>=20 >> Actually, I'm not sure why that restriction is necessary? >=20 > You need to know whether the first byte is a tag or not. =20 I see. I was actually thinking that we might add an real tag field to = the attribute instead of stealing a byte from the payload. This = couldn't be done in RFC 2868 (on the grounds that it would be an = "extension" to RADIUS & extensions were prohibited. OTOH, this is the = RADIUS Extensions WG, so maybe it would be possible now. Perhaps we = could even put in _two_ 1 octet fields to eliminate the problem with XL = attributes not being allowed as members of other groups (though = splitting the single octet into a couple of bit-fields would probably = suffice). > I suppose > one could instead require that any attribute of length 253 always > have a tag. But in that case the actual tag is irrelevant. =20 ?? > So > here's an alternative proposal for overcoming the 253 byte limit: =20 >=20 > If value length <253, entire value in one AVP. > If value length >=3D253, first 252 bytes in first AVP, suffixed with > ignored byte. Repeat until the entire value has been consumed.=20 > In other words, a length field of 255 becomes special, indicating > both that the last byte of the value is to be ignored and that the > next instance of the same attribute type is a continuation. There is > a backwards compatibility risk, that an old sender will generate an > AVP with length field 255 for a 253-byte value. =20 >=20 > -- > Barney Wolff I never met a computer I didn't like. 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, 12 Jul 2006 19:50:44 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-delegated-prefix-02.txt Message-Id: Date: Wed, 12 Jul 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : RADIUS Delegated-IPv6-Prefix Attribute Author(s) : J. Salowey, R. Droms Filename : draft-ietf-radext-delegated-prefix-02.txt Pages : 7 Date : 2006-7-12 This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-delegated-prefix-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-delegated-prefix-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-delegated-prefix-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-12105653.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-delegated-prefix-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-delegated-prefix-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-12105653.I-D@ietf.org> --OtherAccess-- --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.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, 12 Jul 2006 18:36:28 +0000 From: "Alan DeKok" To: Emile van Bergen Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 cc: Bernard Aboba , radiusext@ops.ietf.org Date: Wed, 12 Jul 2006 14:26:21 -0400 Message-Id: <20060712182621.1569516CBC@mail.nitros9.org> Emile van Bergen wrote: > Agreed, however, the inner length field in the Lior proposal seems > redundant, and instead of using attribute 26, vendor 0, I think its > better to allocate a separate attribute I agree. After seeing this discussion go around in circles for a long time, I think enough is enough. Therefore, I'm happy to announce that FreeRADIUS now has an implementation of the Extended-Attribute from draft-wolff-radext-ext-attribute-00.txt. For code, see the CVS instructions on www.freeradius.org/development.html We'll reference the "Diameter-Encoded RADIUS Attributes" as DERA's, to distinguish them from RADIUS or proper Diameter AVP's. * Extended-Attribute is attribute 192, because it's in the "Experimental" space from RFC 2865. Changing this to an IANA allocated number will mean editing 2 lines of text. * The implementation can handle both the Extended-Attribute and Ascend's pseudo-VSA at attribute 192, simultaneously in one packet. * Data types supported include integer, date, IP address, IFID, IPv6 address, IPv6 prefix, text and string (limited to 240 bytes or so) * Diameter-style VSA's via the "V" bit are fully supported, and are in a separate attribute space from RADIUS VSA's * no tag, encryption, or grouping is currently supported * no Diameter AVP flags other than "V" are supported (i.e. they're forbidden) * Each DERA must be in it's own Extended-Attribute (i.e. no concatenation, as of yet) * DERA attributes of less than 256 are forbidden, as they should be encoded as RADIUS attributes * DERA attributes of 256..32767 are forbidden, as they have meaning within Diameter, and RADIUS servers cannot properly deal with them * DERA's are arbitrarily assigned the attribute space 32768..65535. * Outside of the RADIUS marshalling/unmarshalling code, nothing else in the server is aware that the attributes are encoded in any special way. * The new attributes are indistinguishable (other than by name) from existing RADIUS attributes to existing deployments * the RADIUS client included with FreeRADIUS has full support for DERA's in all RADIUS packets, with no code changes to the client. * less than 400 lines of code, limited to a packet handling library * can be easily extended to support multiple Diameter-style AVP's in one or more Extended-Attribute. * with a little more work, can be extended to support text/string DERA's with more than 240 bytes of data. The initial implementation exists. Let's see if we can have multiple inter-operable implementations. "Rough consensus and running code" has not been making progress. Let's try "running code and rough consensus". 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, 12 Jul 2006 13:01:14 +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: Is there interest in Radius MIB notifications? Date: Wed, 12 Jul 2006 07:54:57 -0500 Message-ID: <7221140AD3DA7C4DB2CD49771243D8DD013480B3@nrmail01.netrake.net> Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: AcalMdW+EibiU2/xRgqG6jr14oRcpQAfuYEg From: "Carl Kalbfleisch" To: Hi, Our customers desire SNMP Notifications when the "state" of the radius = server that the client is using changes. IE, when timeouts occur send a = notification and then when responses are received again send another = notification.=20 Is there general interest/demand for this? Essentially I am planning an enterprise extension to the Radius = Authentication and Accounting Client MIBs which are defined in = draft-ietf-radext-rfc2618bis-04.txt and = draft-ietf-radext-rfc2620bis-04.txt Carl -- to unsubscribe send a message to radiusext-request@ops.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, 11 Jul 2006 21:34:17 +0000 Date: Tue, 11 Jul 2006 23:34:06 +0200 From: Emile van Bergen To: Alan DeKok Cc: radiusext@ops.ietf.org Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Message-ID: <20060711213406.GB4990@note.evbergen.xs4all.nl> Mail-Followup-To: Alan DeKok , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Mon, Jul 10, 2006 at 06:10:12PM -0400, Alan DeKok wrote: > I support extending the RADIUS attribute space. > > I also think that the *format* (i.e. encoding) of the extended > attribute space is a separate issue to extending RADIUS with Diameter > features. i.e. TTLS uses the Diameter AVP format, but few to none of > the features. A few hundred lines of code are sufficient to implement > Diameter AVP encoding, which mitigates concerns over parsing & > dictionary support. > > To put it another way, we should standardize on the extended format > first, and explicitely reject any attempt to mingle the work on > extended attribute space with additional work like grouping and new > data types. Once we have a larger attribute space standardized, later > documents can add features for those applications that need them. Hear, hear. I very much like such a layered approach. Incidentally, my earlier suggestion for the extended header format [1] doesn't necessarily concern itself with data types or grouping; other than extending the 1 octet attribute type to a 32 bit space/vendor field and 32 bit type field, it just reserved two byte fields for a tag and child tag in its header. That's it, it doesn't care about the type or syntax of the value field at all. That's entirely attribute dependent. The tag field is there to create compatibility with RFC 2868 sensible way; the combination of tag and child tag also allows you to put grouping/nesting on top of any attribute, whenever desireable, by allowing any tagged or non-tagged attribute to refer to any tagged set as its children. So the nested tree structure containing A/V pairs is separate from the contents of the value fields. A nice effect of creating the grouping tree using two columns is that you can represent the tree using a flat table, which makes conversion from and to databases and log files both trivial and lossless. You don't have to think long and hard about the external representations of requests or replies containing physically grouped types as is the case with DIAMETER. At any rate, no proposed format contains an attribute header field referring to a data type ID (which is a very good thing, IMHO), so the data type remains wholly attribute dependent, thus that issue is also on a layer above the extended format itself. Cheers, Emile. [1] http://www.xs4all.nl/~evbergen/ietf/draft-evbergen-radext-extended-attribute-02.txt Note that it should be rewritten; it contains too many ideas and solutions in too few sections, but I didn't take the draft further so far due to lack of time and apparent lack of interest from the group. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Jul 2006 21:20:23 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: WGLC on Geopriv-Radius draft Date: Tue, 11 Jul 2006 14:20:01 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed The GEOPRIV WG is now about to start a WG last call on the GEOPRIV-RADIUS draft before sending it on to the IESG for consideration as a Proposed Standard: http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-07.txt In order to get all the WG last call comments together relating to all aspects (GEOPRIV + RADIUS) at the same time, we are requesting that the RADEXT WG review the document. Please send your comments to geopriv@ietf.org as well as radiusext@ops.ietf.org by July 28, 2006. >------- Forwarded Message > >Date: Tue, 11 Jul 2006 11:00:51 -0700 >From: Allison Mankin >To: geopriv@ietf.org >cc: geopriv-chairs@tools.ietf.org >Subject: WGLC for Geopriv-Radius draft > >Folks, > >draft-ietf-geopriv-radius-lo-07.txt completed its significant review >for RADIUS considerations in the 06->07 revisions. As we mentioned in >today's meeting, we will now begin WGLC. We'll extend it to three weeks >ending Tuesday, August 1. > >Allison for the Chairs > >------- End of Forwarded Message -- to unsubscribe send a message to radiusext-request@ops.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, 11 Jul 2006 19:02:22 +0000 Date: Tue, 11 Jul 2006 15:02:17 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: paradox Message-ID: <20060711190217.GA2162@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Tue, Jul 11, 2006 at 10:28:52AM -0700, Glen Zorn (gwz) wrote: > > >> Just to be clear, I don't think I've claimed that there is a > >> document, just that there are known methods that (slightly extended) > >> to deal with the problem. Off the top of my head, RFC 2868 > >> specifies an (admittedly unsophisticated) method to group related > >> attributes together using "tags". Although that document only uses > >> tags to group attributes of different types, I don't see why a > >> similar technique would not work with attributes of the same type > >> with the addition of the rule that all instances of the same > >> attribute with the same tag be concatenated in order. A problem > >> would arise if you wanted to group long attributes with others but I > >> didn't think that we were talking about that... > > > > Well yes, I suppose that would work, for long attributes restricted > > to ASCII printable strings. > > Actually, I'm not sure why that restriction is necessary? You need to know whether the first byte is a tag or not. I suppose one could instead require that any attribute of length 253 always have a tag. But in that case the actual tag is irrelevant. So here's an alternative proposal for overcoming the 253 byte limit: If value length <253, entire value in one AVP. If value length >=253, first 252 bytes in first AVP, suffixed with ignored byte. Repeat until the entire value has been consumed. In other words, a length field of 255 becomes special, indicating both that the last byte of the value is to be ignored and that the next instance of the same attribute type is a continuation. There is a backwards compatibility risk, that an old sender will generate an AVP with length field 255 for a 253-byte value. -- Barney Wolff 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, 11 Jul 2006 18:59:35 +0000 Date: Tue, 11 Jul 2006 20:59:25 +0200 From: Emile van Bergen To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Message-ID: <20060711185924.GC3687@note.evbergen.xs4all.nl> Mail-Followup-To: Bernard Aboba , radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Mon, Jul 10, 2006 at 02:45:06PM -0700, Bernard Aboba wrote: > In your reply to this message, please state whether you support the > consensus described below, or whether you disagree with it (and if so, how). > > The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: > > * Exhaustion of the RADIUS standard attribute space is a problem that > should be solved. Agreed. > * RADEXT WG is the place to solve the problem. Agreed. > * The attribute exhaustion problem should be the focus -- not adding other > capabilities to RADIUS (such as support for the Diameter data types). Agreed, though my position is that the issue of data types exists on a layer above the issue of separating and structuring A/V pairs. Further, I think that we should include RFC2868-style tags in the "existing capabilities of RADIUS". > In reviewing the potential solutions to the problem, the people present at > the meeting appeared to strongly favor a RADIUS extension approach such as > that outlined by Lior & Li (RADIUS attribute extension), over the current > proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and > Mitton proposals). Agreed, however, the inner length field in the Lior proposal seems redundant, and instead of using attribute 26, vendor 0, I think its better to allocate a separate attribute, because I don't think the IETF should create VSAs that don't follow the inner VSA format strongly suggested in RFC 2865. Otherwise it's OK, but see also my previous mail to this list (in the 'paradox' thread). Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Jul 2006 18:42:24 +0000 Date: Tue, 11 Jul 2006 20:41:55 +0200 From: Emile van Bergen To: radiusext@ops.ietf.org Cc: "Glen Zorn (gwz)" , Barney Wolff Subject: Re: paradox Message-ID: <20060711184154.GA3687@note.evbergen.xs4all.nl> Mail-Followup-To: radiusext@ops.ietf.org, "Glen Zorn (gwz)" , Barney Wolff Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Hi, On Mon, Jul 10, 2006 at 06:56:37PM -0400, Barney Wolff wrote: > On Mon, Jul 10, 2006 at 01:31:11PM -0700, Glen Zorn (gwz) wrote: > > Barney Wolff <> supposedly scribbled: > > > > > I find it mildly astonishing, listening to today's radext session, > > > that the group seemed to feel that the only problem worth fixing is > > > the 255 limit on AVP type, when just a few minutes before the debate > > > was over what to do with filter/traffic rules that go over the > > > 253-byte limit. > > > > > > Apperently people feel that it's preferable to debate this issue > > > every time it comes up, rather than solve it once. > > > > If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)? > > I'm always willing to be educated - please point me to a document that > solves the attribute length problem when there can be more than one > of the attribute in the message. Ok, ok, kids. It's not /that/ hard to come up with something proper, or is it? Is bickering all we can do nowadays? The issues can really be fixed in a simple and elegant way. We don't need to make it seem any harder than it is. I'll do it powerpoint-style: 1. the only sensible way of overcoming the 253-byte limit is concatenating all instances into one string. Of course, that means only one instance. Let's call this basic facility CONCAT. 2. for some attributes (all the ones allowing just one instance anyway), the CONCAT layer above RADIUS is enough. Let's call that class of attributes SINGLE LONG. 3. in other cases though, you want multiple instances, because a list of values has a meaning different from one single value. So it's desireable for the long attribute to be split in parts. How to split a string? You have a number of options, as we all know. You either need: - fixed length subparts, or - a delimiter that may not occur (unescaped) in the string, or - a length, value structure (see eg. DNS), using a sufficently wide length field. Depending on the case, any of these mechanisms may be used. They all work above CONCAT, which works above RADIUS. No layering violations, standard mechanisms, all proven in RADIUS. Let's call this DELIMITED LIST. There's the 'document'. That didn't hurt, did it? Let's go on a bit: 4. in yet other cases though, you may want to have multiple individually identifyable elements in that delimited string, so that you don't have to rely on a fixed order, and can leave elements out. And how to do that? Well, you simply add a type (AVP code) field to the length, value structure given under 3. above. If you make that field sufficiently wide, you also solve the attribute number space crunch, and can delegate parts of it using smart prefixing (we all know about IPv4 classes, don't we?). Of course, that the only thing the extended attribute header format is: a TLV structure for use inside the single long string attribute. There are two contenters for this header format: the DIAMETER format, and a RADIUS-like format suggested earlier by yours truly that is fully backwards compatible with existing RADIUS features, including tags, and allows parts of the space to be delegated, and which, just like Barney's proposal incidentally, hardly got any comment about its technical merit or substance, as opposed to the amount of abstract philosophy, politics and instinctive feelings voiced around IETF-65. Anyway, let's call this layer, whichever way it's done, EXTATTR. 5. depending on the type of EXTATTR TLV structure chosen, EXTATTR. supports nested trees of attributes using physical parser level nesting or an inode-like structure using tags, which also provides the functionality of the current DIRTYTAGS we have in RFC 2868 et al. (Dirty only because of the the way the first octet of these attributes is both a flag, tag and a value in RFC2868). So, above EXTRAD you either directly have TREE, or you have TAGSET in between. It can be summarised in a simple picture: +-------+ | ... | +-------+ +-------+----+ | ... | | TREE | .. | +-------+-------+------------------+-------+----+----+ | EAP | ... | ... *) | [TAGSET] | .. | +-------+-------+------------------+------------+----+------+-----+ | SINGLE LONG | DELIMITED LIST | EXTATTR | 2868 | ... | +---------------+------------------+-----------------+------+-----+-----+ | CONCAT | DIRTYTAGS | ... | +----------------------------------------------------+------------+-----+ | Standard RADIUS attribute encoding | +-----------------------------------------------------------------------+ *) Eg. NAS-Filter There are no dirty layering violations, implementations can pick and choose how far they want to go with the newfangled bits, and you don't have to rewrite any of your lower layers if you later decide you want to add some or more of the new stuff. It took me 15 minutes to come up with the above, and another 45 to put it down. It should not take any more time from any of you. So, what about it. Can we still /solve/ anything technical here, or has this just become another slashdot? Cheers, Emile. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)78 6136282 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 11 Jul 2006 18:12:05 +0000 To: radiusext@ops.ietf.org Subject: FW: WGLC for Geopriv-Radius draft Cc: geopriv-chairs@tools.ietf.org, fluffy@cisco.com Reply-To: mankin@psg.com Date: Tue, 11 Jul 2006 11:11:49 -0700 From: Allison Mankin Message-Id: Hi, I think Bernard has left us with a few revs for the final final draft, but we've asked GEOPRIV to do its WGLC now. Thanks very much to radiusext for the many reviews and improvements. Please post reviews to GEOPRIV for the WGLC if you do have more!? geopriv@ietf.org Allison ------- Forwarded Message Date: Tue, 11 Jul 2006 11:00:51 -0700 From: Allison Mankin To: geopriv@ietf.org cc: geopriv-chairs@tools.ietf.org Subject: WGLC for Geopriv-Radius draft Folks, draft-ietf-geopriv-radius-lo-07.txt completed its significant review for RADIUS considerations in the 06->07 revisions. As we mentioned in today's meeting, we will now begin WGLC. We'll extend it to three weeks ending Tuesday, August 1. Allison for the Chairs ------- End of Forwarded Message -- to unsubscribe send a message to radiusext-request@ops.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, 11 Jul 2006 17:29:01 +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: paradox Date: Tue, 11 Jul 2006 10:28:52 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250246C03B@xmb-sjc-215.amer.cisco.com> Thread-Topic: paradox Thread-Index: AcalDIbbs7IedH2tQkqNkmnWw710aAAArfxA From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1220; t=1152638933; x=1153502933; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20paradox; X=v=3Dcisco.com=3B=20h=3Do5wsf6BR3aunX3djzC+R3qJ0ZBQ=3D; b=f7Zmp8QyoNNv3GHz4QWFOq9vDAz79zJD0LwCeyzX5iJ1FCocZt2AzvYAQfblytzFdY1zOm5i qDJx3e1IukQPJhGa0f/Bi826AW1xleOKWwLfUb/y2FIc81dCnNErMQbA; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff supposedly scribbled: ... >> Just to be clear, I don't think I've claimed that there is a >> document, just that there are known methods that (slightly extended) >> to deal with the problem. Off the top of my head, RFC 2868 >> specifies an (admittedly unsophisticated) method to group related >> attributes together using "tags". Although that document only uses >> tags to group attributes of different types, I don't see why a >> similar technique would not work with attributes of the same type >> with the addition of the rule that all instances of the same >> attribute with the same tag be concatenated in order. A problem >> would arise if you wanted to group long attributes with others but I >> didn't think that we were talking about that... =20 >=20 > Well yes, I suppose that would work, for long attributes restricted > to ASCII printable strings. =20 Actually, I'm not sure why that restriction is necessary? > Anybody favor using this technique for > filter/traffic rules? =20 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, 11 Jul 2006 17:21:58 +0000 Date: Tue, 11 Jul 2006 13:20:25 -0400 To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Message-ID: <20060711172025.GA14707@steelhead> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline User-Agent: Mutt/1.5.11+cvs20060403 From: Yoshihiro Ohba I support the emerging consensus on the all three items below. I also support Avi's expired draft to address the last issue. In addition, if adding other capability is needed, I'd suggest adding such capabilities inside RADIUS attributes, not RADIUS protocol itself. If such "attribute-level remedy" is considered to be impossible or unreasonably difficult to add some capability, it is really time to think about using Diameter for that capability, instead of trying to do cosmetic or whatever surgery to the RADIUS protocol itself. Best regards, Yoshihiro Ohba On Mon, Jul 10, 2006 at 02:45:06PM -0700, Bernard Aboba wrote: > At the RADEXT WG meeting at IETF 66, we took a "sense of the room" with > respect to what the WG should do with respect to the exhaustion of the > RADIUS standard attribute space. A consensus appeared to emerge. We > would now like to confirm that consensus on the RADEXT WG mailing list. > > In your reply to this message, please state whether you support the > consensus described below, or whether you disagree with it (and if so, how). > > The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: > > * Exhaustion of the RADIUS standard attribute space is a problem that > should be solved. > * RADEXT WG is the place to solve the problem. > * The attribute exhaustion problem should be the focus -- not adding other > capabilities to RADIUS (such as support for the Diameter data types). > > In reviewing the potential solutions to the problem, the people present at > the meeting appeared to strongly favor a RADIUS extension approach such as > that outlined by Lior & Li (RADIUS attribute extension), over the current > proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and > Mitton proposals). Some of the reasoning behind this was that adding > support for Diameter AVP parsing and dictionary support would involve a > substantial portion of the effort to develop a Diameter server, whereas > simply adding support for an extended space vwould involve less effort, and > would therefore be more likely to be deployed. > > This consensus, if it is confirmed on the mailing list, has implications > for the Design Guidelines document. If the RADIUS attribute space is > extended without changing the RADIUS protocol in other ways, then Design > Guidelines document needs only to focus on guidelines for the RADIUS > protocol. Thus, the Design Guidelines effort is considerably simplified. > > > > -- > to 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, 11 Jul 2006 17:07:54 +0000 Date: Tue, 11 Jul 2006 13:07:41 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: paradox Message-ID: <20060711170741.GA7627@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Tue, Jul 11, 2006 at 09:38:17AM -0700, Glen Zorn (gwz) wrote: > > > > I'm always willing to be educated - please point me to a document > > that solves the attribute length problem when there can be more than > > one of the attribute in the message. > > Just to be clear, I don't think I've claimed that there is a document, just that there are known methods that (slightly extended) to deal with the problem. Off the top of my head, RFC 2868 specifies an (admittedly unsophisticated) method to group related attributes together using "tags". Although that document only uses tags to group attributes of different types, I don't see why a similar technique would not work with attributes of the same type with the addition of the rule that all instances of the same attribute with the same tag be concatenated in order. A problem would arise if you wanted to group long attributes with others but I didn't think that we were talking about that... Well yes, I suppose that would work, for long attributes restricted to ASCII printable strings. Anybody favor using this technique for filter/traffic rules? -- Barney Wolff 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, 11 Jul 2006 16:38:49 +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: paradox Date: Tue, 11 Jul 2006 09:38:17 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250246BFC6@xmb-sjc-215.amer.cisco.com> Thread-Topic: paradox Thread-Index: AcakdBqBp7rDIPMkTQ6izZZAvk5nswAknGsw From: "Glen Zorn \(gwz\)" To: "Barney Wolff" Cc: DKIM-Signature: a=rsa-sha1; q=dns; l=1310; t=1152635900; x=1153499900; c=relaxed/simple; s=sjdkim7001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20paradox; X=v=3Dcisco.com=3B=20h=3Do5wsf6BR3aunX3djzC+R3qJ0ZBQ=3D; b=e11zNCHxz0IKmQ2vXHyP4tOTQlPpusGuMepnBMXeNjOrn1BLP0SNgHJGtaDvY/PGPxBYsmBA B6EwgVlgv4PsbqEYn64VZYYZIKkrfPKsRoNGWGsAWvZHjUJEyhaQ1tmC; Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff supposedly scribbled: ... >> If you alleviate the attribute namespace shortage, aren't there >> established ways of dealing w/overly long values (up to the message >> size limit anyway)? =20 >=20 > I'm always willing to be educated - please point me to a document > that solves the attribute length problem when there can be more than > one of the attribute in the message.=20 Just to be clear, I don't think I've claimed that there is a document, = just that there are known methods that (slightly extended) to deal with = the problem. Off the top of my head, RFC 2868 specifies an (admittedly = unsophisticated) method to group related attributes together using = "tags". Although that document only uses tags to group attributes of = different types, I don't see why a similar technique would not work with = attributes of the same type with the addition of the rule that all = instances of the same attribute with the same tag be concatenated in = order. A problem would arise if you wanted to group long attributes = with others but I didn't think that we were talking about that... =20 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: Mon, 10 Jul 2006 23:19: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: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Mon, 10 Jul 2006 16:18:58 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482405222B3A@cacexc07.americas.cpqcorp.net> Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: Acakda2nzQ3zbncCSYOhHbSEd4/ddgAAVDRw From: "Congdon, Paul T (ProCurve)" To: Cc: > "Congdon, Paul T (ProCurve)" wrote: > > I support this consensus position. In particular I support the=20 > > simplified approach proposed by Lior. >=20 > For those of us not in the room, what was that? >=20 The approached referenced in Bernard's email. I assume this is the expired draft: draft-lior-radius-attribute-type-extension-00 View Related Documents (e.g., documents that replaced or were replaced by the subject I-D, and their derivatives and precursors.)=20 I-D Title: Remote Authentication Dial In User Service (RADIUS) Attribute Type Extension=20 I-D Status: Expired=20 I-D Intended Status at Publication: None=20 RFC Number:=20 I-D Tracker State: ID Exists=20 Abstract:=20 In order for Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications it is required that the RADIUS attribute space be extended beyond the current limit of 255 possible attribute types. This document defines a mechanism to extend the base RADIUS attribute types while maintaining backwards compatibility as well as compatibility with Diameter. =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, 10 Jul 2006 23:17:18 +0000 Message-Id: <75404C7727619C4E81A6DABE442E42DD0CC2FA@S4DE9JSAANL.ost.t-com.de> From: Steigerwaldw To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org Subject: AW: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Tue, 11 Jul 2006 01:17:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > * Exhaustion of the RADIUS standard attribute space is a=20 > problem that should be solved. I think we should NOT spend so much effort on radius and should spent = it to diameter (dime) > * RADEXT WG is the place to solve the problem. If consensus for the previous question is yes, radext is the right = place. > * The attribute exhaustion problem should be the focus -- not=20 > adding other capabilities to RADIUS (such as support for the=20 > Diameter data types). If consensus can be found for the work, I support Lior's proposal. Regards Wolfgang > -----Urspr=FCngliche Nachricht----- > Von: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Gesendet: Montag, 10. Juli 2006 23:45 > An: radiusext@ops.ietf.org > Betreff: Consensus Call: "Sense of the Room" at RADEXT WG=20 > meeting at IETF 66 >=20 > At the RADEXT WG meeting at IETF 66, we took a "sense of the=20 > room" with respect to what the WG should do with respect to=20 > the exhaustion of the=20 > RADIUS standard attribute space. A consensus appeared to=20 > emerge. We=20 > would now like to confirm that consensus on the RADEXT WG=20 > mailing list. >=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, 10 Jul 2006 23:07:53 +0000 From: "Alan DeKok" To: "Congdon, Paul T (ProCurve)" Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 cc: radiusext@ops.ietf.org Date: Mon, 10 Jul 2006 18:58:31 -0400 Message-Id: <20060710225831.5EDE316E0B@mail.nitros9.org> "Congdon, Paul T (ProCurve)" wrote: > I support this consensus position. In particular I support the > simplified approach proposed by Lior. For those of us not in the room, what was that? 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, 10 Jul 2006 22:57:50 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Mon, 10 Jul 2006 15:57:42 -0700 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482405222AF7@cacexc07.americas.cpqcorp.net> Thread-Topic: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Thread-Index: AcakalqnyJ6tjLyrQr6P+O78gdYZjwACV+pg From: "Congdon, Paul T (ProCurve)" To: "Bernard Aboba" , =20 >=20 > In your reply to this message, please state whether you=20 > support the consensus described below, or whether you=20 > disagree with it (and if so, how). > I support this consensus position. In particular I support the simplified approach proposed by Lior. =20 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: Mon, 10 Jul 2006 22:57:02 +0000 Date: Mon, 10 Jul 2006 18:56:37 -0400 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: Re: paradox Message-ID: <20060710225637.GA21446@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Mon, Jul 10, 2006 at 01:31:11PM -0700, Glen Zorn (gwz) wrote: > Barney Wolff <> supposedly scribbled: > > > I find it mildly astonishing, listening to today's radext session, > > that the group seemed to feel that the only problem worth fixing is > > the 255 limit on AVP type, when just a few minutes before the debate > > was over what to do with filter/traffic rules that go over the > > 253-byte limit. > > > > Apperently people feel that it's preferable to debate this issue > > every time it comes up, rather than solve it once. > > If you alleviate the attribute namespace shortage, aren't there established ways of dealing w/overly long values (up to the message size limit anyway)? I'm always willing to be educated - please point me to a document that solves the attribute length problem when there can be more than one of the attribute in the message. -- Barney Wolff 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: Mon, 10 Jul 2006 22:19:40 +0000 From: "Alan DeKok" To: radiusext@ops.ietf.org Subject: Re: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Mon, 10 Jul 2006 18:10:12 -0400 Message-Id: <20060710221012.7305E16E0B@mail.nitros9.org> "Bernard Aboba" wrote: > The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: > > * Exhaustion of the RADIUS standard attribute space is a problem that should > be solved. > * RADEXT WG is the place to solve the problem. > * The attribute exhaustion problem should be the focus -- not adding other > capabilities to RADIUS (such as support for the Diameter data types). I agree to all three points. > In reviewing the potential solutions to the problem, the people present at > the meeting appeared to strongly favor a RADIUS extension approach such as > that outlined by Lior & Li (RADIUS attribute extension), over the current > proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and > Mitton proposals). Some of the reasoning behind this was that adding > support for Diameter AVP parsing and dictionary support would involve a > substantial portion of the effort to develop a Diameter server, whereas > simply adding support for an extended space vwould involve less effort, and > would therefore be more likely to be deployed. I support extending the RADIUS attribute space. I also think that the *format* (i.e. encoding) of the extended attribute space is a separate issue to extending RADIUS with Diameter features. i.e. TTLS uses the Diameter AVP format, but few to none of the features. A few hundred lines of code are sufficient to implement Diameter AVP encoding, which mitigates concerns over parsing & dictionary support. To put it another way, we should standardize on the extended format first, and explicitely reject any attempt to mingle the work on extended attribute space with additional work like grouping and new data types. Once we have a larger attribute space standardized, later documents can add features for those applications that need them. 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, 10 Jul 2006 21:46:36 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Consensus Call: "Sense of the Room" at RADEXT WG meeting at IETF 66 Date: Mon, 10 Jul 2006 14:45:06 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed At the RADEXT WG meeting at IETF 66, we took a "sense of the room" with respect to what the WG should do with respect to the exhaustion of the RADIUS standard attribute space. A consensus appeared to emerge. We would now like to confirm that consensus on the RADEXT WG mailing list. In your reply to this message, please state whether you support the consensus described below, or whether you disagree with it (and if so, how). The "sense of the room" in the RADEXT WG meeting at IETF 66 was that: * Exhaustion of the RADIUS standard attribute space is a problem that should be solved. * RADEXT WG is the place to solve the problem. * The attribute exhaustion problem should be the focus -- not adding other capabilities to RADIUS (such as support for the Diameter data types). In reviewing the potential solutions to the problem, the people present at the meeting appeared to strongly favor a RADIUS extension approach such as that outlined by Lior & Li (RADIUS attribute extension), over the current proposals for adding Diameter AVP support to RADIUS (Wolff & Weber and Mitton proposals). Some of the reasoning behind this was that adding support for Diameter AVP parsing and dictionary support would involve a substantial portion of the effort to develop a Diameter server, whereas simply adding support for an extended space vwould involve less effort, and would therefore be more likely to be deployed. This consensus, if it is confirmed on the mailing list, has implications for the Design Guidelines document. If the RADIUS attribute space is extended without changing the RADIUS protocol in other ways, then Design Guidelines document needs only to focus on guidelines for the RADIUS protocol. Thus, the Design Guidelines effort is considerably simplified. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Jul 2006 20:31:34 +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: paradox Date: Mon, 10 Jul 2006 13:31:11 -0700 Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250246BCD5@xmb-sjc-215.amer.cisco.com> Thread-Topic: paradox Thread-Index: AcakSDYxyc5sywOLQMCbBY0QSyYBEAAF1A6Q From: "Glen Zorn \(gwz\)" To: "Barney Wolff" , DKIM-Signature: a=rsa-sha1; q=dns; l=862; t=1152563487; x=1153427487; c=relaxed/simple; s=sjdkim5001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gwz@cisco.com; z=From:=22Glen=20Zorn=20\(gwz\)=22=20 |Subject:RE=3A=20paradox; X=v=3Dcisco.com=3B=20h=3Do5wsf6BR3aunX3djzC+R3qJ0ZBQ=3D; b=Z6sIY+kN304BHa+p1v3mByogkFyOuqllXJfQrB4jOngumlndHjXgZIIFv2zor0+3t4ZiFc4n uWxCBTMu0D43oOMeh+kshRRY+80mGHlT01M8+CWAvAX603hEN5/PB3oI; Authentication-Results: sj-dkim-5.cisco.com; header.From=gwz@cisco.com; dkim=pass ( sig from cisco.com verified; ); Barney Wolff <> supposedly scribbled: > I find it mildly astonishing, listening to today's radext session, > that the group seemed to feel that the only problem worth fixing is > the 255 limit on AVP type, when just a few minutes before the debate > was over what to do with filter/traffic rules that go over the > 253-byte limit. =20 >=20 > Apperently people feel that it's preferable to debate this issue > every time it comes up, rather than solve it once.=20 If you alleviate the attribute namespace shortage, aren't there = established ways of dealing w/overly long values (up to the message size = limit anyway)? >=20 > -- > Barney Wolff I never met a computer I didn't like. 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: Mon, 10 Jul 2006 20:14:42 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair , radext chair Subject: Document Action: 'RADIUS Accounting Client MIB for IPv6' to Informational RFC Message-Id: Date: Mon, 10 Jul 2006 16:14:08 -0400 The IESG has approved the following documents: - 'RADIUS Accounting Server MIB for IPv6 ' as an Informational RFC - 'RADIUS Accounting Client MIB for IPv6 ' as an Informational RFC These documents are products of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-04.txt Technical Summary The two documents in this set represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The documents cover the RADIUS Accounting protocol [RFC2866] client and server functions. The RADIUS Accounting MIB documents are Informational. The scope ofthe revisions in the current set of Internet Drafts includes adding capabilitiesto handle IPv6 address formats, adding UNITS and REFERENCE clauses to selected objects, and generally updating the MIB and Internet Draft boilerplate, and the Security Considerations. Certain objects have been deprecated and backwards compatibility with the existing RFCs and MIBs has been maintained, as these MIBsare widely deployed. The four Internet Drafts in this set will obsolete their respective RFCs when approved. Working Group Summary The Working Group initially took the approach of augmenting the existing MIBs and updating the existing RFCs. Early MIB Doctor review indicated that the MIBsshould be revised and the existing RFCs obsoleted. There is no significant technical content in these documents, but rather a straightforward revision to support IP version neutral address formats. Most of the discussion on these drafts was related to MIB design guidelines and "nits". The only MIB Doctor comment that was not resolved was a recommendation to root the MODULE-IDENTITY objects in these four drafts directly under mib-2 OID, but that would break backwards compatibility with existing OID trees in widely deployed MIBs. This solution was agreed by the MIB Doctor. Protocol Quality The existing two MIB modules are widely deployed. It is expected that many vendors will implement the revised MIBs as the systems which contain RADIUS accounting clients and servers are enhanced to support IPv6. Several WG membersresponded to informal polls at IETF meetings indicating their interest inimplementing these MIBs. The overall protocol quality of these MIBs has been enhanced by detailed review by MIB Doctors: Dave Harrington, C.M. Heard and Dan Romascanu. Note to RFC Editor Please make the following change Section 4 of draft-ietf-radext-rfc2620bis-04.txt OLD: This document obsoletes RFC 2620 [RFC2620], RADIUS Authentication Client MIB, by deprecating the radiusAuthServerTable table and adding a new table, radiusAuthServerExtTable, containing radiusAuthServerInetAddressType, radiusAuthServerInetAddress, and radiusAuthClientServerInetPortNumber. NEW: This document obsoletes RFC 2620 [RFC2620], RADIUS Accounting Client MIB, by deprecating the radiusAccServerTable table and adding a new table, radiusAccServerExtTable, containing radiusAccServerInetAddressType, radiusAccServerInetAddress, and radiusAccClientServerInetPortNumber. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Jul 2006 19:58:22 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair , radext chair Subject: Document Action: 'Dynamic Authorization Client MIB' to Informational RFC Message-Id: Date: Mon, 10 Jul 2006 15:57:39 -0400 The IESG has approved the following documents: - 'Dynamic Authorization Client MIB ' as an Informational RFC - 'Dynamic Authorization Server MIB ' as an Informational RFC These documents are products of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-06.txt Technical Summary Dynamic Authorization Client MIB This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Client (DAC) functions that support the dynamic authorization extensions as defined in RFC 3576. Dynamic Authorization Server MIB This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes the Remote Authentication Dial In User Service (RADIUS) [RFC2865] Dynamic Authorization Server (DAS) functions that support the dynamic authorization extensions as defined in RFC 3576. Working Group Summary The WG has consensus on these documents. Protocol Quality MIB Doctor review was done by Dan Romascanu. The documents are Informational, so no IETF Last Call was issued. However, there was call for comment to MIB doctors list. Bert Wijnen did review these documents for the IESG. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Jul 2006 19:41:12 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair , radext chair Subject: Protocol Action: 'RADIUS Authentication Client MIB for IPV6' to Proposed Standard Message-Id: Date: Mon, 10 Jul 2006 15:40:48 -0400 The IESG has approved the following documents: - 'RADIUS Authentication Server MIB for IPv6 ' as a Proposed Standard - 'RADIUS Authentication Client MIB for IPV6 ' as a Proposed Standard These documents are products of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-04.txt Technical Summary The two documents in this set represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. The documents cover the RADIUS protocol [RFC2865] client and server functions. The RADIUS MIB documents are Standards Track. The scope of the revisions in thecurrent set of Internet Drafts includes adding capabilities to handle IPv6 address formats, adding UNITS and REFERENCE clauses to selected objects, and generally updating the MIB and Internet Draft boilerplate, and the Security Considerations. Certain objects have been deprecated and backwards compatibility with the existing RFCs and MIBs has been maintained, as these MIBsare widely deployed. The two Internet Drafts in this set will obsolete their respective RFCs when approved. Working Group Summary The Working Group initially took the approach of augmenting the existing MIBs and updating the existing RFCs. Early MIB Doctor review indicated that the MIBsshould be revised and the existing RFCs obsoleted. There is no significant technical content in these documents, but rather a straightforward revision to support IP version neutral address formats. Most of the discussion on these drafts was related to MIB design guidelines and "nits". The only MIB Doctor comment that was not resolved was a recommendation to root the MODULE-IDENTITY objects in these four drafts directly under mib-2 OID, but that would break backwards compatibility with existing OID trees in widely deployed MIBs. This resolution was accepted by the MIB Doctor. Protocol Quality The existing two MIB modules are widely deployed. It is expected that many vendors will implement the revised MIBs as the systems which contain RADIUS [accounting] clients and servers are enhanced to support IPv6. Several WG members responded to informal polls at IETF meetings indicating their interest in implementing these MIBs. The overall protocol quality of these MIBs has beenenhanced by detailed review by MIB Doctors: Dave Harrington, C.M. Heard and Dan Romascanu. Note to RFC Editor Please make the following change in the Abstract: OLD: This memo defines a set of extensions, which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. NEW: This memo defines a set of extensions, which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. -- to unsubscribe send a message to radiusext-request@ops.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, 10 Jul 2006 19:08:24 +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: Attribute concatenation/splitting Date: Mon, 10 Jul 2006 15:04:45 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAN0dwAAA1zIig From: "Avi Lior" To: "Sanchez, Mauricio \(ProCurve\)" , , I agree with that. Make them the same.=20 > -----Original Message----- > From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 > Sent: Sunday, July 09, 2006 8:48 PM > To: Pasi.Eronen@nokia.com; Avi Lior; radiusext@ops.ietf.org > Subject: RE: Issue: Attribute concatenation/splitting >=20 >=20 > Pasi wrote...=20 >=20 > > Yes, this would work for NAS-Filter-Rule -- but so would any of the=20 > > other proposals so far (e.g. rules end with LF; rule ends=20 > if attribute=20 > > length <253; attributes begin with a tag octet; etc.) I don't think=20 > > any of these proposals is a really good one, but at least the same=20 > > approach could be reused for NAS-Traffic-Rule (and maybe other=20 > > attributes in the future as well). >=20 > The consensus reached for NAS-Traffic-Rule, when this exact=20 > issue arose, was to use a LF as a rule delimiter. As you=20 > point out it's not ideal, but is probably the most=20 > straightforward option. >=20 > Why not just bite the bullet and add the same LF delimiter to=20 > NAS-Filter-Rule? At least we'd be able to claim then that=20 > NAS-Traffic-Rule and NAS-Filter-Rule use common rule=20 > delimiters, thereby easing a RADIUS implementers effort to=20 > support both attributes. >=20 > MS >=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, 10 Jul 2006 17:42:25 +0000 Date: Mon, 10 Jul 2006 13:42:02 -0400 From: Barney Wolff To: radiusext@ops.ietf.org Subject: paradox Message-ID: <20060710174201.GA72179@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 I find it mildly astonishing, listening to today's radext session, that the group seemed to feel that the only problem worth fixing is the 255 limit on AVP type, when just a few minutes before the debate was over what to do with filter/traffic rules that go over the 253-byte limit. Apperently people feel that it's preferable to debate this issue every time it comes up, rather than solve it once. -- Barney Wolff 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: Mon, 10 Jul 2006 00:47:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Issue: Attribute concatenation/splitting Date: Sun, 9 Jul 2006 17:47:48 -0700 Content-Type: multipart/signed; boundary="----=_NextPart_000_0013_01C6A344.16AFEE50"; protocol="application/x-pkcs7-signature"; micalg=SHA1 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAN0dwAA== From: "Sanchez, Mauricio (ProCurve)" To: , , This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C6A344.16AFEE50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Pasi wrote... > Yes, this would work for NAS-Filter-Rule -- but so would any > of the other proposals so far (e.g. rules end with LF; rule > ends if attribute length <253; attributes begin with a tag > octet; etc.) I don't think any of these proposals is a really > good one, but at least the same approach could be reused for > NAS-Traffic-Rule (and maybe other attributes in the future as well). The consensus reached for NAS-Traffic-Rule, when this exact issue arose, was to use a LF as a rule delimiter. As you point out it's not ideal, but is probably the most straightforward option. Why not just bite the bullet and add the same LF delimiter to NAS-Filter-Rule? At least we'd be able to claim then that NAS-Traffic-Rule and NAS-Filter-Rule use common rule delimiters, thereby easing a RADIUS implementers effort to support both attributes. MS ------=_NextPart_000_0013_01C6A344.16AFEE50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOEjCCAwMw ggJsAhEAuS9gzIifoXpGCbhbcGyKrzANBgkqhkiG9w0BAQUFADCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswHhcNOTgwNTE4MDAwMDAwWhcNMjgwODAxMjM1OTU5WjCBwTELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTwwOgYDVQQLEzNDbGFzcyAyIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzIxOjA4BgNVBAsTMShjKSAxOTk4IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmswgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKeIASF0LOcaA/CY4Zc8DyEI8Zzbl+ma /MIEBhO+X1LIzB4sElYsuAFpLMyZH62wlq55BPITOcF7mLoILOjChBMsqmnpCfTHqQKkQsIjT0rY 8A6i+zFsyeZvmScH9eb0THiebetGhvq5hslU8rLEr9RGHFrJFTD/DWz1LQ5tzn93AgMBAAEwDQYJ KoZIhvcNAQEFBQADgYEAci75f9HxcfvEnvbFXlGKQJi4aPibHIPY4p29/+2h5mbqLwn0ytfqpSuV 9iRghk1ELoOlxC2g0654aW9y2myuCPBjkjfmu8QwF613zEk1qs/Yj9G+txiWR3NqVCI0ZC22FptZ W7RRWTqzCxT0Et9noPStMmResUZyJ4wSe8VEtK4wggQlMIIDjqADAgECAhBWO27ntnEulADNe55i te6UMA0GCSqGSIb3DQEBBQUAMIHBMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xPDA6BgNVBAsTM0NsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3Jp dHkgLSBHMjE6MDgGA1UECxMxKGMpIDE5OTggVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXpl ZCB1c2Ugb25seTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazAeFw0wMTA0MjQwMDAw MDBaFw0wOTA0MjMyMzU5NTlaMIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEf MB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0 IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25T aXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwHBTCwUTa0hb aHog6TMn4eE7398EjzwgM69HP+K7kNyVfFWph26qBIDYAZLebCYtGIb7k9yTmPRVIWAdYDgw28tQ +Q8belgqEWmwzmv9ISTlEgFvOFLKc+cgI9/FKCiRN2QW12uHsugJhKBwNJ21zB7MDoEdBjGY1MyY 5T1+5TsCAwEAAaOB+jCB9zAPBgNVHRMECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4RQEH AQEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8EBAMC AQYwEQYJYIZIAYb4QgEBBAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFi ZWwxLTM4MjA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWcy LmNybDAdBgNVHQ4EFgQU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wDQYJKoZIhvcNAQEFBQADgYEAQZJR XIBAaNmQVGuF68nKEMhda/Wl56rvk9AuHYkKV0sP/9ktuyn7KMuHKiFj4uAKwCZLiq36wjYqiK3j gk9MZ5TPkAuf1TyWJ1MqnoFn6+7WcQk/leJwbVDTtKV7T0bfTP8fGF57cV8qJ6SSWifpDseYdKh+ CnjP1kI3jkLTJ28wggbeMIIGR6ADAgECAhAKQxqZvhqCYGkI3t2w3MxpMA0GCSqGSIb3DQEBBQUA MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24g VHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlz aWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0wNjA2MTkwMDAwMDBaFw0wODA2MTgyMzU5NTlaMIGeMSAwHgYDVQQKFBdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTEmMCQGA1UECxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxDzAN BgNVBAsUBlMvTUlNRTEZMBcGA1UEAxMQTWF1cmljaW8gU2FuY2hlejEmMCQGCSqGSIb3DQEJARYX bWF1cmljaW8uc2FuY2hlekBocC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAPgf5XSw MrmsK38PKwfRhviBxSVuMu/capaqytMG03BP4CLGoEGkpM++Bwa/c3QOiCt+OpdHtwZVTEQoSiDT w9CTLFpZiGF7L6Uj6qMcEhE851Yu+Sl5JchXdgjBzJl+3n+qAUV8sCJ2QrgXM3HAhI+eUdtGuHMh +gzONzNMprNRAgMBAAGjggPVMIID0TA7BgNVHREENDAygRdtYXVyaWNpby5zYW5jaGV6QGhwLmNv bYEXbWF1cmljaW9fc2FuY2hlekBocC5jb20wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAw HwYDVR0jBBgwFoAU7+0gzUNFH4NHYBWWQ3JK5MbM5z0wHQYDVR0OBBYEFJk84lGSnBG2RoqTHc7T YsF6Ss87MFcGA1UdHwRQME4wTKBKoEiGRmh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hl d2xldHRQYWNrYXJkQ29tcGFueVNNSU1FL0xhdGVzdENSTC5jcmwwFgYDVR0lAQH/BAwwCgYIKwYB BQUHAwQwggE9BgNVHSAEggE0MIIBMDCCASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYc aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1Q YWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJl c3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vzc2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQg dG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29y cC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wggEzBggrBgEFBQcBAQSC ASUwggEhMCsGCCsGAQUFBzABhh9odHRwOi8vb25zaXRlLW9jc3AudmVyaXNpZ24uY29tMIHxBggr BgEFBQcwAqSB5DCB4TEuMCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEwMC4GA1UECxMnQ2xhc3MgMiBPblNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMTow OAYDVQQLEzFUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYShjKTAx MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTBLBgkqhkiG9w0BCQ8EPjA8MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG9w0DAgIC AEAwDgYIKoZIhvcNAwQCAgCAMAoGCCqGSIb3DQMHMA0GCSqGSIb3DQEBBQUAA4GBAH50gDgTOqzg Nw8bAbjvdX+Rk/ZtdlGB2ncFo8DvK0MtDhKOhU8jiwWaLffYzfiJgW6iWgD2R5gIpsf/vW8avKen Ca+Q8COT8bUyTc9gEWfgKG4UWdqtKUqVC69YMSOjc69nF2zVWw3FI7OsxRtDKWz7LGkhUcjj2j5v HoFIjr/CMYIEgjCCBH4CAQEwgfcwgeIxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwMTEwMC4GA1UECxMnQ2xhc3MgMiBP blNpdGUgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBMS4wLAYDVQQDEyVDb2xsYWJvcmF0aW9uIENl cnRpZmljYXRpb24gQXV0aG9yaXR5AhAKQxqZvhqCYGkI3t2w3MxpMAkGBSsOAwIaBQCgggLgMBgG CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDcwOTE3NDAyNlowIwYJ KoZIhvcNAQkEMRYEFNiD1kvbVlb1k/sAjzuCBg+uHrHHMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBCAYJKwYBBAGCNxAEMYH6MIH3MIHiMSAwHgYDVQQK ExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDExMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEu MCwGA1UEAxMlQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBp CN7dsNzMaTCCAQoGCyqGSIb3DQEJEAILMYH6oIH3MIHiMSAwHgYDVQQKExdIZXdsZXR0LVBhY2th cmQgQ29tcGFueTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVy bXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDExMDAuBgNVBAsT J0NsYXNzIDIgT25TaXRlIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTEuMCwGA1UEAxMlQ29sbGFi b3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQCkMamb4agmBpCN7dsNzMaTANBgkqhkiG 9w0BAQEFAASBgG7dT11h0vD7N1UcEG1zbhVjcOCNxffskr6wpwaL4XtuB1eCuOCJvTMDbF9lf+SV PNLXnMlPjIAzRB3g1m2j65nc6iekrgj7UGZ+EkjN4D6i/sQ2vI45iGgWGJvq+obQHP6XndsITwQo PXuPViIt9G7jflUvrbeXhfXbVzs/9/KhAAAAAAAA ------=_NextPart_000_0013_01C6A344.16AFEE50-- -- to unsubscribe send a message to radiusext-request@ops.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, 10 Jul 2006 00:39: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: IETF-66: Resources for remote participants Date: Sun, 9 Jul 2006 20:38:56 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021934D@MABOSEVS2.ets.enterasys.com> Thread-Topic: IETF-66: Resources for remote participants Thread-Index: AcajuTHKV0NSpIXzRZetn45BYoqRTw== From: "Nelson, David" To: Streaming audio: http://videolab.uoregon.edu/events/ietf/ Jabber: jabber server =3D jabber.ietf.org, room =3D radext (in general, the = WG name) Meeting materials (slides, etc.): =20 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 6 RADEXT meets at 9:00 AM EDT, tomorrow (Monday, July 10). -- to unsubscribe send a message to radiusext-request@ops.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, 09 Jul 2006 20:05:39 +0000 Message-ID: <44B14850.5030507@gmx.net> Date: Sun, 09 Jul 2006 20:17:52 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) MIME-Version: 1.0 To: NSIS , dime@ietf.org, radiusext@ops.ietf.org, tsvwg Subject: [Fwd: [Dime] Diameter QoS Dinner] Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, please do not forget the QoS dinner Sunday evening, 19:30 at the registration desk. Ciao Hannes -------- Original Message -------- Subject: [Dime] Diameter QoS Dinner Date: Mon, 19 Jun 2006 14:14:39 +0200 From: Tschofenig, Hannes To: Hi all, it would be good to meet Diameter QoS interested folks at the next IETF for a discussion about possible next steps before the DIME session. The DIME WG session will be on***** MONDAY, July 10, 2006** * *1740-1840 Afternoon Session III* Room 519B APP _widex_ Widget Description Exchange Service WG Room 520ABC INT _softwire_ Softwires WG Room 519A IRTF NMRG Network Management Research Group Charter *Room 513C-F OPS **_dime_* * Diameter Maintenance and Extensions WG *Room 520DEF RAI rtpsec Securing the Real-time Transport Protocol BOF Room 513B SEC _sasl_ Simple Authentication and Security Layer WG Room 518AB TSV _tsvwg_ Transport Area Working Group WG _https://datatracker.ietf.org/public/meeting_agenda_html.cgi?meeting_num=66_ Hence, there is only time after the Welcome Reception on Sunday. My proposal would be to meet at the registration desk at 19:30. Please send me a mail if you are interested. Ciao Hannes -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 09 Jul 2006 18:30:37 +0000 Date: Sun, 9 Jul 2006 11:30:06 -0700 Message-Id: <200607091830.k69IU6Jr030024@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4590 on RADIUS Extension for Digest Authentication From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4590 Title: RADIUS Extension for Digest Authentication Author: B. Sterman, D. Sadolevsky, D. Schwartz, D. Williams, W. Beck Status: Standards Track Date: July 2006 Mailbox: baruch@kayote.com, dscreat@dscreat.com, david@kayote.com, dwilli@cisco.com, beckw@t-systems.com Pages: 32 Characters: 67181 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-digest-auth-09.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4590.txt This document defines an extension to the Remote Authentication Dial-In User Service (RADIUS) protocol to enable support of Digest Authentication, for use with HTTP-style protocols like the Session Initiation Protocol (SIP) and HTTP. [STANDARDS TRACK] This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... -- to unsubscribe send a message to radiusext-request@ops.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, 09 Jul 2006 16:08:03 +0000 Date: Sun, 9 Jul 2006 12:07:31 -0400 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting Message-ID: <20060709160731.GA4830@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Sun, Jul 09, 2006 at 08:32:20AM -0400, Avi Lior wrote: > I meant Diameter AVPs in RADIUS (If that initiative is still underway). So did I; see draft-wolff-radext-ext-attribute-00.txt . If we adopted that or anything equivalent, the 253 limit would be removed, among other benefits. -- Barney Wolff 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: Sun, 09 Jul 2006 14:26:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Attribute concatenation/splitting Date: Sun, 9 Jul 2006 17:25:29 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAAjgDOwAAhVuAAAn2XcsAJEBC4A== From: To: , Avi Lior wrote: > Are we talking about NAS-Filter-Rule? That is what I was talking > about. > > NAS-Filter-Rule is IPFilterRule which can only have permit or deny > in the action position. >=20 > However if you are talking about the Redirection work then you are > right. IMHO it would be nice to use the same approach to concatenation/splitting for both NAS-Filter-Rule (the one copied from Diameter) and=20 NAS-Traffic-Rule (the one including redirection and tunnels).=20 Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sun, 09 Jul 2006 12:33:10 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A353.D4CC05A9" Subject: RE: Issue: Attribute concatenation/splitting Date: Sun, 9 Jul 2006 08:32:20 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: Acai8KlylgiPv1COSeivtOTrgJTH6QAYw9BX From: "Avi Lior" To: "Barney Wolff" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A353.D4CC05A9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I meant Diameter AVPs in RADIUS (If that initiative is still underway). -----Original Message----- From: Barney Wolff [mailto:barney@databus.com] Sent: Sat 7/8/2006 8:42 PM To: Avi Lior Cc: Pasi.Eronen@nokia.com; radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting =20 On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote: >=20 > If we want to solve fragmentation in general then inserting a value = inside the attribute will not work. I think we have to invent something = in the header of the attribute. >=20 > For example, if we were to use Diameter AVP in RADIUS we would add a = new flag (where the 'M' 'V' flags are) to indicate that the value of = this attribute spans the next attribute. >=20 > Why don't we hold this work until we can agree on the Diameter AVP? I certainly concur. But using the Diameter AVP header makes the problem go away, as Diameter AVPs are not limited to 253 bytes. --=20 Barney Wolff I never met a computer I didn't like. ------_=_NextPart_001_01C6A353.D4CC05A9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issue: Attribute concatenation/splitting

I meant Diameter AVPs in RADIUS (If that initiative is = still underway).




-----Original Message-----
From: Barney Wolff [mailto:barney@databus.com]
Sent: Sat 7/8/2006 8:42 PM
To: Avi Lior
Cc: Pasi.Eronen@nokia.com; radiusext@ops.ietf.org
Subject: Re: Issue: Attribute concatenation/splitting

On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote:
>
> If we want to solve fragmentation in general then inserting a value = inside the attribute will not work.  I think we have to invent = something in the header of the attribute.
>
> For example, if we were to use Diameter AVP in RADIUS we would add = a new flag (where the 'M' 'V' flags are) to indicate that the value of = this attribute spans the next attribute.
>
> Why don't we hold this work until we can agree on the Diameter = AVP?

I certainly concur.  But using the Diameter AVP header makes the = problem
go away, as Diameter AVPs are not limited to 253 bytes.

--
Barney Wolff         I never met = a computer I didn't like.

------_=_NextPart_001_01C6A353.D4CC05A9-- -- to unsubscribe send a message to radiusext-request@ops.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, 09 Jul 2006 00:42:38 +0000 Date: Sat, 8 Jul 2006 20:42:08 -0400 From: Barney Wolff To: Avi Lior Cc: Pasi.Eronen@nokia.com, radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting Message-ID: <20060709004208.GA14590@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Sat, Jul 08, 2006 at 12:14:11PM -0400, Avi Lior wrote: > > If we want to solve fragmentation in general then inserting a value inside the attribute will not work. I think we have to invent something in the header of the attribute. > > For example, if we were to use Diameter AVP in RADIUS we would add a new flag (where the 'M' 'V' flags are) to indicate that the value of this attribute spans the next attribute. > > Why don't we hold this work until we can agree on the Diameter AVP? I certainly concur. But using the Diameter AVP header makes the problem go away, as Diameter AVPs are not limited to 253 bytes. -- Barney Wolff 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: Sat, 08 Jul 2006 21:07:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A2D2.8E1A9CDD" Subject: RE: Issue: Attribute concatenation/splitting Date: Sat, 8 Jul 2006 17:05:01 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAAjgDOwAAhVuAAAn2Xcs= From: "Avi Lior" To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A2D2.8E1A9CDD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Passi, Are we talking about NAS-Filter-Rule? That is what I was talking about. NAS-Filter-Rule is IPFilterRule which can only have permit or deny in = the action position. However if you are talking about the Redirection work then you are = right. -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Sat 7/8/2006 12:24 PM To: Avi Lior; radiusext@ops.ietf.org Subject: RE: Issue: Attribute concatenation/splitting =20 Avi Lior wrote: > I have to read the draft. Is permit/deny allowed inside the > attribute because we are allowed to include more then one rule > inside the packet? If that is the case IMO we should not do that. > One rule per attribute. No, it's because there are rule elements (e.g. tunnel-id, org-url and redir-url) that are more-or-less arbitrary strings. In other words, you could have a tunnel called "permit" or a URL that contains the string "deny". Best regards, Pasi ------_=_NextPart_001_01C6A2D2.8E1A9CDD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issue: Attribute concatenation/splitting

Hi Passi,

Are we talking about NAS-Filter-Rule?  That is what I was talking = about.

NAS-Filter-Rule is IPFilterRule which can only have permit or deny in = the action position.

However if you are talking about the Redirection work then you are = right.



-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Sat 7/8/2006 12:24 PM
To: Avi Lior; radiusext@ops.ietf.org
Subject: RE: Issue: Attribute concatenation/splitting

Avi Lior wrote:
> I have to read the draft.  Is permit/deny allowed inside = the
> attribute because we are allowed to include more then one rule
> inside the packet? If that is the case IMO we should not do = that.
> One rule per attribute.

No, it's because there are rule elements (e.g. tunnel-id, org-url
and redir-url) that are more-or-less arbitrary strings. In other
words, you could have a tunnel called "permit" or a URL = that
contains the string "deny".

Best regards,
Pasi

------_=_NextPart_001_01C6A2D2.8E1A9CDD-- -- to unsubscribe send a message to radiusext-request@ops.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, 08 Jul 2006 16:25:57 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Attribute concatenation/splitting Date: Sat, 8 Jul 2006 19:24:43 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAAjgDOwAAhVuA From: To: , Avi Lior wrote: > I have to read the draft. Is permit/deny allowed inside the > attribute because we are allowed to include more then one rule > inside the packet? If that is the case IMO we should not do that. > One rule per attribute. No, it's because there are rule elements (e.g. tunnel-id, org-url and redir-url) that are more-or-less arbitrary strings. In other words, you could have a tunnel called "permit" or a URL that contains the string "deny". Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Jul 2006 16:13:58 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A2A9.8C508B1D" Subject: RE: Issue: Attribute concatenation/splitting Date: Sat, 8 Jul 2006 12:14:11 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSAAAjgDOw== From: "Avi Lior" To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A2A9.8C508B1D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Pasi, Understood. Tagging should not be used. Tagging is for grouping not for = fragmentation. If I use tagging for fragmentation then what will I use for grouping = when I want to group things together? I have to read the draft. Is permit/deny allowed inside the attribute = because we are allowed to include more then one rule inside the packet? = If that is the case IMO we should not do that. One rule per attribute. If we want to solve fragmentation in general then inserting a value = inside the attribute will not work. I think we have to invent something = in the header of the attribute. For example, if we were to use Diameter AVP in RADIUS we would add a new = flag (where the 'M' 'V' flags are) to indicate that the value of this = attribute spans the next attribute. Why don't we hold this work until we can agree on the Diameter AVP? -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Sat 7/8/2006 11:08 AM To: Avi Lior; radiusext@ops.ietf.org Subject: RE: Issue: Attribute concatenation/splitting =20 Avi Lior wrote: > I think we should not allow to pack more then one Filter Rule in a > single attribute. >=20 > A Filter Rule should be allowed to overflow (span) more then one > attribute. >=20 > If you have more then one filter rules in a packet with some filter > rules overflowing, how can you tell when a new one begins? >=20 > A filter rule always starts with an action: permit or deny. These > words do not appear anywhere else in the rule. Therefore a Filter > Atribute that starts with a permit or deny must be a new filter > rule. >=20 > What is wrong with that? It requires code specific to this attribute in RADIUS clients, servers, and RADIUS<->Diameter translation agents. And that code=20 cannot be reused for other attributes: e.g. in the current=20 NAS-Traffic-Rule draft, the words "permit"/"deny" can appear in=20 the middle of a rule. Yes, this would work for NAS-Filter-Rule -- but so would any of the other proposals so far (e.g. rules end with LF; rule ends if=20 attribute length <253; attributes begin with a tag octet; etc.) =20 I don't think any of these proposals is a really good one, but at=20 least the same approach could be reused for NAS-Traffic-Rule (and=20 maybe other attributes in the future as well). Best regards, Pasi ------_=_NextPart_001_01C6A2A9.8C508B1D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issue: Attribute concatenation/splitting

Pasi,

Understood.

Tagging should not be used.  Tagging is for grouping not for = fragmentation.

If I use tagging for fragmentation then what will I use for grouping = when I want to group things together?

I have to read the draft.  Is permit/deny allowed inside the = attribute because we are allowed to include more then one rule inside = the packet? If that is the case IMO we should not do that.  One = rule per attribute.

If we want to solve fragmentation in general then inserting a value = inside the attribute will not work.  I think we have to invent = something in the header of the attribute.

For example, if we were to use Diameter AVP in RADIUS we would add a new = flag (where the 'M' 'V' flags are) to indicate that the value of this = attribute spans the next attribute.

Why don't we hold this work until we can agree on the Diameter AVP?


-----Original Message-----
From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] Sent: Sat 7/8/2006 11:08 AM
To: Avi Lior; radiusext@ops.ietf.org
Subject: RE: Issue: Attribute concatenation/splitting

Avi Lior wrote:

> I think we should not allow to pack more then one Filter Rule in = a
> single attribute.
>
> A Filter Rule should be allowed to overflow (span) more then = one
> attribute.
>
> If you have more then one filter rules in a packet with some = filter
> rules overflowing, how can you tell when a new one begins?
>
> A filter rule always starts with an action: permit or deny.  = These
> words do not appear anywhere else in the rule.  Therefore a = Filter
> Atribute that starts with a permit or deny must be a new filter
> rule.
>
> What is wrong with that?

It requires code specific to this attribute in RADIUS clients,
servers, and RADIUS<->Diameter translation agents. And that = code
cannot be reused for other attributes: e.g. in the current
NAS-Traffic-Rule draft, the words "permit"/"deny" = can appear in
the  middle of a rule.

Yes, this would work for NAS-Filter-Rule -- but so would any of the
other proposals so far (e.g. rules end with LF; rule ends if
attribute length <253; attributes begin with a tag octet; = etc.) 
I don't think any of these proposals is a really good one, but at
least the same approach could be reused for NAS-Traffic-Rule (and
maybe other attributes in the future as well).

Best regards,
Pasi

------_=_NextPart_001_01C6A2A9.8C508B1D-- -- to unsubscribe send a message to radiusext-request@ops.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, 08 Jul 2006 15:09:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Attribute concatenation/splitting Date: Sat, 8 Jul 2006 18:08:10 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQAB55oSA= From: To: , Avi Lior wrote: > I think we should not allow to pack more then one Filter Rule in a > single attribute. >=20 > A Filter Rule should be allowed to overflow (span) more then one > attribute. >=20 > If you have more then one filter rules in a packet with some filter > rules overflowing, how can you tell when a new one begins? >=20 > A filter rule always starts with an action: permit or deny. These > words do not appear anywhere else in the rule. Therefore a Filter > Atribute that starts with a permit or deny must be a new filter > rule. >=20 > What is wrong with that? It requires code specific to this attribute in RADIUS clients, servers, and RADIUS<->Diameter translation agents. And that code=20 cannot be reused for other attributes: e.g. in the current=20 NAS-Traffic-Rule draft, the words "permit"/"deny" can appear in=20 the middle of a rule. Yes, this would work for NAS-Filter-Rule -- but so would any of the other proposals so far (e.g. rules end with LF; rule ends if=20 attribute length <253; attributes begin with a tag octet; etc.) =20 I don't think any of these proposals is a really good one, but at=20 least the same approach could be reused for NAS-Traffic-Rule (and=20 maybe other attributes in the future as well). Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Jul 2006 02:22:03 +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: Attribute concatenation/splitting Date: Fri, 7 Jul 2006 22:22:11 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcaiMrPufGpxjlUmRdyT04iLw3hk3AAAeeDQ From: "Avi Lior" To: "Barney Wolff" Cc: Your preaching to the wrong guy. I think I had a proposal on the table when RADEXT started to extend the attributes space, and support attribute segmentation. Everyone was against it and not for technical merits but because nobody thought we need to extend or should extend or enhance etc etc .... =20 =20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Friday, July 07, 2006 10:03 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Issue: Attribute concatenation/splitting >=20 > On Fri, Jul 07, 2006 at 09:54:06PM -0400, Avi Lior wrote: > >=20 > > I understand what your objections. You are trying to solve the=20 > > problem in general. Nothing wrong with that. > >=20 > > But as a specific solution to a specific problem what I=20 > propose will=20 > > work. No? >=20 > Sure, but so would any other technique. That is, until the=20 > filter-rule syntax is "enhanced" in some way. >=20 > Regards, > Barney >=20 > --=20 > Barney Wolff I never met a computer I didn't like. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Jul 2006 02:02:48 +0000 Date: Fri, 7 Jul 2006 22:02:37 -0400 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting Message-ID: <20060708020237.GB98629@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Fri, Jul 07, 2006 at 09:54:06PM -0400, Avi Lior wrote: > > I understand what your objections. You are trying to solve the problem > in general. Nothing wrong with that. > > But as a specific solution to a specific problem what I propose will > work. No? Sure, but so would any other technique. That is, until the filter-rule syntax is "enhanced" in some way. Regards, Barney -- Barney Wolff 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: Sat, 08 Jul 2006 01:53: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: Attribute concatenation/splitting Date: Fri, 7 Jul 2006 21:54:06 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcaiMKS9o7Sb8qo8Q7ynjqQhrum6rwAAHhMw From: "Avi Lior" To: "Barney Wolff" Cc: Barney, I understand what your objections. You are trying to solve the problem in general. Nothing wrong with that. But as a specific solution to a specific problem what I propose will work. No?=20 > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com]=20 > Sent: Friday, July 07, 2006 9:48 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Issue: Attribute concatenation/splitting >=20 > On Fri, Jul 07, 2006 at 08:33:07PM -0400, Avi Lior wrote: > > I think we should not allow to pack more then one Filter Rule in a=20 > > single attribute. > >=20 > > A Filter Rule should be allowed to overflow (span) more then one=20 > > attribute. > >=20 > > If you have more then one filter rules in a packet with some filter=20 > > rules overflowing, how can you tell when a new one begins? > >=20 > > A filter rule always starts with an action: permit or deny. These=20 > > words do not appear anywhere else in the rule. Therefore a Filter=20 > > Atribute that starts with a permit or deny must be a new=20 > filter rule. > >=20 > > What is wrong with that? >=20 > It's a layer violation. >=20 > What will be suggested when the next new attribute runs into=20 > the same problem? Another technique that depends on the=20 > syntax of the particular attribute? >=20 > IMHO, Feh! >=20 > Regards, > Barney >=20 > --=20 > Barney Wolff I never met a computer I didn't like. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Jul 2006 01:47:58 +0000 Date: Fri, 7 Jul 2006 21:47:48 -0400 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting Message-ID: <20060708014748.GA98629@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Fri, Jul 07, 2006 at 08:33:07PM -0400, Avi Lior wrote: > I think we should not allow to pack more then one Filter Rule in a > single attribute. > > A Filter Rule should be allowed to overflow (span) more then one > attribute. > > If you have more then one filter rules in a packet with some filter > rules overflowing, how can you tell when a new one begins? > > A filter rule always starts with an action: permit or deny. These words > do not appear anywhere else in the rule. Therefore a Filter Atribute > that starts with a permit or deny must be a new filter rule. > > What is wrong with that? It's a layer violation. What will be suggested when the next new attribute runs into the same problem? Another technique that depends on the syntax of the particular attribute? IMHO, Feh! Regards, Barney -- Barney Wolff 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: Sat, 08 Jul 2006 01:44:43 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: The RADIUS attribute space: an assessment Date: Fri, 7 Jul 2006 21:44:43 -0400 Message-ID: Thread-Topic: The RADIUS attribute space: an assessment Thread-Index: Acablrry31qqTsgsRZy9qxtIgFw1iQGlMttw From: "Avi Lior" To: "Alan DeKok" , "Glen Zorn \(gwz\)" Cc: Some update: Now that Diameter has been standerdized, 3GPP2 has started to include Diameter in the Packet Data Network. RADIUS is still mandatory and now Vendors are free to deliver products based on Diameter. Operators will now have a choice. Support for NASREQ, Mobile IP, EAP Application and Credit Control. WiMAX release 1.0 is based exclusively on RADIUS. However it is anticipated that Diameter will come in the next release (1.5) I will certainly try to bring it in. We all know about the uses of Diameter in 3GPP. I think that Diameter POs will start to come in the Carrier market. But it will take years before Diameter will overtake RADIUS. When we talk about Diameter vs RADIUS etc we have to consider that there are different deployement and business drivers to consider. There is no right answer except for one: let the market decide. I will continue to do work on (extend) RADIUS in the IETF or elsewhere as long as my customers are willing to pay for that work. I will also continue to work on Diameter because I belive that customers will start to want it. I think that we should extend the RADIUS attribute space in the IETF and support new features etc... The work mentioned by Bernard in Mobile IPv4 that requires 31 attributes is a direct result of the philosophy of some in RADEXT that want flat attribute space. If we did the work in MIPv4 using complex attribute encoding we would probably only need 10 attributes or less. Therefore I think we should allow more complex attribute encoding.=20 I am somewhat puzzled by Glen: on one hand he is yelling "Pull the plug" on the other hand it seems that he is the RADIUS poster boy judging by the number of RADIUS drafts he has floating around. Avi =20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 08 Jul 2006 00:35:35 +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: Attribute concatenation/splitting Date: Fri, 7 Jul 2006 20:33:07 -0400 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcahL2LW15ubFx/dQSmPzvP1/s5NNQA9hUmQ From: "Avi Lior" To: "Bernard Aboba" , I think we should not allow to pack more then one Filter Rule in a single attribute. A Filter Rule should be allowed to overflow (span) more then one attribute. If you have more then one filter rules in a packet with some filter rules overflowing, how can you tell when a new one begins? A filter rule always starts with an action: permit or deny. These words do not appear anywhere else in the rule. Therefore a Filter Atribute that starts with a permit or deny must be a new filter rule. What is wrong with that? > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, July 06, 2006 3:05 PM > To: radiusext@ops.ietf.org > Subject: Re: Issue: Attribute concatenation/splitting >=20 > Do we have a conclusion from this thread? If so, can someone=20 > state what they think it is? >=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: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 06 Jul 2006 21:13:56 +0000 Date: Thu, 6 Jul 2006 17:13:22 -0400 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Issue: Attribute concatenation/splitting Message-ID: <20060706211322.GA94474@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 On Thu, Jul 06, 2006 at 12:05:12PM -0700, Bernard Aboba wrote: > Do we have a conclusion from this thread? If so, can someone state what > they think it is? I don't perceive a conclusion, which reinforces the thought that either we define a standard way of escaping from the 253-byte limit or we get to debate how to do it each and every time a new attribute might need it. I'm too old for the latter, but there is a draft which would enable the former: http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00.txt I'd be happy to update it based on comments from the list, if people will express some interest. Regards, Barney -- Barney Wolff 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: Thu, 06 Jul 2006 19:05:44 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Re: Issue: Attribute concatenation/splitting Date: Thu, 06 Jul 2006 12:05:12 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Do we have a conclusion from this thread? If so, can someone state what they think it is? -- to unsubscribe send a message to radiusext-request@ops.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, 06 Jul 2006 14:44:39 +0000 From: "Alan DeKok" To: Pasi.Eronen@nokia.com Subject: Re: Issue: Attribute concatenation/splitting cc: radiusext@ops.ietf.org Date: Thu, 06 Jul 2006 10:34:47 -0400 Message-Id: <20060706143447.24DDC16E4F@mail.nitros9.org> Pasi.Eronen@nokia.com wrote: > It is, by including a long list of ports: E.g. "permit in tcp from=20 > any to assigned 12345,22222,24224,27272,33333,..." In many of those cases, the list can be split on the *semantic* level, rather than the RADIUS attribute level. e.g. assuming there's a trailing "deny all" filter, your example is entirely equivalent to permit in tcp from any to assigned 12345 permit in tcp from any to assigned 22222 permit in tcp from any to assigned 24224 permit in tcp from any to assigned ... It's not optimal, but it will work, and it will avoid long RADIUS attributes. 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, 06 Jul 2006 07:24:30 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Attribute concatenation/splitting Date: Thu, 6 Jul 2006 10:23:40 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: Acaf+aCP+ccTq0XbSgi8r0rSu/31EwAdCkewABeV5gA= From: To: , David Nelson wrote: > It would be an interesting exercise to see if it is possible=20 > to specify an instance of the IPFilterRule derived data type that=20 > is longer than 253 octets. It is, by including a long list of ports: E.g. "permit in tcp from=20 any to assigned 12345,22222,24224,27272,33333,..." (But perhaps this is so rare that we could simply say that rules longer than 253 octets cannot be used with the RADIUS attribute.) Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Jul 2006 20:23:06 +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: Attribute concatenation/splitting Date: Wed, 5 Jul 2006 16:22:34 -0400 Message-ID: <3CFB564E055A594B82C4FE89D215656021932A@MABOSEVS2.ets.enterasys.com> Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: Acaf+aCP+ccTq0XbSgi8r0rSu/31EwAdCkew From: "Nelson, David" To: Alan DeKok writes... > If one rule can span multiple NAS-Filter-Rule attributes, then it > needs a "terminate this rule" that is independent "terminate this > attribute". While the text in RFC 3588 and RFC 4005 could, IMHO, benefit from some clarification, it appears to me that the Diameter NAS-Filter-Rule AVP {RFC4005] contains one instance of the derived data type IPFilterRule [RFC3588], which appears to describe a single rule. If this is correct, the only situation in which a rule would span multiple RADIUS NAS-Filter-Rule Attributes is when the rule text exceeds 253 octets. While this is theoretically possible, the formal syntax of IPFilterRule tends to limit the likelihood for this to occur. Or so it would seem to me. > A CR, LF, or combination can do that, in which case the > problem of attributes of length 2 doesn't exist, because the packing > methods prohibit it. I'm not in favor of ASCII delimiters for sub-strings within strings. This is effectively "value packing" i.e. encoding multiple values in a single value field of an RADIUS TLV. > If one rule cannot span multiple NAS-Filter-Rule attributes, then > there is no problem, because an attribute of length 255 has no special > meaning. It would be an interesting exercise to see if it is possible to specify an instance of the IPFilterRule derived data type that is longer than 253 octets. > On the other hand, if one rule can span multiple NAS-Filter-Rule > attributes, then you might as well give up on trying to match rules to > attributes. Pack all of the rules together in one long string, and > then chop the string every 253 bytes to encode it into NAS-Filter-Rule > attributes. So there will be no special meaning for attributes of > length 255, so there will be no problem. Ugh. > With this last method, we would presume that any implementation that > needs to be able to add/delete rules would know about the packing > methods, and be able to unpack/add/pack the rules into attributes. > This would tend to break backwards compatibility with older RADIUS > servers, so they wouldn't be able to edit the rules, though. Right. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Jul 2006 06:08:19 +0000 From: "Alan DeKok" To: rajithr@huawei.com Subject: Re: Issue: Attribute concatenation/splitting cc: Pasi.Eronen@nokia.com, radiusext@ops.ietf.org Date: Wed, 05 Jul 2006 01:58:30 -0400 Message-Id: <20060705055830.66F9516E0B@mail.nitros9.org> Rajith R wrote: > In a RADIUS packet, there are 2 successive NAS-Filter-Rule attributes of > length 255 & 50 respectively. How do you determine they are 2 separate > attributes or a single attribute split? If one rule can span multiple NAS-Filter-Rule attributes, then it needs a "terminate this rule" that is independent "terminate this attribute". A CR, LF, or combination can do that, in which case the problem of attributes of length 2 doesn't exist, because the packing methods prohibit it. If one rule cannot span multiple NAS-Filter-Rule attributes, then there is no problem, because an attribute of length 255 has no special meaning. On the other hand, if one rule can span multiple NAS-Filter-Rule attributes, then you might as well give up on trying to match rules to attributes. Pack all of the rules together in one long string, and then chop the string every 253 bytes to encode it into NAS-Filter-Rule attributes. So there will be no special meaning for attributes of length 255, so there will be no problem. With this last method, we would presume that any implementation that needs to be able to add/delete rules would know about the packing methods, and be able to unpack/add/pack the rules into attributes. This would tend to break backwards compatibility with older RADIUS servers, so they wouldn't be able to edit the rules, though. 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, 05 Jul 2006 04:41:04 +0000 Date: Wed, 05 Jul 2006 10:10:27 +0530 From: Rajith R Subject: RE: Issue: Attribute concatenation/splitting To: aland@nitros9.org, Pasi.Eronen@nokia.com Cc: radiusext@ops.ietf.org Reply-to: rajithr@huawei.com Message-id: <000c01c69fed$23f71a20$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcafjKR0qdtNSPMPSWCHOrLg+RB43AAYDWmQ See comments inline **************************************************************************** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >-----Original Message----- >From: aland@nitros9.org [mailto:aland@nitros9.org] >Sent: Tuesday, July 04, 2006 10:30 PM >To: Pasi.Eronen@nokia.com >Cc: rajithr@huawei.com; radiusext@ops.ietf.org >Subject: Re: Issue: Attribute concatenation/splitting > >Pasi.Eronen@nokia.com wrote: >> Yes, this would work as well: an attribute length 255 would mean that >> the data item continues to the next attribute; > > If the next attribute exists. > >> attribute length less than 255 would indicate the final piece of >> this data item. > > Or, if there is no next attribute. > >> The only catch might be that RFC 2865 prohibits string/text attributes >> with length 2 (=string length 0). > > Attributes of length 2 are unnecessary if the above conditions are met. In a RADIUS packet, there are 2 successive NAS-Filter-Rule attributes of length 255 & 50 respectively. How do you determine they are 2 separate attributes or a single attribute split? Rajith > > Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jul 2006 17:09:55 +0000 From: "Alan DeKok" To: Pasi.Eronen@nokia.com Subject: Re: Issue: Attribute concatenation/splitting cc: rajithr@huawei.com, radiusext@ops.ietf.org Date: Tue, 04 Jul 2006 12:59:54 -0400 Message-Id: <20060704165954.46D2916CC1@mail.nitros9.org> Pasi.Eronen@nokia.com wrote: > Yes, this would work as well: an attribute length 255 would mean that > the data item continues to the next attribute; If the next attribute exists. > attribute length less than 255 would indicate the final piece of > this data item. Or, if there is no next attribute. > The only catch might be that RFC 2865 prohibits string/text attributes > with length 2 (=string length 0). Attributes of length 2 are unnecessary if the above conditions are met. 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, 03 Jul 2006 14:37:48 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69EAE.38C4ACB6" Subject: RADEXT WG Agenda for IETF-66 Date: Mon, 3 Jul 2006 10:37:34 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219322@MABOSEVS2.ets.enterasys.com> Thread-Topic: RADEXT WG Agenda for IETF-66 Thread-Index: AcaerjeYKmRqdt4OR6q6D0eJvU1ogA== From: "Nelson, David" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C69EAE.38C4ACB6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This agenda is also posted at: =20 https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 6 =20 Agenda for the RADEXT WG Meeting at IETF 66 MONDAY, July 10, 2006 0900-1130 Morning Session I Room 519A =20 WGs meeting at the same time: apparea, ancp, netlmm, enum, ccamp, krb-wg, tsvwg =20 =20 A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 minutes) =20 B. Agenda Bashing =20 C. Milestone Status Review (5 minutes) =20 D. Document Status =20 D.1 Documents in IESG review (5 minutes): =20 draft-ietf-radext-rfc2618bis-04.txt draft-ietf-radext-rfc2618bis-04.txt draft-ietf-radext-rfc2618bis-04.txt draft-ietf-radext-rfc2618bis-04.txt draft-ietf-radext-dynauth-client-mib-06.txt draft-ietf-radext-dynauth-server-mib-06.txt draft-ietf-radext-delegated-prefix-01.txt draft-ietf-radext-vlan-06.txt =20 D.2 Documents in Pre-WG review =20 D.3.1 NAS-Traffic-Rule Attributes (Mauricio Sanchez, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-01.tx t =20 D.3.2 NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 minutes) http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-00.txt =20 D.3.3 WLAN Attributes (Bernard Aboba, 10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-03.txt D.3.4 Pre-Authentication AAA Requirements (Yoshihiro Ohba, 10 minutes) =20 D.3.5 Design Guidelines (TBD proxy for Greg Weber, 30 minutes) http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0 3.txt =20 D.3.6 Extended RADIUS Attributes (TBD, 30 minutes) http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attribute-00. txt =20 D.3.7 Issues & Fixes (Bernard Aboba, 10 minutes) http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.txt =20 D.3.8 NAS-Management (Dave Nelson, 10 minutes) http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-03.txt =20 D.4 Documents requiring cross-WG review =20 D.4.1 GEOPRIV-RADIUS (TBD, 5 minutes) http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-07.txt =20 D.4.2 ISMS Requirements for "Authorize Only" (Dave Nelson, 5 minutes) =20 E. Wrap-Up (5 minutes) =20 ------_=_NextPart_001_01C69EAE.38C4ACB6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This agenda is also posted at:

 

https://datatracker.ietf.org/public/meeting_materials.cgi?meeting= _num=3D66

 

Agenda for the RADEXT WG Meeting at IETF = 66

MONDAY, July 10, 2006

0900-1130 Morning Session I Room = 519A

 

WGs meeting at the same time: apparea, ancp, netlmm, enum, = ccamp, krb-wg, tsvwg 

 

A. Preliminaries, Note Takers, Jabber Scribes, Blue Sheets (5 = minutes)

 

B. Agenda Bashing

 

C. Milestone Status Review (5 = minutes)

 

D. Document Status

 

D.1 Documents in IESG review (5 = minutes):

 

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-rfc2618bis-04.txt

draft-ietf-radext-dynauth-client-mib-06.txt

draft-ietf-radext-dynauth-server-mib-06.txt

draft-ietf-radext-delegated-prefix-01.txt

draft-ietf-radext-vlan-06.txt

 

D.2  Documents in Pre-WG = review

 

D.3.1  NAS-Traffic-Rule Attributes (Mauricio Sanchez, 10 = minutes)

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rule= s-01.txt

 

D.3.2  NAS-Filter-Rule Attributes (Mauricio Sanchez, 10 = minutes)

http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-00.t= xt

 

D.3.3  WLAN Attributes (Bernard Aboba, 10 = minutes)

http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-03.tx= t

D.3.4  Pre-Authentication AAA Requirements (Yoshihiro Ohba, = 10 minutes)

 

D.3.5  Design Guidelines (TBD proxy for Greg Weber, 30 = minutes)

http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guide= lines-03.txt

 

D.3.6  Extended RADIUS Attributes (TBD, 30 = minutes)

http://www.ietf.org/internet-drafts/draft-wolff-radext-ext-attrib= ute-00.txt

 

D.3.7  Issues & Fixes (Bernard Aboba, 10 = minutes)

http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-03.t= xt

 

D.3.8  NAS-Management (Dave Nelson, 10 = minutes)

http://www.ietf.org/internet-drafts/draft-nelson-radius-managemen= t-authorization-03.txt

 

D.4  Documents requiring cross-WG = review

 

D.4.1  GEOPRIV-RADIUS (TBD, 5 = minutes)

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-= 07.txt

 

D.4.2  ISMS Requirements for "Authorize = Only"  (Dave Nelson, 5 minutes)

 

E. Wrap-Up (5 minutes)

 

------_=_NextPart_001_01C69EAE.38C4ACB6-- -- to unsubscribe send a message to radiusext-request@ops.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, 03 Jul 2006 14:00: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: Attribute concatenation/splitting Date: Mon, 3 Jul 2006 09:59:56 -0400 Message-ID: <3CFB564E055A594B82C4FE89D2156560219321@MABOSEVS2.ets.enterasys.com> Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: Acaek0OLtsEjf56LSQukF8SLl9jt6gABGYoQAAPWcpA= From: "Nelson, David" To: Pasi Eronen writes... > Yes, this would work as well: an attribute length 255 would mean that > the data item continues to the next attribute; attribute length less > than 255 would indicate the final piece of this data item. Making the RADIUS application layer fragmentation and reassembly agnostic to specific attribute ID indeed has some attractive properties. > The only catch might be that RFC 2865 prohibits string/text attributes > with length 2 (=3Dstring length 0). But on the other hand, at least > draft-aboba-radext-fixes talks about User-Name attributes with string > length 0, so perhaps this could be used anyway...? We are documenting this sort of "implementation discrepancies", but IMO, we ought not to encourage them. If RFC 2865 says MUST or MUST NOT, I think we need to honor those requirements. I'll offer another idea, although I'm not sure it is one that I would prefer. We can take advantage for the tagged attribute format used for the tunnel attributes [RFC 2868]. All RADIUS attributes containing fragments of a single Diameter rule would have the same tag value. -- to unsubscribe send a message to radiusext-request@ops.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, 03 Jul 2006 12:08:47 +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: Attribute concatenation/splitting Date: Mon, 3 Jul 2006 15:07:33 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: Acaek0OLtsEjf56LSQukF8SLl9jt6gABGYoQ From: To: , rajithr@huawei.com wrote: >=20 > IMHO, split/concatenate logic for multiple, potentially long data > items of the same type should be attribute type insensitive. One > such option could be split at 253th byte boundary of the payload and > add them successively to the RADIUS message. If the last (split) > RADIUS attribute also happens to be of attribute length =3D 255, add a > delimiter attribute (of the same type) with attribute length as 2. Yes, this would work as well: an attribute length 255 would mean that the data item continues to the next attribute; attribute length less than 255 would indicate the final piece of this data item. The only catch might be that RFC 2865 prohibits string/text attributes with length 2 (=3Dstring length 0). But on the other hand, at least=20 draft-aboba-radext-fixes talks about User-Name attributes with string=20 length 0, so perhaps this could be used anyway...? Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Jul 2006 12:02:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C69E98.880949F7" Subject: FW: I-D ACTION:draft-weber-radius-attr-guidelines-03.txt Date: Mon, 3 Jul 2006 08:01:51 -0400 Message-ID: <15B86BC7352F864BB53A47B540C089B601DA384A@xmb-rtp-20b.amer.cisco.com> Thread-Topic: I-D ACTION:draft-weber-radius-attr-guidelines-03.txt Thread-Index: AcaaRwBKyj5xlQGORqqxvoqYxNHUBwETLpIg From: "Greg Weber \(gdweber\)" To: This is a multi-part message in MIME format. ------_=_NextPart_001_01C69E98.880949F7 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 FYI, I updated the RADIUS attribute design guidelines=20 draft based on the discussion at IETF-65 [1]. See the 02->03 diff [2] for details. The three main issues raised were: -We do not want to preclude future mechanisms for per-attribute encryption (which may result from the current 'crypto-agility' work item). We also want=20 to point at the concerns around the current MD5-based mechanism. -We want to enable SDOs to work independently (from the IETF) by using these guidelines -Structured data fall into different categories based on which entities consume (or parse) them. Some of these categories are essentially opaque to RADIUS entities, and it's fine for these items to be over- loaded into existing types (like String). I tried to address these issues in the current (-03) draft. This topic will be discussed again at the upcoming IETF,=20 so please have a read, file issues, and come with opinions (or voice them on this list). Regards, Greg [1] http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf65/ietf65tuech7. mp3 (time index 1:22:40 - 1:58:26) [2] http://employees.org/~gdweber/02-03-diff.html > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, June 27, 2006 6:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-weber-radius-attr-guidelines-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 >=20 > Title : Design Guidelines for RADIUS Attributes > Author(s) : G. Weber > Filename : draft-weber-radius-attr-guidelines-03.txt > Pages : 17 > Date : 2006-6-27 > =09 > This memo explores various issues related to the data model used by > the Remote Authentication Dial In User Service (RADIUS) protocol. > Recommendations are made to facilitate internal alignment and > uniformity. Attribute design guidelines are provided both as an aid > to IETF development work, and to facilitate independent work by other > Standards Development Organizations (SDOs). >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-0 3.txt >=20 ------_=_NextPart_001_01C69E98.880949F7 Content-Type: application/octet-stream; name="draft-weber-radius-attr-guidelines-03.URL" Content-Transfer-Encoding: base64 Content-Description: draft-weber-radius-attr-guidelines-03.URL Content-Disposition: attachment; filename="draft-weber-radius-attr-guidelines-03.URL" W0ludGVybmV0U2hvcnRjdXRdDQpVUkw9ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC13ZWJlci1yYWRpdXMtYXR0ci1ndWlkZWxpbmVzLTAzLnR4dA0K ------_=_NextPart_001_01C69E98.880949F7-- -- to unsubscribe send a message to radiusext-request@ops.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, 03 Jul 2006 11:35:01 +0000 Date: Mon, 03 Jul 2006 16:54:20 +0530 From: Rajith R Subject: RE: Issue: Attribute concatenation/splitting To: Pasi.Eronen@nokia.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org Reply-to: rajithr@huawei.com Message-id: <000601c69e93$3b3a1080$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT See comments inline ************************************************************************ **** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] >>On Behalf Of Pasi.Eronen@nokia.com >>Sent: Monday, July 03, 2006 4:30 PM >>To: rajithr@huawei.com; bernard_aboba@hotmail.com; radiusext@ops.ietf.org >>Subject: RE: Issue: Attribute concatenation/splitting >> >>rajithr@huawei.com wrote: >> >>> AFAIK, splitting & concatenation are necessitated by the 255 byte >>> limit for RADIUS attributes. So it would be better to split at 253 >>> byte (for the attribute payload) boundary rather than LF or some >>> other attribute specific delimiter, I think this would have the >>> advantage of >>> * same & simple logic for concatenation/splitting of any >>> suitable RADIUS attribute of length > 255 >>> * packing efficiency in the message, though not a principal concern >> >>This simple concatenation/splitting works when you need to include a >>single, potentially long data item (e.g. EAP-Message) in a RADIUS >>message. But it gets complex if you need to include multiple, >>potentially long data items of the same type (in this case, individual >>filter rules) and you need to maintain the boundaries between the >>individual data items somehow. IMHO, split/concatenate logic for multiple, potentially long data items of the same type should be attribute type insensitive. One such option could be split at 253th byte boundary of the payload and add them successively to the RADIUS message. If the last (split) RADIUS attribute also happens to be of attribute length = 255, add a delimiter attribute (of the same type) with attribute length as 2. >> >>In particular, if we decide to support individual filter rules longer >>than 253 characters, it looks like a RADIUS-to-Diameter translation >>agent will need code specific to NAS-Filter-Rule no matter how we >>choose to do the concatenation/splitting on the RADIUS side. The >>difference is just how complex that code needs to be (e.g., is it >>sufficient just to recognize "LF", or understand the full filter >>rule syntax). To convert a RADIUS NAS Filter rule attribute to Diameter, the Diameter AVP header data should be generated/translated from RADIUS attribute header data and the attribute payload could be directly copied to the AVP payload. Only concatenation considerations need to be applied. >> >>Best regards, >>Pasi >> >>-- >>to unsubscribe send a message to radiusext-request@ops.ietf.org with >>the word 'unsubscribe' in a single line as the message text body. >>archive: -- to unsubscribe send a message to radiusext-request@ops.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, 03 Jul 2006 11:00:47 +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: Attribute concatenation/splitting Date: Mon, 3 Jul 2006 14:00:18 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcaeiBBN6GEd49ABS9CxSjYzTXhxyAABoLXg From: To: , , rajithr@huawei.com wrote: > AFAIK, splitting & concatenation are necessitated by the 255 byte > limit for RADIUS attributes. So it would be better to split at 253 > byte (for the attribute payload) boundary rather than LF or some > other attribute specific delimiter, I think this would have the > advantage of > * same & simple logic for concatenation/splitting of any=20 > suitable RADIUS attribute of length > 255 > * packing efficiency in the message, though not a principal concern This simple concatenation/splitting works when you need to include a single, potentially long data item (e.g. EAP-Message) in a RADIUS message. But it gets complex if you need to include multiple, potentially long data items of the same type (in this case, individual filter rules) and you need to maintain the boundaries between the individual data items somehow. In particular, if we decide to support individual filter rules longer than 253 characters, it looks like a RADIUS-to-Diameter translation agent will need code specific to NAS-Filter-Rule no matter how we choose to do the concatenation/splitting on the RADIUS side. The difference is just how complex that code needs to be (e.g., is it sufficient just to recognize "LF", or understand the full filter rule syntax). Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 03 Jul 2006 10:04:21 +0000 Date: Mon, 03 Jul 2006 15:31:34 +0530 From: Rajith R Subject: RE: Issue: Attribute concatenation/splitting To: Pasi.Eronen@nokia.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org Reply-to: rajithr@huawei.com Message-id: <000501c69e87$ab3022f0$a905120a@china.huawei.com> Organization: huawei MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT AFAIK, splitting & concatenation are necessitated by the 255 byte limit for RADIUS attributes. So it would be better to split at 253 byte (for the attribute payload) boundary rather than LF or some other attribute specific delimiter, I think this would have the advantage of * same & simple logic for concatenation/splitting of any suitable RADIUS attribute of length > 255 * packing efficiency in the message, though not a principal concern ************************************************************************ **** This e-mail and attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient's) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: owner-radiusext@ops.ietf.org [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Monday, July 03, 2006 3:09 PM To: bernard_aboba@hotmail.com; radiusext@ops.ietf.org Subject: RE: Issue: Attribute concatenation/splitting Bernard Aboba wrote: > > >I guess this means that a single long rule can be split into multiple > >NAS-Filter-Rule attributes? > > Yes. > > >And a single NAS-Filter-Rule attribute could contain pieces > >of multiple rules? > > Yes. > > BTW, do the same issues also apply to the NAS-Filter-Rule AVP > defined in RFC 4005? As far as I can tell, no: in RFC 4005, a single AVP always contains one complete rule (long rules are not split into multiple AVPs, and one AVP never contains multiple rules). > >If so, I'd recommend separating the individual rules somehow. > > Question: Does introducing a separator into NAS-Filter-Rule > attribute complicate the translation to and from NAS-Filter-Rule > AVP? > > For example, can we have multiple filter rules in a NAS-Filter-Rule > AVP, and if so, how do we tell when one rule ends and another begins? Hmm... the translation is going to be messy no matter what, unless we remove the splitting/concatenation from the RADIUS attribute. This would make it impossible to translate rules that are longer than 253 characters... but perhaps this is not a big problem? Rules that long are probably extremely rare, and there are already situations that cannot be translated (if the total length of rules and other attributes exceeds 4096 bytes). Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.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, 03 Jul 2006 09:42:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue: Attribute concatenation/splitting Date: Mon, 3 Jul 2006 12:38:32 +0300 Message-ID: Thread-Topic: Issue: Attribute concatenation/splitting Thread-Index: AcacdZ47Yaw5jbd6TI6/slG20HE8AgCDeqAg From: To: , Bernard Aboba wrote: >=20 > >I guess this means that a single long rule can be split into multiple > >NAS-Filter-Rule attributes? >=20 > Yes. >=20 > >And a single NAS-Filter-Rule attribute could contain pieces=20 > >of multiple rules? >=20 > Yes. >=20 > BTW, do the same issues also apply to the NAS-Filter-Rule AVP=20 > defined in RFC 4005? As far as I can tell, no: in RFC 4005, a single AVP always contains one complete rule (long rules are not split into multiple AVPs, and one AVP never contains multiple rules). > >If so, I'd recommend separating the individual rules somehow. >=20 > Question: Does introducing a separator into NAS-Filter-Rule > attribute complicate the translation to and from NAS-Filter-Rule > AVP? >=20 > For example, can we have multiple filter rules in a NAS-Filter-Rule=20 > AVP, and if so, how do we tell when one rule ends and another begins? Hmm... the translation is going to be messy no matter what, unless we remove the splitting/concatenation from the RADIUS attribute. This would make it impossible to translate rules that are longer than 253 characters... but perhaps this is not a big problem?=20 Rules that long are probably extremely rare, and there are already situations that cannot be translated (if the total length of rules and other attributes exceeds 4096 bytes). Best regards, Pasi -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: