Subject: Re: [Issue] Special Characters in RFC 2486bis
From: Jari Arkko <[email-masked]>
To: [email-masked]
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Date: Fri, 29 Oct 2004 17:48:59 +0300

[email-masked] wrote:
> Hi,
> you helped me with no doubt. 
> Anyway I have another doubt about the use of %x22 special character in the
> NAI username.
> As an escape mechanism have to be used to allow a special character, can
> you confirm that the following is not a valid NAI? 
> 
> "Paola\. Pappalardo"@ericsson.com

Yes, this is invalid.

> While this other is valid?
> 
> \"Paola\.Pappalardo\"@ericsson.com

Yes, this is valid

--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: Fri, 29 Oct 2004 09:11:29 +0000
Date: Fri, 29 Oct 2004 12:09:37 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: [Issue] Special Characters in RFC 2486bis

> I have to handle the Network Access Identifier (NAI) for my work. I have
> read the RFC 2486 and I'm a little confused about the use of special
> characters,
> like  "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."  / "," / ";" / ":" /
> "@" / %x22  / Ctl,
> 
> in the NAI username.
> 
> Can you help me? Can you please give some examples of valid NAI containing
> special characters?

The issue is what "special" characters, not just alphabets
and digits can appear in NAIs. The realm part rules are
according to the usual DNS, which I think allows only "-"
and ".". The user name part allows more special characters,
but disallows some others. A couple of valid examples:

     [email-masked]
     [email-masked]

A couple of invalid examples:

     [email-masked]
     user>[email-masked]

Nevertheless, there's an escape mechanism that allows
even special characters. Example:

     jari\[email-masked]

If you read the new draft at

   http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2486bis-01.txt

you will see that the ABNF syntax is hopefully easier to read
than in RFC 2486, because the treatment of each character has
been listed on its own line, and you do not have read the
comments to find out what actual characters are allowed.

Hope this helps,

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: Fri, 29 Oct 2004 08:24:25 +0000
Date: Fri, 29 Oct 2004 01:24:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [Issue] Special Characters in RFC 2486bis

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Fri 10/29/2004 12:27 AM
To: Bernard Aboba
Subject: Network Access Identifier: a question.

Dear Mr Aboba,
I have to handle the Network Access Identifier (NAI) for my work. I have
read the RFC 2486 and I'm a little confused about the use of special
characters,
like  "<" / ">" / "(" / ")" / "[" / "]" / "\" / "."  / "," / ";" / ":" /
"@" / %x22  / Ctl,

in the NAI username.

Can you help me? Can you please give some examples of valid NAI containing
special characters?

Thanks in advance and Best Regards.

Paola Pappalardo

--
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, 26 Oct 2004 21:15:34 +0000
Content-class: urn:content-classes:message
Subject: FW: I-D ACTION:draft-adrangi-radius-chargeable-user-identity-02.txt
Date: Tue, 26 Oct 2004 14:15:00 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

> All,
> This version only includes some fixes and clean-up based on=20
> the comments from Greg Weber.  It does not incorporate the=20
> recent discussion on the mailing list - we will put out a=20
> revised version with resolution to the outstanding issues=20
> shortly after the next IETF meeting.
> BR,
> Farid
>=20
> > -----Original Message-----
> > From: [email-masked]=20
> > [mailto:[email-masked]] On Behalf Of=20
> > [email-masked]
> > Sent: Tuesday, October 26, 2004 1:03 PM
> > To: [email-masked]
> > Subject: I-D=20
> > ACTION:draft-adrangi-radius-chargeable-user-identity-02.txt
> >=20
> >=20
> > A New Internet-Draft is available from the on-line=20
> > Internet-Drafts directories.
> >=20
> >=20
> > 	Title		: Chargeable User Identity
> > 	Author(s)	: F. Adrangi, et al.
> > 	Filename	:=20
> > draft-adrangi-radius-chargeable-user-identity-02.txt
> > 	Pages		: 10
> > 	Date		: 2004-10-26
> > =09
> > This document describes a new RADIUS attribute used by a=20
> home RADIUS=20
> > to indicate Chargeable User Identity to all parties involved in the=20
> > roaming transaction outside the home network.
> >=20
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-adrangi-radius-charg
> eable-user-identity-02.txt
>=20
> To remove yourself from the I-D Announcement list, send a message to=20
> [email-masked] with the word unsubscribe in=20
> the body of the message. =20
> You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce=20
> to change your subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login=20
> with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-adrangi-radius-chargeable-user-identity-02.txt".
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html=20
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE=20
> /internet-drafts/draft-adrangi-radius-chargeable-user-identity
> -02.txt".
> =09
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant=20
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 	=09
> 	=09
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>=20

--
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, 26 Oct 2004 17:24:07 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: FYI Prepaid version 6.0
Date: Tue, 26 Oct 2004 13:23:30 -0400

In essence this draft adds One-Time Charging.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title : Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)
Author(s) : A. Lior
Filename : draft-lior-radius-prepaid-extensions-06.txt
Pages : 53
Date : 2004-10-25
This draft presents an extension to the Remote Authentication Dial-
In User Service (RADIUS) protocol to support charging for prepaid 
services. The charging models supported are namely: volume-based 
charging, duration-based charging and one-time-based charging.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-06.
txt

-----------------------------
Avi Lior
Bridgewater Systems Corp.
Phone: 613.591.9104 x 6417
Cell   : 613.297.2177

--
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, 26 Oct 2004 16:43:09 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Tue, 26 Oct 2004 12:42:51 -0400

Alan, Blair, 

Before we start spiralling out of control let me summarize:

If you want opaque value use Class.

No.  Class can't be used as a handle because it will probably change on each
invocation unless of course we standerdized its contents which is not even a
starter.  I hope we never talk about Class in this context again.

Regarding non-opaque handles to users.  Some business models may require an
IMSI or NAI for the subscriber, which does reveal the identity of the user
and may or may not be a privacy issue.  Remember the parties trust each
other so this is probably okay.

However in some cases eventhough the parties trust each other, the true
identity of the subscriber is not to be delivered outside the subscriber's
home realm.  In this case we allow for an opaque handle to the user.  

1) Whether that handle is a UTF-8 string (or text) is really not important. 

2) How it is generated is really not important to the clients that use that
handle.  Clients need to know two things about that string: 
a) that it uniquely represents a subscriber in the home network; 
b) how long is that assertion valid for.
Item b) is made known during business agreement.

3) The generating function is only important to the home entity since it is
making the assertion.  It could simply be a hash( real identity + a
timevalue). In 3GPP they can probably use TIMSI which is created for exactly
this reason.  Note that the Home Entity must make sure that there are no
possible collisions. 

So given 2 I don't think there is an interoperability issue. 

And Item 3) is strictly a producer issue and I don't think that we need to
tell people how to generate that identity.  There are so many ways to do it.
But if you feel that we must perhaps the following will work:

       CUI = '04:' || Hex((HMAC-SHA1(secret,{real identity || realm ||
timestamp})) || @ realm
       
      This would generate a UTF-8 string that looks like:

           04:[email-masked]

    Furthermore, this value MUST be unique (most likely it is ) for the home
network.  Once computed the home network would make sure that it does not
collide with an existing number and would store this value against the
realuser, and keep issuing it until it expired. 

The client would treat the CUI (as received) as a handle to the subscriber.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, October 26, 2004 10:18 AM
> To: [email-masked]
> Subject: Re: Clearinghouse/Aggregator Support for CUI
> 
> 
> "Blair T. Bullock" <[email-masked]> wrote:
> > If you desire opaque data, then use CLASS.  That is what it is for.
> 
>   As Avi noted, Class has issues that the CUI is designed to avoid.
> 
> >  CUI must be visible to all parties and if you want it to 
> be private,
> 
>   I think you misunderstood.  The CUI attribute is, of 
> course, publicly visible.  My concerns about privacy were that the
> *interpretation* of the CUI attribute is often best left to 
> the home system.  Intermediate systems can treat it as an 
> opaque token, with no loss of functionality.
> 
> > If the Home network or any trusted AAA authority wishes to send an 
> > alias or hash/encode the string prior to transmission so that it is 
> > private or opaque, fine and dandy,
> 
>   That's exactly what I've said.
> 
> > but the CUI must be a STRING and cleartext possible.
> 
>   "cleartext" has a specific interpretation in the security 
> world: the information is publicly available to all, and not 
> hashed or encoded.
> 
>   So I'm not sure what you mean here.  If the CUI is in a 
> RADIUS attribute, then all RADIUS servers should be able to 
> understand and proxy it without any problems.
> 
>   Are you saying that the CUI must be an ASCII/UTF-8 string?  
> If so, why?
> 
> > i.e., every time I login, my Accounting would appear as:
> > 
> > User-Name=IPASS/[email-masked]
> > Chargeable-User-Identity=x4188  (or bbullock)
> 
>   Exactly.  The numerical ascii string has no meaning to 
> intermediaries, but the home system knows how to interpret 
> it.  This is a good idea, and I'm all for it.
> 
>   My only extension to this idea is that IMHO the document 
> should describe a way for the home server to generate opaque 
> tokens from usernames.  Doing so permits the method to be 
> peer reviewed, secure, correct, and common across many 
> implementations.
> 
> > Since the CUI only transports between the NAS and the Home 
> > authentication server over a privately peered proxy network and is 
> > never broadcast over the air, there is no exposure to 3rd parties 
> > unless your RADIUS stream has been compromised....
> 
>   Are all proxy networks privately peered?  I don't think so. 
>  I would like to see recommendations in the document for how 
> to use CUI in other widely deployed systems.
> 
> > Besides, this is an Accounting stream which contains no 
> authentication 
> > credential...they are already clear!
> 
>   Yes, but as I said before, the real username is hidden 
> inside of the TLS tunnel.  Exposing the username in 
> accounting packets pretty much defeats the purpose putting 
> the name in the tunnel.
> 
>   While the intent of putting the name in the tunnel is to 
> protect it from wireless sniffers and not people on a wired 
> net, I don't think that it's a good idea to expose that 
> information in accounting packets.  Doing so unnecessarily 
> makes accounting the weak link in the chain.  Since in some 
> situatuions, there's no requirement for intermediaries to 
> parse the CUI, it's entirely reasonable to use an opaque set 
> of octets for the CUI.
> 
>   Alan DeKok.
> 
> --
> 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, 26 Oct 2004 16:16:53 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>,  [email-masked]
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Tue, 26 Oct 2004 12:16:20 -0400

It wouldn't be a vendor (as in Bridgewater etc) that would determine how it
will generate a handle for a real identity and store it in the CUI.

It would be a vendor as in the case of an SDO such as 3GPP or 3GPP2 that
would determine the method for generating handles to subscribers.  For
example, 3GPP already does generate a TIMSI (temporary IMSI) to protect the
true identity. They would define the method of generating an temporary
identity and the length of time.

Note that users of that identity (Clients) really don't care of the format
of the attribute and how it was generated.  They would just use the value as
given knowing that it represents a handle to the identity that will be valid
for some time period.

For example if a 3GPP operator were to send the value to a WLAN operator,
the WLAN operator just needs to know that that value allocated by a 3GPP
operators represents the value of a user for a length of time.  The length
of time will be made known to the WLAN operator based on business
arrangements.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, October 25, 2004 5:37 PM
> To: Avi Lior; Alan DeKok; [email-masked]
> Subject: RE: Clearinghouse/Aggregator Support for CUI
> 
> 
> > I don't think that it is appropriate to mention this in the draft.
> 
> I guess that would depend on whether one would expect to be 
> able to demonstrate multi-vendor interoperability solely 
> based on what is documented in an IETF RFC.  If it is 
> acceptable to require additional, Non-IETF information in 
> order to demonstrate multi-vendor interoperability, then 
> maybe one could omit this information. 
> 

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

Envelope-to: [email-masked]
Delivery-date: Tue, 26 Oct 2004 14:08:44 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Clearinghouse/Aggregator Support for CUI 
Date: Tue, 26 Oct 2004 10:17:36 -0400
Message-Id: <[email-masked]>

"Blair T. Bullock" <[email-masked]> wrote:
> If you desire opaque data, then use CLASS.  That is what it is for.

  As Avi noted, Class has issues that the CUI is designed to avoid.

>  CUI must be visible to all parties and if you want it to be
> private,

  I think you misunderstood.  The CUI attribute is, of course,
publicly visible.  My concerns about privacy were that the
*interpretation* of the CUI attribute is often best left to the home
system.  Intermediate systems can treat it as an opaque token, with no
loss of functionality.

> If the Home network or any trusted AAA authority wishes to send an
> alias or hash/encode the string prior to transmission so that it is
> private or opaque, fine and dandy,

  That's exactly what I've said.

> but the CUI must be a STRING and cleartext possible.

  "cleartext" has a specific interpretation in the security world: the
information is publicly available to all, and not hashed or encoded.

  So I'm not sure what you mean here.  If the CUI is in a RADIUS
attribute, then all RADIUS servers should be able to understand and
proxy it without any problems.

  Are you saying that the CUI must be an ASCII/UTF-8 string?  If so,
why?

> i.e., every time I login, my Accounting would appear as:
> 
> User-Name=IPASS/[email-masked]
> Chargeable-User-Identity=x4188  (or bbullock)

  Exactly.  The numerical ascii string has no meaning to
intermediaries, but the home system knows how to interpret it.  This
is a good idea, and I'm all for it.

  My only extension to this idea is that IMHO the document should
describe a way for the home server to generate opaque tokens from
usernames.  Doing so permits the method to be peer reviewed, secure,
correct, and common across many implementations.

> Since the CUI only transports between the NAS and the Home
> authentication server over a privately peered proxy network and is
> never broadcast over the air, there is no exposure to 3rd parties
> unless your RADIUS stream has been compromised....

  Are all proxy networks privately peered?  I don't think so.  I would
like to see recommendations in the document for how to use CUI in
other widely deployed systems.

> Besides, this is an Accounting stream which contains no
> authentication credential...they are already clear!

  Yes, but as I said before, the real username is hidden inside of the
TLS tunnel.  Exposing the username in accounting packets pretty much
defeats the purpose putting the name in the tunnel.

  While the intent of putting the name in the tunnel is to protect it
from wireless sniffers and not people on a wired net, I don't think
that it's a good idea to expose that information in accounting
packets.  Doing so unnecessarily makes accounting the weak link in the
chain.  Since in some situatuions, there's no requirement for
intermediaries to parse the CUI, it's entirely reasonable to use an
opaque set of octets for the CUI.

  Alan DeKok.

--
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, 26 Oct 2004 05:46:09 +0000
Date: Mon, 25 Oct 2004 22:45:41 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Greg Weber <[email-masked]>
cc: [email-masked]
Subject: Re: mtg in D.C.?

RADEXT will meet at IETF 61 in Washington, DC.

However, for some reason the Secretariat hasn't been responding to our
request for 2.5 hour slot.

On Mon, 25 Oct 2004, Greg Weber wrote:

>
> Does RADEXT intend to meet in D.C.?
> I don't see it on the current agenda...

--
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, 25 Oct 2004 22:51:19 +0000
Content-class: urn:content-classes:message
Subject: RE: mtg in D.C.?
Date: Mon, 25 Oct 2004 18:50:51 -0400
From: "Nelson, David" <[email-masked]>
To: "Greg Weber" <[email-masked]>, <[email-masked]>

> Does RADEXT intend to meet in D.C.?

Yes.  We requested one 2.5 hour session.

> I don't see it on the current agenda...

The current agenda at http://www.ietf.org/meetings/agenda_61.html is
dated October 5. The RADEXT request went in after that date, and is in
agenda queue at the IETF Secretariat.  A message sent out on Friday
(10/22) indicated a revised agenda would be out soon.

--
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, 25 Oct 2004 22:31:04 +0000
Content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 15:27:41 -0700
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked]

If you desire opaque data, then use CLASS.  That is what it is for.  CUI
must be visible to all parties and if you want it to be private, then
don't pass-back a real User-Name in the Access-Accept...or if you can
correlate it directly from the NAI, don't pass a User-Name at all.   I
would say use the CUI in the Access-Accept in order to signal desire to
use the attribute, but we should pay attention to legacy AAA endpoints
for things like TTLS/PAP or CHAP functionality with downwards
compatibility.

Mediating networks who oversee the aggregation of footprint for
reselling network services will need to have visibility into this CUI
string.   The CUI should be transparent to all parties.  If the Home
network or any trusted AAA authority wishes to send an alias or
hash/encode the string prior to transmission so that it is private or
opaque, fine and dandy, but the CUI must be a STRING and cleartext
possible.

An Anonymous TTLS/PEAP using a logical alias CUI, in effect provides the
necessary privacy while still maintaining service oversight on a
per-user/per-session basis.

i.e., every time I login, my Accounting would appear as:

User-Name=3DIPASS/[email-masked]
Chargeable-User-Identity=3Dx4188  (or bbullock)

The need is truly for a correlate to the authorized profile, but not
transmitted over the EAP ID which is interceptable.  Since the CUI only
transports between the NAS and the Home authentication server over a
privately peered proxy network and is never broadcast over the air,
there is no exposure to 3rd parties unless your RADIUS stream has been
compromised....and if so, you have bigger problems than maintaining CUI
privacy.  Besides, this is an Accounting stream which contains no
authentication credential...they are already clear!  This actually
allows us all to use anonymous tunneled EAP logins without losing the
actual user identity and without transmitting that user's ID over the
air.

Blair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alan DeKok
Sent: Monday, October 25, 2004 3:12 PM
To: [email-masked]
Subject: Re: Clearinghouse/Aggregator Support for CUI

Avi Lior <[email-masked]> wrote:
> Operators and SDO that would use the Opaque value would typically have

> their own security review.

  Which is precisely my concern.

  IMHO, for "hidden" data in CUI, inter-operability is less of a
requirement than is "best practices".  The IETF has a history of
accepting both in documents, and sometimes even in the same document.

> Furthermore when thinking about how one might do this, there are many=20
> factors to consider and these factors are specific to deployments.  So

> I am not sure if we came up with an example it would have general
applicability.

  A well-known method which hides the CUI data from all but the users
home system would cover many common cases.

  Since the CUI is encrypted in a TLS tunnel, but is visible to the end
system, then there is value in continuing that practice when the CUI is
carried an attribute.

  Having a CUI which is private, and requires minimal state keeping by
the home server seems to me to be a good solution.

  Alan DeKok.

--
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, 25 Oct 2004 22:27:44 +0000
From: Greg Weber <[email-masked]>
Subject: mtg in D.C.?
To: [email-masked]
Date: Mon, 25 Oct 2004 18:27:05 -0400 (EDT)

Does RADEXT intend to meet in D.C.?
I don't see it on the current agenda...

Greg

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

Envelope-to: [email-masked]
Delivery-date: Mon, 25 Oct 2004 22:02:09 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Clearinghouse/Aggregator Support for CUI 
Date: Mon, 25 Oct 2004 18:12:29 -0400
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Operators and SDO that would use the Opaque value would typically have their
> own security review.

  Which is precisely my concern.

  IMHO, for "hidden" data in CUI, inter-operability is less of a
requirement than is "best practices".  The IETF has a history of
accepting both in documents, and sometimes even in the same document.

> Furthermore when thinking about how one might do this, there are many
> factors to consider and these factors are specific to deployments.  So I am
> not sure if we came up with an example it would have general applicability.

  A well-known method which hides the CUI data from all but the users
home system would cover many common cases.

  Since the CUI is encrypted in a TLS tunnel, but is visible to the
end system, then there is value in continuing that practice when the
CUI is carried an attribute.

  Having a CUI which is private, and requires minimal state keeping by
the home server seems to me to be a good solution.

  Alan DeKok.

--
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, 25 Oct 2004 21:37:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 17:36:34 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Alan DeKok" <[email-masked]>, <[email-masked]>

> I don't think that it is appropriate to mention this in the draft.

I guess that would depend on whether one would expect to be able to
demonstrate multi-vendor interoperability solely based on what is
documented in an IETF RFC.  If it is acceptable to require additional,
Non-IETF information in order to demonstrate multi-vendor
interoperability, then maybe one could omit this information.=20

--
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, 25 Oct 2004 19:57:53 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 15:57:29 -0400

Alan,

I don't think that it is appropriate to mention this in the draft. Also note
that based on my recollections, the Diameter CC, which uses the same
attribute does not give examples.

Operators and SDO that would use the Opaque value would typically have their
own security review.

Furthermore when thinking about how one might do this, there are many
factors to consider and these factors are specific to deployments.  So I am
not sure if we came up with an example it would have general applicability.

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, October 26, 2004 2:41 AM
> To: [email-masked]
> Subject: Re: Clearinghouse/Aggregator Support for CUI
> 
> 
> "Adrangi, Farid" <[email-masked]> wrote:
> > Regarding to a suggested "best practices" for format, are you 
> > suggesting that the draft should recommend one of the specified 
> > formats, or suggest a format for the "opaque string"?
> 
>   I'm suggesting that a method and format for "hiding" user 
> information in the opaque string be part of the draft.  Not 
> as a standard, but as a suggestion.
> 
>   That will allow the format to be peer reviewed for 
> potential problems, and will encourage implementors to use a 
> peer-reviewed method, rather than home-grown solutions.
> 
>   Alan DeKok.
> 
> --
> 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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 25 Oct 2004 18:30:05 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Clearinghouse/Aggregator Support for CUI 
Date: Mon, 25 Oct 2004 14:40:30 -0400
Message-Id: <[email-masked]>

"Adrangi, Farid" <[email-masked]> wrote:
> Regarding to a suggested "best practices" for format, are you suggesting
> that the draft should recommend one of the specified formats, or suggest
> a format for the "opaque string"?

  I'm suggesting that a method and format for "hiding" user
information in the opaque string be part of the draft.  Not as a
standard, but as a suggestion.

  That will allow the format to be peer reviewed for potential
problems, and will encourage implementors to use a peer-reviewed
method, rather than home-grown solutions.

  Alan DeKok.

--
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, 25 Oct 2004 17:48:46 +0000
Content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 10:45:27 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, "Barney Wolff" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4BABA.69C81CF6
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Absolutely correct.  The originally presented NAI as per the Identity
request must stay unchanged for all RADIUS events.  As such, the
original RFC language must be closed.  In order to expose the underlying
authorized profile of a tunneled EAP method, CUI should be used instead
rather than manipulating the User-Name attribute which could possibly
change the Accounting's routing (most assuredly so when promiscuous
source based NAI construction is used which is unknown to the home
network...commonly so).
=20
RADIUS User-Name must remain as originally presented.  The actual
authenticating profile name, or in cases where privacy is required, an
alias may be passed back in the Access-Accept to populate the CUI.
While an alias in the Access-Accept is a function that needs to be
implemented on the home Authentication Server, that is something which
is tenable based on the CUI standard that we propose.  Networks can
build an anonymity mechanism by returning an alias (such as a phone
exchange, PIN, etc) in the Access-Accept User-Name to populate the CUI,
but that is to their discretion.  Otherwise, the normal "unrealmed"
username of the authorized profile would be used in the CUI which does
not affect RADIUS routing (i.e. "blair").  This provides a mechanic for
per-user/per-session correlation, exposes the actual authorized
credential while still allowing networks to build anonymous tunneled
systems with some semblance of fraud detection and service oversight
where none exists today.=20
=20
Blair

________________________________

From: Adrangi, Farid [mailto:[email-masked]]=20
Sent: Sunday, October 24, 2004 11:36 PM
To: Blair T. Bullock; Barney Wolff; [email-masked]
Subject: RE: Clearinghouse/Aggregator Support for CUI

Hi Blair,
=20
Thanks for good notes Blair.
=20
On "UserName Overwrite" below,  the RADIUS routing is done based on the
realm portion of the NAI -- not the user-name part.  As long as the
realm and decorated portion of the NAI sent in the Access-Request gets
reflected in the Access-Accept  then the billing should follow the same
path as the authentication packets.  for the purpose of  the CUI, when
we say "User-Name Overwrite", I think we are referring to the user-name
part of the NAI,  NOT the realm or decoration part.  However, the
problem arises when the decoration part in Access-Request is stripped
off on its way to the home RADIUS server.   And where the RFC2865 says
this about the UserName(1) : "   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."    To fix the routing problem (i.e., ensuring authentication
and accounting packets follow the same path),   it seems to me that the
NAS should also always  include the UserName(1) that was sent in the
Access-Request in Accounting-Requests (on contrary to what RFC 2865
states).     And if so ,  then the intermediaries will not have access
to the CUI that was conveyed by the User-Name Overwrite!     In summary,
This problem can be fixed with the introduction of the CUI *in
conjunction* with the language changes to RFC2865 (as mentinoed above).
Your comment?
=20
BR,
Farid

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Blair T. Bullock
	Sent: Sunday, October 24, 2004 1:18 PM
	To: Barney Wolff; [email-masked]
	Subject: Clearinghouse/Aggregator Support for CUI
=09
=09
	Collegues,=20
=09
=09
	=20
	I wanted to chime in again on the adoption of CUI and summarize
where I see the general consensus within the industry on legacy-based
work-arounds.  When I say "Industry", I mean from the results of
parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance,
IRAP, Intel/IDA IWS and several well-respected RADIUS experts within
this organization.  From a Clearinghouse/Aggregator standpoint, I have
intimate knowlege of several major RADIUS clearinghouse systems and
their supplying networks and know that what I describe here is
absolutely crucial to the proper adoption and mediated AAA of Tunneled
EAP methods for WPA Public Access.    This problem is very well
understood!    Class doesn't work.  NAI modification is bad.  The
Outer-Identity is discarded at Authorization and there is no good way to
oversee tunneled EAP authentications without Early Termination or
reflection in User-Name which modifies the NAI.
	=20
	CUI is basically designed to close operational loopoles in
RADIUS allowed by the original RFCs, but which have impacted roaming
network solutions in a negative way, particularly with the introduction
of multiple identity tunneled protocols such as PEAP or TTLS.  To concur
what was said earlier on this thread, a clearly chargeable user/alias
reflecting the home network's authenticated user profile is absolutely
neccessary for all parties and *must be transparent*.  =20
	=20
	The concern for legacy-based support is valid, but unwarranted.
If presented in a hybrid network, any new attributes should be silently
discarded and not dropped or NAKed due to malformation or unsupported
attributes.  Besides, the CUI is specifically geared to Multi-Identity
EAP authentications which in all honestly, are built with the latest
protocols.  An older radius endpoint could trigger CUI by virtue of
including the User-Name in its Access-Accepts, but would merely drop the
attribute when it arrives in Accounting (assuming that the NAS doesn't
change the NAI and route it into neverland)
	=20
	The loophole RADIUS operations are:
	=20
	1 - User-Name Overwrite:   Overwriting the User-Name with the
User-Name in the Access-Accept.  Ouch!! Whether by chance or choice,
this is just *wrong* as an accounting approach.  In a Local or
Bi-lateral service, I can see why this would be useful to reflect the
authenticated profile from the Access-Accept User-Name (assuming the
home network uses an @realm or they won't get Accounting back, even in
standard methods).  But with a Tunneled EAP Inner ID being returned in a
Home-Based Access-Accept to a network which derives its peering from
client-based source decorated NAI?  It is Desastrous!!  Furthermore,
willfull lack of decoration for the Inner ID is a clear opportunity for
fraud!  Therefore, User-Name is not allowed to be returned in the
Access-Accept User-Name so that RADIUS networks can be assured to
receive Accounting packets down the same peering path that the
Authentication use. =20
	=20
	2 - NAI:  As someone rightfully noted on this reflector, the
proprietary Global clearinghouse Prefix-based NAI construction methods
which have evolved over the past decade are not represented in the
latest drafts.  These methods were designed with business and RADIUS
legacy interoperability in mind.  Simple chained suffix-based routing to
consumers (@realm@realm) was the only standard that we had.  It allowed
for reseller arrangements.  However, in order to deal with the
aggregation of networks for supply, another mechanism was needed.  The
prefix.  The "/" was initially presented by UUnet and because it was not
specifically reserved, allowed the formation of proprietary network
aggregation while leveraging the stadards-based realm support for resale
of that aggregated service. operator/agregator/user@realm@reseller
<mailto:operator/agregator/user@realm@reseller> .  Now it is supported
ubiquitously and maintains legacy compat down to livingston 1.16.
Whether good or bad, reality dictates that it is a defacto standard.
Ergo the originally presented NAI held by the NAS must not be changed
based on "standard" NAI construction principles...ever...at least for
use with these global networks and their partners.   You simply don't
know in every case how they have constructed the NAI and must always
respect a pre-decorated NAI. =20
	=20
	The disparate NAS support for User-Name overwrite is mitigated
by the elimination of User-Name in the A-A, basically breaking CUI too
until allowed on a verified CUI functional network which will be the
normal oversight for deploying a new WPA service.   Tunneled EAP for
Public Access roaming will not be adopted until the User-Name is passed
back in the Access Accept for use with the CUI only and never the
User-name.  This will only happen after verification that these specific
operations have been corrected and CUI fulfills the exposure of the
Authenticated Home User Profile without modifying the Accounting
User-Name.  Its that simple.  We need the NAI in the User-Name unspoiled
to honor our routing and aggregation methods.  A consistent way to
expose the actual authenticated profile on a per-user/per-session basis
for the purposes of revenue assurance, fraud detection and service
oversight is fundamental in a Federated AAA Fabric such as iPass or an
aggregated RADIUS peering fabric such as with our many competitors. =20
	=20
	From discussion with WISP global partners deploying WPA, CUI
service oversight is also crucial where **no roaming** is even
occurring!  Since the OuterID is dropped at the time of authentication,
you simply have to know which profile is authorized as exposed in the
accounting.
	=20
	CLASS - The Class Attribute was the initial legacy-based
work-around to CUI based on its ability to reflect home data in an
accounting stream.  However:
	 1 - It is intended to be opaque to all but the home network
(which does no good since the whole purpose is to tie specific sessions
to distinct authorizations between all parties.)
	2 - This is an additive attribute and their value ordering
unspecified.  How many classes to we demand support for in a NAS?  One?
Four?  Eight?  Many of these APs don't have that much processing power.
	=20
	CUI is the correct standards-based approach to fixing the
problems which have arisen with multiple-identity RADIUS auth and
accounting methods.  While it will not solve all problems (like MSCHAPv2
in TTLS IN TTLS), but it does respond to the readily available EAP
supplicants and provides the current global RADIUS networks with the
capacity to deploy, bill and oversee WPA networks against fraud.
Without this, other proprietary methods will be done, I assure you.
However, our job would be much easier if there was wide adoption of the
CUI attribute.  iPass for instance, would mandate and facilitate its
adoption immediately.
	=20
	CUI is not an overloading of a legacy attribute or arbitrary
kludge of existing attributes in order to make these networks work.  It
is a necessary correction amongst the others listed above.
	=20
	Thanks for your time.
	=20
	Blair Bullock
	Systems Arhitect, iPass Inc.
	=20

------_=_NextPart_001_01C4BABA.69C81CF6
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337123817-25102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Absolutely correct.&nbsp; The originally =
presented NAI as=20
per the Identity request must stay unchanged for all RADIUS =
events.&nbsp; As=20
such, the original RFC language must be closed.&nbsp; In order to expose =
the=20
underlying authorized profile of a tunneled EAP method, CUI should be =
used=20
instead rather than manipulating the User-Name attribute which could =
possibly=20
change the Accounting's routing (most assuredly so when promiscuous =
source based=20
NAI construction is used which is unknown to the home network...commonly =

so).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337123817-25102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337123817-25102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>RADIUS User-Name must remain as originally =
presented.&nbsp;=20
The actual authenticating profile name, or in cases where privacy is =
required,=20
an alias may be passed back in the Access-Accept to populate the =
CUI.&nbsp;=20
While an alias in the Access-Accept is a function that needs to be =
implemented=20
on the home Authentication Server, that is something which is tenable =
based on=20
the CUI standard that we propose.&nbsp; Networks can build an anonymity=20
mechanism by returning an alias (such as a phone exchange, PIN, etc) in =
the=20
Access-Accept User-Name to populate the CUI, but that is to their=20
discretion.&nbsp; Otherwise, the normal "unrealmed" username of the =
authorized=20
profile would be used in the CUI which does not affect RADIUS routing =
(i.e.=20
"blair").&nbsp; This provides a mechanic for per-user/per-session =
correlation,=20
exposes the actual authorized credential while still allowing networks =
to build=20
anonymous tunneled systems with some semblance of fraud detection and =
service=20
oversight where none exists today.&nbsp;</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337123817-25102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D337123817-25102004><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Blair</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Adrangi, Farid=20
[mailto:[email-masked]] <BR><B>Sent:</B> Sunday, October 24, =
2004 11:36=20
PM<BR><B>To:</B> Blair T. Bullock; Barney Wolff;=20
[email-masked]<BR><B>Subject:</B> RE: Clearinghouse/Aggregator =
Support=20
for CUI<BR></FONT><BR></DIV>
<DIV></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial =
color=3D#0000ff>Hi=20
Blair,</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial =
color=3D#0000ff>Thanks for=20
good notes Blair.</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =
size=3D2>On=20
"UserName Overwrite" below,&nbsp; <FONT face=3D"Times New Roman"=20
size=3D3>t</FONT><SPAN class=3D661022405-25102004><FONT color=3D#0000ff =
size=3D2><FONT=20
size=3D3><FONT face=3D"Times New Roman">he RADIUS routing is done based =
on the realm=20
portion of the NAI -- not the user-name part.&nbsp; As long as the=20
realm&nbsp;</FONT><FONT size=3D2><SPAN class=3D825451606-25102004><FONT=20
face=3DArial>and decorated&nbsp;</SPAN><SPAN =
class=3D825451606-25102004>portion of=20
the</SPAN></FONT></FONT><FONT face=3D"Times New Roman">&nbsp;NAI sent in =
the=20
Access-Request gets reflected in the Access-Accept &nbsp;then the =
billing should=20
follow the same path as the authentication packets.&nbsp; for the =
purpose=20
of&nbsp; the CUI, when we say "User-Name Overwrite", I think we are =
referring to=20
the user-name&nbsp;part of the NAI,&nbsp; NOT the realm or decoration=20
part.&nbsp; However, the problem arises when the decoration part in=20
Access-Request is stripped off on its way to the home RADIUS =
server.&nbsp;&nbsp;=20
And where the RFC2865 says this about the UserName(1) : =
"</FONT></FONT><FONT=20
color=3D#000000 size=3D3><FONT face=3D"Times New =
Roman">&nbsp;</FONT><FONT=20
color=3D#0000ff><FONT face=3D"Times New Roman">&nbsp; It MAY be sent in =
an=20
Access-Accept packet, in which case the&nbsp;client SHOULD use the name =
returned=20
in the Access-Accept packet in&nbsp;all Accounting-Request packets for =
this=20
session."&nbsp;&nbsp;&nbsp; To fix the routing problem (i.e., ensuring=20
authentication and accounting packets follow the same path),&nbsp; =
&nbsp;it=20
seems to me that the NAS should also always&nbsp;</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial=20
size=3D2>&nbsp;include&nbsp;</FONT></SPAN><FONT face=3D"Times New =
Roman">the=20
UserName(1) that was sent in the Access-Request in Accounting-Requests =
(on=20
contrary to what RFC 2865 states).&nbsp;&nbsp;&nbsp;&nbsp;</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial size=3D2>&nbsp;<FONT =
size=3D3>And if=20
so&nbsp;</FONT></FONT></SPAN><FONT face=3D"Times New =
Roman">,</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial>&nbsp; =
then</FONT></SPAN><FONT=20
face=3D"Times New Roman"> the intermediaries will not have access to the =
CUI that=20
was conveyed by the User-Name Overwrite</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial>!&nbsp;</SPAN><SPAN=20
class=3D825451606-25102004>&nbsp;</SPAN><SPAN=20
class=3D825451606-25102004>&nbsp;&nbsp; In summary,&nbsp; This problem =
can be=20
fixed with the introduction of the CUI *in conjunction* with the =
language=20
changes to RFC2865 (as mentinoed above).&nbsp; Your=20
comment?</SPAN></FONT></FONT></FONT></FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004></SPAN><SPAN =
class=3D825451606-25102004><FONT=20
face=3DArial color=3D#0000ff size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Blair T. Bullock<BR><B>Sent:</B> Sunday, October 24, =
2004 1:18=20
  PM<BR><B>To:</B> Barney Wolff; =
[email-masked]<BR><B>Subject:</B>=20
  Clearinghouse/Aggregator Support for CUI<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText37396 dir=3Dltr>
  <DIV dir=3Dltr><FONT size=3D2>Collegues, </FONT></DIV><FONT =
size=3D2></FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>I wanted to chime in again on the adoption of CUI and =
summarize=20
  where I see the general consensus within the industry on legacy-based=20
  work-arounds.&nbsp; When I say "Industry", I mean from the results of =
parallel=20
  multi-year analysis by&nbsp;WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, =
IRAP,=20
  Intel/IDA IWS&nbsp;and several well-respected RADIUS experts within =
this=20
  organization.&nbsp; From a Clearinghouse/Aggregator standpoint, I have =

  intimate knowlege of several major RADIUS clearinghouse systems and =
their=20
  supplying networks&nbsp;and know that what I describe here is =
absolutely=20
  crucial to the proper adoption and mediated AAA of Tunneled EAP =
methods for=20
  WPA Public Access.&nbsp;&nbsp;&nbsp; This problem is very well=20
  understood!&nbsp;&nbsp;&nbsp; Class doesn't work.&nbsp; NAI =
modification is=20
  bad.&nbsp; The Outer-Identity is discarded at Authorization and there =
is no=20
  good way to oversee tunneled EAP authentications without Early =
Termination or=20
  reflection in User-Name which modifies the NAI.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is basically designed to close operational loopoles =
in RADIUS=20
  allowed by the original RFCs, but which have impacted roaming network=20
  solutions in a negative way, particularly with the introduction of =
multiple=20
  identity tunneled protocols such as PEAP or TTLS.&nbsp; To concur what =
was=20
  said earlier on this thread,&nbsp;a clearly chargeable user/alias =
reflecting=20
  the home network's authenticated user profile is absolutely neccessary =
for all=20
  parties and *must be transparent*.&nbsp;&nbsp; </DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The concern for legacy-based support is valid, but=20
  unwarranted.&nbsp; If presented in a hybrid network, any new =
attributes should=20
  be silently discarded and not dropped or NAKed due to malformation or=20
  unsupported attributes.&nbsp; Besides, the CUI is specifically geared =
to=20
  Multi-Identity EAP authentications which in all honestly, are built =
with the=20
  latest protocols.&nbsp; An older radius endpoint could trigger CUI by =
virtue=20
  of including the User-Name in its Access-Accepts, but would merely =
drop the=20
  attribute when it arrives in Accounting (assuming that the NAS doesn't =
change=20
  the NAI and route it into neverland)</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The loophole RADIUS&nbsp;operations are:</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>1 - User-Name Overwrite:&nbsp;&nbsp; Overwriting the =
User-Name=20
  with the User-Name in the Access-Accept.&nbsp; Ouch!! Whether by =
chance or=20
  choice, this is just *wrong* as an accounting approach.&nbsp; In a =
Local or=20
  Bi-lateral service, I can see why this would be useful to reflect the=20
  authenticated profile from the Access-Accept User-Name&nbsp;(assuming =
the home=20
  network uses an @realm or they won't get Accounting back, even in =
standard=20
  methods).&nbsp; But with a Tunneled EAP Inner ID being =
returned&nbsp;in a=20
  Home-Based Access-Accept to a network which derives its peering from=20
  client-based source decorated NAI?&nbsp; It is=20
  Desastrous!!&nbsp;&nbsp;Furthermore, willfull lack of decoration for =
the Inner=20
  ID is a clear opportunity for fraud!&nbsp; Therefore, User-Name is not =
allowed=20
  to be returned in the Access-Accept User-Name so that RADIUS networks =
can be=20
  assured to receive Accounting packets down the same peering path that =
the=20
  Authentication use.&nbsp;&nbsp;</DIV>
  <DIV dir=3Dltr><SPAN class=3D661022405-25102004><FONT color=3D#0000ff =
size=3D2><FONT=20
  color=3D#000000 size=3D3><FONT color=3D#0000ff><SPAN=20
  =
class=3D825451606-25102004></SPAN></FONT></FONT></FONT></SPAN>&nbsp;</DIV=
>
  <DIV dir=3Dltr>2 - NAI:&nbsp; As someone rightfully noted on this =
reflector, the=20
  proprietary Global clearinghouse Prefix-based NAI construction methods =
which=20
  have evolved over the past decade are not represented in the latest=20
  drafts.&nbsp; These methods were designed with business and RADIUS=20
  legacy&nbsp;interoperability in mind.&nbsp; Simple chained =
suffix-based=20
  routing to consumers (@realm@realm) was the only standard that we =
had.&nbsp;=20
  It allowed for reseller arrangements.&nbsp; However, in order to deal =
with the=20
  aggregation of networks for supply, another mechanism was =
needed.&nbsp; The=20
  prefix.&nbsp; The "/" was initially presented by UUnet and because it =
was not=20
  specifically reserved, allowed the formation of proprietary network=20
  aggregation while leveraging the stadards-based realm support for =
resale of=20
  that aggregated service.&nbsp;operator/a<A=20
  =
href=3D"mailto:operator/agregator/user@realm@reseller">gregator/user@real=
m@reseller</A>.&nbsp;&nbsp;Now=20
  it is&nbsp;supported ubiquitously and maintains legacy compat =
down&nbsp;to=20
  livingston 1.16.&nbsp;&nbsp;&nbsp; Whether good or bad, reality =
dictates that=20
  it is a defacto standard.&nbsp; Ergo the originally presented NAI held =
by the=20
  NAS must not be changed based on "standard" NAI construction=20
  principles...ever...at least for use with these global networks and =
their=20
  partners.&nbsp;&nbsp; You simply don't know in every case how they =
have=20
  constructed the NAI and must always respect a pre-decorated NAI.&nbsp; =
</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The disparate NAS support for User-Name overwrite is =
mitigated by=20
  the elimination of User-Name in the A-A, basically breaking CUI too =
until=20
  allowed on a verified CUI functional network which will be the normal=20
  oversight for deploying a new WPA service.&nbsp;&nbsp; Tunneled=20
  EAP&nbsp;for&nbsp;Public Access roaming&nbsp;will not be adopted until =
the=20
  User-Name is passed back in the Access Accept for use with the CUI =
only and=20
  never the User-name.&nbsp; This will only happen&nbsp;after =
verification that=20
  these specific operations have been corrected and CUI fulfills the =
exposure of=20
  the Authenticated Home User Profile without modifying the Accounting=20
  User-Name.&nbsp; Its that simple.&nbsp; We need the NAI in the =
User-Name=20
  unspoiled to honor our routing and aggregation methods.&nbsp; A =
consistent way=20
  to expose the actual authenticated profile on a per-user/per-session =
basis for=20
  the purposes of revenue assurance, fraud detection and service =
oversight is=20
  fundamental in a Federated AAA Fabric such as iPass or an=20
  aggregated&nbsp;RADIUS peering fabric such as with our many =
competitors.&nbsp;=20
  </DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>From discussion with WISP global partners deploying =
WPA, CUI=20
  service oversight is also crucial where **no roaming** is even=20
  occurring!&nbsp; Since the OuterID is dropped at the time of =
authentication,=20
  you simply have to know which profile is authorized&nbsp;as exposed in =
the=20
  accounting.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>
  <DIV dir=3Dltr>CLASS - The Class Attribute&nbsp;was the initial =
legacy-based=20
  work-around to CUI based on its ability to reflect home data in an =
accounting=20
  stream.&nbsp; However:</DIV>
  <DIV dir=3Dltr>&nbsp;1 - It is intended to be opaque to all but the =
home network=20
  (which does no good since the whole purpose is to tie specific =
sessions to=20
  distinct authorizations between all parties.)</DIV>
  <DIV dir=3Dltr>2 - This is an additive attribute and their&nbsp;value =
ordering=20
  unspecified.&nbsp; How many classes to we demand support for in a =
NAS?&nbsp;=20
  One?&nbsp; Four?&nbsp; Eight?&nbsp; Many of these APs don't have that =
much=20
  processing power.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is the correct standards-based approach to fixing =
the=20
  problems which have arisen with multiple-identity RADIUS auth and =
accounting=20
  methods.&nbsp; While it will not solve all problems (like MSCHAPv2 in =
TTLS IN=20
  TTLS), but it does respond to the readily available EAP supplicants =
and=20
  provides the current global RADIUS networks with the capacity to =
deploy, bill=20
  and oversee WPA networks against fraud.&nbsp; Without this, other =
proprietary=20
  methods will be done, I assure you.&nbsp; However, our job would be =
much=20
  easier if there was wide adoption of the CUI attribute.&nbsp; iPass =
for=20
  instance, would mandate and facilitate its adoption immediately.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is not an overloading of a legacy attribute or =
arbitrary=20
  kludge of existing attributes in order to make these networks =
work.&nbsp; It=20
  is a necessary correction amongst the others listed above.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>Thanks for your time.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>Blair Bullock</DIV>
  <DIV dir=3Dltr>Systems Arhitect, iPass Inc.</DIV>
  <DIV =
dir=3Dltr>&nbsp;</DIV></DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4BABA.69C81CF6--

--
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, 25 Oct 2004 17:47:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI 
Date: Mon, 25 Oct 2004 10:43:43 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, <[email-masked]>

Hi Alan,

The CUI does not have to reveal the user's real identity.  However, at
the end of the day, it is the operator's choice.  "opaque string" type
is one way to maintain user's anonymity as you noted -- but I guess you
could also do this with the NAI format -- e.g., [email-masked]  where
1234 is not the user's real identity, no? =20

Regarding to a suggested "best practices" for format, are you suggesting
that the draft should recommend one of the specified formats, or suggest
a format for the "opaque string"?

BR,
Farid

> "Alan DeKok" <[email-masked]> wrote:
>=20
>   My one concern about the CUI is privacy.  We may want intermediaries
> to not know the identity, but to still have a unique "token" which may
> be used to bill the home network.  The "opaque string" type is good
> for this purpose, but it would be good to include a suggested "best
> practices" for format.
>=20
>   Alan DeKok.
>=20
> --
> 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/>
>=20

--
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, 25 Oct 2004 17:39:18 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 13:38:37 -0400

Hi Alan,

Just to add and highlight some of your thoughts.  

> -----Original Message-----
> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Monday, October 25, 2004 10:49 PM
> To: [email-masked]
> Subject: Re: Clearinghouse/Aggregator Support for CUI
> 
> 
> "Blair T. Bullock" <[email-masked]> wrote:
> > CLASS - The Class Attribute was the initial legacy-based 
> work-around 
> > to CUI based on its ability to reflect home data in an accounting 
> > stream.
> > However:
> ...
> > 2 - This is an additive attribute and their value ordering 
> > unspecified.
> > How many classes to we demand support for in a NAS?  One?  
> Four?  Eight?
> >  Many of these APs don't have that much processing power.
> 
>   How much processing power is required to keep track of ~1k 
> of data, for multiple attributes?
> 
>   I can see memory on the AP being an issue, and 
> implemenation limitations.  Some AP's already discard 
> trailing octets from the State attribute, if it's longer than 
> 16 octets.  Similar issues may apply to Class.

Many NASes (if they support Class) will only support one Class attribute.
Many NASes truncate Class at the first NULL.
All very ugly.

>   I don't see ordering as much of an issue.  Implementations 
> which use the Class attribute should have some way of 
> recognizing which of multiple Class attributes is theirs.

True.  
 
>   I'm not saying that we *should* use Class, as the CUI does 
> appear to be better.  I just wish to be sure that the 
> benefits of CUI are clear.

I don't think Class is even a starter when we are talking outside the home
realm.
 
>   My one concern about the CUI is privacy.  We may want 
> intermediaries to not know the identity, but to still have a 
> unique "token" which may be used to bill the home network.  
> The "opaque string" type is good for this purpose, but it 
> would be good to include a suggested "best practices" for format.

I agree.  My approach to CUI was to utilize an opaque string. Communities of
operators (e.g., 3GPP 3GPP2 ) would then choose the format that is most
appropriate for this attribute and the contents.  So if they were concerned
about privacy etc... 

However, due to Diameter CC and GSMA we have formally defined several
formats for this attribute.

But most importantly, its up to the Operator's to choose how private the CUI
is.  Its up to us to make sure everyone understands the Privacy issue.

>   Alan DeKok.
> 
> --
> 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/>

Envelope-to: [email-masked]
Delivery-date: Mon, 25 Oct 2004 14:38:45 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Clearinghouse/Aggregator Support for CUI 
Date: Mon, 25 Oct 2004 10:48:32 -0400
Message-Id: <[email-masked]>

"Blair T. Bullock" <[email-masked]> wrote:
> CLASS - The Class Attribute was the initial legacy-based work-around to
> CUI based on its ability to reflect home data in an accounting stream.
> However:
...
> 2 - This is an additive attribute and their value ordering unspecified. 
> How many classes to we demand support for in a NAS?  One?  Four?  Eight?
>  Many of these APs don't have that much processing power.

  How much processing power is required to keep track of ~1k of data,
for multiple attributes?

  I can see memory on the AP being an issue, and implemenation
limitations.  Some AP's already discard trailing octets from the State
attribute, if it's longer than 16 octets.  Similar issues may apply to
Class.

  I don't see ordering as much of an issue.  Implementations which use
the Class attribute should have some way of recognizing which of
multiple Class attributes is theirs.

  I'm not saying that we *should* use Class, as the CUI does appear to
be better.  I just wish to be sure that the benefits of CUI are clear.

  My one concern about the CUI is privacy.  We may want intermediaries
to not know the identity, but to still have a unique "token" which may
be used to bill the home network.  The "opaque string" type is good
for this purpose, but it would be good to include a suggested "best
practices" for format.

  Alan DeKok.

--
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, 25 Oct 2004 06:37:02 +0000
Content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Sun, 24 Oct 2004 23:36:15 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Blair T. Bullock" <[email-masked]>, "Barney Wolff" <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4BA5C.ED38EE90
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Blair,
=20
Thanks for good notes Blair.
=20
On "UserName Overwrite" below,  the RADIUS routing is done based on the
realm portion of the NAI -- not the user-name part.  As long as the
realm and decorated portion of the NAI sent in the Access-Request gets
reflected in the Access-Accept  then the billing should follow the same
path as the authentication packets.  for the purpose of  the CUI, when
we say "User-Name Overwrite", I think we are referring to the user-name
part of the NAI,  NOT the realm or decoration part.  However, the
problem arises when the decoration part in Access-Request is stripped
off on its way to the home RADIUS server.   And where the RFC2865 says
this about the UserName(1) : "   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."    To fix the routing problem (i.e., ensuring authentication
and accounting packets follow the same path),   it seems to me that the
NAS should also always  include the UserName(1) that was sent in the
Access-Request in Accounting-Requests (on contrary to what RFC 2865
states).     And if so ,  then the intermediaries will not have access
to the CUI that was conveyed by the User-Name Overwrite!     In summary,
This problem can be fixed with the introduction of the CUI *in
conjunction* with the language changes to RFC2865 (as mentinoed above).
Your comment?
=20
BR,
Farid

	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Blair T. Bullock
	Sent: Sunday, October 24, 2004 1:18 PM
	To: Barney Wolff; [email-masked]
	Subject: Clearinghouse/Aggregator Support for CUI
=09
=09
	Collegues,=20
=09
=09
	=20
	I wanted to chime in again on the adoption of CUI and summarize
where I see the general consensus within the industry on legacy-based
work-arounds.  When I say "Industry", I mean from the results of
parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance,
IRAP, Intel/IDA IWS and several well-respected RADIUS experts within
this organization.  From a Clearinghouse/Aggregator standpoint, I have
intimate knowlege of several major RADIUS clearinghouse systems and
their supplying networks and know that what I describe here is
absolutely crucial to the proper adoption and mediated AAA of Tunneled
EAP methods for WPA Public Access.    This problem is very well
understood!    Class doesn't work.  NAI modification is bad.  The
Outer-Identity is discarded at Authorization and there is no good way to
oversee tunneled EAP authentications without Early Termination or
reflection in User-Name which modifies the NAI.
	=20
	CUI is basically designed to close operational loopoles in
RADIUS allowed by the original RFCs, but which have impacted roaming
network solutions in a negative way, particularly with the introduction
of multiple identity tunneled protocols such as PEAP or TTLS.  To concur
what was said earlier on this thread, a clearly chargeable user/alias
reflecting the home network's authenticated user profile is absolutely
neccessary for all parties and *must be transparent*.  =20
	=20
	The concern for legacy-based support is valid, but unwarranted.
If presented in a hybrid network, any new attributes should be silently
discarded and not dropped or NAKed due to malformation or unsupported
attributes.  Besides, the CUI is specifically geared to Multi-Identity
EAP authentications which in all honestly, are built with the latest
protocols.  An older radius endpoint could trigger CUI by virtue of
including the User-Name in its Access-Accepts, but would merely drop the
attribute when it arrives in Accounting (assuming that the NAS doesn't
change the NAI and route it into neverland)
	=20
	The loophole RADIUS operations are:
	=20
	1 - User-Name Overwrite:   Overwriting the User-Name with the
User-Name in the Access-Accept.  Ouch!! Whether by chance or choice,
this is just *wrong* as an accounting approach.  In a Local or
Bi-lateral service, I can see why this would be useful to reflect the
authenticated profile from the Access-Accept User-Name (assuming the
home network uses an @realm or they won't get Accounting back, even in
standard methods).  But with a Tunneled EAP Inner ID being returned in a
Home-Based Access-Accept to a network which derives its peering from
client-based source decorated NAI?  It is Desastrous!!  Furthermore,
willfull lack of decoration for the Inner ID is a clear opportunity for
fraud!  Therefore, User-Name is not allowed to be returned in the
Access-Accept User-Name so that RADIUS networks can be assured to
receive Accounting packets down the same peering path that the
Authentication use. =20
	=20
	2 - NAI:  As someone rightfully noted on this reflector, the
proprietary Global clearinghouse Prefix-based NAI construction methods
which have evolved over the past decade are not represented in the
latest drafts.  These methods were designed with business and RADIUS
legacy interoperability in mind.  Simple chained suffix-based routing to
consumers (@realm@realm) was the only standard that we had.  It allowed
for reseller arrangements.  However, in order to deal with the
aggregation of networks for supply, another mechanism was needed.  The
prefix.  The "/" was initially presented by UUnet and because it was not
specifically reserved, allowed the formation of proprietary network
aggregation while leveraging the stadards-based realm support for resale
of that aggregated service. operator/agregator/user@realm@reseller
<mailto:operator/agregator/user@realm@reseller> .  Now it is supported
ubiquitously and maintains legacy compat down to livingston 1.16.
Whether good or bad, reality dictates that it is a defacto standard.
Ergo the originally presented NAI held by the NAS must not be changed
based on "standard" NAI construction principles...ever...at least for
use with these global networks and their partners.   You simply don't
know in every case how they have constructed the NAI and must always
respect a pre-decorated NAI. =20
	=20
	The disparate NAS support for User-Name overwrite is mitigated
by the elimination of User-Name in the A-A, basically breaking CUI too
until allowed on a verified CUI functional network which will be the
normal oversight for deploying a new WPA service.   Tunneled EAP for
Public Access roaming will not be adopted until the User-Name is passed
back in the Access Accept for use with the CUI only and never the
User-name.  This will only happen after verification that these specific
operations have been corrected and CUI fulfills the exposure of the
Authenticated Home User Profile without modifying the Accounting
User-Name.  Its that simple.  We need the NAI in the User-Name unspoiled
to honor our routing and aggregation methods.  A consistent way to
expose the actual authenticated profile on a per-user/per-session basis
for the purposes of revenue assurance, fraud detection and service
oversight is fundamental in a Federated AAA Fabric such as iPass or an
aggregated RADIUS peering fabric such as with our many competitors. =20
	=20
	From discussion with WISP global partners deploying WPA, CUI
service oversight is also crucial where **no roaming** is even
occurring!  Since the OuterID is dropped at the time of authentication,
you simply have to know which profile is authorized as exposed in the
accounting.
	=20
	CLASS - The Class Attribute was the initial legacy-based
work-around to CUI based on its ability to reflect home data in an
accounting stream.  However:
	 1 - It is intended to be opaque to all but the home network
(which does no good since the whole purpose is to tie specific sessions
to distinct authorizations between all parties.)
	2 - This is an additive attribute and their value ordering
unspecified.  How many classes to we demand support for in a NAS?  One?
Four?  Eight?  Many of these APs don't have that much processing power.
	=20
	CUI is the correct standards-based approach to fixing the
problems which have arisen with multiple-identity RADIUS auth and
accounting methods.  While it will not solve all problems (like MSCHAPv2
in TTLS IN TTLS), but it does respond to the readily available EAP
supplicants and provides the current global RADIUS networks with the
capacity to deploy, bill and oversee WPA networks against fraud.
Without this, other proprietary methods will be done, I assure you.
However, our job would be much easier if there was wide adoption of the
CUI attribute.  iPass for instance, would mandate and facilitate its
adoption immediately.
	=20
	CUI is not an overloading of a legacy attribute or arbitrary
kludge of existing attributes in order to make these networks work.  It
is a necessary correction amongst the others listed above.
	=20
	Thanks for your time.
	=20
	Blair Bullock
	Systems Arhitect, iPass Inc.
	=20

------_=_NextPart_001_01C4BA5C.ED38EE90
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial =
color=3D#0000ff>Hi=20
Blair,</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial=20
color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial =
color=3D#0000ff>Thanks for=20
good notes Blair.</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =
size=3D2>On=20
"UserName Overwrite" below,&nbsp; <FONT face=3D"Times New Roman"=20
size=3D3>t</FONT><SPAN class=3D661022405-25102004><FONT color=3D#0000ff =
size=3D2><FONT=20
size=3D3><FONT face=3D"Times New Roman">he RADIUS routing is done based =
on the realm=20
portion of the NAI -- not the user-name part.&nbsp; As long as the=20
realm&nbsp;</FONT><FONT size=3D2><SPAN class=3D825451606-25102004><FONT=20
face=3DArial>and decorated&nbsp;</SPAN><SPAN =
class=3D825451606-25102004>portion of=20
the</SPAN></FONT></FONT><FONT face=3D"Times New Roman">&nbsp;NAI sent in =
the=20
Access-Request gets reflected in the Access-Accept &nbsp;then the =
billing should=20
follow the same path as the authentication packets.&nbsp; for the =
purpose=20
of&nbsp; the CUI, when we say "User-Name Overwrite", I think we are =
referring to=20
the user-name&nbsp;part of the NAI,&nbsp; NOT the realm or decoration=20
part.&nbsp; However, the problem arises when the decoration part in=20
Access-Request is stripped off on its way to the home RADIUS =
server.&nbsp;&nbsp;=20
And where the RFC2865 says this about the UserName(1) : =
"</FONT></FONT><FONT=20
color=3D#000000 size=3D3><FONT face=3D"Times New =
Roman">&nbsp;</FONT><FONT=20
color=3D#0000ff><FONT face=3D"Times New Roman">&nbsp; It MAY be sent in =
an=20
Access-Accept packet, in which case the&nbsp;client SHOULD use the name =
returned=20
in the Access-Accept packet in&nbsp;all Accounting-Request packets for =
this=20
session."&nbsp;&nbsp;&nbsp; To fix the routing problem (i.e., ensuring=20
authentication and accounting packets follow the same path),&nbsp; =
&nbsp;it=20
seems to me that the NAS should also always&nbsp;</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial=20
size=3D2>&nbsp;include&nbsp;</FONT></SPAN><FONT face=3D"Times New =
Roman">the=20
UserName(1) that was sent in the Access-Request in Accounting-Requests =
(on=20
contrary to what RFC 2865 states).&nbsp;&nbsp;&nbsp;&nbsp;</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial size=3D2>&nbsp;<FONT =
size=3D3>And if=20
so&nbsp;</FONT></FONT></SPAN><FONT face=3D"Times New =
Roman">,</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial>&nbsp; =
then</FONT></SPAN><FONT=20
face=3D"Times New Roman"> the intermediaries will not have access to the =
CUI that=20
was conveyed by the User-Name Overwrite</FONT><SPAN=20
class=3D825451606-25102004><FONT face=3DArial>!&nbsp;</SPAN><SPAN=20
class=3D825451606-25102004>&nbsp;</SPAN><SPAN=20
class=3D825451606-25102004>&nbsp;&nbsp; In summary,&nbsp; This problem =
can be=20
fixed with the introduction of the CUI *in conjunction* with the =
language=20
changes to RFC2865 (as mentinoed above).&nbsp; Your=20
comment?</SPAN></FONT></FONT></FONT></FONT></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D825451606-25102004></SPAN><SPAN =
class=3D825451606-25102004><FONT=20
face=3DArial color=3D#0000ff size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D825451606-25102004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [email-masked] [mailto:[email-masked]] =
<B>On=20
  Behalf Of </B>Blair T. Bullock<BR><B>Sent:</B> Sunday, October 24, =
2004 1:18=20
  PM<BR><B>To:</B> Barney Wolff; =
[email-masked]<BR><B>Subject:</B>=20
  Clearinghouse/Aggregator Support for CUI<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText37396 dir=3Dltr>
  <DIV dir=3Dltr><FONT size=3D2>Collegues, </FONT></DIV><FONT =
size=3D2></FONT></DIV>
  <DIV dir=3Dltr><FONT size=3D2>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>I wanted to chime in again on the adoption of CUI and =
summarize=20
  where I see the general consensus within the industry on legacy-based=20
  work-arounds.&nbsp; When I say "Industry", I mean from the results of =
parallel=20
  multi-year analysis by&nbsp;WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, =
IRAP,=20
  Intel/IDA IWS&nbsp;and several well-respected RADIUS experts within =
this=20
  organization.&nbsp; From a Clearinghouse/Aggregator standpoint, I have =

  intimate knowlege of several major RADIUS clearinghouse systems and =
their=20
  supplying networks&nbsp;and know that what I describe here is =
absolutely=20
  crucial to the proper adoption and mediated AAA of Tunneled EAP =
methods for=20
  WPA Public Access.&nbsp;&nbsp;&nbsp; This problem is very well=20
  understood!&nbsp;&nbsp;&nbsp; Class doesn't work.&nbsp; NAI =
modification is=20
  bad.&nbsp; The Outer-Identity is discarded at Authorization and there =
is no=20
  good way to oversee tunneled EAP authentications without Early =
Termination or=20
  reflection in User-Name which modifies the NAI.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is basically designed to close operational loopoles =
in RADIUS=20
  allowed by the original RFCs, but which have impacted roaming network=20
  solutions in a negative way, particularly with the introduction of =
multiple=20
  identity tunneled protocols such as PEAP or TTLS.&nbsp; To concur what =
was=20
  said earlier on this thread,&nbsp;a clearly chargeable user/alias =
reflecting=20
  the home network's authenticated user profile is absolutely neccessary =
for all=20
  parties and *must be transparent*.&nbsp;&nbsp; </DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The concern for legacy-based support is valid, but=20
  unwarranted.&nbsp; If presented in a hybrid network, any new =
attributes should=20
  be silently discarded and not dropped or NAKed due to malformation or=20
  unsupported attributes.&nbsp; Besides, the CUI is specifically geared =
to=20
  Multi-Identity EAP authentications which in all honestly, are built =
with the=20
  latest protocols.&nbsp; An older radius endpoint could trigger CUI by =
virtue=20
  of including the User-Name in its Access-Accepts, but would merely =
drop the=20
  attribute when it arrives in Accounting (assuming that the NAS doesn't =
change=20
  the NAI and route it into neverland)</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The loophole RADIUS&nbsp;operations are:</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>1 - User-Name Overwrite:&nbsp;&nbsp; Overwriting the =
User-Name=20
  with the User-Name in the Access-Accept.&nbsp; Ouch!! Whether by =
chance or=20
  choice, this is just *wrong* as an accounting approach.&nbsp; In a =
Local or=20
  Bi-lateral service, I can see why this would be useful to reflect the=20
  authenticated profile from the Access-Accept User-Name&nbsp;(assuming =
the home=20
  network uses an @realm or they won't get Accounting back, even in =
standard=20
  methods).&nbsp; But with a Tunneled EAP Inner ID being =
returned&nbsp;in a=20
  Home-Based Access-Accept to a network which derives its peering from=20
  client-based source decorated NAI?&nbsp; It is=20
  Desastrous!!&nbsp;&nbsp;Furthermore, willfull lack of decoration for =
the Inner=20
  ID is a clear opportunity for fraud!&nbsp; Therefore, User-Name is not =
allowed=20
  to be returned in the Access-Accept User-Name so that RADIUS networks =
can be=20
  assured to receive Accounting packets down the same peering path that =
the=20
  Authentication use.&nbsp;&nbsp;</DIV>
  <DIV dir=3Dltr><SPAN class=3D661022405-25102004><FONT color=3D#0000ff =
size=3D2><FONT=20
  color=3D#000000 size=3D3><FONT color=3D#0000ff><SPAN=20
  =
class=3D825451606-25102004>&nbsp;</SPAN></FONT></FONT></FONT></SPAN></DIV=
>
  <DIV dir=3Dltr>2 - NAI:&nbsp; As someone rightfully noted on this =
reflector, the=20
  proprietary Global clearinghouse Prefix-based NAI construction methods =
which=20
  have evolved over the past decade are not represented in the latest=20
  drafts.&nbsp; These methods were designed with business and RADIUS=20
  legacy&nbsp;interoperability in mind.&nbsp; Simple chained =
suffix-based=20
  routing to consumers (@realm@realm) was the only standard that we =
had.&nbsp;=20
  It allowed for reseller arrangements.&nbsp; However, in order to deal =
with the=20
  aggregation of networks for supply, another mechanism was =
needed.&nbsp; The=20
  prefix.&nbsp; The "/" was initially presented by UUnet and because it =
was not=20
  specifically reserved, allowed the formation of proprietary network=20
  aggregation while leveraging the stadards-based realm support for =
resale of=20
  that aggregated service.&nbsp;operator/a<A=20
  =
href=3D"mailto:operator/agregator/user@realm@reseller">gregator/user@real=
m@reseller</A>.&nbsp;&nbsp;Now=20
  it is&nbsp;supported ubiquitously and maintains legacy compat =
down&nbsp;to=20
  livingston 1.16.&nbsp;&nbsp;&nbsp; Whether good or bad, reality =
dictates that=20
  it is a defacto standard.&nbsp; Ergo the originally presented NAI held =
by the=20
  NAS must not be changed based on "standard" NAI construction=20
  principles...ever...at least for use with these global networks and =
their=20
  partners.&nbsp;&nbsp; You simply don't know in every case how they =
have=20
  constructed the NAI and must always respect a pre-decorated NAI.&nbsp; =
</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>The disparate NAS support for User-Name overwrite is =
mitigated by=20
  the elimination of User-Name in the A-A, basically breaking CUI too =
until=20
  allowed on a verified CUI functional network which will be the normal=20
  oversight for deploying a new WPA service.&nbsp;&nbsp; Tunneled=20
  EAP&nbsp;for&nbsp;Public Access roaming&nbsp;will not be adopted until =
the=20
  User-Name is passed back in the Access Accept for use with the CUI =
only and=20
  never the User-name.&nbsp; This will only happen&nbsp;after =
verification that=20
  these specific operations have been corrected and CUI fulfills the =
exposure of=20
  the Authenticated Home User Profile without modifying the Accounting=20
  User-Name.&nbsp; Its that simple.&nbsp; We need the NAI in the =
User-Name=20
  unspoiled to honor our routing and aggregation methods.&nbsp; A =
consistent way=20
  to expose the actual authenticated profile on a per-user/per-session =
basis for=20
  the purposes of revenue assurance, fraud detection and service =
oversight is=20
  fundamental in a Federated AAA Fabric such as iPass or an=20
  aggregated&nbsp;RADIUS peering fabric such as with our many =
competitors.&nbsp;=20
  </DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>From discussion with WISP global partners deploying =
WPA, CUI=20
  service oversight is also crucial where **no roaming** is even=20
  occurring!&nbsp; Since the OuterID is dropped at the time of =
authentication,=20
  you simply have to know which profile is authorized&nbsp;as exposed in =
the=20
  accounting.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>
  <DIV dir=3Dltr>CLASS - The Class Attribute&nbsp;was the initial =
legacy-based=20
  work-around to CUI based on its ability to reflect home data in an =
accounting=20
  stream.&nbsp; However:</DIV>
  <DIV dir=3Dltr>&nbsp;1 - It is intended to be opaque to all but the =
home network=20
  (which does no good since the whole purpose is to tie specific =
sessions to=20
  distinct authorizations between all parties.)</DIV>
  <DIV dir=3Dltr>2 - This is an additive attribute and their&nbsp;value =
ordering=20
  unspecified.&nbsp; How many classes to we demand support for in a =
NAS?&nbsp;=20
  One?&nbsp; Four?&nbsp; Eight?&nbsp; Many of these APs don't have that =
much=20
  processing power.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is the correct standards-based approach to fixing =
the=20
  problems which have arisen with multiple-identity RADIUS auth and =
accounting=20
  methods.&nbsp; While it will not solve all problems (like MSCHAPv2 in =
TTLS IN=20
  TTLS), but it does respond to the readily available EAP supplicants =
and=20
  provides the current global RADIUS networks with the capacity to =
deploy, bill=20
  and oversee WPA networks against fraud.&nbsp; Without this, other =
proprietary=20
  methods will be done, I assure you.&nbsp; However, our job would be =
much=20
  easier if there was wide adoption of the CUI attribute.&nbsp; iPass =
for=20
  instance, would mandate and facilitate its adoption immediately.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>CUI is not an overloading of a legacy attribute or =
arbitrary=20
  kludge of existing attributes in order to make these networks =
work.&nbsp; It=20
  is a necessary correction amongst the others listed above.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>Thanks for your time.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>Blair Bullock</DIV>
  <DIV dir=3Dltr>Systems Arhitect, iPass Inc.</DIV>
  <DIV =
dir=3Dltr>&nbsp;</DIV></DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4BA5C.ED38EE90--

--
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, 25 Oct 2004 04:06:45 +0000
content-class: urn:content-classes:message
Subject: RE: Clearinghouse/Aggregator Support for CUI
Date: Mon, 25 Oct 2004 07:03:56 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Blair,

I agree your mail below; re-reading the current CUI draft, most of the =
information you list is missing, however. I think it would make sense to =
add a motivation section to the draft - I'd suggest adding some of the =
content from your mail as part of the motivation section.

John

-----Original Message-----
From: [email-masked] =
[mailto:[email-masked]]On Behalf Of ext Blair T. Bullock
Sent: 24 October, 2004 23:18
To: Barney Wolff; [email-masked]
Subject: Clearinghouse/Aggregator Support for CUI

Collegues,=20

I wanted to chime in again on the adoption of CUI and summarize where I =
see the general consensus within the industry on legacy-based =
work-arounds.  When I say "Industry", I mean from the results of =
parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, =
IRAP, Intel/IDA IWS and several well-respected RADIUS experts within =
this organization.  From a Clearinghouse/Aggregator standpoint, I have =
intimate knowlege of several major RADIUS clearinghouse systems and =
their supplying networks and know that what I describe here is =
absolutely crucial to the proper adoption and mediated AAA of Tunneled =
EAP methods for WPA Public Access.    This problem is very well =
understood!    Class doesn't work.  NAI modification is bad.  The =
Outer-Identity is discarded at Authorization and there is no good way to =
oversee tunneled EAP authentications without Early Termination or =
reflection in User-Name which modifies the NAI.

CUI is basically designed to close operational loopoles in RADIUS =
allowed by the original RFCs, but which have impacted roaming network =
solutions in a negative way, particularly with the introduction of =
multiple identity tunneled protocols such as PEAP or TTLS.  To concur =
what was said earlier on this thread, a clearly chargeable user/alias =
reflecting the home network's authenticated user profile is absolutely =
neccessary for all parties and *must be transparent*.  =20

The concern for legacy-based support is valid, but unwarranted.  If =
presented in a hybrid network, any new attributes should be silently =
discarded and not dropped or NAKed due to malformation or unsupported =
attributes.  Besides, the CUI is specifically geared to Multi-Identity =
EAP authentications which in all honestly, are built with the latest =
protocols.  An older radius endpoint could trigger CUI by virtue of =
including the User-Name in its Access-Accepts, but would merely drop the =
attribute when it arrives in Accounting (assuming that the NAS doesn't =
change the NAI and route it into neverland)

The loophole RADIUS operations are:

1 - User-Name Overwrite:   Overwriting the User-Name with the User-Name =
in the Access-Accept.  Ouch!! Whether by chance or choice, this is just =
*wrong* as an accounting approach.  In a Local or Bi-lateral service, I =
can see why this would be useful to reflect the authenticated profile =
from the Access-Accept User-Name (assuming the home network uses an =
@realm or they won't get Accounting back, even in standard methods).  =
But with a Tunneled EAP Inner ID being returned in a Home-Based =
Access-Accept to a network which derives its peering from client-based =
source decorated NAI?  It is Desastrous!!  Furthermore, willfull lack of =
decoration for the Inner ID is a clear opportunity for fraud!  =
Therefore, User-Name is not allowed to be returned in the Access-Accept =
User-Name so that RADIUS networks can be assured to receive Accounting =
packets down the same peering path that the Authentication use. =20

2 - NAI:  As someone rightfully noted on this reflector, the proprietary =
Global clearinghouse Prefix-based NAI construction methods which have =
evolved over the past decade are not represented in the latest drafts.  =
These methods were designed with business and RADIUS legacy =
interoperability in mind.  Simple chained suffix-based routing to =
consumers (@realm@realm) was the only standard that we had.  It allowed =
for reseller arrangements.  However, in order to deal with the =
aggregation of networks for supply, another mechanism was needed.  The =
prefix.  The "/" was initially presented by UUnet and because it was not =
specifically reserved, allowed the formation of proprietary network =
aggregation while leveraging the stadards-based realm support for resale =
of that aggregated service. operator/agregator/user@realm@reseller.  Now =
it is supported ubiquitously and maintains legacy compat down to =
livingston 1.16.    Whether good or bad, reality dictates that it is a =
defacto standard.  Ergo the originally presented NAI held by the NAS =
must not be changed based on "standard" NAI construction =
principles...ever...at least for use with these global networks and =
their partners.   You simply don't know in every case how they have =
constructed the NAI and must always respect a pre-decorated NAI. =20

The disparate NAS support for User-Name overwrite is mitigated by the =
elimination of User-Name in the A-A, basically breaking CUI too until =
allowed on a verified CUI functional network which will be the normal =
oversight for deploying a new WPA service.   Tunneled EAP for Public =
Access roaming will not be adopted until the User-Name is passed back in =
the Access Accept for use with the CUI only and never the User-name.  =
This will only happen after verification that these specific operations =
have been corrected and CUI fulfills the exposure of the Authenticated =
Home User Profile without modifying the Accounting User-Name.  Its that =
simple.  We need the NAI in the User-Name unspoiled to honor our routing =
and aggregation methods.  A consistent way to expose the actual =
authenticated profile on a per-user/per-session basis for the purposes =
of revenue assurance, fraud detection and service oversight is =
fundamental in a Federated AAA Fabric such as iPass or an aggregated =
RADIUS peering fabric such as with our many competitors. =20

>From discussion with WISP global partners deploying WPA, CUI service =
oversight is also crucial where **no roaming** is even occurring!  Since =
the OuterID is dropped at the time of authentication, you simply have to =
know which profile is authorized as exposed in the accounting.

CLASS - The Class Attribute was the initial legacy-based work-around to =
CUI based on its ability to reflect home data in an accounting stream.  =
However:
 1 - It is intended to be opaque to all but the home network (which does =
no good since the whole purpose is to tie specific sessions to distinct =
authorizations between all parties.)
2 - This is an additive attribute and their value ordering unspecified.  =
How many classes to we demand support for in a NAS?  One?  Four?  Eight? =
 Many of these APs don't have that much processing power.

CUI is the correct standards-based approach to fixing the problems which =
have arisen with multiple-identity RADIUS auth and accounting methods.  =
While it will not solve all problems (like MSCHAPv2 in TTLS IN TTLS), =
but it does respond to the readily available EAP supplicants and =
provides the current global RADIUS networks with the capacity to deploy, =
bill and oversee WPA networks against fraud.  Without this, other =
proprietary methods will be done, I assure you.  However, our job would =
be much easier if there was wide adoption of the CUI attribute.  iPass =
for instance, would mandate and facilitate its adoption immediately.

CUI is not an overloading of a legacy attribute or arbitrary kludge of =
existing attributes in order to make these networks work.  It is a =
necessary correction amongst the others listed above.

Thanks for your time.

Blair Bullock
Systems Arhitect, iPass Inc.

--
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, 24 Oct 2004 20:21:39 +0000
Content-class: urn:content-classes:message
Subject: Clearinghouse/Aggregator Support for CUI
Date: Sun, 24 Oct 2004 13:17:55 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4BA06.8C43F603
Content-Type: text/plain;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Collegues,=20
=20
I wanted to chime in again on the adoption of CUI and summarize where I =
see the general consensus within the industry on legacy-based =
work-arounds.  When I say "Industry", I mean from the results of =
parallel multi-year analysis by WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, =
IRAP, Intel/IDA IWS and several well-respected RADIUS experts within =
this organization.  From a Clearinghouse/Aggregator standpoint, I have =
intimate knowlege of several major RADIUS clearinghouse systems and =
their supplying networks and know that what I describe here is =
absolutely crucial to the proper adoption and mediated AAA of Tunneled =
EAP methods for WPA Public Access.    This problem is very well =
understood!    Class doesn't work.  NAI modification is bad.  The =
Outer-Identity is discarded at Authorization and there is no good way to =
oversee tunneled EAP authentications without Early Termination or =
reflection in User-Name which modifies the NAI.
=20
CUI is basically designed to close operational loopoles in RADIUS =
allowed by the original RFCs, but which have impacted roaming network =
solutions in a negative way, particularly with the introduction of =
multiple identity tunneled protocols such as PEAP or TTLS.  To concur =
what was said earlier on this thread, a clearly chargeable user/alias =
reflecting the home network's authenticated user profile is absolutely =
neccessary for all parties and *must be transparent*.  =20
=20
The concern for legacy-based support is valid, but unwarranted.  If =
presented in a hybrid network, any new attributes should be silently =
discarded and not dropped or NAKed due to malformation or unsupported =
attributes.  Besides, the CUI is specifically geared to Multi-Identity =
EAP authentications which in all honestly, are built with the latest =
protocols.  An older radius endpoint could trigger CUI by virtue of =
including the User-Name in its Access-Accepts, but would merely drop the =
attribute when it arrives in Accounting (assuming that the NAS doesn't =
change the NAI and route it into neverland)
=20
The loophole RADIUS operations are:
=20
1 - User-Name Overwrite:   Overwriting the User-Name with the User-Name =
in the Access-Accept.  Ouch!! Whether by chance or choice, this is just =
*wrong* as an accounting approach.  In a Local or Bi-lateral service, I =
can see why this would be useful to reflect the authenticated profile =
from the Access-Accept User-Name (assuming the home network uses an =
@realm or they won't get Accounting back, even in standard methods).  =
But with a Tunneled EAP Inner ID being returned in a Home-Based =
Access-Accept to a network which derives its peering from client-based =
source decorated NAI?  It is Desastrous!!  Furthermore, willfull lack of =
decoration for the Inner ID is a clear opportunity for fraud!  =
Therefore, User-Name is not allowed to be returned in the Access-Accept =
User-Name so that RADIUS networks can be assured to receive Accounting =
packets down the same peering path that the Authentication use. =20
=20
2 - NAI:  As someone rightfully noted on this reflector, the proprietary =
Global clearinghouse Prefix-based NAI construction methods which have =
evolved over the past decade are not represented in the latest drafts.  =
These methods were designed with business and RADIUS legacy =
interoperability in mind.  Simple chained suffix-based routing to =
consumers (@realm@realm) was the only standard that we had.  It allowed =
for reseller arrangements.  However, in order to deal with the =
aggregation of networks for supply, another mechanism was needed.  The =
prefix.  The "/" was initially presented by UUnet and because it was not =
specifically reserved, allowed the formation of proprietary network =
aggregation while leveraging the stadards-based realm support for resale =
of that aggregated service. operator/agregator/user@realm@reseller =
<mailto:operator/agregator/user@realm@reseller> .  Now it is supported =
ubiquitously and maintains legacy compat down to livingston 1.16.    =
Whether good or bad, reality dictates that it is a defacto standard.  =
Ergo the originally presented NAI held by the NAS must not be changed =
based on "standard" NAI construction principles...ever...at least for =
use with these global networks and their partners.   You simply don't =
know in every case how they have constructed the NAI and must always =
respect a pre-decorated NAI. =20
=20
The disparate NAS support for User-Name overwrite is mitigated by the =
elimination of User-Name in the A-A, basically breaking CUI too until =
allowed on a verified CUI functional network which will be the normal =
oversight for deploying a new WPA service.   Tunneled EAP for Public =
Access roaming will not be adopted until the User-Name is passed back in =
the Access Accept for use with the CUI only and never the User-name.  =
This will only happen after verification that these specific operations =
have been corrected and CUI fulfills the exposure of the Authenticated =
Home User Profile without modifying the Accounting User-Name.  Its that =
simple.  We need the NAI in the User-Name unspoiled to honor our routing =
and aggregation methods.  A consistent way to expose the actual =
authenticated profile on a per-user/per-session basis for the purposes =
of revenue assurance, fraud detection and service oversight is =
fundamental in a Federated AAA Fabric such as iPass or an aggregated =
RADIUS peering fabric such as with our many competitors. =20
=20
>From discussion with WISP global partners deploying WPA, CUI service =
oversight is also crucial where **no roaming** is even occurring!  Since =
the OuterID is dropped at the time of authentication, you simply have to =
know which profile is authorized as exposed in the accounting.
=20
CLASS - The Class Attribute was the initial legacy-based work-around to =
CUI based on its ability to reflect home data in an accounting stream.  =
However:
 1 - It is intended to be opaque to all but the home network (which does =
no good since the whole purpose is to tie specific sessions to distinct =
authorizations between all parties.)
2 - This is an additive attribute and their value ordering unspecified.  =
How many classes to we demand support for in a NAS?  One?  Four?  Eight? =
 Many of these APs don't have that much processing power.
=20
CUI is the correct standards-based approach to fixing the problems which =
have arisen with multiple-identity RADIUS auth and accounting methods.  =
While it will not solve all problems (like MSCHAPv2 in TTLS IN TTLS), =
but it does respond to the readily available EAP supplicants and =
provides the current global RADIUS networks with the capacity to deploy, =
bill and oversee WPA networks against fraud.  Without this, other =
proprietary methods will be done, I assure you.  However, our job would =
be much easier if there was wide adoption of the CUI attribute.  iPass =
for instance, would mandate and facilitate its adoption immediately.
=20
CUI is not an overloading of a legacy attribute or arbitrary kludge of =
existing attributes in order to make these networks work.  It is a =
necessary correction amongst the others listed above.
=20
Thanks for your time.
=20
Blair Bullock
Systems Arhitect, iPass Inc.
=20

------_=_NextPart_001_01C4BA06.8C43F603
Content-Type: text/html;
 charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">=0A=
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">=0A=
<HTML>=0A=
<HEAD>=0A=
=0A=
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7226.0">=0A=
<TITLE>Re: -01 version of Chargeable User Identity</TITLE>=0A=
</HEAD>=0A=
<BODY>=0A=
<DIV id=3DidOWAReplyText37396 dir=3Dltr>=0A=
<DIV dir=3Dltr><FONT size=3D2>Collegues, </FONT></DIV><FONT =
size=3D2></FONT></DIV>=0A=
<DIV dir=3Dltr><FONT size=3D2>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>I wanted to chime in again on the adoption of CUI and =
summarize =0A=
where I see the general consensus within the industry on legacy-based =0A=
work-arounds.&nbsp; When I say "Industry", I mean from the results of =
parallel =0A=
multi-year analysis by&nbsp;WISPr, GSMA, 3GPP,GWDR, Wi-Fi Alliance, =
IRAP, =0A=
Intel/IDA IWS&nbsp;and several well-respected RADIUS experts within this =0A=
organization.&nbsp; From a Clearinghouse/Aggregator standpoint, I have =
intimate =0A=
knowlege of several major RADIUS clearinghouse systems and their =
supplying =0A=
networks&nbsp;and know that what I describe here is absolutely crucial =
to the =0A=
proper adoption and mediated AAA of Tunneled EAP methods for WPA Public =0A=
Access.&nbsp;&nbsp;&nbsp; This problem is very well =0A=
understood!&nbsp;&nbsp;&nbsp; Class doesn't work.&nbsp; NAI modification =
is =0A=
bad.&nbsp; The Outer-Identity is discarded at Authorization and there is =
no good =0A=
way to oversee tunneled EAP authentications without Early Termination or =0A=
reflection in User-Name which modifies the NAI.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>CUI is basically designed to close operational loopoles =
in RADIUS =0A=
allowed by the original RFCs, but which have impacted roaming network =
solutions =0A=
in a negative way, particularly with the introduction of multiple =
identity =0A=
tunneled protocols such as PEAP or TTLS.&nbsp; To concur what was said =
earlier =0A=
on this thread,&nbsp;a clearly chargeable user/alias reflecting the home =0A=
network's authenticated user profile is absolutely neccessary for all =
parties =0A=
and *must be transparent*.&nbsp;&nbsp; </DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The concern for legacy-based support is valid, but =0A=
unwarranted.&nbsp; If presented in a hybrid network, any new attributes =
should =0A=
be silently discarded and not dropped or NAKed due to malformation or =0A=
unsupported attributes.&nbsp; Besides, the CUI is specifically geared to =0A=
Multi-Identity EAP authentications which in all honestly, are built with =
the =0A=
latest protocols.&nbsp; An older radius endpoint could trigger CUI by =
virtue of =0A=
including the User-Name in its Access-Accepts, but would merely drop the =0A=
attribute when it arrives in Accounting (assuming that the NAS doesn't =
change =0A=
the NAI and route it into neverland)</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The loophole RADIUS&nbsp;operations are:</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>1 - User-Name Overwrite:&nbsp;&nbsp; Overwriting the =
User-Name with =0A=
the User-Name in the Access-Accept.&nbsp; Ouch!! Whether by chance or =
choice, =0A=
this is just *wrong* as an accounting approach.&nbsp; In a Local or =
Bi-lateral =0A=
service, I can see why this would be useful to reflect the authenticated =
profile =0A=
from the Access-Accept User-Name&nbsp;(assuming the home network uses an =
@realm =0A=
or they won't get Accounting back, even in standard methods).&nbsp; But =
with a =0A=
Tunneled EAP Inner ID being returned&nbsp;in a Home-Based Access-Accept =
to a =0A=
network which derives its peering from client-based source decorated =
NAI?&nbsp; =0A=
It is Desastrous!!&nbsp;&nbsp;Furthermore, willfull lack of decoration =
for the =0A=
Inner ID is a clear opportunity for fraud!&nbsp; Therefore, User-Name is =
not =0A=
allowed to be returned in the Access-Accept User-Name so that RADIUS =
networks =0A=
can be assured to receive Accounting packets down the same peering path =
that the =0A=
Authentication use.&nbsp;&nbsp;</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>2 - NAI:&nbsp; As someone rightfully noted on this =
reflector, the =0A=
proprietary Global clearinghouse Prefix-based NAI construction methods =
which =0A=
have evolved over the past decade are not represented in the latest =0A=
drafts.&nbsp; These methods were designed with business and RADIUS =0A=
legacy&nbsp;interoperability in mind.&nbsp; Simple chained suffix-based =
routing =0A=
to consumers (@realm@realm) was the only standard that we had.&nbsp; It =
allowed =0A=
for reseller arrangements.&nbsp; However, in order to deal with the =
aggregation =0A=
of networks for supply, another mechanism was needed.&nbsp; The =
prefix.&nbsp; =0A=
The "/" was initially presented by UUnet and because it was not =
specifically =0A=
reserved, allowed the formation of proprietary network aggregation while =0A=
leveraging the stadards-based realm support for resale of that =
aggregated =0A=
service.&nbsp;operator/a<A =0A=
href=3D"mailto:operator/agregator/user@realm@reseller">gregator/user@real=
m@reseller</A>.&nbsp;&nbsp;Now =0A=
it is&nbsp;supported ubiquitously and maintains legacy compat =
down&nbsp;to =0A=
livingston 1.16.&nbsp;&nbsp;&nbsp; Whether good or bad, reality dictates =
that it =0A=
is a defacto standard.&nbsp; Ergo the originally presented NAI held by =
the NAS =0A=
must not be changed based on "standard" NAI construction =
principles...ever...at =0A=
least for use with these global networks and their partners.&nbsp;&nbsp; =
You =0A=
simply don't know in every case how they have constructed the NAI and =
must =0A=
always respect a pre-decorated NAI.&nbsp; </DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>The disparate NAS support for User-Name overwrite is =
mitigated by =0A=
the elimination of User-Name in the A-A, basically breaking CUI too =
until =0A=
allowed on a verified CUI functional network which will be the normal =
oversight =0A=
for deploying a new WPA service.&nbsp;&nbsp; Tunneled =
EAP&nbsp;for&nbsp;Public =0A=
Access roaming&nbsp;will not be adopted until the User-Name is passed =
back in =0A=
the Access Accept for use with the CUI only and never the =
User-name.&nbsp; This =0A=
will only happen&nbsp;after verification that these specific operations =
have =0A=
been corrected and CUI fulfills the exposure of the Authenticated Home =
User =0A=
Profile without modifying the Accounting User-Name.&nbsp; Its that =
simple.&nbsp; =0A=
We need the NAI in the User-Name unspoiled to honor our routing and =
aggregation =0A=
methods.&nbsp; A consistent way to expose the actual authenticated =
profile on a =0A=
per-user/per-session basis for the purposes of revenue assurance, fraud =0A=
detection and service oversight is fundamental in a Federated AAA Fabric =
such as =0A=
iPass or an aggregated&nbsp;RADIUS peering fabric such as with our many =0A=
competitors.&nbsp; </DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>From discussion with WISP global partners deploying WPA, =
CUI =0A=
service oversight is also crucial where **no roaming** is even =
occurring!&nbsp; =0A=
Since the OuterID is dropped at the time of authentication, you simply =
have to =0A=
know which profile is authorized&nbsp;as exposed in the accounting.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>=0A=
<DIV dir=3Dltr>CLASS - The Class Attribute&nbsp;was the initial =
legacy-based =0A=
work-around to CUI based on its ability to reflect home data in an =
accounting =0A=
stream.&nbsp; However:</DIV>=0A=
<DIV dir=3Dltr>&nbsp;1 - It is intended to be opaque to all but the home =
network =0A=
(which does no good since the whole purpose is to tie specific sessions =
to =0A=
distinct authorizations between all parties.)</DIV>=0A=
<DIV dir=3Dltr>2 - This is an additive attribute and their&nbsp;value =
ordering =0A=
unspecified.&nbsp; How many classes to we demand support for in a =
NAS?&nbsp; =0A=
One?&nbsp; Four?&nbsp; Eight?&nbsp; Many of these APs don't have that =
much =0A=
processing power.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>CUI is the correct standards-based approach to fixing the =
problems =0A=
which have arisen with multiple-identity RADIUS auth and accounting =0A=
methods.&nbsp; While it will not solve all problems (like MSCHAPv2 in =
TTLS IN =0A=
TTLS), but it does respond to the readily available EAP supplicants and =
provides =0A=
the current global RADIUS networks with the capacity to deploy, bill and =
oversee =0A=
WPA networks against fraud.&nbsp; Without this, other proprietary =
methods will =0A=
be done, I assure you.&nbsp; However, our job would be much easier if =
there was =0A=
wide adoption of the CUI attribute.&nbsp; iPass for instance, would =
mandate and =0A=
facilitate its adoption immediately.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>CUI is not an overloading of a legacy attribute or =
arbitrary kludge =0A=
of existing attributes in order to make these networks work.&nbsp; It is =
a =0A=
necessary correction amongst the others listed above.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Thanks for your time.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV>=0A=
<DIV dir=3Dltr>Blair Bullock</DIV>=0A=
<DIV dir=3Dltr>Systems Arhitect, iPass Inc.</DIV>=0A=
<DIV dir=3Dltr>&nbsp;</DIV></DIV></FONT></DIV>=0A=
=0A=
</BODY>=0A=
</HTML>
------_=_NextPart_001_01C4BA06.8C43F603--

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

Envelope-to: [email-masked]
Delivery-date: Sun, 24 Oct 2004 15:01:10 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: -01 version of Chargeable User Identity 
Date: Sun, 24 Oct 2004 11:11:11 -0400
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> Keeping state in RADIUS, where there is no "connection" between client
> and server to notice reboots and possible state loss, is, imho, a truly
> bad idea.

  Many servers already keep per-user, and per-NAS state, for a host of
reasons.  While not perfect, it works well enough to be deployed in
enterprise-scale systems.

  Can you give more details as to what part of "keeping state" you're
objecting to, and why?  I understand that tracking NAS capabilities in
proxied situations is awkward, but I don't think it's impossible.

  Alan DeKok.

--
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, 24 Oct 2004 06:14:59 +0000
Content-class: urn:content-classes:message
Subject: RE: AW: -01 version of Chargeable User Identity
Date: Sat, 23 Oct 2004 23:14:07 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Emile van Bergen" <[email-masked]>, "Lothar Reith" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi Barney,
Thanks for discussion.  Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20
> Sent: Friday, October 22, 2004 11:52 PM
> To: Adrangi, Farid
> Cc: Barney Wolff; Emile van Bergen; Lothar Reith;=20
> [email-masked]; Bernard Aboba
> Subject: Re: AW: -01 version of Chargeable User Identity
>=20
>=20
> On Fri, Oct 22, 2004 at 03:32:38PM -0700, Adrangi, Farid wrote:
> >=20
> > No, the NAS is not going to bill the end-user directly. =20
> But, it could
> > use a unique identity (known by the home network) that can=20
> be associated
> > to a session, for possible charging disputes in future.  In=20
> general, a
> > unique identity (known by the home network) is useful to all parties
> > involved in *roaming* transaction for correlating the=20
> authentication and
> > accounting packets.  I think we all are in agreement on=20
> this point.  Now
> > whether or not this can be addressed by Class(25),=20
> UserName(1), or a new
> > attribute CUI is under debate here.  On use  of Class(25) attribute
> > (which mostly discussed in this thread), it does not=20
> address the problem
> > completely as its content opaque and cannot be interpreted by the
> > entities outside the home network.  Of course, in roaming=20
> situations,
> > where there is a bilateral agreement between parties on use and
> > interpretation of the Class(25) attribute, then it works. =20
> But, we don't
> > think bilateral agreements scale in a complex global roaming.  =20
>=20
> Whoa!  There are several assumptions here that I don't think are
> universally shared (if only because I don't share them :).
>=20
> 1.  How does the unique identity help in charging disputes?  If the
> parties don't trust each other, how is an unverified identity asserted
> by the home server going to improve things?
>=20

There has to be some sort of trust relationship between the parties.
The unique identity (known to the home network) would help when the
user's identity is not exposed to the local and intermediaries outside
the home network due to use of specific methods with identity protection
(e.g., EAP-PEAP or EAP-TTLS,  EAP-SIM, and EAP-AKA). =20

> 2.  There is no need for end-to-end bilateral agreements no matter
> how complex the roaming.  How can it possibly make sense for the
> billing to take a different path than the access-request and
> accounting packets take?  The whole problem is people trying to
> shortcut that flow, and CUI or not that will just dissolve into
> profit-destroying billing disputes.
>=20

It seems that you misunderstood me.  I do agree with your point that it
does not make billing to take different path than access-request.  I
don't think I ever suggested otherwise! =20

> 3.  An opaque Class is every bit as good as CUI as evidence that the
> home server did indeed send Access-Accept.  It's the home server owner
> that needs to be convinced, and in that sense opacity is a=20
> plus, because
> it can be arranged so that neither the NAS nor any proxy can fake or
> replay a Class, if the home server is sufficiently paranoid.
>=20

Then, how can the Local and intermediary networks enforce usage policies
(e.g., a limit on simultaneous sessions) per user basis if they are not
supposed to look at or interpret the content of the class attribute, and
if the user's identity is not exposed to them in UserName(1)? =20

> 4.  If, on the other hand, the home server owner is going to=20
> claim that
> no Access-Accept was sent and yet it's been billed for service, CUI
> is no use, because an evil NAS or proxy can indeed replay one.  Do we
> want to introduce asymmetric crypto to provide non-repudiation?  Oy.
>=20

I think there is a little bit disconnect on the intent of the CUI here.
The home server and NAS are business entities and therefore some
business ethics and trust are expected here.  The main intent of CUI is
to help entities (involved in the roaming transaction) outside the home
network to identify a user's session by an identity known to the home
network. =20

> > The proposed CUI attribute is optional, hence it should be=20
> used where
> > there is a need for it.  In situations where the class(25) attribute
> > works fine, no need to introduce CUI. =20
>=20
> Yes.  The problem is that 2865 says that both server and=20
> client MAY ignore
> unknown attributes.  The clear implication is that some may not.=20
> In
> retrospect, granting that flexibility was unwise.  My own=20
> implementation
> ignores unknown attributes as a client. As a proxy, it passes unknown
> attributes in requests and strips unknown attributes in=20
> responses.  That's
> not clearly wise in the general case but correct in its particular
> application.
>=20

When you say "my implementation", I assume you are referring to a
commercial implementation currently being deployed.  Right?  Just for my
own curiosity, why passing unknown attributes in requests but not in
responses -- what is the logic behind it?

Anyhow, do you think this problem is specific to CUI?  Or, is it a
general problem when a new attribute is introduced?

> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20

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

Delivery-date: Sun, 24 Oct 2004 00:31:52 +0000
Date: Sat, 23 Oct 2004 20:31:13 -0400
From: Barney Wolff <[email-masked]>
To: Greg Weber <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: -01 version of Chargeable User Identity

On Sat, Oct 23, 2004 at 01:24:52PM -0400, Greg Weber wrote:
> > 
> > Are you suggesting that the RADIUS server keep state on NAS capabilities,
> > by presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
> > attributes to various negotiated capabilities?
> 
> Hmm. Less than ideal, but the server does already have some
> per-NAS information, e.g. shared-secret, vendor.  

Not in a proxied situation, which is the only case where CUI could even
conceivably be justified.

Keeping state in RADIUS, where there is no "connection" between client
and server to notice reboots and possible state loss, is, imho, a truly
bad idea.

-- 
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, 23 Oct 2004 17:25:21 +0000
From: Greg Weber <[email-masked]>
Subject: Re: -01 version of Chargeable User Identity
To: [email-masked] (Bernard Aboba)
Date: Sat, 23 Oct 2004 13:24:52 -0400 (EDT)
Cc: [email-masked] (Greg Weber), [email-masked]

> 
> On Tue, 19 Oct 2004, Greg Weber wrote:
> 
> > > Overhead is not the issue -- the null CUI attribute will only require 2
> > > octets.
> >
> > The overhead is a potential issue if we are introducing
> > a precedent that might be followed by many attributes
> > in the future.  The current suggestion seems to be that
> > _every_ Access-Request contain this advertisement (cf once
> > per NAS which might be more reflective of capability).
> 
> I think your point about overhead is well taken.  It's one thing to do
> this in a single case (CUI); it's another thing to set a precedent to be
> replicated again and again, on every RADIUS Access-Request.
> 
> Diameter can avoid this via capabilities negotiation (CER/CEA), but since
> RADIUS has no such feature, what do we do?
> 
> Are you suggesting that the RADIUS server keep state on NAS capabilities,
> by presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
> attributes to various negotiated capabilities?

Hmm. Less than ideal, but the server does already have some
per-NAS information, e.g. shared-secret, vendor.  

I wonder if the Status-Server/Status-Client (12/13) packet codes
mentioned in 2865 were originally intended for exchanging this
type of state information?

Greg

> 
> --
> 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, 23 Oct 2004 06:52:32 +0000
Date: Sat, 23 Oct 2004 02:51:30 -0400
From: Barney Wolff <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: Barney Wolff <[email-masked]>, Emile van Bergen <[email-masked]>, Lothar Reith <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

On Fri, Oct 22, 2004 at 03:32:38PM -0700, Adrangi, Farid wrote:
> 
> No, the NAS is not going to bill the end-user directly.  But, it could
> use a unique identity (known by the home network) that can be associated
> to a session, for possible charging disputes in future.  In general, a
> unique identity (known by the home network) is useful to all parties
> involved in *roaming* transaction for correlating the authentication and
> accounting packets.  I think we all are in agreement on this point.  Now
> whether or not this can be addressed by Class(25), UserName(1), or a new
> attribute CUI is under debate here.  On use  of Class(25) attribute
> (which mostly discussed in this thread), it does not address the problem
> completely as its content opaque and cannot be interpreted by the
> entities outside the home network.  Of course, in roaming situations,
> where there is a bilateral agreement between parties on use and
> interpretation of the Class(25) attribute, then it works.  But, we don't
> think bilateral agreements scale in a complex global roaming.   

Whoa!  There are several assumptions here that I don't think are
universally shared (if only because I don't share them :).

1.  How does the unique identity help in charging disputes?  If the
parties don't trust each other, how is an unverified identity asserted
by the home server going to improve things?

2.  There is no need for end-to-end bilateral agreements no matter
how complex the roaming.  How can it possibly make sense for the
billing to take a different path than the access-request and
accounting packets take?  The whole problem is people trying to
shortcut that flow, and CUI or not that will just dissolve into
profit-destroying billing disputes.

3.  An opaque Class is every bit as good as CUI as evidence that the
home server did indeed send Access-Accept.  It's the home server owner
that needs to be convinced, and in that sense opacity is a plus, because
it can be arranged so that neither the NAS nor any proxy can fake or
replay a Class, if the home server is sufficiently paranoid.

4.  If, on the other hand, the home server owner is going to claim that
no Access-Accept was sent and yet it's been billed for service, CUI
is no use, because an evil NAS or proxy can indeed replay one.  Do we
want to introduce asymmetric crypto to provide non-repudiation?  Oy.

> The proposed CUI attribute is optional, hence it should be used where
> there is a need for it.  In situations where the class(25) attribute
> works fine, no need to introduce CUI.  

Yes.  The problem is that 2865 says that both server and client MAY ignore
unknown attributes.  The clear implication is that some may not.  In
retrospect, granting that flexibility was unwise.  My own implementation
ignores unknown attributes as a client. As a proxy, it passes unknown
attributes in requests and strips unknown attributes in responses.  That's
not clearly wise in the general case but correct in its particular
application.

-- 
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: Fri, 22 Oct 2004 22:33:39 +0000
Content-class: urn:content-classes:message
Subject: RE: AW: -01 version of Chargeable User Identity
Date: Fri, 22 Oct 2004 15:32:38 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Emile van Bergen" <[email-masked]>, "Lothar Reith" <[email-masked]>, <[email-masked]>, "Bernard Aboba" <[email-masked]>

Hi Barney, all

No, the NAS is not going to bill the end-user directly.  But, it could
use a unique identity (known by the home network) that can be associated
to a session, for possible charging disputes in future.  In general, a
unique identity (known by the home network) is useful to all parties
involved in *roaming* transaction for correlating the authentication and
accounting packets.  I think we all are in agreement on this point.  Now
whether or not this can be addressed by Class(25), UserName(1), or a new
attribute CUI is under debate here.  On use  of Class(25) attribute
(which mostly discussed in this thread), it does not address the problem
completely as its content opaque and cannot be interpreted by the
entities outside the home network.  Of course, in roaming situations,
where there is a bilateral agreement between parties on use and
interpretation of the Class(25) attribute, then it works.  But, we don't
think bilateral agreements scale in a complex global roaming.  =20

The proposed CUI attribute is optional, hence it should be used where
there is a need for it.  In situations where the class(25) attribute
works fine, no need to introduce CUI. =20

BR,
Farid =20

>=20
> I still don't understand the local (ie, NAS) problem.  It's not going
> to bill the end user directly, in any scenario that makes=20
> business sense.
> If for no other reason, it has no billing address or credit=20
> card number,
> just, even given CUI, [email-masked].  So for whom is=20
> CUI intended?
>=20
> > However, the argument was made that if the "local realm"=20
> needs assurance,
> > it can't get this from Class, since that this attribute is=20
> to be treated
> > as opaque data by RADIUS clients.  So I think the argument=20
> for CUI is one
> > that originates from the local realm, not the home server.
>=20
> What does "assurance" mean?  Does it mean that somehow the=20
> Access-Accept
> is more trustworthy because the home server said it was=20
> [email-masked]
> rather than just [email-masked]?  Why does the NAS's=20
> owner care?
>=20
> > Does this make sense??
>=20
> Call me stubborn, but I still see the only scenario where CUI=20
> is required
> would be where the access and accounting servers are run by different
> organizations that fail to negotiate a format for Class, and=20
> where (despite
> that) the accounting server is willing to trust what the access server
> says about the user's identity.  I find it hard to believe=20
> this is a real
> case, or to sympathize if it is.
>=20
> Oh, wait.  We did hear the scenario.  The NAS or proxy is=20
> pricing based on
> the maximum number of distinct users per time-period, rather=20
> than on total
> minutes of use or number of calls or anything else easy to=20
> record.  For this
> we are talking about attribute support negotiation, servers=20
> keeping state
> on NAS capabilities and such?
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
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, 22 Oct 2004 07:54:10 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: drafts-sterman-aaa-sip-04 is available
Date: Fri, 22 Oct 2004 09:53:44 +0200

An updated draft of draft-sterman-aaa-sip is available:
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-04.txt

Changes:

Issue 3:
1) Abstract
new text:
'Several protocols borrow the syntax and authentication mechanisms
from the Hypertext Transfer Protocol, HTTP.  This document specifies
an extension to RADIUS that allows a RADIUS client in a HTTP-style
server, upon reception of a request, retrieve and compute Digest
authentication information from a RADIUS server.  Additionally, a
scenario describing  the authentication of a user emitting a
HTTP-style request is provided.'

2) body digest
renamed to Digest-Entity-Body-Hash

3) figures in attribute description
only one figure for all attributes

4) mentioning of early number assignments
removed

5) DIAMETER
-> Diameter

6) IANA request
added "This document serves as IANA registration request for ..."

7) horrible examples
shortened and fixed

Issue 4:
1) Attribute reuse
removed attribute reuse, introduced new attributes

Issue 5:
1) Digest-Stale
Use is now mandatory if server chooses nonces. 

2) Typos

Issue 6:
1) Overview too short
added overview section, rearranged document structure
     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  6
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  7

2) missing explanation for pre-computed hashes
new text:
'However, when using AKA [RFC3310] the nonce is partially derived from
a precomputed authentication vector.  These authentication vectors are
often stored centrally.'

3) unclear defintion of 'secured connection' 
added a reference to Security Considerations,
added explanation in Security Considerations

Issue 7:
Use of Message Authenticator should be mandatory
RfC 2869 is informational. I see that it is useful but
I hesitate to make it mandatory. 
new text:
'Informational RfC 3579 [RFC3579], section 3.2 describes
a Message-Authenticator attribute which MAY be used to protect the
integrity of RADIUS messages.'

Issue 8:
Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int 

In contrast to Diameter, RADIUS has no mandatory encryption support.
Sending H(A1) in the clear can make some attacks easier. Here's
the compromise:

A new attribute Digest-HA1 is introduced. It's use is restricted
to *-sess algorithms, where HA1 is constructed partially from random
values. 
>From the text:

   o  If the Digest-QoP attribute's value is 'auth' or unspecified, the
      RADIUS server puts a Digest-Response-Auth attribute into the
      Access-Accept message
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5-sess' or
      'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute
      into the Access-Accept message.
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the
      RADIUS server MUST NOT send a Digest-HA1 attribute unless the
      connection between RADIUS server and client is encrypted or
      otherwise protected against eavesdropping.

Issue 9:
On suggestion of Avi Lior, I replaced the special Access-Accept
with Access-Challenge

(Issue 10 refers to NAIbis)

Issue 11:
1) missing reference
new text:
'Due to the limitations and weaknesses of Digest authentication (see
   [RFC2617], section 4 />)..'

2) when to use server generated nonces
added a paragraph in the overview section

Wolfgang

--
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, 22 Oct 2004 07:29:22 +0000
Date: Fri, 22 Oct 2004 09:28:57 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Barney Wolff <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

Hello,

On Thu, Oct 21, 2004 at 10:51:22PM -0700, Bernard Aboba wrote:

> > I still don't understand the local (ie, NAS) problem.  It's not going
> > to bill the end user directly, in any scenario that makes business sense.
> > If for no other reason, it has no billing address or credit card number,
> > just, even given CUI, [email-masked].  So for whom is CUI intended?
> 
> Well, the original request was for the authors to explain the problem in
> their draft, and for the WG to read their explanation and opine as to
> whether the problem statement is convincing.  So the authors
> really need to answer that question to the WG's satisfaction if this draft
> is to become a WG work item.  The other alternative is for the WG to
> reject the submission, either for consideration as a WG work item, or for
> allocation of an attribute type under RFC 3575.
> 
> Since the GSMA asked for this, we owe them an extra dollop of due diligence --
> and therefore the attempt to determine whether there are any scenarios in
> which the CUI attribute is needed.
> 
> In the last few emails, I think we've established that if the local realm
> and home realm are doing business directly then the home
> realm can send Class and get what it needs and as far as I can see, there
> is no need for CUI.
> 
> But what if the local server bills an intermediary?  Then it can't
> necessarily be sure that the intermediary and home server are in agreement
> on what is to go into the Class attribute.  

But the intermediate can add its own unique Class attribute to responses
going back from the home server to the local NAS, can it not? And then
it has all the information it needs when the accounting packet comes.

> In other words, Class could be meaningful to the home server, but not
> to the intermediary.  If the intermediary and home server have
> arrangements that relate to things like simultaneous usage, then the
> intermediary may not be able to carry out those agreements without a
> meaningful username.

The intermediate proxies based on certain criteria, so I'd say it should
also be able to track sessions using those same criteria? (Modulo the
stale session problem, but CUI doesn't intend to help there).

> I accept your argument that the local server may not care  about whether
> it can confirm a billable identity or not.  If there is some
> kind of monthly report required, the local realm can generate that report
> based on the class attribute(s), by pre-arrangement with the home realm.
> 
> > What does "assurance" mean?  Does it mean that somehow the Access-Accept
> > is more trustworthy because the home server said it was [email-masked]
> > rather than just [email-masked]?  Why does the NAS's owner care?
> 
> "Assurance" means that the local server has fulfilled the terms of its
> obligation to the entity that it bills.  If this is the home server, then
> I think there is no need for CUI, since echo'ing the Class attribute
> should give the home server whatever it might need.
> 
> However, if the payor is an intermediary, then the Class attribute may not
> be sufficient.

Not the single class from the home server, but the intermediate can add
its own instance of Class. 2865 and 2866 say it's a 0+ attribute after all,
and ordering is to be preserved anyway.

If it doesn't trust the local NAS and server to be standards compliant,
it can prepend its own data to an existing Class using a separator; as
long as the home server sees the same Class it sent earlier, the
intermediate can pull any stunt he wants. But that's for the
administrator of the intermediate to decide.

Therefore I would say the intermediate too has all it needs to help it
with tracking things, including the ability to match unique responses
from the home server to accounting packets from the local NAS/proxy.

Kind regards,

Emile van Bergen.

-- 
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: Fri, 22 Oct 2004 05:51:42 +0000
Date: Thu, 21 Oct 2004 22:51:22 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

> I still don't understand the local (ie, NAS) problem.  It's not going
> to bill the end user directly, in any scenario that makes business sense.
> If for no other reason, it has no billing address or credit card number,
> just, even given CUI, [email-masked].  So for whom is CUI intended?

Well, the original request was for the authors to explain the problem in
their draft, and for the WG to read their explanation and opine as to
whether the problem statement is convincing.  So the authors
really need to answer that question to the WG's satisfaction if this draft
is to become a WG work item.  The other alternative is for the WG to
reject the submission, either for consideration as a WG work item, or for
allocation of an attribute type under RFC 3575.

Since the GSMA asked for this, we owe them an extra dollop of due diligence --
and therefore the attempt to determine whether there are any scenarios in
which the CUI attribute is needed.

In the last few emails, I think we've established that if the local realm
and home realm are doing business directly then the home
realm can send Class and get what it needs and as far as I can see, there
is no need for CUI.

But what if the local server bills an intermediary?  Then it can't
necessarily be sure that the intermediary and home server are in agreement
on what is to go into the Class attribute.  In other words, Class could be
meaningful to the home server, but not to the intermediary.  If the
intermediary and home server have arrangements that relate
to things like simultaneous usage, then the intermediary may not be able
to carry out those agreements without a meaningful username.

I accept your argument that the local server may not care  about whether
it can confirm a billable identity or not.  If there is some
kind of monthly report required, the local realm can generate that report
based on the class attribute(s), by pre-arrangement with the home realm.

> What does "assurance" mean?  Does it mean that somehow the Access-Accept
> is more trustworthy because the home server said it was [email-masked]
> rather than just [email-masked]?  Why does the NAS's owner care?

"Assurance" means that the local server has fulfilled the terms of its
obligation to the entity that it bills.  If this is the home server, then
I think there is no need for CUI, since echo'ing the Class attribute
should give the home server whatever it might need.

However, if the payor is an intermediary, then the Class attribute may not
be sufficient.

> Call me stubborn, but I still see the only scenario where CUI is required
> would be where the access and accounting servers are run by different
> organizations that fail to negotiate a format for Class, and where (despite
> that) the accounting server is willing to trust what the access server
> says about the user's identity.  I find it hard to believe this is a real
> case, or to sympathize if it is.

Yes, I think this is essentially the same scenario as the one I outlined
above, where the Accounting Server is run by an intermediary and the
authentication server is in the home realm.

Perhaps RADEXT WG participants from roaming firms can answer whether this
is a real usage scenario or not.

> Oh, wait.  We did hear the scenario.  The NAS or proxy is pricing based on
> the maximum number of distinct users per time-period, rather than on total
> minutes of use or number of calls or anything else easy to record.  For this
> we are talking about attribute support negotiation, servers keeping state
> on NAS capabilities and such?

Yes, that would be a scenario where a username is needed by the local
server and intermediary and CUI provides this, whereas Class doesn't
accomplish this without pre-arrangement.

--
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, 22 Oct 2004 04:56:22 +0000
Date: Fri, 22 Oct 2004 00:55:26 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Emile van Bergen <[email-masked]>, Barney Wolff <[email-masked]>, Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

On Thu, Oct 21, 2004 at 07:29:05PM -0700, Bernard Aboba wrote:
> > > I think this is not a real issue, at least for the NAS.  After all, the
> > > NAS (perhaps with proxy help) managed to get the Access-Request to a
> > > server that was willing to -Accept.  The bill must go to the organization
> > > responsible for that server.  Whether the server can then bill some
> > > individual/organization is the server's problem, not the NAS's.
> > >
> > > Surely as a matter of ordinary business practice, a server cannot say
> > > "provide service" but then refuse to accept billing for that service.
> 
> But in a roaming situation, it is the problem of the local realm that
> provided the service, not the "home server", no?  If it is purely the
> problem of the "home server" then the Class attribute can be used by
> the home server and there is no need for CUI, as you point out.

I still don't understand the local (ie, NAS) problem.  It's not going
to bill the end user directly, in any scenario that makes business sense.
If for no other reason, it has no billing address or credit card number,
just, even given CUI, [email-masked].  So for whom is CUI intended?

> However, the argument was made that if the "local realm" needs assurance,
> it can't get this from Class, since that this attribute is to be treated
> as opaque data by RADIUS clients.  So I think the argument for CUI is one
> that originates from the local realm, not the home server.

What does "assurance" mean?  Does it mean that somehow the Access-Accept
is more trustworthy because the home server said it was [email-masked]
rather than just [email-masked]?  Why does the NAS's owner care?

> Does this make sense??

Call me stubborn, but I still see the only scenario where CUI is required
would be where the access and accounting servers are run by different
organizations that fail to negotiate a format for Class, and where (despite
that) the accounting server is willing to trust what the access server
says about the user's identity.  I find it hard to believe this is a real
case, or to sympathize if it is.

Oh, wait.  We did hear the scenario.  The NAS or proxy is pricing based on
the maximum number of distinct users per time-period, rather than on total
minutes of use or number of calls or anything else easy to record.  For this
we are talking about attribute support negotiation, servers keeping state
on NAS capabilities and such?

-- 
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: Fri, 22 Oct 2004 02:30:11 +0000
Date: Thu, 21 Oct 2004 19:29:05 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Emile van Bergen <[email-masked]>
cc: Barney Wolff <[email-masked]>, Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

> > I think this is not a real issue, at least for the NAS.  After all, the
> > NAS (perhaps with proxy help) managed to get the Access-Request to a
> > server that was willing to -Accept.  The bill must go to the organization
> > responsible for that server.  Whether the server can then bill some
> > individual/organization is the server's problem, not the NAS's.
> >
> > Surely as a matter of ordinary business practice, a server cannot say
> > "provide service" but then refuse to accept billing for that service.

But in a roaming situation, it is the problem of the local realm that
provided the service, not the "home server", no?  If it is purely the
problem of the "home server" then the Class attribute can be used by
the home server and there is no need for CUI, as you point out.

However, the argument was made that if the "local realm" needs assurance,
it can't get this from Class, since that this attribute is to be treated
as opaque data by RADIUS clients.  So I think the argument for CUI is one
that originates from the local realm, not the home server.

Does this make sense??

> I wholeheartedly agree. And I also think that there's a better solution
> to help administrators of accounting servers to guarantee that they
> don't process and bill their users for unwanted records.

Yes, there is an existing solution to this problem -- the Class attribute,
as you point out.

> I feel this is a better solution to tying accounting to authentication
> than eg. requiring Acct-Session-Id in access requests as some operators
> stretch RFC2869 to, or CUI.  I know, it's not exactly the same thing,
> but as far as I understand CUI's purpose, CUI was aimed at solving a
> similar problem.

I guess I understood CUI's purpose differently.  But that's not a good
sign, since a clearly stated problem is a pre-requisite for a solution to
that problem.

--
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, 21 Oct 2004 07:46:00 +0000
Date: Thu, 21 Oct 2004 09:45:31 +0200
From: Emile van Bergen <[email-masked]>
To: Barney Wolff <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

Hello,

On Wed, Oct 20, 2004 at 11:44:05AM -0400, Barney Wolff wrote:

> On Wed, Oct 20, 2004 at 07:20:40AM -0700, Bernard Aboba wrote:
> > 
> > The other issue is whether the NAS supports CUI, and if so, what it will
> > do on receipt of an Access-Accept where CUI is not present.  My
> > understanding is that CUI will typically be required by the NAS, at least
> > for sessions where privacy is invoked.  Without CUI, there may be no way
> > for the NAS to know that has a valid billable identity prior to providing
> > service.  So it seems that the NAS would need to treat an Access-Accept
> > without CUI like an Access-Reject.  There is some precedent for this in
> > RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
> > unimplemented Service-Type this way.
> 
> I think this is not a real issue, at least for the NAS.  After all, the
> NAS (perhaps with proxy help) managed to get the Access-Request to a
> server that was willing to -Accept.  The bill must go to the organization
> responsible for that server.  Whether the server can then bill some
> individual/organization is the server's problem, not the NAS's.
> 
> Surely as a matter of ordinary business practice, a server cannot say
> "provide service" but then refuse to accept billing for that service.

I wholeheartedly agree. And I also think that there's a better solution
to help administrators of accounting servers to guarantee that they
don't process and bill their users for unwanted records.

Historically, the Class attribute seemed to be intended for the
accounting server to distinguish among differently charged service
types, according to information that was available authentication time.

That doesn't help accounting servers in making sure that the session
actually occurred and was not forged by the party operating the NAS or
intermediate proxy, who has an incentive to do so, if it gets paid per
minute or session.

However, if the party that authenticates and is responsible for handling
the bill for the user generates a cryptographically strong cookie and
puts that in Class, it can guarantee that subsequent accounting requests
are only processed if they can be tied to authentications it performed
itself.

I feel this is a better solution to tying accounting to authentication
than eg. requiring Acct-Session-Id in access requests as some operators
stretch RFC2869 to, or CUI.  I know, it's not exactly the same thing,
but as far as I understand CUI's purpose, CUI was aimed at solving a
similar problem.

With a server that allows you to put arbitrary logic and database
queries into the authentication and accounting sequences, such a scheme
can be implemented without any changes to NASes or proxies, or even the
code of the server itself. My server (OpenRADIUS) is an example, but
there are probably others that can do it just as well.

Kind regards,

Emile van Bergen.

-- 
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: Thu, 21 Oct 2004 06:30:57 +0000
content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity 
Date: Thu, 21 Oct 2004 09:29:53 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Alan,

>   FreeRADIUS ignores all attributes it doesn't understand.  That is,
> it's policy is:
>=20
>   - Try to authorize/authenticate the request by looking for, and =
using,
>     known attributes in the Access-Request
>   - If no known attributes are found, send Access-Reject
>   - If the authentication using known attributes succeeds, send =
Access-Accept.
>   - If not, send Access-Reject
>=20
>   Any "extra" attributes in the Access-Request not used as part of the
> above process are ignored.  It doesn't matter if they're
> Vendor-Specific or not, they're all treated identically.
>=20
> > The latter is more problematic, because the RADIUS server could send =
an
> > Access-Accept with no CUI attribute, and then wonder why the NAS =
never
> > sent an Accounting packet indicating that service started.  Or is =
the
> > intent for a non-supporting RADIUS server to send an Access-Reject?  =
If
> > so, then we need to verify that existing RADIUS servers that don't =
support
> > CUI actually behave this way.
>=20
>   FreeRADIUS doesn't, but it can be configured to do so.

This is good to know - we're not running FreeRADIUS, but I do know a lot =
of
places that are; this will have some impact upon what is deployed out =
there.

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: Wed, 20 Oct 2004 15:45:25 +0000
Date: Wed, 20 Oct 2004 11:44:05 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

On Wed, Oct 20, 2004 at 07:20:40AM -0700, Bernard Aboba wrote:
> 
> The other issue is whether the NAS supports CUI, and if so, what it will
> do on receipt of an Access-Accept where CUI is not present.  My
> understanding is that CUI will typically be required by the NAS, at least
> for sessions where privacy is invoked.  Without CUI, there may be no way
> for the NAS to know that has a valid billable identity prior to providing
> service.  So it seems that the NAS would need to treat an Access-Accept
> without CUI like an Access-Reject.  There is some precedent for this in
> RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
> unimplemented Service-Type this way.

I think this is not a real issue, at least for the NAS.  After all, the
NAS (perhaps with proxy help) managed to get the Access-Request to a
server that was willing to -Accept.  The bill must go to the organization
responsible for that server.  Whether the server can then bill some
individual/organization is the server's problem, not the NAS's.

Surely as a matter of ordinary business practice, a server cannot say
"provide service" but then refuse to accept billing for that service.

Maybe I still don't understand the model this attribute is designed for.
Are we really laboring to repair fatal defects in a model where the
Access and Accounting are handled by different organizations who cannot
come to agreement with each other on Class, and where bills somehow flow
by a different path than Access-Requests?  Why should we?

I have philosophical problems with the whole class of such issues.  We
already have a super-heavyweight AAA protocol in Diameter.  RADIUS has
always been the bantamweight.  Attempts to bulk it up will ultimately
fail, because its legs are still toothpicks.

-- 
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: Wed, 20 Oct 2004 14:52:07 +0000
From: "David Mariblanca (ML/EEM)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: alternatives for carrying eap lower layer information
Date: Wed, 20 Oct 2004 16:51:50 +0200

Hi Bernard,
you are proposing here to use Tunnel-Type and Tunnel-Medium-Type. The problem I see is that the values we wanted to allocate for EAP-lower-layer are:
          PPP                      1
          802.1X                   2
          IKEv2                    3
          PANA                     4

But in the attributes Tunnel-Type, Tunnel-Medium-Type and NAS-port-type you cannot find all these. And if you want some of them you have to use sometimes one attribute and sometimes other. For example, Tunnel-Type is for tunneled protocols and hence it does not include 802.1X.
On the other hand, Tunnel-Type and Tunnel-Medium-Type are for tunneling protocols. We want to use it for a IKEv2 exchange, which is not a tunneling protocol itself. Is this valid ?

BR,
David.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: viernes, 24 de septiembre de 2004 0:57
To: [email-masked]'; [email-masked]
Cc: David Mariblanca (ML/EEM)
Subject: Re: alternatives for carrying eap lower layer information

There are multiple problems being discussed here: 

a. Ability to differentiate tunneled EAP methods (PEAP, EAP-IKEv2, etc.) from non-tunneled EAP methods. 

b. Ability to differentiate EAP lower layers from one another (EAP-IKEv2).

In terms of problem a), the EAP peer and server know what EAP method is being negotiated (and whether it is tunneled), but the NAS is presumed to be a pass-through.  Therefore, I am not clear how the NAS would obtain information on the EAP method to put into an attribute, unless it gets this from the RADIUS server.  

In terms of problem b), it seems that the problem arises in part from the allocation of a single NAS-Port-Type (Virtual) to all tunnels.  In contrast, in RFC 2868 the combination of Tunnel-Type and Tunnel-Medium-Type attributes enables description of virtually any tunnel type over any medium.  I'd suggest that this approach is more sound than trying to allocate a NAS-Port-Type value for every conceivable combination. 

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

Envelope-to: [email-masked]
Delivery-date: Wed, 20 Oct 2004 14:48:55 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: -01 version of Chargeable User Identity 
Date: Wed, 20 Oct 2004 10:58:54 -0400
Message-Id: <[email-masked]>

Bernard Aboba <[email-masked]> wrote:
> [ rejecting requests with unrecognized attributes ]
>
> There are two questions:  whether this is behavior that is commonly
> implemented, and whether this is behavior that the IETF wishes to condone.
> I agree that it seems like a bad idea, but of course that doesn't mean
> that it isn't commonly implemented anyway.  I'd like to hear more from
> RADIUS server implementers on what their implementations do.

  FreeRADIUS ignores all attributes it doesn't understand.  That is,
it's policy is:

  - Try to authorize/authenticate the request by looking for, and using,
    known attributes in the Access-Request
  - If no known attributes are found, send Access-Reject
  - If the authentication using known attributes succeeds, send Access-Accept.
  - If not, send Access-Reject

  Any "extra" attributes in the Access-Request not used as part of the
above process are ignored.  It doesn't matter if they're
Vendor-Specific or not, they're all treated identically.

> The latter is more problematic, because the RADIUS server could send an
> Access-Accept with no CUI attribute, and then wonder why the NAS never
> sent an Accounting packet indicating that service started.  Or is the
> intent for a non-supporting RADIUS server to send an Access-Reject?  If
> so, then we need to verify that existing RADIUS servers that don't support
> CUI actually behave this way.

  FreeRADIUS doesn't, but it can be configured to do so.

  i.e. "If attribute X is not in the Access-Request, send Access-Reject".

  This ability is dependent only on the administrators ability to know
the attribute number, and potentially the vendor ID of the attribute.
It doesn't require knowledge of the attribute format or values.

  Alan DeKok.

--
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, 20 Oct 2004 14:20:49 +0000
Date: Wed, 20 Oct 2004 07:20:40 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Lothar Reith <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: AW: -01 version of Chargeable User Identity

> I was indeed suggesting that a CUI creating RADIUS Server should keep state
> of trusted CUI-capable NASes, and therefore inherit the risk of an "old" NAS
> not presenting the provided CUI in the accounting requests. After all, it is
> himself or  his user who probably asked for privacy protection which made
> the CUI necessary. The CUI creating RADIUS Server is basically a home RADIUS
> Server supporting roaming privacy - at least that is my point of view.

OK.  Are you saying that the null CUI attribute is only sent by the NAS
for a session in which authentication privacy is invoked?  For example,
this would imply that the Access-Request only contains a null CUI when the
EAP-Response/Identity is compatible with privacy (e.g. "@example.com").
But when a full identity is used (e.g. "[email-masked]") the null CUI
attribute is ommitted.

> To the more general question, of the overhead potentially introduced by a
> "mandatory" CUI attribute I would like to comment as follows:
> So far RADIUS does not support the concept of a mandatory attribute.

At IETF 60 David Nelson made a presentation on this.  In fact, RFC 2865
does seem to indicate that some attributes are mandatory, such as
Service-Type.

Dave -- can you summarize your conclusions?

> indeed proposed that the RADIUS server may enforce  "mandatoriness" by
> sending a "conditional" REJECT, indicating via a Reject reason (or
> alternatively via the mandatory attribute being present), that this Reject
> is indeed a Reject which has only been sent because the sender was unsure if
> the receiver would interpret a certain attribute as mandatory when present
> in an ACCEPT message - otherwise an ACCEPT would have been sent.

One issue is whether the RADIUS server supports CUI, and if not, what it
will do on receipt of an Access-Request with a null CUI attribute.  Since every
existing RADIUS server is in this category, this isn't behavior we can change
-- it is what it is.  All we can do is try to understand the current
behavior.

The other issue is whether the NAS supports CUI, and if so, what it will
do on receipt of an Access-Accept where CUI is not present.  My
understanding is that CUI will typically be required by the NAS, at least
for sessions where privacy is invoked.  Without CUI, there may be no way
for the NAS to know that has a valid billable identity prior to providing
service.  So it seems that the NAS would need to treat an Access-Accept
without CUI like an Access-Reject.  There is some precedent for this in
RFC 2865 -- I believe that the NAS needs to treat an Access-Accept with an
unimplemented Service-Type this way.

> I would be interested to hear if this could be a general method to solve the
> "mandatory/optional" backwards compabibility problem associated with the
> fact that it appears to be un-predictable if an unknown old NAS will reject
> or accept an Access Accept Message with a new attribute present, that he
> does not recognize.

Changing the semantics of the Access-Reject is somewhat tricky since the
goal of that message is to deny service.  As a result, RFC 2865
discourages inclusion of service-definition attributes within an
Access-Reject, and subsequent RFCs have only included attributes that
provide elaboration on the failure or its causes:  EAP-Message,
Reply-Message, etc.

> 3. NAS should autonomously convert the conditional REJECT into an ACCEPT and
> welcome the user as usual.

Interpetting an Access-Reject as an Access-Accept is explicitly forbidden
by RFC 2865.  We don't want to go down that road.

--
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, 20 Oct 2004 14:17:43 +0000
Content-class: urn:content-classes:message
Subject: Capability advertisement (was RE: -01 version of Chargeable User Identity)
Date: Wed, 20 Oct 2004 10:17:31 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

> The overhead is a potential issue if we are introducing
> a precedent that might be followed by many attributes
> in the future.  The current suggestion seems to be that
> _every_ Access-Request contain this advertisement (cf once
> per NAS which might be more reflective of capability).

RFC2865 says, in part:

"An Access-Request MAY contain additional attributes as a hint to
the server, but the server is not required to honor the hint."

RFC2865 already allows a relatively large number of attributes to appear
in Access-Request messages, many of them as hints.  I haven't included a
similar listing from other RADIUS RFCs, simply for the sake of brevity.

   0-1       0-1      0        0            1   User-Name
   0-1       0        0        0            2   User-Password [Note 1]
   0-1       0        0        0            3   CHAP-Password [Note 1]
   0-1       0        0        0            4   NAS-IP-Address [Note 2]
   0-1       0        0        0            5   NAS-Port
   0-1       0-1      0        0            6   Service-Type
   0-1       0-1      0        0            7   Framed-Protocol
   0-1       0-1      0        0            8   Framed-IP-Address
   0-1       0-1      0        0            9   Framed-IP-Netmask
   0-1       0-1      0        0           12   Framed-MTU
   0-1       0-1      0        0           19   Callback-Number
   0-1       0-1      0        0-1         24   State [Note 1]
   0-1       0        0        0           30   Called-Station-Id
   0-1       0        0        0           31   Calling-Station-Id
   0-1       0        0        0           32   NAS-Identifier [Note 2]
   0+        0+       0+       0+          33   Proxy-State
   0-1       0-1      0        0           34   Login-LAT-Service
   0-1       0-1      0        0           35   Login-LAT-Node
   0-1       0-1      0        0           36   Login-LAT-Group
   0-1       0        0        0           60   CHAP-Challenge
   0-1       0        0        0           61   NAS-Port-Type
   0-1       0-1      0        0           62   Port-Limit
   0-1       0-1      0        0           63   Login-LAT-Port

Most RAIUS servers have existing mechanisms to deal with hint attributes
in Access-Request messages.  Most of these implementations have some
notion of a match list, allowing the system administrator to specify
certain hint attribute match conditions that are required for a
successful authentication or cause the application of a certain
authentication and/or authorization policy to the request.

While it might become a burden if there were often a large number of
additional hints included in Access-Request messages, the potential for
this exists, to some extent, already.  The use of hints may be the
simplest way to extend RADIUS to encompass some notion of capability
advertisement (note that I avoid the term capability negotiation).

-- 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: Wed, 20 Oct 2004 10:03:00 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: AW: -01 version of Chargeable User Identity
Date: Wed, 20 Oct 2004 12:02:09 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4B68B.DCAA6380
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Bernard,

I was indeed suggesting that a CUI creating RADIUS Server should keep =
state
of trusted CUI-capable NASes, and therefore inherit the risk of an =
"old" NAS
not presenting the provided CUI in the accounting requests. After all, =
it is
himself or  his user who probably asked for privacy protection which =
made
the CUI necessary. The CUI creating RADIUS Server is basically a home =
RADIUS
Server supporting roaming privacy - at least that is my point of view.

To the more general question, of the overhead potentially introduced by =
a
"mandatory" CUI attribute I would like to comment as follows:
So far RADIUS does not support the concept of a mandatory attribute.  I
indeed proposed that the RADIUS server may enforce  "mandatoriness" by
sending a "conditional" REJECT, indicating via a Reject reason (or
alternatively via the mandatory attribute being present), that this =
Reject
is indeed a Reject which has only been sent because the sender was =
unsure if
the receiver would interpret a certain attribute as mandatory when =
present
in an ACCEPT message - otherwise an ACCEPT would have been sent.

When it comes to setting a precedence and more future attributes =
requiring
to be interpreted as "mandatory" another possible solution may be to
introduce a "Mandatory" attribute, and to include it into the Reject,
followed by all mandatory attributes (optionally preceded by =
non-mandatory
attributes). The NAS MAY convert such a "Conditional" REJECT into an =
ACCEPT
if he supports all attributes following the Mandatory attribute. This =
would
effectively convert a Reject with a Mandatory attribute into a =
CONDITIONAL
REJECT, indicating to the NAS that a subsequent ACCESS ACCEPT with =
these
Attributes with NUL-value present would result in an ACCESS ACCEPT.

Perhaps the NAS may even automatically convert the CONDITIONAL REJECT =
into
an CONDITIONAL ACCEPT, if he supports the condition, without informing =
the
RADIUS Authentication Server about it. The RADIUS Accounting Server =
will
learn this via the Accounting Request messages.

I would be interested to hear if this could be a general method to =
solve the
"mandatory/optional" backwards compabibility problem associated with =
the
fact that it appears to be un-predictable if an unknown old NAS will =
reject
or accept an Access Accept Message with a new attribute present, that =
he
does not recognize.

On a different note:
Based on the comment, that the REJECT MESSAGE should be displayed, =
there are
the following possibilities:
1. NAS should Diplay immidiately: "Please try again" (and should =
include the
CUI-NUL attribute in the next Access REQUEST that may follow suit)
2. NAS should delay displaying the Reject, and wait for the response to =
a
second ACCESS REQUEST (which he automatically produces, basically =
resending
the previous ACCESS REQUEST but this time with a CUI NUL Attribute =
present).
3. NAS should autonomously convert the conditional REJECT into an =
ACCEPT and
welcome the user as usual.

Lothar=20
(by the way announcing vacation till Nov 1)

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Mittwoch, 20. Oktober 2004 05:02
An: Greg Weber
Cc: [email-masked]
Betreff: Re: -01 version of Chargeable User Identity

On Tue, 19 Oct 2004, Greg Weber wrote:

> > Overhead is not the issue -- the null CUI attribute will only=20
> > require 2 octets.
>
> The overhead is a potential issue if we are introducing
> a precedent that might be followed by many attributes
> in the future.  The current suggestion seems to be that _every_=20
> Access-Request contain this advertisement (cf once per NAS which =
might=20
> be more reflective of capability).

I think your point about overhead is well taken.  It's one thing to do =
this
in a single case (CUI); it's another thing to set a precedent to be
replicated again and again, on every RADIUS Access-Request.

Diameter can avoid this via capabilities negotiation (CER/CEA), but =
since
RADIUS has no such feature, what do we do?

Are you suggesting that the RADIUS server keep state on NAS =
capabilities, by
presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
attributes to various negotiated capabilities?

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

------_=_NextPart_001_01C4B68B.DCAA6380
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: -01 version of Chargeable User Identity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Bernard,</FONT>
</P>

<P><FONT SIZE=3D2>I was indeed suggesting that a CUI creating RADIUS =
Server should keep state of trusted CUI-capable NASes, and therefore =
inherit the risk of an &quot;old&quot; NAS not presenting the provided =
CUI in the accounting requests. After all, it is himself or&nbsp; his =
user who probably asked for privacy protection which made the CUI =
necessary. The CUI creating RADIUS Server is basically a home RADIUS =
Server supporting roaming privacy - at least that is my point of =
view.</FONT></P>

<P><FONT SIZE=3D2>To the more general question, of the overhead =
potentially introduced by a &quot;mandatory&quot; CUI attribute I would =
like to comment as follows:</FONT></P>

<P><FONT SIZE=3D2>So far RADIUS does not support the concept of a =
mandatory attribute.&nbsp; I indeed proposed that the RADIUS server may =
enforce&nbsp; &quot;mandatoriness&quot; by sending a =
&quot;conditional&quot; REJECT, indicating via a Reject reason (or =
alternatively via the mandatory attribute being present), that this =
Reject is indeed a Reject which has only been sent because the sender =
was unsure if the receiver would interpret a certain attribute as =
mandatory when present in an ACCEPT message - otherwise an ACCEPT would =
have been sent.</FONT></P>

<P><FONT SIZE=3D2>When it comes to setting a precedence and more future =
attributes requiring to be interpreted as &quot;mandatory&quot; another =
possible solution may be to introduce a &quot;Mandatory&quot; =
attribute, and to include it into the Reject, followed by all mandatory =
attributes (optionally preceded by non-mandatory attributes). The NAS =
MAY convert such a &quot;Conditional&quot; REJECT into an ACCEPT if he =
supports all attributes following the Mandatory attribute. This would =
effectively convert a Reject with a Mandatory attribute into a =
CONDITIONAL REJECT, indicating to the NAS that a subsequent ACCESS =
ACCEPT with these Attributes with NUL-value present would result in an =
ACCESS ACCEPT.</FONT></P>

<P><FONT SIZE=3D2>Perhaps the NAS may even automatically convert the =
CONDITIONAL REJECT into an CONDITIONAL ACCEPT, if he supports the =
condition, without informing the RADIUS Authentication Server about it. =
The RADIUS Accounting Server will learn this via the Accounting Request =
messages.</FONT></P>

<P><FONT SIZE=3D2>I would be interested to hear if this could be a =
general method to solve the &quot;mandatory/optional&quot; backwards =
compabibility problem associated with the fact that it appears to be =
un-predictable if an unknown old NAS will reject or accept an Access =
Accept Message with a new attribute present, that he does not =
recognize.</FONT></P>

<P><FONT SIZE=3D2>On a different note:</FONT>
<BR><FONT SIZE=3D2>Based on the comment, that the REJECT MESSAGE should =
be displayed, there are the following possibilities:</FONT>
<BR><FONT SIZE=3D2>1. NAS should Diplay immidiately: &quot;Please try =
again&quot; (and should include the CUI-NUL attribute in the next =
Access REQUEST that may follow suit)</FONT></P>

<P><FONT SIZE=3D2>2. NAS should delay displaying the Reject, and wait =
for the response to a second ACCESS REQUEST (which he automatically =
produces, basically resending the previous ACCESS REQUEST but this time =
with a CUI NUL Attribute present).</FONT></P>

<P><FONT SIZE=3D2>3. NAS should autonomously convert the conditional =
REJECT into an ACCEPT and welcome the user as usual.</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Lothar </FONT>
<BR><FONT SIZE=3D2>(by the way announcing vacation till Nov 1)</FONT>
</P>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Mittwoch, 20. Oktober 2004 05:02</FONT>
<BR><FONT SIZE=3D2>An: Greg Weber</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: Re: -01 version of Chargeable User =
Identity</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>On Tue, 19 Oct 2004, Greg Weber wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; Overhead is not the issue -- the null CUI =
attribute will only </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; require 2 octets.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; The overhead is a potential issue if we are =
introducing</FONT>
<BR><FONT SIZE=3D2>&gt; a precedent that might be followed by many =
attributes</FONT>
<BR><FONT SIZE=3D2>&gt; in the future.&nbsp; The current suggestion =
seems to be that _every_ </FONT>
<BR><FONT SIZE=3D2>&gt; Access-Request contain this advertisement (cf =
once per NAS which might </FONT>
<BR><FONT SIZE=3D2>&gt; be more reflective of capability).</FONT>
</P>

<P><FONT SIZE=3D2>I think your point about overhead is well =
taken.&nbsp; It's one thing to do this in a single case (CUI); it's =
another thing to set a precedent to be replicated again and again, on =
every RADIUS Access-Request.</FONT></P>

<P><FONT SIZE=3D2>Diameter can avoid this via capabilities negotiation =
(CER/CEA), but since RADIUS has no such feature, what do we do?</FONT>
</P>

<P><FONT SIZE=3D2>Are you suggesting that the RADIUS server keep state =
on NAS capabilities, by presumably mapping =
NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address</FONT></P>

<P><FONT SIZE=3D2>attributes to various negotiated capabilities?</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4B68B.DCAA6380--

--
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, 20 Oct 2004 03:59:33 +0000
Date: Tue, 19 Oct 2004 20:59:23 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: Greg Weber <[email-masked]>, [email-masked]
Subject: RE: -01 version of Chargeable User Identity

> This conversation should apply to the capability exchange being proposed by
> another draft.

Or for that matter, perhaps to some existing attributes, no?

> To respond to your comment. What you suggest could work.  It would be best
> though to actually created a new packet for capability exchange. Which has
> other issues.  But failing that, would the NAS advertize its capabilities on
> the first Access-Request that it sends to a particular realm?  But packets
> are not neccesarily routed based on realm.  So there could be some RADIUS
> server that would never learn the capabilities.
>
> But is having a few added bytes in every access accept really that big an
> issue?  I would think not.

I'm not sure it's really an issue either... but it's worth discussing what
we should do in general, since this issue will come up multiple times.
Are we making an exception for CUI, or are we saying "this is the way you
handle backward negotiation" in general?

--
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, 20 Oct 2004 03:48:07 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, Greg Weber <[email-masked]>
Cc: [email-masked]
Subject: RE: -01 version of Chargeable User Identity
Date: Tue, 19 Oct 2004 23:47:49 -0400

Hi Bernard,

This converstation should apply to the capability exchange being proposed by
another draft.

To respond to your comment. What you suggest could work.  It would be best
though to actually created a new packet for capability exchange. Which has
other issues.  But failing that, would the NAS advertize its capabilities on
the first Access-Request that it sends to a particular realm?  But packets
are not neccesarily routed based on realm.  So there could be some RADIUS
server that would never learn the capabilities.  

But is having a few added bytes in every access accept really that big an
issue?  I would think not.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Wednesday, October 20, 2004 11:02 AM
> To: Greg Weber
> Cc: [email-masked]
> Subject: Re: -01 version of Chargeable User Identity
> 
> 
> On Tue, 19 Oct 2004, Greg Weber wrote:
> 
> > > Overhead is not the issue -- the null CUI attribute will only 
> > > require 2 octets.
> >
> > The overhead is a potential issue if we are introducing
> > a precedent that might be followed by many attributes
> > in the future.  The current suggestion seems to be that _every_ 
> > Access-Request contain this advertisement (cf once per NAS 
> which might 
> > be more reflective of capability).
> 
> I think your point about overhead is well taken.  It's one 
> thing to do this in a single case (CUI); it's another thing 
> to set a precedent to be replicated again and again, on every 
> RADIUS Access-Request.
> 
> Diameter can avoid this via capabilities negotiation 
> (CER/CEA), but since RADIUS has no such feature, what do we do?
> 
> Are you suggesting that the RADIUS server keep state on NAS 
> capabilities, by presumably mapping 
> NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
> attributes to various negotiated capabilities?
> 
> --
> 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, 20 Oct 2004 03:02:29 +0000
Date: Tue, 19 Oct 2004 20:02:02 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Greg Weber <[email-masked]>
cc: [email-masked]
Subject: Re: -01 version of Chargeable User Identity

On Tue, 19 Oct 2004, Greg Weber wrote:

> > Overhead is not the issue -- the null CUI attribute will only require 2
> > octets.
>
> The overhead is a potential issue if we are introducing
> a precedent that might be followed by many attributes
> in the future.  The current suggestion seems to be that
> _every_ Access-Request contain this advertisement (cf once
> per NAS which might be more reflective of capability).

I think your point about overhead is well taken.  It's one thing to do
this in a single case (CUI); it's another thing to set a precedent to be
replicated again and again, on every RADIUS Access-Request.

Diameter can avoid this via capabilities negotiation (CER/CEA), but since
RADIUS has no such feature, what do we do?

Are you suggesting that the RADIUS server keep state on NAS capabilities,
by presumably mapping NAS-Identifer/NAS-IP-Address/NAS-IPv6-Address
attributes to various negotiated capabilities?

--
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, 20 Oct 2004 01:24:52 +0000
From: Greg Weber <[email-masked]>
Subject: Re: -01 version of Chargeable User Identity
To: [email-masked] (Bernard Aboba)
Date: Tue, 19 Oct 2004 21:24:38 -0400 (EDT)
Cc: [email-masked] (Adrangi Farid), [email-masked] (Barney Wolff), [email-masked]

> > I agree.  So, I think the proposal was that NAS advertises its support
> > for the new attribute by sending a nul CUI.  And, the RADIUS will have
> > the option to reject the request in the absence of the CUI.  Do you see
> > any problem with respect to overhead resulting from the CUI
> > advertisement here?
> 
> Overhead is not the issue -- the null CUI attribute will only require 2
> octets.

The overhead is a potential issue if we are introducing
a precedent that might be followed by many attributes
in the future.  The current suggestion seems to be that
_every_ Access-Request contain this advertisement (cf once
per NAS which might be more reflective of capability).

Greg

--
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, 20 Oct 2004 00:47:29 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: "'Barney Wolff'" <[email-masked]>, <[email-masked]>
Subject: RE: -01 version of Chargeable User Identity
Date: Tue, 19 Oct 2004 17:46:49 -0700

[email-masked] <mailto:[email-masked]>
writes:

>> A bigger question is the expected behavior by NAS and RADIUS
server.
>>=20
>> What is the purpose of the "null CUI" attribute in the
>> Access-Request?  Is this to inform the RADIUS server that the NAS
>> supports CUI, in case the RADIUS server supports it and wants to
use
>> it?=20
>=20
> Yes, this is the reason, at least IMO.  If so, I propose the
following
> text:
>=20
> "
> The NAS SHOULD include the CUI attribute with a nul value in the
> Access-Request message to advertise its support for this attribute
to
> the RADIUS server.  In cases where the CUI is required for the
proper
> billing and the home RADIUS server cannot determine the NAS
support
> for the CUI attribute, the home RADIUS server MAY reject the
request
> by sending an Access-Reject message containing a Reply-Message(18)
> attribute indicating the failure text: "CUI is missing". "  =20

Given that the Reply-message attribute is meant to be displayed to
the user, don't you think that "CUI is missing" is a little cryptic?
Not to mention that, even if the user is one of us (and thus might
recognize it), what is (s)he to do about the problem?

>=20
> Your comment?
>=20
>> Or is it a
>> statement from
>> the NAS that "the RADIUS server MUST support CUI or I won't
provide
>> service."=20
>>=20
>> The latter is more problematic, because the RADIUS server could
send
>> an Access-Accept with no CUI attribute, and then wonder why the
NAS
>> never sent an Accounting packet indicating that service started.
Or
>> is the intent for a non-supporting RADIUS server to send an
>> Access-Reject?  If so, then we need to verify that existing
RADIUS
>> servers that don't support CUI actually behave this way.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
listening to John Coltrane?=20
  -- 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, 19 Oct 2004 23:43:34 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Tue, 19 Oct 2004 16:42:37 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: "Barney Wolff" <[email-masked]>, <[email-masked]>

> A bigger question is the expected behavior by NAS and RADIUS server.
>=20
> What is the purpose of the "null CUI" attribute in the=20
> Access-Request?  Is
> this to inform the RADIUS server that the NAS supports CUI,=20
> in case the
> RADIUS server supports it and wants to use it?=20

Yes, this is the reason, at least IMO.  If so, I propose the following
text:

"
The NAS SHOULD include the CUI attribute with a nul value in the
Access-Request message to advertise its support for this attribute to
the RADIUS server.  In cases where the CUI is required for the proper
billing and the home RADIUS server cannot determine the NAS support for
the CUI attribute, the home RADIUS server MAY reject the request by
sending an Access-Reject message containing a Reply-Message(18)
attribute indicating the failure text: "CUI is missing".
"

Your comment?

> Or is it a=20
> statement from
> the NAS that "the RADIUS server MUST support CUI or I won't provide
> service."
>=20
> The latter is more problematic, because the RADIUS server=20
> could send an
> Access-Accept with no CUI attribute, and then wonder why the NAS never
> sent an Accounting packet indicating that service started.  Or is the
> intent for a non-supporting RADIUS server to send an=20
> Access-Reject?  If
> so, then we need to verify that existing RADIUS servers that=20
> don't support
> CUI actually behave this way.
>=20

--
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, 19 Oct 2004 23:22:24 +0000
Date: Tue, 19 Oct 2004 16:08:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
cc: Barney Wolff <[email-masked]>, [email-masked]
Subject: RE: -01 version of Chargeable User Identity

> As I stated it in my response to Barney's e-mail, I don't understand why
> the RADIUS server should ever reject a request because it contains a new
> attribute, not supported by the server.  In general, this should not be
> the expected behavior as it impacts the interoperability every time a
> new attribute is introduced.

There are two questions:  whether this is behavior that is commonly
implemented, and whether this is behavior that the IETF wishes to condone.
I agree that it seems like a bad idea, but of course that doesn't mean
that it isn't commonly implemented anyway.  I'd like to hear more from
RADIUS server implementers on what their implementations do.

> > In this particular case, my understanding is that the local
> > operator is
> > unwilling to provide service if the new attribute isn't
> > included, because
> > it does not feeling confident about payment.  So it seems to
> > me that an
> > Access-Reject might be the desired response.
> >
>
> I agree.  So, I think the proposal was that NAS advertises its support
> for the new attribute by sending a nul CUI.  And, the RADIUS will have
> the option to reject the request in the absence of the CUI.  Do you see
> any problem with respect to overhead resulting from the CUI
> advertisement here?

Overhead is not the issue -- the null CUI attribute will only require 2
octets.

A bigger question is the expected behavior by NAS and RADIUS server.

What is the purpose of the "null CUI" attribute in the Access-Request?  Is
this to inform the RADIUS server that the NAS supports CUI, in case the
RADIUS server supports it and wants to use it?  Or is it a statement from
the NAS that "the RADIUS server MUST support CUI or I won't provide
service."

The latter is more problematic, because the RADIUS server could send an
Access-Accept with no CUI attribute, and then wonder why the NAS never
sent an Accounting packet indicating that service started.  Or is the
intent for a non-supporting RADIUS server to send an Access-Reject?  If
so, then we need to verify that existing RADIUS servers that don't support
CUI actually behave this way.

--
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, 19 Oct 2004 19:39:11 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Tue, 19 Oct 2004 12:38:34 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

>=20
> On Fri, 15 Oct 2004, Barney Wolff wrote:
>=20
> > On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
> >> Thanks for your comments.   RADIUS does not support a=20
> generic capability advertisement.
> >> However in this draft,  we can say that the NAS MUST send the CUI
> >> attribute with a nul value in the Access-Request, if it=20
> supports the
> >> attribute.  This indicates the home RADIUS server whether=20
> or not the
> >> NAS support CUI.  Will this address your concern?
> >
> > Since an old server that does not support CUI is quite=20
> likely to respond
> > with Reject to a request with an attribute that it does not=20
> understand,
> > this is not likely to solve all interoperability problems.
>=20
> Do we know that existing servers will behave this way?  Perhaps a poll
> would be appropriate.
>=20

As I stated it in my response to Barney's e-mail, I don't understand why
the RADIUS server should ever reject a request because it contains a new
attribute, not supported by the server.  In general, this should not be
the expected behavior as it impacts the interoperability every time a
new attribute is introduced. =20

>=20
> In this particular case, my understanding is that the local=20
> operator is
> unwilling to provide service if the new attribute isn't=20
> included, because
> it does not feeling confident about payment.  So it seems to=20
> me that an
> Access-Reject might be the desired response.
>=20

I agree.  So, I think the proposal was that NAS advertises its support
for the new attribute by sending a nul CUI.  And, the RADIUS will have
the option to reject the request in the absence of the CUI.  Do you see
any problem with respect to overhead resulting from the CUI
advertisement here? =20

--
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, 19 Oct 2004 08:11:27 +0000
Date: Tue, 19 Oct 2004 01:10:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: Re: -01 version of Chargeable User Identity

On Fri, 15 Oct 2004, Barney Wolff wrote:

> On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
>> Thanks for your comments.   RADIUS does not support a generic capability advertisement.
>> However in this draft,  we can say that the NAS MUST send the CUI
>> attribute with a nul value in the Access-Request, if it supports the
>> attribute.  This indicates the home RADIUS server whether or not the
>> NAS support CUI.  Will this address your concern?
>
> Since an old server that does not support CUI is quite likely to respond
> with Reject to a request with an attribute that it does not understand,
> this is not likely to solve all interoperability problems.

Do we know that existing servers will behave this way?  Perhaps a poll
would be appropriate.

> On the other hand,
> > 	From: Lothar Reith [mailto:[email-masked]]
> > 	I beleive it is not acceptable for the Home-Radius to find out only when
> >     receiving the RADIUS Accounting Start Request Message (i.e. after
> >     the fact of admitting the user) that he does not have a
> >     chargeable-identity for the currently already ongoing usage  - and
> >     therefore can not charge for that usage.
>
> A server that expects to see the accounting requests can always use Class
> to communicate whatever information it likes back to itself.  CUI seems
> intended to solve the cases where the servers for access and accounting
> are run by different organizations that cannot manage to negotiate an
> agreed format for Class.

Yes, I think that is the issue.  If the local ISP felt confident that a
billable identiy was included in the Class attribute, then it wouldn't
need this attribute.  On the other hand, if it's a trust issue, what is it
about this attribute that makes the local ISP more confident?  After all,
if the home server can't be trusted to put [email-masked] in the Class
attribute, why are they more trusted to put [email-masked] in the new
attribute?

> While that is perhaps a real case, it is NOT
> acceptable to impose retroactive requirements on existing devices that
> are now RADIUS compliant.  One would need a much stronger reason to
> disenfranchise the installed base; only a major break could justify it.

In this particular case, my understanding is that the local operator is
unwilling to provide service if the new attribute isn't included, because
it does not feeling confident about payment.  So it seems to me that an
Access-Reject might be the desired response.

If an Access-Reject isn't the desired response, I think we have a bigger
problem -- because if the local ISP is willing to live with a Class
attribute, why would this new attribute be needed at all?

--
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, 18 Oct 2004 06:09:39 +0000
Date: Mon, 18 Oct 2004 09:07:22 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-arkko-roamops-rfc2486bis-02.txt

[email-masked] wrote:

> I have looked through the radext mailings and saw some discussion but 
> could not find anything specifically regarding the reason for preferring 
> suffix over prefix in determining the routable realm. 

I think that discussion occurred prior to the creation of the radext
group or even list; it took a while to find a home for this work.
We did discuss this specific issue in the EAP WG, however, on the
list or at least in the meetings.

--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: Fri, 15 Oct 2004 22:25:58 +0000
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-arkko-roamops-rfc2486bis-02.txt
From: [email-masked]
Date: Fri, 15 Oct 2004 14:39:20 -0700

This is a multipart message in MIME format.
--=_alternative 0076F6EF88256F2E_=
Content-Type: text/plain; charset="US-ASCII"

Hello Jari,

>  Typically what is commonly referred to as the prefix domain, the 
> portion before the '!', is used for the intermediary domains where the 
> suffix domain, portion after the '@', is used as the home domain....
> 
> I think we have had this discussion in the past already,
> and came to the conclusion which is in the current draft...
> 

I have looked through the radext mailings and saw some discussion but 
could not find anything specifically regarding the reason for preferring 
suffix over prefix in determining the routable realm.  I understand it is 
too late to change anything when in last call so just for my edification, 
is it because it was agreed to preserve the designation of the suffix as 
"the realm" from the original RFC?   It is actually standard practice with 
all the large roaming aggregators with which we partner to use the prefix 
domain as priority over the suffix when both exist in the string.  Not 
blaming anyone or group but it is unfortunate that since there was nothing 
in the original RFC with regards to chaining domains that a practice 
developed that is non-compliant.  I understand not wanting to define the 
'/' since it would break the original RFC but unfortunately those roaming 
partners all use it for the prefix delimiter as well.   I guess it is 
fairly common these days to have a standard practice that does not comply 
with the standard and that's life...

Best regards,
Josh
--=_alternative 0076F6EF88256F2E_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=2><tt>Hello Jari,</tt></font>
<br>
<br><font size=2><tt>&gt; &nbsp;Typically what is commonly referred to
as the prefix domain, the <br>
&gt; portion before the '!', is used for the intermediary domains where
the <br>
&gt; suffix domain, portion after the '@', is used as the home domain....</tt></font>
<br><font size=2><tt>&gt; <br>
&gt; I think we have had this discussion in the past already,<br>
&gt; and came to the conclusion which is in the current draft...<br>
&gt; <br>
</tt></font>
<br><font size=2><tt>I have looked through the radext mailings and saw
some discussion but could not find anything specifically regarding the
reason for preferring suffix over prefix in determining the routable realm.
&nbsp;I understand it is too late to change anything when in last call
so just for my edification, is it because it was agreed to preserve the
designation of the suffix as &quot;the realm&quot; from the original RFC?
&nbsp; It is actually standard practice with all the large roaming aggregators
with which we partner to use the prefix domain as priority over the suffix
when both exist in the string. &nbsp;Not blaming anyone or group but it
is unfortunate that since there was nothing in the original RFC with regards
to chaining domains that a practice developed that is non-compliant. &nbsp;I
understand not wanting to define the '/' since it would break the original
RFC but unfortunately those roaming partners all use it for the prefix
delimiter as well. &nbsp; I guess it is fairly common these days to have
a standard practice that does not comply with the standard and that's life...</tt></font>
<br>
<br><font size=2><tt>Best regards,<br>
Josh</tt></font>
--=_alternative 0076F6EF88256F2E_=--

--
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, 15 Oct 2004 20:33:06 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Fri, 15 Oct 2004 13:32:26 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: "Lothar Reith" <[email-masked]>, "Greg Weber" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Barney,
The CUI is an optional attribute -- I don't understand why the old
server should reject the request, as you indicated below. =20
BR,
Farid

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]]=20
> Sent: Friday, October 15, 2004 9:58 AM
> To: Adrangi, Farid
> Cc: Lothar Reith; Greg Weber; [email-masked];=20
> [email-masked]; [email-masked]
> Subject: Re: -01 version of Chargeable User Identity
>=20
>=20
> On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
> > Thanks for your comments.   RADIUS does not support a=20
> generic capability advertisement.  However in this draft,  we=20
> can say that the NAS MUST send the CUI attribute with a nul=20
> value in the Access-Request, if it supports the attribute. =20
> This indicates the home RADIUS server whether or not the NAS=20
> support CUI.  Will this address your concern?
>=20
> Since an old server that does not support CUI is quite likely=20
> to respond
> with Reject to a request with an attribute that it does not=20
> understand,
> this is not likely to solve all interoperability problems.
>=20
> On the other hand,=20
> > 	From: Lothar Reith [mailto:[email-masked]]=20
> > 	I beleive it is not acceptable for the Home-Radius to=20
> find out only when receiving the RADIUS Accounting Start=20
> Request Message (i.e. after the fact of admitting the user)=20
> that he does not have a chargeable-identity for the currently=20
> already ongoing usage  - and therefore can not charge for that usage.
>=20
> A server that expects to see the accounting requests can=20
> always use Class
> to communicate whatever information it likes back to itself. =20
> CUI seems
> intended to solve the cases where the servers for access and=20
> accounting
> are run by different organizations that cannot manage to negotiate an
> agreed format for Class.  While that is perhaps a real case, it is NOT
> acceptable to impose retroactive requirements on existing devices that
> are now RADIUS compliant.  One would need a much stronger reason to
> disenfranchise the installed base; only a major break could=20
> justify it.
>=20
> --=20
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via=20
> the 'Net.
>=20

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

Delivery-date: Fri, 15 Oct 2004 20:27:04 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Fri, 15 Oct 2004 13:26:20 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "Greg Weber" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4B2F5.3B2F0A89
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Lothar,
Please see my comments inline.  Thanks for the dialogue.
BR,
Farid

	-----Original Message-----
	From: Lothar Reith [mailto:[email-masked]]=20
	Sent: Friday, October 15, 2004 10:04 AM
	To: Adrangi, Farid; Lothar Reith; 'Greg Weber'
	Cc: [email-masked]'; [email-masked]'; =
[email-masked]'
	Subject: AW: -01 version of Chargeable User Identity
=09
=09
	Hi Farid,
	=20
	yes, your proposal that CUI-capable NASes SHOULD (or MUST ?) "always =
include a CUI-support-indication-attribute (-value) in every =
ACCESS-REQUEST"  would adress my concerns, but at a relatively high =
cost.
	=20
	 This additional overhead may not be justifiable in all situations.
	=20
	=3D=3D> I guess by the additional cost, you are referring to the  =
bandwidth and resources required for transmitting the CUI attribute with =
a nul value (total length of 2-byte?)  in the Access-Request -- right? =20
	=20
	I would rather suggest that the Home-Radius - if he is not trusting the =
NAS having CUI-capability - SHOULD send an ACCESS REJECT with
	-  a reject reason "CUI-support-required, with CUI support I would have =
accepted, please respond with a CUI-support-indication message =
immidiately"=20
	=20
	A CUI-capable NAS SHOULD react to such an ACCESS REJECT Message by =
informing the HOME RADIUS about it's CUI capability, such that =
subsequent authentication requests may be accepted by the Home-RADIUS =
with trust that the CUI will be presented in the corresponding =
accounting requests.
	=20
	=3D=3D> Possible, but this requires more logic to be implemented on NAS =
and RADIUS.  This also incurs some cost and overhead!  If I am asked to =
choose between the two, I would go with the adverting the support by =
including the CUI in Access-Request.  But, I would like to hear other =
people's opinon on this.
	=20
	Infact, ideally a CUI-capable NAS SHOULD not immidiately reject the =
peer (supplicant), rather immidiately respond to the Home-RADIUS with a =
Dummy ACCESS-REQUEST including the CUI attribute to inform the =
HOME-RADIUS about CUI capability.
	The Home-RADIUS SHOULD have queued the ACCESS-ACCEPT message just in =
case the untrusted NAS will respond with a CUI-capability-indication =
within a specific timeframe (requires a CUI-indication-response timer at =
the Home-RADIUS).=20
	If that response arrives within the timer, the Home-RADIUS should send =
out all ACCESS-ACCEPTS queued for this "untrusted NAS" and add it to his =
list of trusted CUI-capable NASes.
	=20
	A CUI-capable-NAS should - when sending the dummy-access-request - =
start a second timer, waiting for the ACCESS-ACCEPT associate with the =
original ACCESS-REQUEST.
	=20
	This way, only the first authentication attempt from a previously =
CUI-capability-untrusted NAS will take a bit longer, and there is no =
need to burden all ACCESS-REQUESTS with the CUI attribute.
	=20
	This would solve the backwards compatibility issue, as CUI-incapable =
NASes will receive an ACCESS-REJECT Message when they should reject the =
authentication attempt - for them it is just a new REJECT CAUSE, which =
should be no problem hopefully.
	=20
	=20
	Lothar=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20
	=20

		-----Urspr=FCngliche Nachricht-----
		Von: Adrangi, Farid [mailto:[email-masked]]=20
		Gesendet: Freitag, 15. Oktober 2004 15:59
		An: Reith, Lothar [HAHN:NGD:EXCH]; Greg Weber
		Cc: [email-masked]; [email-masked]; =
[email-masked]
		Betreff: RE: -01 version of Chargeable User Identity
	=09
	=09
		Hi Lothar,
		Thanks for your comments.   RADIUS does not support a generic =
capability advertisement.  However in this draft,  we can say that the =
NAS MUST send the CUI attribute with a nul value in the Access-Request, =
if it supports the attribute.  This indicates the home RADIUS server =
whether or not the NAS support CUI.  Will this address your concern?
		BR,
		Farid

			-----Original Message-----
			From: Lothar Reith [mailto:[email-masked]]=20
			Sent: Friday, October 15, 2004 2:05 AM
			To: Adrangi, Farid; 'Greg Weber'
			Cc: [email-masked]'; [email-masked]'; =
[email-masked]'
			Subject: AW: -01 version of Chargeable User Identity
		=09
		=09

			Farid,=20

			I think we are talking about a backwards compatibility issue here. =20

			In this context, I do not think your below proposal of adding the =
words "and supported by NAS" is a good idea. It is equivalent to allow =
the NAS to just ignore a CUI attribute present in an ACCESS ACCEPT.  =20

			 The key question is if it is acceptable to the Home-RADIUS, that the =
NAS accepts the user but does not support (and therefore accept) the CUI =
attribute - and therefore does not provide the CUI in the corresponding =
ACCOUNTING  REQUEST messages (Start, Interim, and Stop).=20

			I do not think that this is acceptable to the Home Network.=20

			If it was acceptable, the Home-RADIUS would not need to send the CUI =
in the first place.=20

			I beleive it is not acceptable for the Home-Radius to find out only =
when receiving the RADIUS Accounting Start Request Message (i.e. after =
the fact of admitting the user) that he does not have a =
chargeable-identity for the currently already ongoing usage  - and =
therefore can not charge for that usage.

			In consequence, I think some kind of CUI capability discovery =
procedure needs to be performed, that allows the Home-RADIUS to discover =
if a NAS supports CUI. In this case, the Home-RADIUS would only send the =
CUI when the NAS supports CUI, otherwise reject the Authentication =
Request in those cases where the Home RADIUS considers that a CUI is =
necessary.

			Alternatively, potentially a large number of NASes may have to be =
upgraded to understand that an ACCESS ACCEPT message with a CUI =
attribute present MUST actually be interpreted as an ACCESS-REJECT =
Message if the NAS does not support copying the CUI attribute unmodified =
as received into all accounting requests.

			Blair - I also just read your "rambling" mail to this topic: if I =
understand you correctly, your main point is that you need the CUI. I =
further understand that the CUI - if present - will be the only identity =
which is guaranteed to have the quality "never modified", neither by the =
peer nor by any intermediary.

			I conclude therefore,  that it is not acceptable that the NAS ignores =
the CUI - after all it is a serious "modification" by the NAS to just =
"delete" the CUI - which is what would appear to the Home-Network as =
effect of the NAS "ignoring" the CUI but still accepting the user.

			my 2 (Euro-) Cents=20

			Lothar=20

			-----Urspr=FCngliche Nachricht-----=20
			Von: [email-masked] =
[mailto:[email-masked]]=20
			Gesendet: Mittwoch, 13. Oktober 2004 02:07=20
			An: Greg Weber=20
			Cc: [email-masked]; [email-masked]; =
[email-masked]=20
			Betreff: RE: -01 version of Chargeable User Identity=20

			Hi Greg,=20
			Thanks for reviewing the draft.  I see your point.  Does it help if =
we say something like:=20

			"=20
			The NAS MUST include this  attribute  in  the  Accounting  Requests =
(Start, Interim, and Stop) messages if it was included in the Access =
Accept message and supported by NAS. "

			BR,=20
			Farid=20

			> -----Original Message-----=20
			> From: Greg Weber [mailto:[email-masked]]=20
			> Sent: Tuesday, October 12, 2004 4:40 PM=20
			> To: Adrangi, Farid=20
			> Cc: [email-masked]; [email-masked];=20
			> [email-masked]=20
			> Subject: Re: -01 version of Chargeable User Identity=20
			>=20
			>=20
			>=20
			> Hi Farid,=20
			> A question on how -01 attempts to resolve a particular=20
			> part of issue #14.=20
			>=20
			>   From -00:=20
			>                        The NAS or the access network AAA server =
MUST=20
			>       include  this  attribute  in  the  Accounting  Requests  =
(Start,=20
			>       Interim, and Stop) messages if it was included in the Access=20
			>       Accept message.=20
			>  =20
			>   From #14:=20
			>       [BA] I don't understand how backward compatibility is =
achieved.=20
			>       How is a RADIUS server to know whether the NAS supports the =
CUI=20
			>       attribute?=20
			>=20
			>   -01 adds:=20
			>       In cases where the home RADIUS server cannot determine the =
NAS=20
			>       support for CUI attribute, it MUST send both the UserName (1) =

			>       attribute and CUI attribute, with the understanding that if =
the=20
			>       NAS supports the CUI attribute the CUI attribute will =
override=20
			>       the identity portion the UserName (1) attribute.  That is, =
the=20
			>       UserName(1) attribute will be used for routing and the CUI=20
			>       attribute will be used for identity purposes.=20
			>=20
			> But the additional text does not obviate the still existing excerpt =

			> from the -00 draft.  -01 still says that the NAS MUST send the new=20
			> attribute if it is received and that is a compatibility problem.=20
			>=20
			> Greg=20
			>=20
			> >=20
			> > Hi all,=20
			> > The version -01 should appear on ID repository soon.  In=20
			> the mean time,=20
			> > you can access the draft here :=20
			> >=20
			> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char=20
			geable-use=20
			> r-id-01.txt.=20
			>=20
			> The -01 update addresses the two issues (issue 13 and 14) submitted =

			> against the draft by David and Bernard respectively - please see=20
			> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed=20
			> descriptions of the issues.=20
			>=20
			>=20
			> Bernard,=20
			>=20
			> Regarding two of your comments,=20
			>=20
			> - Made a clarification on encoded format for CUI string.  But, we=20
			> weren't sure if you were also questioning the proposed =
XX:YYYYYYYYYY=20
			> format rather than just NAI or other encoding supported=20
			by=20
			> Username.  =20
			>=20
			> - Diameter translation /CoA message comment, are you suggesting to=20
			> prohibit the user of the attribute in COA/Disconnect message?  =
Please=20
			> note that the CUI is for identifying the user session than =
username.=20
			>=20
			> BR,=20
			> Farid=20
			>=20
			> --=20
			> to unsubscribe send a message to [email-masked] =
with=20
			> the word 'unsubscribe' in a single line as the message text body.=20
			> archive: <http://psg.com/lists/radiusext/>=20
			>=20

			--=20
			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/>=20

------_=_NextPart_001_01C4B2F5.3B2F0A89
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D531530120-15102004><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Lothar,</FONT></SPAN></DIV>
<DIV><SPAN class=3D531530120-15102004><FONT face=3DArial color=3D#0000ff =

size=3D2>Please&nbsp;see my comments&nbsp;inline.&nbsp; Thanks for the=20
dialogue.</FONT></SPAN></DIV>
<DIV><SPAN class=3D531530120-15102004><FONT face=3DArial color=3D#0000ff =

size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D531530120-15102004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Lothar Reith=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Friday, =
October 15,=20
  2004 10:04 AM<BR><B>To:</B> Adrangi, Farid; Lothar Reith; 'Greg=20
  Weber'<BR><B>Cc:</B> [email-masked]';=20
  [email-masked]';=20
  [email-masked]'<BR><B>Subject:</B> AW: -01 version of=20
  Chargeable User Identity<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  Farid,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>yes,=20
  your proposal that CUI-capable NASes SHOULD (or MUST ?) "always =
include a=20
  CUI-support-indication-attribute (-value) in every=20
  ACCESS-REQUEST"&nbsp;&nbsp;would adress my concerns, but at a =
relatively high=20
  cost.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;This additional overhead may not be justifiable in all=20
  situations.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><SPAN =
class=3D531530120-15102004><FONT=20
  face=3DArial color=3D#0000ff size=3D2>=3D=3D&gt; I guess by the =
additional cost, you are=20
  referring to the&nbsp;&nbsp;bandwidth and resources required=20
  for&nbsp;transmitting the CUI attribute with a nul value&nbsp;(total =
length=20
  of&nbsp;2-byte?) &nbsp;in the Access-Request -- right?&nbsp;=20
  </FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><SPAN =
class=3D531530120-15102004><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>I=20
  would rather suggest that the Home-Radius - if he is not trusting the =
NAS=20
  having CUI-capability - SHOULD send an ACCESS REJECT =
with</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>-&nbsp; a reject reason "CUI-support-required, with CUI =
support I would=20
  have accepted, please respond with a CUI-support-indication=20
  message&nbsp;immidiately"&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN><SPAN class=3D481322615-15102004><FONT =
face=3DArial=20
  color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>A=20
  CUI-capable NAS SHOULD&nbsp;react to such an ACCESS&nbsp;REJECT =
Message=20
  by&nbsp;informing the HOME RADIUS about it's CUI capability, such that =

  subsequent authentication requests may be accepted by the Home-RADIUS =
with=20
  trust that the CUI will be presented in the corresponding accounting=20
  requests.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><SPAN =
class=3D531530120-15102004><FONT=20
  face=3DArial color=3D#0000ff size=3D2>=3D=3D&gt; Possible, but this =
requires more logic=20
  to be implemented on NAS and RADIUS.&nbsp; This also incurs some cost =
and=20
  overhead!&nbsp; If I am asked to choose between the two, I would go =
with the=20
  adverting the support by including the CUI in Access-Request.&nbsp; =
But, I=20
  would like to hear other people's opinon on =
this.</FONT></SPAN></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><SPAN =
class=3D531530120-15102004><FONT=20
  face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Infact, ideally a CUI-capable NAS SHOULD not immidiately =
reject the=20
  peer (supplicant), rather immidiately respond to the Home-RADIUS with =
a Dummy=20
  ACCESS-REQUEST including the CUI attribute to inform the HOME-RADIUS =
about CUI=20
  capability.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
  Home-RADIUS SHOULD have queued the ACCESS-ACCEPT message just in case =
the=20
  untrusted NAS will respond with a CUI-capability-indication within a =
specific=20
  timeframe (requires a CUI-indication-response timer at the =
Home-RADIUS).=20
  </FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>If=20
  that response arrives within the timer, the Home-RADIUS should send =
out all=20
  ACCESS-ACCEPTS queued for this "untrusted NAS" and add it to his list =
of=20
  trusted CUI-capable NASes.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>A=20
  CUI-capable-NAS should - when sending the dummy-access-request - start =
a=20
  second timer, waiting for the ACCESS-ACCEPT associate with the =
original=20
  ACCESS-REQUEST.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  way, only the first authentication attempt from a previously=20
  CUI-capability-untrusted NAS will take a bit longer, and there is no =
need to=20
  burden all ACCESS-REQUESTS with the CUI attribute.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>This=20
  would solve the backwards compatibility issue, as CUI-incapable NASes =
will=20
  receive an ACCESS-REJECT Message when they should reject the =
authentication=20
  attempt - for them it is just a new REJECT CAUSE, which should be no =
problem=20
  hopefully.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Lothar </FONT></SPAN></DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D481322615-15102004><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
    size=3D2>-----Urspr=FCngliche Nachricht-----<BR><B>Von:</B> Adrangi, =
Farid=20
    [mailto:[email-masked]] <BR><B>Gesendet:</B> Freitag, 15. =
Oktober=20
    2004 15:59<BR><B>An:</B> Reith, Lothar [HAHN:NGD:EXCH]; Greg=20
    Weber<BR><B>Cc:</B> [email-masked]; =
[email-masked];=20
    [email-masked]<BR><B>Betreff:</B> RE: -01 version of=20
    Chargeable User Identity<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D316044013-15102004><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
    Lothar,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D316044013-15102004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Thanks for your comments.&nbsp;&nbsp;&nbsp;RADIUS does not =
support=20
    a&nbsp;generic capability advertisement.&nbsp; However in this=20
    draft,&nbsp;&nbsp;we can say that the NAS MUST send the CUI =
attribute with a=20
    nul value&nbsp;in the Access-Request, if it supports the =
attribute.&nbsp;=20
    This indicates the home RADIUS server whether or not the NAS support =

    CUI.&nbsp; Will this address your concern?</FONT></SPAN></DIV>
    <DIV><SPAN class=3D316044013-15102004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>BR,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D316044013-15102004><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Farid</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV></DIV>
      <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
      face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Lothar Reith=20
      [mailto:[email-masked]] <BR><B>Sent:</B> Friday, =
October=20
      15, 2004 2:05 AM<BR><B>To:</B> Adrangi, Farid; 'Greg =
Weber'<BR><B>Cc:</B>=20
      [email-masked]'; [email-masked]';=20
      [email-masked]'<BR><B>Subject:</B> AW: -01 version =
of=20
      Chargeable User Identity<BR><BR></FONT></DIV>
      <P><FONT size=3D2>Farid,</FONT> </P>
      <P><FONT size=3D2>I think we are talking about a backwards =
compatibility=20
      issue here.</FONT>&nbsp;<SPAN class=3D316044013-15102004><FONT =
face=3DArial=20
      color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
      <P><FONT size=3D2>In this context, I do not think your below =
proposal of=20
      adding the words "and supported by NAS" is a good idea. It is =
equivalent=20
      to allow the NAS to just ignore a CUI attribute present in an =
ACCESS=20
      ACCEPT.<SPAN class=3D316044013-15102004><FONT face=3DArial=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT><FONT size=3D2><SPAN=20
      class=3D316044013-15102004>&nbsp;</SPAN></FONT><FONT =
size=3D2><SPAN=20
      class=3D316044013-15102004><FONT face=3DArial=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT size=3D2><SPAN =
class=3D316044013-15102004>&nbsp;</SPAN>The key=20
      question is if it is acceptable to the Home-RADIUS, that the NAS =
accepts=20
      the user but does not support (and therefore accept) the CUI =
attribute -=20
      and therefore does not provide the CUI in the corresponding=20
      ACCOUNTING&nbsp; REQUEST messages (Start, Interim, and Stop).<SPAN =

      class=3D316044013-15102004><FONT face=3DArial=20
      color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
      <P><FONT size=3D2>I do not think that this is acceptable to the =
Home=20
      Network.</FONT> </P>
      <P><FONT size=3D2>If it was acceptable, the Home-RADIUS would not =
need to=20
      send the CUI in the first place.</FONT> </P>
      <P><FONT size=3D2>I beleive it is not acceptable for the =
Home-Radius to find=20
      out only when receiving the RADIUS Accounting Start Request =
Message (i.e.=20
      after the fact of admitting the user) that he does not have a=20
      chargeable-identity for the currently already ongoing usage&nbsp; =
- and=20
      therefore can not charge for that usage.</FONT></P>
      <P><FONT size=3D2>In consequence, I think some kind of CUI =
capability=20
      discovery procedure needs to be performed, that allows the =
Home-RADIUS to=20
      discover if a NAS supports CUI. In this case, the Home-RADIUS =
would only=20
      send the CUI when the NAS supports CUI, otherwise reject the=20
      Authentication Request in those cases where the Home RADIUS =
considers that=20
      a CUI is necessary.</FONT></P>
      <P><FONT size=3D2>Alternatively, potentially a large number of =
NASes may=20
      have to be upgraded to understand that an ACCESS ACCEPT message =
with a CUI=20
      attribute present MUST actually be interpreted as an ACCESS-REJECT =
Message=20
      if the NAS does not support copying the CUI attribute unmodified =
as=20
      received into all accounting requests.</FONT></P>
      <P><FONT size=3D2>Blair - I also just read your "rambling" mail to =
this=20
      topic: if I understand you correctly, your main point is that you =
need the=20
      CUI. I further understand that the CUI - if present - will be the =
only=20
      identity which is guaranteed to have the quality "never modified", =
neither=20
      by the peer nor by any intermediary.</FONT></P>
      <P><FONT size=3D2>I conclude therefore,&nbsp; that it is not =
acceptable that=20
      the NAS ignores the CUI - after all it is a serious "modification" =
by the=20
      NAS to just "delete" the CUI - which is what would appear to the=20
      Home-Network as effect of the NAS "ignoring" the CUI but still =
accepting=20
      the user.</FONT></P>
      <P><FONT size=3D2>my 2 (Euro-) Cents</FONT> </P>
      <P><FONT size=3D2>Lothar</FONT> </P><BR><BR>
      <P><FONT size=3D2>-----Urspr=FCngliche Nachricht-----</FONT> =
<BR><FONT=20
      size=3D2>Von: [email-masked] [<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]=
etf.org</A>]=20
      </FONT><BR><FONT size=3D2>Gesendet: Mittwoch, 13. Oktober 2004 =
02:07</FONT>=20
      <BR><FONT size=3D2>An: Greg Weber</FONT> <BR><FONT size=3D2>Cc:=20
      [email-masked]; [email-masked];=20
      [email-masked]</FONT> <BR><FONT size=3D2>Betreff: =
RE: -01=20
      version of Chargeable User Identity</FONT> </P><BR><BR>
      <P><FONT size=3D2>Hi Greg,</FONT> <BR><FONT size=3D2>Thanks for =
reviewing the=20
      draft.&nbsp; I see your point.&nbsp; Does it help if we say =
something=20
      like:</FONT> </P>
      <P><FONT size=3D2>"</FONT> <BR><FONT size=3D2>The NAS MUST include =
this&nbsp;=20
      attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests =
(Start,=20
      Interim, and Stop) messages if it was included in the Access =
Accept=20
      message and supported by NAS. "</FONT></P>
      <P><FONT size=3D2>BR,</FONT> <BR><FONT size=3D2>Farid</FONT> </P>
      <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =

      size=3D2>&gt; From: Greg Weber [<A=20
      =
href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Tuesday, October 12, 2004 4:40 =
PM</FONT>=20
      <BR><FONT size=3D2>&gt; To: Adrangi, Farid</FONT> <BR><FONT =
size=3D2>&gt; Cc:=20
      [email-masked]; [email-masked];</FONT> =
<BR><FONT=20
      size=3D2>&gt; [email-masked]</FONT> <BR><FONT =
size=3D2>&gt;=20
      Subject: Re: -01 version of Chargeable User Identity</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; Hi Farid,</FONT> <BR><FONT =
size=3D2>&gt; A=20
      question on how -01 attempts to resolve a particular</FONT> =
<BR><FONT=20
      size=3D2>&gt; part of issue #14.</FONT> <BR><FONT size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; From -00:</FONT> =
<BR><FONT=20
      =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
      The NAS or the access network AAA server MUST </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include&nbsp; =
this&nbsp;=20
      attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests&nbsp; =

      (Start,</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      Interim, and Stop) messages if it was included in the Access=20
      </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Accept=20
      message. </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; =
</FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp; From #14:</FONT> <BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [BA] I don't =
understand=20
      how backward compatibility is achieved. </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How is a RADIUS =
server to=20
      know whether the NAS supports the CUI </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
attribute?</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; =
-01=20
      adds:</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In=20
      cases where the home RADIUS server cannot determine the NAS=20
      </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
support=20
      for CUI attribute, it MUST send both the UserName (1) =
</FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute and =
CUI=20
      attribute, with the understanding that if the </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS supports the =
CUI=20
      attribute the CUI attribute will override </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the identity =
portion the=20
      UserName (1) attribute.&nbsp; That is, the </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UserName(1) =
attribute will=20
      be used for routing and the CUI </FONT><BR><FONT=20
      size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute will =
be used for=20
      identity purposes.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

      size=3D2>&gt; But the additional text does not obviate the still =
existing=20
      excerpt</FONT> <BR><FONT size=3D2>&gt; from the -00 draft.&nbsp; =
-01 still=20
      says that the NAS MUST send the new </FONT><BR><FONT size=3D2>&gt; =
attribute=20
      if it is received and that is a compatibility problem.</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Greg</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; =
&gt; Hi=20
      all,</FONT> <BR><FONT size=3D2>&gt; &gt; The version -01 should =
appear on ID=20
      repository soon.&nbsp; In</FONT> <BR><FONT size=3D2>&gt; the mean=20
      time,</FONT> <BR><FONT size=3D2>&gt; &gt; you can access the draft =
here=20
      :</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; <A=20
      =
href=3D"http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char"=20
      =
target=3D_blank>http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius=
-char</A></FONT>=20
      <BR><FONT size=3D2>geable-use</FONT> <BR><FONT size=3D2>&gt;=20
      r-id-01.txt.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; The=20
      -01 update addresses the two issues (issue 13 and 14) =
submitted</FONT>=20
      <BR><FONT size=3D2>&gt; against the draft by David and Bernard =
respectively=20
      - please see </FONT><BR><FONT size=3D2>&gt; <A=20
      href=3D"http://www.drizzle.com/~aboba/RADEXT/#Issue%2014"=20
      =
target=3D_blank>http://www.drizzle.com/~aboba/RADEXT/#Issue%2014</A> for =
the=20
      detailed </FONT><BR><FONT size=3D2>&gt; descriptions of the =
issues.</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; Bernard,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; Regarding two of your comments,</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; - Made a clarification on encoded =
format for=20
      CUI string.&nbsp; But, we</FONT> <BR><FONT size=3D2>&gt; weren't =
sure if you=20
      were also questioning the proposed XX:YYYYYYYYYY </FONT><BR><FONT=20
      size=3D2>&gt; format rather than just NAI or other encoding =
supported</FONT>=20
      <BR><FONT size=3D2>by</FONT> <BR><FONT size=3D2>&gt; =
Username.&nbsp;&nbsp;=20
      </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; - =
Diameter=20
      translation /CoA message comment, are you suggesting to</FONT> =
<BR><FONT=20
      size=3D2>&gt; prohibit the user of the attribute in COA/Disconnect =

      message?&nbsp; Please </FONT><BR><FONT size=3D2>&gt; note that the =
CUI is=20
      for identifying the user session than username.</FONT> <BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; BR,</FONT> <BR><FONT =
size=3D2>&gt;=20
      Farid</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; --</FONT>=20
      <BR><FONT size=3D2>&gt; to unsubscribe send a message to=20
      [email-masked] with</FONT> <BR><FONT size=3D2>&gt; =
the word=20
      'unsubscribe' in a single line as the message text body.</FONT> =
<BR><FONT=20
      size=3D2>&gt; archive: &lt;<A =
href=3D"http://psg.com/lists/radiusext/"=20
      target=3D_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT></P><BR>
      <P><FONT size=3D2>--</FONT> <BR><FONT size=3D2>to unsubscribe send =
a message=20
      to [email-masked] with the word 'unsubscribe' in a =
single=20
      line as the message text body.</FONT></P>
      <P><FONT size=3D2>archive: &lt;<A =
href=3D"http://psg.com/lists/radiusext/"=20
      target=3D_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT>=20
    </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4B2F5.3B2F0A89--

--
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, 15 Oct 2004 17:05:13 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, "Lothar Reith" <[email-masked]>, "'Greg Weber'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: -01 version of Chargeable User Identity
Date: Fri, 15 Oct 2004 19:04:22 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4B2D9.04464D20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Farid,
=20
yes, your proposal that CUI-capable NASes SHOULD (or MUST ?) "always =
include
a CUI-support-indication-attribute (-value) in every ACCESS-REQUEST"  =
would
adress my concerns, but at a relatively high cost.
=20
 This additional overhead may not be justifiable in all situations.
=20
I would rather suggest that the Home-Radius - if he is not trusting the =
NAS
having CUI-capability - SHOULD send an ACCESS REJECT with
-  a reject reason "CUI-support-required, with CUI support I would have
accepted, please respond with a CUI-support-indication message =
immidiately"=20
=20
A CUI-capable NAS SHOULD react to such an ACCESS REJECT Message by =
informing
the HOME RADIUS about it's CUI capability, such that subsequent
authentication requests may be accepted by the Home-RADIUS with trust =
that
the CUI will be presented in the corresponding accounting requests.
=20
Infact, ideally a CUI-capable NAS SHOULD not immidiately reject the =
peer
(supplicant), rather immidiately respond to the Home-RADIUS with a =
Dummy
ACCESS-REQUEST including the CUI attribute to inform the HOME-RADIUS =
about
CUI capability.
The Home-RADIUS SHOULD have queued the ACCESS-ACCEPT message just in =
case
the untrusted NAS will respond with a CUI-capability-indication within =
a
specific timeframe (requires a CUI-indication-response timer at the
Home-RADIUS).=20
If that response arrives within the timer, the Home-RADIUS should send =
out
all ACCESS-ACCEPTS queued for this "untrusted NAS" and add it to his =
list of
trusted CUI-capable NASes.
=20
A CUI-capable-NAS should - when sending the dummy-access-request - =
start a
second timer, waiting for the ACCESS-ACCEPT associate with the original
ACCESS-REQUEST.
=20
This way, only the first authentication attempt from a previously
CUI-capability-untrusted NAS will take a bit longer, and there is no =
need to
burden all ACCESS-REQUESTS with the CUI attribute.
=20
This would solve the backwards compatibility issue, as CUI-incapable =
NASes
will receive an ACCESS-REJECT Message when they should reject the
authentication attempt - for them it is just a new REJECT CAUSE, which
should be no problem hopefully.
=20
=20
Lothar=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20
=20

-----Urspr=FCngliche Nachricht-----
Von: Adrangi, Farid [mailto:[email-masked]]=20
Gesendet: Freitag, 15. Oktober 2004 15:59
An: Reith, Lothar [HAHN:NGD:EXCH]; Greg Weber
Cc: [email-masked]; [email-masked];
[email-masked]
Betreff: RE: -01 version of Chargeable User Identity

Hi Lothar,
Thanks for your comments.   RADIUS does not support a generic =
capability
advertisement.  However in this draft,  we can say that the NAS MUST =
send
the CUI attribute with a nul value in the Access-Request, if it =
supports the
attribute.  This indicates the home RADIUS server whether or not the =
NAS
support CUI.  Will this address your concern?
BR,
Farid

-----Original Message-----
From: Lothar Reith [mailto:[email-masked]]=20
Sent: Friday, October 15, 2004 2:05 AM
To: Adrangi, Farid; 'Greg Weber'
Cc: [email-masked]'; [email-masked]';
[email-masked]'
Subject: AW: -01 version of Chargeable User Identity

Farid,=20

I think we are talking about a backwards compatibility issue here. =20

In this context, I do not think your below proposal of adding the words =
"and
supported by NAS" is a good idea. It is equivalent to allow the NAS to =
just
ignore a CUI attribute present in an ACCESS ACCEPT.  =20

 The key question is if it is acceptable to the Home-RADIUS, that the =
NAS
accepts the user but does not support (and therefore accept) the CUI
attribute - and therefore does not provide the CUI in the corresponding
ACCOUNTING  REQUEST messages (Start, Interim, and Stop).=20

I do not think that this is acceptable to the Home Network.=20

If it was acceptable, the Home-RADIUS would not need to send the CUI in =
the
first place.=20

I beleive it is not acceptable for the Home-Radius to find out only =
when
receiving the RADIUS Accounting Start Request Message (i.e. after the =
fact
of admitting the user) that he does not have a chargeable-identity for =
the
currently already ongoing usage  - and therefore can not charge for =
that
usage.

In consequence, I think some kind of CUI capability discovery procedure
needs to be performed, that allows the Home-RADIUS to discover if a NAS
supports CUI. In this case, the Home-RADIUS would only send the CUI =
when the
NAS supports CUI, otherwise reject the Authentication Request in those =
cases
where the Home RADIUS considers that a CUI is necessary.

Alternatively, potentially a large number of NASes may have to be =
upgraded
to understand that an ACCESS ACCEPT message with a CUI attribute =
present
MUST actually be interpreted as an ACCESS-REJECT Message if the NAS =
does not
support copying the CUI attribute unmodified as received into all =
accounting
requests.

Blair - I also just read your "rambling" mail to this topic: if I =
understand
you correctly, your main point is that you need the CUI. I further
understand that the CUI - if present - will be the only identity which =
is
guaranteed to have the quality "never modified", neither by the peer =
nor by
any intermediary.

I conclude therefore,  that it is not acceptable that the NAS ignores =
the
CUI - after all it is a serious "modification" by the NAS to just =
"delete"
the CUI - which is what would appear to the Home-Network as effect of =
the
NAS "ignoring" the CUI but still accepting the user.

my 2 (Euro-) Cents=20

Lothar=20

-----Urspr=FCngliche Nachricht-----=20
Von: [email-masked] [mailto:[email-masked]
<mailto:[email-masked]> ]=20
Gesendet: Mittwoch, 13. Oktober 2004 02:07=20
An: Greg Weber=20
Cc: [email-masked]; [email-masked];
[email-masked]=20
Betreff: RE: -01 version of Chargeable User Identity=20

Hi Greg,=20
Thanks for reviewing the draft.  I see your point.  Does it help if we =
say
something like:=20

"=20
The NAS MUST include this  attribute  in  the  Accounting  Requests =
(Start,
Interim, and Stop) messages if it was included in the Access Accept =
message
and supported by NAS. "

BR,=20
Farid=20

> -----Original Message-----=20
> From: Greg Weber [mailto:[email-masked] <mailto:[email-masked]> =
]=20
> Sent: Tuesday, October 12, 2004 4:40 PM=20
> To: Adrangi, Farid=20
> Cc: [email-masked]; [email-masked];=20
> [email-masked]=20
> Subject: Re: -01 version of Chargeable User Identity=20
>=20
>=20
>=20
> Hi Farid,=20
> A question on how -01 attempts to resolve a particular=20
> part of issue #14.=20
>=20
>   From -00:=20
>                        The NAS or the access network AAA server MUST=20
>       include  this  attribute  in  the  Accounting  Requests  =
(Start,=20
>       Interim, and Stop) messages if it was included in the Access=20
>       Accept message.=20
>  =20
>   From #14:=20
>       [BA] I don't understand how backward compatibility is achieved. =

>       How is a RADIUS server to know whether the NAS supports the CUI =

>       attribute?=20
>=20
>   -01 adds:=20
>       In cases where the home RADIUS server cannot determine the NAS=20
>       support for CUI attribute, it MUST send both the UserName (1)=20
>       attribute and CUI attribute, with the understanding that if the =

>       NAS supports the CUI attribute the CUI attribute will override=20
>       the identity portion the UserName (1) attribute.  That is, the=20
>       UserName(1) attribute will be used for routing and the CUI=20
>       attribute will be used for identity purposes.=20
>=20
> But the additional text does not obviate the still existing excerpt=20
> from the -00 draft.  -01 still says that the NAS MUST send the new=20
> attribute if it is received and that is a compatibility problem.=20
>=20
> Greg=20
>=20
> >=20
> > Hi all,=20
> > The version -01 should appear on ID repository soon.  In=20
> the mean time,=20
> > you can access the draft here :=20
> >=20
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
<http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char> =20
geable-use=20
> r-id-01.txt.=20
>=20
> The -01 update addresses the two issues (issue 13 and 14) submitted=20
> against the draft by David and Bernard respectively - please see=20
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014
<http://www.drizzle.com/~aboba/RADEXT/#Issue%2014>  for the detailed=20
> descriptions of the issues.=20
>=20
>=20
> Bernard,=20
>=20
> Regarding two of your comments,=20
>=20
> - Made a clarification on encoded format for CUI string.  But, we=20
> weren't sure if you were also questioning the proposed XX:YYYYYYYYYY=20
> format rather than just NAI or other encoding supported=20
by=20
> Username.  =20
>=20
> - Diameter translation /CoA message comment, are you suggesting to=20
> prohibit the user of the attribute in COA/Disconnect message?  Please =

> note that the CUI is for identifying the user session than username.=20
>=20
> BR,=20
> Farid=20
>=20
> --=20
> to unsubscribe send a message to [email-masked] with=20
> the word 'unsubscribe' in a single line as the message text body.=20
> archive: <http://psg.com/lists/radiusext/
<http://psg.com/lists/radiusext/> >=20
>=20

--=20
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/ =
<http://psg.com/lists/radiusext/>
>=20

------_=_NextPart_001_01C4B2D9.04464D20
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>Nachricht</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>Hi 
Farid,</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>yes, 
your proposal that CUI-capable NASes SHOULD (or MUST ?) "always include a 
CUI-support-indication-attribute (-value) in every 
ACCESS-REQUEST"&nbsp;&nbsp;would adress my concerns, but at a relatively high 
cost.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2>&nbsp;This additional overhead may not be justifiable in all 
situations.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>I 
would rather suggest that the Home-Radius - if he is not trusting the NAS having 
CUI-capability - SHOULD send an ACCESS REJECT with</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2>-&nbsp; a reject reason "CUI-support-required, with CUI support I would 
have accepted, please respond with a CUI-support-indication 
message&nbsp;immidiately"&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN><SPAN class=481322615-15102004><FONT face=Arial 
color=#0000ff size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>A 
CUI-capable NAS SHOULD&nbsp;react to such an ACCESS&nbsp;REJECT Message 
by&nbsp;informing the HOME RADIUS about it's CUI capability, such that 
subsequent authentication requests may be accepted by the Home-RADIUS with trust 
that the CUI will be presented in the corresponding accounting 
requests.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2>Infact, ideally a CUI-capable NAS SHOULD not immidiately reject the peer 
(supplicant), rather immidiately respond to the Home-RADIUS with a Dummy 
ACCESS-REQUEST including the CUI attribute to inform the HOME-RADIUS about CUI 
capability.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>The 
Home-RADIUS SHOULD have queued the ACCESS-ACCEPT message just in case the 
untrusted NAS will respond with a CUI-capability-indication within a specific 
timeframe (requires a CUI-indication-response timer at the Home-RADIUS). 
</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>If 
that response arrives within the timer, the Home-RADIUS should send out all 
ACCESS-ACCEPTS queued for this "untrusted NAS" and add it to his list of trusted 
CUI-capable NASes.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>A 
CUI-capable-NAS should - when sending the dummy-access-request - start a second 
timer, waiting for the ACCESS-ACCEPT associate with the original 
ACCESS-REQUEST.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>This 
way, only the first authentication attempt from a previously 
CUI-capability-untrusted NAS will take a bit longer, and there is no need to 
burden all ACCESS-REQUESTS with the CUI attribute.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>This 
would solve the backwards compatibility issue, as CUI-incapable NASes will 
receive an ACCESS-REJECT Message when they should reject the authentication 
attempt - for them it is just a new REJECT CAUSE, which should be no problem 
hopefully.</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff size=2>Lothar 
</FONT></SPAN></DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=481322615-15102004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=de dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Ursprüngliche Nachricht-----<BR><B>Von:</B> Adrangi, Farid 
  [mailto:[email-masked]] <BR><B>Gesendet:</B> Freitag, 15. Oktober 
  2004 15:59<BR><B>An:</B> Reith, Lothar [HAHN:NGD:EXCH]; Greg 
  Weber<BR><B>Cc:</B> [email-masked]; [email-masked]; 
  [email-masked]<BR><B>Betreff:</B> RE: -01 version of Chargeable 
  User Identity<BR><BR></FONT></DIV>
  <DIV><SPAN class=316044013-15102004><FONT face=Arial color=#0000ff size=2>Hi 
  Lothar,</FONT></SPAN></DIV>
  <DIV><SPAN class=316044013-15102004><FONT face=Arial color=#0000ff 
  size=2>Thanks for your comments.&nbsp;&nbsp;&nbsp;RADIUS does not support 
  a&nbsp;generic capability advertisement.&nbsp; However in this 
  draft,&nbsp;&nbsp;we can say that the NAS MUST send the CUI attribute with a 
  nul value&nbsp;in the Access-Request, if it supports the attribute.&nbsp; This 
  indicates the home RADIUS server whether or not the NAS support CUI.&nbsp; 
  Will this address your concern?</FONT></SPAN></DIV>
  <DIV><SPAN class=316044013-15102004><FONT face=Arial color=#0000ff 
  size=2>BR,</FONT></SPAN></DIV>
  <DIV><SPAN class=316044013-15102004><FONT face=Arial color=#0000ff 
  size=2>Farid</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
    face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Lothar Reith 
    [mailto:[email-masked]] <BR><B>Sent:</B> Friday, October 
    15, 2004 2:05 AM<BR><B>To:</B> Adrangi, Farid; 'Greg Weber'<BR><B>Cc:</B> 
    [email-masked]'; [email-masked]'; 
    [email-masked]'<BR><B>Subject:</B> AW: -01 version of 
    Chargeable User Identity<BR><BR></FONT></DIV>
    <P><FONT size=2>Farid,</FONT> </P>
    <P><FONT size=2>I think we are talking about a backwards compatibility issue 
    here.</FONT>&nbsp;<SPAN class=316044013-15102004><FONT face=Arial 
    color=#0000ff size=2>&nbsp;</FONT></SPAN></P>
    <P><FONT size=2>In this context, I do not think your below proposal of 
    adding the words "and supported by NAS" is a good idea. It is equivalent to 
    allow the NAS to just ignore a CUI attribute present in an ACCESS 
    ACCEPT.<SPAN class=316044013-15102004><FONT face=Arial 
    color=#0000ff>&nbsp;</FONT></SPAN></FONT><FONT size=2><SPAN 
    class=316044013-15102004>&nbsp;</SPAN></FONT><FONT size=2><SPAN 
    class=316044013-15102004><FONT face=Arial 
    color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
    <P><FONT size=2><SPAN class=316044013-15102004>&nbsp;</SPAN>The key question 
    is if it is acceptable to the Home-RADIUS, that the NAS accepts the user but 
    does not support (and therefore accept) the CUI attribute - and therefore 
    does not provide the CUI in the corresponding ACCOUNTING&nbsp; REQUEST 
    messages (Start, Interim, and Stop).<SPAN class=316044013-15102004><FONT 
    face=Arial color=#0000ff>&nbsp;</FONT></SPAN></FONT></P>
    <P><FONT size=2>I do not think that this is acceptable to the Home 
    Network.</FONT> </P>
    <P><FONT size=2>If it was acceptable, the Home-RADIUS would not need to send 
    the CUI in the first place.</FONT> </P>
    <P><FONT size=2>I beleive it is not acceptable for the Home-Radius to find 
    out only when receiving the RADIUS Accounting Start Request Message (i.e. 
    after the fact of admitting the user) that he does not have a 
    chargeable-identity for the currently already ongoing usage&nbsp; - and 
    therefore can not charge for that usage.</FONT></P>
    <P><FONT size=2>In consequence, I think some kind of CUI capability 
    discovery procedure needs to be performed, that allows the Home-RADIUS to 
    discover if a NAS supports CUI. In this case, the Home-RADIUS would only 
    send the CUI when the NAS supports CUI, otherwise reject the Authentication 
    Request in those cases where the Home RADIUS considers that a CUI is 
    necessary.</FONT></P>
    <P><FONT size=2>Alternatively, potentially a large number of NASes may have 
    to be upgraded to understand that an ACCESS ACCEPT message with a CUI 
    attribute present MUST actually be interpreted as an ACCESS-REJECT Message 
    if the NAS does not support copying the CUI attribute unmodified as received 
    into all accounting requests.</FONT></P>
    <P><FONT size=2>Blair - I also just read your "rambling" mail to this topic: 
    if I understand you correctly, your main point is that you need the CUI. I 
    further understand that the CUI - if present - will be the only identity 
    which is guaranteed to have the quality "never modified", neither by the 
    peer nor by any intermediary.</FONT></P>
    <P><FONT size=2>I conclude therefore,&nbsp; that it is not acceptable that 
    the NAS ignores the CUI - after all it is a serious "modification" by the 
    NAS to just "delete" the CUI - which is what would appear to the 
    Home-Network as effect of the NAS "ignoring" the CUI but still accepting the 
    user.</FONT></P>
    <P><FONT size=2>my 2 (Euro-) Cents</FONT> </P>
    <P><FONT size=2>Lothar</FONT> </P><BR><BR>
    <P><FONT size=2>-----Ursprüngliche Nachricht-----</FONT> <BR><FONT 
    size=2>Von: [email-masked] [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>] 
    </FONT><BR><FONT size=2>Gesendet: Mittwoch, 13. Oktober 2004 02:07</FONT> 
    <BR><FONT size=2>An: Greg Weber</FONT> <BR><FONT size=2>Cc: 
    [email-masked]; [email-masked]; 
    [email-masked]</FONT> <BR><FONT size=2>Betreff: RE: -01 
    version of Chargeable User Identity</FONT> </P><BR><BR>
    <P><FONT size=2>Hi Greg,</FONT> <BR><FONT size=2>Thanks for reviewing the 
    draft.&nbsp; I see your point.&nbsp; Does it help if we say something 
    like:</FONT> </P>
    <P><FONT size=2>"</FONT> <BR><FONT size=2>The NAS MUST include this&nbsp; 
    attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests (Start, 
    Interim, and Stop) messages if it was included in the Access Accept message 
    and supported by NAS. "</FONT></P>
    <P><FONT size=2>BR,</FONT> <BR><FONT size=2>Farid</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Greg Weber [<A 
    href="mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Tuesday, October 12, 2004 4:40 PM</FONT> 
    <BR><FONT size=2>&gt; To: Adrangi, Farid</FONT> <BR><FONT size=2>&gt; Cc: 
    [email-masked]; [email-masked];</FONT> <BR><FONT 
    size=2>&gt; [email-masked]</FONT> <BR><FONT size=2>&gt; 
    Subject: Re: -01 version of Chargeable User Identity</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Hi Farid,</FONT> <BR><FONT size=2>&gt; A 
    question on how -01 attempts to resolve a particular</FONT> <BR><FONT 
    size=2>&gt; part of issue #14.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp; From -00:</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    The NAS or the access network AAA server MUST </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include&nbsp; this&nbsp; 
    attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests&nbsp; 
    (Start,</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    Interim, and Stop) messages if it was included in the Access 
    </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Accept 
    message. </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp; From #14:</FONT> <BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [BA] I don't understand how 
    backward compatibility is achieved. </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How is a RADIUS server to 
    know whether the NAS supports the CUI </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute?</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp;&nbsp; -01 adds:</FONT> 
    <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In cases where the 
    home RADIUS server cannot determine the NAS </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support for CUI attribute, 
    it MUST send both the UserName (1) </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute and CUI attribute, 
    with the understanding that if the </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS supports the CUI 
    attribute the CUI attribute will override </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the identity portion the 
    UserName (1) attribute.&nbsp; That is, the </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UserName(1) attribute will 
    be used for routing and the CUI </FONT><BR><FONT 
    size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute will be used for 
    identity purposes.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    But the additional text does not obviate the still existing excerpt</FONT> 
    <BR><FONT size=2>&gt; from the -00 draft.&nbsp; -01 still says that the NAS 
    MUST send the new </FONT><BR><FONT size=2>&gt; attribute if it is received 
    and that is a compatibility problem.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Greg</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Hi 
    all,</FONT> <BR><FONT size=2>&gt; &gt; The version -01 should appear on ID 
    repository soon.&nbsp; In</FONT> <BR><FONT size=2>&gt; the mean time,</FONT> 
    <BR><FONT size=2>&gt; &gt; you can access the draft here :</FONT> <BR><FONT 
    size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; <A 
    href="http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char" 
    target=_blank>http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char</A></FONT> 
    <BR><FONT size=2>geable-use</FONT> <BR><FONT size=2>&gt; r-id-01.txt.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The -01 update addresses 
    the two issues (issue 13 and 14) submitted</FONT> <BR><FONT size=2>&gt; 
    against the draft by David and Bernard respectively - please see 
    </FONT><BR><FONT size=2>&gt; <A 
    href="http://www.drizzle.com/~aboba/RADEXT/#Issue%2014" 
    target=_blank>http://www.drizzle.com/~aboba/RADEXT/#Issue%2014</A> for the 
    detailed </FONT><BR><FONT size=2>&gt; descriptions of the issues.</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Bernard,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Regarding two of your comments,</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; - Made a clarification on encoded format for 
    CUI string.&nbsp; But, we</FONT> <BR><FONT size=2>&gt; weren't sure if you 
    were also questioning the proposed XX:YYYYYYYYYY </FONT><BR><FONT 
    size=2>&gt; format rather than just NAI or other encoding supported</FONT> 
    <BR><FONT size=2>by</FONT> <BR><FONT size=2>&gt; Username.&nbsp;&nbsp; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; - Diameter 
    translation /CoA message comment, are you suggesting to</FONT> <BR><FONT 
    size=2>&gt; prohibit the user of the attribute in COA/Disconnect 
    message?&nbsp; Please </FONT><BR><FONT size=2>&gt; note that the CUI is for 
    identifying the user session than username.</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; BR,</FONT> <BR><FONT size=2>&gt; Farid</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; --</FONT> <BR><FONT 
    size=2>&gt; to unsubscribe send a message to [email-masked] 
    with</FONT> <BR><FONT size=2>&gt; the word 'unsubscribe' in a single line as 
    the message text body.</FONT> <BR><FONT size=2>&gt; archive: &lt;<A 
    href="http://psg.com/lists/radiusext/" 
    target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> <BR><FONT 
    size=2>&gt; </FONT></P><BR>
    <P><FONT size=2>--</FONT> <BR><FONT size=2>to unsubscribe send a message to 
    [email-masked] with the word 'unsubscribe' in a single line 
    as the message text body.</FONT></P>
    <P><FONT size=2>archive: &lt;<A href="http://psg.com/lists/radiusext/" 
    target=_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4B2D9.04464D20--

--
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, 15 Oct 2004 16:58:49 +0000
Date: Fri, 15 Oct 2004 12:58:08 -0400
From: Barney Wolff <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: Lothar Reith <[email-masked]>, Greg Weber <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: -01 version of Chargeable User Identity

On Fri, Oct 15, 2004 at 06:58:46AM -0700, Adrangi, Farid wrote:
> Thanks for your comments.   RADIUS does not support a generic capability advertisement.  However in this draft,  we can say that the NAS MUST send the CUI attribute with a nul value in the Access-Request, if it supports the attribute.  This indicates the home RADIUS server whether or not the NAS support CUI.  Will this address your concern?

Since an old server that does not support CUI is quite likely to respond
with Reject to a request with an attribute that it does not understand,
this is not likely to solve all interoperability problems.

On the other hand, 
> 	From: Lothar Reith [mailto:[email-masked]] 
> 	I beleive it is not acceptable for the Home-Radius to find out only when receiving the RADIUS Accounting Start Request Message (i.e. after the fact of admitting the user) that he does not have a chargeable-identity for the currently already ongoing usage  - and therefore can not charge for that usage.

A server that expects to see the accounting requests can always use Class
to communicate whatever information it likes back to itself.  CUI seems
intended to solve the cases where the servers for access and accounting
are run by different organizations that cannot manage to negotiate an
agreed format for Class.  While that is perhaps a real case, it is NOT
acceptable to impose retroactive requirements on existing devices that
are now RADIUS compliant.  One would need a much stronger reason to
disenfranchise the installed base; only a major break could justify it.

-- 
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: Fri, 15 Oct 2004 13:59:35 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Fri, 15 Oct 2004 06:58:46 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Lothar Reith" <[email-masked]>, "Greg Weber" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C4B2BF.16E3414B
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Lothar,
Thanks for your comments.   RADIUS does not support a generic capability =
advertisement.  However in this draft,  we can say that the NAS MUST =
send the CUI attribute with a nul value in the Access-Request, if it =
supports the attribute.  This indicates the home RADIUS server whether =
or not the NAS support CUI.  Will this address your concern?
BR,
Farid

	-----Original Message-----
	From: Lothar Reith [mailto:[email-masked]]=20
	Sent: Friday, October 15, 2004 2:05 AM
	To: Adrangi, Farid; 'Greg Weber'
	Cc: [email-masked]'; [email-masked]'; =
[email-masked]'
	Subject: AW: -01 version of Chargeable User Identity
=09
=09

	Farid,=20

	I think we are talking about a backwards compatibility issue here. =20

	In this context, I do not think your below proposal of adding the words =
"and supported by NAS" is a good idea. It is equivalent to allow the NAS =
to just ignore a CUI attribute present in an ACCESS ACCEPT.  =20

	 The key question is if it is acceptable to the Home-RADIUS, that the =
NAS accepts the user but does not support (and therefore accept) the CUI =
attribute - and therefore does not provide the CUI in the corresponding =
ACCOUNTING  REQUEST messages (Start, Interim, and Stop).=20

	I do not think that this is acceptable to the Home Network.=20

	If it was acceptable, the Home-RADIUS would not need to send the CUI in =
the first place.=20

	I beleive it is not acceptable for the Home-Radius to find out only =
when receiving the RADIUS Accounting Start Request Message (i.e. after =
the fact of admitting the user) that he does not have a =
chargeable-identity for the currently already ongoing usage  - and =
therefore can not charge for that usage.

	In consequence, I think some kind of CUI capability discovery procedure =
needs to be performed, that allows the Home-RADIUS to discover if a NAS =
supports CUI. In this case, the Home-RADIUS would only send the CUI when =
the NAS supports CUI, otherwise reject the Authentication Request in =
those cases where the Home RADIUS considers that a CUI is necessary.

	Alternatively, potentially a large number of NASes may have to be =
upgraded to understand that an ACCESS ACCEPT message with a CUI =
attribute present MUST actually be interpreted as an ACCESS-REJECT =
Message if the NAS does not support copying the CUI attribute unmodified =
as received into all accounting requests.

	Blair - I also just read your "rambling" mail to this topic: if I =
understand you correctly, your main point is that you need the CUI. I =
further understand that the CUI - if present - will be the only identity =
which is guaranteed to have the quality "never modified", neither by the =
peer nor by any intermediary.

	I conclude therefore,  that it is not acceptable that the NAS ignores =
the CUI - after all it is a serious "modification" by the NAS to just =
"delete" the CUI - which is what would appear to the Home-Network as =
effect of the NAS "ignoring" the CUI but still accepting the user.

	my 2 (Euro-) Cents=20

	Lothar=20

	-----Urspr=FCngliche Nachricht-----=20
	Von: [email-masked] [mailto:[email-masked]] =

	Gesendet: Mittwoch, 13. Oktober 2004 02:07=20
	An: Greg Weber=20
	Cc: [email-masked]; [email-masked]; =
[email-masked]=20
	Betreff: RE: -01 version of Chargeable User Identity=20

	Hi Greg,=20
	Thanks for reviewing the draft.  I see your point.  Does it help if we =
say something like:=20

	"=20
	The NAS MUST include this  attribute  in  the  Accounting  Requests =
(Start, Interim, and Stop) messages if it was included in the Access =
Accept message and supported by NAS. "

	BR,=20
	Farid=20

	> -----Original Message-----=20
	> From: Greg Weber [mailto:[email-masked]]=20
	> Sent: Tuesday, October 12, 2004 4:40 PM=20
	> To: Adrangi, Farid=20
	> Cc: [email-masked]; [email-masked];=20
	> [email-masked]=20
	> Subject: Re: -01 version of Chargeable User Identity=20
	>=20
	>=20
	>=20
	> Hi Farid,=20
	> A question on how -01 attempts to resolve a particular=20
	> part of issue #14.=20
	>=20
	>   From -00:=20
	>                        The NAS or the access network AAA server MUST=20
	>       include  this  attribute  in  the  Accounting  Requests  =
(Start,=20
	>       Interim, and Stop) messages if it was included in the Access=20
	>       Accept message.=20
	>  =20
	>   From #14:=20
	>       [BA] I don't understand how backward compatibility is achieved. =

	>       How is a RADIUS server to know whether the NAS supports the CUI =

	>       attribute?=20
	>=20
	>   -01 adds:=20
	>       In cases where the home RADIUS server cannot determine the NAS=20
	>       support for CUI attribute, it MUST send both the UserName (1)=20
	>       attribute and CUI attribute, with the understanding that if the =

	>       NAS supports the CUI attribute the CUI attribute will override=20
	>       the identity portion the UserName (1) attribute.  That is, the=20
	>       UserName(1) attribute will be used for routing and the CUI=20
	>       attribute will be used for identity purposes.=20
	>=20
	> But the additional text does not obviate the still existing excerpt=20
	> from the -00 draft.  -01 still says that the NAS MUST send the new=20
	> attribute if it is received and that is a compatibility problem.=20
	>=20
	> Greg=20
	>=20
	> >=20
	> > Hi all,=20
	> > The version -01 should appear on ID repository soon.  In=20
	> the mean time,=20
	> > you can access the draft here :=20
	> >=20
	> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char=20
	geable-use=20
	> r-id-01.txt.=20
	>=20
	> The -01 update addresses the two issues (issue 13 and 14) submitted=20
	> against the draft by David and Bernard respectively - please see=20
	> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed=20
	> descriptions of the issues.=20
	>=20
	>=20
	> Bernard,=20
	>=20
	> Regarding two of your comments,=20
	>=20
	> - Made a clarification on encoded format for CUI string.  But, we=20
	> weren't sure if you were also questioning the proposed XX:YYYYYYYYYY=20
	> format rather than just NAI or other encoding supported=20
	by=20
	> Username.  =20
	>=20
	> - Diameter translation /CoA message comment, are you suggesting to=20
	> prohibit the user of the attribute in COA/Disconnect message?  Please =

	> note that the CUI is for identifying the user session than username.=20
	>=20
	> BR,=20
	> Farid=20
	>=20
	> --=20
	> to unsubscribe send a message to [email-masked] with=20
	> the word 'unsubscribe' in a single line as the message text body.=20
	> archive: <http://psg.com/lists/radiusext/>=20
	>=20

	--=20
	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/>=20

------_=_NextPart_001_01C4B2BF.16E3414B
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1458" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D316044013-15102004><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Lothar,</FONT></SPAN></DIV>
<DIV><SPAN class=3D316044013-15102004><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks=20
for your comments.&nbsp;&nbsp;&nbsp;RADIUS does not support =
a&nbsp;generic=20
capability advertisement.&nbsp; However in this draft,&nbsp;&nbsp;we can =
say=20
that the NAS MUST send the CUI attribute with a nul value&nbsp;in the=20
Access-Request, if it supports the attribute.&nbsp; This indicates the =
home=20
RADIUS server whether or not the NAS support CUI.&nbsp; Will this =
address your=20
concern?</FONT></SPAN></DIV>
<DIV><SPAN class=3D316044013-15102004><FONT face=3DArial color=3D#0000ff =

size=3D2>BR,</FONT></SPAN></DIV>
<DIV><SPAN class=3D316044013-15102004><FONT face=3DArial color=3D#0000ff =

size=3D2>Farid</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Lothar Reith=20
  [mailto:[email-masked]] <BR><B>Sent:</B> Friday, =
October 15,=20
  2004 2:05 AM<BR><B>To:</B> Adrangi, Farid; 'Greg Weber'<BR><B>Cc:</B>=20
  [email-masked]'; [email-masked]';=20
  [email-masked]'<BR><B>Subject:</B> AW: -01 version of=20
  Chargeable User Identity<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Farid,</FONT> </P>
  <P><FONT size=3D2>I think we are talking about a backwards =
compatibility issue=20
  here.</FONT>&nbsp;<SPAN class=3D316044013-15102004><FONT face=3DArial=20
  color=3D#0000ff size=3D2>&nbsp;</FONT></SPAN></P>
  <P><FONT size=3D2>In this context, I do not think your below proposal =
of adding=20
  the words "and supported by NAS" is a good idea. It is equivalent to =
allow the=20
  NAS to just ignore a CUI attribute present in an ACCESS ACCEPT.<SPAN=20
  class=3D316044013-15102004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT><FONT size=3D2><SPAN=20
  class=3D316044013-15102004>&nbsp;</SPAN></FONT><FONT size=3D2><SPAN=20
  class=3D316044013-15102004><FONT face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2><SPAN class=3D316044013-15102004>&nbsp;</SPAN>The =
key question=20
  is if it is acceptable to the Home-RADIUS, that the NAS accepts the =
user but=20
  does not support (and therefore accept) the CUI attribute - and =
therefore does=20
  not provide the CUI in the corresponding ACCOUNTING&nbsp; REQUEST =
messages=20
  (Start, Interim, and Stop).<SPAN class=3D316044013-15102004><FONT =
face=3DArial=20
  color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></P>
  <P><FONT size=3D2>I do not think that this is acceptable to the Home=20
  Network.</FONT> </P>
  <P><FONT size=3D2>If it was acceptable, the Home-RADIUS would not need =
to send=20
  the CUI in the first place.</FONT> </P>
  <P><FONT size=3D2>I beleive it is not acceptable for the Home-Radius =
to find out=20
  only when receiving the RADIUS Accounting Start Request Message (i.e. =
after=20
  the fact of admitting the user) that he does not have a =
chargeable-identity=20
  for the currently already ongoing usage&nbsp; - and therefore can not =
charge=20
  for that usage.</FONT></P>
  <P><FONT size=3D2>In consequence, I think some kind of CUI capability =
discovery=20
  procedure needs to be performed, that allows the Home-RADIUS to =
discover if a=20
  NAS supports CUI. In this case, the Home-RADIUS would only send the =
CUI when=20
  the NAS supports CUI, otherwise reject the Authentication Request in =
those=20
  cases where the Home RADIUS considers that a CUI is =
necessary.</FONT></P>
  <P><FONT size=3D2>Alternatively, potentially a large number of NASes =
may have to=20
  be upgraded to understand that an ACCESS ACCEPT message with a CUI =
attribute=20
  present MUST actually be interpreted as an ACCESS-REJECT Message if =
the NAS=20
  does not support copying the CUI attribute unmodified as received into =
all=20
  accounting requests.</FONT></P>
  <P><FONT size=3D2>Blair - I also just read your "rambling" mail to =
this topic:=20
  if I understand you correctly, your main point is that you need the =
CUI. I=20
  further understand that the CUI - if present - will be the only =
identity which=20
  is guaranteed to have the quality "never modified", neither by the =
peer nor by=20
  any intermediary.</FONT></P>
  <P><FONT size=3D2>I conclude therefore,&nbsp; that it is not =
acceptable that the=20
  NAS ignores the CUI - after all it is a serious "modification" by the =
NAS to=20
  just "delete" the CUI - which is what would appear to the Home-Network =
as=20
  effect of the NAS "ignoring" the CUI but still accepting the =
user.</FONT></P>
  <P><FONT size=3D2>my 2 (Euro-) Cents</FONT> </P>
  <P><FONT size=3D2>Lothar</FONT> </P><BR><BR>
  <P><FONT size=3D2>-----Urspr=FCngliche Nachricht-----</FONT> <BR><FONT =
size=3D2>Von:=20
  [email-masked] [<A=20
  =
href=3D"mailto:[email-masked]">mailto:[email-masked]=
etf.org</A>]=20
  </FONT><BR><FONT size=3D2>Gesendet: Mittwoch, 13. Oktober 2004 =
02:07</FONT>=20
  <BR><FONT size=3D2>An: Greg Weber</FONT> <BR><FONT size=3D2>Cc:=20
  [email-masked]; [email-masked];=20
  [email-masked]</FONT> <BR><FONT size=3D2>Betreff: RE: =
-01 version=20
  of Chargeable User Identity</FONT> </P><BR><BR>
  <P><FONT size=3D2>Hi Greg,</FONT> <BR><FONT size=3D2>Thanks for =
reviewing the=20
  draft.&nbsp; I see your point.&nbsp; Does it help if we say something=20
  like:</FONT> </P>
  <P><FONT size=3D2>"</FONT> <BR><FONT size=3D2>The NAS MUST include =
this&nbsp;=20
  attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests (Start, =
Interim,=20
  and Stop) messages if it was included in the Access Accept message and =

  supported by NAS. "</FONT></P>
  <P><FONT size=3D2>BR,</FONT> <BR><FONT size=3D2>Farid</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Greg Weber [<A=20
  href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT> =
<BR><FONT=20
  size=3D2>&gt; Sent: Tuesday, October 12, 2004 4:40 PM</FONT> <BR><FONT =

  size=3D2>&gt; To: Adrangi, Farid</FONT> <BR><FONT size=3D2>&gt; Cc:=20
  [email-masked]; [email-masked];</FONT> =
<BR><FONT=20
  size=3D2>&gt; [email-masked]</FONT> <BR><FONT =
size=3D2>&gt;=20
  Subject: Re: -01 version of Chargeable User Identity</FONT> <BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Hi Farid,</FONT> <BR><FONT =
size=3D2>&gt; A question=20
  on how -01 attempts to resolve a particular</FONT> <BR><FONT =
size=3D2>&gt; part=20
  of issue #14.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp; From -00:</FONT> <BR><FONT=20
  =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
  The NAS or the access network AAA server MUST </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; include&nbsp; =
this&nbsp;=20
  attribute&nbsp; in&nbsp; the&nbsp; Accounting&nbsp; Requests&nbsp;=20
  (Start,</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Interim, and Stop) messages if it was included in the Access =
</FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Accept message.=20
  </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp; From #14:</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [BA] I don't =
understand how=20
  backward compatibility is achieved. </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How is a RADIUS =
server to know=20
  whether the NAS supports the CUI </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute?</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;&nbsp;&nbsp; -01 =
adds:</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In cases =
where the=20
  home RADIUS server cannot determine the NAS </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support for CUI =
attribute, it=20
  MUST send both the UserName (1) </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute and CUI =
attribute,=20
  with the understanding that if the </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS supports the CUI =
attribute=20
  the CUI attribute will override </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the identity portion =
the=20
  UserName (1) attribute.&nbsp; That is, the </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UserName(1) =
attribute will be=20
  used for routing and the CUI </FONT><BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute will be =
used for=20
  identity purposes.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  But the additional text does not obviate the still existing =
excerpt</FONT>=20
  <BR><FONT size=3D2>&gt; from the -00 draft.&nbsp; -01 still says that =
the NAS=20
  MUST send the new </FONT><BR><FONT size=3D2>&gt; attribute if it is =
received and=20
  that is a compatibility problem.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Greg</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi all,</FONT> <BR><FONT =
size=3D2>&gt;=20
  &gt; The version -01 should appear on ID repository soon.&nbsp; =
In</FONT>=20
  <BR><FONT size=3D2>&gt; the mean time,</FONT> <BR><FONT size=3D2>&gt; =
&gt; you can=20
  access the draft here :</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; <A=20
  =
href=3D"http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char"=20
  =
target=3D_blank>http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius=
-char</A></FONT>=20
  <BR><FONT size=3D2>geable-use</FONT> <BR><FONT size=3D2>&gt; =
r-id-01.txt.</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; The -01 update =
addresses=20
  the two issues (issue 13 and 14) submitted</FONT> <BR><FONT =
size=3D2>&gt;=20
  against the draft by David and Bernard respectively - please see=20
  </FONT><BR><FONT size=3D2>&gt; <A=20
  href=3D"http://www.drizzle.com/~aboba/RADEXT/#Issue%2014"=20
  target=3D_blank>http://www.drizzle.com/~aboba/RADEXT/#Issue%2014</A> =
for the=20
  detailed </FONT><BR><FONT size=3D2>&gt; descriptions of the =
issues.</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Bernard,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  Regarding two of your comments,</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; - Made a clarification on encoded format for CUI =
string.&nbsp;=20
  But, we</FONT> <BR><FONT size=3D2>&gt; weren't sure if you were also =
questioning=20
  the proposed XX:YYYYYYYYYY </FONT><BR><FONT size=3D2>&gt; format =
rather than=20
  just NAI or other encoding supported</FONT> <BR><FONT =
size=3D2>by</FONT>=20
  <BR><FONT size=3D2>&gt; Username.&nbsp;&nbsp; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; - Diameter translation /CoA message =
comment, are=20
  you suggesting to</FONT> <BR><FONT size=3D2>&gt; prohibit the user of =
the=20
  attribute in COA/Disconnect message?&nbsp; Please </FONT><BR><FONT =
size=3D2>&gt;=20
  note that the CUI is for identifying the user session than =
username.</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; BR,</FONT> =
<BR><FONT=20
  size=3D2>&gt; Farid</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  --</FONT> <BR><FONT size=3D2>&gt; to unsubscribe send a message to=20
  [email-masked] with</FONT> <BR><FONT size=3D2>&gt; the =
word=20
  'unsubscribe' in a single line as the message text body.</FONT> =
<BR><FONT=20
  size=3D2>&gt; archive: &lt;<A href=3D"http://psg.com/lists/radiusext/" =

  target=3D_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT></P><BR>
  <P><FONT size=3D2>--</FONT> <BR><FONT size=3D2>to unsubscribe send a =
message to=20
  [email-masked] with the word 'unsubscribe' in a single =
line as=20
  the message text body.</FONT></P>
  <P><FONT size=3D2>archive: &lt;<A =
href=3D"http://psg.com/lists/radiusext/"=20
  target=3D_blank>http://psg.com/lists/radiusext/</A>&gt;</FONT>=20
</P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C4B2BF.16E3414B--

--
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, 15 Oct 2004 10:45:34 +0000
Date: Fri, 15 Oct 2004 13:43:44 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-arkko-roamops-rfc2486bis-02.txt

[email-masked] wrote:
> 
> Hello Jari,
> 
> Very minor, a missing period on the bottom of section 2.7.
>         "would first be converted in other1.example net to"
> should be
>         "would first be converted in other1.example.net to"

Thanks, this is now corrected.

> Also, sorry to come in so late on the disccusion but just wanted to add 
> a comment on 2.7 Realm Construction as it pertains to roaming.  The 
> proposed method seems to be opposite of what I see in practice today. 
>  Typically what is commonly referred to as the prefix domain, the 
> portion before the '!', is used for the intermediary domains where the 
> suffix domain, portion after the '@', is used as the home domain.  Not 
> only does it make it much more readable since the username@realm is 
> preserved at the end of the string, but it also takes away the need to 
> reorder the parts when proxying and is simpler for an intermediary 
> domain to just strip off its own domain in the front and the first '!' 
> and pass on the rest of the string.  
> 
> So in your example where you have
> 
>         [email-masked]
> 
> in practice today it would be written as
> 
>         [email-masked]
> 
> and sent from other1.example.net as
>        
>         [email-masked]
> 
> and sent from other2.example.net as
> 
>         [email-masked]
> 
> Not sure it really makes much of a difference since both are recursive 
> just seems a little cleaner to me...

I think we have had this discussion in the past already,
and came to the conclusion which is in the current draft...

--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: Fri, 15 Oct 2004 09:05:32 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, "'Greg Weber'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: -01 version of Chargeable User Identity
Date: Fri, 15 Oct 2004 11:04:45 +0200

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C4B296.03835F1A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Farid,

I think we are talking about a backwards compatibility issue here.

In this context, I do not think your below proposal of adding the words =
"and
supported by NAS" is a good idea. It is equivalent to allow the NAS to =
just
ignore a CUI attribute present in an ACCESS ACCEPT.

The key question is if it is acceptable to the Home-RADIUS, that the =
NAS
accepts the user but does not support (and therefore accept) the CUI
attribute - and therefore does not provide the CUI in the corresponding
ACCOUNTING  REQUEST messages (Start, Interim, and Stop).

I do not think that this is acceptable to the Home Network.

If it was acceptable, the Home-RADIUS would not need to send the CUI in =
the
first place.

I beleive it is not acceptable for the Home-Radius to find out only =
when
receiving the RADIUS Accounting Start Request Message (i.e. after the =
fact
of admitting the user) that he does not have a chargeable-identity for =
the
currently already ongoing usage  - and therefore can not charge for =
that
usage.

In consequence, I think some kind of CUI capability discovery procedure
needs to be performed, that allows the Home-RADIUS to discover if a NAS
supports CUI. In this case, the Home-RADIUS would only send the CUI =
when the
NAS supports CUI, otherwise reject the Authentication Request in those =
cases
where the Home RADIUS considers that a CUI is necessary.

Alternatively, potentially a large number of NASes may have to be =
upgraded
to understand that an ACCESS ACCEPT message with a CUI attribute =
present
MUST actually be interpreted as an ACCESS-REJECT Message if the NAS =
does not
support copying the CUI attribute unmodified as received into all =
accounting
requests.

Blair - I also just read your "rambling" mail to this topic: if I =
understand
you correctly, your main point is that you need the CUI. I further
understand that the CUI - if present - will be the only identity which =
is
guaranteed to have the quality "never modified", neither by the peer =
nor by
any intermediary.

I conclude therefore,  that it is not acceptable that the NAS ignores =
the
CUI - after all it is a serious "modification" by the NAS to just =
"delete"
the CUI - which is what would appear to the Home-Network as effect of =
the
NAS "ignoring" the CUI but still accepting the user.

my 2 (Euro-) Cents

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =

Gesendet: Mittwoch, 13. Oktober 2004 02:07
An: Greg Weber
Cc: [email-masked]; [email-masked];
[email-masked]
Betreff: RE: -01 version of Chargeable User Identity

Hi Greg,
Thanks for reviewing the draft.  I see your point.  Does it help if we =
say
something like:

"
The NAS MUST include this  attribute  in  the  Accounting  Requests =
(Start,
Interim, and Stop) messages if it was included in the Access Accept =
message
and supported by NAS. "

BR,
Farid

> -----Original Message-----
> From: Greg Weber [mailto:[email-masked]]
> Sent: Tuesday, October 12, 2004 4:40 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: -01 version of Chargeable User Identity
>=20
>=20
>=20
> Hi Farid,
> A question on how -01 attempts to resolve a particular
> part of issue #14.
>=20
>   From -00:
>                        The NAS or the access network AAA server MUST=20
>       include  this  attribute  in  the  Accounting  Requests  =
(Start,
>       Interim, and Stop) messages if it was included in the Access=20
>       Accept message.=20
>  =20
>   From #14:
>       [BA] I don't understand how backward compatibility is achieved. =

>       How is a RADIUS server to know whether the NAS supports the CUI =

>       attribute?
>=20
>   -01 adds:
>       In cases where the home RADIUS server cannot determine the NAS=20
>       support for CUI attribute, it MUST send both the UserName (1)=20
>       attribute and CUI attribute, with the understanding that if the =

>       NAS supports the CUI attribute the CUI attribute will override=20
>       the identity portion the UserName (1) attribute.  That is, the=20
>       UserName(1) attribute will be used for routing and the CUI=20
>       attribute will be used for identity purposes.
>=20
> But the additional text does not obviate the still existing excerpt
> from the -00 draft.  -01 still says that the NAS MUST send the new=20
> attribute if it is received and that is a compatibility problem.
>=20
> Greg
>=20
> >=20
> > Hi all,
> > The version -01 should appear on ID repository soon.  In
> the mean time,
> > you can access the draft here :
> >=20
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
geable-use
> r-id-01.txt.
>=20
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see=20
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed=20
> descriptions of the issues.
>=20
>=20
> Bernard,
>=20
> Regarding two of your comments,
>=20
> - Made a clarification on encoded format for CUI string.  But, we
> weren't sure if you were also questioning the proposed XX:YYYYYYYYYY=20
> format rather than just NAI or other encoding supported
by
> Username.  =20
>=20
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message?  Please =

> note that the CUI is for identifying the user session than username.
>=20
> BR,
> Farid
>=20
> --
> 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/>
>=20

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

------_=_NextPart_001_01C4B296.03835F1A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>AW: -01 version of Chargeable User Identity</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Farid,</FONT>
</P>

<P><FONT SIZE=3D2>I think we are talking about a backwards =
compatibility issue here.</FONT>
</P>

<P><FONT SIZE=3D2>In this context, I do not think your below proposal =
of adding the words &quot;and supported by NAS&quot; is a good idea. It =
is equivalent to allow the NAS to just ignore a CUI attribute present =
in an ACCESS ACCEPT.</FONT></P>

<P><FONT SIZE=3D2>The key question is if it is acceptable to the =
Home-RADIUS, that the NAS accepts the user but does not support (and =
therefore accept) the CUI attribute - and therefore does not provide =
the CUI in the corresponding ACCOUNTING&nbsp; REQUEST messages (Start, =
Interim, and Stop).</FONT></P>

<P><FONT SIZE=3D2>I do not think that this is acceptable to the Home =
Network.</FONT>
</P>

<P><FONT SIZE=3D2>If it was acceptable, the Home-RADIUS would not need =
to send the CUI in the first place.</FONT>
</P>

<P><FONT SIZE=3D2>I beleive it is not acceptable for the Home-Radius to =
find out only when receiving the RADIUS Accounting Start Request =
Message (i.e. after the fact of admitting the user) that he does not =
have a chargeable-identity for the currently already ongoing =
usage&nbsp; - and therefore can not charge for that usage.</FONT></P>

<P><FONT SIZE=3D2>In consequence, I think some kind of CUI capability =
discovery procedure needs to be performed, that allows the Home-RADIUS =
to discover if a NAS supports CUI. In this case, the Home-RADIUS would =
only send the CUI when the NAS supports CUI, otherwise reject the =
Authentication Request in those cases where the Home RADIUS considers =
that a CUI is necessary.</FONT></P>

<P><FONT SIZE=3D2>Alternatively, potentially a large number of NASes =
may have to be upgraded to understand that an ACCESS ACCEPT message =
with a CUI attribute present MUST actually be interpreted as an =
ACCESS-REJECT Message if the NAS does not support copying the CUI =
attribute unmodified as received into all accounting =
requests.</FONT></P>

<P><FONT SIZE=3D2>Blair - I also just read your &quot;rambling&quot; =
mail to this topic: if I understand you correctly, your main point is =
that you need the CUI. I further understand that the CUI - if present - =
will be the only identity which is guaranteed to have the quality =
&quot;never modified&quot;, neither by the peer nor by any =
intermediary.</FONT></P>

<P><FONT SIZE=3D2>I conclude therefore,&nbsp; that it is not acceptable =
that the NAS ignores the CUI - after all it is a serious =
&quot;modification&quot; by the NAS to just &quot;delete&quot; the CUI =
- which is what would appear to the Home-Network as effect of the NAS =
&quot;ignoring&quot; the CUI but still accepting the user.</FONT></P>

<P><FONT SIZE=3D2>my 2 (Euro-) Cents</FONT>
</P>

<P><FONT SIZE=3D2>Lothar</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>-----Urspr=FCngliche Nachricht-----</FONT>
<BR><FONT SIZE=3D2>Von: [email-masked] [<A =
HREF=3D"mailto:[email-masked]">mailto:owner-radiusext@ops.=
ietf.org</A>] </FONT>
<BR><FONT SIZE=3D2>Gesendet: Mittwoch, 13. Oktober 2004 02:07</FONT>
<BR><FONT SIZE=3D2>An: Greg Weber</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]; =
[email-masked]; [email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: RE: -01 version of Chargeable User =
Identity</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Greg,</FONT>
<BR><FONT SIZE=3D2>Thanks for reviewing the draft.&nbsp; I see your =
point.&nbsp; Does it help if we say something like:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;</FONT>
<BR><FONT SIZE=3D2>The NAS MUST include this&nbsp; attribute&nbsp; =
in&nbsp; the&nbsp; Accounting&nbsp; Requests (Start, Interim, and Stop) =
messages if it was included in the Access Accept message and supported =
by NAS. &quot;</FONT></P>

<P><FONT SIZE=3D2>BR,</FONT>
<BR><FONT SIZE=3D2>Farid</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Greg Weber [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, October 12, 2004 4:40 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Adrangi, Farid</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [email-masked]; =
[email-masked];</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: -01 version of Chargeable User =
Identity</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Farid,</FONT>
<BR><FONT SIZE=3D2>&gt; A question on how -01 attempts to resolve a =
particular</FONT>
<BR><FONT SIZE=3D2>&gt; part of issue #14.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; From -00:</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp; The NAS or the access network AAA server MUST </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
include&nbsp; this&nbsp; attribute&nbsp; in&nbsp; the&nbsp; =
Accounting&nbsp; Requests&nbsp; (Start,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interim, =
and Stop) messages if it was included in the Access </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Accept =
message. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; From #14:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [BA] I =
don't understand how backward compatibility is achieved. </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; How is a =
RADIUS server to know whether the NAS supports the CUI </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
attribute?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; -01 adds:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In cases =
where the home RADIUS server cannot determine the NAS </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; support for =
CUI attribute, it MUST send both the UserName (1) </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute =
and CUI attribute, with the understanding that if the </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAS =
supports the CUI attribute the CUI attribute will override </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the =
identity portion the UserName (1) attribute.&nbsp; That is, the </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UserName(1) =
attribute will be used for routing and the CUI </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; attribute =
will be used for identity purposes.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But the additional text does not obviate the =
still existing excerpt</FONT>
<BR><FONT SIZE=3D2>&gt; from the -00 draft.&nbsp; -01 still says that =
the NAS MUST send the new </FONT>
<BR><FONT SIZE=3D2>&gt; attribute if it is received and that is a =
compatibility problem.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Greg</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi all,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The version -01 should appear on ID =
repository soon.&nbsp; In</FONT>
<BR><FONT SIZE=3D2>&gt; the mean time,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; you can access the draft here :</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char" =
TARGET=3D"_blank">http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-rad=
ius-char</A></FONT>
<BR><FONT SIZE=3D2>geable-use</FONT>
<BR><FONT SIZE=3D2>&gt; r-id-01.txt.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The -01 update addresses the two issues (issue =
13 and 14) submitted</FONT>
<BR><FONT SIZE=3D2>&gt; against the draft by David and Bernard =
respectively - please see </FONT>
<BR><FONT SIZE=3D2>&gt; <A =
HREF=3D"http://www.drizzle.com/~aboba/RADEXT/#Issue%2014" =
TARGET=3D"_blank">http://www.drizzle.com/~aboba/RADEXT/#Issue%2014</A> =
for the detailed </FONT>
<BR><FONT SIZE=3D2>&gt; descriptions of the issues.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Bernard,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Regarding two of your comments,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Made a clarification on encoded format for =
CUI string.&nbsp; But, we</FONT>
<BR><FONT SIZE=3D2>&gt; weren't sure if you were also questioning the =
proposed XX:YYYYYYYYYY </FONT>
<BR><FONT SIZE=3D2>&gt; format rather than just NAI or other encoding =
supported</FONT>
<BR><FONT SIZE=3D2>by</FONT>
<BR><FONT SIZE=3D2>&gt; Username.&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; - Diameter translation /CoA message comment, =
are you suggesting to</FONT>
<BR><FONT SIZE=3D2>&gt; prohibit the user of the attribute in =
COA/Disconnect message?&nbsp; Please </FONT>
<BR><FONT SIZE=3D2>&gt; note that the CUI is for identifying the user =
session than username.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; BR,</FONT>
<BR><FONT SIZE=3D2>&gt; Farid</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; --</FONT>
<BR><FONT SIZE=3D2>&gt; to unsubscribe send a message to =
[email-masked] with</FONT>
<BR><FONT SIZE=3D2>&gt; the word 'unsubscribe' in a single line as the =
message text body.</FONT>
<BR><FONT SIZE=3D2>&gt; archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>to unsubscribe send a message to =
[email-masked] with the word 'unsubscribe' in a single =
line as the message text body.</FONT></P>

<P><FONT SIZE=3D2>archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/" =
TARGET=3D"_blank">http://psg.com/lists/radiusext/</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C4B296.03835F1A--

--
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, 15 Oct 2004 00:26:26 +0000
To: [email-masked]
Cc: [email-masked]
Subject: Re: draft-arkko-roamops-rfc2486bis-02.txt
From: [email-masked]
Date: Thu, 14 Oct 2004 17:17:24 -0700

This is a multipart message in MIME format.
--=_alternative 0001994588256F2E_=
Content-Type: text/plain; charset="US-ASCII"

Hello Jari,

Very minor, a missing period on the bottom of section 2.7.
        "would first be converted in other1.example net to"
should be
        "would first be converted in other1.example.net to"

Also, sorry to come in so late on the disccusion but just wanted to add a 
comment on 2.7 Realm Construction as it pertains to roaming.  The proposed 
method seems to be opposite of what I see in practice today.  Typically 
what is commonly referred to as the prefix domain, the portion before the 
'!', is used for the intermediary domains where the suffix domain, portion 
after the '@', is used as the home domain.  Not only does it make it much 
more readable since the username@realm is preserved at the end of the 
string, but it also takes away the need to reorder the parts when proxying 
and is simpler for an intermediary domain to just strip off its own domain 
in the front and the first '!' and pass on the rest of the string. 

So in your example where you have

        [email-masked]

in practice today it would be written as

        [email-masked]

and sent from other1.example.net as
 
        [email-masked]

and sent from other2.example.net as

        [email-masked]

Not sure it really makes much of a difference since both are recursive 
just seems a little cleaner to me...
Thanks and regards,
Josh
--=_alternative 0001994588256F2E_=
Content-Type: text/html; charset="US-ASCII"

<br><font size=3><tt>Hello Jari,</tt></font>
<br>
<br><font size=3><tt>Very minor, a missing period on the bottom of section
2.7.</tt></font>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; &quot;would first
be converted in other1.example net to&quot;</tt></font>
<br><font size=3><tt>should be</tt></font>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; &quot;would first
be converted in other1.example.net to&quot;</tt></font>
<br>
<br>
<br><font size=3><tt>Also, sorry to come in so late on the disccusion but
just wanted to add a comment on 2.7 Realm Construction as it pertains to
roaming. &nbsp;The proposed method seems to be opposite of what I see in
practice today. &nbsp;Typically what is commonly referred to as the prefix
domain, the portion before the '!', is used for the intermediary domains
where the suffix domain, portion after the '@', is used as the home domain.
&nbsp;Not only does it make it much more readable since the username@realm
is preserved at the end of the string, but it also takes away the need
to reorder the parts when proxying and is simpler for an intermediary domain
to just strip off its own domain in the front and the first '!' and pass
on the rest of the string. &nbsp;</tt></font>
<br>
<br><font size=3><tt>So in your example where you have</tt></font>
<br>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; [email-masked]</tt></font>
<br>
<br><font size=3><tt>in practice today it would be written as</tt></font>
<br>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; [email-masked]</tt></font>
<br>
<br><font size=3><tt>and sent from other1.example.net as</tt></font>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; </tt></font>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; [email-masked]</tt></font>
<br>
<br><font size=3><tt>and sent from other2.example.net as</tt></font>
<br>
<br><font size=3><tt>&nbsp; &nbsp; &nbsp; &nbsp; [email-masked]</tt></font>
<br>
<br><font size=3><tt>Not sure it really makes much of a difference since
both are recursive just seems a little cleaner to me...</tt></font>
<br><font size=3><tt>Thanks and regards,<br>
Josh</tt></font>
--=_alternative 0001994588256F2E_=--

--
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, 14 Oct 2004 11:26:26 +0000
From: "Beck01, Wolfgang" <[email-masked]>
To: [email-masked]
Subject: Status of draft-sterman issues
Date: Thu, 14 Oct 2004 13:25:48 +0200

Hello,

below, I've compiled the open issues and solution proposals of draft-sterman.
Issue 8 (Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int) made quite a few changes necessary. Do we need a second WG Last
Call ?

Issue 3:
1) Abstract
new text:
'Several protocols borrow the syntax and authentication mechanisms
from the Hypertext Transfer Protocol, HTTP.  This document specifies
an extension to RADIUS that allows a RADIUS client in a HTTP-style
server, upon reception of a request, retrieve and compute Digest
authentication information from a RADIUS server.  Additionally, a
scenario describing  the authentication of a user emitting a
HTTP-style request is provided.'

2) body digest
renamed to Digest-Entity-Body-Hash

3) figures in attribute description
only one figure for all attributes

4) mentioning of early number assignments
removed

5) DIAMETER
-> Diameter

6) IANA request
added "This document serves as IANA registration request for ..."

7) horrible examples
shortened and fixed

Issue 4:
1) Attribute reuse
removed attribute reuse, introduced new attributes

Issue 5:
1) Digest-Stale
Use is now mandatory if server chooses nonces. 

2) Typos

Issue 6:
1) Overview too short
added overview section, rearranged document structure
     1.3   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  4
       1.3.1   Scenario 1, RADIUS client chooses nonces . . . . . . .  6
       1.3.2   Scenario 2, RADIUS server chooses nonces . . . . . . .  7

2) missing explanation for pre-computed hashes
new text:
'However, when using AKA [RFC3310] the nonce is partially derived from
a precomputed authentication vector.  These authentication vectors are
often stored centrally.'

3) unclear defintion of 'secured connection' 
added a reference to Security Considerations
added explanation in Security Considerations

Issue 7:
Use of Message Authenticator should be mandatory
RfC 2869 is informational. I see that it is useful but
I hesitate to make it mandatory. 
new text:
'Informational RfC 3579 [RFC3579], section 3.2 describes
a Message-Authenticator attribute which MAY be used to protect the
integrity of RADIUS messages.'

Issue 8:
Rspauth generation not possible if RADIUS server chooses nonces and
qop=auth-int 

In contrast to Diameter, RADIUS has no mandatory encryption support.
Sending H(A1) in the clear can make some attacks easier. Here's
the compromise:

A new attribute Digest-HA1 is introduced. It's use is restricted
to *-sess algorithms, where HA1 is constructed partially from random
values. 
>From the text:

   o  If the Digest-QoP attribute's value is 'auth' or unspecified, the
      RADIUS server puts a Digest-Response-Auth attribute into the
      Access-Accept message
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5-sess' or
      'AKAv1-MD5-sess', the RADIUS server puts a Digest-HA1 attribute
      into the Access-Accept message.
   o  If the Digest-QoP attribute's value is 'auth-int' and the
      Digest-Algorithm attribute's value is 'MD5' or 'AKAv1-MD5', the
      RADIUS server MUST NOT send a Digest-HA1 attribute unless the
      connection between RADIUS server and client is encrypted or
      otherwise protected against eavesdropping.

Issue 9:
On suggestion of Avi Lior, I replaced the special Access-Accept
with Access-Challenge

(Issue 10 refers to NAIbis)

Issue 11:
1) missing reference
new text:
'Due to the limitations and weaknesses of Digest authentication (see
   [RFC2617], section 4 />)..'

2) when to use server generated nonces
added a paragraph in the overview section

Wolfgang

--
Wolfgang Beck
T-Systems
Internet Netzplattformen
+49 6151 937 2863
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: Thu, 14 Oct 2004 08:48:32 +0000
Date: Thu, 14 Oct 2004 10:48:07 +0200
From: Nagi Reddy Jonnala <[email-masked]>
Reply-To: [email-masked]
Organization: Alcatel Telecom
To: [email-masked]
CC: "Nelson, David" <[email-masked]>, [email-masked], Pasi Eronen <[email-masked]>
Subject: Re: RFC2486bis issue 10 (Was: Re: Status of open issues?)

The first issue resolution is inline with my proposal and acceptable to me.

regards
Nagi.

Jari Arkko wrote:

> It seems that my draft has one issue, #10, marked
> as open. It was partially addressed already, but
> there's apparently one small thing that needs to
> be changed. I have revised the draft and if the WG
> agrees with the resolution I will submit it.
>
> Here's what the issue said:
>
> > See the snips from formal syntax (In fact they are there in the original RFC as well).
> >
> > char        =/ "\" x
> > x           =  %x00-7F ; all 128 ASCII characters, no exception
> >
> > I suppose that you would want to allow the user name like
> > "myusername\x0\x1". I'm curious to know  in which cases do we make use
> > of these combo characters.
>
> I do not know, but I do not want to limit the syntax from
> the original RFC. Lets leave them as they are.
>
> > Doesn't it look consistent if you make the syntax of x to take all 256
> > includes ASCII and the remaining UTF-8 characters ( i.e., x = %x00-FF)
>
> I think so. I have produced a straman version of
> draft-ietf-radext-rfc2486bis-01, see:
>
>    http://www.arkko.com/publications/nai/naibisdiff.html
>
> > [Ignacio Goyret]
> >
> > A detail:
> >
> > c =/ %x60-7a ; 'a'-'z' allowed
> > ^^^^ ^^^
> >
> > 0x60 == '`' (on a US keyboard, it is the key to the left of the '1'
> > 0x61 == 'a'
> > ...
>
> This has already been corrected in
> draft-ietf-radext-rfc2486bis-00.txt.
>
> > This also looks odd:
> > c =/ %x26 ; '&et;' allowed
> > ^^^
> > In USASCII, 0x26 == '&' or '&amp;' in html. Right?
>
> This too.
>
> --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/>

--
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, 14 Oct 2004 08:28:23 +0000
Date: Thu, 14 Oct 2004 11:26:41 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked], Pasi Eronen <[email-masked]>
Subject: RFC2486bis issue 10 (Was: Re: Status of open issues?)

It seems that my draft has one issue, #10, marked
as open. It was partially addressed already, but
there's apparently one small thing that needs to
be changed. I have revised the draft and if the WG
agrees with the resolution I will submit it.

Here's what the issue said:

> See the snips from formal syntax (In fact they are there in the original RFC as well).
> 
> char        =/ "\" x
> x           =  %x00-7F ; all 128 ASCII characters, no exception
> 
> I suppose that you would want to allow the user name like
> "myusername\x0\x1". I'm curious to know  in which cases do we make use
> of these combo characters.

I do not know, but I do not want to limit the syntax from
the original RFC. Lets leave them as they are.

> Doesn't it look consistent if you make the syntax of x to take all 256
> includes ASCII and the remaining UTF-8 characters ( i.e., x = %x00-FF)

I think so. I have produced a straman version of
draft-ietf-radext-rfc2486bis-01, see:

   http://www.arkko.com/publications/nai/naibisdiff.html

> [Ignacio Goyret]
> 
> A detail:
> 
> c =/ %x60-7a ; 'a'-'z' allowed
> ^^^^ ^^^
> 
> 0x60 == '`' (on a US keyboard, it is the key to the left of the '1'
> 0x61 == 'a'
> ...

This has already been corrected in
draft-ietf-radext-rfc2486bis-00.txt.

> This also looks odd:
> c =/ %x26 ; '&et;' allowed
> ^^^
> In USASCII, 0x26 == '&' or '&amp;' in html. Right?

This too.

--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: Thu, 14 Oct 2004 00:30:23 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Wed, 13 Oct 2004 17:26:41 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Greg Weber" <[email-masked]>, [email-masked]
cc: [email-masked], [email-masked], [email-masked]

I only intended 2 cents, but ended up with a buck fifty and change....

A perspective.

Typically iPass restricts the User-Name in the Access-Accept by policy
because of the emergence and continuing possibility of proxy routing
failures in both dial and Wi-Fi.  While specifically allowed in RADIUS,
and certainly valuable in peer-to-peer arrangements, it causes havoc
with logical peering through mediating networks, particularly when the
inner EAP method is completely negotiated independently by the peer and
H.A.S. =20

Which is okay!  This was never really a problem until tunneled EAP
methods introduced the second Identity, yah.   So for any provisioned
WPA service we have to audit the capability of each network and ensure
that this capability is known and supported wherever tunneled methods
are to be used for any Public Access service.  That is the challenge,
Greg.

For supplying UAM/GIS service or RAS narrowband, this doesn't really
matter (unless you are using EAP) since there is only a single Identity
and the billable subscriber can always be derived by the NAI post-facto;
therefore such cases we just filter the User-Name return in the
Access-Accept to guard against User-Name re-write and route failure.

However the spec is word-smithed, for many well established systems to
remain remotely stable for legacy radius proxy roaming involving
aggregation and mediation, the *User-Name must never be modified* unless
explicit knowledge of the supplier access arrangement is known.  Without
it, a Home Network won't always get a copy of their own acct due to
their own Access-Accept into a heterogeneous source-routed (by
necessity) proxy network.  Ergo if there is a need to expose the inner
EAP Identity (or alias of the authorizing profile), you must include it
in some attribute of the RADIUS accounting...but not the User-Name.

In sum, if you want to muck with the user-name on the
Access-Accept...you can't, thereby you must put it in the Chargeable
User Identity alias. Those networks who do overwrite the
User-Name...don't pass them one in an Access-Accept.  And for any
reasonable semblance of service oversight or fraud detection beyond the
Home Authentication Server's log, networks would be wise to ensure and
verify this Chargeable Alias feature is available for any WPA network
intending to use a tunneled EAP.  =3D^)   When a User-Name is returned, =
it
must go into the Chargeable Identity or get dropped, but the originally
(decorated and presented) User-Name must remain untouched to maintain
legacy RADIUS and OSS support.  That is truly our challenge as a VNO,
but we can't operationally approach an end-to-end EAP service without
the feature.  The added benefit is that now we can decorate the NAI
however we all want to!  =3D^))

There are some reasonable alternatives which iPass implement, but none
are as good as this proposal for handling multiple ID AAA and not
everybody has our advanced policy and privacy features.

Rambling,=20

Blair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Greg Weber
Sent: Tuesday, October 12, 2004 4:40 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: -01 version of Chargeable User Identity

Hi Farid,
A question on how -01 attempts to resolve a particular
part of issue #14.

  From -00:
                       The NAS or the access network AAA server MUST=20
      include  this  attribute  in  the  Accounting  Requests  (Start,=20
      Interim, and Stop) messages if it was included in the Access=20
      Accept message.=20
 =20
  From #14:
      [BA] I don't understand how backward compatibility is achieved.=20
      How is a RADIUS server to know whether the NAS supports the CUI=20
      attribute?

  -01 adds:
      In cases where the home RADIUS server cannot determine the NAS=20
      support for CUI attribute, it MUST send both the UserName (1)=20
      attribute and CUI attribute, with the understanding that if the=20
      NAS supports the CUI attribute the CUI attribute will override=20
      the identity portion the UserName (1) attribute.  That is, the=20
      UserName(1) attribute will be used for routing and the CUI=20
      attribute will be used for identity purposes.=20

But the additional text does not obviate the still existing
excerpt from the -00 draft.  -01 still says that the NAS
MUST send the new attribute if it is received and that is=20
a compatibility problem.

Greg

>=20
> Hi all,
> The version -01 should appear on ID repository soon.  In the mean
time,
> you can access the draft here :
>
http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-use
> r-id-01.txt.
>=20
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
> descriptions of the issues.
>=20
>=20
> Bernard,
>=20
> Regarding two of your comments,
>=20
> - Made a clarification on encoded format for CUI string.  But, we
> weren't sure if you were also questioning the proposed
> XX:YYYYYYYYYY format rather than just NAI or other encoding supported
by
> Username.  =20
>=20
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message?  Please
> note that the CUI is for identifying the user session than username. =20
>=20
> BR,
> Farid
>=20
> --
> 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/>
>=20

--
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, 13 Oct 2004 20:20:46 +0000
Content-class: urn:content-classes:message
Subject: Status of open issues?
Date: Wed, 13 Oct 2004 16:20:20 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I would like to request that all Internet Draft authors, whose drafts =
are under review by RADEXT, please check the Open Issues Tracker at =
http://www.drizzle.com/~aboba/RADEXT/ .

If there are open issues in your draft, please respond with a proposed =
resolution (or resolutions).  We will need to review this information =
during the Document Status agenda item at IETF-61 next month.  It would =
be well to identify resolutions, and if WG consensus is obtained, to =
submit a revised draft incorporating those changes prior to IETF-61.

Thank you, in advance, for your assistance.

As a reminder:

There are two (2) Internet-Draft cutoff dates for the 61st IETF Meeting =
in Washington, DC, USA:

October 18: Cutoff Date for Initial (i.e., -00) Internet-Draft =
Submissions=20

All initial Internet-Drafts (-00) must be submitted by Monday, October =
18 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, October 11 at 9:00 AM ET.

October 25: Cutoff Date for Revised (i.e., -01 and higher) =
Internet-Draft Submissions=20

All revised Internet-Drafts (-01 and higher) must be submitted by =
Monday, October 25 at 9:00 AM ET.

Regards,
=A0
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: Wed, 13 Oct 2004 00:19:55 +0000
From: Greg Weber <[email-masked]>
Subject: [Issue ] Editorial cmts on Chargeable User Identity
To: [email-masked]
Date: Tue, 12 Oct 2004 20:19:44 -0400 (EDT)

Editorial Comments on Chargeable User Identity (-01)
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: October 12, 2004
Reference: n/a
Document: ChargeIUD-01
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

I noticed a number of problems while reading this draft.
Correcting these will make the draft a little less likely
to confuse, and in some cases more correct.

.) The References are slightly jumbled. Section 1.1 has
   a reference to [RFC2119] but there is no citation in Section 7.
   Likewise Section 2 refers to [RFC 3588, NASREQ] without a
   citation.
.) Section 7 needs to be split into Informative and Normative
   references.
.) There are a lot of disallowed control characters- all those
   curly quotes and em-dashes.
.) References to RADIUS attribute names are inconsistent, e.g.:
   User-Name(1)
   UserName(1)
   UserName
   UserName (1)
   Likewise for Class and for "Chargeable-User-Identity".
   I'd suggest you make this consistent in the style of 3579/3580.
.) Likewise as above for RADIUS Packet Types, e.g. Access-Request.
.) In Section 2.1, under String, under "02", should that "URL" be
   a "URI"?
.) Does the IANA Considerations Section need to mention setting up
   a registry for the "User-Identity types", e.g. E.164, IMSI?

Proposed Resolution: 
  I think correcting these issues would assist readability.
  Using XML2RFC, as originally suggested in the RADEXT charter
  would help with some of these. :-)

--
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, 13 Oct 2004 00:11:10 +0000
Content-class: urn:content-classes:message
Subject: RE: -01 version of Chargeable User Identity
Date: Tue, 12 Oct 2004 17:07:26 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "Greg Weber" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Greg,
Thanks for reviewing the draft.  I see your point.  Does it help if we
say something like:

"
The NAS MUST include this  attribute  in  the  Accounting  Requests
(Start, Interim, and Stop) messages if it was included in the Access
Accept message and supported by NAS.
"

BR,
Farid

> -----Original Message-----
> From: Greg Weber [mailto:[email-masked]]=20
> Sent: Tuesday, October 12, 2004 4:40 PM
> To: Adrangi, Farid
> Cc: [email-masked]; [email-masked];=20
> [email-masked]
> Subject: Re: -01 version of Chargeable User Identity
>=20
>=20
>=20
> Hi Farid,
> A question on how -01 attempts to resolve a particular
> part of issue #14.
>=20
>   From -00:
>                        The NAS or the access network AAA server MUST=20
>       include  this  attribute  in  the  Accounting  Requests=20
>  (Start,=20
>       Interim, and Stop) messages if it was included in the Access=20
>       Accept message.=20
>  =20
>   From #14:
>       [BA] I don't understand how backward compatibility is achieved.=20
>       How is a RADIUS server to know whether the NAS supports the CUI=20
>       attribute?
>=20
>   -01 adds:
>       In cases where the home RADIUS server cannot determine the NAS=20
>       support for CUI attribute, it MUST send both the UserName (1)=20
>       attribute and CUI attribute, with the understanding that if the=20
>       NAS supports the CUI attribute the CUI attribute will override=20
>       the identity portion the UserName (1) attribute.  That is, the=20
>       UserName(1) attribute will be used for routing and the CUI=20
>       attribute will be used for identity purposes.=20
>=20
> But the additional text does not obviate the still existing
> excerpt from the -00 draft.  -01 still says that the NAS
> MUST send the new attribute if it is received and that is=20
> a compatibility problem.
>=20
> Greg
>=20
> >=20
> > Hi all,
> > The version -01 should appear on ID repository soon.  In=20
> the mean time,
> > you can access the draft here :
> >=20
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-char
geable-use
> r-id-01.txt.
>=20
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
> descriptions of the issues.
>=20
>=20
> Bernard,
>=20
> Regarding two of your comments,
>=20
> - Made a clarification on encoded format for CUI string.  But, we
> weren't sure if you were also questioning the proposed
> XX:YYYYYYYYYY format rather than just NAI or other encoding supported
by
> Username.  =20
>=20
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message?  Please
> note that the CUI is for identifying the user session than username. =20
>=20
> BR,
> Farid
>=20
> --
> 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/>
>=20

--
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, 12 Oct 2004 23:41:03 +0000
From: Greg Weber <[email-masked]>
Subject: Re: -01 version of Chargeable User Identity
To: [email-masked] (Adrangi, Farid)
Date: Tue, 12 Oct 2004 19:40:11 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]

Hi Farid,
A question on how -01 attempts to resolve a particular
part of issue #14.

  From -00:
                       The NAS or the access network AAA server MUST 
      include  this  attribute  in  the  Accounting  Requests  (Start, 
      Interim, and Stop) messages if it was included in the Access 
      Accept message. 
  
  From #14:
      [BA] I don't understand how backward compatibility is achieved. 
      How is a RADIUS server to know whether the NAS supports the CUI 
      attribute?

  -01 adds:
      In cases where the home RADIUS server cannot determine the NAS 
      support for CUI attribute, it MUST send both the UserName (1) 
      attribute and CUI attribute, with the understanding that if the 
      NAS supports the CUI attribute the CUI attribute will override 
      the identity portion the UserName (1) attribute.  That is, the 
      UserName(1) attribute will be used for routing and the CUI 
      attribute will be used for identity purposes. 

But the additional text does not obviate the still existing
excerpt from the -00 draft.  -01 still says that the NAS
MUST send the new attribute if it is received and that is 
a compatibility problem.

Greg

> 
> Hi all,
> The version -01 should appear on ID repository soon.  In the mean time,
> you can access the draft here :
> http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-chargeable-use
> r-id-01.txt.
> 
> The -01 update addresses the two issues (issue 13 and 14) submitted
> against the draft by David and Bernard respectively - please see
> http://www.drizzle.com/~aboba/RADEXT/#Issue%2014 for the detailed
> descriptions of the issues.
> 
> 
> Bernard,
> 
> Regarding two of your comments,
> 
> - Made a clarification on encoded format for CUI string.  But, we
> weren't sure if you were also questioning the proposed
> XX:YYYYYYYYYY format rather than just NAI or other encoding supported by
> Username.   
> 
> - Diameter translation /CoA message comment, are you suggesting to
> prohibit the user of the attribute in COA/Disconnect message?  Please
> note that the CUI is for identifying the user session than username.  
> 
> 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: Thu, 07 Oct 2004 14:04:08 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt
Date: Thu, 7 Oct 2004 10:02:31 -0400
From: "Nelson, David" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>, <[email-masked]>, <[email-masked]>

> However, it was later decided (by the chairs) that this work=20
> should be homed in GeoPriv WG because of their expertise in
> location objects and privacy.

Yes, with input from the relevant ADs.

> But, I think it would be nice this WG review this draft=20
> from RADIUS point of view -- e.g., attributes format and
> syntax.

Yes, that is the plan.

--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: Thu, 07 Oct 2004 08:07:47 +0000
From: Tschofenig Hannes <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt
Date: Thu, 7 Oct 2004 10:05:59 +0200 

hi glen, 

early this year it was decided that the work on radius carrying location
information as defined in the geopriv working group will be done in the
geopriv working group. it would be great if the radext working group could
review this draft as well. sorry, i forgot to post it here as well. 

review comments are highly appreciated!

ciao
hannes

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Wednesday, October 06, 2004 11:45 PM
> To: [email-masked]
> Subject: FW: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt
> 
> FYI; mightn't this be WG be a better place for this draft?
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> > directories. This draft is a work item of the Geographic 
> > Location/Privacy Working Group of the IETF.
> > 
> > 	Title		: Carrying Location Objects in RADIUS
> > 	Author(s)	: H. Tschofenig, et al.
> > 	Filename	: draft-ietf-geopriv-radius-lo-00.txt
> > 	Pages		: 47
> > 	Date		: 2004-10-6
> > 
> > This document describes RADIUS attributes for conveying the Access
> >    Network's operational ownership and location information based
> on a
> >    civil and geospatial location location format.
> > 
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-00.
> txt
> > 
> > To remove yourself from the I-D Announcement list, send a message
> to
> > [email-masked] with the word unsubscribe in the
> body
> > of the message. You can also visit
> > https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
> > subscription settings.
> > 
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with
> the
> > 	username "anonymous" and a password of your e-mail address.
> After
> > logging in, type "cd internet-drafts" and then "get 
> > draft-ietf-geopriv-radius-lo-00.txt".
> > 
> > A list of Internet-Drafts directories can be found in 
> > http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > 
> > Internet-Drafts can also be obtained by e-mail.
> > 
> > Send a message to:
> > 	[email-masked].
> > In the body type:
> > 	"FILE /internet-drafts/draft-ietf-geopriv-radius-lo-00.txt".
> > 
> > NOTE:	The mail server at ietf.org can return the document in
> > 	MIME-encoded form by using the "mpack" utility.  To use this
> > 	feature, insert the command "ENCODING mime" before the
> "FILE"
> > 	command.  To decode the response(s), you will need "munpack"
> or
> > 	a MIME-compliant mail reader.  Different MIME-compliant mail
> readers
> > 	exhibit different behavior, especially when dealing with
> > 	"multipart" MIME messages (i.e. documents which have been
> split
> > 	up into multiple messages), so check your local
> documentation on
> > 	how to manipulate these messages.
> > 
> > 
> > Below is the data which will enable a MIME compliant mail reader 
> > implementation to automatically retrieve the ASCII version of the 
> > Internet-Draft.
> > 
> >
> --------------------------------------------------------------------
> -----
> > In order to maintain computing infrastructure integrity, 
> Cisco Systems 
> > Enterprise Messaging Services and InfoSec teams have set a 
> mail policy 
> > disallowing executable attachments in email.
> > 
> > This message contained an executable attachment type that is 
> > prohibited by this policy. The attachment has been removed from
> this
> > message and copied to quarantine by our systems. It will be held
> in
> > quarantine for seven days in the event that the content needs to
> be
> > retrieved.  
> > 
> > 
> >
> --------------------------------------------------------------------
> -----
> > For further reference information about viruses and email
> antivirus
> > efforts within Cisco, please visit:
> > 
> > http://wwwin.cisco.com/it/ems/services/antiviral
> > 
> > 
> > If your concern isn't addressed by the information in this 
> > notification or the above web page, you may open a support
> request:
> > 
> > http://wwwin.cisco.com/support/
> > 
> > Select "Messaging", "Email-Related", "Mail Routing"
> > 
> > Please include in the text of your case the following information:
> > 
> > * Full headers of the message. Documentation on displaying the
> full
> > headers is available at this URL:
> > 
> > http://wwwin.cisco.com/support/library/faqs/solution002471.html
> > 
> > * This unique quarantine identifier: i96Ju0RT027671
> > 
> > If the matter is urgent, you may follow up by calling one of the
> below
> > referenced numbers. Please make every effort to provide the above 
> > requested information via the support web tool prior to calling as
> it
> > will greatly aid the resolution of your issue.
> > 
> > Americas:
> > 1 408 526 8888
> > 
> > Asiapac
> > +61 2 8446 8888
> > 
> > EMEA
> > +31 20 485 4888
> > 
> > Japan
> > +81 3 5549 6888
> > 
> > US (Toll Free)
> > 1| 800| 888| 8187| (ext.68888)
> > 
> > Thank you for your cooperation,
> > 
> > Enterprise Messaging Services
> > Cisco Systems, Inc
> 

--
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, 06 Oct 2004 22:37:08 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt
Date: Wed, 6 Oct 2004 15:35:48 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Glen,
There is a history behind this ....  But, in short, we started this work
in the RADEXT WG originally.  However, it was later decided (by the
chairs) that this work should be homed in GeoPriv WG because of their
expertise in location objects and privacy.  But, I think it would be
nice this WG review this draft from RADIUS point of view -- e.g.,
attributes format and syntax.  =20
BR,
Farid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Glen Zorn (gwz)
Sent: Wednesday, October 06, 2004 2:45 PM
To: [email-masked]
Subject: FW: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt

FYI; mightn't this be WG be a better place for this draft?

> A New Internet-Draft is available from the on-line Internet-Drafts=20
> directories. This draft is a work item of the Geographic=20
> Location/Privacy Working Group of the IETF.
>=20
> 	Title		: Carrying Location Objects in RADIUS
> 	Author(s)	: H. Tschofenig, et al.
> 	Filename	: draft-ietf-geopriv-radius-lo-00.txt
> 	Pages		: 47
> 	Date		: 2004-10-6
>=20
> This document describes RADIUS attributes for conveying the Access
>    Network's operational ownership and location information based
on a
>    civil and geospatial location location format.
>=20
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-00.
txt
>=20
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message. You can also visit=20
> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your=20
> subscription settings.
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with
the
> 	username "anonymous" and a password of your e-mail address.
After
> logging in, type "cd internet-drafts" and then "get=20
> draft-ietf-geopriv-radius-lo-00.txt".
>=20
> A list of Internet-Drafts directories can be found in=20
> http://www.ietf.org/shadow.html or=20
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-geopriv-radius-lo-00.txt".
>=20
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the
"FILE"
> 	command.  To decode the response(s), you will need "munpack"
or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been
split
> 	up into multiple messages), so check your local
documentation on
> 	how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader=20
> implementation to automatically retrieve the ASCII version of the=20
> Internet-Draft.
>=20
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco Systems

> Enterprise Messaging Services and InfoSec teams have set a mail policy

> disallowing executable attachments in email.
>=20
> This message contained an executable attachment type that is=20
> prohibited by this policy. The attachment has been removed from
this
> message and copied to quarantine by our systems. It will be held
in
> quarantine for seven days in the event that the content needs to
be
> retrieved.
>=20
>=20
>
--------------------------------------------------------------------
-----
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
>=20
> http://wwwin.cisco.com/it/ems/services/antiviral
>=20
>=20
> If your concern isn't addressed by the information in this=20
> notification or the above web page, you may open a support
request:
>=20
> http://wwwin.cisco.com/support/
>=20
> Select "Messaging", "Email-Related", "Mail Routing"
>=20
> Please include in the text of your case the following information:
>=20
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
>=20
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>=20
> * This unique quarantine identifier: i96Ju0RT027671
>=20
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above=20
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
>=20
> Americas:
> 1 408 526 8888
>=20
> Asiapac
> +61 2 8446 8888
>=20
> EMEA
> +31 20 485 4888
>=20
> Japan
> +81 3 5549 6888
>=20
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
>=20
> Thank you for your cooperation,
>=20
> Enterprise Messaging Services
> Cisco Systems, Inc

--
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, 06 Oct 2004 21:45:34 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn \(gwz\)" <[email-masked]>
To: <[email-masked]>
Subject: FW: I-D ACTION:draft-ietf-geopriv-radius-lo-00.txt
Date: Wed, 6 Oct 2004 14:45:01 -0700

This is a multi-part message in MIME format.

------=_NextPart_000_017A_01C4ABB3.0FCE98F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

FYI; mightn't this be WG be a better place for this draft?

> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Geographic
> Location/Privacy Working Group of the IETF. =20
>=20
> 	Title		: Carrying Location Objects in RADIUS
> 	Author(s)	: H. Tschofenig, et al.
> 	Filename	: draft-ietf-geopriv-radius-lo-00.txt
> 	Pages		: 47
> 	Date		: 2004-10-6
>=20
> This document describes RADIUS attributes for conveying the Access
>    Network's operational ownership and location information based
on a
>    civil and geospatial location location format.
>=20
> A URL for this Internet-Draft is:
>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-00.
txt
>=20
> To remove yourself from the I-D Announcement list, send a message
to
> [email-masked] with the word unsubscribe in the
body
> of the message. You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
> subscription settings.=20
>=20
>=20
> Internet-Drafts are also available by anonymous FTP. Login with
the
> 	username "anonymous" and a password of your e-mail address.
After
> logging in, type "cd internet-drafts" and then "get
> draft-ietf-geopriv-radius-lo-00.txt". =20
>=20
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt=20
>=20
>=20
> Internet-Drafts can also be obtained by e-mail.
>=20
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-geopriv-radius-lo-00.txt".
>=20
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the
"FILE"
> 	command.  To decode the response(s), you will need "munpack"
or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been
split
> 	up into multiple messages), so check your local
documentation on
> 	how to manipulate these messages.
>=20
>=20
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft. =20
>=20
>
--------------------------------------------------------------------
-----
> In order to maintain computing infrastructure integrity, Cisco
> Systems Enterprise Messaging Services and InfoSec teams have set a
> mail policy disallowing executable attachments in email. =20
>=20
> This message contained an executable attachment type that is
> prohibited by this policy. The attachment has been removed from
this
> message and copied to quarantine by our systems. It will be held
in
> quarantine for seven days in the event that the content needs to
be
> retrieved. =20
>=20
>=20
>
--------------------------------------------------------------------
-----
> For further reference information about viruses and email
antivirus
> efforts within Cisco, please visit:
>=20
> http://wwwin.cisco.com/it/ems/services/antiviral
>=20
>=20
> If your concern isn't addressed by the information in this
> notification or the above web page, you may open a support
request:
>=20
> http://wwwin.cisco.com/support/
>=20
> Select "Messaging", "Email-Related", "Mail Routing"
>=20
> Please include in the text of your case the following information:
>=20
> * Full headers of the message. Documentation on displaying the
full
> headers is available at this URL:
>=20
> http://wwwin.cisco.com/support/library/faqs/solution002471.html
>=20
> * This unique quarantine identifier: i96Ju0RT027671
>=20
> If the matter is urgent, you may follow up by calling one of the
below
> referenced numbers. Please make every effort to provide the above
> requested information via the support web tool prior to calling as
it
> will greatly aid the resolution of your issue.
>=20
> Americas:
> 1 408 526 8888
>=20
> Asiapac
> +61 2 8446 8888
>=20
> EMEA
> +31 20 485 4888
>=20
> Japan
> +81 3 5549 6888
>=20
> US (Toll Free)
> 1| 800| 888| 8187| (ext.68888)
>=20
> Thank you for your cooperation,
>=20
> Enterprise Messaging Services
> Cisco Systems, Inc

------=_NextPart_000_017A_01C4ABB3.0FCE98F0
Content-Type: text/plain;
	name="ATT00261.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename="ATT00261.txt"

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

------=_NextPart_000_017A_01C4ABB3.0FCE98F0--

--
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, 03 Oct 2004 06:12:15 +0000
Date: Sat, 2 Oct 2004 23:02:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REMINDER: Posting Issues to the RADEXT Issues List

This is just a reminder about the process for posting Issues.

If you are posting an Issue (as opposed to just asking a question), you
MUST include the string "Issue" in the subject line of your posting.

If you are posting an issue, please also use the Issue format specified on
the RADEXT Issues list:

http://www.drizzle.com/~aboba/RADEXT/

This format enables us to be clear about what draft your issue refers to,
what section is affected, and what the proposed solution is.

Along with the issue,  please also include the proposed text.  Just saying
"this is an issue" isn't sufficient -- editors will typically not make
changes until consensus has emerged on a proposed resolution.  The best
way to ensure that a problem is resolved is to propose a fix to the
editor.

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