Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 Jan 2005 23:31:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: re: Issue 37: Merging of Filter Attributes Date: Mon, 31 Jan 2005 15:30:30 -0800 Message-ID: Thread-Topic: re: Issue 37: Merging of Filter Attributes Thread-Index: AcThh1ojyncqXt7AQxOQXp9SpGdRiQAp/rHgAACUDSAAJUIBUAfpMNCQACg95DABN84JwAAATEBw From: "Sanchez, Mauricio (PNB Roseville)" To: =20 Dave Nelson and other argue over... >=20 > > "Filter-ID and NAS-Filter-Rule both define how filters are to be > applied > > in the NAS. They both should not appear in the same message and only > one > > of them should be processed. If Filter-ID is present, it > should take > > precedence. Furthermore, multiple Filter-ID attributes may appear in > the > > same Radius message. It is unclear how implementations should > process > > these multiple attributes. Some implementation may append > them to one > > another; others may select only a single attribute to > process. This > > document recommends that all recognized Filter-ID attributes be > appended > > to one another in the order they appear in the message." >=20 > I would recommend omitting the last sentence. This tends to have the=20 > effect of updating RFC2865 and adding new normative requirements. I have no qualms in removing the last sentence as long as we all agree that this is indeed input that should be further discussed in the RADIUS Issues and Fixes document. We were hoping to bring some clarity to what we saw as an issue, but if this document is not the right forum, then so be it. Therefore, the additional description to section 2.7 NAS-Filter Rule would read: "Filter-ID and NAS-Filter-Rule both define how filters are to be applied in the NAS. They both should not appear in the same message and only one of them should be processed. If Filter-ID is present, it should take precedence. Furthermore, multiple Filter-ID attributes may appear in the same Radius message. It is unclear how implementations should process these multiple attributes. Some implementation may append them to one another; others may select only a single attribute to process."=20 MS -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 21:33:13 +0000 Date: Mon, 31 Jan 2005 13:32:50 -0800 (PST) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: "'Murtaza Chiba'" , john.loughney@nokia.com, radiusext@ops.ietf.org Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > This discussion has brought to light something that doesn't make > sense to me. The Request Authenticators calculated differently in > Access-Requests and Accounting-Requests, but I don't understand why > (& I can't believe I didn't notice this before). RFC 2866 says "Note > that the Request Authenticator of an Accounting-Request can not be > done the same way as the Request Authenticator of a RADIUS > Access-Request, because there is no User-Password attribute in an > Accounting-Request." The problem is, while the "encryption" > technique used for the User-Password Attribute depends upon the > Request Authenticator, the dependency is not, as far as I can tell, > mutual. Maybe someone can explain this? I think it came up because in RFC 2865 Access-Requests are authenticated via the User-Password attribute (Message-Authenticator wasn't required). RFC 2866 wanted both Accounting-Requests and Accounting-Responses to be authenticated, so they couldn't re-use the RFC 2865 scheme, since no User-Password attribute would be included in the Accounting-Request. Message-Authenticator didn't exist at the time (it was defined in RFC 2869), so they changed the definition of the Request Authenticator in the Accounting-Request. In this particular case, RFC 3576 documented the existing practice, which copied RFC 2866. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 20:31:54 +0000 Date: Mon, 31 Jan 2005 15:25:05 -0500 From: Barney Wolff To: "Glen Zorn (gwz)" Cc: "'Bernard Aboba'" , "'Murtaza Chiba'" , john.loughney@nokia.com, radiusext@ops.ietf.org Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator Message-ID: <20050131202505.GA395@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Mon, Jan 31, 2005 at 11:59:51AM -0800, Glen Zorn (gwz) wrote: > > This discussion has brought to light something that doesn't make > sense to me. The Request Authenticators calculated differently in > Access-Requests and Accounting-Requests, but I don't understand why > (& I can't believe I didn't notice this before). RFC 2866 says "Note > that the Request Authenticator of an Accounting-Request can not be > done the same way as the Request Authenticator of a RADIUS > Access-Request, because there is no User-Password attribute in an > Accounting-Request." The problem is, while the "encryption" > technique used for the User-Password Attribute depends upon the > Request Authenticator, the dependency is not, as far as I can tell, > mutual. Maybe someone can explain this? I believe the reasoning, which I present without endorsing, is that the receiver of an Access-Request with User-Password can verify that the sender knows the shared-secret, since the User-Password will not decrypt correctly otherwise. Thus the Request Authenticator (a misnomer in this case) can be a nonce. Implicit in this design choice is the assumption that the cost of responding to bogus Access-Requests is less than the cost of doing some validation on every Access-Request of heavier weight than simply checking the source IP. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 Jan 2005 20:00:34 +0000 Message-Id: <200501311959.j0VJxqPm020259@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" , "'Murtaza Chiba'" Cc: , Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator Date: Mon, 31 Jan 2005 11:59:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcUHV1kzsd7JQxFDRPaK1fyP0wDRtAAdcSNg Bernard Aboba <> supposedly scribbled: > In looking through the Attribute table in RFC 3576, Section 3.2, > there appears to be two attributes that depend on the Request > Authenticator: > Message-Authenticator (80), and Tunnel-Password (69). > > If the desire were to change the value of the Tunnel-Password > attribute or any other attribute depending on the Request > Authenticator, one way to get around the chicken-egg problem would be > to send a CoA-Request with Service-Type="Authorize Only". The > encrypted attribute would not need to be present in the CoA-Request, > but could then be present in a subsequent Access-Accept, using the > existing attribute definitions. > > It would therefore appear to me that the Tunnel-Password attribute > should probably also have a "0" for its entries in the table in > Section 3.2, instead of "0-1". > > Defining a new Nonce attribute, and then re-defining existing IETF > standard attributes to use it when present in a CoA-Request seems > somewhat problematic to me. This discussion has brought to light something that doesn't make sense to me. The Request Authenticators calculated differently in Access-Requests and Accounting-Requests, but I don't understand why (& I can't believe I didn't notice this before). RFC 2866 says "Note that the Request Authenticator of an Accounting-Request can not be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password attribute in an Accounting-Request." The problem is, while the "encryption" technique used for the User-Password Attribute depends upon the Request Authenticator, the dependency is not, as far as I can tell, mutual. Maybe someone can explain this? > > > On Sun, 30 Jan 2005, Murtaza Chiba wrote: > >> Bernard, >> Sounds good. Somewhat related, there are Vendor attributes that are >> encrypted, although we want to discourage per attribute encryption, >> the fact of the matter is that Customers are using it. So I would >> like to request a new attribute Initialization-Vector that can be >> used for all encrypted attributes in CoA and Disconnect Messages. >> >> Regards, >> Murtaza >> >> john.loughney@nokia.com wrote: >>> Bernard, >>> >>> I agree with your proposal. >>> >>> John 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, 31 Jan 2005 20:00:26 +0000 Message-Id: <200501311959.j0VJxqPn020259@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" , Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator Date: Mon, 31 Jan 2005 11:59:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcUFmtvCYfillNVsQCywm6gusjMA/wCLEYKw Bernard Aboba <> supposedly scribbled: > RFC 3576 calculation of the Request and Response Authenticator is > modelled after RFC 2866 (RADIUS Accounting). However, the > Message-Authenticator attribute is not allowed in Accounting-Request > and Accounting-Response messages, because these messages do not > contain a random Request Authenticator, as specified in RFC 3579: > > Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, > Request Authenticator, Attributes) The word "random" is not present in RFC 3579; therefore it's hard to see how one can claim that a random Request Authenticator is "specified" thereby. Maybe a better phrase would be "tacitly assumed by the authors"? In any case, however, I agree that the use of the accounting-style Request Authenticator in the generation of the Message-Authenticator Attribute is probably inappropriate. > > It therefore would appear that a Message-Authenticator attribute is > not allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, > Disconnect-ACK or Disconnect-NAK messages. > > This is contrary to the table in Section 3.2, which has the following > entry for both CoA and Disconnect messages: > > Request ACK NAK # Attribute > 0-1 0-1 0-1 80 Message-Authenticator > > Proposed Resolution: > > My proposal is that we submit an errata to RFC 3576, changing the > "0-1" > entries to "0" entries. Given the existence of the above-mentioned and undocumented assumption in RFC 3579 and the effect that the absence of the Message-Authenticator Attribute on the already less-than-stellar security properties of RFC 3576, I think that more than just a change in a table is required. For example, the usage of the Event-Timestamp for replay detection in 3576 would seem to be weakened. I really think that the assumption in RFC 3579 needs to be laid bare; I'm not sure whether an erratum is sufficient for this or if an applicability statement needs to be published. 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, 31 Jan 2005 05:38:54 +0000 Date: Sun, 30 Jan 2005 21:38:20 -0800 (PST) From: Bernard Aboba To: Murtaza Chiba cc: john.loughney@nokia.com, radiusext@ops.ietf.org Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In looking through the Attribute table in RFC 3576, Section 3.2, there appears to be two attributes that depend on the Request Authenticator: Message-Authenticator (80), and Tunnel-Password (69). If the desire were to change the value of the Tunnel-Password attribute or any other attribute depending on the Request Authenticator, one way to get around the chicken-egg problem would be to send a CoA-Request with Service-Type="Authorize Only". The encrypted attribute would not need to be present in the CoA-Request, but could then be present in a subsequent Access-Accept, using the existing attribute definitions. It would therefore appear to me that the Tunnel-Password attribute should probably also have a "0" for its entries in the table in Section 3.2, instead of "0-1". Defining a new Nonce attribute, and then re-defining existing IETF standard attributes to use it when present in a CoA-Request seems somewhat problematic to me. On Sun, 30 Jan 2005, Murtaza Chiba wrote: > Bernard, > Sounds good. Somewhat related, there are Vendor attributes that are > encrypted, although we want to discourage per attribute encryption, the > fact of the matter is that Customers are using it. So I would like to > request a new attribute Initialization-Vector that can be used for all > encrypted attributes in CoA and Disconnect Messages. > > Regards, > Murtaza > > john.loughney@nokia.com wrote: > > Bernard, > > > > I agree with your proposal. > > > > John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 31 Jan 2005 00:54:43 +0000 Message-ID: <41FD81C2.9080806@cisco.com> Date: Sun, 30 Jan 2005 16:54:26 -0800 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) MIME-Version: 1.0 To: john.loughney@nokia.com CC: aboba@internaut.com, radiusext@ops.ietf.org Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard, Sounds good. Somewhat related, there are Vendor attributes that are encrypted, although we want to discourage per attribute encryption, the fact of the matter is that Customers are using it. So I would like to request a new attribute Initialization-Vector that can be used for all encrypted attributes in CoA and Disconnect Messages. Regards, Murtaza john.loughney@nokia.com wrote: > Bernard, > > I agree with your proposal. > > John > > >>-----Original Message----- >>From: owner-radiusext@ops.ietf.org >>[mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba >>Sent: 29 January, 2005 02:37 >>To: radiusext@ops.ietf.org >>Subject: [Issue] RFC 3576 Usage of Message-Authenticator >> >> >>RFC 3576 calculation of the Request and Response >>Authenticator is modelled >>after RFC 2866 (RADIUS Accounting). However, the >>Message-Authenticator >>attribute is not allowed in Accounting-Request and Accounting-Response >>messages, because these messages do not contain a random Request >>Authenticator, as specified in RFC 3579: >> >> Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, >> Request Authenticator, Attributes) >> >>It therefore would appear that a Message-Authenticator >>attribute is not >>allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, >>Disconnect-ACK or Disconnect-NAK messages. >> >>This is contrary to the table in Section 3.2, which has the following >>entry for both CoA and Disconnect messages: >> >> Request ACK NAK # Attribute >> 0-1 0-1 0-1 80 Message-Authenticator >> >>Proposed Resolution: >> >>My proposal is that we submit an errata to RFC 3576, changing >>the "0-1" >>entries to "0" entries. >> >>-- >>to 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: Sun, 30 Jan 2005 20:20:32 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator Date: Sun, 30 Jan 2005 22:16:57 +0200 Message-ID: Thread-Topic: [Issue] RFC 3576 Usage of Message-Authenticator Thread-Index: AcUFmvQhOwy2ff8zSKazaGvh82PSAQBbabxw From: To: , Bernard, I agree with your proposal. John > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org]On Behalf Of ext Bernard Aboba > Sent: 29 January, 2005 02:37 > To: radiusext@ops.ietf.org > Subject: [Issue] RFC 3576 Usage of Message-Authenticator >=20 >=20 > RFC 3576 calculation of the Request and Response=20 > Authenticator is modelled > after RFC 2866 (RADIUS Accounting). However, the=20 > Message-Authenticator > attribute is not allowed in Accounting-Request and Accounting-Response > messages, because these messages do not contain a random Request > Authenticator, as specified in RFC 3579: >=20 > Message-Authenticator =3D HMAC-MD5 (Type, Identifier, Length, > Request Authenticator, Attributes) >=20 > It therefore would appear that a Message-Authenticator=20 > attribute is not > allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, > Disconnect-ACK or Disconnect-NAK messages. >=20 > This is contrary to the table in Section 3.2, which has the following > entry for both CoA and Disconnect messages: >=20 > Request ACK NAK # Attribute > 0-1 0-1 0-1 80 Message-Authenticator >=20 > Proposed Resolution: >=20 > My proposal is that we submit an errata to RFC 3576, changing=20 > the "0-1" > entries to "0" entries. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 29 Jan 2005 00:38:23 +0000 Date: Fri, 28 Jan 2005 16:37:12 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: [Issue] RFC 3576 Usage of Message-Authenticator Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII RFC 3576 calculation of the Request and Response Authenticator is modelled after RFC 2866 (RADIUS Accounting). However, the Message-Authenticator attribute is not allowed in Accounting-Request and Accounting-Response messages, because these messages do not contain a random Request Authenticator, as specified in RFC 3579: Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) It therefore would appear that a Message-Authenticator attribute is not allowed in CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK or Disconnect-NAK messages. This is contrary to the table in Section 3.2, which has the following entry for both CoA and Disconnect messages: Request ACK NAK # Attribute 0-1 0-1 0-1 80 Message-Authenticator Proposed Resolution: My proposal is that we submit an errata to RFC 3576, changing the "0-1" entries to "0" entries. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 15:48:19 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Nelson, David" Cc: radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes Date: Thu, 27 Jan 2005 10:47:43 -0500 MIME-Version: 1.0 Content-Type: text/plain Bernard wrote: > BTW, it is interesting to be finding these differences years > *after* RFC 2865 was approved as a Draft standard. Perhaps its not broken. It is what it is and people make use of it as they may - and it was probably designed that way. After all, the very nature of Filter-Id requires that there is knowledge by both party of the filters that each Id represents and as well if you you multiple filter ids the semantics of what happens. > -- > to 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 Jan 2005 02:38:18 +0000 Message-Id: <200501260238.j0Q2c0RO007133@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" , "'Nelson, David'" Cc: Subject: RE: Issue 37: Merging of Filter Attributes Date: Tue, 25 Jan 2005 18:38:00 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcUDP1ABF1RECP0MSPGyekxIynAUHwADj6uw Bernard Aboba <> supposedly scribbled: ... > > BTW, it is interesting to be finding these differences years *after* > RFC 2865 was approved as a Draft standard. I don't actually think that this is a discovery. As I recall, at least two interpretations were discussed in the RADIUS WG, David's among them and the interpretation of multiple Filter-Id Attributes was purposely left undefined. 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 Jan 2005 00:37:49 +0000 Date: Tue, 25 Jan 2005 16:37:34 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > That is why this subject might be fodder for the Issues and Fixes > document. To clarify, or at least highlight, an inadequate > specification in RFC 2865 of what to do with multiple instances of > Filter-ID. I think it might be fodder, yes. > > In my experience, implementations merge the filters in the order they > > are specified. But perhaps there are implementations that do not do > > this? > > We have implementations that treat multiple instances as Filter-ID as > alternative filters, rather than cumulative filters. The first > Filter-ID attribute having a name matching a locally defined filter is > used. The remaining ones are ignored. > > In the absence of guidance to the contrary, this is a permissible > interpretation, and I presume there might be others. Yes. Perhaps we should solicit interpretations? BTW, it is interesting to be finding these differences years *after* RFC 2865 was approved as a Draft standard. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 00:15:31 +0000 Message-Id: <200501260015.j0Q0F3RO021613@sj-core-3.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Nelson, David'" , "'Bernard Aboba'" Cc: Subject: RE: Issue 37: Merging of Filter Attributes Date: Tue, 25 Jan 2005 16:15:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcUDK+mBcsBJrA8wQraPhBngLS6CzgAAC8gQAAOK+CA= Nelson, David <> supposedly scribbled: > Bernard Aboba writes... > >> RFC 2865 doesn't have much to say on this subject, other than that >> zero or more instances of Filter-Id can be included in an >> Access-Accept. > > That is why this subject might be fodder for the Issues and Fixes > document. To clarify, or at least highlight, an inadequate > specification in RFC 2865 of what to do with multiple instances of > Filter-ID. I think that inadequacy is in the eye of the beholder: as with "terrorists" and "freedom-fighters", one man's inadequacy is another's flexibility... > >> In my experience, implementations merge the filters in the order they >> are specified. But perhaps there are implementations that do not do >> this? > > We have implementations that treat multiple instances as Filter-ID as > alternative filters, rather than cumulative filters. The first > Filter-ID attribute having a name matching a locally defined filter > is used. The remaining ones are ignored. Seems perfectly reasonable to me, and much simpler than the merging approach. For example, suppose that 2 Filter-ID attributes identify actual filters which are self-contradictory? This might not be a matter of misconfiguration, just of a Filter-ID having different meanings on different devices (switch vs. AP, for example. > > In the absence of guidance to the contrary, this is a permissible > interpretation, and I presume there might be others. 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 Jan 2005 22:28:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 37: Merging of Filter Attributes Date: Tue, 25 Jan 2005 17:27:18 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190C3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 37: Merging of Filter Attributes Thread-Index: AcUDK+mBcsBJrA8wQraPhBngLS6CzgAAC8gQ From: "Nelson, David" To: "Bernard Aboba" Cc: Bernard Aboba writes... > RFC 2865 doesn't have much to say on this subject, other than that=20 > zero or more instances of Filter-Id can be included in an=20 > Access-Accept. That is why this subject might be fodder for the Issues and Fixes document. To clarify, or at least highlight, an inadequate specification in RFC 2865 of what to do with multiple instances of Filter-ID. > In my experience, implementations merge the filters in the order=20 > they are specified. But perhaps there are implementations that do=20 > not do this? We have implementations that treat multiple instances as Filter-ID as alternative filters, rather than cumulative filters. The first Filter-ID attribute having a name matching a locally defined filter is used. The remaining ones are ignored. In the absence of guidance to the contrary, this is a permissible interpretation, and I presume there might be others. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 22:20:01 +0000 Date: Tue, 25 Jan 2005 14:19:10 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Does this issue exist in "merging" two or more instances of Filter-ID? RFC 2865 doesn't have much to say on this subject, other than that zero or more instances of Filter-Id can be included in an Access-Accept. In my experience, implementations merge the filters in the order they are specified. But perhaps there are implementations that do not do this? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 25 Jan 2005 18:40: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: Issue 37: Merging of Filter Attributes Date: Tue, 25 Jan 2005 13:40:20 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190C0@MAANDMBX2.ets.enterasys.com> Thread-Topic: Issue 37: Merging of Filter Attributes Thread-Index: AcThh1ojyncqXt7AQxOQXp9SpGdRiQAp/rHgAACUDSAAJUIBUAfpMNCQACg95DA= From: "Nelson, David" To: Mauricio Sanchez writes... > "Filter-ID and NAS-Filter-Rule both define how filters are to be applied > in the NAS. They both should not appear in the same message and only one > of them should be processed. If Filter-ID is present, it should take > precedence. Furthermore, multiple Filter-ID attributes may appear in the > same Radius message. It is unclear how implementations should process > these multiple attributes. Some implementation may append them to one > another; others may select only a single attribute to process. This > document recommends that all recognized Filter-ID attributes be appended > to one another in the order they appear in the message." I would recommend omitting the last sentence. This tends to have the effect of updating RFC2865 and adding new normative requirements. I would further recommend that the multi-vendor interoperability questions that arise out of the way multiple instances of the Filter-ID attribute are specified (or not specified) in RFC2865 be discussed in the context of the RADIUS Issues and Fixes Draft. Is there an issue? We seem to think so, in terms of how Filter-ID specified behavior can or cannot be "merged" with NAS-Filter-Rule specified behavior. Does this issue exist in "merging" two or more instances of Filter-ID? -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 16:24:38 +0000 Message-ID: From: Avi Lior To: "'Sanchez, Mauricio (PNB Roseville)'" , radiusext@ops.ietf.org Subject: RE: Issue 38 - Ordering of filter attributes Date: Tue, 25 Jan 2005 11:24:00 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, There are two issues that need to be addressed. One is that one NAS-Filter-Rule maybe too large to fit a single RADIUS attribute; and A session may require several of these NAS attributes. Ordering is a given in RADIUS (as already described in the mail) Therefore receipient of the Access-Accept must be able to reconstruct a single NAS-Filter-Rule that extends over two or more attributes. And then you need to build the list of NAS-Filter-Rules. Note that there is no specific hint to help detect a Filter-Rule that spans over more then one attribute. For example a key word at the end that indicates that the rule is extended over the next attribute. > -----Original Message----- > From: Sanchez, Mauricio (PNB Roseville) > [mailto:mauricio.sanchez@hp.com] > Sent: Monday, January 24, 2005 5:49 PM > To: radiusext@ops.ietf.org > Subject: RE: Issue 38 - Ordering of filter attributes > > > > I'm working with Paul going through the IEEE802 draft issues. > On issue 38 it appears discussion stopped with the email > shown below. Any additional comments on this or can this be closed? > > MS > > -------------------------------------------- > Mauricio Sanchez > Network Security Architect > Procurve Networking Business > Hewlett Packard > 8000 Foothills Boulevard, ms 5555 > Roseville CA, 95747-5557 > > 916.785.1910 Tel > 916.785.1815 Fax > mauricio.sanchez@hp.com > -------------------------------------------- > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, January 03, 2005 5:04 PM > To: Congdon, Paul T (ProCurve) > Cc: Nelson, David; Joseph Salowey; edwin@rsquared.com; > Romascanu, Dan (Dan); Jari Arkko; Sanchez, Mauricio (PNB > Roseville); Black, Chuck A; Nagi_Reddy.Jonnala@alcatel.be > Subject: RE: Rough Notes from Conf Call on RADExt for IEEE 802 > > > Actually, the issue I was referencing is Issue 38: Ordering > of Filter > > Attributes. It only describes the ordering requirements of > > NAS-Filter-Rule and says nothing about different types. I > believe we > > can potentially close this issue with the following resolution that > > incorporates Alan DeKok's comments: > > > > "As per the requirements of RFC 2865, Section 2.3, if multiple > > NAS-Filter-Rule attributes are contained within an Access-Request > > or Access-Accept packet, they MUST be maintained in order. The > > attributes MUST be consecutive attributes in the packet. RADIUS > > proxies MUST NOT reorder NAS-Filter-Rule attributes. > > > > The RADIUS server can return NAS-Filter-Rule attributes in an > > Access-Accept packet. Where more than one NAS-Filter-Rule > attribute > is > > included, it is assumed that the attributes are to be concatenated > to > > form a single filter list." > > Sounds good. > > -- > to 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, 24 Jan 2005 23:29:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 37: Merging of Filter Attributes Date: Mon, 24 Jan 2005 15:28:53 -0800 Message-ID: Thread-Topic: Issue 37: Merging of Filter Attributes Thread-Index: AcThh1ojyncqXt7AQxOQXp9SpGdRiQAp/rHgAACUDSAAJUIBUAfpMNCQ From: "Sanchez, Mauricio (PNB Roseville)" To: Per the team design meeting discussion on Jan. 4 2005, issue 37 was dicussed with the tentative conclusion that Filter-ID and NAS-Filter-Rule attributes should not appear in the same RADIUS message. The primary reason is the lack of any simple methods to reconcile differences that may arise when both are present. One may attribute may say 'permit' while the other says 'deny'. Suggested addition to description of section 2.7 NAS-Filter Rule would be: "Filter-ID and NAS-Filter-Rule both define how filters are to be applied in the NAS. They both should not appear in the same message and only one of them should be processed. If Filter-ID is present, it should take precedence. Furthermore, multiple Filter-ID attributes may appear in the same Radius message. It is unclear how implementations should process these multiple attributes. Some implementation may append them to one another; others may select only a single attribute to process. This document recommends that all recognized Filter-ID attributes be appended to one another in the order they appear in the message."=20 Cheers, MS -----Original Message----- From: Congdon, Paul T (ProCurve) Sent: Tuesday, December 14, 2004 3:08 PM To: 'Bernard Aboba'; radiusext@ops.ietf.org Subject: RE: Issue 37: Merging of Filter Attributes I agree that if both of these attributes appear in the packet, they should append one another. Given that order is important (as seen in Issue 38), why wouldn't we want to indicate that a NAS-Filter-Rule can also pre-pend the Filter-ID if it appears before the Filter-ID? It seems kind of limiting to only allow NAS-Filter-Rule to follow the Filter-ID. Consider the following text... "If both Filter-ID and NAS-Filter-Rule attributes are included within an Access-Request or Access-Accept packet, the filters are appended to one another. If the filter specified by the NAS-Filter-Rule attribute appears after the filter list specified by the Filter-ID attribute, the filter is considered to be appended to the end of the filter list. If the filter specified by the NAS-Filter-Rule attribute appears before the filter list specified by the Filter-ID attribute, the filter is pre-pended to the filter list. As a result, if either of the filters specify that a packet is to be discarded, then the filter(s) specified by the other attribute can have no effect on the processing of that packet." Paul > -----Original Message----- > From: owner-radiusext@ops.ietf.org > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Monday, December 13, 2004 6:46 PM > To: radiusext@ops.ietf.org > Subject: Issue 37: Merging of Filter Attributes >=20 > Issue 37: Merging of Filter Attributes Submitter name: Bernard Aboba=20 > Submitter email address: aboba@internaut.com Date first > submitted: December 13, 2004 > Reference: > Document: Congdon-02 > Comment type: T > Priority: S > Section: 2.7 > Rationale/Explanation of issue: > Section 2.7 does not state what happens if both Filter-ID and=20 > NAS-Filter-Rule attributes are included in an Access-Accept. > How are the filters merged? >=20 > Suggest the addition of the following text: >=20 > "If both Filter-ID and NAS-Filter-Rule attributes are included within=20 > an Access-Request or Access-Accept packet, the filter specified by the > NAS-Filter-Rule attribute is considered to be appended to the end of=20 > the filter list specified by the Filter-ID attribute. >=20 > As a result, if the Filter-ID attribute specifies that a packet is to=20 > be discarded, then the filter specified by NAS-Filter-Rule can have no > effect on the processing of that packet, since it will have already=20 > been discarded prior to examination by the filter specified in=20 > NAS-Filter-Rule." >=20 >=20 > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single > line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 24 Jan 2005 23:08: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: Issue: 'key' attributes in IEEE802 draft Date: Mon, 24 Jan 2005 15:07:49 -0800 Message-ID: Thread-Topic: Issue: 'key' attributes in IEEE802 draft Thread-Index: AcUCaYYqfaEPuaSqSm2vjgyFVLbzdQ== From: "Sanchez, Mauricio (PNB Roseville)" To: Issue: Per the design team meeting on Dec. 21, 2004, there was discussion around the removal of 'key' attributes ('EAP-Master-Session-Key', 'EAP-Key-Name') out of the IEEE802 draft for fear of then requiring NIST approval.=20 Proposal: Remove said attributes from draft. Endangering the ratification of all attributes for just a couple does not seem advisable. Cheers, MS -------------------------------------------- Mauricio Sanchez Network Security Architect Procurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5555 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =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, 24 Jan 2005 22:50:05 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Issue 38 - Ordering of filter attributes Date: Mon, 24 Jan 2005 14:49:28 -0800 Message-ID: Thread-Topic: RE: Issue 38 - Ordering of filter attributes Thread-Index: AcTx+VwEf53VsWdcSVaDncnySi829wQbP/RA From: "Sanchez, Mauricio (PNB Roseville)" To: I'm working with Paul going through the IEEE802 draft issues. On issue 38 it appears discussion stopped with the email shown below. Any additional comments on this or can this be closed? MS -------------------------------------------- Mauricio Sanchez Network Security Architect Procurve Networking Business Hewlett Packard 8000 Foothills Boulevard, ms 5555 Roseville CA, 95747-5557 916.785.1910 Tel 916.785.1815 Fax mauricio.sanchez@hp.com -------------------------------------------- =20 -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com]=20 Sent: Monday, January 03, 2005 5:04 PM To: Congdon, Paul T (ProCurve) Cc: Nelson, David; Joseph Salowey; edwin@rsquared.com; Romascanu, Dan (Dan); Jari Arkko; Sanchez, Mauricio (PNB Roseville); Black, Chuck A; Nagi_Reddy.Jonnala@alcatel.be Subject: RE: Rough Notes from Conf Call on RADExt for IEEE 802 > Actually, the issue I was referencing is Issue 38: Ordering of Filter=20 > Attributes. It only describes the ordering requirements of=20 > NAS-Filter-Rule and says nothing about different types. I believe we=20 > can potentially close this issue with the following resolution that=20 > incorporates Alan DeKok's comments: > > "As per the requirements of RFC 2865, Section 2.3, if multiple > NAS-Filter-Rule attributes are contained within an Access-Request > or Access-Accept packet, they MUST be maintained in order. The > attributes MUST be consecutive attributes in the packet. RADIUS > proxies MUST NOT reorder NAS-Filter-Rule attributes. > > The RADIUS server can return NAS-Filter-Rule attributes in an > Access-Accept packet. Where more than one NAS-Filter-Rule attribute is > included, it is assumed that the attributes are to be concatenated to > form a single filter list." Sounds good. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 04:22:55 +0000 Message-ID: <11533831.1106540516341.JavaMail.root@nam.ext.nokia.com> Date: Mon, 24 Jan 2005 06:21:56 +0200 (EET) From: John Loughney To: radiusext@ops.ietf.org, farid.adrangi@intel.com Subject: RE: Response to Issue 46 - status so far Cc: aboba@internaut.com, dnelson@enterasys.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_127_13866071.1106540516332" ------=_Part_127_13866071.1106540516332 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Farid, My guess is that if someone hasn't suggested additional use-cases, then we should be OK with the current text. If anyone feels that something needs to be added, we should probably confirm working consensus before adding it to the draft. thanks, John --- Original Message --- From: "ext Adrangi, Farid" To: radiusext@ops.ietf.org CC: dnelson@enterasys.com, Bernard Aboba Date: Mon Jan 24 05:02:17 EET 2005 Subject: RE: Response to Issue 46 - status so far Based on our discussion so far, we have agreed to make the following clarification on the use-case currently included in the document. " The CUI attribute serves as an alias to the user's real identity, representing a chargeable identity as defined and provided by the home network as a supplemental or alternative information to User-Name(1). Typically the CUI represents the identity of the actual user but it may also indicate other chargeable identities such as a group of users. " To best of my knowledge, there hasn't been any other use-cases proposed to the list. We are planning to submit an update this week -- please let us know if you have any new use-cases in mind. BR, Farid On Sun, 16 Jan 2005, Adrangi, Farid wrote: > Background: > =========== > The CUI document define a new RADIUS attribute called a CUI. The CUI > functions as an handle or an alias to a user identity especially when > the more traditional user identity attributes (username) do not convey > the user identity. The draft cites one example when this happens mainly > EAP methods that hide that hide the identity. > > As per the document, the CUI is assigned a value by the home network so > that entities outside the home network, can have a handle to the user to > fulfill certain business scenarios. The document cites two cases: 1) > when an intermediary requires to ensure that a user is only logged in > once; and 2) For the purpose of billing mediation. > > To function as a handle to the user identity, it is suffice that the CUI > which is of type string contain an opaque value that is generated by the > home network. This value is an assertion by the home network that > represents a unique user in their network. The only operation that is > reasonably allowed to be performed by none home network entities on this > attribute therefore is a binary comparison. > > Are there other use-cases? > =========================- > > As instructed by David Nelson we are seeking any other use-case > scenarios that would demonstrate the need to change the content of the > CUI, that is would require non-opaqueness; Or ones that would require > semantic changes to the current document. We are not looking for use > cases that will further support the current CUI document. > > If there are such use cases, can you please respond with: "[CUI USECASE] > some title" on the list. We will look for consensus to support this > scenario. > > BR, > Farid > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: ------=_Part_127_13866071.1106540516332-- -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 03:02: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: Response to Issue 46 - status so far Date: Sun, 23 Jan 2005 19:02:17 -0800 Message-ID: Thread-Topic: Response to Issue 46 - status so far Thread-Index: AcT8XDpFMcE5scBLTeCsoyRp7HFyCQFY5hqQ From: "Adrangi, Farid" To: Cc: , "Bernard Aboba" Based on our discussion so far, we have agreed to make the following clarification on the use-case currently included in the document.=20 " The CUI attribute serves as an alias to the user's real identity, representing a chargeable identity as defined and provided by the home network as a supplemental or alternative information to User-Name(1). Typically the CUI represents the identity of the actual user but it may also indicate other chargeable identities such as a group of users.=20 " To best of my knowledge, there hasn't been any other use-cases proposed to the list. We are planning to submit an update this week -- please let us know if you have any new use-cases in mind. BR, Farid On Sun, 16 Jan 2005, Adrangi, Farid wrote: > Background: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > The CUI document define a new RADIUS attribute called a CUI. The CUI > functions as an handle or an alias to a user identity especially when > the more traditional user identity attributes (username) do not convey > the user identity. The draft cites one example when this happens mainly > EAP methods that hide that hide the identity. > > As per the document, the CUI is assigned a value by the home network so > that entities outside the home network, can have a handle to the user to > fulfill certain business scenarios. The document cites two cases: 1) > when an intermediary requires to ensure that a user is only logged in > once; and 2) For the purpose of billing mediation. > > To function as a handle to the user identity, it is suffice that the CUI > which is of type string contain an opaque value that is generated by the > home network. This value is an assertion by the home network that > represents a unique user in their network. The only operation that is > reasonably allowed to be performed by none home network entities on this > attribute therefore is a binary comparison. > > Are there other use-cases? > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= - > > As instructed by David Nelson we are seeking any other use-case > scenarios that would demonstrate the need to change the content of the > CUI, that is would require non-opaqueness; Or ones that would require > semantic changes to the current document. We are not looking for use > cases that will further support the current CUI document. > > If there are such use cases, can you please respond with: "[CUI USECASE] > some title" on the list. We will look for consensus to support this > scenario. > > BR, > Farid > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 24 Jan 2005 02:01: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: Issue 52: Review of CUI-01 -- summary of changes Date: Sun, 23 Jan 2005 18:00:52 -0800 Message-ID: Thread-Topic: Issue 52: Review of CUI-01 -- summary of changes Thread-Index: AcT127+Pojli62/DR42qJLlSQdiDrQLytYKQ From: "Adrangi, Farid" To: Cc: Hi Bernard, Please see a summary of fixes/changes below inline - as per our e-mail exchanges. We are planning to submit an update this week so it would be great if you tell us the fixes/changes are satisfactory. =20 I think we have addressed all of sub-issues in issue 52, except to the following: 1) On Diameter Consideration, I agree with you. Maybe we should just say : "Diameter needs to define an identical attribute with the same Type value." but which Diameter application? =20 2) On RADIUS capabilities, I think we all agree on the benefit of having a capabilities attribute. There has been a few solution proposals along with some discussions - I hope we can work together to come up with a reasonable solution. In the mean time, I will not make any changes to the current advertisement method (i.e., including a nul CUI in Access-Request) -- I also think we should capture and track this issue as a separate issue. Thanks for your time for reviewing the draft and your excellent comments/issues - very much appreciated. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, January 08, 2005 3:42 PM > To: radiusext@ops.ietf.org > Subject: Issue 52: Review of CUI-01 >=20 >=20 > Issue 52: Review of CUI-01 > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: January 8, 2004 > Reference: > Document: CUI-01 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > Section 1 >=20 > " For example, local or intermediate networks may limit the number of > simultaneous sessions for specific users; they may require a > chargeable-user-identity in order to demonstrate willingness to pay > or otherwise limit the potential for fraud. >=20 > This implies that an authenticated and unique identity provided by > the home network should be able to be conveyed to all parties > involved in the roaming transaction for correlating the > authentication and accounting packets. >=20 > Providing a unique identity, called the Chargeable-User-Identity > (CUI) to intermediaries, is necessary to fulfill certain business > needs. This should not undermine the anonymity of the user. The > mechanism provided by this draft allows the home operator to meet > these business requirements by providing a temporary identity > representing the subscriber and at the same time protecting the > anonymity of the subscriber." >=20 > There is a tradeoff between providing an authenticated and > unique identity to all parties suitable for correlation, while also > not compromising some aspects of privacy. >=20 > Later on in Section 1.1, it is stated: >=20 > " When the home network assigns a value to > the CUI, it asserts that this value represents a user in the home > network. The assertion should be temporary. Long enough to be > useful for the external applications and not too long such that it > can be used to identify the user." >=20 > I think this paragraph helps clarify the tradeoff, so that it > should follow the paragraph above. >=20 [FA] Done. > Section 1.1 >=20 > The first two paragraphs appear like they belong better in Section 1. >=20 [FA] There were moved to section 1 with some editing: " Several organizations, including WISPr, GSMA, 3GPP, Wi-Fi Alliance, IRAP, have been studying mechanisms to provide roaming services, using RADIUS. One missing element is a mechanism for providing the current deployments with the capacity to deploy, bill and oversee WPA networks against fraud. The CUI attribute is intended to close operational loopholes in RADIUS specifications that have impacted roaming solutions negatively, especially when tunneled protocols with multiple identities, such as PEAP or TTLS, are used. =20 Use of the CUI is geared to multi-identity EAP authentications which are, for the most part, recent deployments. A chargeable identity reflecting the user profile authenticated by the home network is needed in such roaming scenarios. " > "A mechanism for providing the current deployments wit > the capacity to deploy, bill and oversee WPA networks against fraud." >=20 > This is not a sentence. Should this be > "One missing element is a mechanism for...." >=20 [FA] Done - please see the above edited paragraphs that moved up. > "Therefore whether a RADIUS > server/proxy or client accepts or rejects the presence or lack of > presence of the CUI attribute is a matter of business policy." >=20 > This statement appears to come out of the blue. We are just > getting into a discussion of usage scenarios, and suddenly > we jump to a discussion which appears to be about backward > compatibility. I'd suggest you move this sentence later > in the document where it may be better put in context. >=20 [FA] This paragraph was moved to section 2.1. It was combined with the second paragraph in section 2.1, as below: " The RADIUS server (a RADIUS proxy, home RADIUS server) may include the CUI attribute in the Access-Accept message destined to a roaming partner. The CUI support by RADIUS infrastructure is driven by the business requirements between roaming entities. Therefore whether a RADIUS server/proxy or client accepts or rejects the presence or lack of presence of the CUI attribute is a matter of business policy. " > "Additionally, > there could be multiple class attributes in a RADIUS packet with > unspecified ordering, which makes it hard to the entities outside > home network to determine which one contains the CUI." >=20 > RFC 2865 does specify that attributes of the same type are not > reordered by proxies, so I don't think ordering is an issue. > The problem is opacity, which would occur whether a single > Class attribute was used, or multiple attributes. My > recommendation is to delete this sentence. [FA]=20 You are right that 2865 does specify the ordering of class. But it is still an issue. =20 An intermediary receives an list of class attributes:=20 If the home network inserted once class attributes then the intermediary can assume that the first class attributes represents the CUI however if it did not and someone else inserted the class attribute then the next intermediary will act on the first class attribute which would not be the CUI. So the problem really stems from the fact that even though class is ordered, an intermediary cannot with certainty detect which one if any contains the CUI-like-information. So, perhaps we can fix the above sentence (as below) instead of removing it: "Additionally, there could be multiple class attributes in a RADIUS packet, and since the contents of Class attribute is not to be interpreted by clients, this makes it hard to the entities outside home network to determine which one contains the CUI." >=20 > " The home network could use User-Name(1) in the Access-Accept > message to convey the CUI to intermediaries and the=20 > NAS. However, > as the Access-Accept packet is routed to the NAS, the=20 > User-Name(1) > attribute could be (completely) rewritten by an intermediary and > therefore the NAS or other intermediaries along the way will not > have access to the CUI. Furthermore, the NAS may use=20 > the original > value of the User-Name(1) attribute (the one sent in the > Access-Request packet) in the Accounting-Request=20 > packets to ensure > the billing follows the same path as authentication packets." >=20 > To my knowledge, existing implementations do not rewrite a User-Name > attribute sent in an Access-Accept, since a proxy-state attribute > can be used to enable routing of the Access-Accept back to the NAS > without examining the User-Name attribute. So the issue is not > rewriting so much as the potential impact on routing of accounting > packets. For example, the original "privacy" NAI in the > EAP-Response/Identity might have been: > example.com!@isp.com. >=20 > This is rewritten by isp.com to "@example.com". As a result, > the example.com RADIUS server may not even be aware of isp.com > as an intermediary, and might send a User-Name attribute in the > Access-Accept of "2388484848@example.com". However, without > decoration, the resulting Accounting-Request would be routed > differently than the Access-Request, which might cause problems. > Section 2.1 >=20 [FA] Based on our email exchanges on this thread, I agree your proposed text (with some minor modification/editing):=20 " The User-Name(1) attribute included in the Access-Request may be used for the purpose of request routing, and in the process may be rewritten by intermediaries. As a result, a RADIUS server receiving an Access-Request packet relayed by a proxy cannot assume that the User-Name(1) attribute remained unmodified. On the other hand, rewriting of a User-Name(1) attribute sent within an Access-Accept packet occurs more rarely, since a Proxy-State(33) attribute can be used to route the Access-Accept packet without parsing the User-Name(1) attribute. As a result, a RADIUS server cannot assume that a proxy stripping routing information from a User-Name(1) attribute within an Access-Request will add this information to a User-Name(1) attribute included within an Access-Accept. The result is that when a User-Name(1) attribute is sent in an Access-Accept it is possible that the Access-Request and Accounting-Request packets will follow different paths. Where this outcome is undesirable, the RADIUS client should use the original User-Name(1) in accounting packets. Therfore, another mechanism is required to convey a CUI within an Access-Accept message to the RADIUS client, so that the CUI can be included in the accounting packets. " > "RADIUS clients (proxy or NAS) outside > the home network MUST NOT modify the CUI attribute." >=20 > I think you want to say that RADIUS proxies MUST NOT modify the CUI > attribute, and that NAS devices that support CUI MUST include=20 > it in the > Accounting-Request unmodified, no? [FA] We mean both proxies and NAS. And you are right about the inclusion of the CUI in the accounting packets, and we mention that couple of paragraphs below in section 2.1. In summary, we are not requesting some behavior *other* than having proxies leave the CUI alone and having NAS devices include it in the Accounting-Request. >=20 > " RADIUS client (Proxy or NAS) that does not support the CUI=20 > attribute > MAY ignore this attribute or MAY treat the Access-Accept as > Access-Reject." >=20 > Rather than including this paragraph, I would cite RFC 2865=20 > with respect > to behavior on receipt of an unimplemented attribute in an=20 > Access-Accept. > That way you are guaranteed not to be updating RFC 2865. > For example, RFC 2865 only indicates that an Access-Accept > is treated as an Access-Reject if the service cannot be provided. > This would require a different value of the Service-Type attribute, > which is not used here. So the statement above represents a major > change to RFC 2865, which is already a Draft Standard. >=20 [FA] Right. The paragraph was reworked as below: " RFC 2865 includes the following statements about behaviors of RADIUS client and server with respect to unsupported attributes: "A RADIUS client MAY ignore Attributes with an unknown Type." and "A RADIUS server MAY ignore Attributes with an unknown Type.". Therefore, RADIUS client or server that does not support the CUI attribute MAY ignore this attribute. " > " If RADIUS client (Proxy or NAS) requires the presence of the CUI > attribute in the Access-Accept, it MUST indicate its requirement by > including this attribute with a nul character for its data field > (hereafter, it is also referred to as a nul CUI) in the > Access-Request message." >=20 > A cleaner approach might be to include a Capabilities > attribute including the Type codes of (standard) attributes > that the NAS is advertising support for. That way a single > attribute could be used to advertise support for up to 253 > attributes. >=20 [FA] I think we all agree on the benefit of having a capabilities attribute. There has been several solution proposals, that I hope we can work together to come up with a reasonable solution. In the mean time, I will not make any changes to the document on this -- and I think we should capture and track this as a separate issue. > " If the NAS supports CUI attribute then the CUI attribute=20 > MAY also be > used as one of the identity attribute in Disconnect Message and > Change of Authorization messages defined by [RFC3576]. =20 > Determination > of NAS support for the CUI is outside the scope of this document." >=20 > I don't think this is a good idea. There is already an issue in > translation of RFC 3576 messages into equivalent > Diameter messages and this is going to make it harder. > In retrospect, we probably should have been more > strict with respect to identification in RFC 3576, > such as requiring the Session-Id as a unique identifier. [FA] As per our e-mail discussions, we agreed to remove this. So, it was removed. >=20 > Section 3 >=20 > 0 0 0-1 0 0 101 Error-Cause >=20 > This would seem to be updating RFC 3579 and RFC 3576. Please=20 > delete this > line. >=20 [FA] Removed. > Section 4 >=20 > " In deployments with both RADIUS and Diameter interworking, a > translation agent will be deployed and operate in accordance to the > NASREQ specification." >=20 > Why is translation required? Shouldn't Diameter just define=20 > an identical > attribute with the same Type value? And isn't CUI used in applications > other than NASREQ, such as EAP? >=20 [FA] See your point. Maybe we should just say: "Diameter needs to define an identical attribute with the same Type value." but which Diameter application??=20 > Section 5.2 >=20 > " This document instructs IANA to assign a new Error-Cause attribute > [RFC3576]," >=20 > Since the attribute already exists, I think you want a new Error-Cause > value. >=20 [FA] "This document instructs IANA to assign a new value for Error-Cause attribute [RFC3576], ..." > Section 6 >=20 > " The CUI attribute must be protected against Man-in-the-Middle > attacks. The CUI appears in Access-Accept and Accounting-Requests > packets and is protected by the mechanisms that are defined for > RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional > security considerations beyond those already identified in=20 > [RFC2865] > and [RFC2866]. >=20 > Message-Authenticator(80) and Event-Timestamp(55) can be used to > further protect against Man-in-the-middle attacks. >=20 > It is strongly recommended that the CUI form used is such that the > real user identity is not revealed. Furthermore, where a reference > is used to a real user identity, the binding lifetime of that > reference to the real user be kept as short as possible." >=20 > I think you really mean that you would like to protect > RADIUS packets including CUI against modification. Even > though the draft prohibits modification of the CUI attribute > by proxies, there is no way to prevent this, really. >=20 > Message-Authenticator and Event-Timestamp attributes don't > protect against man-in-the-middle (e.g. rogue proxies), they > protect against modification and replay, respectively. >=20 [FA] Okay, how about the revised text for the security section, as below? " It is strongly recommended that the CUI form used is such that the real user identity is not revealed. Furthermore, where a reference is used to a real user identity, the binding lifetime of that reference to the real user be kept as short as possible. The RADIUS entities (RADIUS proxies and clients) outside the home network MUST NOT modify the CUI. However, there is no way to detect or prevent this. If the NAS includes CUI in an Access-Request. A man in the middle may remove the CUI attribute from the Access-Request. The result is that the Access-Accept will not have a CUI which will cause the NAS to reject the session resulting in a DOS attack. To prevent this attack, the NAS SHOULD include Message-Authenticator(80) in the Access-Request packets that contain a CUI. " Please note that the last paragraph will change once we decide on using capabilities attribute. > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=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, 22 Jan 2005 08:42:18 +0000 Message-Id: <41EF920D.2060808@piuha.net> Date: Thu, 20 Jan 2005 13:12:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Proposal: Capabilities Attribute Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that we need a capabilities function. But I would like to see a relatively coarse granularity facility, rather than something that sends data about individual attributes. For instance, I liked the list that someone made up about prepaid, filtering capability, redirection, etc. The right granularity to me appears to roughly one RFC. I say roughly because I do want to prepare for the possibility that, say, prepaid has a small number of different profiles*. And yes, there can be capabilities that don't map nicely to new attributes. There seems to be a few different kinds of capabilities negotiation, by the way. In Diameter, for instance, we have hop-by-hop negotiation. The primary purpose of this scheme is to ensure to provide information for routing purposes. But another type of negotiation is something that occurs end-to-end with a specific home system, and this is what we attempt to address in the various proposals right now. The primary purpose of this is to ensure whether we can send an attribute or command or expect a behavior relating to this specific user's session. The difference between the two approaches is that even if you know next-hop wise that FOO is supported, you don't know if FOO is supported for the particular user's session at a particular home domain. Note that the end-to-end negotiation is typically limited to the capabilities of the server that you currently talk to; it may well be that even if FOO doesn't exist on the authentication server it might exist on the accounting server at the same domain. This part is harder to solve, so I presume we are not going to require it. Anyway, here's my strawman approach to capabilities negotiation: 1. End-to-end Capability Attribute 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Capabilities string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for end-to-end capability attribute. Length The length. Capabilities string This field contains a variable length bit string. Each bit position, if set to 1, indicates full compliance with the respective feature specification. An initial allocation of bits for different features is listed below: Bit 0 (NASREQ) Support for basic authentication and authorization service [RFC 2865, I-D.NASREQ]. Mandatory in RADIUS. Bit 1 (MOBILE IPv4) Support for Mobile IPv4 [I-D.MIPv4]. Bit 2 (PREPAID) Support for prepaid services [I-D.Prepaid-R, I-D.Prepaid-D]. Bit 3 (ACCOUNTING) Support for accounting [RFC 2866, RFC 3855]. Bit 4 (FILTER-RULE) Support for generalized filters (mandatory in Diameter nodes and optional for RADIUS nodes). Bit 5 (REDIRECT) Support for user-session redirection feature (I-D.redirect). Bit 6 (CUI) Support for the CUI functionality (I-D.CUI). Bit 7 (LOCATION) Support for the location attributes (I-D.LOC). Bit 128 (CX) Support for the 3GPP CX application. Bit 129 (Sh) Support for the 3GPP Sh application. Bit 130 (Rf/Ro) Support for the 3GPP Rf/Ro application. 2. Diameter Compatibility This attribute functions in an equivalent manner in both RADIUS and Diameter. In Diameter, the base protocol layer may fill in the attribute values automatically based on its knowledge of applications running on top of it. Note that a single bit has been allocated for a feature if it is expected that it is supported in the same manner in RADIUS and Diameter and that translation rules exist. In this situation the peer does not care whether Diameter or RADIUS is used on the other side. Otherwise, separate bits have been allocated. 3. IANA Considerations IANA should create a new name space, Capabilities Bit. The initial values in this name space include those listed in Section 1. New values in the 0-128 range can be allocated through IETF Consensus. Other values (upto 2023 i.e. 253 bytes times 8 bits) can be allocated on a First-Come First Served basis with Specification Required. --Jari *) I too dislike complexity in the prepaid scheme. But having reviewed requirements and interest from various different scenarios, I tend to agree with Avi that we can't make it simpler. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 21 Jan 2005 16:11:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16881.10612.975401.282232@gargle.gargle.HOWL> Date: Fri, 21 Jan 2005 10:10:28 -0600 From: Pete McCann To: "Beck01, Wolfgang" Cc: radiusext@ops.ietf.org Subject: draft-ietf-radext-digest-auth, Securit Considerations section This looks good, and resolves my issue. -Pete Beck01, Wolfgang writes: > Here's a proposal for the text regarding the encryption of RADIUS > which is required when accepting sips/https: > > HTTP-style clients can use TLS with server side certificates together > with HTTP-Digest authentication. Instead of TLS, IPSec can be used, > too. TLS or IPSec secure the connection while Digest Authentication > authenticates the user. The RADIUS connection can be regarded as one > leg on the path between the HTTP-style client and the HTTP-style > server. To prevent the RADIUS link from being the weakest hop on the > path, a RADIUS client receiving an HTTP-style request via TLS or > IPSec MUST use an equally secure connection to the RADIUS server. > There are two ways to achieve this: > o the RADIUS client rejects HTTP-style requests received over TLS or > IPSec > o the operator of the RADIUS client takes actions to ensure that > RADIUS traffic is exclusively sent and received using IPSec. > When using IPSec, it MUST be set up as described [RFC3579] section > 4.2. > > > Wolfgang > > -- > T-Systems > Internet Platforms > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 21 Jan 2005 14:59:55 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE26@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: Miguel.an.garcia@nokia.com Subject: draft-ietf-radext-digest-auth; SIP-AOR Date: Fri, 21 Jan 2005 15:25:58 +0100 MIME-Version: 1.0 Content-Type: text/plain Here's a text proposal for the SIP-AOR attribute, which is relevant for the Diameter draft 2.20 SIP-AOR This attribute is for the authorization of SIP messages. Type [IANA:use 121 if possible] for SIP-AOR Length >=3 String The syntax of this attribute corresponds either to a SIP URI (with the format defined in [RFC3261] or a TEL URI (with the format defined in [RFC3966]). The RADIUS client (SIP server) uses the value found in a SIP Request-URI or a particular header field value of the SIP request to construct the SIP-AOR attribute. The selection of a Request-URI or a particular header field depends on the semantics of the SIP message and whether the SIP server is acting for originating or terminating requests. For instance, when the SIP server receives an REGISTER request addressed from the served user, it maps the To header field value of the SIP request to this attribute. However, when the SIP server receives an INVITE request originated by the served user, it maps either the P-Asserted-Identity or the From header field values to this attribute. This attribute MUST only be used when the RADIUS client wants to authorize SIP users and MUST only be used in Access-Request messages. Wolfgang -- T-Systems Business Unit Technologiezentrum +49 6151 9372863 Am Kavalleriesand 3 64295 Darmstadt -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 14:56:28 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE25@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: mccap@lucent.com Subject: draft-ietf-radext-digest-auth, Securit Considerations section Date: Fri, 21 Jan 2005 15:22:50 +0100 MIME-Version: 1.0 Content-Type: text/plain Here's a proposal for the text regarding the encryption of RADIUS which is required when accepting sips/https: HTTP-style clients can use TLS with server side certificates together with HTTP-Digest authentication. Instead of TLS, IPSec can be used, too. TLS or IPSec secure the connection while Digest Authentication authenticates the user. The RADIUS connection can be regarded as one leg on the path between the HTTP-style client and the HTTP-style server. To prevent the RADIUS link from being the weakest hop on the path, a RADIUS client receiving an HTTP-style request via TLS or IPSec MUST use an equally secure connection to the RADIUS server. There are two ways to achieve this: o the RADIUS client rejects HTTP-style requests received over TLS or IPSec o the operator of the RADIUS client takes actions to ensure that RADIUS traffic is exclusively sent and received using IPSec. When using IPSec, it MUST be set up as described [RFC3579] section 4.2. Wolfgang -- T-Systems Internet Platforms +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Fri, 21 Jan 2005 02:39:35 +0000 Date: Thu, 20 Jan 2005 18:39:01 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: IETF Internet Draft Submission Deadlines Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET. As always, all initial submissions (-00) with a filename beginning with "draft-ietf" must be approved by the appropriate WG Chair before they can be processed or announced. WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not be made available in the Internet-Drafts directory or announced, and will have to be resubmitted. Please do not wait until the last minute to submit. The Secretariat will begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET, but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts at ietf.org. FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 Jan 2005 16:38:30 +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: Proposal: Capabilities Attribute Date: Thu, 20 Jan 2005 18:37:30 +0200 Message-ID: Thread-Topic: Proposal: Capabilities Attribute Thread-Index: AcT+ZjPawmGenv+DSlWehH4G1WdkSwAP3bqwABoblZA= From: To: , , , Avi, I re-read your mail, and now realize that I completely misread your intent, so I retract my earlier mail. I sent the mail before my morning coffee so I was irony-impared. John > Avi, >=20 > Come on! >=20 > > Diameter is significantly more complex protocol then RADIUS. = Hmmmmmmm is it > > an example of a protocol with way too much complexity to be = successful in > > broad deployments, involving more than a very small number of = implementations? >=20 > I know (personally) of 15 implementations, quite a few deployed, = serving hundred > of thousands of users, so your point doesn't really hold >=20 > I think David and others are saying that complexity grafted onto a = protocol after > the fact is more complex than if it had been designed into the project = > originally. >=20 > John >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 Jan 2005 11:13:30 +0000 Message-ID: <41EF920D.2060808@piuha.net> Date: Thu, 20 Jan 2005 13:12:13 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: Proposal: Capabilities Attribute Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I agree that we need a capabilities function. But I would like to see a relatively coarse granularity facility, rather than something that sends data about individual attributes. For instance, I liked the list that someone made up about prepaid, filtering capability, redirection, etc. The right granularity to me appears to roughly one RFC. I say roughly because I do want to prepare for the possibility that, say, prepaid has a small number of different profiles*. And yes, there can be capabilities that don't map nicely to new attributes. There seems to be a few different kinds of capabilities negotiation, by the way. In Diameter, for instance, we have hop-by-hop negotiation. The primary purpose of this scheme is to ensure to provide information for routing purposes. But another type of negotiation is something that occurs end-to-end with a specific home system, and this is what we attempt to address in the various proposals right now. The primary purpose of this is to ensure whether we can send an attribute or command or expect a behavior relating to this specific user's session. The difference between the two approaches is that even if you know next-hop wise that FOO is supported, you don't know if FOO is supported for the particular user's session at a particular home domain. Note that the end-to-end negotiation is typically limited to the capabilities of the server that you currently talk to; it may well be that even if FOO doesn't exist on the authentication server it might exist on the accounting server at the same domain. This part is harder to solve, so I presume we are not going to require it. Anyway, here's my strawman approach to capabilities negotiation: 1. End-to-end Capability Attribute 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Capabilities string ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for end-to-end capability attribute. Length The length. Capabilities string This field contains a variable length bit string. Each bit position, if set to 1, indicates full compliance with the respective feature specification. An initial allocation of bits for different features is listed below: Bit 0 (NASREQ) Support for basic authentication and authorization service [RFC 2865, I-D.NASREQ]. Mandatory in RADIUS. Bit 1 (MOBILE IPv4) Support for Mobile IPv4 [I-D.MIPv4]. Bit 2 (PREPAID) Support for prepaid services [I-D.Prepaid-R, I-D.Prepaid-D]. Bit 3 (ACCOUNTING) Support for accounting [RFC 2866, RFC 3855]. Bit 4 (FILTER-RULE) Support for generalized filters (mandatory in Diameter nodes and optional for RADIUS nodes). Bit 5 (REDIRECT) Support for user-session redirection feature (I-D.redirect). Bit 6 (CUI) Support for the CUI functionality (I-D.CUI). Bit 7 (LOCATION) Support for the location attributes (I-D.LOC). Bit 128 (CX) Support for the 3GPP CX application. Bit 129 (Sh) Support for the 3GPP Sh application. Bit 130 (Rf/Ro) Support for the 3GPP Rf/Ro application. 2. Diameter Compatibility This attribute functions in an equivalent manner in both RADIUS and Diameter. In Diameter, the base protocol layer may fill in the attribute values automatically based on its knowledge of applications running on top of it. Note that a single bit has been allocated for a feature if it is expected that it is supported in the same manner in RADIUS and Diameter and that translation rules exist. In this situation the peer does not care whether Diameter or RADIUS is used on the other side. Otherwise, separate bits have been allocated. 3. IANA Considerations IANA should create a new name space, Capabilities Bit. The initial values in this name space include those listed in Section 1. New values in the 0-128 range can be allocated through IETF Consensus. Other values (upto 2023 i.e. 253 bytes times 8 bits) can be allocated on a First-Come First Served basis with Specification Required. --Jari *) I too dislike complexity in the prepaid scheme. But having reviewed requirements and interest from various different scenarios, I tend to agree with Avi that we can't make it simpler. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 04:11: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: Proposal: Capabilities Attribute Date: Thu, 20 Jan 2005 06:10:27 +0200 Message-ID: Thread-Topic: Proposal: Capabilities Attribute Thread-Index: AcT+ZjPawmGenv+DSlWehH4G1WdkSwAP3bqw From: To: , , Avi, Come on! > Diameter is significantly more complex protocol then RADIUS. Hmmmmmmm = is it > an example of a protocol with way too much complexity to be successful = in > broad deployments, involving more than a very small number of = implementations? I know (personally) of 15 implementations, quite a few deployed, serving = hundred of thousands of users, so your point doesn't really hold I think David and others are saying that complexity grafted onto a = protocol after the fact is more complex than if it had been designed into the project=20 originally. John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 20 Jan 2005 01:09: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: Proposal: Capabilities Attribute Date: Wed, 19 Jan 2005 17:09:16 -0800 Message-ID: <85ECA15B7BB46944BFD4C73AEA55482401DD68A7@cacexc07.americas.cpqcorp.net> Thread-Topic: Proposal: Capabilities Attribute Thread-Index: AcT9i1vbyDUokNg4TCSLVGmYrjhtcQBAG2Jg From: "Congdon, Paul T (ProCurve)" To: "Avi Lior" , "Barney Wolff" , > Thanx Barney. >=20 > Interms of justification. There have been at least three=20 > features in front of us the require that the home server know=20 > whether or not the NAS supports a particular capability. =20 > Prepaid, CUI, Bandwidth.=20 >=20 I think you could also add NAS-Filter-Rule to the list. 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: Wed, 19 Jan 2005 18:39:37 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Wed, 19 Jan 2005 13:39:07 -0500 MIME-Version: 1.0 Content-Type: text/plain David, > it(Prepaid) does seem to me to be an > example of a protocol with way too much complexity to be > successful in broad deployments, involving more that a very > small number of implementations. Diameter is significantly more complex protocol then RADIUS. Hmmmmmmm is it an example of a protocol with way too much complexity to be successful in broad deployments, involving more than a very small number of implementations? I don't know. As Mozart said when the King complained that his compositions had too many notes; his reply, "This composition has just the right number of notes." While I respect your personal opinion on the complexity issue and perhaps I agree in theory; Prepaid is one example to the contrary. It would be nice to reduce the number of notes but more often then not that leads to bad music or bad procols that have a zero life. Complex protocols such as Diameter and Prepaid can be successful in broad deployements. Just speaking to my personal knowledge on prepaid: Prepaid requirements have been analyized by many many engineers in 3GPP, 3GPP2, all their customers; and folks in AAA-WG and RADEXT and many other engineers who work for companies. I am sure that they are even more concerned by overlly complex requirements and protocols. The Protocol produced in the case of Diameter was reviewed by 3GPP and AAA-WG and I am sure that they were concerned about complex protocols. The AAA-WG and their solution has the "same number of notes" (more or less) as the RADIUS solution. I would tend to think that Prepaid has the right number of notes. As for implementation: both RADIUS and DIAMETER have been provided by many companies. Also we know from our meeting that many folks have implemented similar solutions and are looking for the features that Diameter and RADIUS protocols are offering. As for deployments, Prepaid as been deployed both in 3GPP and 3GPP2. And serving millions of subscribers today. Avi > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, January 18, 2005 3:35 PM > To: radiusext@ops.ietf.org > Subject: RE: Proposal: Capabilities Attribute > > > Avi Lior writes... > > > Well I think I wasn't making my point clear: > > > > > The solution we propose would allow for supporting capabilities > introduced > > by SDOs. They would simply assign a Capability number. So > no need to > hide > > your head in the sand. > > Well, I think I did understand what you were trying to say... > I just didn't agree. > > I guess I'm moderately opposed to complex protocols, with > lots of nuances in option support, sub-options, > sub-capabilities and partial compliance states. And I'm > opposed to using RADIUS to facilitate that sort of thing. > > We are not debating the issue of Prepaid Services, but since > you used it as an example, it does seem to me to be an > example of a protocol with way too much complexity to be > successful in broad deployments, involving more that a very > small number of implementations. It would be better, IMHO, > to have a few "profiles" of compliance, rather than allowing > all the conceivable scenarios. > > > -- > to 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, 18 Jan 2005 20:35: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: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 15:34:58 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190AB@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposal: Capabilities Attribute Thread-Index: AcT9m8UvgqeS0SrDT8Wd9dS+VTozFwAAD8ag From: "Nelson, David" To: Avi Lior writes... > Well I think I wasn't making my point clear: =20 > The solution we propose would allow for supporting capabilities introduced > by SDOs. They would simply assign a Capability number. So no need to hide > your head in the sand. Well, I think I did understand what you were trying to say... I just didn't agree. I guess I'm moderately opposed to complex protocols, with lots of nuances in option support, sub-options, sub-capabilities and partial compliance states. And I'm opposed to using RADIUS to facilitate that sort of thing. We are not debating the issue of Prepaid Services, but since you used it as an example, it does seem to me to be an example of a protocol with way too much complexity to be successful in broad deployments, involving more that a very small number of implementations. It would be better, IMHO, to have a few "profiles" of compliance, rather than allowing all the conceivable scenarios. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 20:35:17 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 15:35:10 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Barney, > This is exactly what I was ranting against. If you're gonna > support prepaid, either do both or don't support it. As for > command support, I might do that with virtual attributes - > we're not actually tight on attribute space, and indefinite > expansion of RADIUS makes no sense to me. Unless RADIUS > remains forever much less complex than Diameter, it loses its > justification for continued use. Well, this is up to the protocol designers and should not be a choice mandated by a poor design of a capability attribute. So in the case of prepaid (outside the IETF) there were discussions and it was decided that some prepaid clients would have different capabilities. As for > command support, I might do that with virtual attributes - That would be a hack. So why are we doing work arounds. Lets do it right. > we're not actually tight on attribute space, and indefinite > expansion of RADIUS makes no sense to me. Well I think we are tight on attributes. RADIUS Digest is adding more then a dozen attributes. There is another draft that we are wokring on that would add more then a dozen attributes. So why comeup with something that is intorducing limits. > Indefinite > expansion of RADIUS makes no sense to me. Lets not go there. > Regards, > Barney > -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 20:25:02 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Nelson, David" Cc: Avi Lior , Barney Wolff , radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 15:24:45 -0500 MIME-Version: 1.0 Content-Type: text/plain Well I think I wasn't making my point clear: Sending a list of attributes does not fully address all the requirements of a capability exchange as I pointed out. We are just thinking about CUI. Yes it seems to solve the CUI problem but what about, Dynamic Auth? How would you do that in your solution? Or prepaid where I need to know what is the supported features of the prepaid capability. It is one thing to say that it is too complex lets keep it simple, but the solution you proposed has issues with it. We are not trying to save bytes but get something that works. But even then, saving bytes does become an issue especially if the attribute is going to be huge and you would have to use lots of attributes. For example, transmitting VSA capabilities would require huge number of attributes. Since VSA space is much larger then 256 and there would be more then one dictionary. So you would say lets not worry about capabilities outside the IETF. But why hide your head in the sand. The solution we propose would allow for supporting capabilities introduced by SDOs. They would simply assign a Capability number. So no need to hide your head in the sand. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Tuesday, January 18, 2005 2:46 PM > To: Nelson, David > Cc: Avi Lior; Barney Wolff; radiusext@ops.ietf.org > Subject: RE: Proposal: Capabilities Attribute > > > > Just to be clear it's not a bit per attribute but rater a > bit (or two) > > subcapabilites. The authors of a capability will determine > which are > > the subcapabilities of their feature. Obviously we can do this for > > existing capabilities. > > I agree that this proposal is too complex. Grouping existing > attributes into "capabilities" and "sub-capabilities" seems > is not necessary, particularly if the only justification is > saving a few octets in the attribute. > > Let's keep it simple. > -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 19:49:58 +0000 Date: Tue, 18 Jan 2005 14:49:53 -0500 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Proposal: Capabilities Attribute Message-ID: <20050118194953.GA41374@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 18, 2005 at 02:03:18PM -0500, Avi Lior wrote: > > To me that is sending a sparse metrics. And also, not every capability and > or sub-capability maps to an attribute. For example, support for DM or COA > message, they are actually two command codes. It's a question for debate whether an attribute of 256/8=32 bytes is bigger or smaller than an attribute of one byte per supported attribute. I can't get terribly excited either way. > But in prepaid we need to know whether or not the NAS supports a type of > prepaid for example Volume based prepaid or Time based prepaid or both. This > does not map to an attribute but rather a value of one or more attributes. > So it is not safe to say that Capabilities and sub-capabilities map to > attributes. This is exactly what I was ranting against. If you're gonna support prepaid, either do both or don't support it. As for command support, I might do that with virtual attributes - we're not actually tight on attribute space, and indefinite expansion of RADIUS makes no sense to me. Unless RADIUS remains forever much less complex than Diameter, it loses its justification for continued use. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 19:45:58 +0000 Date: Tue, 18 Jan 2005 11:45:49 -0800 (PST) From: Bernard Aboba To: "Nelson, David" cc: Avi Lior , Barney Wolff , radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Just to be clear it's not a bit per attribute but rater a bit (or two) > subcapabilites. The authors of a capability will determine which are > the subcapabilities of their feature. Obviously we can do this for > existing capabilities. I agree that this proposal is too complex. Grouping existing attributes into "capabilities" and "sub-capabilities" seems is not necessary, particularly if the only justification is saving a few octets in the attribute. Let's keep it simple. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 19:27: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: Capabilites and Sub-capabilities -- was RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 14:26:29 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190A4@MAANDMBX2.ets.enterasys.com> Thread-Topic: Capabilites and Sub-capabilities -- was RE: Proposal: Capabilities Attribute Thread-Index: AcT9kwdu4qwk7CKWS2WKZTwm+eNF2wAABXmg From: "Nelson, David" To: "Avi Lior" , "Barney Wolff" , Avi Lior writes... > We already have these examples out there that require to know=20 > more then just capabilities but rather finer details. I don't > think we are adding unneccesary complexity. Publishing a draft that indicates a requirement for something isn't the same as obtaining WG consensus that the requirement is valid for WG work items. Hence my footnote about the various definitions of "necessary"... -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jan 2005 19:22:23 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , Avi Lior , Barney Wolff , radiusext@ops.ietf.org Subject: Capabilites and Sub-capabilities -- was RE: Proposal: Capabilitie s Attribute Date: Tue, 18 Jan 2005 14:22:11 -0500 MIME-Version: 1.0 Content-Type: text/plain See my subsequent emails. We already have these examples out there that require to know more then just capabilities but rather finer details. I don't think we are adding unneccesary complexity. For me what maybe unneccessary complexity would be using two bits to code: Not supported, Supported, and required. And that is because I didn't run into cases but I suppose CUI is one where you could use Supported and Required. > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, January 18, 2005 2:09 PM > To: Avi Lior; Barney Wolff; radiusext@ops.ietf.org > Subject: RE: Proposal: Capabilities Attribute > > > Avi Lior writes... > > > Just to be clear it's not a bit per attribute but rater a > bit (or two) > per > > subcapabilites. The authors of a capability will determine > which are > the > > subcapabilities of their feature. Obviously we can do this for > existing > > capabilities. > > I, too, question the need for, and desirability of, > "sub-capabilities". Let's not make this any more complicated > than necessary. I will define "necessary" for the purposes > of this memo as a higher burden of proof than the fact that > authors of various drafts have *claimed* that it is > "necessary". As the number of possible attribute support > states increases, the likelihood of convergence, correct > implementation and global interoperability decreases. Let's KISS. > > -- Dave > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jan 2005 19:09:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 14:08:39 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190A3@MAANDMBX2.ets.enterasys.com> Thread-Topic: Proposal: Capabilities Attribute Thread-Index: AcT9iyu4hdTFMCuOR1ifzZtg9UFuUQABRnFQ From: "Nelson, David" To: "Avi Lior" , "Barney Wolff" , Avi Lior writes... > Just to be clear it's not a bit per attribute but rater a bit (or two) per > subcapabilites. The authors of a capability will determine which are the > subcapabilities of their feature. Obviously we can do this for existing > capabilities. I, too, question the need for, and desirability of, "sub-capabilities". Let's not make this any more complicated than necessary. I will define "necessary" for the purposes of this memo as a higher burden of proof than the fact that authors of various drafts have *claimed* that it is "necessary". As the number of possible attribute support states increases, the likelihood of convergence, correct implementation and global interoperability decreases. Let's KISS. -- Dave -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jan 2005 19:03:29 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Avi Lior Cc: radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 14:03:18 -0500 MIME-Version: 1.0 Content-Type: text/plain How would you do a bit per attribute? To me that is sending a sparse metrics. And also, not every capability and or sub-capability maps to an attribute. For example, support for DM or COA message, they are actually two command codes. But in prepaid we need to know whether or not the NAS supports a type of prepaid for example Volume based prepaid or Time based prepaid or both. This does not map to an attribute but rather a value of one or more attributes. So it is not safe to say that Capabilities and sub-capabilities map to attributes. > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, January 18, 2005 1:46 PM > To: Avi Lior > Cc: radiusext@ops.ietf.org > Subject: Re: Proposal: Capabilities Attribute > > > On Tue, Jan 18, 2005 at 01:25:36PM -0500, Avi Lior wrote: > > > > Interms of justification. There have been at least three > features in > > front of us the require that the home server know whether > or not the > > NAS supports a particular capability. Prepaid, CUI, Bandwidth. > > > > Just to be clear it's not a bit per attribute but rater a > bit (or two) > > per subcapabilites. The authors of a capability will > determine which > > are the subcapabilities of their feature. Obviously we can do this > > for existing capabilities. > > I was arguing for the simplest scheme that solves > otherwise-painful problems. To me, that's a bit per *attribute*. > > I was more urgently arguing for fewer options in feature > support. To paraphrase Yoda, "Support, or do not support. > There is no partial." Consider the code and the testing > effort implied by a need to handle interacting combinations > of subfeatures. > > Regards, > Barney > -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 18:46:03 +0000 Date: Tue, 18 Jan 2005 13:45:52 -0500 From: Barney Wolff To: Avi Lior Cc: radiusext@ops.ietf.org Subject: Re: Proposal: Capabilities Attribute Message-ID: <20050118184552.GA27751@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 18, 2005 at 01:25:36PM -0500, Avi Lior wrote: > > Interms of justification. There have been at least three features in front > of us the require that the home server know whether or not the NAS supports > a particular capability. Prepaid, CUI, Bandwidth. > > Just to be clear it's not a bit per attribute but rater a bit (or two) per > subcapabilites. The authors of a capability will determine which are the > subcapabilities of their feature. Obviously we can do this for existing > capabilities. I was arguing for the simplest scheme that solves otherwise-painful problems. To me, that's a bit per *attribute*. I was more urgently arguing for fewer options in feature support. To paraphrase Yoda, "Support, or do not support. There is no partial." Consider the code and the testing effort implied by a need to handle interacting combinations of subfeatures. Regards, Barney -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 18:25:44 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 13:25:36 -0500 MIME-Version: 1.0 Content-Type: text/plain Thanx Barney. Interms of justification. There have been at least three features in front of us the require that the home server know whether or not the NAS supports a particular capability. Prepaid, CUI, Bandwidth. Just to be clear it's not a bit per attribute but rater a bit (or two) per subcapabilites. The authors of a capability will determine which are the subcapabilities of their feature. Obviously we can do this for existing capabilities. So to summarize: ================= For the capability: one octet will give us 256 capabilites. Should be okay or do we want two octets? For subcapabilites one bit: per subcapabilites. Or as you suggest: using two bits: 00 means do not support 10 means supported 11 means supported and required > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, January 18, 2005 12:38 PM > To: radiusext@ops.ietf.org > Subject: Re: Proposal: Capabilities Attribute > > > I hope every proposer of a complex attribute is prepared to > design, code, debug and support the logic necessary to react > to all possible values, in client, proxy, protocol gateway > and server. Otherwise, it becomes what in US politics is > called an "unfunded mandate". > > IMHO, anything beyond a single bit per attribute number is > overkill. But if we want to expend 2 bits, I'd opt for 1 bit > meaning "I accept this attribute" and the other meaning "I > require this attribute in an Access-Accept and if missing > will treat it as a -Reject". I would also exclude any > VSA-related functions from standard capabilities indication. > > For every perceived problem, there is a solution. But one > has to ask whether the cost of the solution is really less > than the cost of leaving the problem unsolved. > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via > the 'Net. > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jan 2005 18:23: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: Response to Issue 46 Date: Tue, 18 Jan 2005 13:21:53 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190A0@MAANDMBX2.ets.enterasys.com> Thread-Topic: Response to Issue 46 Thread-Index: AcT8XDpFMcE5scBLTeCsoyRp7HFyCQAZFMmQAAAwFzAAMcsggAAAQsvQ From: "Nelson, David" To: "Adrangi, Farid" Cc: > You have a point, David. We can add something like this to the draft: >=20 > " > The CUI represents an chargeable identity as defined by the business > relationship. Typically the CUI represents the identity of the actual > user but it may also indicate other chargeable identities such as a=20 > group of users." >=20 > Would that address your concern? That would be fine, as long as it meets with consensus. If there is a use case that demands that the CUI maintain a one-to-one mapping to real users, then this language would be problematic. OTOH, if there are no such use cases this language is preferable, as it does not make possibly unsupported assumptions. As an editorial nit, is the CUI actually defined by the business relationship? Does the CUI syntax appear in a contract for services? Or is it more accurate to say that "The CUI represents a chargeable identity as defined by the Home AAA operator, pursuant to the requirements of business relationships." ? -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 18:08:51 +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: Response to Issue 46 Date: Tue, 18 Jan 2005 10:08:17 -0800 Message-ID: Thread-Topic: Response to Issue 46 Thread-Index: AcT8XDpFMcE5scBLTeCsoyRp7HFyCQAZFMmQAAAwFzAAMcsggA== From: "Adrangi, Farid" To: "Nelson, David" Cc: You have a point, David. We can add something like this to the draft: " The CUI represents an chargeable identity as defined by the business relationship. Typically the CUI represents the identity of the actual user but it may also indicate other chargeable identities such as a group of users. " Would that address your concern? BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Nelson, David > Sent: Monday, January 17, 2005 10:24 AM > To: radiusext@ops.ietf.org > Subject: RE: Response to Issue 46=20 >=20 >=20 > Farid Adrangi writes... >=20 > > Isn't the draft say that the CUI is an alias to user's real=20 > identity? > > Doesn't that mean that there needs to be a unique mapping=20 > between CUI > > and the actual user? >=20 > Not necessisarily. The username dnelson@enterasys.com might=20 > be aliased > as engineering@enterasys.com, if the policy at Enterasys were to lump > all employees with engineering job codes into a single class for alias > identification purposes. I don't see any text that would=20 > preclude this > kind of approach. >=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: Tue, 18 Jan 2005 17:38:32 +0000 Date: Tue, 18 Jan 2005 12:38:16 -0500 From: Barney Wolff To: radiusext@ops.ietf.org Subject: Re: Proposal: Capabilities Attribute Message-ID: <20050118173816.GA27208@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i I hope every proposer of a complex attribute is prepared to design, code, debug and support the logic necessary to react to all possible values, in client, proxy, protocol gateway and server. Otherwise, it becomes what in US politics is called an "unfunded mandate". IMHO, anything beyond a single bit per attribute number is overkill. But if we want to expend 2 bits, I'd opt for 1 bit meaning "I accept this attribute" and the other meaning "I require this attribute in an Access-Accept and if missing will treat it as a -Reject". I would also exclude any VSA-related functions from standard capabilities indication. For every perceived problem, there is a solution. But one has to ask whether the cost of the solution is really less than the cost of leaving the problem unsolved. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 18 Jan 2005 16:57:20 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 11:57:16 -0500 MIME-Version: 1.0 Content-Type: text/plain Oh I forgot to mention. We started this work already in draft and we are going to move this to a stand alone draft for the next meeting. Will post soon. Thanx Avi and Farid > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, January 17, 2005 1:23 AM > To: Glen Zorn (gwz) > Cc: radiusext@ops.ietf.org > Subject: RE: Proposal: Capabilities Attribute > > > > > This Attribute includes a list of attribute types supported > > > by the client. One or more Capabilities attributes > MAY be sent > > > within an Access-Request packet. > > > > Why only client & request? > > The usage scenario I had in mind was a NAS announcing to a > server that it supported various attributes. This could be > useful, for debugging purposes (oops, I forgot to upgrade > that NAS!), or backward compatibility (server won't send a > new attribute to a NAS that doesn't support it). > > Can you describe how a server could use a Capabilities attribute? > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 16:56:24 +0000 Message-ID: From: Avi Lior To: 'Bernard Aboba' , "Glen Zorn (gwz)" Cc: radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Date: Tue, 18 Jan 2005 11:55:39 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi, We already have proposed a scheme for doing this in one of the other drafts. I will post the attribte below: The requirements as we saw them is: NAS advertizes support for a capability. Prepaid, Dynamic Auth. NAS advertizes subcapabilities of a given feature. So using prepaid as an example, you adveritze that NAS supports prepaid and also what kind of prepaid support is available. For example, Volume based, Time based, etc... Another example: Support for Dynamic Auth RFC 3576 NAS may support DM, COA (PUSH model), COA (PULL model) To Bernards design. Its almost identical to ours except that we bit encode the subcapabilities instead of pushing the dictionary to the Server. This is more efficient and in somecase a subcapability may have no attributes (see the above example for Dynamic Auth) or too many attributes. So here is what we proposed in the following (http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-ext NOTE we are thinking a much simpler layout for this attribute (same as Bernard suggested): So instead of an integer we will use a string with the first part being the capability followed by one or more octest representing bit mask for suboptions. This would make it simpler to extend. 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 | Integer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Name Generic Capability Type To be assigned by IANA Length = 6 Integer The format of this Integer is as follows: 0xCCCTSSSS Where: CCC is a 12-bit indicator that identifies the capability ID. CCC = 0x000 and 0xFFF is reserved. T is a 4-bit indicator used for extending the sub-capability space. T = 0xF is reserved. SSSS is 16-bit indicator that identifies the sub-capabilities ID. These are determined by the application writer and may represent a number of mutually exclusive sub-capabilities or mutually inclusive sub-capabilities codes as bits. Extension of sub-capabilities: T=0x0 represents the first 16 bits of sub-capabilities T=0x1 represents the next 16 bits of sub-capabilities T=0xF represents the last 16 bits of sub-capabilities The following Capability Identities are assigned by this RFC. Additional capability ids may be assigned later. See the IANA section. Note: we have to assign some capabilities from radius and also sub-capabilities. Candidates would be from RFCs 2865, 2869, 2867, 3162, 3576, 3580. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Monday, January 17, 2005 1:23 AM > To: Glen Zorn (gwz) > Cc: radiusext@ops.ietf.org > Subject: RE: Proposal: Capabilities Attribute > > > > > This Attribute includes a list of attribute types supported > > > by the client. One or more Capabilities attributes > MAY be sent > > > within an Access-Request packet. > > > > Why only client & request? > > The usage scenario I had in mind was a NAS announcing to a > server that it supported various attributes. This could be > useful, for debugging purposes (oops, I forgot to upgrade > that NAS!), or backward compatibility (server won't send a > new attribute to a NAS that doesn't support it). > > Can you describe how a server could use a Capabilities attribute? > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.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, 17 Jan 2005 18:24:29 +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: Response to Issue 46 Date: Mon, 17 Jan 2005 13:24:24 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19095@MAANDMBX2.ets.enterasys.com> Thread-Topic: Response to Issue 46 Thread-Index: AcT8XDpFMcE5scBLTeCsoyRp7HFyCQAZFMmQAAAwFzA= From: "Nelson, David" To: Farid Adrangi writes... > Isn't the draft say that the CUI is an alias to user's real identity? > Doesn't that mean that there needs to be a unique mapping between CUI > and the actual user? Not necessisarily. The username dnelson@enterasys.com might be aliased as engineering@enterasys.com, if the policy at Enterasys were to lump all employees with engineering job codes into a single class for alias identification purposes. I don't see any text that would preclude this kind of approach. -- to unsubscribe send a message to radiusext-request@ops.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, 17 Jan 2005 18:20: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: Response to Issue 46 Date: Mon, 17 Jan 2005 10:19:57 -0800 Message-ID: Thread-Topic: Response to Issue 46 Thread-Index: AcT8XDpFMcE5scBLTeCsoyRp7HFyCQAZFMmQ From: "Adrangi, Farid" To: "Bernard Aboba" Cc: , > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com]=20 > Sent: Sunday, January 16, 2005 10:17 PM > To: Adrangi, Farid > Cc: radiusext@ops.ietf.org; dnelson@enterasys.com > Subject: Re: Response to Issue 46=20 >=20 >=20 > As I understand it, this scenario cannot be handled by the User-Name > attribute when: >=20 > a) The CUI is not a valid NAI > b) It is necessary for the Authentication-Request and > Accounting-Request to traverse the same path. >=20 > Are we clear why the Class attribute couldn't be used to handle this > scenario? While RFC 2865, Section 5.25 says "The client MUST NOT > interpret the attribute locally", it doesn't say that the client can't > store the blob for the purpose of simultaneous usage comparison. > Using the class attribute as a comparison is against the intent of 2865. The client would do the comparison for a reason. Isn't that a local interpretation of the class attribute? In this case the reason would be to extract an alias for the user.=20 But even then, Servers that use the class attribute use it for their own purposes. Mainly for keeping state etc. There is no guarantee that the class attribute wouldn't change between a user's session. Therefore this overloading would create a problem for implementations. They may have to use multiple class attribute, one for the state maintaining purpose the other for the indentity alias purpose. Finally, a client may see many class attributes. Even if we allowed clients to use the class attribute as you indicated, which one should it use? =20 > I think the issue may be that the CUI is potentially usable=20 > by accounting > servers at intermediaries as well as the home accounting=20 > server. This may > imply something about the CUI, such as that there needs to be a > unique mapping between a CUI and the actual user. If so, the document > should state the requirement. >=20 Isn't the draft say that the CUI is an alias to user's real identity? Doesn't that mean that there needs to be a unique mapping between CUI and the actual user? >=20 >=20 > On Sun, 16 Jan 2005, Adrangi, Farid wrote: >=20 > > Background: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > The CUI document define a new RADIUS attribute called a=20 > CUI. The CUI > > functions as an handle or an alias to a user identity=20 > especially when > > the more traditional user identity attributes (username) do=20 > not convey > > the user identity. The draft cites one example when this=20 > happens mainly > > EAP methods that hide that hide the identity. > > > > As per the document, the CUI is assigned a value by the=20 > home network so > > that entities outside the home network, can have a handle=20 > to the user to > > fulfill certain business scenarios. The document cites two=20 > cases: 1) > > when an intermediary requires to ensure that a user is only=20 > logged in > > once; and 2) For the purpose of billing mediation. > > > > To function as a handle to the user identity, it is suffice=20 > that the CUI > > which is of type string contain an opaque value that is=20 > generated by the > > home network. This value is an assertion by the home network that > > represents a unique user in their network. The only=20 > operation that is > > reasonably allowed to be performed by none home network=20 > entities on this > > attribute therefore is a binary comparison. > > > > Are there other use-cases? > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= - > > > > As instructed by David Nelson we are seeking any other use-case > > scenarios that would demonstrate the need to change the=20 > content of the > > CUI, that is would require non-opaqueness; Or ones that=20 > would require > > semantic changes to the current document. We are not=20 > looking for use > > cases that will further support the current CUI document. > > > > If there are such use cases, can you please respond with:=20 > "[CUI USECASE] > > some title" on the list. We will look for consensus to support this > > scenario. > > > > BR, > > Farid > > >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 13:47: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: Response to Issue 46 Date: Mon, 17 Jan 2005 15:45:41 +0200 Message-ID: Thread-Topic: Response to Issue 46 Thread-Index: AcT8a+0j9tL08Ao5TL2P3zEKg5KvwQALsSpA From: To: , Cc: , , Bernard, > Bernard Aboba wrote: > > As I understand it, this scenario cannot be handled by the User-Name > > attribute when: > >=20 > > a) The CUI is not a valid NAI >=20 > Yes, although presumably pretty much anything could > be [and has been :-) ] mapped to a NAI using some > sort of a convention. I agree. > > b) It is necessary for the Authentication-Request and > > Accounting-Request to traverse the same path. >=20 > Yes. But I seem to recall that there were also other > issues in User-Name rewriting. >=20 > > Are we clear why the Class attribute couldn't be used to handle this > > scenario? While RFC 2865, Section 5.25 says "The client MUST NOT > > interpret the attribute locally", it doesn't say that the client = can't > > store the blob for the purpose of simultaneous usage comparison. >=20 > I think this one is clear -- there is no guarantee that class > attribute can be used for identity comparisons -- the equal > operator may not be defined for it, as that was never > required in the RFCs. Implementations could use something > else than a stable handle, like a pointer to an event > record in a database, portion of the contents could be > a sequence number of some kind, and so on. I agree with Jari on this. =20 John -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 08:05:18 +0000 Message-ID: <41EB7174.40707@piuha.net> Date: Mon, 17 Jan 2005 10:04:04 +0200 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 MIME-Version: 1.0 To: Bernard Aboba Cc: "Adrangi, Farid" , radiusext@ops.ietf.org, dnelson@enterasys.com Subject: Re: Response to Issue 46 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > As I understand it, this scenario cannot be handled by the User-Name > attribute when: > > a) The CUI is not a valid NAI Yes, although presumably pretty much anything could be [and has been :-) ] mapped to a NAI using some sort of a convention. > b) It is necessary for the Authentication-Request and > Accounting-Request to traverse the same path. Yes. But I seem to recall that there were also other issues in User-Name rewriting. > Are we clear why the Class attribute couldn't be used to handle this > scenario? While RFC 2865, Section 5.25 says "The client MUST NOT > interpret the attribute locally", it doesn't say that the client can't > store the blob for the purpose of simultaneous usage comparison. I think this one is clear -- there is no guarantee that class attribute can be used for identity comparisons -- the equal operator may not be defined for it, as that was never required in the RFCs. Implementations could use something else than a stable handle, like a pointer to an event record in a database, portion of the contents could be a sequence number of some kind, and so on. > I think the issue may be that the CUI is potentially usable by accounting > servers at intermediaries as well as the home accounting server. This may > imply something about the CUI, such as that there needs to be a > unique mapping between a CUI and the actual user. If so, the document > should state the requirement. Yes. --Jari -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 06:23:06 +0000 Date: Sun, 16 Jan 2005 22:23:01 -0800 (PST) From: Bernard Aboba To: "Glen Zorn (gwz)" cc: radiusext@ops.ietf.org Subject: RE: Proposal: Capabilities Attribute Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > > This Attribute includes a list of attribute types supported > > by the client. One or more Capabilities attributes MAY be sent > > within an Access-Request packet. > > Why only client & request? The usage scenario I had in mind was a NAS announcing to a server that it supported various attributes. This could be useful, for debugging purposes (oops, I forgot to upgrade that NAS!), or backward compatibility (server won't send a new attribute to a NAS that doesn't support it). Can you describe how a server could use a Capabilities attribute? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 06:17:52 +0000 Date: Sun, 16 Jan 2005 22:17:27 -0800 (PST) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org, dnelson@enterasys.com Subject: Re: Response to Issue 46 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII As I understand it, this scenario cannot be handled by the User-Name attribute when: a) The CUI is not a valid NAI b) It is necessary for the Authentication-Request and Accounting-Request to traverse the same path. Are we clear why the Class attribute couldn't be used to handle this scenario? While RFC 2865, Section 5.25 says "The client MUST NOT interpret the attribute locally", it doesn't say that the client can't store the blob for the purpose of simultaneous usage comparison. I think the issue may be that the CUI is potentially usable by accounting servers at intermediaries as well as the home accounting server. This may imply something about the CUI, such as that there needs to be a unique mapping between a CUI and the actual user. If so, the document should state the requirement. On Sun, 16 Jan 2005, Adrangi, Farid wrote: > Background: > =========== > The CUI document define a new RADIUS attribute called a CUI. The CUI > functions as an handle or an alias to a user identity especially when > the more traditional user identity attributes (username) do not convey > the user identity. The draft cites one example when this happens mainly > EAP methods that hide that hide the identity. > > As per the document, the CUI is assigned a value by the home network so > that entities outside the home network, can have a handle to the user to > fulfill certain business scenarios. The document cites two cases: 1) > when an intermediary requires to ensure that a user is only logged in > once; and 2) For the purpose of billing mediation. > > To function as a handle to the user identity, it is suffice that the CUI > which is of type string contain an opaque value that is generated by the > home network. This value is an assertion by the home network that > represents a unique user in their network. The only operation that is > reasonably allowed to be performed by none home network entities on this > attribute therefore is a binary comparison. > > Are there other use-cases? > =========================- > > As instructed by David Nelson we are seeking any other use-case > scenarios that would demonstrate the need to change the content of the > CUI, that is would require non-opaqueness; Or ones that would require > semantic changes to the current document. We are not looking for use > cases that will further support the current CUI document. > > If there are such use cases, can you please respond with: "[CUI USECASE] > some title" on the list. We will look for consensus to support this > scenario. > > BR, > Farid > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 03:52: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: Response to Issue 46 Date: Sun, 16 Jan 2005 19:51:31 -0800 Message-ID: Thread-Topic: Response to Issue 46 Thread-Index: AcT8R9TqIKGfIzBaSt+YRSSmPIeeuA== From: "Adrangi, Farid" To: Cc: , Background: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The CUI document define a new RADIUS attribute called a CUI. The CUI functions as an handle or an alias to a user identity especially when the more traditional user identity attributes (username) do not convey the user identity. The draft cites one example when this happens mainly EAP methods that hide that hide the identity. =20 As per the document, the CUI is assigned a value by the home network so that entities outside the home network, can have a handle to the user to fulfill certain business scenarios. The document cites two cases: 1) when an intermediary requires to ensure that a user is only logged in once; and 2) For the purpose of billing mediation. =20 To function as a handle to the user identity, it is suffice that the CUI which is of type string contain an opaque value that is generated by the home network. This value is an assertion by the home network that represents a unique user in their network. The only operation that is reasonably allowed to be performed by none home network entities on this attribute therefore is a binary comparison. Are there other use-cases? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= - As instructed by David Nelson we are seeking any other use-case scenarios that would demonstrate the need to change the content of the CUI, that is would require non-opaqueness; Or ones that would require semantic changes to the current document. We are not looking for use cases that will further support the current CUI document. =20 If there are such use cases, can you please respond with: "[CUI USECASE] some title" on the list. We will look for consensus to support this scenario. BR, Farid -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 17 Jan 2005 02:40:37 +0000 Message-Id: <200501170239.j0H2drW6000197@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Bernard Aboba'" , Subject: RE: Proposal: Capabilities Attribute Date: Sun, 16 Jan 2005 18:39:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcT8F6/59jEmij14RoyXygkgP+wOuQAJYf1Q Bernard Aboba <> supposedly scribbled: > Farid mentioned in his last message that we might want to move ahead > on defining a general Capabilities attribute. Here is a strawman > proposal: > > Capabilities > > Description > > This Attribute includes a list of attribute types supported by > the client. One or more Capabilities attributes MAY be sent > within an Access-Request packet. Why only client & request? > > A summary of the Capabilities 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 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Value | String.. > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Type > > TBD for Capabilities. > > Length > > >= 3 > > Value > > The Value field is one octet, falling in the range between 1 > and 253. > > String > > The String field is one or more octets. > > Where the Value field is not equal to 26, the String field > contains a list of Type values, 1 octet per Type; up to > 253 Type values may be included within each Capabilities > attribute. > > Where the Value field is equal to 26, the format of the String > field is as follows: > > 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 2 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Vendor-Id | String2... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Vendor-Id > > The Vendor-Id field is 3 octets, containing the SMI > Management Private Enterprise Code of the Vendor in > network byte order, as defined by [IANA]. > > String2 > > The String2 field is one or more octets. The actual format of > the information is site or application specific as described in > [RFC2865] Section 5.26. 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: Sun, 16 Jan 2005 22:06:43 +0000 Date: Sun, 16 Jan 2005 14:06:36 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Proposal: Capabilities Attribute Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Farid mentioned in his last message that we might want to move ahead on defining a general Capabilities attribute. Here is a strawman proposal: Capabilities Description This Attribute includes a list of attribute types supported by the client. One or more Capabilities attributes MAY be sent within an Access-Request packet. A summary of the Capabilities 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value | String.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD for Capabilities. Length >= 3 Value The Value field is one octet, falling in the range between 1 and 253. String The String field is one or more octets. Where the Value field is not equal to 26, the String field contains a list of Type values, 1 octet per Type; up to 253 Type values may be included within each Capabilities attribute. Where the Value field is equal to 26, the format of the String field is as follows: 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-Id | String2... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id The Vendor-Id field is 3 octets, containing the SMI Management Private Enterprise Code of the Vendor in network byte order, as defined by [IANA]. String2 The String2 field is one or more octets. The actual format of the information is site or application specific as described in [RFC2865] Section 5.26. -- to unsubscribe send a message to radiusext-request@ops.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, 16 Jan 2005 21:59:18 +0000 Date: Sun, 16 Jan 2005 13:58:50 -0800 (PST) From: Bernard Aboba To: "Adrangi, Farid" cc: radiusext@ops.ietf.org Subject: RE:Issue 52: Review of CUI-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > "The NAS may use the original value of the User-Name(1) attribute (the > one sent in the Access-Request packet) in the Accounting-Request packets > to ensure the billing follows the same path as authentication packets. Here is what RFC 2865, Section 5.1 says about including the User-Name attribute in the Access-Accept: " It MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session." So while a NAS does not have to include the returned User-Name attribute in subsequent Accounting-Request packets, that is not the recommended practice. > For example, the EAP peer may construct the NAI with additional > information (e.g., example.com@intermediary.com) to influence routing of > the AAA packet through a preferred intermediary network. This is > rewritten by the intermediary network (i.e., "intermediary.com" ) to > example.com . As a result, the home > RADIUS server in "example.com" may not even be aware of > "intermediary.com" and therefore sends a User-Name(1) containing CUI > (i.e., CUI @example.com > ) in the Access-Accept to the NAS. If the NAS > uses the User-Name(1) of the received Access-Accept in > Accounting-Request (as recommended by a strong SHOULD in RFC 2865), then > the resulting Accounting-Request would be routed differently than the > Access-Request, which might cause problems. I don't think you need to go into this level of detail. You can just say: "The User-Name attribute included in the Access-Request may be used for the purpose of request routing, and in the process may be rewritten by intermediaries. As a result, a RADIUS server receiving an Access-Request packet relayed by a proxy cannot assume that the User-Name attribute remained unmodified. On the other hand, rewriting of a User-Name attribute sent within an Access-Accept packet occurs more rarely, since a Proxy-State attribute can be used to route the Access-Accept packet without parsing the User-Name attribute. As a result, a RADIUS server cannot assume that a proxy stripping routing information from a User-Name attribute within an Access-Request will add this information to a User-Name attribute included within an Access-Accept. The result is that when a User-Name attribute is sent in an Access-Accept it is possible that the Access-Request and Accounting-Request packets will follow different paths. Where this outcome is undesirable, another mechanism is required to provide a billable identity within an Accounting-Request." > > I think you want to say that RADIUS proxies MUST NOT modify the CUI > > attribute, and that NAS devices that support CUI MUST include > > it in the Accounting-Request unmodified, no? > > Your statement is correct. And we say that in sectoin 2.1 -- couple of > paragraphs below. but here we are simply stating that the entities > outside the home network MUST NOT modify CUI. Are you requesting some behavior *other* than having proxies leave the CUI along and having NAS devices include it in the Accounting-Request? > You are right, so how about this? > > " > RFC 2865 states that A RADIUS server or client ignore Attributes with > an unknown Type. Therefore, RADIUS client (Proxy or NAS) that does not > support the CUI attribute MAY ignore this attribute. > " I'd suggest you quote RFC 2865, rather than paraphrasing it. > I agree. But, there is no capabilities attribute for RADUS now, and as > you know we have a proposal for capabilities attribute but no progerss > yet - we may want to accelerate this. I'll post a proposal for a Capabilities attribute to the list. > Are you implying that RADIUS has a session-id -- I wasn't aware of that. Disconnect or COA messages can only be sent after the service has been started. Therefore the Acct-Session-Id attribute can be included in either a Disconnect-Request or CoA-Request mesage in order to identify the specific session which is to be affected. See [RFC3576] Section 3.2. > I thought Glen Zorn is proposing this in one of his drafts. Anyhow, I > guess you are suggesting to remove this paragraph - yes? Yes. > NASREQ does not have this attribute. Does NASREQ automatically cover > new RADIUS attributes? CUI will not be used in EAP - unless you correct > me by describing a use-case for it. NASREQ describes how RADIUS-Diameter gateways handle translation of attributes within the standard RADIUS attribute space. A good implementation will apply that processing to new RADIUS attributes. Otherwise new code would be required in the gateway whenever a new RADIUS attribute is created, which creates maintenance headaches. -- to unsubscribe send a message to radiusext-request@ops.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, 16 Jan 2005 20:40:04 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FC0B.710F1535" Subject: RE:Issue 52: Review of CUI-01 Date: Sun, 16 Jan 2005 12:39:14 -0800 Message-ID: Thread-Topic: RE:Issue 52: Review of CUI-01 Thread-Index: AcT8C3CN7CDWpR/NTL2dhrftp9MNTQ== From: "Adrangi, Farid" To: Cc: This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FC0B.710F1535 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, Thanks for your comments/feedbacks/corrections. I agree with most of your comments -- we will incorporate them into the next version. Please see my comments inline. =20 BR, Farid =20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Saturday, January 08, 2005 3:42 PM > To: radiusext@ops.ietf.org > Subject: Issue 52: Review of CUI-01 >=20 >=20 > Issue 52: Review of CUI-01 > Submitter name: Bernard Aboba > Submitter email address: aboba@internaut.com > Date first submitted: January 8, 2004 > Reference: > Document: CUI-01 > Comment type: T > Priority: S > Section: Various > Rationale/Explanation of issue: > Section 1 >=20 > " For example, local or intermediate networks may limit the number of > simultaneous sessions for specific users; they may require a > chargeable-user-identity in order to demonstrate willingness to pay > or otherwise limit the potential for fraud. >=20 > This implies that an authenticated and unique identity provided by > the home network should be able to be conveyed to all parties > involved in the roaming transaction for correlating the > authentication and accounting packets. >=20 > Providing a unique identity, called the Chargeable-User-Identity > (CUI) to intermediaries, is necessary to fulfill certain business > needs. This should not undermine the anonymity of the user. The > mechanism provided by this draft allows the home operator to meet > these business requirements by providing a temporary identity > representing the subscriber and at the same time protecting the > anonymity of the subscriber." >=20 > There is a tradeoff between providing an authenticated and > unique identity to all parties suitable for correlation, while also > not compromising some aspects of privacy. >=20 > Later on in Section 1.1, it is stated: >=20 > " When the home network assigns a value to > the CUI, it asserts that this value represents a user in the home > network. The assertion should be temporary. Long enough to be > useful for the external applications and not too long such that it > can be used to identify the user." >=20 > I think this paragraph helps clarify the tradeoff, so that it > should follow the paragraph above. >=20 =20 Good suggestion. Will do. =20 > Section 1.1 >=20 > The first two paragraphs appear like they belong better in Section 1. >=20 =20 Makes sense - Will move it up. =20 > "A mechanism for providing the current deployments wit > the capacity to deploy, bill and oversee WPA networks against fraud." >=20 > This is not a sentence. Should this be > "One missing element is a mechanism for...." =20 yes. =20 >=20 > "Therefore whether a RADIUS > server/proxy or client accepts or rejects the presence or lack of > presence of the CUI attribute is a matter of business policy." >=20 > This statement appears to come out of the blue. We are just > getting into a discussion of usage scenarios, and suddenly > we jump to a discussion which appears to be about backward > compatibility. I'd suggest you move this sentence later > in the document where it may be better put in context. >=20 Ok. =20 > "Additionally, > there could be multiple class attributes in a RADIUS packet with > unspecified ordering, which makes it hard to the entities outside > home network to determine which one contains the CUI." >=20 > RFC 2865 does specify that attributes of the same type are not > reordered by proxies, so I don't think ordering is an issue. > The problem is opacity, which would occur whether a single > Class attribute was used, or multiple attributes. My > recommendation is to delete this sentence. =20 Ok. =20 >=20 > " The home network could use User-Name(1) in the Access-Accept > message to convey the CUI to intermediaries and the=20 > NAS. However, > as the Access-Accept packet is routed to the NAS, the=20 > User-Name(1) > attribute could be (completely) rewritten by an intermediary and > therefore the NAS or other intermediaries along the way will not > have access to the CUI. Furthermore, the NAS may use=20 > the original > value of the User-Name(1) attribute (the one sent in the > Access-Request packet) in the Accounting-Request=20 > packets to ensure > the billing follows the same path as authentication packets." >=20 > To my knowledge, existing implementations do not rewrite a User-Name > attribute sent in an Access-Accept, since a proxy-state attribute > can be used to enable routing of the Access-Accept back to the NAS > without examining the User-Name attribute. So the issue is not > rewriting so much as the potential impact on routing of accounting > packets. For example, the original "privacy" NAI in the > EAP-Response/Identity might have been: > example.com!@isp.com. >=20 =20 > This is rewritten by isp.com to "@example.com". As a result, > the example.com RADIUS server may not even be aware of isp.com > as an intermediary, and might send a User-Name attribute in the > Access-Accept of "2388484848@example.com". However, without > decoration, the resulting Accounting-Request would be routed > differently than the Access-Request, which might cause problems. > Section 2.1 >=20 =20 I think the second half of the paragraph addresses the above problem w.r.t decoration and routing. Maybe we should add an example for clarification. How about we revise the paragraph to something like this? =20 " The NAS may use the original value of the User-Name(1) attribute (the one sent in the Access-Request packet) in the Accounting-Request packets to ensure the billing follows the same path as authentication packets. For example, the EAP peer may construct the NAI with additional information (e.g., example.com@intermediary.com) to influence routing of the AAA packet through a preferred intermediary network. This is rewritten by the intermediary network (i.e., "intermediary.com" ) to example.com . As a result, the home RADIUS server in "example.com" may not even be aware of "intermediary.com" and therefore sends a User-Name(1) containing CUI (i.e., CUI @example.com ) in the Access-Accept to the NAS. If the NAS uses the User-Name(1) of the received Access-Accept in Accounting-Request (as recommended by a strong SHOULD in RFC 2865), then the resulting Accounting-Request would be routed differently than the Access-Request, which might cause problems. If the NAS uses the original NAI sent in the Access-Request, then the CUI will not be included in the Accounting-Request. Furthermore, in some deployments, as the Access-Accept packet is routed to the NAS, the User-Name(1) attribute could be (completely) rewritten by an intermediary and therefore the NAS or other intermediaries along the way will not have access to the CUI. =20 " =20 Section 2.1 > "RADIUS clients (proxy or NAS) outside > the home network MUST NOT modify the CUI attribute." >=20 > I think you want to say that RADIUS proxies MUST NOT modify the CUI > attribute, and that NAS devices that support CUI MUST include=20 > it in the > Accounting-Request unmodified, no? =20 Your statement is correct. And we say that in sectoin 2.1 -- couple of paragraphs below. but here we are simply stating that the entities outside the home network MUST NOT modify CUI. >=20 > " RADIUS client (Proxy or NAS) that does not support the CUI=20 > attribute > MAY ignore this attribute or MAY treat the Access-Accept as > Access-Reject." >=20 > Rather than including this paragraph, I would cite RFC 2865=20 > with respect > to behavior on receipt of an unimplemented attribute in an=20 > Access-Accept. > That way you are guaranteed not to be updating RFC 2865. > For example, RFC 2865 only indicates that an Access-Accept > is treated as an Access-Reject if the service cannot be provided. > This would require a different value of the Service-Type attribute, > which is not used here. So the statement above represents a major > change to RFC 2865, which is already a Draft Standard. >=20 =20 You are right, so how about this? =20 " RFC 2865 states that A RADIUS server or client ignore Attributes with an unknown Type. Therefore, RADIUS client (Proxy or NAS) that does not support the CUI attribute MAY ignore this attribute. " > " If RADIUS client (Proxy or NAS) requires the presence of the CUI > attribute in the Access-Accept, it MUST indicate its requirement by > including this attribute with a nul character for its data field > (hereafter, it is also referred to as a nul CUI) in the > Access-Request message." >=20 > A cleaner approach might be to include a Capabilities > attribute including the Type codes of (standard) attributes > that the NAS is advertising support for. That way a single > attribute could be used to advertise support for up to 253 > attributes. =20 I agree. But, there is no capabilities attribute for RADUS now, and as you know we have a proposal for capabilities attribute but no progerss yet - we may want to accelerate this. >=20 > " If the NAS supports CUI attribute then the CUI attribute=20 > MAY also be > used as one of the identity attribute in Disconnect Message and > Change of Authorization messages defined by [RFC3576]. =20 > Determination > of NAS support for the CUI is outside the scope of this document." >=20 > I don't think this is a good idea. There is already an issue in > translation of RFC 3576 messages into equivalent > Diameter messages and this is going to make it harder. > In retrospect, we probably should have been more > strict with respect to identification in RFC 3576, > such as requiring the Session-Id as a unique identifier. >=20 =20 Are you implying that RADIUS has a session-id -- I wasn't aware of that. I thought Glen Zorn is proposing this in one of his drafts. Anyhow, I guess you are suggesting to remove this paragraph - yes? =20 > Section 3 >=20 > 0 0 0-1 0 0 101 Error-Cause >=20 > This would seem to be updating RFC 3579 and RFC 3576. Please=20 > delete this > line. >=20 =20 Ok. > Section 4 >=20 > " In deployments with both RADIUS and Diameter interworking, a > translation agent will be deployed and operate in accordance to the > NASREQ specification." >=20 > Why is translation required? Shouldn't Diameter just define=20 > an identical > attribute with the same Type value? And isn't CUI used in applications > other than NASREQ, such as EAP? =20 NASREQ does not have this attribute. Does NASREQ automatically cover new RADIUS attributes? CUI will not be used in EAP - unless you correct me by describing a use-case for it. >=20 > Section 5.2 >=20 > " This document instructs IANA to assign a new Error-Cause attribute > [RFC3576]," >=20 > Since the attribute already exists, I think you want a new Error-Cause > value. =20 Yes, right! >=20 > Section 6 >=20 > " The CUI attribute must be protected against Man-in-the-Middle > attacks. The CUI appears in Access-Accept and Accounting-Requests > packets and is protected by the mechanisms that are defined for > RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional > security considerations beyond those already identified in=20 > [RFC2865] > and [RFC2866]. >=20 > Message-Authenticator(80) and Event-Timestamp(55) can be used to > further protect against Man-in-the-middle attacks. >=20 > It is strongly recommended that the CUI form used is such that the > real user identity is not revealed. Furthermore, where a reference > is used to a real user identity, the binding lifetime of that > reference to the real user be kept as short as possible." >=20 > I think you really mean that you would like to protect > RADIUS packets including CUI against modification. Even > though the draft prohibits modification of the CUI attribute > by proxies, there is no way to prevent this, really. >=20 =20 You are right there is no way to prevent this by design of RADIUS. RADIUS assumes that the clients are trusted. Therefore we would n't even attempt to prevent it. > Message-Authenticator and Event-Timestamp attributes don't > protect against man-in-the-middle (e.g. rogue proxies), they > protect against modification and replay, respectively. >=20 =20 RADIUS is not an end to end protocol. It a hop by hop protocol. So there is a client and a server and the "man in the middle" threat is NOT the client or the server but rather someone that is observing the traffic. =20 RADIUS already provides protection for man in the middle against changing the Access-Accept. However, not in the Access-Request but this may not be important here. Except when the NAS wants CUI but the man in the middle deletes that attribute. Message-Authenticator can be used here. =20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > >=20 =20 ------_=_NextPart_001_01C4FC0B.710F1535 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi=20 Bernard,
Thanks = for your=20 comments/feedbacks/corrections.   I agree with most of your = comments=20 -- we will incorporate them into the next version.  Please see=20 my comments inline. 
BR,
Farid
 
> -----Original Message-----
> = From: owner-radiusext@ops.ietf.org= =20
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard=20 Aboba
> Sent: Saturday, January 08, 2005 3:42 PM
> To: radiusext@ops.ietf.org
>= Subject:=20 Issue 52: Review of CUI-01
>
>
> Issue 52: Review of = CUI-01
> Submitter name: Bernard Aboba
> Submitter email = address: aboba@internaut.com
> Date = first=20 submitted: January 8, 2004
> Reference:
> Document: = CUI-01
>=20 Comment type: T
> Priority: S
> Section: Various
>=20 Rationale/Explanation of issue:
> Section 1
>
> " For = example, local or intermediate networks may limit the number of
>=20 simultaneous sessions for specific users; they may require a
>=20 chargeable-user-identity in order to demonstrate willingness to = pay
> or=20 otherwise limit the potential for fraud.
>
> This implies = that an=20 authenticated and unique identity provided by
> the home network = should be=20 able to be conveyed to all parties
> involved in the roaming = transaction=20 for correlating the
> authentication and accounting = packets.
>=20
> Providing a unique identity, called the=20 Chargeable-User-Identity
> (CUI) to intermediaries, is necessary = to=20 fulfill certain business
> needs. This should not undermine the = anonymity=20 of the user. The
> mechanism provided by this draft allows the = home=20 operator to meet
> these business requirements by providing a = temporary=20 identity
> representing the subscriber and at the same time = protecting=20 the
> anonymity of the subscriber."
>
> There is a = tradeoff=20 between providing an authenticated and
> unique identity to all = parties=20 suitable for correlation, while also
> not compromising some = aspects of=20 privacy.
>
> Later on in Section 1.1, it is stated:
> =
> "  When the home network assigns a value=20 to
>    the CUI, it asserts that this value = represents a=20 user in the home
>    network.  The assertion = should=20 be temporary.  Long enough to be
>    useful = for the=20 external applications and not too long such that = it
>   =20 can be used to identify the user."
>
> I think this = paragraph helps=20 clarify the tradeoff, so that it
> should follow the paragraph=20 above.
>
 
Good suggestion.  Will do.
 
> Section 1.1
>
> The = first two=20 paragraphs appear like they belong better in Section 1.
> =
 
Makes sense - = Will=20 move it up.
 
> "A mechanism for providing the = current=20 deployments wit
> the capacity to deploy, bill and oversee WPA = networks=20 against fraud."
>
> This is not a sentence. Should this = be
>=20 "One missing element is a mechanism for...."
 
yes.
 
>
> "Therefore whether a = RADIUS
>=20 server/proxy or client accepts or rejects the presence or lack = of
>=20 presence of the CUI attribute is a matter of business policy."
> =
>=20 This statement appears to come out of the blue. We are just
> = getting into=20 a discussion of usage scenarios, and suddenly
> we jump to a = discussion=20 which appears to be about backward
> compatibility. I'd suggest = you move=20 this sentence later
> in the document where it may be better put = in=20 context.
>

Ok.
 
> "Additionally,
> there could = be multiple=20 class attributes in a RADIUS packet with
> unspecified ordering, = which=20 makes it hard to the entities outside
> home network to determine = which=20 one contains the CUI."
>
> RFC 2865 does specify that = attributes of=20 the same type are not
> reordered by proxies, so I don't think = ordering is=20 an issue.
> The problem is opacity, which would occur whether a=20 single
> Class attribute was used, or multiple attributes. = My
>=20 recommendation is to delete this sentence.
 
Ok.
 
>
> "     = The home=20 network could use User-Name(1) in the=20 Access-Accept
>       message to = convey the=20 CUI to intermediaries and the
> NAS. =20 However,
>       as the = Access-Accept packet=20 is routed to the NAS, the
>=20 User-Name(1)
>       attribute could = be=20 (completely) rewritten by an intermediary=20 and
>       therefore the NAS or = other=20 intermediaries along the way will=20 not
>       have access to the = CUI. =20 Furthermore, the NAS may use
> the=20 original
>       value of the = User-Name(1)=20 attribute (the one sent in = the
>      =20 Access-Request packet) in the Accounting-Request
> packets to=20 ensure
>       the billing follows = the same=20 path as authentication packets."
>
> To my knowledge, = existing=20 implementations do not rewrite a User-Name
> attribute sent in an=20 Access-Accept, since a proxy-state attribute
> can be used to = enable=20 routing of the Access-Accept back to the NAS
> without examining = the=20 User-Name attribute. So the issue is not
> rewriting so much as = the=20 potential impact on routing of accounting
> packets. For example, = the=20 original "privacy" NAI in the
> EAP-Response/Identity might have=20 been:
> example.com!@isp.com.
>=20
 
> This is rewritten by isp.com to=20 "@example.com". As a result,
> the example.com RADIUS server may = not even=20 be aware of isp.com
> as an intermediary, and might send a = User-Name=20 attribute in the
> Access-Accept of "2388484848@example.com". = However,=20 without
> decoration, the resulting Accounting-Request would be=20 routed
> differently than the Access-Request, which might cause=20 problems.
> Section 2.1
>
 
I think the second half of the = paragraph=20 addresses the above problem w.r.t = decoration and=20 routing.  Maybe we should add an example for=20 clarification.   How about we = revise=20 the paragraph to something like this?
 
"
The NAS may=20 use the original value of the User-Name(1) attribute (the one sent in = the=20 Access-Request packet) in the Accounting-Request packets to ensure the = billing=20 follows the same path as authentication packets.  For example, the = EAP peer=20 may construct the NAI with additional information (e.g., example.com@intermediary.com= ) to=20 influence routing of the AAA packet through a preferred intermediary=20 network.  This is rewritten by the intermediary network (i.e.,=20 "intermediary.com" ) to example.com.  As a result, = the home=20 RADIUS server in "example.com" may not even be aware of = "intermediary.com" and=20 therefore sends a User-Name(1) containing CUI (i.e., CUI@example.com) in the = Access-Accept to the=20 NAS.  If the NAS uses the User-Name(1) of the received = Access-Accept=20 in Accounting-Request (as recommended by a strong SHOULD in RFC 2865), = then the=20 resulting Accounting-Request would be routed differently than the=20 Access-Request, which might cause problems.   If the NAS uses = the=20 original NAI sent in the Access-Request, then the CUI  will = not be=20 included in the Accounting-Request.  Furthermore,  in = some=20 deployments, as the Access-Accept packet is routed to the NAS,=20 the User-Name(1) attribute could be (completely) rewritten by=20 an intermediary and therefore the NAS or other = intermediaries along=20 the way will not have access to the CUI.
 
"
 
Section=20 2.1

> "RADIUS = clients (proxy=20 or NAS) outside
> the home network MUST NOT modify the CUI=20 attribute."
>
> I think you want to say that RADIUS proxies = MUST=20 NOT modify the CUI
> attribute, and that NAS devices that support = CUI MUST=20 include
> it in the
> Accounting-Request unmodified,=20 no?
 
Your = statement is=20 correct.  And we say that in sectoin 2.1 -- couple of = paragraphs=20 below.  but here we are simply stating that the entities outside = the home=20 network MUST NOT modify CUI.

>
> "  = RADIUS client=20 (Proxy or NAS) that does not support the CUI
>=20 attribute
>    MAY ignore this attribute or MAY = treat the=20 Access-Accept as
>    Access-Reject."
> =
>=20 Rather than including this paragraph, I would cite RFC 2865
> = with=20 respect
> to behavior on receipt of an unimplemented attribute in = an=20
> Access-Accept.
> That way you are guaranteed not to be = updating=20 RFC 2865.
> For example, RFC 2865 only indicates that an=20 Access-Accept
> is treated as an Access-Reject if the service = cannot be=20 provided.
> This would require a different value of the = Service-Type=20 attribute,
> which is not used here. So the statement above = represents a=20 major
> change to RFC 2865, which is already a Draft = Standard.
>=20
 
You are = right, so how=20 about this?
 
"
RFC 2865 states = that A=20 RADIUS server or client  ignore = Attributes=20 with an unknown Type. Therefore,  RADIUS client (Proxy = or NAS)=20 that does not support the CUI attribute MAY ignore this=20 attribute.
"

>=20 "  If RADIUS client (Proxy or NAS) requires the presence of the=20 CUI
>    attribute in the Access-Accept, it MUST = indicate=20 its requirement by
>    including this attribute = with a nul=20 character for its data field
>    (hereafter, it is = also=20 referred to as a nul CUI) in the
>    = Access-Request=20 message."
>
> A cleaner approach might be to include a=20 Capabilities
> attribute including the Type codes of (standard)=20 attributes
> that the NAS is advertising support for. That way a=20 single
> attribute could be used to advertise support for up to=20 253
> attributes.
 
I agree. = But, there=20 is no capabilities attribute for RADUS now, and as you know we have a = proposal=20 for capabilities attribute but no progerss yet - we may want  to = accelerate=20 this.

>
> "  If = the NAS=20 supports CUI attribute then the CUI attribute
> MAY also=20 be
>    used as one of the identity attribute in = Disconnect=20 Message and
>    Change of Authorization messages = defined=20 by [RFC3576]. 
> Determination
>    of = NAS=20 support for the CUI is outside the scope of this document."
> =
> I=20 don't think this is a good idea. There is already an issue in
>=20 translation of RFC 3576 messages into equivalent
> Diameter = messages and=20 this is going to make it harder.
> In retrospect, we probably = should have=20 been more
> strict with respect to identification in RFC = 3576,
>=20 such as requiring the Session-Id as a unique identifier.
> =
 
Are you implying that RADIUS = has a=20 session-id -- I wasn't aware of that.  I thought Glen Zorn is = proposing=20 this in one of his drafts.  Anyhow,  I guess you are = suggesting to remove=20 this paragraph - yes?  =  

> = Section 3
>=20
>      = 0      =20 0       0-1    =20 0       =20 0         101  =20 Error-Cause
>
> This would seem to be updating RFC 3579 and = RFC=20 3576.  Please
> delete this
> line.
> =
 
Ok.
> Section 4
>
> "  In = deployments=20 with both RADIUS and Diameter interworking, a
>   =20 translation agent will be deployed and operate in accordance to=20 the
>    NASREQ specification."
>
> = Why is=20 translation required? Shouldn't Diameter just define
> an=20 identical
> attribute with the same Type value? And isn't CUI used = in=20 applications
> other than NASREQ, such as EAP?
 
NASREQ does not = have this=20 attribute.  Does NASREQ automatically cover new RADIUS = attributes? =20 CUI will not be used in EAP - unless you correct me by describing a = use-case for=20 it.

>
> Section 5.2
> =
>=20 "  This document instructs IANA to assign a new Error-Cause=20 attribute
>    [RFC3576],"
>
> Since = the=20 attribute already exists, I think you want a new Error-Cause
>=20 value.
 
Yes, right!

>
> Section 6
> =
>=20 "  The CUI attribute must be protected against=20 Man-in-the-Middle
>    attacks.  The CUI = appears in=20 Access-Accept and Accounting-Requests
>    packets = and is=20 protected by the mechanisms that are defined = for
>   =20 RADIUS [RFC2865] and [RFC2866].  Therefore there are no=20 additional
>    security considerations beyond = those=20 already identified in
> [RFC2865]
>    and=20 [RFC2866].
>
>    Message-Authenticator(80) = and=20 Event-Timestamp(55) can be used to
>    further = protect=20 against Man-in-the-middle attacks.
>
>    It = is=20 strongly recommended that the CUI form used is such that=20 the
>    real user identity is not revealed. =20 Furthermore, where a reference
>    is used to a = real user=20 identity, the binding lifetime of that
>    = reference to=20 the real user be kept as short as possible."
>
> I think = you really=20 mean that you would like to protect
> RADIUS packets including CUI = against=20 modification. Even
> though the draft prohibits modification of = the CUI=20 attribute
> by proxies, there is no way to prevent this, = really.
>=20
 
You are = right there=20 is no way to prevent this by design of RADIUS.  RADIUS
assumes = that the=20 clients are trusted.  Therefore we would n't even attempt to
prevent = it.

> Message-Authenticator and = Event-Timestamp attributes don't
> protect against = man-in-the-middle (e.g.=20 rogue proxies), they
> protect against modification and replay,=20 respectively.
>
 
RADIUS is not an end to end = protocol.  It a hop=20 by hop protocol.
So there is a client and a server and the "man in = the=20 middle" threat is NOT
the client or the server but rather someone = that is=20 observing the traffic.
 
RADIUS already provides protection for man = in the=20 middle against changing
the Access-Accept.  However, not in the=20 Access-Request but this may not be
important here.  Except when = the NAS=20 wants CUI but the man in the middle
deletes that attribute. =20 Message-Authenticator can be used here.
 

> --
> to unsubscribe send a message to=20 radiusext-request@ops.ietf.org=20 with
> the word 'unsubscribe' in a single line as the message text = body.
> archive: <http://psg.com/lists/radiusext/>
>
 
------_=_NextPart_001_01C4FC0B.710F1535-- -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 15:42: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: FW: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN Date: Fri, 14 Jan 2005 10:41:37 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1908C@MAANDMBX2.ets.enterasys.com> Thread-Topic: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN Thread-Index: AcT6TRAHdr5IS3u4TteaWSAldWM2ogAAmlkg From: "Nelson, David" To: -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of ietf-secretariat@ietf.org Sent: Friday, January 14, 2005 10:09 AM To: IETF-Announce@ietf.org Subject: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN There are two (2) Internet-Draft cutoff dates for the 62nd IETF Meeting=20 in Minneapolis, MN: February 14th: Cutoff Date for Initial (i.e., -00) Internet-Draft Submissions=20 All initial Internet-Drafts (-00) must be submitted by Monday, February 14th at 9:00 AM ET.=20 As always, all initial submissions (-00) with a filename beginning with "draft-ietf"=20 must be approved by the appropriate WG Chair before they can be processed or announced.=20 WG Chair approval must be received by Monday, February 7th at 9:00 AM ET. February 21st: Cutoff Date for Revised (i.e., -01 and higher) Internet-Draft Submissions=20 All revised Internet-Drafts (-01 and higher) must be submitted by Monday, February 21st=20 at 9:00 AM ET. Initial and revised Internet-Drafts received after their respective cutoff dates will not=20 be made available in the Internet-Drafts directory or announced, and will have to be=20 resubmitted. Please do not wait until the last minute to submit. The Secretariat will=20 begin accepting Internet-Draft submissions starting Monday, March 7th at 9:00 AM ET,=20 but may not post or announce them until Monday, March 14th. Thank you for your understanding and cooperation. If you have any questions or concerns,=20 then please send a message to internet-drafts@ietf.org. The IETF Secretariat FYI: The Internet-Draft cutoff dates as well as other significant dates for the 62nd IETF=20 Meeting can be found at http://www.ietf.org/meetings/IETF-62.html. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 10 Jan 2005 15:34:53 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE0D@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Cc: aboba@internaut.com Subject: AW: RADIUS Attribute Hiding and radext-digest-auth Date: Mon, 10 Jan 2005 16:34:37 +0100 MIME-Version: 1.0 Content-Type: text/plain Bernard wrote: > My suggestion is to address the issue in the > Security Considerations section by providing the figure you > enclosed in your message and then saying "In order to address > these vulnerabilities, IPsec protection of RADIUS can be > implemented, as described in [RFC3579], Section 4.2." > If the WG could agree with this, I would be happy. Wolfgang -- T-Systems Internet Platforms +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 10 Jan 2005 15:13:10 +0000 Date: Mon, 10 Jan 2005 07:12:39 -0800 (PST) From: Bernard Aboba To: "Beck01, Wolfgang" cc: radiusext@ops.ietf.org Subject: Re: RADIUS Attribute Hiding and radext-digest-auth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > UA A -- TLS -- Proxy1 -- TLS -- Proxy2 -- TLS -- UA B > | > UDP > | > RADIUS Server > > Even if all Proxies use TLS for the SIP messages, the RADIUS > part is still unencrypted and exposes usernames, SIP-Methods > and URIs. An attacker can see whether a user is reachable or > is being called or sends an instant message. Thanks for the explanation -- I'd suggest this go into the security considerations section. My take is that the problem as stated applies to both RADIUS authentication and accounting and is best handled by encrypting the entire RADIUS packet, rather than individual attributes. For example, the User-Name attribute is not currently encrypted and for backward compatibility reasons, we do not want to create another attribute just for SIP. > We could set User-Name to 'anonymous@NAI' and define some > Encrypted-User-Name attribute which carries the real User-Name. > Personally, I would prefer the IPSec / VPN solution, even if > RADIUS application can not determine whether their connection > is secure. If the above scenario is the only one we're concerned about, then I'd agree. My suggestion is to address the issue in the Security Considerations section by providing the figure you enclosed in your message and then saying "In order to address these vulnerabilities, IPsec protection of RADIUS can be implemented, as described in [RFC3579], Section 4.2." -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 08:55:11 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE0B@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: aboba@internaut.com, radiusext@ops.ietf.org Subject: Re: RADIUS Attribute Hiding and radext-digest-auth Date: Mon, 10 Jan 2005 09:53:45 +0100 MIME-Version: 1.0 Content-Type: text/plain Bernard Aboba wrote: > Wolfgang Beck wrote: > > When authorizing sips or https connections, at least RADIUS > attributes > > revealing the identity must be encrypted. In > radext-digest-auth this > > applies to the following attributes: > > - User-Name > > - Digest-Username > > - Digest-URI > > - SIP-AOR [not yet in the draft] > > Digest-HA1 would profit from encryption, too. .. > Can you summarize the reasons that each of the above > attributes need to be encrypted? > A bit of history: In SIP, proxies route message from an originating User Agent (UA) towards the destination User Agent. Messages can be sent over UDP, TCP or TLS. The old SIP RfC 2543 permitted the following scenario: User Agent A -- TLS -- Proxy1 -- UDP -- Proxy2 -- TLS -- User Agent B In 2002, a security design team came to the conclusion that such a scenario gives the User Agents a false sense of security. As a result the current SIP RfC 3261 is much stricter and introduced the 'sips' URI. The 'sips' URI tells all Proxies on the way to use TLS. With RADIUS, an example scenarion would look like this: UA A -- TLS -- Proxy1 -- TLS -- Proxy2 -- TLS -- UA B | UDP | RADIUS Server Even if all Proxies use TLS for the SIP messages, the RADIUS part is still unencrypted and exposes usernames, SIP-Methods and URIs. An attacker can see whether a user is reachable or is being called or sends an instant message. As Avi pointed out, most operators already use some kind of VPN to protect their RADIUS traffic. That's why I used formulations like 'encrypted or equally secure connections'. We could set User-Name to 'anonymous@NAI' and define some Encrypted-User-Name attribute which carries the real User-Name. Personally, I would prefer the IPSec / VPN solution, even if RADIUS application can not determine whether their connection is secure. Wolfgang -- T-Systems Internet Platforms +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Mon, 10 Jan 2005 04:05:11 +0000 Message-ID: <41E1FEBB.6040006@cisco.com> Date: Sun, 09 Jan 2005 20:04:11 -0800 From: Murtaza Chiba User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Summary: RADIUS Attribute Hiding Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Since there have been some questions relating to the security of RADIUS > attribute hiding mechanisms, I thought I'd post a summary of RADIUS > attribute hiding mechanisms, describing their vulnerabilities in more > detail. > > First, some background on the Request and Response Authenticators and the > shared secret. > > RFC 2865 Section 3 on the Request Authenticator: > > In Access-Request Packets, the Authenticator value is a 16 > octet random number, called the Request Authenticator. The > value SHOULD be unpredictable and unique over the lifetime of a > secret (the password shared between the client and the RADIUS > server), since repetition of a request value in conjunction > with the same secret would permit an attacker to reply with a > previously intercepted response. Since it is expected that the > same secret MAY be used to authenticate with servers in > disparate geographic regions, the Request Authenticator field > SHOULD exhibit global and temporal uniqueness. > > The Request Authenticator value in an Access-Request packet > SHOULD also be unpredictable, lest an attacker trick a server > into responding to a predicted future request, and then use the > response to masquerade as that server to a future Access- > Request. > > Section 3 also defines the RADIUS Response Authenticator: > > ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) > > [BA] In practice, maintaining global and temporal uniqueness over the > lifetime of a shared secret is a tall order. Some NAS devices do not > have sufficient entropy on boot to provide temporal uniqueness. When > the same shared secret is used across dozens or even thousands of > devices (a common deployment scenario), global and temporal uniqueness > can become very difficult to satisfy. In retrospect, it would have made > more sense to mix a globally unique quantity (such as NAS-Identifier > or NAS-IP-Address) in subsequent calculations, including in the > Response Authenticator, so as to make global uniqueness more likely. > > Here is what RFC 2865, Section 3 has to say about the shared secret: > > The secret (password shared between the client and the RADIUS > server) SHOULD be at least as large and unguessable as a well- > chosen password. It is preferred that the secret be at least 16 > octets. This is to ensure a sufficiently large range for the > secret to provide protection against exhaustive search attacks. > The secret MUST NOT be empty (length 0) since this would allow > packets to be trivially forged. > > [BA] At IETF60, we discussed the consequences of violating this > prescription, namely that the Response Authenticator becomes subject > to dictionary attack. > > The encryption algorithm for the User-Password attribute is described in > RFC 2865, Section 5.1: > > Call the shared secret S and the pseudo-random 128-bit Request > Authenticator RA. Break the password into 16-octet chunks p1, p2, > etc. with the last one padded at the end with nulls to a 16-octet > boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need > intermediate values b1, b2, etc. > > b1 = MD5(S + RA) c(1) = p1 xor b1 > b2 = MD5(S + c(1)) c(2) = p2 xor b2 > . . > . . > . . > bi = MD5(S + c(i-1)) c(i) = pi xor bi > > The String will contain c(1)+c(2)+...+c(i) where + denotes > concatenation. > > [BA] Note that the first block of the keystream b1 is based solely on the > shared secret and the Request Authenticator, and does not include any > NAS-specific information (e.g. NAS-Identifier or NAS-IP-Address). > Thus, if the Request Authenticator is not temporally and globally > unique for a given shared secret, the keystream will repeat. > > This can be exploited in a number of ways. When two identical Response > Authenticators are found on the same NAS, or on two different NASes that > are known to share the same secret S, the ciphertexts can be XOR'd > yielding the XOR of the first clearext password blocks. This can assist > an attacker in guessing the user passwords; once those are determined > the keystream b1 is also known. > > Another way is via a known-plaintext attack, where an attacker attempts > authentication with password p, and then collects the ciphertext c, > allowing the keystream b to be calculated. If the Request > Authenticator ever repeats, the attacker can use the known value of b1 and > the c1 collected from the User-Password attribute to calculate the first > 16 octets of the password p1. > > Note that both of these attacks do not require the attacker to compromise > the password S. > > RFC 2548, Section 2.4.2: MS-MPPE-Send-Key > > Call the shared secret S, the pseudo-random 128-bit Request > Authenticator (from the corresponding Access-Request packet) R, > and the contents of the Salt field A. Break P into 16 octet > chunks p(1), p(2)...p(i), where i = len(P)/16. Call the > ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. > Intermediate values b(1), b(2)...c(i) are required. Encryption > is performed in the following manner ('+' indicates > concatenation): > > b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) > b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) > . . > . . > . . > b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) > > The resulting encrypted String field will contain > c(1)+c(2)+...+c(i). > > On receipt, the process is reversed to yield the plaintext String. > > > [BA] In the situation where a known plaintext attack has been carried out > and the keystream b1=MD5 (S + R) has been determined, the above salt > construction does not help much, since the MD5 calculation can be > continued using the salt field A, which is sent in the clear. Therefore, > an attacker can determine the first 16 octets of the Tunnel-Password, > using the calculated keystream b1'=MD5(S + R + A). > I believe the original motivation for the salt was to make it difficult for dictionary attacks and to also prevent breaking multiple keys if any one of the passwords was guessed. This is because of the simple XOR properties and since C1 is the same for multiple passwords included in the same packer (as would be necessary for multiple tunnel profiles). An attacker breaking one password could get all the others without knowing the shared secret. Or atleast get the first sixteen bytes of the password. C1 xor P1 = X1; X1 xor P1 = C1 C1 xor P2 = X2; X2 xor C1 = P2 If P1 is guessed then P2 is simple to crack as C1 is simply X1 xor P1 and since X1 and X2 are included in the packet P2 is the only unknown in the second equation. Known plaintext attacks can pretty much defeat any algorithm out there. Unless we start mandating quantum cryptography :) The real question is, how easy it is to launch a known plaintext attack considering you need to be part of the control path to capture packets. Probably possible in roaming environments. Regards, Murtaza > RFC 2868, Section 3.5: Tunnel-Password > > Call the shared secret S, the pseudo-random 128-bit Request > Authenticator (from the corresponding Access-Request packet) R, > and the contents of the Salt field A. Break P into 16 octet > chunks p(1), p(2)...p(i), where i = len(P)/16. Call the > ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. > Intermediate values b(1), b(2)...c(i) are required. Encryption > is performed in the following manner ('+' indicates > concatenation): > > b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) > b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) > . . > . . > . . > b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) > > The resulting encrypted String field will contain > c(1)+c(2)+...+c(i). > > On receipt, the process is reversed to yield the plaintext String. > > [BA] The Tunnel-Password attribute utilizes the same construction as the > MS-MPPE-Send-Key attribute, and therefore has the same weakness. > > SUMMARY > > In order to prevent forgeries and keystream recovery, RADIUS requires that > the Request Authenticator be globally and temporally unique. However, > in practice implemenations and deployments often do not satisfy this > requirement. Due to deficiencies in the construction of the Response > Authenticator and attribute hiding algorithms, the problem is magnified. > > To address these problems, future attribute hiding algorithms would be > wise to do one or more of the following: > > a. Utilize a well-analyzed keywrap mechanism based on a block cipher, > rather than the add-hoc stream ciphers used in RADIUS. > > b. Mix in NAS-specific attributes into the calculation, ensuring global > uniqueness. > > c. Utilize randomness from two parties (RADIUS client + RADIUS server). > A minimum of 128-bit nonces are recommended. > > > -- > to 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: Sat, 08 Jan 2005 23:42:34 +0000 Date: Sat, 8 Jan 2005 15:41:41 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Issue 52: Review of CUI-01 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Issue 52: Review of CUI-01 Submitter name: Bernard Aboba Submitter email address: aboba@internaut.com Date first submitted: January 8, 2004 Reference: Document: CUI-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Section 1 " For example, local or intermediate networks may limit the number of simultaneous sessions for specific users; they may require a chargeable-user-identity in order to demonstrate willingness to pay or otherwise limit the potential for fraud. This implies that an authenticated and unique identity provided by the home network should be able to be conveyed to all parties involved in the roaming transaction for correlating the authentication and accounting packets. Providing a unique identity, called the Chargeable-User-Identity (CUI) to intermediaries, is necessary to fulfill certain business needs. This should not undermine the anonymity of the user. The mechanism provided by this draft allows the home operator to meet these business requirements by providing a temporary identity representing the subscriber and at the same time protecting the anonymity of the subscriber." There is a tradeoff between providing an authenticated and unique identity to all parties suitable for correlation, while also not compromising some aspects of privacy. Later on in Section 1.1, it is stated: " When the home network assigns a value to the CUI, it asserts that this value represents a user in the home network. The assertion should be temporary. Long enough to be useful for the external applications and not too long such that it can be used to identify the user." I think this paragraph helps clarify the tradeoff, so that it should follow the paragraph above. Section 1.1 The first two paragraphs appear like they belong better in Section 1. "A mechanism for providing the current deployments wit the capacity to deploy, bill and oversee WPA networks against fraud." This is not a sentence. Should this be "One missing element is a mechanism for...." "Therefore whether a RADIUS server/proxy or client accepts or rejects the presence or lack of presence of the CUI attribute is a matter of business policy." This statement appears to come out of the blue. We are just getting into a discussion of usage scenarios, and suddenly we jump to a discussion which appears to be about backward compatibility. I'd suggest you move this sentence later in the document where it may be better put in context. "Additionally, there could be multiple class attributes in a RADIUS packet with unspecified ordering, which makes it hard to the entities outside home network to determine which one contains the CUI." RFC 2865 does specify that attributes of the same type are not reordered by proxies, so I don't think ordering is an issue. The problem is opacity, which would occur whether a single Class attribute was used, or multiple attributes. My recommendation is to delete this sentence. " The home network could use User-Name(1) in the Access-Accept message to convey the CUI to intermediaries and the NAS. However, as the Access-Accept packet is routed to the NAS, the User-Name(1) attribute could be (completely) rewritten by an intermediary and therefore the NAS or other intermediaries along the way will not have access to the CUI. Furthermore, the NAS may use the original value of the User-Name(1) attribute (the one sent in the Access-Request packet) in the Accounting-Request packets to ensure the billing follows the same path as authentication packets." To my knowledge, existing implementations do not rewrite a User-Name attribute sent in an Access-Accept, since a proxy-state attribute can be used to enable routing of the Access-Accept back to the NAS without examining the User-Name attribute. So the issue is not rewriting so much as the potential impact on routing of accounting packets. For example, the original "privacy" NAI in the EAP-Response/Identity might have been: example.com!@isp.com. This is rewritten by isp.com to "@example.com". As a result, the example.com RADIUS server may not even be aware of isp.com as an intermediary, and might send a User-Name attribute in the Access-Accept of "2388484848@example.com". However, without decoration, the resulting Accounting-Request would be routed differently than the Access-Request, which might cause problems. Section 2.1 "RADIUS clients (proxy or NAS) outside the home network MUST NOT modify the CUI attribute." I think you want to say that RADIUS proxies MUST NOT modify the CUI attribute, and that NAS devices that support CUI MUST include it in the Accounting-Request unmodified, no? " RADIUS client (Proxy or NAS) that does not support the CUI attribute MAY ignore this attribute or MAY treat the Access-Accept as Access-Reject." Rather than including this paragraph, I would cite RFC 2865 with respect to behavior on receipt of an unimplemented attribute in an Access-Accept. That way you are guaranteed not to be updating RFC 2865. For example, RFC 2865 only indicates that an Access-Accept is treated as an Access-Reject if the service cannot be provided. This would require a different value of the Service-Type attribute, which is not used here. So the statement above represents a major change to RFC 2865, which is already a Draft Standard. " If RADIUS client (Proxy or NAS) requires the presence of the CUI attribute in the Access-Accept, it MUST indicate its requirement by including this attribute with a nul character for its data field (hereafter, it is also referred to as a nul CUI) in the Access-Request message." A cleaner approach might be to include a Capabilities attribute including the Type codes of (standard) attributes that the NAS is advertising support for. That way a single attribute could be used to advertise support for up to 253 attributes. " If the NAS supports CUI attribute then the CUI attribute MAY also be used as one of the identity attribute in Disconnect Message and Change of Authorization messages defined by [RFC3576]. Determination of NAS support for the CUI is outside the scope of this document." I don't think this is a good idea. There is already an issue in translation of RFC 3576 messages into equivalent Diameter messages and this is going to make it harder. In retrospect, we probably should have been more strict with respect to identification in RFC 3576, such as requiring the Session-Id as a unique identifier. Section 3 0 0 0-1 0 0 101 Error-Cause This would seem to be updating RFC 3579 and RFC 3576. Please delete this line. Section 4 " In deployments with both RADIUS and Diameter interworking, a translation agent will be deployed and operate in accordance to the NASREQ specification." Why is translation required? Shouldn't Diameter just define an identical attribute with the same Type value? And isn't CUI used in applications other than NASREQ, such as EAP? Section 5.2 " This document instructs IANA to assign a new Error-Cause attribute [RFC3576]," Since the attribute already exists, I think you want a new Error-Cause value. Section 6 " The CUI attribute must be protected against Man-in-the-Middle attacks. The CUI appears in Access-Accept and Accounting-Requests packets and is protected by the mechanisms that are defined for RADIUS [RFC2865] and [RFC2866]. Therefore there are no additional security considerations beyond those already identified in [RFC2865] and [RFC2866]. Message-Authenticator(80) and Event-Timestamp(55) can be used to further protect against Man-in-the-middle attacks. It is strongly recommended that the CUI form used is such that the real user identity is not revealed. Furthermore, where a reference is used to a real user identity, the binding lifetime of that reference to the real user be kept as short as possible." I think you really mean that you would like to protect RADIUS packets including CUI against modification. Even though the draft prohibits modification of the CUI attribute by proxies, there is no way to prevent this, really. Message-Authenticator and Event-Timestamp attributes don't protect against man-in-the-middle (e.g. rogue proxies), they protect against modification and replay, respectively. -- to unsubscribe send a message to radiusext-request@ops.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, 07 Jan 2005 17:47:48 +0000 Date: Fri, 7 Jan 2005 09:46:35 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: RE: RADIUS Attribute Hiding and radext-digest-auth Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > When authorizing sips or https connections, at least RADIUS > attributes revealing the identity must be encrypted. In > radext-digest-auth this applies to the following attributes: > - User-Name > - Digest-Username > - Digest-URI > - SIP-AOR [not yet in the draft] > Digest-HA1 would profit from encryption, too. I think we need a threat model. It is one thing to require that Tunnel-Password be a hidden attribute in order to avoid exposing a cleartext secret on the wire. It is another thing to require privacy for existing attributes such as User-Name. If exposing a given attribute would create a security vulnerability, then we can hide the attribute. However, if we are just talking about privacy of existing attributes, that is a situation where IPsec makes more sense. Can you summarize the reasons that each of the above attributes need to be encrypted? I would like to get to the bottom of this. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 06 Jan 2005 16:34:56 +0000 Message-ID: From: Avi Lior To: "'Beck01, Wolfgang'" , radiusext@ops.ietf.org Subject: RE: RADIUS Attribute Hiding and radext-digest-auth Date: Thu, 6 Jan 2005 11:34:19 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Wolfgang, My initial "gut" reaction is not to solely rely on Ipsec because of deployment issues. That is, we should encrypt these values because there are not that many IPSec RADIUS deployements out there. However, on second thought it seems that in most commercial deployments the RADIUS infrastructure is secure anyway. As well, there seems to be a lot of SIP deployments but I am not aware of SIPS which is where you would use this anyway right? So perhaps we can just state in the security section that if HTTPS or SIPS is being used then we need to use Ipsec. Regarding Digest-HA1. If you must send it back from the server to the client then you can use 2868. > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > Sent: Wednesday, January 05, 2005 10:43 AM > To: radiusext@ops.ietf.org > Subject: RADIUS Attribute Hiding and radext-digest-auth > > > Hi, > > so we have some ways to encrypt individual RADIUS attributes. > When authorizing sips or https connections, at least RADIUS > attributes revealing the identity must be encrypted. In > radext-digest-auth this applies to the following attributes: > - User-Name > - Digest-Username > - Digest-URI > - SIP-AOR [not yet in the draft] > > Digest-HA1 would profit from encryption, too. > > We can re-define Digest-Username, Digest-URI and SIP-AOR to > use one of the encryption algorithms Bernard summarized in a > previous post. We can't do this for User-Name, a new > Encrypted-User-Name attribute would be necessary. > > Message-Authenticator does not help here. > > Should I change the document to use the attribute hiding > mechanism (Tunnel-Password) described in RfC 2868, despite > its weaknesses? > > Or is making IPSec mandatory in the relevant cases acceptable > (as it is in the current version)? > > > Wolfgang > > -- > T-Systems > Internet Platforms > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany > > > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Thu, 06 Jan 2005 15:22:55 +0000 From: Greg Weber Message-Id: <200501061521.KAA15730@cisco.com> Subject: [Issue] CUI not in Accounting-Response To: radiusext@ops.ietf.org Date: Thu, 6 Jan 2005 10:21:51 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Description of issue: CUI not in Accounting-Response Submitter name: Greg Weber Submitter email address: gdweber@cisco.com Date first submitted: January 6, 2005 Reference: n/a Document: draft-ietf-radext-chargeable-user-id-01.txt Comment type: E Priority: S Section: 2.1, 8th paragraph Rationale/Explanation of issue: A RADIUS server (a RADIUS proxy or the home RADIUS server) that requires the presence of the CUI in the Accounting-Response messages... The above reference to Accounting-Response should be Accounting-Request. Requested change: A RADIUS server (a RADIUS proxy or the home RADIUS server) that requires the presence of the CUI in the Accounting-Request messages... -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Jan 2005 21:11: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: CUI-01 and Open Issues Date: Wed, 5 Jan 2005 16:10:47 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19064@MAANDMBX2.ets.enterasys.com> Thread-Topic: CUI-01 and Open Issues Thread-Index: AcTzawavUHnbWL9tTfagBMpAMkjxjg== From: "Nelson, David" To: In reviewing draft-ietf-radext-chargeable-user-id-01.txt against my open issues on the RADEXT Issues Tracker, I observe the following: Issue 35. This issue can be closed. The proposed resolution was not used, but the relevant draft section was completely re-written. Issue 36. (1) The request was to change the CUI attribute to Chargeable-User-ID attribute. The 01 draft uses the Chargeable-User-Identity attribute, which is probably close enough. Classical RADIUS RFC usage is to abbreviate Identity or Identifier as ID, but... This sub-issue can probably be closed. (2) Done. This sub-issue can be closed. (3) Uhhh... The CUI-Type field was written out of the 01 draft, so this issue is no longer relevant. This sub-issue can be closed. (4) Done. This sub-issue can be closed. The entire Issue 36 can therefore be closed. Issue 46. This issue cannot be closed. While the relevant section was re-written in the 01 draft such that the format of the CUI is "indeterminate" i.e. to be determined by business arrangements outside the scope of standardization, the underlying issues of transparency vs. opacity and usable semantic content vs. opaque cookie have not yet been resolved on the WG mailing list. The text in the 01 draft attempts to dodge these issues by avoiding any specific characterization of the data payload of CUI. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 20:39:59 +0000 Message-ID: From: Avi Lior To: "'Beck01, Wolfgang'" , radiusext@ops.ietf.org Subject: RE: RADIUS Attribute Hiding and radext-digest-auth Date: Wed, 5 Jan 2005 15:39:07 -0500 MIME-Version: 1.0 Content-Type: text/plain I need to think about your proposal but my immediate reaction to Ipsec is that its not a good thing to make it mandatory. > -----Original Message----- > From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] > Sent: January 5, 2005 10:43 AM > To: radiusext@ops.ietf.org > Subject: RADIUS Attribute Hiding and radext-digest-auth > > > Hi, > > so we have some ways to encrypt individual RADIUS attributes. > When authorizing sips or https connections, at least RADIUS > attributes revealing the identity must be encrypted. In > radext-digest-auth this applies to the following attributes: > - User-Name > - Digest-Username > - Digest-URI > - SIP-AOR [not yet in the draft] > > Digest-HA1 would profit from encryption, too. > > We can re-define Digest-Username, Digest-URI and SIP-AOR to > use one of the encryption algorithms Bernard summarized in a > previous post. We can't do this for User-Name, a new > Encrypted-User-Name attribute would be necessary. > > Message-Authenticator does not help here. > > Should I change the document to use the attribute hiding > mechanism (Tunnel-Password) described in RfC 2868, despite > its weaknesses? > > Or is making IPSec mandatory in the relevant cases acceptable > (as it is in the current version)? > > > Wolfgang > > -- > T-Systems > Internet Platforms > +49 6151 937 2863 > Am Kavalleriesand 3 > 64295 Darmstadt > Germany > > > > > > -- > to unsubscribe send a message to > radiusext-request@ops.ietf.org with the word 'unsubscribe' in > a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Jan 2005 20:21:50 +0000 From: Greg Weber Message-Id: <200501052020.PAA06946@cisco.com> Subject: Re: CUI version -01 To: farid.adrangi@intel.com (Adrangi, Farid) Date: Wed, 5 Jan 2005 15:20:18 -0500 (EST) Cc: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit The -01 version resolves all the editorial issues i mentioned in Issue #18. That issue may be closed. Greg > > Hi all, > I just submitted -01 version of the CUI. The draft does yet appear in > I-D repository, but you can access it here : > http://mng.ctgisp.com/IETF/RADIUSEXT/draft-ietf-radext-chargeable-user-i > d-01.txt. > > This version provides resolutions to the following issues listed in > http://www.drizzle.com/~aboba/RADEXT/#Issue%2014. > > Issue 14 (Bernard Aboba) > Issue 18 (Greg Weber) > Issue 21 and 22 (Barney Wolf) > Issue 35, 36, 46 (David Nelson) > > In this version, the CUI is represented just in cleartext format - > please see the draft for more details. Hope this version brings us > closer to some consensus. Thanks to all reviewers and folks > participated in the discussions. > > BR, > Farid > > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: > -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 18:00:15 +0000 Message-Id: <200501051759.j05HxhW6015716@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Avi Lior'" , "'Barney Wolff'" , "'Nelson, David'" Cc: Subject: RE: Possible issue for clarification -- RADIUS Accounting Date: Wed, 5 Jan 2005 09:59:43 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit thread-index: AcTzR0WmuTpQWZWQQxi5EFvIe0Fi8gACCAow Avi Lior supposedly scribbled: > Actually 2869 says the following: > > It is envisioned that an Interim Accounting record (with Acct- > Status-Type = Interim-Update (3)) would contain all of the > attributes normally found in an Accounting Stop message with the > exception of the Acct-Term-Cause attribute. I'm quite aware of that; what's missing is the reverse pointer to 2866 that would allow people to discover (without the use of ESP :-) that they need to read 2869 to understand interim accounting. > > Hope this helps, > > Avi > >> -----Original Message----- >> From: Glen Zorn (gwz) [mailto:gwz@cisco.com] >> Sent: January 4, 2005 7:16 PM >> To: 'Barney Wolff'; 'Nelson, David' >> Cc: radiusext@ops.ietf.org >> Subject: RE: Possible issue for clarification -- RADIUS Accounting >> >> >> Barney Wolff <> supposedly scribbled: >> >>> On Tue, Jan 04, 2005 at 06:07:40PM -0500, Nelson, David wrote: >>>> >>>> Since the purpose of the Interim-Update is to provide a snap-shot >>>> of the accounting statistics at that moment in time, I see no >>>> reason why the octet counts and session time attributes ought not >>>> to be included. Is this potentially an erratum in RFC 2866? Or was >>>> there a good reason to omit these accounting statistics from the >>>> Interim-Update messages? >>> >>> I believe you are correct, and this was simply an oversight. >> >> I tend to agree, but I think that the oversight )and error) was >> actually in RFC 2869, which defines the semantics of the >> Interim-Update Acct-Status-Type. I think that the problem could have >> been avoided but just including "Updates: RFC 2866" in the header... >> >>> Regards, >>> Barney >>> >>> -- >>> Barney Wolff http://www.databus.com/bwresume.pdf >>> I'm available by contract or FT, in the NYC metro area or via the >>> 'Net. >> >> 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: 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, 05 Jan 2005 17:04: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: Possible issue for clarification -- RADIUS Accounting Date: Wed, 5 Jan 2005 12:04:06 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19061@MAANDMBX2.ets.enterasys.com> Thread-Topic: Possible issue for clarification -- RADIUS Accounting Thread-Index: AcTzR0CNTxzTqIfXQZmSEqeNnWtP9gAAHhYg From: "Nelson, David" To: Avi Lior writes... > Actually 2869 says the following: >=20 > It is envisioned that an Interim Accounting record (with Acct- > Status-Type =3D Interim-Update (3)) would contain all of the attributes > normally found in an Accounting Stop message with the exception of > the Acct-Term-Cause attribute. So it seems clear that this is the intent. As Glen Zorn points out, RFC 2869 does not indicate that it updates RFC 2866, and RFC 2866 *does* include the code-id for Interim-Update (3), but did not pick up any of the other related text from RFC 2869. RFC 2869 also says: "This memo suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental." While the RFC status is Informational, it indicates that the Attribute status is Experimental? Odd. Perhaps we should consider adding a clarification in our RADIUS Issues and Fixes document, once we actually start work on that charter item. -- to unsubscribe send a message to radiusext-request@ops.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 Jan 2005 16:55:34 +0000 Message-ID: From: Avi Lior To: "'gwz@cisco.com'" , 'Barney Wolff' , "'Nelson, David'" Cc: radiusext@ops.ietf.org Subject: RE: Possible issue for clarification -- RADIUS Accounting Date: Wed, 5 Jan 2005 11:54:31 -0500 MIME-Version: 1.0 Content-Type: text/plain Actually 2869 says the following: It is envisioned that an Interim Accounting record (with Acct- Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message with the exception of the Acct-Term-Cause attribute. Hope this helps, Avi > -----Original Message----- > From: Glen Zorn (gwz) [mailto:gwz@cisco.com] > Sent: January 4, 2005 7:16 PM > To: 'Barney Wolff'; 'Nelson, David' > Cc: radiusext@ops.ietf.org > Subject: RE: Possible issue for clarification -- RADIUS Accounting > > > Barney Wolff <> supposedly scribbled: > > > On Tue, Jan 04, 2005 at 06:07:40PM -0500, Nelson, David wrote: > >> > >> Since the purpose of the Interim-Update is to provide a snap-shot > of > >> the accounting statistics at that moment in time, I see no reason > why > >> the octet counts and session time attributes ought not to be > >> included. Is this potentially an erratum in RFC 2866? Or was > there a > >> good reason to omit these accounting statistics from the > >> Interim-Update messages? > > > > I believe you are correct, and this was simply an oversight. > > I tend to agree, but I think that the oversight )and error) > was actually in RFC 2869, which defines the semantics of the > Interim-Update Acct-Status-Type. I think that the problem > could have been avoided but just including "Updates: RFC > 2866" in the header... > > > Regards, > > Barney > > > > -- > > Barney Wolff http://www.databus.com/bwresume.pdf > > I'm available by contract or FT, in the NYC metro area or via the > > 'Net. > > 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, 05 Jan 2005 15:43:47 +0000 Message-Id: <76C27E1CE3FFC847B4D51C645D6F42AA15FE04@E9JDF.mgb01.telekom.de> From: "Beck01, Wolfgang" To: radiusext@ops.ietf.org Subject: RADIUS Attribute Hiding and radext-digest-auth Date: Wed, 5 Jan 2005 16:42:49 +0100 MIME-Version: 1.0 Content-Type: text/plain Hi, so we have some ways to encrypt individual RADIUS attributes. When authorizing sips or https connections, at least RADIUS attributes revealing the identity must be encrypted. In radext-digest-auth this applies to the following attributes: - User-Name - Digest-Username - Digest-URI - SIP-AOR [not yet in the draft] Digest-HA1 would profit from encryption, too. We can re-define Digest-Username, Digest-URI and SIP-AOR to use one of the encryption algorithms Bernard summarized in a previous post. We can't do this for User-Name, a new Encrypted-User-Name attribute would be necessary. Message-Authenticator does not help here. Should I change the document to use the attribute hiding mechanism (Tunnel-Password) described in RfC 2868, despite its weaknesses? Or is making IPSec mandatory in the relevant cases acceptable (as it is in the current version)? Wolfgang -- T-Systems Internet Platforms +49 6151 937 2863 Am Kavalleriesand 3 64295 Darmstadt Germany -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Wed, 05 Jan 2005 00:16:22 +0000 Message-Id: <200501050015.j050FqW6015662@ams-core-1.cisco.com> Reply-To: From: "Glen Zorn \(gwz\)" To: "'Barney Wolff'" , "'Nelson, David'" Cc: Subject: RE: Possible issue for clarification -- RADIUS Accounting Date: Tue, 4 Jan 2005 16:15:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcTyuTxvheW5CA0QSeeWH1WcXxdZXQAAZABQ Barney Wolff <> supposedly scribbled: > On Tue, Jan 04, 2005 at 06:07:40PM -0500, Nelson, David wrote: >> >> Since the purpose of the Interim-Update is to provide a snap-shot of >> the accounting statistics at that moment in time, I see no reason why >> the octet counts and session time attributes ought not to be >> included. Is this potentially an erratum in RFC 2866? Or was there a >> good reason to omit these accounting statistics from the >> Interim-Update messages? > > I believe you are correct, and this was simply an oversight. I tend to agree, but I think that the oversight )and error) was actually in RFC 2869, which defines the semantics of the Interim-Update Acct-Status-Type. I think that the problem could have been avoided but just including "Updates: RFC 2866" in the header... > Regards, > Barney > > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via the > 'Net. 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, 04 Jan 2005 23:56:43 +0000 Date: Tue, 4 Jan 2005 18:56:15 -0500 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Possible issue for clarification -- RADIUS Accounting Message-ID: <20050104235615.GA76232@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 04, 2005 at 06:07:40PM -0500, Nelson, David wrote: > > Since the purpose of the Interim-Update is to provide a snap-shot of the > accounting statistics at that moment in time, I see no reason why the > octet counts and session time attributes ought not to be included. Is > this potentially an erratum in RFC 2866? Or was there a good reason to > omit these accounting statistics from the Interim-Update messages? I believe you are correct, and this was simply an oversight. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 23:09: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: Possible issue for clarification -- RADIUS Accounting Date: Tue, 4 Jan 2005 18:07:40 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1905A@MAANDMBX2.ets.enterasys.com> Thread-Topic: Possible issue for clarification -- RADIUS Accounting Thread-Index: AcTysjBBsBH3TrYwRwGepm9dC5+plw== From: "Nelson, David" To: RFC 2866 has the following text (or similar): "...can only be present in Accounting-Request records where=20 the Acct-Status-Type is set to Stop." contained in the description of the following RADIUS Accounting Attributes:=20 5.3. Acct-Input-Octets 5.4. Acct-Output-Octets 5.7. Acct-Session-Time 5.8. Acct-Input-Packets 5.9. Acct-Output-Packets 5.10. Acct-Terminate-Cause With the exception of Acct-Terminate-Cause, do folks in think that RFC 2866 intended to prohibit these attributes from also appearing in Accounting-Request messages where the Acct-Status-Type is set to Interim-Update? My research shows that the text in question first appears in RFC 2059. RFC 2059 is obsoleted by RFC 2139, which in turn is obsoleted by RFC 2866. The Interim-Update value of Acct-Status-Type is *not* included in RFC 2059, just Start and Stop. One possible scenario is that when the Interim-Update type was added, no one bothered to notice the sections of text that indicate this "Stop only" text and updated them to read "Stop or Interim-Update". =20 Since the purpose of the Interim-Update is to provide a snap-shot of the accounting statistics at that moment in time, I see no reason why the octet counts and session time attributes ought not to be included. Is this potentially an erratum in RFC 2866? Or was there a good reason to omit these accounting statistics from the Interim-Update messages? -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 22:13:40 +0000 Date: Tue, 4 Jan 2005 17:13:06 -0500 From: Barney Wolff To: radiusext@ops.ietf.org Subject: CUI - I'm happy Message-ID: <20050104221306.GA60821@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i My issues with CUI were 1) Not retroactively making old implementations non-compliant with "RADIUS". 2) Not using CUI where Class would suffice. I believe both have been dealt with, and it's time to publish. Authors, thanks for your patience and for taking my comments like gentlemen. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 20:30:39 +0000 Message-ID: From: Avi Lior To: "'Nelson, David'" , radiusext@ops.ietf.org Subject: RE: Logical sessions vs. statement reconcilliation (was RE: ) Date: Tue, 4 Jan 2005 15:30:22 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi David, > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Tuesday, January 04, 2005 2:39 PM > To: radiusext@ops.ietf.org > Subject: Logical sessions vs. statement reconcilliation (was RE: ) > > > Avi Lior writes... > > > When User-name is not available, CUI can be used to help > > correalating related (shorter) accounting session into > > longer "user experienced session" that extend over multiple > > disconnect and reconnect cases. > > I think what this means is that the Home AAA might choose to > issue a one consistent value of the "user handle" (CUI) for a > number of authentication requests, and switch to issuing a > different consistent value after some session threshold has > expired, e.g. 24 hours after the initial "sign-up" for > service, or at 12:00 noon on each day of use, etc. Yes. The number of authentication requests and when the switch happens will be driven by the Service Level agreement and/or specified by an SDO for their specific network (Eg., GSMA). > This is not immediately in conflict with the notion that the > CUI value is sufficiently long-lived as to be useful for > billing purposes, but sufficiently short-lived as to protect > anonymity, when such is required. This is especially so as > the longevity issue is left as out-of-scope for the document. Right. > The grouping of accounting records by CUI value is very > similar to grouping of accounting records by User-Name value > -- typically a reconciliation process that leads to issuing > an itemized statement or bill, e.g. on a monthly basis. Right. > One question remains in my mind, however. If the Home AAA > changes the CUI value for a given user on a (frequent) > logical session basis, how many CUI values will the Home AAA > need to remember as belonging to the given user, in order for > the end-of-month statement reconciliation process to be feasible? It will have to remember all of them. Note though that we don't specify how the CUI is generated. The Home Network may only need to remember some "parameters". For example, as long as the CUI value is unique it may be consturucted by encrypting the real user-identity (or an constant index to the real user identity) plus a sequence number. So to recupe the identity, during the reconcilliation phase it just needs to decrpypt the CUI and get its answer. You know what I mean. So in deployments where the number of CUIs maybe a problem this strategy maybe employed. > > > -- > to 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, 04 Jan 2005 20:27:29 +0000 Date: Tue, 4 Jan 2005 15:26:57 -0500 From: Barney Wolff To: Avi Lior Cc: "'Barney Wolff'" , "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: Re: Message-ID: <20050104202657.GA52299@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 04, 2005 at 03:15:42PM -0500, Avi Lior wrote: > > > > CUI is a handle to a user. Therefore CUI can be used outside the home > network in scenarios > > > that traditionaly relied on username to correlate a session > > > to a user. > > Is this better? Works for me. Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 20:25:18 +0000 Date: Tue, 4 Jan 2005 15:25:02 -0500 From: Barney Wolff To: "Nelson, David" Cc: radiusext@ops.ietf.org Subject: Re: Logical sessions vs. statement reconcilliation (was RE: ) Message-ID: <20050104202502.GB40326@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 04, 2005 at 02:39:17PM -0500, Nelson, David wrote: > > The grouping of accounting records by CUI value is very similar to > grouping of accounting records by User-Name value -- typically a > reconciliation process that leads to issuing an itemized statement or > bill, e.g. on a monthly basis. > > One question remains in my mind, however. If the Home AAA changes the > CUI value for a given user on a (frequent) logical session basis, how > many CUI values will the Home AAA need to remember as belonging to the > given user, in order for the end-of-month statement reconciliation > process to be feasible? The home server does not have to remember the handle at all. It has the Acct-Session-Ids for each of the sessions, and surely for its own purposes must store the accounting records with the real user as a key. When the NAS or proxy owner presents a bill or makes an inquiry about one or more sessions, the home server can verify that each of them did indeed belong to the same user. On the other hand, if the NAS/proxy presents a semi-itemized bill with only a total for each CUI, then the home server must be able to derive the real user from the CUI for as long as either the bill or an accusation of abuse could take to arrive. In such a case I might use an algorithm for reversably computing CUI from real-user-id with a key that changed for each period. But really, this is over-design - storage is pretty cheap these days. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 20:16:11 +0000 Message-ID: From: Avi Lior To: 'Barney Wolff' , Avi Lior Cc: "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: Date: Tue, 4 Jan 2005 15:15:42 -0500 MIME-Version: 1.0 Content-Type: text/plain Hi Barney, See inline. > -----Original Message----- > From: Barney Wolff [mailto:barney@databus.com] > Sent: Tuesday, January 04, 2005 2:44 PM > To: Avi Lior > Cc: 'jouni.korhonen@teliasonera.com'; > john.loughney@nokia.com; jari.arkko@piuha.net; > Madjid.Nakhjiri@motorola.com; dnelson@enterasys.com; > radiusext@ops.ietf.org > Subject: Re: > > > On Tue, Jan 04, 2005 at 01:41:45PM -0500, Avi Lior wrote: > > > > > One of the intended additional uses for CUI (at least in > our roaming > > > scenarios) > > > at the home AAA is indeed to be able to help correlating related > > > (shorter) > > > accounting sessions into longer "user experienced session" -- > > > e.g. something acct-multi-session-id could also be used for > > > but extended to multiple disconnect & reconnect cases as well. > > > > Repharsing: > > > > When User-name is not available, CUI can be used to help > correalating > > related (shorter) accounting session into longer "user experienced > > session" that extend over multiple disconnect and reconnect cases. > > > > Note that if acct-multi-session-id can be used it should be > used. The > > above is a case where multi-session-id would not work. So without a > > username or some other attribute to tie them together then > CUI would > > indeed help. Another attribute that can be used for this would be > > Calling-Station-Id. > > > > Perhaps we can generalize this -- There will be lots of different > > scenario that would fit here. So how about: > > > > CUI is a handle to a user. Therefore CUI can be used in scenarios > > that traditionaly relied on username to correlate a session > to a user. > > For example, CUI can be used to correlating related accounting > > sessions into longer sessions that extend over multiple disconnnect > > and reconnect cases. > > > > This use case aligns with the one that someone brought up for WLAN > > roaming where the SLA agreement covers 24 hours period and all the > > individual accounting sessions need to be mapped to a User at the > > visited network. > > Watch out here. Those of us in the stick-in-the-mud camp can > only accept CUI when Class won't do. So any use of CUI at > the behest of the home network is out of order. Absolutely. The above was not inetended for Home Network use at all. I don't think I mentioned the home network. So perhaps a tighter scenario: I added "outside the home network". > > CUI is a handle to a user. Therefore CUI can be used outside the home network in scenarios > > that traditionaly relied on username to correlate a session > > to a user. Is this better? > -- > Barney Wolff http://www.databus.com/bwresume.pdf > I'm available by contract or FT, in the NYC metro area or via > the 'Net. > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 20:15:58 +0000 Date: Tue, 4 Jan 2005 21:22:28 +0100 From: Emile van Bergen To: Barney Wolff Cc: Avi Lior , "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: Re: CUI Message-ID: <20050104202228.GB23364@host.e-advies.nl> Mail-Followup-To: Barney Wolff , Avi Lior , "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, dnelson@enterasys.com, radiusext@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Hi, On Tue, Jan 04, 2005 at 02:43:55PM -0500, Barney Wolff wrote: > Watch out here. Those of us in the stick-in-the-mud camp can only accept > CUI when Class won't do. So any use of CUI at the behest of the home > network is out of order. Seconded. > CUI can only be justified when it's the owner of the NAS or proxy that > demands a handle to the user. Agreed. And 'user', for whatever lifetime of 'user' that was agreed between the home AAA and the other parts of the chain. Kind regards, Emlie. -- E-Advies - Emile van Bergen emile@e-advies.nl tel. +31 (0)70 3906153 http://www.e-advies.nl -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 19:44:35 +0000 Date: Tue, 4 Jan 2005 14:43:55 -0500 From: Barney Wolff To: Avi Lior Cc: "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com, dnelson@enterasys.com, radiusext@ops.ietf.org Subject: Re: Message-ID: <20050104194355.GA40326@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Tue, Jan 04, 2005 at 01:41:45PM -0500, Avi Lior wrote: > > > One of the intended additional uses for CUI (at least in our roaming > > scenarios) > > at the home AAA is indeed to be able to help correlating related > > (shorter) > > accounting sessions into longer "user experienced session" -- > > e.g. something acct-multi-session-id could also be used for > > but extended to multiple disconnect & reconnect cases as well. > > Repharsing: > > When User-name is not available, CUI can be used to help correalating > related (shorter) accounting session into longer "user experienced session" > that extend over multiple disconnect and reconnect cases. > > Note that if acct-multi-session-id can be used it should be used. The above > is a case where multi-session-id would not work. So without a username or > some other attribute to tie them together then CUI would indeed help. > Another attribute that can be used for this would be Calling-Station-Id. > > Perhaps we can generalize this -- There will be lots of different scenario > that would fit here. So how about: > > CUI is a handle to a user. Therefore CUI can be used in scenarios that > traditionaly relied on username to correlate a session to a user. For > example, CUI can be used to correlating related accounting sessions into > longer sessions that extend over multiple disconnnect and reconnect cases. > > This use case aligns with the one that someone brought up for WLAN roaming > where the SLA agreement covers 24 hours period and all the individual > accounting sessions need to be mapped to a User at the visited network. Watch out here. Those of us in the stick-in-the-mud camp can only accept CUI when Class won't do. So any use of CUI at the behest of the home network is out of order. CUI can only be justified when it's the owner of the NAS or proxy that demands a handle to the user. A home server that gets CUI in the Access-Request and therefore puts CUI in the Accept could, I suppose, use the CUI in Accounting requests rather than Class, but why would its developer want to use two different mechanisms when always using Class would work just as well? Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 19:41: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: Logical sessions vs. statement reconcilliation (was RE: ) Date: Tue, 4 Jan 2005 14:39:17 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19054@MAANDMBX2.ets.enterasys.com> Thread-Topic: Logical sessions vs. statement reconcilliation (was RE: ) Thread-Index: AcTyjRNdg0Rn3CYuR+ycEfnvGL+osgABkN3w From: "Nelson, David" To: Avi Lior writes... > When User-name is not available, CUI can be used to help=20 > correalating related (shorter) accounting session into=20 > longer "user experienced session" that extend over multiple > disconnect and reconnect cases. I think what this means is that the Home AAA might choose to issue a one consistent value of the "user handle" (CUI) for a number of authentication requests, and switch to issuing a different consistent value after some session threshold has expired, e.g. 24 hours after the initial "sign-up" for service, or at 12:00 noon on each day of use, etc. This is not immediately in conflict with the notion that the CUI value is sufficiently long-lived as to be useful for billing purposes, but sufficiently short-lived as to protect anonymity, when such is required. This is especially so as the longevity issue is left as out-of-scope for the document. The grouping of accounting records by CUI value is very similar to grouping of accounting records by User-Name value -- typically a reconciliation process that leads to issuing an itemized statement or bill, e.g. on a monthly basis. One question remains in my mind, however. If the Home AAA changes the CUI value for a given user on a (frequent) logical session basis, how many CUI values will the Home AAA need to remember as belonging to the given user, in order for the end-of-month statement reconciliation process to be feasible?=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, 04 Jan 2005 18:42:28 +0000 Message-ID: From: Avi Lior To: "'jouni.korhonen@teliasonera.com'" , john.loughney@nokia.com, jari.arkko@piuha.net, Madjid.Nakhjiri@motorola.com Cc: Avi Lior , dnelson@enterasys.com, radiusext@ops.ietf.org Subject: RE: Date: Tue, 4 Jan 2005 13:41:45 -0500 MIME-Version: 1.0 Content-Type: text/plain > One of the intended additional uses for CUI (at least in our roaming > scenarios) > at the home AAA is indeed to be able to help correlating related > (shorter) > accounting sessions into longer "user experienced session" -- > e.g. something acct-multi-session-id could also be used for > but extended to multiple disconnect & reconnect cases as well. Repharsing: When User-name is not available, CUI can be used to help correalating related (shorter) accounting session into longer "user experienced session" that extend over multiple disconnect and reconnect cases. Note that if acct-multi-session-id can be used it should be used. The above is a case where multi-session-id would not work. So without a username or some other attribute to tie them together then CUI would indeed help. Another attribute that can be used for this would be Calling-Station-Id. Perhaps we can generalize this -- There will be lots of different scenario that would fit here. So how about: CUI is a handle to a user. Therefore CUI can be used in scenarios that traditionaly relied on username to correlate a session to a user. For example, CUI can be used to correlating related accounting sessions into longer sessions that extend over multiple disconnnect and reconnect cases. This use case aligns with the one that someone brought up for WLAN roaming where the SLA agreement covers 24 hours period and all the individual accounting sessions need to be mapped to a User at the visited network. > /Jouni > > > > > > John > > > > -- > > to unsubscribe send a message to > radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: > > > -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 18:11:56 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on CUI Usage and Applicability Date: Tue, 4 Jan 2005 10:03:52 -0800 Message-ID: Thread-Topic: Consensus on CUI Usage and Applicability Thread-Index: AcTuxMf+x8u+mOOzSn6LK3QAZuh0xADwqYPA From: "Adrangi, Farid" To: "Bernard Aboba" Cc: Hi Bernard, all Thanks for the e-mail. In response to your points.... - I think we have reached some rough consensus on opacity, CUI applicability, backward compatibility, NAS vs. Proxy vs. Server during our e-mail discussion. The latest draft (version -01, submitted recently) provides resolutions to the issues raised in the reflector and also filed in the issues tracker. Authors have closely worked with folks like Barney Wolf who filed initial issues pertaining to CUI applicability and backward compatibility, and together we came up with resolutions to these issues. If the resolutions are not satisfactory to other folks, then they should submit new issue(s) to the tracker. =20 - Authors had a usage scenario for CUI as explained in the draft. If some folks think that there are more usage scenarios that need to be considered, then we would like to see issues (explaining the usage scenarios an why it should be included/addressed in the draft) submitted to issues tracker rather than having some random e-mails discussions. Once the usage scenarios are identified and filed in the issue tracker, then we can discuss the inclusion of these usage scenario in the draft. The chairs then can call for consensus on each scenario .... =20 =20 - On Class attribute, I don't think there are any confusion. Anyhow, Section 1.1 (motivation) describes why existing attributes (e.g., class) cannot be used to solve the problem. If this is not convincing or accurate, then we would like to see an issue submitted to the tracker. And please note that the draft is not intended to provide tutorial on class attribute. - Finally, as the next step, we think issue submitters and others should review version -01 against the existing issues filed in the tracker. The issues tracker should be updated based on their review. Thanks again. BR, Farid > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Thursday, December 30, 2004 3:10 PM > To: radiusext@ops.ietf.org > Subject: Consensus on CUI Usage and Applicability >=20 >=20 > One of the guidelines for IETF work is "rough consensus and=20 > running code". >=20 > Looking over the recent WG discussion on CUI usage and=20 > applicability, it > is difficult to discern much in the way of consensus. With respect to > quite a few points (opacity, backward compatibility, NAS vs. Proxy vs. > Server) RADEXT WG participants appear to be deeply divided. >=20 > If the RADEXT WG cannot come to consensus on what CUI is intended to > achieve and how it is to be used, then it seems unlikely that=20 > we will be > able to make progress on completing this work item. Therefore it is > important for us to make progress on this, and figure out why opinions > are so divergent. >=20 > There are several potential explanations for the wide range of > opinions that have been expressed: >=20 > a. People are looking at CUI to solve several different problems. > Depending on the problem of interest, the usage and applicability may > differ substantially. If this is the case, then we may be=20 > able to make > progress by specifying the usage scenarios and describing how=20 > CUI can be > used in each situation, omitting the scenarios on which the=20 > WG cannot come > to consensus. >=20 > b. Within a given usage scenario there may be differences as=20 > to the use > and applicability of CUI. If this is the problem, then we will not be > able to proceed on that usage scenario. Hopefully, this won't be > the case for all usage scenarios. >=20 > c. There is confusion about the usage of the existing Class attribute > and that is affecting people's opinions on how CUI would be=20 > used. If this > is the problem, then further discussion and clarifications within the > specification should help. >=20 > Based on the discussion so far, my guess is that a) may be=20 > closer to the > mark than b). However, the discussion so far also provides=20 > some evidence > for c). >=20 > In order to try to find our way through this issue, the=20 > Chairs would like > to suggest the following approach: >=20 > a. Have the document editors write up a series of usage scenarios, > describing how CUI would be used within each scenario, and how > backward compatibility issues would be addressed. >=20 > b. The Chairs will then call for consensus on each scenario, in order > to isolate what usage scenarios have consensus and which do not. >=20 > Our hope is that this approach will identify points of=20 > agreement that will > allow the specification to move forward. We can then focus=20 > on the points > of disagreement to understand whether an alternative approach=20 > (such as use > of different attributes, including Class) may be required. >=20 > Comments welcome. >=20 > -- > to unsubscribe send a message to radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Tue, 04 Jan 2005 15:21:47 +0000 Message-ID: <41DAB43E.9000005@alcatel.be> Date: Tue, 04 Jan 2005 16:20:30 +0100 From: stefaan.de_cnodder@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" Cc: "Wijnen, Bert (Bert)" , radiusext@ops.ietf.org Subject: Re: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: base64 DQpIaSBEYW4sDQoNClNvcnJ5IGZvciB0aGUgbGF0ZSByZXNwb25zZS4gVGhhbmtzIGZvciB5b3Vy IHJldmlldy4gQWxsIHlvdXIgY29tbWVudHMgDQp3aWxsIGJlIHRha2VuIGludG8gYWNjb3VudCBp biB0aGUgbmV4dCB2ZXJzaW9uIG9mIHRoZSBkcmFmdC4gU2VlIGJlbG93IA0KZm9yIHNvbWUgY29t bWVudHMuLi4NCg0KDQpXaWpuZW4sIEJlcnQgKEJlcnQpIHdyb3RlOg0KDQo+IFRoYW5rcyBmb3Ig dGhlIHJldmlldyBEYW4uDQo+ICANCj4gTGV0IG1lIGFkZCB3LnIudC4gcG9pbnQgNg0KPiAgDQo+ IFdlIGRvIG5vdCBsaWtlIHRoZSBpZGVhIG9mIGRvaW5nIGEgc2VwYXJhdGUgc3VidHJlZSBmb3Ig ZWFjaCB0ZWNobm9sb2d5Lg0KPiBTbw0KPiAgICAgIHJhZGl1c0R5bmFtaWNBdXRob3JpemF0aW9u ICBPQkpFQ1QgSURFTlRJRklFUiA6Oj0geyByYWRpdXNNSUIgMyB9DQo+IGlzIG5vdCBnb29kLiBX ZSdkIHJhdGhlciBzZWU6DQo+ICANCj4gICAgcmFkaXVzRHluYW1pY0F1dGhvcml6YXRpb24gIE9C SkVDVCBJREVOVElGSUVSIDo6PSB7IG1pYi0yIHh4eCB9IC0tIA0KPiB4eHggdG8gYmUgYXNzaWdu ZWQgYnkgSUFOQQ0KPiAgDQo+IFRoZSByZWFzb24gaXMgdGhhdCB3ZSBoYXZlIHJ1biBpbnRvIGNs YXNoZWQgKGkuZS4gY29uZmxpY3RpbmcgDQo+IGRlZmluaXRpb25zKSB3aGVuIFdHcyB0cnkgdG8g a2VlcA0KPiB0cmFjayBvZiByZWdpc3RyYXRpb25zIHVuZGVybmVhdGggYSBNSUIgYnJhbmNoLiBT ZWUgYWxzbyB0aGUgcmVjb21tZW5kYXRpb24NCj4gaW4gTUlCIHJldmlldyBndWlkZWxpbmVzIGRy YWZ0LWlldGYtb3BzLW1pYi1yZXZpZXctZ3VpZGVsaW5lcy0wMy50eHQgDQo+IHNlY3QgNC41LCAz cmQgYnVsbGV0Lg0KPiAgDQo+IFNvIHBscyBnbyBmb3IgYXNzaWdubWVudCB1bmRlciBtaWItMi4g SWYgeW91IHdhbnQgdG8gc3RpY2sNCj4gaXQgdW5kZXIgcmFkaXVzTUlCLCB0aGVuIEknZCBsaWtl IHRvIHNlZSBhIGRvY3VtZW50IHNpbWlsYXINCj4gdG8gIFJGQzM3MzcuDQo+ICANCj4gQmVydA0K PiAgDQo+ICAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiAqRnJvbToqIFJvbWFzY2FudSwg RGFuIChEYW4pIFttYWlsdG86ZHJvbWFzY2FAYXZheWEuY29tXQ0KPiAqU2VudDoqIE1vbmRheSwg RGVjZW1iZXIgMjAsIDIwMDQgMTU6MzkNCj4gKlRvOiogcmFkaXVzZXh0QG9wcy5pZXRmLm9yZw0K PiAqQ2M6KiBid2lqbmVuQGx1Y2VudC5jb20NCj4gKlN1YmplY3Q6KiBDb21tZW50cyBvbiBkcmFm dC1kZWNub2RkZXItcmFkZXh0LWR5bmF1dGgtY2xpZW50LW1pYi0wMi50eHQNCj4gDQo+ICAgICBB dCB0aGUgcmVxdWVzdCBvZiB0aGUgT3BlcmF0aW9ucyBhbmQgTWFuYWdlbWVudCBBcmVhIERpcmVj dG9yIEkNCj4gICAgIHJldmlld2VkIGRyYWZ0LWRlY25vZGRlci1yYWRleHQtZHluYXV0aC1jbGll bnQtbWliLTAyLnR4dC4gUGxlYXNlDQo+ICAgICBmaW5kIGJlbG93IG15IGNvbW1lbnRzLg0KPiAN Cj4gICAgIFJlZ2FyZHMsDQo+IA0KPiAgICAgRGFuDQo+IA0KPiAgICAgMS4gVGhlIGJvaWxlcnBs YXRlIGRvZXMgbm90IGNvbmZvcm0gd2l0aCB0aGUgbGF0ZXN0IHJlY29tbWVuZGF0aW9ucw0KPiAg ICAgcmVmZXJyaW5nIHRvIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBub3RpY2VzLiBTZWUNCj4gICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtZ3VpZGVsaW5lcy50eHQg/WZvciB0aGUgbWFu ZGF0b3J5IG5vdGljZXMuDQo+IA0KPiAgICAgMi4gVGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIGNv bnRhaW5zIHVuLWV4cGFuZGVkIGFjcm9ueW1zIHdoaWNoIGFyZQ0KPiAgICAgbm90IHB1YmxpYyBk b21haW4ga25vd2xlZGdlIGZvciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5IC0gQ29BLCBOQVMuIA0K PiANCj4gICAgIDMuIFNlY3Rpb24gNSBpbiB0aGlzIGRvY3VtZW50IGR1cGxpY2F0ZXMgbXVjaCBv ZiB0aGUgc2ltaWxhciBzZWN0aW9uDQo+ICAgICA1IGluIGRyYWZ0LWRlY25vZGRlci1yYWRleHQt ZHluYXV0aC1zZXJ2ZXItbWliLTAyLnR4dC4gSXQgbWF5IGJlDQo+ICAgICBiZXR0ZXIgdG8gYXZv aWQgZHVwbGljYXRpb24gYnkgaGF2aW5nIHRoZSByZXNwZWN0aXZlIHRleHQgYmUgd3JpdHRlbg0K PiAgICAgb25seSBpbiBvbmUgZG9jdW1lbnQgYW5kIHJlZmVycmVkIGJ5IHRoZSBvdGhlci4NCj4g DQo+ICAgICA0LiBTZWN0aW9uIDUsIGZpcnN0IHBhcmFncmFwaCAtICdUaGUgUkFESVVTIGR5bmFt aWMgYXV0aG9yaXphdGlvbg0KPiAgICAgZXh0ZW5zaW9ucyAuLi4gZGlzdGluZ3Vpc2hlcy4uLicg LSBncmFtbWFyIHByb2JsZW0NCj4gDQo+ICAgICA1LklzIHRoaXMgTUlCIG1vZHVsZSBpbXBsZW1l bnRlZCBpbiBjb25qdW5jdGlvbiB3aXRoIG90aGVyIE1JQg0KPiAgICAgbW9kdWxlcyAtIGZvciBl eGFtcGxlIHRob3NlIGRlZmluZWQgaW4gUkZDIDI2MTggdGhyb3VnaCAyNjIxPyBJZg0KPiAgICAg dGhpcyBpcyB0aGUgY2FzZSwgdGhpcyByZWxhdGlvbnNoaXAgc2hvdWxkIGJlIGRpc2N1c3NlZCBp biBvbmUgb2YNCj4gICAgIHRoZSAnbmFycmF0aXZlJyBzZWN0aW9ucyAtIHByb2JhYmx5IGluIFNl Y3Rpb24gNS4NCj4gDQo+ICAgICA2LiByYWRpdXNNSUIgaXMgYWxyZWFkeSBkZWZpbmVkIGluIG90 aGVyIGRvY3VtZW50cyAtIHNlZSBmb3IgZXhhbXBsZQ0KPiAgICAgUkZDIDI2MTkgLSAgUkFESVVT LUFVVEgtU0VSVkVSLU1JQiAtIEkgc3VnZ2VzdCB0aGF0IGl0IGlzIGltcG9ydGVkDQo+ICAgICBm cm9tIHRoZXJlLg0KPiANCg0Kc2VlIEJlcnQncyByZXNwb25zZTogdGhlIE1JQiB3aWxsIGJlIHB1 dCB1bmRlciBtaWItMi4NCg0KDQo+ICAgICA3LiBXaGF0IGlzIHRoZSBwdXJwb3NlIG9mIHRoZSBy YWRpdXNEeW5BdXRoQ2xpZW50SWRlbnRpZmllciBvYmplY3Q/DQo+ICAgICBJZiB0aGlzIGlzIGFi b3V0IHNvZnR3YXJlIHZlcnNpb25zLCBhcHBsaWNhdGlvbiBuYW1lcywgZXRjLiB0aGVyZQ0KPiAg ICAgYXJlIG9iamVjdHMgaW4gb3RoZXIgTUlCIG1vZHVsZXMgYWxyZWFkeSBkZWZpbmluZyB0aGlz IC0gc2VlIGZvcg0KPiAgICAgZXhhbXBsZSBSRkMgMjczNy4gSWYgdGhlcmUgaXMgYSBzb21ldGhp bmcgc3BlY2lmaWMgYWJvdXQgYSBSQURJVVMNCj4gICAgIGR5bmFtaWMgYXV0aGVudGljYXRpb24g Y2xpZW50IGlkZW50aWZpZXIsIHNvbWUgbW9yZSBpbmZvcm1hdGlvbiBpcw0KPiAgICAgbmVlZGVk Lg0KPiANCg0KSW4gZmFjdCwgd2UgdG9vayB0aGlzIG9iamVjdCAodG9nZXRoZXIgd2l0aCANCnJh ZGl1c0R5bkF1dGhTZXJ2ZXJJZGVudGlmaWVyIGluIA0KZHJhZnQtZGVjbm9kZGVyLXJhZGV4dC1k eW5hdXRoLWNsaWVudC1taWItMDIudHh0KSBmcm9tIFJGQyAyNjE4IHRocm91Z2ggDQpSRkMgMjYy MSB3aGVyZSB5b3UgYWxzbyBmaW5kIHRoZXNlIG9iamVjdHMgZm9yIGF1dGhlbnRpY2F0aW9uIA0K c2VydmVyL2NsaWVudCBhbmQgYWNjb3VudGluZyBzZXJ2ZXIvY2xpZW50LiBJIGFtIG5vdCBzdXJl IHdoYXQgdGhlIFdHIA0KaW50ZW50IHRvIGRvIGluIHRoZSByZXZpc2lvbiBvZiB0aGVzZSBNSUJz IChhcyBmYXIgYXMgSSBrbm93IG9ubHkgDQp1cGRhdGluZyB3aXRoIElQdjYgc3VwcG9ydCkuIElm IFJGQzI2MTgtMjYyMSBrZWVwcyB0aGVtLCBpdCBtaWdodCBiZSANCmJldHRlciBhbHNvIHRvIGtl ZXAgdGhlbSBoZXJlIHRvIG1ha2UgaXQgY29uc2lzdGVudC4gDQpyYWRpdXNEeW5BdXRoU2VydmVy SWRlbnRpZmllciBpcyB0aGUgTkFTIGlkZW50aWZpZXIgb2YgdGhlIER5bkF1dGggDQpzZXJ2ZXIs IGkuZS4gYmFzZWQgb24gdGhpcyB2YWx1ZSwgdGhlIER5bkF1dGggY2xpZW50IGNhbiBpZGVudGlm eSB0aGUgTkFTLg0KDQoNCj4gICAgIDguIERFU0NSSVBUSU9OIGNsYXVzZSBvZiByYWRpdXNEeW5B dXRoU2VydmVyRW50cnkuIEkgc3VnZ2VzdCB0byBzYXkNCj4gICAgICdyZXByZXNlbnRpbmcgb25l IER5bmFtaWMuLi4nIGluc3RlYWQgb2YgJ3JlcHJlc2VudGluZyB0aGUgRHluYW1pYy4uLicuDQo+ IA0KPiAgICAgOS4gVGhlIERFU0NSSVBUSU9OIGNsYXVzZSBvZiByYWRpdXNEeW5BdXRoU2VydmVy SW5kZXggc2hvdWxkIGJlDQo+ICAgICBjbGVhciBpbiBzYXlpbmcgdGhhdCB0aGlzIG51bWJlciBp cyBhbGxvY2F0ZWQgYnkgdGhlIGFnZW50DQo+ICAgICBpbXBsZW1lbnRpbmcgdGhpcyBNSUIgbW9k dWxlLCBhbmQgdW5pcXVlIGluIHRoaXMgY29udGV4dCAoYW5kIG5vdA0KPiAgICAgZm9yIGFuIGFk bWluIGRvbWFpbikNCj4gDQo+ICAgICAxMC4gQWRkIFJFRkVSRU5DRSBjbGF1c2VzIGZvciBvYmpl Y3RzIGRlZmluaW5nIE5BUyBhdHRyaWJ1dGVzIGZyb20NCj4gICAgIFJGQyAyODY1LCAyODY5LCAz MTYyIC0g/WZyb20gY2FzZSB0byBjYXNlDQo+IA0KPiAgICAgMTEuIERFU0NSSVBUSU9OIGNsYXVz ZSBvZiByYWRpdXNEeW5BdXRoQ2xpZW50Um91bmRUcmlwVGltZSAtIHRoaXMNCj4gICAgIHNob3Vs ZCBiZSBkZWZpbmVkIGFzIHRoZSB0aW1lIGJldHdlZW4gc2VuZGluZyBhIERpc2Nvbm5lY3Qgb3Ig Q29BDQo+ICAgICByZXF1ZXN0IGFuZCB0aGUgcmVjZXB0aW9uIG9mIGEgY29ycmVzcG9uZGluZyBE aXNjb25uZWN0LXJlcGx5L0NvQS1yZXBseQ0KPiANCj4gICAgIDEyLiB3aGF0IGFyZSB0aGUgdmFs dWVzIG9mIHRoZSBvYmplY3RzIGluIHRoZQ0KPiAgICAgcmFkaXVzRHluQXV0aFNlcnZlckVudHJ5 IHRoYXQgZGVwZW5kIG9uIHByb2Nlc3NpbmcgcmVwbGllcyBsaWtlDQo+ICAgICByYWRpdXNEeW5B dXRoQ2xpZW50Um91bmRUcmlwVGltZSBiZWZvcmUgYSBmaXJzdCByZXBseSBpcyByZWNlaXZlZA0K PiAgICAgZnJvbSB0aGUgc2VydmVyPyBGb3IgZXhhbXBsZSB3aGF0IHdpbGwgYmUgcmV0dXJuZWQg YnkgYW4gYWdlbnQNCj4gICAgIGltcGxlbWVudGluZyB0aGlzIE1JQiBtb2R1bGUgZm9yIHJhZGl1 c0R5bkF1dGhDbGllbnRSb3VuZFRyaXBUaW1lDQo+ICAgICBiZWZvcmUgYSBmaXJzdCByZXBseSBp cyByZWNlaXZlZCBhbmQgYSBtZWFuaW5nZnVsIHJvdW5kIHRyaXAgZGVsYXkNCj4gICAgIGNhbiBi ZSBwcmVzZW50ZWQ/DQo+IA0KDQpBZ3JlZWQsIEkgd2lsbCBhZGQgYW4gaW5pdGlhbCB2YWx1ZSBp biB0aGUgZGVzY3JpcHRpb24gZm9yIHRoZSANCm5vbi10cml2aWFsIGNhc2VzIChzZWVtcyB0byBi ZSB0aGF0IHJhZGl1c0R5bkF1dGhDbGllbnRSb3VuZFRyaXBUaW1lIGlzIA0KdGhlIG9ubHkgbm9u LXRyaXZpYWwgY2FzZSkuDQoNCg0KPiAgICAgMTMuIERFU0NSSVBUSU9OIGNsYXVzZSBvZiAgcmFk aXVzRHluQXV0aENsaWVudERpc2NvblBhY2tldHNEcm9wcGVkIC0NCj4gICAgIEkgc3VnZ2VzdCB0 byBhZGQgJy4uLmJ5IHRoZSBjbGllbnQgYXBwbGljYXRpb24nIGFmdGVyICdzaWxlbnRseQ0KPiAg ICAgZGlzY2FyZGVkJy4NCj4gDQo+ICAgICAxNC4gc2FtZSBmb3IgcmFkaXVzRHluQXV0aENsaWVu dENvQVBhY2tldHNEcm9wcGVkDQo+IA0KPiAgICAgMTUuIEkgc3VnZ2VzdCB0byBhZGQgVU5JVFMg Y2xhdXNlcyB0byB0aGUgY291bnRlciBvYmplY3RzIC0gcGFja2V0cywNCj4gICAgIHJldHJhbnNt aXNzaW9ucywgZXRjLg0KPiANCj4gICAgIDE2LiBTZWN0aW9uIDcsIDR0aCBwYXJhZ3JhcGggLSBz aG91bGQgYmUgJ1RoZXNlJyByYXRoZXIgdGhhbiAndGhpcycNCj4gICAgIGJlY2F1c2UgdGhlIHBo cmFzZSByZWZlcnMgdG8gdGhlIHR3byBvYmplY3RzIGFib3ZlDQo+IA0KPiAgICAgMTcuIFNlY3Rp b24gOS4xIC0gSSB3b25kZXIgaWYgcmVmZXJlbmNlcyB0byBSRkMgMjYxOCB0aHJvdWdoIDI2MjEN Cj4gICAgIGFyZSByZWFsbHkgbm9ybWF0aXZlIHJlZmVyZW5jZXMuIEkgZG8gbm90IHNlZSB0aGUg c3Ryb25nIGRlcGVuZGVuY2UNCj4gICAgIG9uIHRoZXNlIHNwZWNpZmljYXRpb25zIHRoYXQgd291 bGQganVzdGlmeSBpdC4NCj4gDQoNCnllcywgaXQgaXMgYmV0dGVyIHRvIG1ha2UgdGhlbSBJbmZv cm1hdGl2ZSBiZWNhdXNlIHRoZSBNSUJzIGFyZSANCmluZGVwZW5kZW50IGZyb20gZWFjaCBvdGhl ci4gSXQgaXMgdmVyeSBsaWtlbHkgdGhhdCBmb3IgaW5zdGFuY2UgYSBOQVMgDQppbXBsZW1lbnRz IGFsbCBNSUJzIHRvZ2V0aGVyIGJ1dCB0aGF0IGRvZXMgbm90IG1lYW4gdGhhdCB0aGV5IGFyZSAN CmRlcGVuZGVudCBmcm9tIGVhY2hvdGhlci4NCg0KPiAgICAgMTguIFRoZXJlIGlzIG5vIElBTkEg Q29uc2lkZXJhdGlvbiBzZWN0aW9uLiBFdmVuIGlmIG5vIGFjdGlvbnMgYXJlDQo+ICAgICByZXF1 aXJlZCBmcm9tIElBTkEsIHN1Y2ggYSBzZWN0aW9uIG11c3QgYmUgcHJlc2VudCBhbmQganVzdCBt ZW50aW9uDQo+ICAgICB0aGlzLioqKiAqDQo+IA0KDQpJQU5BIGNvbnNpZGVyYXRpb25zIHdpbGwg YmUgYWRkZWQuDQoNCnRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBmb3IgdGhlIG90aGVyIGNvbW1l bnRzIGFib3ZlLCBJIGFncmVlIG9uIHRoZW0uDQoNCnJlZ2FyZHMsDQoNClN0ZWZhYW4NCg0KDQo= -- to unsubscribe send a message to radiusext-request@ops.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, 01 Jan 2005 19:51:45 +0000 Date: Sat, 1 Jan 2005 14:51:14 -0500 From: Barney Wolff To: Bernard Aboba Cc: radiusext@ops.ietf.org Subject: Re: Summary: RADIUS Attribute Hiding Message-ID: <20050101195114.GA47458@pit.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i On Sat, Jan 01, 2005 at 10:40:54AM -0800, Bernard Aboba wrote: > > RFC 2548, Section 2.4.2: MS-MPPE-Send-Key > > Call the shared secret S, the pseudo-random 128-bit Request > Authenticator (from the corresponding Access-Request packet) R, > and the contents of the Salt field A. Break P into 16 octet > chunks p(1), p(2)...p(i), where i = len(P)/16. Call the > ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. > Intermediate values b(1), b(2)...c(i) are required. Encryption > is performed in the following manner ('+' indicates > concatenation): > > b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) > b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) > . . > . . > . . > b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) > > The resulting encrypted String field will contain > c(1)+c(2)+...+c(i). > > On receipt, the process is reversed to yield the plaintext String. > > > [BA] In the situation where a known plaintext attack has been carried out > and the keystream b1=MD5 (S + R) has been determined, the above salt > construction does not help much, since the MD5 calculation can be > continued using the salt field A, which is sent in the clear. Therefore, > an attacker can determine the first 16 octets of the Tunnel-Password, > using the calculated keystream b1'=MD5(S + R + A). I don't think this is correct. MD5 pads the bitstring to be hashed, so it's not obvious (to me) how to compute MD5(S+R+A) given MD5(S+R). Am I missing something here? But of course I agree with the general point, which is that future RADIUS work should use standard crypto rather than attempting amateur invention. Regards, Barney -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data@psg.com Delivery-date: Sat, 01 Jan 2005 18:41:44 +0000 Date: Sat, 1 Jan 2005 10:40:54 -0800 (PST) From: Bernard Aboba To: radiusext@ops.ietf.org Subject: Summary: RADIUS Attribute Hiding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Since there have been some questions relating to the security of RADIUS attribute hiding mechanisms, I thought I'd post a summary of RADIUS attribute hiding mechanisms, describing their vulnerabilities in more detail. First, some background on the Request and Response Authenticators and the shared secret. RFC 2865 Section 3 on the Request Authenticator: In Access-Request Packets, the Authenticator value is a 16 octet random number, called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. The Request Authenticator value in an Access-Request packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Access- Request. Section 3 also defines the RADIUS Response Authenticator: ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret) [BA] In practice, maintaining global and temporal uniqueness over the lifetime of a shared secret is a tall order. Some NAS devices do not have sufficient entropy on boot to provide temporal uniqueness. When the same shared secret is used across dozens or even thousands of devices (a common deployment scenario), global and temporal uniqueness can become very difficult to satisfy. In retrospect, it would have made more sense to mix a globally unique quantity (such as NAS-Identifier or NAS-IP-Address) in subsequent calculations, including in the Response Authenticator, so as to make global uniqueness more likely. Here is what RFC 2865, Section 3 has to say about the shared secret: The secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well- chosen password. It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged. [BA] At IETF60, we discussed the consequences of violating this prescription, namely that the Response Authenticator becomes subject to dictionary attack. The encryption algorithm for the User-Password attribute is described in RFC 2865, Section 5.1: Call the shared secret S and the pseudo-random 128-bit Request Authenticator RA. Break the password into 16-octet chunks p1, p2, etc. with the last one padded at the end with nulls to a 16-octet boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need intermediate values b1, b2, etc. b1 = MD5(S + RA) c(1) = p1 xor b1 b2 = MD5(S + c(1)) c(2) = p2 xor b2 . . . . . . bi = MD5(S + c(i-1)) c(i) = pi xor bi The String will contain c(1)+c(2)+...+c(i) where + denotes concatenation. [BA] Note that the first block of the keystream b1 is based solely on the shared secret and the Request Authenticator, and does not include any NAS-specific information (e.g. NAS-Identifier or NAS-IP-Address). Thus, if the Request Authenticator is not temporally and globally unique for a given shared secret, the keystream will repeat. This can be exploited in a number of ways. When two identical Response Authenticators are found on the same NAS, or on two different NASes that are known to share the same secret S, the ciphertexts can be XOR'd yielding the XOR of the first clearext password blocks. This can assist an attacker in guessing the user passwords; once those are determined the keystream b1 is also known. Another way is via a known-plaintext attack, where an attacker attempts authentication with password p, and then collects the ciphertext c, allowing the keystream b to be calculated. If the Request Authenticator ever repeats, the attacker can use the known value of b1 and the c1 collected from the User-Password attribute to calculate the first 16 octets of the password p1. Note that both of these attacks do not require the attacker to compromise the password S. RFC 2548, Section 2.4.2: MS-MPPE-Send-Key Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) The resulting encrypted String field will contain c(1)+c(2)+...+c(i). On receipt, the process is reversed to yield the plaintext String. [BA] In the situation where a known plaintext attack has been carried out and the keystream b1=MD5 (S + R) has been determined, the above salt construction does not help much, since the MD5 calculation can be continued using the salt field A, which is sent in the clear. Therefore, an attacker can determine the first 16 octets of the Tunnel-Password, using the calculated keystream b1'=MD5(S + R + A). RFC 2868, Section 3.5: Tunnel-Password Call the shared secret S, the pseudo-random 128-bit Request Authenticator (from the corresponding Access-Request packet) R, and the contents of the Salt field A. Break P into 16 octet chunks p(1), p(2)...p(i), where i = len(P)/16. Call the ciphertext blocks c(1), c(2)...c(i) and the final ciphertext C. Intermediate values b(1), b(2)...c(i) are required. Encryption is performed in the following manner ('+' indicates concatenation): b(1) = MD5(S + R + A) c(1) = p(1) xor b(1) C = c(1) b(2) = MD5(S + c(1)) c(2) = p(2) xor b(2) C = C + c(2) . . . . . . b(i) = MD5(S + c(i-1)) c(i) = p(i) xor b(i) C = C + c(i) The resulting encrypted String field will contain c(1)+c(2)+...+c(i). On receipt, the process is reversed to yield the plaintext String. [BA] The Tunnel-Password attribute utilizes the same construction as the MS-MPPE-Send-Key attribute, and therefore has the same weakness. SUMMARY In order to prevent forgeries and keystream recovery, RADIUS requires that the Request Authenticator be globally and temporally unique. However, in practice implemenations and deployments often do not satisfy this requirement. Due to deficiencies in the construction of the Response Authenticator and attribute hiding algorithms, the problem is magnified. To address these problems, future attribute hiding algorithms would be wise to do one or more of the following: a. Utilize a well-analyzed keywrap mechanism based on a block cipher, rather than the add-hoc stream ciphers used in RADIUS. b. Mix in NAS-specific attributes into the calculation, ensuring global uniqueness. c. Utilize randomness from two parties (RADIUS client + RADIUS server). A minimum of 128-bit nonces are recommended. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: