Subject: re: Issue 37: Merging of Filter Attributes
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>
Date: Mon, 31 Jan 2005 15:30:30 -0800

Dave Nelson and other argue over...

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

MS

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

Delivery-date: Mon, 31 Jan 2005 21:33:13 +0000
Date: Mon, 31 Jan 2005 13:32:50 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: "'Murtaza Chiba'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator

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

Delivery-date: Mon, 31 Jan 2005 20:31:54 +0000
Date: Mon, 31 Jan 2005 15:25:05 -0500
From: Barney Wolff <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, "'Murtaza Chiba'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator

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

Delivery-date: Mon, 31 Jan 2005 20:00:34 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Murtaza Chiba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator
Date: Mon, 31 Jan 2005 11:59:51 -0800

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

Delivery-date: Mon, 31 Jan 2005 20:00:26 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator
Date: Mon, 31 Jan 2005 11:59:51 -0800

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

Delivery-date: Mon, 31 Jan 2005 05:38:54 +0000
Date: Sun, 30 Jan 2005 21:38:20 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Murtaza Chiba <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator

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
>
> [email-masked] wrote:
> > Bernard,
> >
> > I agree with your proposal.
> >
> > John

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

Delivery-date: Mon, 31 Jan 2005 00:54:43 +0000
Date: Sun, 30 Jan 2005 16:54:26 -0800
From: Murtaza Chiba <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [Issue] RFC 3576 Usage of Message-Authenticator

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

[email-masked] wrote:
> Bernard,
> 
> I agree with your proposal.
> 
> John
> 
> 
>>-----Original Message-----
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of ext Bernard Aboba
>>Sent: 29 January, 2005 02:37
>>To: [email-masked]
>>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 [email-masked] with
>>the word 'unsubscribe' in a single line as the message text body.
>>archive: <http://psg.com/lists/radiusext/>
>>
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Sun, 30 Jan 2005 20:20:32 +0000
Content-class: urn:content-classes:message
Subject: RE: [Issue] RFC 3576 Usage of Message-Authenticator
Date: Sun, 30 Jan 2005 22:16:57 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Bernard,

I agree with your proposal.

John

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Bernard Aboba
> Sent: 29 January, 2005 02:37
> To: [email-masked]
> 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Sat, 29 Jan 2005 00:38:23 +0000
Date: Fri, 28 Jan 2005 16:37:12 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 27 Jan 2005 15:48:19 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Thu, 27 Jan 2005 10:47:43 -0500

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

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

Delivery-date: Wed, 26 Jan 2005 02:38:18 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 25 Jan 2005 18:38:00 -0800

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

Delivery-date: Wed, 26 Jan 2005 00:37:49 +0000
Date: Tue, 25 Jan 2005 16:37:34 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Issue 37: Merging of Filter Attributes

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

Delivery-date: Wed, 26 Jan 2005 00:15:31 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 25 Jan 2005 16:15:03 -0800
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 25 Jan 2005 22:28:25 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 25 Jan 2005 17:27:18 -0500
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

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.

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

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

Delivery-date: Tue, 25 Jan 2005 22:20:01 +0000
Date: Tue, 25 Jan 2005 14:19:10 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: Issue 37: Merging of Filter Attributes

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

Delivery-date: Tue, 25 Jan 2005 18:40:50 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Tue, 25 Jan 2005 13:40:20 -0500
To: <[email-masked]>

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

Delivery-date: Tue, 25 Jan 2005 16:24:38 +0000
From: Avi Lior <[email-masked]>
To: "'Sanchez, Mauricio (PNB Roseville)'" <[email-masked]>,  [email-masked]
Subject: RE: Issue 38 - Ordering of filter attributes
Date: Tue, 25 Jan 2005 11:24:00 -0500

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:[email-masked]] 
> Sent: Monday, January 24, 2005 5:49 PM
> To: [email-masked]
> 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
> [email-masked]
> --------------------------------------------    
> 
> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, January 03, 2005 5:04 PM
> To: Congdon, Paul T (ProCurve)
> Cc: Nelson, David; Joseph Salowey; [email-masked]; 
> Romascanu, Dan (Dan); Jari Arkko; Sanchez, Mauricio (PNB 
> Roseville); Black, Chuck A; [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 24 Jan 2005 23:29:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 37: Merging of Filter Attributes
Date: Mon, 24 Jan 2005 15:28:53 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

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

Cheers,
MS

-----Original Message-----
From: Congdon, Paul T (ProCurve)
Sent: Tuesday, December 14, 2004 3:08 PM
To: 'Bernard Aboba'; [email-masked]
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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Monday, December 13, 2004 6:46 PM
> To: [email-masked]
> Subject: Issue 37: Merging of Filter Attributes
> 
> Issue 37: Merging of Filter Attributes Submitter name: Bernard Aboba 
> Submitter email address: [email-masked] Date first
> submitted: December 13, 2004
> Reference:
> Document: Congdon-02
> Comment type: T
> Priority: S
> Section: 2.7
> Rationale/Explanation of issue:
> Section 2.7 does not state what happens if both Filter-ID and 
> NAS-Filter-Rule attributes are included in an Access-Accept.
> How are the filters merged?
> 
> Suggest the addition of the following text:
> 
> "If both Filter-ID and NAS-Filter-Rule attributes are included within 
> an Access-Request or Access-Accept packet, the filter specified by the

> NAS-Filter-Rule attribute is considered to be appended to the end of 
> the filter list specified by the Filter-ID attribute.
> 
> As a result, if the Filter-ID attribute specifies that a packet is to 
> be discarded, then the filter specified by NAS-Filter-Rule can have no

> effect on the processing of that packet, since it will have already 
> been discarded prior to examination by the filter specified in 
> NAS-Filter-Rule."
> 
> 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in a single

> line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 24 Jan 2005 23:08:09 +0000
Content-class: urn:content-classes:message
Subject: Issue: 'key' attributes in IEEE802 draft
Date: Mon, 24 Jan 2005 15:07:49 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

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. 

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
[email-masked]
--------------------------------------------   

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

Delivery-date: Mon, 24 Jan 2005 22:50:05 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 38 - Ordering of filter attributes
Date: Mon, 24 Jan 2005 14:49:28 -0800
From: "Sanchez, Mauricio (PNB Roseville)" <[email-masked]>
To: <[email-masked]>

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
[email-masked]
--------------------------------------------    

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, January 03, 2005 5:04 PM
To: Congdon, Paul T (ProCurve)
Cc: Nelson, David; Joseph Salowey; [email-masked]; Romascanu, Dan
(Dan); Jari Arkko; Sanchez, Mauricio (PNB Roseville); Black, Chuck A;
[email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 24 Jan 2005 04:22:55 +0000
Date: Mon, 24 Jan 2005 06:21:56 +0200 (EET)
From: John Loughney <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Response to Issue 46 - status so far 
Cc: [email-masked], [email-masked]

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

------=_Part_127_13866071.1106540516332--

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

Delivery-date: Mon, 24 Jan 2005 03:02:59 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46 - status so far 
Date: Sun, 23 Jan 2005 19:02:17 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

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

Delivery-date: Mon, 24 Jan 2005 02:01:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 52: Review of CUI-01 -- summary of changes
Date: Sun, 23 Jan 2005 18:00:52 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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.  

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?  

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, January 08, 2005 3:42 PM
> To: [email-masked]
> Subject: Issue 52: Review of CUI-01
> 
> 
> Issue 52: Review of CUI-01
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> 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.
> 
[FA] Done.

> Section 1.1
> 
> The first two paragraphs appear like they belong better in Section 1.
> 

[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.  
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."
> 
> This is not a sentence. Should this be
> "One missing element is a mechanism for...."
> 
[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."
> 
> 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.
> 

[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."
> 
> 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] 

You are right that 2865 does specify the ordering of class.  But it is
still an issue.  

An intermediary receives an list of class attributes: 
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."

> 
> "     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:
> [email-masked].
> 
> 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 "[email-masked]". However, without
> decoration, the resulting Accounting-Request would be routed
> differently than the Access-Request, which might cause problems.
> Section 2.1
> 
[FA] Based on our email exchanges on this thread, I agree your proposed
text (with some minor modification/editing): 

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

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

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

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

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

[FA] As per our e-mail discussions, we agreed to remove this.  So, it
was removed.

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

[FA] Removed.

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

> 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.
> 
[FA]

"This document instructs IANA to assign a new value for Error-Cause
attribute [RFC3576], ..."

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

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

Delivery-date: Sat, 22 Jan 2005 08:42:18 +0000
Date: Thu, 20 Jan 2005 13:12:13 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Subject: Re: Proposal: Capabilities Attribute

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

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

Delivery-date: Fri, 21 Jan 2005 16:11:06 +0000
Date: Fri, 21 Jan 2005 10:10:28 -0600
From: Pete McCann <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
Cc: [email-masked]
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 [email-masked] with
 > the word 'unsubscribe' in a single line as the message text body.
 > archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Fri, 21 Jan 2005 14:59:55 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-radext-digest-auth; SIP-AOR
Date: Fri, 21 Jan 2005 15:25:58 +0100

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

Delivery-date: Fri, 21 Jan 2005 14:56:28 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: draft-ietf-radext-digest-auth, Securit Considerations section
Date: Fri, 21 Jan 2005 15:22:50 +0100

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

Delivery-date: Fri, 21 Jan 2005 02:39:35 +0000
Date: Thu, 20 Jan 2005 18:39:01 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: IETF Internet Draft Submission Deadlines

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

Delivery-date: Thu, 20 Jan 2005 16:38:30 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposal: Capabilities Attribute
Date: Thu, 20 Jan 2005 18:37:30 +0200
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

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

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

Delivery-date: Thu, 20 Jan 2005 11:13:30 +0000
Date: Thu, 20 Jan 2005 13:12:13 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Subject: Re: Proposal: Capabilities Attribute

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

Delivery-date: Thu, 20 Jan 2005 04:11:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposal: Capabilities Attribute
Date: Thu, 20 Jan 2005 06:10:27 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

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

John

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

Delivery-date: Thu, 20 Jan 2005 01:09:47 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposal: Capabilities Attribute
Date: Wed, 19 Jan 2005 17:09:16 -0800
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Barney Wolff" <[email-masked]>, <[email-masked]>

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

I think you could also add NAS-Filter-Rule to the list.

Paul

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

Delivery-date: Wed, 19 Jan 2005 18:39:37 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Wed, 19 Jan 2005 13:39:07 -0500

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:[email-masked]] 
> Sent: Tuesday, January 18, 2005 3:35 PM
> To: [email-masked]
> Subject: RE: Proposal: Capabilities Attribute
> 
> 
> Avi Lior writes...
> 
> > Well I think I wasn't making my point clear:
> 
> <snip>
>  
> > 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 18 Jan 2005 20:35:24 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 15:34:58 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> Well I think I wasn't making my point clear:

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

Delivery-date: Tue, 18 Jan 2005 20:35:17 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 15:35:10 -0500

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

Delivery-date: Tue, 18 Jan 2005 20:25:02 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: Avi Lior <[email-masked]>, Barney Wolff <[email-masked]>, [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 15:24:45 -0500

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:[email-masked]] 
> Sent: Tuesday, January 18, 2005 2:46 PM
> To: Nelson, David
> Cc: Avi Lior; Barney Wolff; [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 19:49:58 +0000
Date: Tue, 18 Jan 2005 14:49:53 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Proposal: Capabilities Attribute

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

Delivery-date: Tue, 18 Jan 2005 19:45:58 +0000
Date: Tue, 18 Jan 2005 11:45:49 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: Avi Lior <[email-masked]>, Barney Wolff <[email-masked]>, [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 19:27:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilites and Sub-capabilities -- was RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 14:26:29 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Barney Wolff" <[email-masked]>, <[email-masked]>

Avi Lior writes...

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

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

Delivery-date: Tue, 18 Jan 2005 19:22:23 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Barney Wolff <[email-masked]>,  [email-masked]
Subject: Capabilites and Sub-capabilities -- was RE: Proposal: Capabilitie s Attribute
Date: Tue, 18 Jan 2005 14:22:11 -0500

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:[email-masked]] 
> Sent: Tuesday, January 18, 2005 2:09 PM
> To: Avi Lior; Barney Wolff; [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 19:09:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 14:08:39 -0500
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Barney Wolff" <[email-masked]>, <[email-masked]>

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

Delivery-date: Tue, 18 Jan 2005 19:03:29 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 14:03:18 -0500

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:[email-masked]] 
> Sent: Tuesday, January 18, 2005 1:46 PM
> To: Avi Lior
> Cc: [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 18:46:03 +0000
Date: Tue, 18 Jan 2005 13:45:52 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 18:25:44 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 13:25:36 -0500

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:[email-masked]] 
> Sent: Tuesday, January 18, 2005 12:38 PM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 18 Jan 2005 18:23:14 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46 
Date: Tue, 18 Jan 2005 13:21:53 -0500
From: "Nelson, David" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: <[email-masked]>

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

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

Delivery-date: Tue, 18 Jan 2005 18:08:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46 
Date: Tue, 18 Jan 2005 10:08:17 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, January 17, 2005 10:24 AM
> To: [email-masked]
> Subject: RE: Response to Issue 46 
> 
> 
> 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 [email-masked] might 
> be aliased
> as [email-masked], 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 18 Jan 2005 17:38:32 +0000
Date: Tue, 18 Jan 2005 12:38:16 -0500
From: Barney Wolff <[email-masked]>
To: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 18 Jan 2005 16:57:20 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 11:57:16 -0500

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:[email-masked]] 
> Sent: Monday, January 17, 2005 1:23 AM
> To: Glen Zorn (gwz)
> Cc: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 18 Jan 2005 16:56:24 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Glen Zorn (gwz)" <[email-masked]>
Cc: [email-masked]
Subject: RE: Proposal: Capabilities Attribute
Date: Tue, 18 Jan 2005 11:55:39 -0500

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:[email-masked]] 
> Sent: Monday, January 17, 2005 1:23 AM
> To: Glen Zorn (gwz)
> Cc: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Mon, 17 Jan 2005 18:24:29 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46 
Date: Mon, 17 Jan 2005 13:24:24 -0500
To: <[email-masked]>

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

Delivery-date: Mon, 17 Jan 2005 18:20:43 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46 
Date: Mon, 17 Jan 2005 10:19:57 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Sunday, January 16, 2005 10:17 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked]
> Subject: Re: Response to Issue 46 
> 
> 
> 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.
>

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. 

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

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?

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

Delivery-date: Mon, 17 Jan 2005 13:47:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Response to Issue 46
Date: Mon, 17 Jan 2005 15:45:41 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard,

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

I agree.

> > 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 agree with Jari on this.
 
John

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

Delivery-date: Mon, 17 Jan 2005 08:05:18 +0000
Date: Mon, 17 Jan 2005 10:04:04 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "Adrangi, Farid" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Response to Issue 46

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

Delivery-date: Mon, 17 Jan 2005 06:23:06 +0000
Date: Sun, 16 Jan 2005 22:23:01 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
cc: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 17 Jan 2005 06:17:52 +0000
Date: Sun, 16 Jan 2005 22:17:27 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Response to Issue 46 

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

Delivery-date: Mon, 17 Jan 2005 03:52:08 +0000
Content-class: urn:content-classes:message
Subject: Response to Issue 46 
Date: Sun, 16 Jan 2005 19:51:31 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

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

Delivery-date: Mon, 17 Jan 2005 02:40:37 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>
Subject: RE: Proposal: Capabilities Attribute
Date: Sun, 16 Jan 2005 18:39:53 -0800

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

Delivery-date: Sun, 16 Jan 2005 22:06:43 +0000
Date: Sun, 16 Jan 2005 14:06:36 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Proposal: Capabilities Attribute

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

Delivery-date: Sun, 16 Jan 2005 21:59:18 +0000
Date: Sun, 16 Jan 2005 13:58:50 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: [email-masked]
Subject: RE:Issue 52: Review of CUI-01

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

Delivery-date: Sun, 16 Jan 2005 20:40:04 +0000
Content-class: urn:content-classes:message
Subject: RE:Issue 52: Review of CUI-01
Date: Sun, 16 Jan 2005 12:39:14 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

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.  
BR,
Farid
 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Saturday, January 08, 2005 3:42 PM
> To: [email-masked]
> Subject: Issue 52: Review of CUI-01
> 
> 
> Issue 52: Review of CUI-01
> Submitter name: Bernard Aboba
> Submitter email address: [email-masked]
> 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.
> 
 
Good suggestion.  Will do.
 
> Section 1.1
> 
> The first two paragraphs appear like they belong better in Section 1.
> 
 
Makes sense - Will move it up.
 
> "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...."
 
yes.
 
> 
> "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.
> 

Ok.
 
> "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.
 
Ok.
 
> 
> "     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:
> [email-masked].
> 
 
> 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 "[email-masked]". However, without
> decoration, the resulting Accounting-Request would be routed
> differently than the Access-Request, which might cause problems.
> Section 2.1
> 
 
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?
 
"
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., [email-masked]) 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 <mailto:[email-masked]> .  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 <mailto:[email-masked]> @example.com
<mailto:[email-masked]> ) 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.
 
"
 
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?
 
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.

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

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

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

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

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

> 
> 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.
 
Yes, right!

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

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

------_=_NextPart_001_01C4FC0B.710F1535
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.2800.1480" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN class=403435717-16012005>Hi 
Bernard,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=403435717-16012005>Thanks for your 
comments/feedbacks/corrections.&nbsp;&nbsp; I agree with most of your comments 
-- we will incorporate them into the next version.&nbsp; Please see 
my&nbsp;comments&nbsp;inline.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=403435717-16012005>BR,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=403435717-16012005>Farid</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; -----Original Message-----<BR>&gt; From: <A 
href="mailto:[email-masked]">[email-masked]</A> 
<BR>&gt; [mailto:[email-masked]] On Behalf Of Bernard 
Aboba<BR>&gt; Sent: Saturday, January 08, 2005 3:42 PM<BR>&gt; To: <A 
href="mailto:[email-masked]">[email-masked]</A><BR>&gt; Subject: 
Issue 52: Review of CUI-01<BR>&gt; <BR>&gt; <BR>&gt; Issue 52: Review of 
CUI-01<BR>&gt; Submitter name: Bernard Aboba<BR>&gt; Submitter email address: <A 
href="mailto:[email-masked]">[email-masked]</A><BR>&gt; Date first 
submitted: January 8, 2004<BR>&gt; Reference:<BR>&gt; Document: CUI-01<BR>&gt; 
Comment type: T<BR>&gt; Priority: S<BR>&gt; Section: Various<BR>&gt; 
Rationale/Explanation of issue:<BR>&gt; Section 1<BR>&gt; <BR>&gt; " For 
example, local or intermediate networks may limit the number of<BR>&gt; 
simultaneous sessions for specific users; they may require a<BR>&gt; 
chargeable-user-identity in order to demonstrate willingness to pay<BR>&gt; or 
otherwise limit the potential for fraud.<BR>&gt; <BR>&gt; This implies that an 
authenticated and unique identity provided by<BR>&gt; the home network should be 
able to be conveyed to all parties<BR>&gt; involved in the roaming transaction 
for correlating the<BR>&gt; authentication and accounting packets.<BR>&gt; 
<BR>&gt; Providing a unique identity, called the 
Chargeable-User-Identity<BR>&gt; (CUI) to intermediaries, is necessary to 
fulfill certain business<BR>&gt; needs. This should not undermine the anonymity 
of the user. The<BR>&gt; mechanism provided by this draft allows the home 
operator to meet<BR>&gt; these business requirements by providing a temporary 
identity<BR>&gt; representing the subscriber and at the same time protecting 
the<BR>&gt; anonymity of the subscriber."<BR>&gt; <BR>&gt; There is a tradeoff 
between providing an authenticated and<BR>&gt; unique identity to all parties 
suitable for correlation, while also<BR>&gt; not compromising some aspects of 
privacy.<BR>&gt; <BR>&gt; Later on in Section 1.1, it is stated:<BR>&gt; 
<BR>&gt; "&nbsp; When the home network assigns a value 
to<BR>&gt;&nbsp;&nbsp;&nbsp; the CUI, it asserts that this value represents a 
user in the home<BR>&gt;&nbsp;&nbsp;&nbsp; network.&nbsp; The assertion should 
be temporary.&nbsp; Long enough to be<BR>&gt;&nbsp;&nbsp;&nbsp; useful for the 
external applications and not too long such that it<BR>&gt;&nbsp;&nbsp;&nbsp; 
can be used to identify the user."<BR>&gt; <BR>&gt; I think this paragraph helps 
clarify the tradeoff, so that it<BR>&gt; should follow the paragraph 
above.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial>Good suggestion.&nbsp; Will do.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; Section 1.1<BR>&gt; <BR>&gt; The first two 
paragraphs appear like they belong better in Section 1.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><SPAN class=403435717-16012005>Makes sense - </SPAN>Will 
move it up.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; "A mechanism for providing the current 
deployments wit<BR>&gt; the capacity to deploy, bill and oversee WPA networks 
against fraud."<BR>&gt; <BR>&gt; This is not a sentence. Should this be<BR>&gt; 
"One missing element is a mechanism for...."</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial>yes.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; <BR>&gt; "Therefore whether a RADIUS<BR>&gt; 
server/proxy or client accepts or rejects the presence or lack of<BR>&gt; 
presence of the CUI attribute is a matter of business policy."<BR>&gt; <BR>&gt; 
This statement appears to come out of the blue. We are just<BR>&gt; getting into 
a discussion of usage scenarios, and suddenly<BR>&gt; we jump to a discussion 
which appears to be about backward<BR>&gt; compatibility. I'd suggest you move 
this sentence later<BR>&gt; in the document where it may be better put in 
context.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2><BR><FONT size=3>Ok.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; "Additionally,<BR>&gt; there could be multiple 
class attributes in a RADIUS packet with<BR>&gt; unspecified ordering, which 
makes it hard to the entities outside<BR>&gt; home network to determine which 
one contains the CUI."<BR>&gt; <BR>&gt; RFC 2865 does specify that attributes of 
the same type are not<BR>&gt; reordered by proxies, so I don't think ordering is 
an issue.<BR>&gt; The problem is opacity, which would occur whether a 
single<BR>&gt; Class attribute was used, or multiple attributes. My<BR>&gt; 
recommendation is to delete this sentence.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><SPAN class=403435717-16012005>Ok</SPAN>.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; <BR>&gt; "&nbsp;&nbsp;&nbsp;&nbsp; The home 
network could use User-Name(1) in the 
Access-Accept<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; message to convey the 
CUI to intermediaries and the <BR>&gt; NAS.&nbsp; 
However,<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as the Access-Accept packet 
is routed to the NAS, the <BR>&gt; 
User-Name(1)<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute could be 
(completely) rewritten by an intermediary 
and<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; therefore the NAS or other 
intermediaries along the way will 
not<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; have access to the CUI.&nbsp; 
Furthermore, the NAS may use <BR>&gt; the 
original<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; value of the User-Name(1) 
attribute (the one sent in the<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
Access-Request packet) in the Accounting-Request <BR>&gt; packets to 
ensure<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the billing follows the same 
path as authentication packets."<BR>&gt; <BR>&gt; To my knowledge, existing 
implementations do not rewrite a User-Name<BR>&gt; attribute sent in an 
Access-Accept, since a proxy-state attribute<BR>&gt; can be used to enable 
routing of the Access-Accept back to the NAS<BR>&gt; without examining the 
User-Name attribute. So the issue is not<BR>&gt; rewriting so much as the 
potential impact on routing of accounting<BR>&gt; packets. For example, the 
original "privacy" NAI in the<BR>&gt; EAP-Response/Identity might have 
been:<BR>&gt; <A 
href="mailto:[email-masked]">[email-masked]</A>.<BR>&gt; 
</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&gt; This is rewritten by isp.com to 
"@example.com". As a result,<BR>&gt; the example.com RADIUS server may not even 
be aware of isp.com<BR>&gt; as an intermediary, and might send a User-Name 
attribute in the<BR>&gt; Access-Accept of "<A 
href="mailto:[email-masked]">[email-masked]</A>". However, 
without<BR>&gt; decoration, the resulting Accounting-Request would be 
routed<BR>&gt; differently than the Access-Request, which might cause 
problems.<BR>&gt; Section 2.1<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT face=Arial>I think the second half of the paragraph 
addresses the above problem<SPAN class=403435717-16012005> w.r.t decoration and 
routing</SPAN>.&nbsp; Maybe we should add an example for 
clarification.&nbsp;&nbsp;<SPAN class=403435717-16012005> How about we revise 
the paragraph to something like this?</SPAN></FONT></FONT></DIV>
<DIV><FONT size=2><FONT face=Arial><SPAN 
class=403435717-16012005></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT size=2><FONT face=Arial><SPAN 
class=403435717-16012005>"</SPAN></FONT></FONT></DIV>
<DIV><FONT><SPAN class=403435717-16012005><FONT face=Arial size=2>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.&nbsp; For example, the EAP peer 
may construct the NAI with additional information (e.g., <A 
href="mailto:[email-masked]">[email-masked]</A>) to 
influence routing of the AAA packet through a preferred intermediary 
network.&nbsp; This is rewritten by the intermediary network (i.e., 
"intermediary.com" ) to <A 
href="mailto:[email-masked]">example.com</A>.&nbsp; 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., <A 
href="mailto:[email-masked]">CUI<A 
href="mailto:[email-masked]">@example.com</A></A>) in the Access-Accept to the 
NAS.&nbsp; If the NAS uses the User-Name(1)&nbsp;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.&nbsp;&nbsp; If the NAS uses the 
original NAI sent in the Access-Request, then the&nbsp;CUI&nbsp; will not be 
included in the Accounting-Request.&nbsp; </FONT></SPAN></FONT><FONT face=Arial 
size=2><SPAN class=403435717-16012005>Furthermore,&nbsp;&nbsp;in some 
deployments, as the Access-Accept packet is routed to the NAS, 
the&nbsp;User-Name(1) attribute could be (completely) rewritten by 
an&nbsp;intermediary and therefore the NAS or other intermediaries&nbsp;along 
the way will not have access to the CUI.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=403435717-16012005></SPAN></FONT><FONT><SPAN 
class=403435717-16012005><FONT size=2><FONT 
face=Arial></FONT></FONT></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=403435717-16012005>"</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN 
class=403435717-16012005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=403435717-16012005><FONT size=2><FONT face=Arial>Section 
2.1</FONT></DIV></FONT></SPAN></FONT><FONT size=2>
<DIV><FONT face=Arial></FONT><FONT face=Arial></FONT><FONT 
face=Arial></FONT><BR></FONT><FONT face=Arial size=2>&gt; "RADIUS clients (proxy 
or NAS) outside<BR>&gt; the home network MUST NOT modify the CUI 
attribute."<BR>&gt; <BR>&gt; I think you want to say that RADIUS proxies MUST 
NOT modify the CUI<BR>&gt; attribute, and that NAS devices that support CUI MUST 
include <BR>&gt; it in the<BR>&gt; Accounting-Request unmodified, 
no?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=403435717-16012005><FONT face=Arial>Your statement is 
correct.&nbsp; And we say that&nbsp;in sectoin 2.1&nbsp;-- couple of paragraphs 
below.&nbsp; but here we are simply stating that the entities outside the home 
network MUST NOT modify CUI.</FONT></SPAN></DIV><FONT face=Arial 
size=2></FONT><FONT face=Arial size=2></FONT>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><BR><FONT face=Arial size=2>&gt; <BR>&gt; "&nbsp; RADIUS client 
(Proxy or NAS) that does not support the CUI <BR>&gt; 
attribute<BR>&gt;&nbsp;&nbsp;&nbsp; MAY ignore this attribute or MAY treat the 
Access-Accept as<BR>&gt;&nbsp;&nbsp;&nbsp; Access-Reject."<BR>&gt; <BR>&gt; 
Rather than including this paragraph, I would cite RFC 2865 <BR>&gt; with 
respect<BR>&gt; to behavior on receipt of an unimplemented attribute in an 
<BR>&gt; Access-Accept.<BR>&gt; That way you are guaranteed not to be updating 
RFC 2865.<BR>&gt; For example, RFC 2865 only indicates that an 
Access-Accept<BR>&gt; is treated as an Access-Reject if the service cannot be 
provided.<BR>&gt; This would require a different value of the Service-Type 
attribute,<BR>&gt; which is not used here. So the statement above represents a 
major<BR>&gt; change to RFC 2865, which is already a Draft Standard.<BR>&gt; 
</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=403435717-16012005><FONT face=Arial>You are right, so how 
about this?</FONT></SPAN></FONT></DIV>
<DIV><FONT face=Arial><SPAN class=403435717-16012005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><SPAN class=403435717-16012005>"</SPAN></FONT></DIV>
<DIV><FONT face=Arial><SPAN class=403435717-16012005>RFC 2865 states that A 
RADIUS server or client&nbsp;<FONT face="Times New Roman"> ignore Attributes 
with an unknown Type.</FONT>&nbsp;Therefore, &nbsp;RADIUS client (Proxy or NAS) 
that does not support the CUI attribute MAY ignore this 
attribute.</SPAN></FONT></DIV>
<DIV><FONT><SPAN class=403435717-16012005><FONT 
face=Arial>"</FONT></SPAN></DIV><FONT face=Arial size=2></FONT>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><FONT face=Arial size=2></FONT><BR><FONT face=Arial size=2>&gt; 
"&nbsp; If RADIUS client (Proxy or NAS) requires the presence of the 
CUI<BR>&gt;&nbsp;&nbsp;&nbsp; attribute in the Access-Accept, it MUST indicate 
its requirement by<BR>&gt;&nbsp;&nbsp;&nbsp; including this attribute with a nul 
character for its data field<BR>&gt;&nbsp;&nbsp;&nbsp; (hereafter, it is also 
referred to as a nul CUI) in the<BR>&gt;&nbsp;&nbsp;&nbsp; Access-Request 
message."<BR>&gt; <BR>&gt; A cleaner approach might be to include a 
Capabilities<BR>&gt; attribute including the Type codes of (standard) 
attributes<BR>&gt; that the NAS is advertising support for. That way a 
single<BR>&gt; attribute could be used to advertise support for up to 
253<BR>&gt; attributes.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT><FONT face=Arial><SPAN class=403435717-16012005>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&nbsp; to accelerate 
this.</SPAN></FONT></FONT></DIV><FONT><FONT><SPAN 
class=403435717-16012005></SPAN>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><BR><FONT face=Arial size=2>&gt; <BR>&gt; "&nbsp; If the NAS 
supports CUI attribute then the CUI attribute <BR>&gt; MAY also 
be<BR>&gt;&nbsp;&nbsp;&nbsp; used as one of the identity attribute in Disconnect 
Message and<BR>&gt;&nbsp;&nbsp;&nbsp; Change of Authorization messages defined 
by [RFC3576].&nbsp; <BR>&gt; Determination<BR>&gt;&nbsp;&nbsp;&nbsp; of NAS 
support for the CUI is outside the scope of this document."<BR>&gt; <BR>&gt; I 
don't think this is a good idea. There is already an issue in<BR>&gt; 
translation of RFC 3576 messages into equivalent<BR>&gt; Diameter messages and 
this is going to make it harder.<BR>&gt; In retrospect, we probably should have 
been more<BR>&gt; strict with respect to identification in RFC 3576,<BR>&gt; 
such as requiring the Session-Id as a unique identifier.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><SPAN class=403435717-16012005></SPAN><FONT face=Arial><FONT size=2><SPAN 
class=403435717-16012005><FONT size=3>Are you implying that RADIUS has a 
session-id -- I wasn't aware of that.&nbsp; I thought Glen Zorn is proposing 
this in one of his drafts.&nbsp; Anyhow, </FONT></SPAN><SPAN 
class=403435717-16012005><FONT size=3>&nbsp;I guess you are suggesting to remove 
this paragraph - yes?</FONT>&nbsp; &nbsp;</SPAN></FONT></FONT></DIV><SPAN 
class=403435717-16012005></SPAN><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT>
<DIV><FONT face=Arial size=2></FONT><BR><FONT face=Arial>&gt; Section 3<BR>&gt; 
<BR>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0-1&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 101&nbsp;&nbsp; 
Error-Cause<BR>&gt; <BR>&gt; This would seem to be updating RFC 3579 and RFC 
3576.&nbsp; Please <BR>&gt; delete this<BR>&gt; line.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><SPAN class=403435717-16012005></SPAN><FONT face=Arial>O<SPAN 
class=403435717-16012005>k.</SPAN><BR></FONT></DIV>
<DIV><FONT face=Arial>&gt; Section 4<BR>&gt; <BR>&gt; "&nbsp; In deployments 
with both RADIUS and Diameter interworking, a<BR>&gt;&nbsp;&nbsp;&nbsp; 
translation agent will be deployed and operate in accordance to 
the<BR>&gt;&nbsp;&nbsp;&nbsp; NASREQ specification."<BR>&gt; <BR>&gt; Why is 
translation required? Shouldn't Diameter just define <BR>&gt; an 
identical<BR>&gt; attribute with the same Type value? And isn't CUI used in 
applications<BR>&gt; other than NASREQ, such as EAP?</FONT></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><SPAN class=403435717-16012005><FONT face=Arial>NASREQ does not have this 
attribute.&nbsp; Does NASREQ automatically cover new RADIUS attributes?&nbsp; 
CUI will not be used in EAP - unless you correct me by describing a use-case for 
it.</FONT></SPAN></DIV><SPAN class=403435717-16012005><FONT 
face=Arial></FONT></SPAN><FONT>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><BR><FONT face=Arial>&gt; <BR>&gt; Section 5.2<BR>&gt; <BR>&gt; 
"&nbsp; This document instructs IANA to assign a new Error-Cause 
attribute<BR>&gt;&nbsp;&nbsp;&nbsp; [RFC3576],"<BR>&gt; <BR>&gt; Since the 
attribute already exists, I think you want a new Error-Cause<BR>&gt; 
value.</FONT></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><SPAN class=403435717-16012005></SPAN><FONT face=Arial>Y<SPAN 
class=403435717-16012005>es, right!</SPAN></FONT></DIV><FONT><FONT size=2><SPAN 
class=403435717-16012005></SPAN></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT>
<DIV><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT 
face=Arial size=2></FONT><FONT face=Arial size=2></FONT><FONT face=Arial 
size=2></FONT><BR><FONT face=Arial>&gt; <BR>&gt; Section 6<BR>&gt; <BR>&gt; 
"&nbsp; The CUI attribute must be protected against 
Man-in-the-Middle<BR>&gt;&nbsp;&nbsp;&nbsp; attacks.&nbsp; The CUI appears in 
Access-Accept and Accounting-Requests<BR>&gt;&nbsp;&nbsp;&nbsp; packets and is 
protected by the mechanisms that are defined for<BR>&gt;&nbsp;&nbsp;&nbsp; 
RADIUS [RFC2865] and [RFC2866].&nbsp; Therefore there are no 
additional<BR>&gt;&nbsp;&nbsp;&nbsp; security considerations beyond those 
already identified in <BR>&gt; [RFC2865]<BR>&gt;&nbsp;&nbsp;&nbsp; and 
[RFC2866].<BR>&gt; <BR>&gt;&nbsp;&nbsp;&nbsp; Message-Authenticator(80) and 
Event-Timestamp(55) can be used to<BR>&gt;&nbsp;&nbsp;&nbsp; further protect 
against Man-in-the-middle attacks.<BR>&gt; <BR>&gt;&nbsp;&nbsp;&nbsp; It is 
strongly recommended that the CUI form used is such that 
the<BR>&gt;&nbsp;&nbsp;&nbsp; real user identity is not revealed.&nbsp; 
Furthermore, where a reference<BR>&gt;&nbsp;&nbsp;&nbsp; is used to a real user 
identity, the binding lifetime of that<BR>&gt;&nbsp;&nbsp;&nbsp; reference to 
the real user be kept as short as possible."<BR>&gt; <BR>&gt; I think you really 
mean that you would like to protect<BR>&gt; RADIUS packets including CUI against 
modification. Even<BR>&gt; though the draft prohibits modification of the CUI 
attribute<BR>&gt; by proxies, there is no way to prevent this, really.<BR>&gt; 
</FONT></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial><FONT size=2></FONT><FONT face=Arial>You are right there 
is no way to prevent this by design of RADIUS.&nbsp; RADIUS<BR>assumes that the 
clients are trusted.&nbsp; Therefore we would&nbsp;<SPAN 
class=403435717-16012005>n't </SPAN>even attempt to<BR>prevent it.</FONT></DIV>
<DIV><FONT size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><FONT 
size=2></FONT><FONT size=2></FONT><BR>&gt; Message-Authenticator and 
Event-Timestamp attributes don't<BR>&gt; protect against man-in-the-middle (e.g. 
rogue proxies), they<BR>&gt; protect against modification and replay, 
respectively.<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial></FONT>&nbsp;</DIV>
<DIV><FONT><FONT face=Arial>RADIUS is not an end to end protocol.&nbsp; It a hop 
by hop protocol.<BR>So there is a client and a server and the "man in the 
middle" threat is NOT<BR>the client or the server but rather someone that is 
observing the traffic.</FONT></FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT><FONT face=Arial>RADIUS already provides protection for man in the 
middle against changing<BR>the Access-Accept.&nbsp; However, not in the 
Access-Request but this may not be<BR>important here.&nbsp; Except when the NAS 
wants CUI but the man in the middle<BR>deletes that attribute.&nbsp; 
Message-Authenticator can be used here.</FONT></FONT></DIV>
<DIV><FONT><FONT face=Arial size=2></FONT></FONT>&nbsp;</DIV><FONT face=Arial>
<DIV><FONT size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><FONT 
size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><FONT 
size=2></FONT><FONT size=2></FONT><FONT size=2></FONT><FONT 
size=2></FONT><BR>&gt; --<BR>&gt; to unsubscribe send a message to 
</FONT></FONT></FONT></FONT></FONT></FONT></FONT><A 
href="mailto:[email-masked]"><FONT face=Arial color=#000000 
size=2>[email-masked]</FONT></A><FONT face=Arial size=2> 
with<BR>&gt; the word 'unsubscribe' in a single line as the message text 
body.<BR>&gt; archive: &lt;</FONT><A 
href="http://psg.com/lists/radiusext/"><FONT face=Arial color=#000000 
size=2>http://psg.com/lists/radiusext/</FONT></A><FONT face=Arial 
size=2>&gt;<BR>&gt; </FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C4FC0B.710F1535--

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

Delivery-date: Fri, 14 Jan 2005 15:42:25 +0000
Content-class: urn:content-classes:message
Subject: FW: Internet-Draft Submission Cutoff Dates for the 62nd IETF Meeting inMinneapolis, MN
Date: Fri, 14 Jan 2005 10:41:37 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, January 14, 2005 10:09 AM
To: [email-masked]
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 
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 [email-masked].

The IETF Secretariat

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

Delivery-date: Mon, 10 Jan 2005 15:34:53 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: AW: RADIUS Attribute Hiding and radext-digest-auth
Date: Mon, 10 Jan 2005 16:34:37 +0100

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

Delivery-date: Mon, 10 Jan 2005 15:13:10 +0000
Date: Mon, 10 Jan 2005 07:12:39 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Beck01, Wolfgang" <[email-masked]>
cc: [email-masked]
Subject: Re: RADIUS Attribute Hiding and radext-digest-auth

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

Delivery-date: Mon, 10 Jan 2005 08:55:11 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: RADIUS Attribute Hiding and radext-digest-auth
Date: Mon, 10 Jan 2005 09:53:45 +0100

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

Delivery-date: Mon, 10 Jan 2005 04:05:11 +0000
Date: Sun, 09 Jan 2005 20:04:11 -0800
From: Murtaza Chiba <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Summary: RADIUS Attribute Hiding

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

<http://www.sciam.com/article.cfm?chanID=sa006&colID=1&articleID0479CD-F58C-11BE-AD0683414B7F0000>

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

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

Delivery-date: Sat, 08 Jan 2005 23:42:34 +0000
Date: Sat, 8 Jan 2005 15:41:41 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Issue 52: Review of CUI-01

Issue 52: Review of CUI-01
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
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:
[email-masked].

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

Delivery-date: Fri, 07 Jan 2005 17:47:48 +0000
Date: Fri, 7 Jan 2005 09:46:35 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RE: RADIUS Attribute Hiding and radext-digest-auth

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

Delivery-date: Thu, 06 Jan 2005 16:34:56 +0000
From: Avi Lior <[email-masked]>
To: "'Beck01, Wolfgang'" <[email-masked]>, [email-masked]
Subject: RE: RADIUS Attribute Hiding and radext-digest-auth
Date: Thu, 6 Jan 2005 11:34:19 -0500 

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:[email-masked]] 
> Sent: Wednesday, January 05, 2005 10:43 AM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 06 Jan 2005 15:22:55 +0000
From: Greg Weber <[email-masked]>
Subject: [Issue] CUI not in Accounting-Response
To: [email-masked]
Date: Thu, 6 Jan 2005 10:21:51 -0500 (EST)

Description of issue: CUI not in Accounting-Response
Submitter name: Greg Weber
Submitter email address: [email-masked]
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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 05 Jan 2005 21:11:48 +0000
Content-class: urn:content-classes:message
Subject: CUI-01 and Open Issues
Date: Wed, 5 Jan 2005 16:10:47 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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

Delivery-date: Wed, 05 Jan 2005 20:39:59 +0000
From: Avi Lior <[email-masked]>
To: "'Beck01, Wolfgang'" <[email-masked]>, [email-masked]
Subject: RE: RADIUS Attribute Hiding and radext-digest-auth
Date: Wed, 5 Jan 2005 15:39:07 -0500 

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:[email-masked]] 
> Sent: January 5, 2005 10:43 AM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Wed, 05 Jan 2005 20:21:50 +0000
From: Greg Weber <[email-masked]>
Subject: Re: CUI version -01
To: [email-masked] (Adrangi, Farid)
Date: Wed, 5 Jan 2005 15:20:18 -0500 (EST)
Cc: [email-masked]

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

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

Delivery-date: Wed, 05 Jan 2005 18:00:15 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Possible issue for clarification -- RADIUS Accounting
Date: Wed, 5 Jan 2005 09:59:43 -0800

Avi Lior <mailto:[email-masked]> 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:[email-masked]]
>> Sent: January 4, 2005 7:16 PM
>> To: 'Barney Wolff'; 'Nelson, David'
>> Cc: [email-masked]
>> 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
>> [email-masked] with the word 'unsubscribe' in a
>> single line as the message text body.
>> archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Wed, 05 Jan 2005 17:04:54 +0000
Content-class: urn:content-classes:message
Subject: RE: Possible issue for clarification -- RADIUS Accounting
Date: Wed, 5 Jan 2005 12:04:06 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

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

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

Delivery-date: Wed, 05 Jan 2005 16:55:34 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, 'Barney Wolff' <[email-masked]>,  "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Possible issue for clarification -- RADIUS Accounting
Date: Wed, 5 Jan 2005 11:54:31 -0500 

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:[email-masked]] 
> Sent: January 4, 2005 7:16 PM
> To: 'Barney Wolff'; 'Nelson, David'
> Cc: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Wed, 05 Jan 2005 15:43:47 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: RADIUS Attribute Hiding and radext-digest-auth
Date: Wed, 5 Jan 2005 16:42:49 +0100 

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

Delivery-date: Wed, 05 Jan 2005 00:16:22 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Barney Wolff'" <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Possible issue for clarification -- RADIUS Accounting
Date: Tue, 4 Jan 2005 16:15:52 -0800

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

Delivery-date: Tue, 04 Jan 2005 23:56:43 +0000
Date: Tue, 4 Jan 2005 18:56:15 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Possible issue for clarification -- RADIUS Accounting

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

Delivery-date: Tue, 04 Jan 2005 23:09:54 +0000
Content-class: urn:content-classes:message
Subject: Possible issue for clarification -- RADIUS Accounting
Date: Tue, 4 Jan 2005 18:07:40 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

RFC 2866 has the following text (or similar):

"...can only be present in Accounting-Request records where 
the Acct-Status-Type is set to Stop."

contained in the description of the following RADIUS Accounting
Attributes: 

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

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

Delivery-date: Tue, 04 Jan 2005 22:13:40 +0000
Date: Tue, 4 Jan 2005 17:13:06 -0500
From: Barney Wolff <[email-masked]>
To: [email-masked]
Subject: CUI - I'm happy

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

Delivery-date: Tue, 04 Jan 2005 20:30:39 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: Logical sessions vs. statement reconcilliation (was RE: )
Date: Tue, 4 Jan 2005 15:30:22 -0500 

Hi David,

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, January 04, 2005 2:39 PM
> To: [email-masked]
> 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 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Tue, 04 Jan 2005 20:27:29 +0000
Date: Tue, 4 Jan 2005 15:26:57 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "'Barney Wolff'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: 

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

Delivery-date: Tue, 04 Jan 2005 20:25:18 +0000
Date: Tue, 4 Jan 2005 15:25:02 -0500
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: Logical sessions vs. statement reconcilliation (was RE: )

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

Delivery-date: Tue, 04 Jan 2005 20:16:11 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked],  [email-masked], [email-masked],  [email-masked]
Subject: RE: 
Date: Tue, 4 Jan 2005 15:15:42 -0500 

Hi Barney, 

See inline.

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Tuesday, January 04, 2005 2:44 PM
> To: Avi Lior
> Cc: [email-masked]'; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 04 Jan 2005 20:15:58 +0000
Date: Tue, 4 Jan 2005 21:22:28 +0100
From: Emile van Bergen <[email-masked]>
To: Barney Wolff <[email-masked]>
Cc: Avi Lior <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: CUI
Mail-Followup-To: Barney Wolff <[email-masked]>, Avi Lior <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

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           [email-masked]      
tel. +31 (0)70 3906153           http://www.e-advies.nl    

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

Delivery-date: Tue, 04 Jan 2005 19:44:35 +0000
Date: Tue, 4 Jan 2005 14:43:55 -0500
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
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.

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

Delivery-date: Tue, 04 Jan 2005 19:41:18 +0000
Content-class: urn:content-classes:message
Subject: Logical sessions vs. statement reconcilliation (was RE: )
Date: Tue, 4 Jan 2005 14:39:17 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

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.

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? 

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

Delivery-date: Tue, 04 Jan 2005 18:42:28 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked],  [email-masked]
Cc: Avi Lior <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: 
Date: Tue, 4 Jan 2005 13:41:45 -0500 

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

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

Delivery-date: Tue, 04 Jan 2005 18:11:56 +0000
Content-class: urn:content-classes:message
Subject: RE: Consensus on CUI Usage and Applicability
Date: Tue, 4 Jan 2005 10:03:52 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>

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.  

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

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

Delivery-date: Tue, 04 Jan 2005 15:21:47 +0000
Date: Tue, 04 Jan 2005 16:20:30 +0100
From: [email-masked]
To: "Romascanu, Dan (Dan)" <[email-masked]>
Cc: "Wijnen, Bert (Bert)" <[email-masked]>, [email-masked]
Subject: Re: Comments on draft-decnodder-radext-dynauth-client-mib-02.txt

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

Delivery-date: Sat, 01 Jan 2005 19:51:45 +0000
Date: Sat, 1 Jan 2005 14:51:14 -0500
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Summary: RADIUS Attribute Hiding

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

Delivery-date: Sat, 01 Jan 2005 18:41:44 +0000
Date: Sat, 1 Jan 2005 10:40:54 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Summary: RADIUS Attribute Hiding

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