Subject: Re: Submission for RADIUS extensions working group
From: "Randy Chou" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>
Date: Sat, 31 Jul 2004 01:29:58 -0700

> Post under a pseudonym to bugtraq,

Great.  Now every anonymous post on bugtraq related to RADIUS will be blamed
on me :).  Seriously though, I'm looking for a way to get the vendors to
understand the severity of not being compliant and also educate the consumer
on the best practices when implementing Radius.

> IPsec with a 6 byte shared key is not very secure either. :)
>
> There's no excuse for a vendor's not allowing an adequately long shared
> secret.  If RADIUS is actually insecure with a shared secret with at
> least 128 bits of entropy, we need to hear about it and take action,
> but unless I'm missing something that's not the case.

That's the thing.  How secure something is also depends on what and how it's
used.  By not incorporating IPSEC as a requirement, too many of the security
decisions IMO are left to the consumer who a lot of times is not
knowledgeable enough to make an educated decision.  Not that I'm suggesting
people to use 6-byte shared keys, but using it as an example...If I had an
offline sniff of a RADIUS handshake that was encrypted with a 6-byte RADIUS
shared key, I'd be able to decrypt that very easily.  On the other hand, if
I had the same handshake over IPSEC w/ a 6-byte IKE pre-shared key, I would
never be able to decrypt that assuming DH is used (as it typically is).
That's just one of the properties of IPSEC.

Another example would be the case where a good enterprise uses RADIUS and
rotates the RADIUS shared secret diligently say once every week.  If a
hacker sniffed RADIUS packets, stored it, and say somehow gets the shared
secret 12 weeks later, he would still be able to get the contents.  On the
other hand if IPSEC was used in this case, the hacker would not be able to
decrypt the contents even after he knew the IKE pre-shared key.  This
problem may or may not be serious depending on the application.  If the
contents were the keys that secured financial reports from a company, the
decryption of the report 12 weeks later would matter much less (public
knowledge by then) than compared to data that contained employee
compensation.  By not using IPSEC, we're settling for the lowest common
denominator.  But most consumers don't know the implications of that
decision.  Again, there are many other properties of IPSEC that are missing
in RADIUS.  To get to the same level of security would be re-inventing the
wheel.  I would assume this conclusion was reached back when RADIUS over
IPSEC was already recommended in the RFC.  However, few NAS vendors follow
such recommendation.

Anyways, let me know if you think we're still wasting your time.  If not,
we'd really like more feedback.  We chose what we considered a set of
examples that illustrated the severity of the problems.

Regards,

--
Randy

----- Original Message ----- 
From: "Barney Wolff" <[email-masked]>
To: "Randy Chou" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, July 31, 2004 12:00 AM
Subject: Re: Submission for RADIUS extensions working group

> On Fri, Jul 30, 2004 at 11:12:56PM -0700, Randy Chou wrote:
> > Thanks for the feedback.  Here are my comments...
> >
> > > A draft discussing faulty implementations, by name, would be useful.
> > > So would problem reports to the vendors/authors of said faulty
> > > implementations.
> >
> > A CERT was already sent.  Unfortunately, discussion of the vendors by
name
> > is not a good way to approach this for hopefully obvious reasons.  On
the
> > other hand, as you said, many of these vulnerabilities have been known
for a
> > while.  If you have any other creative ideas on how to approach this,
please
> > do share.
>
> Post under a pseudonym to bugtraq, if you have actually notified the
> vendor(s) and gotten no satisfactory response in a reasonable time.
> Why on earth should RADIUS vendors be immune from having security
> vulnerabilities pointed out when everybody else in the world is not?
>
> > > If one were going to expound on RADIUS vulnerabilities, the most
> > > serious one in my opinion is that the CHAP response is unencrypted
> >
> > Everyone has their favorite one.  I actually don't consider these
> > vulnerabilities in RADIUS, but the lack of compliance to the standard
itself
> > in many NAS devices.  If everyone ran RADIUS over IPSEC as recommended
in
> > the RFC, most of these issues would go away.  Sometimes I wonder if it
> > would've been better if none of the RADIUS handshakes were hashed.  Then
> > maybe people would've stopped using it to send keys around until they
made
> > sure the mechanism to transport it was truly secure.
>
> RADIUS hashing predates IPsec.  One might argue that it should have been
> dropped when IPsec became practical to run on all new equipment, but
> just this week I saw somebody wanting to acquire a Portmaster to use for
> multiple remote console access.  Customers do tend to get upset when
> equipment that still works is obsoleted by fiat, much as protocol
> designers and developers might wish otherwise.
>
> IPsec with a 6 byte shared key is not very secure either. :)
>
> There's no excuse for a vendor's not allowing an adequately long shared
> secret.  If RADIUS is actually insecure with a shared secret with at
> least 128 bits of entropy, we need to hear about it and take action,
> but unless I'm missing something that's not the case.
>
> -- 
> 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, 31 Jul 2004 07:01:33 +0000
Date: Sat, 31 Jul 2004 03:00:50 -0400
From: Barney Wolff <[email-masked]>
To: Randy Chou <[email-masked]>
Cc: [email-masked]
Subject: Re: Submission for RADIUS extensions working group

On Fri, Jul 30, 2004 at 11:12:56PM -0700, Randy Chou wrote:
> Thanks for the feedback.  Here are my comments...
> 
> > A draft discussing faulty implementations, by name, would be useful.
> > So would problem reports to the vendors/authors of said faulty
> > implementations.
> 
> A CERT was already sent.  Unfortunately, discussion of the vendors by name
> is not a good way to approach this for hopefully obvious reasons.  On the
> other hand, as you said, many of these vulnerabilities have been known for a
> while.  If you have any other creative ideas on how to approach this, please
> do share.

Post under a pseudonym to bugtraq, if you have actually notified the
vendor(s) and gotten no satisfactory response in a reasonable time.
Why on earth should RADIUS vendors be immune from having security
vulnerabilities pointed out when everybody else in the world is not?

> > If one were going to expound on RADIUS vulnerabilities, the most
> > serious one in my opinion is that the CHAP response is unencrypted
> 
> Everyone has their favorite one.  I actually don't consider these
> vulnerabilities in RADIUS, but the lack of compliance to the standard itself
> in many NAS devices.  If everyone ran RADIUS over IPSEC as recommended in
> the RFC, most of these issues would go away.  Sometimes I wonder if it
> would've been better if none of the RADIUS handshakes were hashed.  Then
> maybe people would've stopped using it to send keys around until they made
> sure the mechanism to transport it was truly secure.

RADIUS hashing predates IPsec.  One might argue that it should have been
dropped when IPsec became practical to run on all new equipment, but
just this week I saw somebody wanting to acquire a Portmaster to use for
multiple remote console access.  Customers do tend to get upset when
equipment that still works is obsoleted by fiat, much as protocol
designers and developers might wish otherwise.

IPsec with a 6 byte shared key is not very secure either. :)

There's no excuse for a vendor's not allowing an adequately long shared
secret.  If RADIUS is actually insecure with a shared secret with at
least 128 bits of entropy, we need to hear about it and take action,
but unless I'm missing something that's not the case.

-- 
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, 31 Jul 2004 06:09:13 +0000
From: "Randy Chou" <[email-masked]>
To: "Barney Wolff" <[email-masked]>, "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Submission for RADIUS extensions working group
Date: Fri, 30 Jul 2004 23:12:56 -0700

Thanks for the feedback.  Here are my comments...

> A draft discussing faulty implementations, by name, would be useful.
> So would problem reports to the vendors/authors of said faulty
> implementations.

A CERT was already sent.  Unfortunately, discussion of the vendors by name
is not a good way to approach this for hopefully obvious reasons.  On the
other hand, as you said, many of these vulnerabilities have been known for a
while.  If you have any other creative ideas on how to approach this, please
do share.

> A draft pointing out, yet again, that shared-secret crypto depends
> on an adequately long and not widely shared key, is not.

We also wanted to point out the practicality of attacking and consequences
of faulty implementations.

> If one were going to expound on RADIUS vulnerabilities, the most
> serious one in my opinion is that the CHAP response is unencrypted

Everyone has their favorite one.  I actually don't consider these
vulnerabilities in RADIUS, but the lack of compliance to the standard itself
in many NAS devices.  If everyone ran RADIUS over IPSEC as recommended in
the RFC, most of these issues would go away.  Sometimes I wonder if it
would've been better if none of the RADIUS handshakes were hashed.  Then
maybe people would've stopped using it to send keys around until they made
sure the mechanism to transport it was truly secure.

Regards,

--
Randy

----- Original Message ----- 
From: "Barney Wolff" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, July 30, 2004 9:40 AM
Subject: Re: Submission for RADIUS extensions working group

> On Fri, Jul 30, 2004 at 07:48:03AM -0700, Bernard Aboba wrote:
> > We have had a late submission relating to RADIUS security
vulnerabilities.
> > I've allocated time for discussion of this within the Thursday session.
> >
> > Since the draft submission deadline has closed, the document is
available
> > for examination here:
> > http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt
>
> Since I won't be at the meeting, I'll make my comments here.
>
> A draft discussing faulty implementations, by name, would be useful.
> So would problem reports to the vendors/authors of said faulty
> implementations.
>
> A draft pointing out, yet again, that shared-secret crypto depends
> on an adequately long and not widely shared key, is not.
>
> If one were going to expound on RADIUS vulnerabilities, the most
> serious one in my opinion is that the CHAP response is unencrypted,
> thus exposing users' secrets to offline attack.  That makes user-chosen
> CHAP secrets very risky.  Hardly new news.
>
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via the 'Net.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

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

Delivery-date: Fri, 30 Jul 2004 17:37:44 +0000
Date: Fri, 30 Jul 2004 10:33:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Radius MIBs statistics misunderstandings (fwd)

---------- Forwarded message ----------
Date: Wed, 28 Jul 2004 17:25:53 +0200
From: Nagi Reddy Jonnala <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], 'Bernard Aboba' <[email-masked]>
Subject: Radius MIBs statistics misunderstandings

As suggested by Bernard, since the WG is revising the MIBs,  this
discussion might be generally useful.

Glen,

I would like to resolve these statistics misunderstandings once and for
all. Could you please review if my understanding match with your
interpretations.

Issue-1:

Stefaan asked:

  > Some questions we have regarding the existing RFCs (since you are
  > updating these) we found while writing our draft:
  >
  > 1) Is the definition o TotalIncomingPackets in RFC2618 on page 6
  > correct? I believe there is something wrong with it.

Glen replied:

  I think that you are right.  With the curent definition, it appears
that
  "Successfully Received" could be negative, since we're subtracting
  counters from TotalIncomingPackets that were not include in the sum.
  Also, I guess that "AccessRequests + PendingRequests + ClientTimeouts
=
  Successfully Received" just below should read "AccessRequests +
  PendingRequests + ClientTimeouts = Successfully Transmitted".

Nagi commented:

My understanding is that RFC-2618 considers that an Access Response
(Accept or Reject or Challenge) counter MUST be incremented before it is
validated. i.e.,
Either one of Malformed responses or bad authenticators or  packets
dropped counters will be incremented if the packet is invalid.

Do you interpret the same from the RFC-2618. If yes, I would like to
know what are the reasons for this. Isn't that an Access Response
counter MUST be incremented
only after the packet is found *valid*.

If you are convinced that the approach in RFC-2618 is OK, then I would
say that the first two equations hold good. i.e., Your statement above
(saying
Successfully_Received could be negative) is incorrect. Am I right? or
missing something?

Issue-2:

Stefaan asked:

  > 3) radiusAuthClientPendingRequests: upon retransmission this counter

  > is decremented. So a retransmitted packet is not considered as being

  > pending, although such restransmissions can still be considered as
  > being pending requests.

Glen replied:

  Yup, it probably shouldn't be decremented on retransmissions,
especially
  since it's already decremented on timeouts.

Nagi commented:

My understanding is that Pending requests should be decremented on
receiving an Access response and on an expiry of timeout. It looks
obvious to me that Pending
requests should be incremented on a retransmission (to the same server).

Please see the text

"This variable is incremented when an Access-Request is sent and
decremented due to
 receipt of an Acess-Accept, Access-Reject or Access-Challenge, a
timeout or retransmission."

I suspect that the text is misleading. The text should be like

"This variable is incremented when an Access-Request and retransmission
is sent and decremented due to receipt of an Acess-Accept, Access-Reject
or
Access-Challenge, a timeout "

Do you guys agree?

Issue-3:

See the equation:

AccessRequests + PendingRequests + ClientTimeouts = Successfully
Received

I agree with you that left hand side value should be equal to
"Successfully Transmitted".  Also  "AccessRequests +
AccessRetransmissions = Successfully
Transmitted" equation holds good. Right?

Thanks & regards
Nagi.

--
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, 30 Jul 2004 16:41:31 +0000
Date: Fri, 30 Jul 2004 12:40:30 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Submission for RADIUS extensions working group

On Fri, Jul 30, 2004 at 07:48:03AM -0700, Bernard Aboba wrote:
> We have had a late submission relating to RADIUS security vulnerabilities.
> I've allocated time for discussion of this within the Thursday session.
> 
> Since the draft submission deadline has closed, the document is available
> for examination here:
> http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt

Since I won't be at the meeting, I'll make my comments here.

A draft discussing faulty implementations, by name, would be useful.
So would problem reports to the vendors/authors of said faulty
implementations.

A draft pointing out, yet again, that shared-secret crypto depends
on an adequately long and not widely shared key, is not.

If one were going to expound on RADIUS vulnerabilities, the most
serious one in my opinion is that the CHAP response is unencrypted,
thus exposing users' secrets to offline attack.  That makes user-chosen
CHAP secrets very risky.  Hardly new news.

-- 
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, 30 Jul 2004 14:52:38 +0000
Date: Fri, 30 Jul 2004 07:48:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Submission for RADIUS extensions working group

We have had a late submission relating to RADIUS security vulnerabilities.
I've allocated time for discussion of this within the Thursday session.

Since the draft submission deadline has closed, the document is available
for examination here:
http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt

-------------------------------------------------------------------
IETF Secretariat, Working Group Chairs,

Please accept this draft submission for consideration as a working
group document.

Thank you,

- -Josh
- --
- -Joshua Wright
The SANS Institute
[email-masked]
http://home.jwu.edu/jwright/

--
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, 30 Jul 2004 14:52:22 +0000
Date: Fri, 30 Jul 2004 07:48:20 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Thursday Agenda, Take One

The Secretariat has been kind enough to allocate another session to the
RADEXT WG.  Below find our preliminary plan for the Thursday slot.

RADIUS Extensions WG (radext)

Thursday, August 5, 2004
0900 - 1130 (Marina 5)
==================================================

CHAIRS: Bernard Aboba <[email-masked]>
        David Nelson <[email-masked]>

AGENDA:

Preliminaries (5 minutes)

Bluesheets
 Meeting Minutes
 Agenda Bashing

RADIUS Implementation Issues and Fixes (20 minutes)
  Various short (1-2 slide) presentations.  If you're interested
  in presenting, send email to the chairs.

RADIUS Data Model Issues (40 minutes)

RADIUS RFC Data Model, Bernard Aboba, 10 minutes
TBD

RADIUS attributes extension, Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-01.txt

Diameter/RADIUS Compatibility Issues - Jari Arkko, 10 minutes
http://ops.ietf.org/lists/radiusext/2004/msg00441.html
http://www.drizzle.com/~aboba/RADEXT/draft-congdon-radext-ieee802-01.txt
(Appendix A)

Discussion, 10 minutes

RADIUS Security Issues (30 minutes)

RADIUS Security Vulnerability - Randy Chou, 10 minutes
http://www.drizzle.com/~aboba/RADEXT/radius_vuln_00.txt

Alternative EAP keying approaches, Glen Zorn & Jesse Walker, 10 minutes
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-01.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-02.txt

Discussion, 10 minutes

Wrap-Up (10 minutes)

--
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, 29 Jul 2004 19:00:24 +0000
Date: Thu, 29 Jul 2004 11:56:06 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Slides for IETF 60

If you are presenting at IETF 60, please send your slides to David and
myself.  The schedule is packed so we are going to preload the slides on
the laptop so as to avoid switching delays.

--
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, 27 Jul 2004 21:41:13 +0000
Date: Tue, 27 Jul 2004 14:37:54 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: Issue with 3576

Actually, we are got another slot from the Secretariat, so we can give you
separate time for this (on Thursday).  So there is no need to cramp your
other presentation to squeeze this in.

On Tue, 27 Jul 2004, Avi Lior wrote:

> Yes I will Bernard.  Unfortunately we need to address the semantics issue.
> I will include it as part of my slot.  I don't think additional time will be
> needed.  I am going last anyway.

--
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, 27 Jul 2004 21:32:20 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Issue with 3576
Date: Tue, 27 Jul 2004 17:31:59 -0400

Yes I will Bernard.  Unfortunately we need to address the semantics issue.
I will include it as part of my slot.  I don't think additional time will be
needed.  I am going last anyway.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, July 27, 2004 3:30 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: Issue with 3576
> 
> 
> > Okay I see my confusion:
> >
> > 1) Message-Authenticator SHOULD be included in an 
> Access-Request that 
> > does not contain....EAP-Message,
> >
> > 2) Message-Authenticator MUST be included in an Access-Request that 
> > contains EAP-Message.
> >
> > I am aware of item 2 but somehow when I read item 1) it seemed to 
> > exclude item 2).  So I am okay now.
> 
> I think the confusion with respect to the "Authorize Only" 
> semantics remain though, right?  Would you be willing to 
> prepare a slide or two for IETF 60 to describe the issues?
> 
> > > > It should be more explicit what the behavior is.  For 
> example, we 
> > > > should state what happens when the Access-Accept with an 
> > > > Authorize-Only is received that doesn't contain attributes
> > > that were
> > > > previously received in an Access-Accept message.  This is cause 
> > > > for lots of discussion.
> > >
> > > Yes, I do think we need to be more explicit on this.  This can be 
> > > put into an errata (or the "implementations and fixes"
> > > doc) once we figure this out.
> 

--
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, 27 Jul 2004 20:08:22 +0000
Date: Tue, 27 Jul 2004 13:00:52 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT Monday Agenda, Take Seven

The folks at the Secretariat have been generous enough to grant our
request for an additional RADEXT session (on Thursday morning).  As a
result, we're in the process of reformulating our agenda.

Here is a fresh take at the potential Monday agenda.  The potential
Thursday agenda is a work in progress at this point.

RADIUS Extensions WG (radext)

Monday, August 2, 2004
1300-1500 (Marina 5)
========================================

CHAIRS: Bernard Aboba <[email-masked]>
        David Nelson <[email-masked]>

AGENDA:

Preliminaries (15 minutes)

Bluesheets
 Meeting Minutes
 Agenda Bashing
 Liaison Requests
    See: http://www.drizzle.com/~aboba/RADEXT/liaisons/
 Issues List
 Review Procedures
 Document Status

Management Issues (30 minutes)

IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 10 min
 http://www.ietf.org/rfc/rfc2618.txt
 http://www.ietf.org/rfc/rfc2619.txt
 http://www.ietf.org/rfc/rfc2620.txt
 http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba, 10 minutes
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

RADIUS Management Issues - David Nelson, 10 minutes
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-00.txt

SIP-RADIUS (10 minutes)

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt

(W)LAN applications (45 minutes)

RFC 2486bis - Jari Arkko, 10 minutes
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt

EAP lower layer attribues for AAA protocols - David Mariblanca, 10 minutes
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
http://www.drizzle.com/~aboba/IEEE/draft-congdon-radext-ieee802-01.txt

Re-direction Support - Avi Lior, 5 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Bandwidth Attributes - Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt

Pre-Paid (20 minutes)

RADIUS Prepaid - Avi Lior, 10 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-05.txt

Prepaid Extensions to RADIUS for Event-Based Charging -  H. Tschofenig, 10
minutes
http://www.ietf.org/internet-drafts/draft-guenther-radext-ppebc-00.txt

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

Delivery-date: Tue, 27 Jul 2004 19:41:02 +0000
Date: Tue, 27 Jul 2004 12:37:42 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Presentations on Interoperability Issues

During the last few months we have talked about a number of
interoperability issues that have arisen.  For example, Avi has mentioned
some lack of clarity in RFC 3576, we've talked about problems with the use
of User-Name for accounting identification, etc.

I have set aside some time on the RADEXT WG Agenda for discussion of
"RADIUS Implementation Issues".  If you have something that
fits in this category that can be presented in a few slides with say, 5
minutes of airtime, send email to myself or David.

--
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, 27 Jul 2004 19:33:56 +0000
Date: Tue, 27 Jul 2004 12:30:29 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: [email-masked]
Subject: RE: Issue with 3576

> Okay I see my confusion:
>
> 1) Message-Authenticator SHOULD be included in an Access-Request that does
> not contain....EAP-Message,
>
> 2) Message-Authenticator MUST be included in an Access-Request that contains
> EAP-Message.
>
> I am aware of item 2 but somehow when I read item 1) it seemed to exclude
> item 2).  So I am okay now.

I think the confusion with respect to the "Authorize Only" semantics
remain though, right?  Would you be willing to prepare a slide or two for
IETF 60 to describe the issues?

> > > It should be more explicit what the behavior is.  For example, we
> > > should state what happens when the Access-Accept with an
> > > Authorize-Only is received that doesn't contain attributes
> > that were
> > > previously received in an Access-Accept message.  This is cause for
> > > lots of discussion.
> >
> > Yes, I do think we need to be more explicit on this.  This
> > can be put into an errata (or the "implementations and fixes"
> > doc) once we figure this out.

--
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, 27 Jul 2004 19:13:21 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: Murtaza Chiba <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: Issue with 3576
Date: Tue, 27 Jul 2004 15:13:03 -0400

Okay I see my confusion:

1) Message-Authenticator SHOULD be included in an Access-Request that does
not contain....EAP-Message,

2) Message-Authenticator MUST be included in an Access-Request that contains
EAP-Message.

I am aware of item 2 but somehow when I read item 1) it seemed to exclude
item 2).  So I am okay now.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, July 27, 2004 10:49 AM
> To: Avi Lior
> Cc: Murtaza Chiba; [email-masked]; [email-masked]
> Subject: Re: Issue with 3576
> 
> 
> > I found a minor bug in 3576 ( I don't know if this one was reported 
> > yet)
> >
> > Deep down in Note[6] it says:
> >
> > a Message-Authenticator attribute SHOULD be included in an 
> > Access-Request that does not contain a User-Password, 
> CHAP-Password, 
> > ARAP-Password or EAP-Message Attribute.
> 
> The complete quote is:
> 
>  As noted in [RFC2869] Section 5.19, a Message-Authenticator 
> attribute  SHOULD be included in an Access-Request that does 
> not contain a  User-Password, CHAP-Password, ARAP-Password or 
> EAP-Message Attribute.
> 
> Note [6] applied to the Service-Type attribute, in order to 
> remind implementers that Service-Type="Authorize Only" could 
> not be sent in an Access-Request without a 
> Message-Authenticator attribute.
> 
> > The inclusion of EAP-Message in an Access-Request however 
> does require 
> > Message-Authenticator.
> 
> Yes, that is required (in [RFC2869] and [RFC3579]).  Since 
> the quote references those documents, I don't think there is 
> a contradiction.
> 
> > As well, unless I am missing something, 3576 does not say what the 
> > semantics of the Re-authorization Access-Request message.
> 
> Note [6] says:
> 
> "the NAS should attempt reauthorization by sending an Access- 
> Request with a Service-Type Attribute with value "Authorize 
> Only". The (perhaps naive) assumption is that these 
> Access-Request messages would otherwise obey RFC 2865.
> 
> > It just eludes to the fact
> > that it is there to ease interop between RADIUS and 
> DIAMETER.  Reading 
> > between the line then one would conclude that they have to read 
> > diameter to understand the semantics.  In fact NASREQ right?
> 
> NASREQ does contain the discussion on the translation of 
> server-initiated messages between RADIUS and Diameter.  Among 
> other things, we discovered in the process of writing those 
> sections that the RFC 3579 discussion of translation of 
> Disconnect-Request messages is wrong; Diameter supports the 
> Disconnect-Request/ACK model, so that an "Authorize Only" 
> Disconnect-Request is not necessary.  That is a pretty 
> significant error, so an errata is probably needed for that.
> 
> > It should be more explicit what the behavior is.  For example, we 
> > should state what happens when the Access-Accept with an 
> > Authorize-Only is received that doesn't contain attributes 
> that were 
> > previously received in an Access-Accept message.  This is cause for 
> > lots of discussion.
> 
> Yes, I do think we need to be more explicit on this.  This 
> can be put into an errata (or the "implementations and fixes" 
> doc) once we figure this out.
> 

--
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, 27 Jul 2004 17:53:10 +0000
Date: Tue, 27 Jul 2004 10:49:25 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: Murtaza Chiba <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Issue with 3576

> I found a minor bug in 3576 ( I don't know if this one was reported yet)
>
> Deep down in Note[6] it says:
>
> a Message-Authenticator attribute SHOULD be included in an Access-Request
> that does not contain a
> User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

The complete quote is:

 As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute
 SHOULD be included in an Access-Request that does not contain a
 User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

Note [6] applied to the Service-Type attribute, in order to remind
implementers that Service-Type="Authorize Only" could not be sent
in an Access-Request without a Message-Authenticator attribute.

> The inclusion of EAP-Message in an Access-Request however does require
> Message-Authenticator.

Yes, that is required (in [RFC2869] and [RFC3579]).  Since the quote
references those documents, I don't think there is a contradiction.

> As well, unless I am missing something, 3576 does not say what the semantics
> of the Re-authorization Access-Request message.

Note [6] says:

"the NAS should attempt reauthorization by sending an Access-
Request with a Service-Type Attribute with value "Authorize Only".
The (perhaps naive) assumption is that these Access-Request messages would
otherwise obey RFC 2865.

> It just eludes to the fact
> that it is there to ease interop between RADIUS and DIAMETER.  Reading
> between the line then one would conclude that they have to read diameter to
> understand the semantics.  In fact NASREQ right?

NASREQ does contain the discussion on the translation of server-initiated
messages between RADIUS and Diameter.  Among other things, we discovered
in the process of writing those sections that the RFC 3579 discussion of
translation of Disconnect-Request messages is wrong; Diameter supports the
Disconnect-Request/ACK model, so that an "Authorize Only"
Disconnect-Request is not necessary.  That is a pretty significant error,
so an errata is probably needed for that.

> It should be more explicit what the behavior is.  For example, we should
> state what happens when the Access-Accept with an Authorize-Only is received
> that doesn't contain attributes that were previously received in an
> Access-Accept message.  This is cause for lots of discussion.

Yes, I do think we need to be more explicit on this.  This can be put into
an errata (or the "implementations and fixes" doc) once we figure this
out.

--
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, 27 Jul 2004 15:34:49 +0000
From: Avi Lior <[email-masked]>
To: Bernard Aboba <[email-masked]>, Murtaza Chiba <[email-masked]>,  [email-masked]
Cc: [email-masked]
Subject: Issue with 3576
Date: Tue, 27 Jul 2004 11:34:09 -0400

Bernard, Murtaza,

I found a minor bug in 3576 ( I don't know if this one was reported yet)

Deep down in Note[6] it says:

a Message-Authenticator attribute SHOULD be included in an Access-Request
that does not contain a
User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute.

The inclusion of EAP-Message in an Access-Request however does require
Message-Authenticator.

As well, unless I am missing something, 3576 does not say what the semantics
of the Re-authorization Access-Request message.  It just eludes to the fact
that it is there to ease interop between RADIUS and DIAMETER.  Reading
between the line then one would conclude that they have to read diameter to
understand the semantics.  In fact NASREQ right?

It should be more explicit what the behavior is.  For example, we should
state what happens when the Access-Accept with an Authorize-Only is received
that doesn't contain attributes that were previously received in an
Access-Accept message.  This is cause for lots of discussion.

-----------------------------
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: Mon, 26 Jul 2004 19:49:07 +0000
Date: Mon, 26 Jul 2004 12:45:35 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: AAA WG last call on Diameter SIP Application

This is an announcement of AAA WG Last Call on the "Diameter SIP
Application" specification, prior to sending the draft on to
the IESG for consideration as an IETF Proposed Standard. The
draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-sip-app-03.txt

AAA WG Last Call will complete on August 26, 2004.  Please send
comments to the AAA WG mailing list ([email-masked]), using the
issue format described at http://www.drizzle.com/~aboba/AAA/issues.html.

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

Delivery-date: Mon, 26 Jul 2004 15:10:33 +0000
Date: Mon, 26 Jul 2004 08:07:23 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG last call on RADIUS Extension for Digest Authentication

This is an announcement of RADEXT WG Last Call on the "RADIUS Extension
for Digest Authentication" specification, prior to sending the draft on to
the IESG for consideration as an IETF Proposed Standard. The
draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt

RADEXT WG Last Call will complete on August 26, 2004.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
issue format described at http://www.drizzle.com/~aboba/AAA/issues.html.

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

Delivery-date: Mon, 26 Jul 2004 15:07:56 +0000
Date: Mon, 26 Jul 2004 08:04:10 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG last call on RFC 2486bis

This is an announcement of RADEXT WG Last Call on "The Network Access
Identifier" specification, RFC 2486bis, prior to sending the draft on to
the IESG for consideration as an IETF Proposed Standard (recycled). The
draft is available for inspection at:

http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt

RADEXT WG Last Call will complete on August 26, 2004.  Please send
comments to the RADEXT WG mailing list ([email-masked]), using the
issue format described at http://www.drizzle.com/~aboba/AAA/issues.html.

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

Delivery-date: Sun, 25 Jul 2004 23:40:16 +0000
Content-class: urn:content-classes:message
Subject: RE: Comments/questions about bandwidth draft
Date: Sun, 25 Jul 2004 16:39:41 -0700
From: "Adrangi, Farid" <[email-masked]>
To: "BOURDON Gilles RD-CORE-ISS" <[email-masked]>
Cc: <[email-masked]>

Hi Gilles,
Thanks for reading the draft and your comments.  Please see my responses
inline.
BR,
Farid

> -----Original Message-----
> From: BOURDON Gilles RD-CORE-ISS=20
> [mailto:[email-masked]]=20
> Sent: Thursday, July 22, 2004 2:43 AM
> To: Adrangi, Farid
> Cc: [email-masked]
> Subject: Comments/questions about bandwidth draft
>=20
>=20
> I have some comments and questions about the bandwidth draft:
>=20
> 1) As far as I understand, the NAS behaves differently when receiving
> invalid selection of bandwidth parameter: in push mode, a COA NAK is
> sent but nothing happens to the session, and in pull mode the user
> session is terminated.=20

Your observation is correct, but I don't think there is an inconsistency
here.  In pull mode, when the NAS advertises its bandwidth capabilities,
the AAA server is expected to do the selection within the boundary of
the advertised bandwidth parameters.  In the absence of the
advertisement, the NAS does not drop the session if it cannot honor the
"Selection" specified by the AAA server.

> I think it would be better to adopt the same
> behaviour in both cases. In the same idea, no specific behaviour is
> defined in pull mode in case the NAS cannot comply with the request
> ("resources unavailable" error cause is sent in push mode).
>=20
That would be nice - but how can we do that in the pull model after
receiving an Access-Accept? =20

> 2) Maybe the four bandwidth parameters could be aggregated in a unique
> attribute, since all are required in a message ? Or the rule can be
> loosen a little bit in allowing transmission of a composed set of
> attribute... Non present attributes could be interpreted as=20
> "default" or
> "unchanged". But maybe there is a specific explanation to=20
> this choice ?
>=20
As you are aware, we had a long discussion on this topic -- I think the
consenus was to use individual attributes but we are okay with using a
single attribute here as well.  How do you suggest we should close on
this subjet?

> 3) About the "Don't care" value, I think it requires more precision.
> Should we understand "don't care" as a infinite (line-rate)=20
> bandwidth ?
> Or a default bandwidth already set in the NAS ?
>=20
Ok.  It refers to the default bandwidth already set in the NAS -- you
are right the draft is not specific about it; will fix it.  Thanks.

> 4) In section 4, shouldn't Note 1 include Access-Accept messages, not
> only COA ?
>=20

You are right -- it should apply to both!

Again, thank you for comments and your help.

--
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, 23 Jul 2004 23:25:12 +0000
Date: Fri, 23 Jul 2004 16:22:03 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: RADEXT WG Agenda, Take Four

RADIUS Extensions WG (radext)

Monday, August 2 at 1300-1500
==============================

CHAIRS: Bernard Aboba <[email-masked]>
        David Nelson <[email-masked]>

AGENDA:

Preliminaries (15 minutes)

Bluesheets
Meeting Minutes
Agenda Bashing
Liaison Requests
   See: http://www.drizzle.com/~aboba/RADEXT/liaisons/
Issues List
Review Procedures
Document Status

Basic RADIUS work (25 minutes)

IPv6 support in the RADIUS MIBs - Bert Wijnen & David Harrington, 5 min
http://www.ietf.org/rfc/rfc2618.txt
http://www.ietf.org/rfc/rfc2619.txt
http://www.ietf.org/rfc/rfc2620.txt
http://www.ietf.org/rfc/rfc2621.txt

RFC 3576 MIBs - M. Chiba, 5 minutes
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-client-mib-01.txt
http://www.ietf.org/internet-drafts/draft-decnodder-radext-dynauth-server-mib-01.txt

EAP lower layer attribues for AAA protocols - David Mariblanca, 5 minutes
http://www.ietf.org/internet-drafts/draft-mariblanca-aaa-eap-lla-01.txt

RADIUS Management Issues - David Nelson, 5 minutes
TBD

RADIUS Security Issues - Randy Chou, 5 minutes
TBD

SIP-RADIUS (10 minutes)

Digest Authentication in RADIUS - W, Beck, 10 minutes
http://www.ietf.org/internet-drafts/draft-sterman-aaa-sip-03.txt

(W)LAN applications (20 minutes)

RFC 2486bis - Jari Arkko, 5 minutes
http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-02.txt

IEEE 802 attributes - Paul Congdon, 10 minutes
http://www.ietf.org/internet-drafts/draft-congdon-radext-ieee802-00.txt

Bandwidth Attributes - Farid Adrangi, 5 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-bandwidth-capability-01.txt

RADIUS Data Model Issues (30 minutes)

Diameter/RADIUS compatibility - Jari Arkko, 10 minutes
TBD

RADIUS attributes extension, Farid Adrangi, 10 minutes
http://www.ietf.org/internet-drafts/draft-adrangi-radius-attributes-extension-01.txt

Discussion (10 minutes)

Pre-Paid (10 minutes)

RADIUS Prepaid - Avi Lior, 10 minutes
http://www.ietf.org/internet-drafts/draft-lior-radius-extensions-for-prepaid-05.txt
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.txt

Wrap-Up (10 minutes)

--
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, 22 Jul 2004 09:44:12 +0000
Content-class: urn:content-classes:message
Subject: Comments/questions about bandwidth draft
Date: Thu, 22 Jul 2004 11:43:11 +0200
From: "BOURDON Gilles RD-CORE-ISS" <[email-masked]>
To: "Adrangi, Farid" <[email-masked]>
Cc: <[email-masked]>

I have some comments and questions about the bandwidth draft:

1) As far as I understand, the NAS behaves differently when receiving
invalid selection of bandwidth parameter: in push mode, a COA NAK is
sent but nothing happens to the session, and in pull mode the user
session is terminated. I think it would be better to adopt the same
behaviour in both cases. In the same idea, no specific behaviour is
defined in pull mode in case the NAS cannot comply with the request
("resources unavailable" error cause is sent in push mode).

2) Maybe the four bandwidth parameters could be aggregated in a unique
attribute, since all are required in a message ? Or the rule can be
loosen a little bit in allowing transmission of a composed set of
attribute... Non present attributes could be interpreted as "default" or
"unchanged". But maybe there is a specific explanation to this choice ?

3) About the "Don't care" value, I think it requires more precision.
Should we understand "don't care" as a infinite (line-rate) bandwidth ?
Or a default bandwidth already set in the NAS ?

4) In section 4, shouldn't Note 1 include Access-Accept messages, not
only COA ?

Thank you.

Gilles.

--
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, 21 Jul 2004 08:11:10 +0000
Content-class: urn:content-classes:message
Subject: Version 1 of bandwidth draft for your review
Date: Wed, 21 Jul 2004 01:10:32 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>

Hi,
I have submitted version 1 of the bandwidth draft.  It does not appear
in the ID directories yet - but here is the url to access it:

http://mng.ctgisp.com/IETF/RADIUSEXT/draft-adrangi-radius-bandwidth-capa
bility-01.txt

- Incorporated comments and feedback from Jari. Jari pointed out several
issues with the draft and helped us with Diameter aspect of the draft. =20
- Incorporated comments and feedback form Stefan.   We are still
discussing Stefan's suggestion on adding burst size and perhaps
algorithms or profile ID for handling the parameters.

BR,
Farid

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

Delivery-date: Wed, 21 Jul 2004 03:17:40 +0000
From: Avi Lior <[email-masked]>
To: Ignacio Goyret <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Redirection Draft v1 is now available for review
Date: Tue, 20 Jul 2004 23:17:13 -0400

I agree.  I basically stole these definition or this style from Diameter see
RFC3588

We could do a better job but I was hoping that if they got away with it so
could we.  But perhaps not.

Lets see what others say.

> -----Original Message-----
> From: Ignacio Goyret [mailto:[email-masked]] 
> Sent: Tuesday, July 20, 2004 7:38 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Redirection Draft v1 is now available for review
> 
> 
> At 21:35 7/20/2004 -0400, Avi Lior wrote:
> >
> >Subject: I-D ACTION:draft-lior-radius-redirection-01.txt
> 
> Avi,
> The format to be used for NAS-Filter-Rule at the top of page 
> 13 is not very clear to me from reading this doc. In 
> particular, it is not clear to me:
> - whether the words 'from' and 'to' should or should not be used
> - if the '/' character in the port spec is a character to be inserted
>   or it means alternate choices (as in 'port' or 'port-port').
> - is the '!' character allowed before port specs (to indicate
>   "everything except these ports").
> - are the "from" and "to" parts always required? Is either 
> one optional?
>   If so, is the other mandatory? (eg, if the "to" part is optional,
>   is the "from" part mandatory?)
> - which words are keywords that must be entered as is and which ones
>   are tokens.
> - for "ipoptions": is the comma-separated list an AND-condition (where
>   all the listed options must be present) or an OR-condition 
> (where any
>   of the listed options must be present). Same for "tcpoptions" and
>   "tcpflags".
> 
> Similar questions rise from reading the other rules 
> (IP-Redirection-Rule and HTTP-Redirection-Rule).
> 
> Please consider clarifying them. Examples are not necessarily 
> needed but can definitely help convey the idea.
> 
> Best regards,
> -Ignacio
> 

--
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, 21 Jul 2004 03:17:32 +0000
From: Avi Lior <[email-masked]>
To: Barney Wolff <[email-masked]>, Avi Lior <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Tue, 20 Jul 2004 23:13:43 -0400

Hi

See inline...

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Tuesday, July 20, 2004 6:16 PM
> To: Avi Lior
> Cc: Jari Arkko; Lothar Reith; [email-masked]'
> Subject: Re: AW: Privacy (Was: Re: NAI decoration: User 
> Identity issues)
> 
> 
> On Tue, Jul 20, 2004 at 08:09:18PM -0400, Avi Lior wrote:
> > In proxy scenarios a RADIUS intermediary acts as a server and a 
> > client.
> > 
> > The Intermediary (acting as a server) can *completely* re-write the 
> > username attribute as it sends the access accept message to its 
> > client.
> > 
> > The only requirement is that a Client (in this case the 
> intermediary ) 
> > replace the username that it received from it's server in the 
> > Acccounting Messages that it sends to that server.
> > 
> > Because of this behavior it is *not* guaranteed that RADIUS 
> > Intermediaries or the NAS will actually see what the home 
> network has 
> > placed in the username attribute in the access request.
> > 
> > User-Identity-Alias seperates the routing out and allows us to have 
> > cleaner solutions.
> 
> I think you're confusing IETF standards with laws of nature.  
> If an intermediary wants to conceal the user's "true" 
> identity, it will rewrite User-Identity-Alias no matter what 
> an RFC says.  For that matter, if the home server wants to 
> conceal the identity, it can put random garbage into 
> User-Identity-Alias.

Intermediary could even leave it out.  I understand this all too well.

> Surely business models depend on contracts, not just RFCs.  
> Since this is a matter of a business model, not of the 
> technical operation of RADIUS, I don't see any difference 
> between a contract that requires certain treatment of 
> User-Name in Access-Accepts vs one that requires a stable 
> medium-to-long-term User-Identity-Alias.

In the draft we have taken comments (From Nelson and others) that says that
intermediaries MUST not modify the User-Identity-Alias.

So we are trying to clean up the issues.  Cause some roaming relationships
are very complex and involve brokers etc....

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

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

Delivery-date: Wed, 21 Jul 2004 02:39:04 +0000
Date: Tue, 20 Jul 2004 19:38:06 -0700
To: Avi Lior <[email-masked]>
From: Ignacio Goyret <[email-masked]>
Subject: Re: Redirection Draft v1 is now available for review
Cc: [email-masked]

At 21:35 7/20/2004 -0400, Avi Lior wrote:
>
>Subject: I-D ACTION:draft-lior-radius-redirection-01.txt

Avi,
The format to be used for NAS-Filter-Rule at the top of page 13
is not very clear to me from reading this doc. In particular,
it is not clear to me:
- whether the words 'from' and 'to' should or should not be used
- if the '/' character in the port spec is a character to be inserted
  or it means alternate choices (as in 'port' or 'port-port').
- is the '!' character allowed before port specs (to indicate
  "everything except these ports").
- are the "from" and "to" parts always required? Is either one optional?
  If so, is the other mandatory? (eg, if the "to" part is optional,
  is the "from" part mandatory?)
- which words are keywords that must be entered as is and which ones
  are tokens.
- for "ipoptions": is the comma-separated list an AND-condition (where
  all the listed options must be present) or an OR-condition (where any
  of the listed options must be present). Same for "tcpoptions" and
  "tcpflags".

Similar questions rise from reading the other rules (IP-Redirection-Rule
and HTTP-Redirection-Rule).

Please consider clarifying them. Examples are not necessarily needed
but can definitely help convey the idea.

Best regards,
-Ignacio

--
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, 21 Jul 2004 01:35:47 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Redirection Draft v1 is now available for review
Date: Tue, 20 Jul 2004 21:35:27 -0400

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_000_01C46EC3.00871F70
Content-Type: text/plain

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2004 1:04 PM
To: [email-masked]
Subject: I-D ACTION:draft-lior-radius-redirection-01.txt

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

	Title		: Remote Authentication Dial In User Service
(RADIUS) Redirection
	Author(s)	: A. Lior, F. Adrangi
	Filename	: draft-lior-radius-redirection-01.txt
	Pages		: 25
	Date		: 2004-7-20
	
In certain scenarios there needs to be a method to force the users
   traffic to a specific location. This document describes several
   methods that are available to be used with Remote Authentication Dial
   In User Service (RADIUS) Protocol and defines three new RADIUS
   attributes: NAS-Filter-Rule, Redirect-Id and Redirect-Rule.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-redirection-01.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-lior-radius-redirection-01.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-lior-radius-redirection-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C46EC3.00871F70
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 20 Jul 2004 19:31:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C46EC3.00871F70"

------_=_NextPart_002_01C46EC3.00871F70
Content-Type: text/plain

------_=_NextPart_002_01C46EC3.00871F70
Content-Type: application/octet-stream;
	name="ATT59499.txt"
Content-Disposition: attachment;
	filename="ATT59499.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-lior-radius-redirection-01.txt

------_=_NextPart_002_01C46EC3.00871F70
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-lior-radius-redirection-01.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C46EC3.00871F70--

------_=_NextPart_000_01C46EC3.00871F70
Content-Type: text/plain;
	name="ATT59500.txt"
Content-Disposition: attachment;
	filename="ATT59500.txt"

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

------_=_NextPart_000_01C46EC3.00871F70--

--
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, 21 Jul 2004 01:35:41 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Prepaid draft v5 is available for review
Date: Tue, 20 Jul 2004 21:35:31 -0400

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_000_01C46EC3.029F9F30
Content-Type: text/plain

Hi

In this version:
-we have cleaned up the architecture to make it more vendor neutral.
-we introduce multi-services prepaid which lines up with Diameter concepts.
-addressed other issues and clean up.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, July 20, 2004 1:01 PM
To: [email-masked]
Subject: I-D ACTION:draft-lior-radius-prepaid-extensions-05.txt

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, et al.
	Filename	: draft-lior-radius-prepaid-extensions-05.txt
	Pages		: 48
	Date		: 2004-7-20
	
The draft presents an extension to the Remote Authentication Dial-In 
User Service (RADIUS) protocol to support Prepaid data services for 
a wide range of deployments such as Dial, Wireless, WLAN.  
Consideration for roaming using mobile-ip is also given.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions-05.
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-lior-radius-prepaid-extensions-05.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-lior-radius-prepaid-extensions-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

------_=_NextPart_000_01C46EC3.029F9F30
Content-Type: message/rfc822

To: 
Subject: 
Date: Tue, 20 Jul 2004 19:31:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C46EC3.029F9F30"

------_=_NextPart_002_01C46EC3.029F9F30
Content-Type: text/plain

------_=_NextPart_002_01C46EC3.029F9F30
Content-Type: application/octet-stream;
	name="ATT59428.txt"
Content-Disposition: attachment;
	filename="ATT59428.txt"

Content-type: message/external-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-lior-radius-prepaid-extensions-05.txt

------_=_NextPart_002_01C46EC3.029F9F30
Content-Type: message/external-body;
	site="internet-drafts";
	dir="draft-lior-radius-prepaid-extensions-05.txt";
	mode="ftp.ietf.org";
	access-type="anon-ftp"

------_=_NextPart_002_01C46EC3.029F9F30--

------_=_NextPart_000_01C46EC3.029F9F30
Content-Type: text/plain;
	name="ATT59429.txt"
Content-Disposition: attachment;
	filename="ATT59429.txt"

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

------_=_NextPart_000_01C46EC3.029F9F30--

--
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, 21 Jul 2004 01:15:59 +0000
Date: Tue, 20 Jul 2004 21:15:35 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Jari Arkko <[email-masked]>, Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

On Tue, Jul 20, 2004 at 08:09:18PM -0400, Avi Lior wrote:
> In proxy scenarios a RADIUS intermediary acts as a server and a client.
> 
> The Intermediary (acting as a server) can *completely* re-write the username
> attribute as it sends the access accept message to its client. 
> 
> The only requirement is that a Client (in this case the intermediary )
> replace the username that it received from it's server in the Acccounting
> Messages that it sends to that server.
> 
> Because of this behavior it is *not* guaranteed that RADIUS Intermediaries
> or the NAS will actually see what the home network has placed in the
> username attribute in the access request.
> 
> User-Identity-Alias seperates the routing out and allows us to have cleaner
> solutions.

I think you're confusing IETF standards with laws of nature.  If an
intermediary wants to conceal the user's "true" identity, it will
rewrite User-Identity-Alias no matter what an RFC says.  For that matter,
if the home server wants to conceal the identity, it can put random
garbage into User-Identity-Alias.

Surely business models depend on contracts, not just RFCs.  Since this is
a matter of a business model, not of the technical operation of RADIUS,
I don't see any difference between a contract that requires certain
treatment of User-Name in Access-Accepts vs one that requires a stable
medium-to-long-term User-Identity-Alias.

Regards,
Barney

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

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

Delivery-date: Wed, 21 Jul 2004 00:10:03 +0000
From: Avi Lior <[email-masked]>
To: Barney Wolff <[email-masked]>, Jari Arkko <[email-masked]>
Cc: Lothar Reith <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Tue, 20 Jul 2004 20:09:18 -0400

In proxy scenarios a RADIUS intermediary acts as a server and a client.

The Intermediary (acting as a server) can *completely* re-write the username
attribute as it sends the access accept message to its client. 

The only requirement is that a Client (in this case the intermediary )
replace the username that it received from it's server in the Acccounting
Messages that it sends to that server.

Because of this behavior it is *not* guaranteed that RADIUS Intermediaries
or the NAS will actually see what the home network has placed in the
username attribute in the access request.

User-Identity-Alias seperates the routing out and allows us to have cleaner
solutions.

--
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, 21 Jul 2004 00:09:56 +0000
From: Avi Lior <[email-masked]>
To: Lothar Reith <[email-masked]>, 'Bernard Aboba' <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Tue, 20 Jul 2004 20:09:19 -0400

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_01C46EB6.F7F94BF0
Content-Type: text/plain

Lothar and all,
 
In the draft we call this attribute  User Identity Alias.  This makes it
billing nautral.
 
As well there maybe more then one use for this attribute.
 
 Lothar wrote:  Please note that I meanwhile would propose to refer to the
new attribute which we are discussing as "accountable-identity".  

 

------_=_NextPart_001_01C46EB6.F7F94BF0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1400" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=891394423-20072004><FONT face=Arial color=#0000ff size=2>Lothar 
and all,</FONT></SPAN></DIV>
<DIV><SPAN class=891394423-20072004><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=891394423-20072004><FONT face=Arial color=#0000ff size=2>In the 
draft we call this attribute&nbsp; User Identity Alias.&nbsp; This makes it 
billing nautral.</FONT></SPAN></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=891394423-20072004><FONT 
face=Arial color=#0000ff></FONT></SPAN></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN class=891394423-20072004><FONT 
face=Arial color=#0000ff>As well there maybe&nbsp;more then one use for this 
attribute.</FONT></SPAN></FONT></FONT></DIV>
<DIV><FONT face=Tahoma><FONT size=2><SPAN 
class=891394423-20072004>&nbsp;</SPAN></FONT></FONT></DIV>
<DIV><FONT size=2><SPAN class=891394423-20072004><FONT face=Arial 
color=#0000ff>&nbsp;Lothar wrote: &nbsp;</FONT></SPAN>Please note that I 
meanwhile would propose to refer to the new attribute which we are discussing as 
"accountable-identity".&nbsp;<SPAN class=891394423-20072004><FONT face=Arial 
color=#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=891394423-20072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT size=2><SPAN class=891394423-20072004>&nbsp;</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=891394423-20072004></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV></BODY></HTML>

------_=_NextPart_001_01C46EB6.F7F94BF0--

--
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, 20 Jul 2004 15:41:05 +0000
Date: Tue, 20 Jul 2004 11:40:41 -0400
From: Barney Wolff <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Lothar Reith <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

On Tue, Jul 20, 2004 at 02:03:50PM +0300, Jari Arkko wrote:
> 
> And I didn't mean to imply that Klaas' requirement is bad either.
> I'm just trying to collect possible requirements, and the tracking
> requirement is reasonable enough to be considered -- though it may well
> be that the privacy requirements conflict with it or that there's
> no need for a real-time real-identity tracking. More discussion
> is needed on that.

If a persistent alias is not required, an abusive user can be
identified via Acct-Session-Id, provided of course that the user's
home auth server also gets acct requests and stores them.

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

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

Delivery-date: Tue, 20 Jul 2004 11:09:21 +0000
Date: Tue, 20 Jul 2004 14:03:50 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Lothar Reith <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

Lothar Reith wrote:

> please note that there appears to be a serious misunderstanding of my 
> statements.
> 
> In no way did I propose anything that would compromise privacy - in the 
> opposite I am proposing that the attribute 
> "privacy-protected-identity"/"billable identity"/"user-alias" may be 
> considered *essential* to enable privacy by means of using an anonymous 
> NAI for routing the authentication request and a billable-identity only 
> resolvable by the home network  for accounting.

(snip)

> I never stated what you linked with my name:
> 
> "Get the user's "trackable" identity for the access
>     network so that fraudulent users can be tracked down and
>     acted upon without involving home operator (possibly in
>     another timezone and government etc)."
> 
> The opposite is true:   Provide a 
> "billable-identity"/"privacy-protected-identity"  which on one hand does 
> not allow any tracking by any intermediary or access-network under 
> normal circumstances, but on the other hand allows billing (normal 
> circumstances) and - in case of abuse, i.e. in rare circumstances  - 
> tracking down the abusive user.
> 
> I suggested the use of the billing-identity attribute for "tracking" in 
> response to the requirement stated by Klaas Wierenga:
> 
> "Some universities want to know the real identity of a user in case of 
> abuse" which he made in the context of the following NAI: 
> "[email-masked]"  which implies that the NAI can not be used 
> for this purpose.
> 
> The point is, that I do not beleive that these universities require the 
> real identity "in real time" - rather I assume it would be perfectly 
> sufficient to be able to track down the real identity of an abusive 
> anonymous user after the fact of abuse. In this case, the university 
> would have to request the resolution of the anonymous user-name from the 
> home network providing evidence that the request is legitimate.

Ok. Sorry for mixing up who said what. What you say above about
non-real-time does make sense to me.

And I didn't mean to imply that Klaas' requirement is bad either.
I'm just trying to collect possible requirements, and the tracking
requirement is reasonable enough to be considered -- though it may well
be that the privacy requirements conflict with it or that there's
no need for a real-time real-identity tracking. More discussion
is needed on that.

--Jari

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

Delivery-date: Mon, 19 Jul 2004 12:36:48 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Mon, 19 Jul 2004 13:36:16 +0100

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_01C46D8C.FC4FC312
Content-Type: text/plain

Bernard,

let me answer your question if username-rewrite could do the job as follows:

context (lothar wrote)
> "privacy-protected-identity", which - when present - is used instead 
> of the NAI for all kinds of purposes normally the NAI is used for, 
> including billing, re-authorization, abuse tracking etc.

Bernhard wrote:
Can't that function be handled by sending a User-Name attribute in the
Access-Accept?  Why would another attribute be needed?

Lothar responds:
I think the answer lies in Blair Bullocks mail in the below appendix.

Blair's mail has led me to believe that username rewrite may not be suitable
in all cases. Also, it would be less overloading of the NAI and therefore
more expandable if we introduce a "privacy protected identity" which can be
uses as "billable identity" as well, compared to overloading the already
overloaded NAI even more (with privacy feature).

This should allow more flexibility by virtue of being able to separate the
"routing" function of the NAI from the "accountability" function which for
privacy purposes may be "hidden" and home-resolvable only. 

Please note that I meanwhile would propose to refer to the new attribute
which we are discussing as "accountable-identity". This attribute name is
IMHO more suitable than "billing-identity", as it also includes the notion
of a malicious user being held accountable for abuse, even if no accounting
is taking place for billing purposes, just logging of RADIUS accounting
messages for abuse trackability purposes. It also covers the
"privacy-protected-identity" as even though the identity is privacy
protected, it is still accountable - but not without cooperation of the home
network which may not be willing to share the true identity with all access
networks and intermediaries. 

Best Regards, Lothar

Appendix:

Blair Bullock wrote on 15.7.2004
"The routing is done based on the realm and/or prefix/suffix used for NAI
decoration.  In the context of conveying a billable identity, the
UserName(1) rewrite does not have to impact the realm or prefix/suffix parts
of the decorated NAI.  For example, if the AAA server receives UserName
value [email-masked] in the Access-Request, the AAA server can convey
the billable identity via UserName (1) rewrite like [email-masked] , where
2345 is the billable identity.  This should cause the accounting packets
follow the same path as the authorization. "

Assumes that all routing is suffix based in a direct peer-to-peer
relationship.  We don't route every domain to every other domain.  The
constant realm add/remove process is a total nightmare!  Therefore a chained
suffix or prefix is typically used to aggregate unknown suffixes under a
roaming agency:

user@[email-masked]
Or
IPASS/[email-masked]

Either way, if the Access-Accept returns User-Name=[email-masked] and
the accounting is re-written with this User-Name value, it will not route to
the proper AAA exchange.  

To reiterate some from my last email:

1- maintaining the re-decoration of the User-Name of the Access-Accept
User-Name by the intermediary proxy requires statefulness of all AAA events.
2- To have the Access-Accept username return the decorated NAI from the Home
AS requires knowledge of the aggregation principles (suffix or
prefix) and provisioning of that information at the Home Authentication
Server so it will normalize the user-name and won't mess-up local requests.
(not to mention what if the Home Network uses multiple aggregators with
different aggregation suffixes and/or prefix). 3 - To route via suffix only
with a root NAI as per the RFC user@realm requires realm add/deletes ad
nauseum from now until the end of time.  A reseller adds a new enterprise
realm and we have to update every RADIUS proxy in the system to tell them it
should be routed to our exchange?! When you have hundreds of networks it is
untenable.  Also, what if that realm can be routed via multiple
intermediaries?!  

Thus the intermediary decoration of user@[email-masked] or
user@[email-masked] (or IPASS/[email-masked] or even
IPASS/[email-masked]@reseller.com) is necessary to address these
footprint aggregation, routing, reselling and billable user resolution
requirements for roaming.  Prefixes and suffix chains serve a very valid
business functions.  NAI decoration must be inclusive of all service models
and is primarily used to eliminate the constant ongoing provisioning
requirements of direct suffix peering.  User@realm is too simplistic and
doesn't reflect all of the business models that have emerged in our space
over the past eight years.

On a side note, what if the inner method authentication simply uses "john"
with no suffix in the user-name?  Accounting will be re-written as just
"john" and it will not route at all, even if there is a direct suffix
relationship between two networks.

Position swapping of any NAI element is right-out bad.

Blair

------_=_NextPart_001_01C46D8C.FC4FC312
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Re: Privacy (Was: Re: NAI decoration: User Identity =
issues)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>let me answer your question if username-rewrite could =
do the job as follows:</FONT>
</P>

<P><FONT SIZE=3D2>context (lothar wrote)</FONT>
<BR><FONT SIZE=3D2>&gt; &quot;privacy-protected-identity&quot;, which - =
when present - is used instead </FONT>
<BR><FONT SIZE=3D2>&gt; of the NAI for all kinds of purposes normally =
the NAI is used for, </FONT>
<BR><FONT SIZE=3D2>&gt; including billing, re-authorization, abuse =
tracking etc.</FONT>
</P>

<P><FONT SIZE=3D2>Bernhard wrote:</FONT>
<BR><FONT SIZE=3D2>Can't that function be handled by sending a =
User-Name attribute in the Access-Accept?&nbsp; Why would another =
attribute be needed?</FONT></P>

<P><FONT SIZE=3D2>Lothar responds:</FONT>
<BR><FONT SIZE=3D2>I think the answer lies in Blair Bullocks mail in =
the below appendix.</FONT>
</P>

<P><FONT SIZE=3D2>Blair's mail has led me to believe that username =
rewrite may not be suitable in all cases. Also, it would be less =
overloading of the NAI and therefore more expandable if we introduce a =
&quot;privacy protected identity&quot; which can be uses as =
&quot;billable identity&quot; as well, compared to overloading the =
already overloaded NAI even more (with privacy feature).</FONT></P>

<P><FONT SIZE=3D2>This should allow more flexibility by virtue of being =
able to separate the &quot;routing&quot; function of the NAI from the =
&quot;accountability&quot; function which for privacy purposes may be =
&quot;hidden&quot; and home-resolvable only. </FONT></P>

<P><FONT SIZE=3D2>Please note that I meanwhile would propose to refer =
to the new attribute which we are discussing as =
&quot;accountable-identity&quot;. This attribute name is IMHO more =
suitable than &quot;billing-identity&quot;, as it also includes the =
notion of a malicious user being held accountable for abuse, even if no =
accounting is taking place for billing purposes, just logging of RADIUS =
accounting messages for abuse trackability purposes. It also covers the =
&quot;privacy-protected-identity&quot; as even though the identity is =
privacy protected, it is still accountable - but not without =
cooperation of the home network which may not be willing to share the =
true identity with all access networks and intermediaries. </FONT></P>
<BR>

<P><FONT SIZE=3D2>Best Regards, Lothar</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Appendix:</FONT>
</P>

<P><FONT SIZE=3D2>Blair Bullock wrote on 15.7.2004</FONT>
<BR><FONT SIZE=3D2>&quot;The routing is done based on the realm and/or =
prefix/suffix used for NAI decoration.&nbsp; In the context of =
conveying a billable identity, the</FONT></P>

<P><FONT SIZE=3D2>UserName(1) rewrite does not have to impact the realm =
or prefix/suffix parts of the decorated NAI.&nbsp; For example, if the =
AAA server receives UserName value [email-masked] in the =
Access-Request, the AAA server can convey the billable identity via =
UserName (1) rewrite like [email-masked] , where 2345 is the billable =
identity.&nbsp; This should cause the accounting packets follow the =
same path as the authorization. &quot;</FONT></P>

<P><FONT SIZE=3D2>Assumes that all routing is suffix based in a direct =
peer-to-peer relationship.&nbsp; We don't route every domain to every =
other domain.&nbsp; The constant realm add/remove process is a total =
nightmare!&nbsp; Therefore a chained suffix or prefix is typically used =
to aggregate unknown suffixes under a roaming agency:</FONT></P>

<P><FONT SIZE=3D2>user@[email-masked]</FONT>
<BR><FONT SIZE=3D2>Or</FONT>
<BR><FONT SIZE=3D2>IPASS/[email-masked]</FONT>
</P>

<P><FONT SIZE=3D2>Either way, if the Access-Accept returns =
User-Name=[email-masked] and the accounting is re-written with =
this User-Name value, it will not route to the proper AAA =
exchange.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>To reiterate some from my last email:</FONT>
</P>

<P><FONT SIZE=3D2>1- maintaining the re-decoration of the User-Name of =
the Access-Accept User-Name by the intermediary proxy requires =
statefulness of all AAA events.</FONT></P>

<P><FONT SIZE=3D2>2- To have the Access-Accept username return the =
decorated NAI from the Home AS requires knowledge of the aggregation =
principles (suffix or</FONT></P>

<P><FONT SIZE=3D2>prefix) and provisioning of that information at the =
Home Authentication Server so it will normalize the user-name and won't =
mess-up local requests. (not to mention what if the Home Network uses =
multiple aggregators with different aggregation suffixes and/or =
prefix). 3 - To route via suffix only with a root NAI as per the RFC =
user@realm requires realm add/deletes ad nauseum from now until the end =
of time.&nbsp; A reseller adds a new enterprise realm and we have to =
update every RADIUS proxy in the system to tell them it should be =
routed to our exchange?! When you have hundreds of networks it is =
untenable.&nbsp; Also, what if that realm can be routed via multiple =
intermediaries?!&nbsp; </FONT></P>

<P><FONT SIZE=3D2>Thus the intermediary decoration of =
user@[email-masked] or user@[email-masked] (or =
IPASS/[email-masked] or even</FONT></P>

<P><FONT SIZE=3D2>IPASS/[email-masked]@reseller.com) is necessary =
to address these footprint aggregation, routing, reselling and billable =
user resolution requirements for roaming.&nbsp; Prefixes and suffix =
chains serve a very valid business functions.&nbsp; NAI decoration must =
be inclusive of all service models and is primarily used to eliminate =
the constant ongoing provisioning requirements of direct suffix =
peering.&nbsp; User@realm is too simplistic and doesn't reflect all of =
the business models that have emerged in our space over the past eight =
years.</FONT></P>

<P><FONT SIZE=3D2>On a side note, what if the inner method =
authentication simply uses &quot;john&quot; with no suffix in the =
user-name?&nbsp; Accounting will be re-written as just &quot;john&quot; =
and it will not route at all, even if there is a direct suffix =
relationship between two networks.</FONT></P>

<P><FONT SIZE=3D2>Position swapping of any NAI element is right-out =
bad.</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C46D8C.FC4FC312--

--
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, 19 Jul 2004 09:10:02 +0000
Date: Mon, 19 Jul 2004 11:09:45 +0200
From: Klaas Wierenga <[email-masked]>
To: Lothar Reith <[email-masked]>
CC: "[email-masked]'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

Hi Lothar,

> I suggested the use of the billing-identity attribute for "tracking" in 
> response to the requirement stated by Klaas Wierenga:
> 
> "Some universities want to know the real identity of a user in case of 
> abuse" which he made in the context of the following NAI: 
> "[email-masked]"  which implies that the NAI can not be used 
> for this purpose.
> 
> The point is, that I do not beleive that these universities require the 
> real identity "in real time" - rather I assume it would be perfectly 
> sufficient to be able to track down the real identity of an abusive 
> anonymous user after the fact of abuse. In this case, the university 
> would have to request the resolution of the anonymous user-name from the 
> home network providing evidence that the request is legitimate.

Actually, currently this is exactly the path we are following. We have a 
  project (http://www.sourceforge.net/projects/usertracking) that tries 
to gather all the relevant data to do this. And I agree completely with 
you that this is in general the desired behaviour. However I believe 
there are 2 buts:

- Sometimes you do want to track down realtime the abusive user, if some 
user from university-a is sending lots of spam via university-b, are you 
going to shutdown all users from university-a (since they are all 
anonymous@university-a to university-b) or just badguy@university-a? 
Just as a user has the right to only connect via a provider that guards 
their privacy I believe a visited institution should have the right to 
refuse anonymous users, it's after all their infrastructure they are 
giving access too.

- Universities or other entities may be in some kind of federation where 
they agree to share user data with eachother. Either the low level 
attributes of a user or some aggregated form of it.

As I mentioned before, I am not sure whether this kind of authorisation 
should be carried on this layer or on some other like EAP. I think 
however that there is value in giving the *possibility* to reveal the 
real identity of a user, this 'real identiy' may also be some kind of 
pseudonymous id, but it is useful to be able to distinguish individual 
users.

> 
> In my mind, the real problem is to find the right balance between the 
> valid privacy and security requirements of the user, and the valid 
> privacy and security requirements of the home-network povider, the 
> intermediaries, the access provider and the Internet at large.

agreed

> A privacy conscious user may contract only with a home-network that 
> cares about privacy and resolves his true identity only to a legimitate 
> requester providing strong evidence of abuse and of course only on the 
> basis of local legislation of the home network anyway.
> 
> By the way: A privacy conscious home-network provider may not want to 
> expose his customer's clear-text user-names to access-networks and 
> intermediaries.

Yes, within the TERENA (the 'club' of european research and education 
networks) Taskforce Mobility (http://www.terena.nl/mobility) we try to 
do this by defining policies for the european toplevel RADIUS-server, 
the country level toplevel server and the institutional RADIUS-servers. 
Here we try to state what users can expect and also what 1 NREN can 
expect from the other NRENs.

> 
> In a nutshell, my proposal was actually aimed at avoiding the below 
> cited horror scenario that Jari has put in the context of my name (much 
> to my dislike):

Actually I'm trying to do the same. I have noticed that candidate 
participants to this hierarchy often are afraid they lack the tools to 
exclude abusive users/institutions and countries. By providing them the 
tools to exclude whoever they feel like the reality is that they don't 
bother to take any of these measures, just having the tools is enough 
insurance.

Klaas

--
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, 19 Jul 2004 08:28:09 +0000
From: "Lothar Reith" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Mon, 19 Jul 2004 09:27:14 +0100

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_01C46D6A.32231A3E
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Jari,

please note that there appears to be a serious misunderstanding of my
statements.=20

In no way did I propose anything that would compromise privacy - in the
opposite I am proposing that the attribute
"privacy-protected-identity"/"billable identity"/"user-alias" may be
considered *essential* to enable privacy by means of using an anonymous =
NAI
for routing the authentication request and a billable-identity only
resolvable by the home network  for accounting.

I never stated what you linked with my name:

"Get the user's "trackable" identity for the access
    network so that fraudulent users can be tracked down and
    acted upon without involving home operator (possibly in
    another timezone and government etc)."

The opposite is true:   Provide a
"billable-identity"/"privacy-protected-identity"  which on one hand =
does not
allow any tracking by any intermediary or access-network under normal
circumstances, but on the other hand allows billing (normal =
circumstances)
and - in case of abuse, i.e. in rare circumstances  - tracking down the
abusive user.

I suggested the use of the billing-identity attribute for "tracking" in
response to the requirement stated by Klaas Wierenga:
"Some universities want to know the real identity of a user in case of
abuse" which he made in the context of the following NAI:
"[email-masked]"  which implies that the NAI can not be used =
for
this purpose.

The point is, that I do not beleive that these universities require the =
real
identity "in real time" - rather I assume it would be perfectly =
sufficient
to be able to track down the real identity of an abusive anonymous user
after the fact of abuse. In this case, the university would have to =
request
the resolution of the anonymous user-name from the home network =
providing
evidence that the request is legitimate.

In my mind, the real problem is to find the right balance between the =
valid
privacy and security requirements of the user, and the valid privacy =
and
security requirements of the home-network povider, the intermediaries, =
the
access provider and the Internet at large.
=20
A privacy conscious user may contract only with a home-network that =
cares
about privacy and resolves his true identity only to a legimitate =
requester
providing strong evidence of abuse and of course only on the basis of =
local
legislation of the home network anyway.

By the way: A privacy conscious home-network provider may not want to =
expose
his customer's clear-text user-names to access-networks and =
intermediaries.

In a nutshell, my proposal was actually aimed at avoiding the below =
cited
horror scenario that Jari has put in the context of my name (much to my
dislike):
  =20
Jari wrote start:
>    No hotspot access in the Big Brother
>    Republic unless your home ISP sends your passport number,
>   snail address, and biometric data in an Access-Accept. Hmm...
>    I think we are going to get here sooner or later :-(=20
Jari wrote end.

Business reality appears to me to be very different: The home-network =
may
NOT want to provide any resolvable identity data, because they may be =
afraid
that someone else in the food-chain could steal their customer.

Best Regards, Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =
Im
Auftrag von Jari Arkko
Gesendet: Freitag, 16. Juli 2004 20:27
An: Bernard Aboba
Cc: [email-masked]'
Betreff: Re: Privacy (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

> It seems like everyone is seeing a different application for the=20
> attribute
> -- and that is why it is so hard to come to agreement on the problem
> statement.

Right. I think we have seen the following applications
or individual requirements:

1. Lothar: Get the user's "trackable" identity for the access
    network so that fraudulent users can be tracked down and
    acted upon without involving home operator (possibly in
    another timezone and government etc).

    Note 1: This requires some sort of real identity, just
    stable but opaque identifier would be insufficient. Or
    its sufficient for denying further service, but not for
    taking some action against the user.

    Note 2: I'm not sure I want to think about the privacy
    implications of this. No hotspot access in the Big Brother
    Republic unless your home ISP sends your passport number,
    snail address, and biometric data in an Access-Accept. Hmm...
    I think we are going to get here sooner or later :-(

2. Avi: Controlling a policy for the user, such as limits
    on the number of simultaneous sessions per user.

    Note 3: This is only useful if the home network's policy
    is different from the access network's policy. For instance,
    home network has unlimited access while access network
    allows at most one access at a time.

    Note 4: Even if the policies are different, home networks
    could still apply the policy on a per-visited network
    basis. This could be problematic for provisioning,
    however.

    Note 5: Even if the access network applies the policy,
    it has no guarantee that the identity given to it is
    correct. A fraudulent home network could claim that
    all sessions come from a different user, whereas in
    reality they actually are from one user. Does this
    matter?

3. Farid: Retrieve real identity when tunneled or
    pseudonym-based EAP methods are used.

4. Blair: Correlate accounting records with
    an identifier so that fixed price
    billing models can be applied at a service
    provider.

    Note 6: This requires a stable (~ month)
    identity, but it does not have to be a "real"
    identity. Compare to requirement 1!

5. Farid: Provide a new format to carry non-NAI
    identities, such as IMSI or E.164 numbers.

6. Farid: Provide an alternate, second identifier
    in addition to the NAI.

    Note 7: I am presuming that this is a requirement.
    Is it?

7. Jari: Carry a privacy-protected "handle" instead
    of the "real" identity when returning User-Name/
    Class/User-Alias.

Anything else?

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

------_=_NextPart_001_01C46D6A.32231A3E
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.2656.31">
<TITLE>AW: Privacy (Was: Re: NAI decoration: User Identity =
issues)</TITLE>
</HEAD>
<BODY>

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

<P><FONT SIZE=3D2>please note that there appears to be a serious =
misunderstanding of my statements. </FONT>
</P>

<P><FONT SIZE=3D2>In no way did I propose anything that would =
compromise privacy - in the opposite I am proposing that the attribute =
&quot;privacy-protected-identity&quot;/&quot;billable =
identity&quot;/&quot;user-alias&quot; may be considered *essential* to =
enable privacy by means of using an anonymous NAI for routing the =
authentication request and a billable-identity only resolvable by the =
home network&nbsp; for accounting.</FONT></P>

<P><FONT SIZE=3D2>I never stated what you linked with my name:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Get the user's &quot;trackable&quot; identity =
for the access</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; network so that fraudulent users =
can be tracked down and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; acted upon without involving home =
operator (possibly in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; another timezone and government =
etc).&quot;</FONT>
</P>

<P><FONT SIZE=3D2>The opposite is true:&nbsp;&nbsp; Provide a =
&quot;billable-identity&quot;/&quot;privacy-protected-identity&quot;&nbs=
p; which on one hand does not allow any tracking by any intermediary or =
access-network under normal circumstances, but on the other hand allows =
billing (normal circumstances) and - in case of abuse, i.e. in rare =
circumstances&nbsp; - tracking down the abusive user.</FONT></P>

<P><FONT SIZE=3D2>I suggested the use of the billing-identity attribute =
for &quot;tracking&quot; in response to the requirement stated by Klaas =
Wierenga:</FONT></P>

<P><FONT SIZE=3D2>&quot;Some universities want to know the real =
identity of a user in case of abuse&quot; which he made in the context =
of the following NAI: &quot;[email-masked]&quot;&nbsp; which =
implies that the NAI can not be used for this purpose.</FONT></P>

<P><FONT SIZE=3D2>The point is, that I do not beleive that these =
universities require the real identity &quot;in real time&quot; - =
rather I assume it would be perfectly sufficient to be able to track =
down the real identity of an abusive anonymous user after the fact of =
abuse. In this case, the university would have to request the =
resolution of the anonymous user-name from the home network providing =
evidence that the request is legitimate.</FONT></P>

<P><FONT SIZE=3D2>In my mind, the real problem is to find the right =
balance between the valid privacy and security requirements of the =
user, and the valid privacy and security requirements of the =
home-network povider, the intermediaries, the access provider and the =
Internet at large.</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>A privacy conscious user may contract only with a =
home-network that cares about privacy and resolves his true identity =
only to a legimitate requester providing strong evidence of abuse and =
of course only on the basis of local legislation of the home network =
anyway.</FONT></P>

<P><FONT SIZE=3D2>By the way: A privacy conscious home-network provider =
may not want to expose his customer's clear-text user-names to =
access-networks and intermediaries.</FONT></P>

<P><FONT SIZE=3D2>In a nutshell, my proposal was actually aimed at =
avoiding the below cited horror scenario that Jari has put in the =
context of my name (much to my dislike):</FONT></P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>Jari wrote start:</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; No hotspot access in the Big =
Brother</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; Republic unless your home ISP =
sends your passport number,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp; snail address, and biometric data =
in an Access-Accept. Hmm...</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp; I think we are going to get =
here sooner or later :-( </FONT>
<BR><FONT SIZE=3D2>Jari wrote end.</FONT>
</P>

<P><FONT SIZE=3D2>Business reality appears to me to be very different: =
The home-network may NOT want to provide any resolvable identity data, =
because they may be afraid that someone else in the food-chain could =
steal their customer.</FONT></P>

<P><FONT SIZE=3D2>Best Regards, Lothar</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
<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>] Im Auftrag von Jari Arkko</FONT>
<BR><FONT SIZE=3D2>Gesendet: Freitag, 16. Juli 2004 20:27</FONT>
<BR><FONT SIZE=3D2>An: Bernard Aboba</FONT>
<BR><FONT SIZE=3D2>Cc: [email-masked]'</FONT>
<BR><FONT SIZE=3D2>Betreff: Re: Privacy (Was: Re: NAI decoration: User =
Identity issues)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Bernard Aboba wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; It seems like everyone is seeing a different =
application for the </FONT>
<BR><FONT SIZE=3D2>&gt; attribute</FONT>
<BR><FONT SIZE=3D2>&gt; -- and that is why it is so hard to come to =
agreement on the problem</FONT>
<BR><FONT SIZE=3D2>&gt; statement.</FONT>
</P>

<P><FONT SIZE=3D2>Right. I think we have seen the following =
applications</FONT>
<BR><FONT SIZE=3D2>or individual requirements:</FONT>
</P>

<P><FONT SIZE=3D2>1. Lothar: Get the user's &quot;trackable&quot; =
identity for the access</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; network so that fraudulent users =
can be tracked down and</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; acted upon without involving home =
operator (possibly in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; another timezone and government =
etc).</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 1: This requires some sort of =
real identity, just</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; stable but opaque identifier =
would be insufficient. Or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; its sufficient for denying =
further service, but not for</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; taking some action against the =
user.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 2: I'm not sure I want to =
think about the privacy</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; implications of this. No hotspot =
access in the Big Brother</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Republic unless your home ISP =
sends your passport number,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; snail address, and biometric data =
in an Access-Accept. Hmm...</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; I think we are going to get here =
sooner or later :-(</FONT>
</P>

<P><FONT SIZE=3D2>2. Avi: Controlling a policy for the user, such as =
limits</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; on the number of simultaneous =
sessions per user.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 3: This is only useful if the =
home network's policy</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; is different from the access =
network's policy. For instance,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; home network has unlimited access =
while access network</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; allows at most one access at a =
time.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 4: Even if the policies are =
different, home networks</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; could still apply the policy on a =
per-visited network</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; basis. This could be problematic =
for provisioning,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; however.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 5: Even if the access network =
applies the policy,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; it has no guarantee that the =
identity given to it is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; correct. A fraudulent home =
network could claim that</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; all sessions come from a =
different user, whereas in</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; reality they actually are from =
one user. Does this</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; matter?</FONT>
</P>

<P><FONT SIZE=3D2>3. Farid: Retrieve real identity when tunneled =
or</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; pseudonym-based EAP methods are =
used.</FONT>
</P>

<P><FONT SIZE=3D2>4. Blair: Correlate accounting records with</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; an identifier so that fixed =
price</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; billing models can be applied at =
a service</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; provider.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 6: This requires a stable (~ =
month)</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; identity, but it does not have to =
be a &quot;real&quot;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; identity. Compare to requirement =
1!</FONT>
</P>

<P><FONT SIZE=3D2>5. Farid: Provide a new format to carry =
non-NAI</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; identities, such as IMSI or E.164 =
numbers.</FONT>
</P>

<P><FONT SIZE=3D2>6. Farid: Provide an alternate, second =
identifier</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; in addition to the NAI.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Note 7: I am presuming that this =
is a requirement.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Is it?</FONT>
</P>

<P><FONT SIZE=3D2>7. Jari: Carry a privacy-protected &quot;handle&quot; =
instead</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; of the &quot;real&quot; identity =
when returning User-Name/</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Class/User-Alias.</FONT>
</P>

<P><FONT SIZE=3D2>Anything else?</FONT>
</P>

<P><FONT SIZE=3D2>--Jari</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_01C46D6A.32231A3E--

--
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, 17 Jul 2004 14:40:40 +0000
Date: Sat, 17 Jul 2004 07:37:58 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

> But since they do exist, we are not going to do extensions that
> break backwards compatibility without a very good reason. This
> I believe is independent of any potential attempts to extend
> the data model: data model extensions, if any, would only apply
> to new attributes.

Right.  There is a proposal on the table to provide a well-defined data
model (including sub-attribute support) within an extended attribute
space, whose use will be explicitly negotiated between the RADIUS client
and server.  However, the charter explicitly forbids any non-backward
compatible changes within the standard RADIUS attribute space.

--
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, 17 Jul 2004 10:07:04 +0000
Date: Sat, 17 Jul 2004 13:01:29 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Subject: naibis-02

Hi,

I have submitted the -02 version of my draft,
draft-arkko-roamops-rfc2486bis-02.txt.

Here's the draft and the diff:

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

There is only one modification: Per Farid's request it
is now clarified that the '!' syntax can be applied
multiple times. No one seems to need more than one '!'
but it is actually hard to limit this given that the
rest of the username should be opaque to the intermediary.

We have also had a discussion of whether the User-Name
attribute coming back in an Access-Accept should get
the reverse conversion. Based on the input on the list,
I currently don't see a lot of support for this so I
decided to leave it out. But we could discuss it at
IETF 60.

--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, 16 Jul 2004 20:01:23 +0000
Date: Fri, 16 Jul 2004 16:00:46 -0400
From: Barney Wolff <[email-masked]>
To: Jari Arkko <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues)

On Fri, Jul 16, 2004 at 08:57:12PM +0300, Jari Arkko wrote:
> 
> Perhaps the answer lies in the definition of the
> business model. Is it
> 
>   (a) Access provider MUST present a fixed cost bill
>       per user per month, and MUST ensure that a given
>       user is logged on at most once at any given time.

Let me ask the standard security question:  What's the threat model?

If the fear is that the intermediary's customer itself may cheat,
by trying to get away with paying for fewer users than it actually
has, the business model is non-viable, because the customer's server
can keep track of how many simultaneous sessions there are and
generate fake User-Aliases user0001, user0002 etc.

So we decide to trust the customer's server.  But in that case, we may
just as well rely on having the server rewrite User-Name in the Accept,
as the only risk is that the server will fake the realm.  But such
fakery can be detected by the intermediary, because it's capable of
logging both the request and the accept, or even doing a real-time check.

As a side note, since detection of session-end is not always
completely reliable (modems can be slow to drop DCD, and similar
issues apply to newer access technologies or (heaven forfend!) the
NAS may silently die) limiting the user to at most 1 simultaneous
login can generate annoyance and/or help-desk calls on false
positives.  A brilliant product-line manager at the ISP with which
I was once associated changed the limit to two, which made that
problem disappear without reducing protection against massive abuse.

-- 
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, 16 Jul 2004 19:24:39 +0000
content-class: urn:content-classes:message
Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 12:21:10 -0700
From: "Roy Albert" <[email-masked]>
To: [email-masked]
cc: [email-masked]

We do this today as an intermediary. The home networks are mostly
enterprises and have no facilities for doing this.=20

-Roy

Roy D. Albert
[email-masked]
=20

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]=20
Sent: Friday, July 16, 2004 11:48 AM
To: Roy Albert
Cc: [email-masked]
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)

Thanks. Would this be done by the home networks or the
intermediaries? Are you willing to say if something
like this is currently done in your organization,
acting as an intermediary?

--Jari

Roy Albert wrote:
> In the case where someone's credentials have been compromised, it is
> necessary to have a unique per-user identifier to help detect this
(much
> as credit card companies do) by monitoring for unusual activity. This
is
> not quite covered by your points below.
>=20
> -Roy
>=20
> Roy D. Albert
> [email-masked]
> =20
>=20
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]=20
> Sent: Friday, July 16, 2004 11:27 AM
> To: Bernard Aboba
> Cc: [email-masked]'
> Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)
>=20
> Bernard Aboba wrote:
>=20
>=20
>>It seems like everyone is seeing a different application for the
>=20
> attribute
>=20
>>-- and that is why it is so hard to come to agreement on the problem
>>statement.
>=20
>=20
> Right. I think we have seen the following applications
> or individual requirements:
>=20
> 1. Lothar: Get the user's "trackable" identity for the access
>     network so that fraudulent users can be tracked down and
>     acted upon without involving home operator (possibly in
>     another timezone and government etc).
>=20
>     Note 1: This requires some sort of real identity, just
>     stable but opaque identifier would be insufficient. Or
>     its sufficient for denying further service, but not for
>     taking some action against the user.
>=20
>     Note 2: I'm not sure I want to think about the privacy
>     implications of this. No hotspot access in the Big Brother
>     Republic unless your home ISP sends your passport number,
>     snail address, and biometric data in an Access-Accept. Hmm...
>     I think we are going to get here sooner or later :-(
>=20
> 2. Avi: Controlling a policy for the user, such as limits
>     on the number of simultaneous sessions per user.
>=20
>     Note 3: This is only useful if the home network's policy
>     is different from the access network's policy. For instance,
>     home network has unlimited access while access network
>     allows at most one access at a time.
>=20
>     Note 4: Even if the policies are different, home networks
>     could still apply the policy on a per-visited network
>     basis. This could be problematic for provisioning,
>     however.
>=20
>     Note 5: Even if the access network applies the policy,
>     it has no guarantee that the identity given to it is
>     correct. A fraudulent home network could claim that
>     all sessions come from a different user, whereas in
>     reality they actually are from one user. Does this
>     matter?
>=20
> 3. Farid: Retrieve real identity when tunneled or
>     pseudonym-based EAP methods are used.
>=20
> 4. Blair: Correlate accounting records with
>     an identifier so that fixed price
>     billing models can be applied at a service
>     provider.
>=20
>     Note 6: This requires a stable (~ month)
>     identity, but it does not have to be a "real"
>     identity. Compare to requirement 1!
>=20
> 5. Farid: Provide a new format to carry non-NAI
>     identities, such as IMSI or E.164 numbers.
>=20
> 6. Farid: Provide an alternate, second identifier
>     in addition to the NAI.
>=20
>     Note 7: I am presuming that this is a requirement.
>     Is it?
>=20
> 7. Jari: Carry a privacy-protected "handle" instead
>     of the "real" identity when returning User-Name/
>     Class/User-Alias.
>=20
> Anything else?
>=20
> --Jari
>=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
>=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/>

Delivery-date: Fri, 16 Jul 2004 18:53:11 +0000
Date: Fri, 16 Jul 2004 21:47:41 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Roy Albert <[email-masked]>
Cc: [email-masked]
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)

Thanks. Would this be done by the home networks or the
intermediaries? Are you willing to say if something
like this is currently done in your organization,
acting as an intermediary?

--Jari

Roy Albert wrote:
> In the case where someone's credentials have been compromised, it is
> necessary to have a unique per-user identifier to help detect this (much
> as credit card companies do) by monitoring for unusual activity. This is
> not quite covered by your points below.
> 
> -Roy
> 
> Roy D. Albert
> [email-masked]
>  
> 
> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, July 16, 2004 11:27 AM
> To: Bernard Aboba
> Cc: [email-masked]'
> Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)
> 
> Bernard Aboba wrote:
> 
> 
>>It seems like everyone is seeing a different application for the
> 
> attribute
> 
>>-- and that is why it is so hard to come to agreement on the problem
>>statement.
> 
> 
> Right. I think we have seen the following applications
> or individual requirements:
> 
> 1. Lothar: Get the user's "trackable" identity for the access
>     network so that fraudulent users can be tracked down and
>     acted upon without involving home operator (possibly in
>     another timezone and government etc).
> 
>     Note 1: This requires some sort of real identity, just
>     stable but opaque identifier would be insufficient. Or
>     its sufficient for denying further service, but not for
>     taking some action against the user.
> 
>     Note 2: I'm not sure I want to think about the privacy
>     implications of this. No hotspot access in the Big Brother
>     Republic unless your home ISP sends your passport number,
>     snail address, and biometric data in an Access-Accept. Hmm...
>     I think we are going to get here sooner or later :-(
> 
> 2. Avi: Controlling a policy for the user, such as limits
>     on the number of simultaneous sessions per user.
> 
>     Note 3: This is only useful if the home network's policy
>     is different from the access network's policy. For instance,
>     home network has unlimited access while access network
>     allows at most one access at a time.
> 
>     Note 4: Even if the policies are different, home networks
>     could still apply the policy on a per-visited network
>     basis. This could be problematic for provisioning,
>     however.
> 
>     Note 5: Even if the access network applies the policy,
>     it has no guarantee that the identity given to it is
>     correct. A fraudulent home network could claim that
>     all sessions come from a different user, whereas in
>     reality they actually are from one user. Does this
>     matter?
> 
> 3. Farid: Retrieve real identity when tunneled or
>     pseudonym-based EAP methods are used.
> 
> 4. Blair: Correlate accounting records with
>     an identifier so that fixed price
>     billing models can be applied at a service
>     provider.
> 
>     Note 6: This requires a stable (~ month)
>     identity, but it does not have to be a "real"
>     identity. Compare to requirement 1!
> 
> 5. Farid: Provide a new format to carry non-NAI
>     identities, such as IMSI or E.164 numbers.
> 
> 6. Farid: Provide an alternate, second identifier
>     in addition to the NAI.
> 
>     Note 7: I am presuming that this is a requirement.
>     Is it?
> 
> 7. Jari: Carry a privacy-protected "handle" instead
>     of the "real" identity when returning User-Name/
>     Class/User-Alias.
> 
> Anything else?
> 
> --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: Fri, 16 Jul 2004 18:40:40 +0000
content-class: urn:content-classes:message
Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 11:36:28 -0700
From: "Roy Albert" <[email-masked]>
To: [email-masked], "Bernard Aboba" <[email-masked]>
cc: [email-masked]

In the case where someone's credentials have been compromised, it is
necessary to have a unique per-user identifier to help detect this (much
as credit card companies do) by monitoring for unusual activity. This is
not quite covered by your points below.

-Roy

Roy D. Albert
[email-masked]
=20

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]=20
Sent: Friday, July 16, 2004 11:27 AM
To: Bernard Aboba
Cc: [email-masked]'
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

> It seems like everyone is seeing a different application for the
attribute
> -- and that is why it is so hard to come to agreement on the problem
> statement.

Right. I think we have seen the following applications
or individual requirements:

1. Lothar: Get the user's "trackable" identity for the access
    network so that fraudulent users can be tracked down and
    acted upon without involving home operator (possibly in
    another timezone and government etc).

    Note 1: This requires some sort of real identity, just
    stable but opaque identifier would be insufficient. Or
    its sufficient for denying further service, but not for
    taking some action against the user.

    Note 2: I'm not sure I want to think about the privacy
    implications of this. No hotspot access in the Big Brother
    Republic unless your home ISP sends your passport number,
    snail address, and biometric data in an Access-Accept. Hmm...
    I think we are going to get here sooner or later :-(

2. Avi: Controlling a policy for the user, such as limits
    on the number of simultaneous sessions per user.

    Note 3: This is only useful if the home network's policy
    is different from the access network's policy. For instance,
    home network has unlimited access while access network
    allows at most one access at a time.

    Note 4: Even if the policies are different, home networks
    could still apply the policy on a per-visited network
    basis. This could be problematic for provisioning,
    however.

    Note 5: Even if the access network applies the policy,
    it has no guarantee that the identity given to it is
    correct. A fraudulent home network could claim that
    all sessions come from a different user, whereas in
    reality they actually are from one user. Does this
    matter?

3. Farid: Retrieve real identity when tunneled or
    pseudonym-based EAP methods are used.

4. Blair: Correlate accounting records with
    an identifier so that fixed price
    billing models can be applied at a service
    provider.

    Note 6: This requires a stable (~ month)
    identity, but it does not have to be a "real"
    identity. Compare to requirement 1!

5. Farid: Provide a new format to carry non-NAI
    identities, such as IMSI or E.164 numbers.

6. Farid: Provide an alternate, second identifier
    in addition to the NAI.

    Note 7: I am presuming that this is a requirement.
    Is it?

7. Jari: Carry a privacy-protected "handle" instead
    of the "real" identity when returning User-Name/
    Class/User-Alias.

Anything else?

--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: Fri, 16 Jul 2004 18:32:24 +0000
Date: Fri, 16 Jul 2004 21:27:05 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Privacy (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

> It seems like everyone is seeing a different application for the attribute
> -- and that is why it is so hard to come to agreement on the problem
> statement.

Right. I think we have seen the following applications
or individual requirements:

1. Lothar: Get the user's "trackable" identity for the access
    network so that fraudulent users can be tracked down and
    acted upon without involving home operator (possibly in
    another timezone and government etc).

    Note 1: This requires some sort of real identity, just
    stable but opaque identifier would be insufficient. Or
    its sufficient for denying further service, but not for
    taking some action against the user.

    Note 2: I'm not sure I want to think about the privacy
    implications of this. No hotspot access in the Big Brother
    Republic unless your home ISP sends your passport number,
    snail address, and biometric data in an Access-Accept. Hmm...
    I think we are going to get here sooner or later :-(

2. Avi: Controlling a policy for the user, such as limits
    on the number of simultaneous sessions per user.

    Note 3: This is only useful if the home network's policy
    is different from the access network's policy. For instance,
    home network has unlimited access while access network
    allows at most one access at a time.

    Note 4: Even if the policies are different, home networks
    could still apply the policy on a per-visited network
    basis. This could be problematic for provisioning,
    however.

    Note 5: Even if the access network applies the policy,
    it has no guarantee that the identity given to it is
    correct. A fraudulent home network could claim that
    all sessions come from a different user, whereas in
    reality they actually are from one user. Does this
    matter?

3. Farid: Retrieve real identity when tunneled or
    pseudonym-based EAP methods are used.

4. Blair: Correlate accounting records with
    an identifier so that fixed price
    billing models can be applied at a service
    provider.

    Note 6: This requires a stable (~ month)
    identity, but it does not have to be a "real"
    identity. Compare to requirement 1!

5. Farid: Provide a new format to carry non-NAI
    identities, such as IMSI or E.164 numbers.

6. Farid: Provide an alternate, second identifier
    in addition to the NAI.

    Note 7: I am presuming that this is a requirement.
    Is it?

7. Jari: Carry a privacy-protected "handle" instead
    of the "real" identity when returning User-Name/
    Class/User-Alias.

Anything else?

--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, 16 Jul 2004 18:02:30 +0000
Date: Fri, 16 Jul 2004 20:57:12 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

> It's only a problem if the RADIUS server requires this behavior.  But
> we've already said that from the RADIUS server point of view, there is no
> distinction between Billable Identity and Class.  They provide the same
> functionality.  So a RADIUS server can send *both* Class and
> Billable-Identity and be ensured that at least one of these will be
> understood.

This is OK, but one may wonder whether Class alone would suffice
all the time, if it suffices for some cases. I do see the problems
in using Class -- there are many. But if you are saying its
OK for some subset of the cases... what's the difference that
the new attribute would give in the rest of the cases? And
presuming that there is a difference, how is it that the
service providers are going to live with the restrictions of
the Class attribute _and_ keep their fixed price business
model?

Perhaps the answer lies in the definition of the
business model. Is it

   (a) Access provider MUST present a fixed cost bill
       per user per month, and MUST ensure that a given
       user is logged on at most once at any given time.

or

   (b) Access provider SHOULD present a fixed cost bill
       per user per month, and SHOULD ensure that a
       given is logged on at most once at any given time.
       However, if the peer equipment indicates that it
       does not support this feature, then a per-session
       bill MAY also be presented, and session limits
       MAY be ignored.

Note that if the answer is "a", then we have two ways
of achieving it: we can either try to achieve it at
the protocol level or through some sort of roamaing
agreements (e.g., GSMA).

--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, 16 Jul 2004 17:42:12 +0000
Date: Fri, 16 Jul 2004 20:36:50 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: NAIbis effects (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

> This is functionality that has been in place for many years and so I'm not
> sure we can mandate new behavior.  My assumption has been that User-Name
> attributes returned in the Access-Accept are not handled the same way that
> User-Name attributes in an Access-Request are.

I can do this in either way, but let me just dig a bit
deeper into the above. Why do you think Access-Accept is
handled in a different way? Its certainly handled by
a different piece of code, but I would assume that there
has to be some state associated with the Access-Reques/Accept
pair, otherwise retransmission would not be possible. So,
given that the '!' conversion already needs new code for the
Access-Request, it seems that all that is needed is that
the Access-Accept part of the code looks into the stored
state and sees that it needs to insert back something.

(Note: I'd like to find out whether I will leave this
out from naibis-02 by tomorrow, because I will submit
the revision then, as I'm going to be away from the
net a couple of days after that.)

--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, 16 Jul 2004 17:26:03 +0000
Date: Fri, 16 Jul 2004 10:23:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Lothar Reith <[email-masked]>
cc: "'Klaas Wierenga'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

> "privacy-protected-identity", which - when present - is used instead of the
> NAI for all kinds of purposes normally the NAI is used for, including
> billing, re-authorization, abuse tracking etc.

Can't that function be handled by sending a User-Name attribute in the
Access-Accept?  Why would another attribute be needed?

> seems to be federated identity management (with privacy).  Is anybody seeing
> a different application for this new attribute ?

It seems like everyone is seeing a different application for the attribute
-- and that is why it is so hard to come to agreement on the problem
statement.

The proposal on the table only uses the new attribute for accounting, not
for authentication.

--
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, 16 Jul 2004 17:18:04 +0000
Date: Fri, 16 Jul 2004 10:15:43 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Barney Wolff <[email-masked]>, [email-masked]
Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues)

> The primary problem is that RFC 2866 did not require that unrecognized
> attributes be copied verbatim to the accounting request packets. (Or
> am I missing some text somewhere?)

No you're not missing something.  Since unrecognized attributes can be
ignored entirely, it's possible that nothing at all may happen as a result
of sending them.

> So I agree that the NAS support for a new attribute which would have
> to be copied from Access-Accept to Accounting-Request is a problem.

It's only a problem if the RADIUS server requires this behavior.  But
we've already said that from the RADIUS server point of view, there is no
distinction between Billable Identity and Class.  They provide the same
functionality.  So a RADIUS server can send *both* Class and
Billable-Identity and be ensured that at least one of these will be
understood.

> bit mask) which would enable the server to know what the NAS
> can do.

This only helps if the attribute in question is really Mandatory.  But
Billable-Identity seems like it is optional.

> it isn't clear what to _do_ in the case when the NAS does
> not support it.

It's only a problem if the attribute MUST be supported by the NAS or
service cannot be provided (such as security-critical functionality).

So far quite a few attributes in the LAN attributes document fit in this
category (such as VLAN-related attributes or IP filters).  So that
document appears dependent on the resolution of this issue.  Note that in
this particular case the "RFC Compliance" argument doesn't hold.  It's one
thing to assume that a NAS with NAS-Port-Type of 802.11 or 802 is
compliant with RFC 3580; it's another thing to assume that they're
compliant with an extension document that may only reach a fraction of the
installed base.

--
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, 16 Jul 2004 17:11:55 +0000
From: "Lothar Reith" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, "'Klaas Wierenga'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: AW: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 18:11:28 +0100

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_01C46B57.EEB997E6
Content-Type: text/plain

Klaas wrote:
> Possibly. In the Netherlands most universities are in such a 'roaming 
> consortium' to provide guest access to eachothers wireless LANs based 
> on 802.1X+RADIUS. Some universities want to know the real identity of 
> a user in case of abuse. The alternative is to agree on a logging 
> format so that abuse can be tracked down by contacting the home 
> organisation of the user, but this may be difficult (many log entries 
> for
> [email-masked]) and requires in any case a lot of coordination.
> And a bit further along the road, possibly the visited institution wants
> to do more advance authorisation based on the identity of the user (did
> he complete math101, is he a staff member etc.)

Bernard wrote:
Can this particular scenario be handled by the attributes that exist
(User-Name, Class) or are being discussed (Billable-Identity)?

Lothar writes:
I would think yes, e.g. by combining all 3 of them, the privacy requesting
NAI "[email-masked]" with a privacy granting "Billable identity"
issued by a trusted party (the home university), combined with Class
attribute which by some bilateral agreement between participating
universities could use the Class attribute to communicate membership in a
certain group, such as university-staff-member or
advanced-student-of-mathematics. 

I would however suggest to be very careful with the name of the
"billable-identity" attribute - after all these students probably do not
receive a bill at all, therefor the notion of "billable identity" may be
misleading.  I think we are really talking about a
"privacy-protected-identity", which - when present - is used instead of the
NAI for all kinds of purposes normally the NAI is used for, including
billing, re-authorization, abuse tracking etc. Simply because the NAI is not
unique and in this case appears to only serve the routing of the initial
access request to the home network and back.  Of course the home network
MUST be able to assert and resolve the privacy-protected-identity to the
true identity of the user.  

And the notion of "logging format" leads me to the suggestion, that if the
logging is not done via RADIUS accounting, than it must include the
"privacy-protected-identity" otherwise there would be no way to track down
the true identity of an abusive user.

I guess at the end of the day, the one key application for this new RADIUS
attribute sofar called either "billable-identity"- or "alius-username"
seems to be federated identity management (with privacy).  Is anybody seeing
a different application for this new attribute ?

Regards, Lothar

------_=_NextPart_001_01C46B57.EEB997E6
Content-Type: text/html
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=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>AW: AW: Privacy (Was: Re: NAI decoration: User Identity =
issues)</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=3D2>Klaas wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; Possibly. In the Netherlands most universities =
are in such a 'roaming </FONT>
<BR><FONT SIZE=3D2>&gt; consortium' to provide guest access to =
eachothers wireless LANs based </FONT>
<BR><FONT SIZE=3D2>&gt; on 802.1X+RADIUS. Some universities want to =
know the real identity of </FONT>
<BR><FONT SIZE=3D2>&gt; a user in case of abuse. The alternative is to =
agree on a logging </FONT>
<BR><FONT SIZE=3D2>&gt; format so that abuse can be tracked down by =
contacting the home </FONT>
<BR><FONT SIZE=3D2>&gt; organisation of the user, but this may be =
difficult (many log entries </FONT>
<BR><FONT SIZE=3D2>&gt; for</FONT>
<BR><FONT SIZE=3D2>&gt; [email-masked]) and requires in any =
case a lot of coordination.</FONT>
<BR><FONT SIZE=3D2>&gt; And a bit further along the road, possibly the =
visited institution wants</FONT>
<BR><FONT SIZE=3D2>&gt; to do more advance authorisation based on the =
identity of the user (did</FONT>
<BR><FONT SIZE=3D2>&gt; he complete math101, is he a staff member =
etc.)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Bernard wrote:</FONT>
<BR><FONT SIZE=3D2>Can this particular scenario be handled by the =
attributes that exist (User-Name, Class) or are being discussed =
(Billable-Identity)?</FONT></P>

<P><FONT SIZE=3D2>Lothar writes:</FONT>
<BR><FONT SIZE=3D2>I would think yes, e.g. by combining all 3 of them, =
the privacy requesting NAI &quot;[email-masked]&quot; with a =
privacy granting &quot;Billable identity&quot; issued by a trusted =
party (the home university), combined with Class attribute which by =
some bilateral agreement between participating universities could use =
the Class attribute to communicate membership in a certain group, such =
as university-staff-member or advanced-student-of-mathematics. =
</FONT></P>

<P><FONT SIZE=3D2>I would however suggest to be very careful with the =
name of the &quot;billable-identity&quot; attribute - after all these =
students probably do not receive a bill at all, therefor the notion of =
&quot;billable identity&quot; may be misleading.&nbsp; I think we are =
really talking about a &quot;privacy-protected-identity&quot;, which - =
when present - is used instead of the NAI for all kinds of purposes =
normally the NAI is used for, including billing, re-authorization, =
abuse tracking etc. Simply because the NAI is not unique and in this =
case appears to only serve the routing of the initial access request to =
the home network and back.&nbsp; Of course the home network MUST be =
able to assert and resolve the privacy-protected-identity to the true =
identity of the user.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>And the notion of &quot;logging format&quot; leads me =
to the suggestion, that if the logging is not done via RADIUS =
accounting, than it must include the =
&quot;privacy-protected-identity&quot; otherwise there would be no way =
to track down the true identity of an abusive user.</FONT></P>

<P><FONT SIZE=3D2>I guess at the end of the day, the one key =
application for this new RADIUS attribute sofar called either =
&quot;billable-identity&quot;- or &quot;alius-username&quot;&nbsp; =
seems to be federated identity management (with privacy).&nbsp; Is =
anybody seeing a different application for this new attribute =
?</FONT></P>

<P><FONT SIZE=3D2>Regards, Lothar</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C46B57.EEB997E6--

--
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, 16 Jul 2004 17:08:22 +0000
Date: Fri, 16 Jul 2004 10:06:06 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: Class vs. UserAlias (Was: Re: NAI decoration: User Identity issues)

> One could perhaps argue that if there's a business relationship
> between X and Y, they should agree that a Class attribute is used,
> and that the bytes 1-20 represent the true identity.

This kind of thing is fine on the RADIUS server.  However, it doesn't work
on the RADIUS client, which needs to contain code to parse the Class
attribute in order to determine if it has a billable identity or not.  In
many cases, this is not possible.

--
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, 16 Jul 2004 17:06:50 +0000
Date: Fri, 16 Jul 2004 10:04:28 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: [email-masked]
Subject: Re: NAIbis effects (Was: Re: NAI decoration: User Identity issues)

> But don't you think the reader
> should be alerted to this potential feature interaction in some
> document?

Yes, we do need to address it somewhere.  Perhaps the "RADIUS
implementation issues and fixes" document is the place for this.

>  Maybe in the naibis document? In fact,  we have two
> choices:
>
> 1) Warn the reader about this interaction, and suggest not
> using returned user name and routing syntax at the same
> time.

I think we need to alert the reader to the consequences. Not every setup
involves roaming, so it may not be an issue.

> 2) Require intermediaries to redo the routing syntax
> when the user name comes back in an Access-Accept.

This is functionality that has been in place for many years and so I'm not
sure we can mandate new behavior.  My assumption has been that User-Name
attributes returned in the Access-Accept are not handled the same way that
User-Name attributes in an Access-Request are.

--
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, 16 Jul 2004 16:48:20 +0000
Date: Fri, 16 Jul 2004 18:48:43 +0200
From: Klaas Wierenga <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC: "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:

Bernard,

>>Possibly. In the Netherlands most universities are in such a 'roaming
>>consortium' to provide guest access to eachothers wireless LANs based on
>>802.1X+RADIUS. Some universities want to know the real identity of a
>>user in case of abuse. The alternative is to agree on a logging format
>>so that abuse can be tracked down by contacting the home organisation of
>>the user, but this may be difficult (many log entries for
>>[email-masked]) and requires in any case a lot of coordination.
>>And a bit further along the road, possibly the visited institution wants
>>to do more advance authorisation based on the identity of the user (did
>>he complete math101, is he a staff member etc.)
> 
> 
> Can this particular scenario be handled by the attributes that exist
> (User-Name, Class) or are being discussed (Billable-Identity)?

To be totally honest, I don't know. I hope to get some students to 
investigate this. I really don't know what would be best/possible, use 
RADIUS for this or perhaps keep the RADIUS infrastructure relatively 
stupid and try to solve this in EAP (talking SAML over EAP??). Any 
thoughts on this would be appreciated.

Klaas

--
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, 16 Jul 2004 16:36:57 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: Deployment (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 12:36:32 -0400

Hi Jari,

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, July 16, 2004 10:55 AM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Deployment (Was: Re: NAI decoration: User 
> Identity issues)
> 
> 
> Avi Lior wrote:
> 
> > I think the MUST should be changed to SHOULD and thus not requiring 
> > any changes to NASes.
> 
> I can see the "legal" distinction between a MUST and a 
> SHOULD, but wouldn't the change still be needed in practise 
> on the NASes, before this functionality becomes operational?

There are two general uses for User-Alias.

1) One is the case where Intermediaries or Access network etc are trying to
control policy such as how many times a user can connect to the network.
(Appatently this is the case in some deployements)

2) The other is the case where it is needed during accounting.

So to have the functionality operational in somecases it doesn't have to be
a MUST.

> In fact, I'd be happy even with a MUST -- NASes that don't 
> support that MUST don't support this particular RFC, which is 
> of course perfectly legal...

We could do that. My prefence is to use MUSTs whenever I can so if there
were no objections then leave it as a MUST.  But its not allways necessary
as pointed above.  

> > In a situtaion where a NAS does not support this attribute yet an 
> > Intermediary needed to correlate accounting to the 
> > User-Alias-Identity, the Intermediary would insert the 
> Class attribute 
> > in the Access Accept and if the NAS supported the Class attribute, 
> > problem solved.
> 
> I think the NASes must support the Class attribute if they 
> are compliant with RFC 2865/66.

In 2865 Class is a SHOULD not a MUST.

"This Attribute is available to be sent by the server to the client
      in an Access-Accept and SHOULD be sent unmodified by the client to
      the accounting server."

And while I am at the section - just in case some are thinking that its okay
to have the client interpret Class:

"The client MUST NOT interpret the attribute locally."

> Anyway, I think your compatibility scheme works. I just wish
> we didn't need to have alternative modes of operation.

Me 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: Fri, 16 Jul 2004 16:14:53 +0000
Date: Fri, 16 Jul 2004 09:12:33 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Klaas Wierenga <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

> Possibly. In the Netherlands most universities are in such a 'roaming
> consortium' to provide guest access to eachothers wireless LANs based on
> 802.1X+RADIUS. Some universities want to know the real identity of a
> user in case of abuse. The alternative is to agree on a logging format
> so that abuse can be tracked down by contacting the home organisation of
> the user, but this may be difficult (many log entries for
> [email-masked]) and requires in any case a lot of coordination.
> And a bit further along the road, possibly the visited institution wants
> to do more advance authorisation based on the identity of the user (did
> he complete math101, is he a staff member etc.)

Can this particular scenario be handled by the attributes that exist
(User-Name, Class) or are being discussed (Billable-Identity)?

--
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, 16 Jul 2004 15:52:14 +0000
Date: Fri, 16 Jul 2004 17:52:27 +0200
From: Klaas Wierenga <[email-masked]>
To: Lothar Reith <[email-masked]>
CC: "[email-masked]'" <[email-masked]>,  'Barney Wolff' <[email-masked]>, 'Bernard Aboba' <[email-masked]>,  'Avi Lior' <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

Lothar Reith wrote:

Lothar,

> Is there any reason that the roaming consortium or the local access 
> network *needs* to know the  *true" user identity, in case of the 
> authenticating user (or the home network) requesting privacy ?

Possibly. In the Netherlands most universities are in such a 'roaming 
consortium' to provide guest access to eachothers wireless LANs based on 
802.1X+RADIUS. Some universities want to know the real identity of a 
user in case of abuse. The alternative is to agree on a logging format 
so that abuse can be tracked down by contacting the home organisation of 
the user, but this may be difficult (many log entries for 
[email-masked]) and requires in any case a lot of coordination.
And a bit further along the road, possibly the visited institution wants 
to do more advance authorisation based on the identity of the user (did 
he complete math101, is he a staff member etc.)

Klaas

--
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, 16 Jul 2004 15:52:06 +0000
Content-class: urn:content-classes:message
Subject: RE: MUST vs. SHOULD, Mandatory vs. Optional
Date: Fri, 16 Jul 2004 11:51:01 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

> >RADIUS has never had a protocol-based notion of Mandatory vs.
Optional
> Attributes.
>=20
> In RFC 2865, it says that attributes that aren't understood may be
treated
> as optional.

It says that they may be ignored, which means the same thing.

> On the other hand, a RADIUS client that receives a request
> for a service it does not implement must not provide that service.  So
the
> question comes down to what attributes define a service (mandatory)
and
> which don't (optional).  One take on this is that Service-Type is a
> mandatory attribute.  That is, if a NAS doesn't support the
Service-Type
> value requested by the server, then it has to act as if an
Access-Reject
> was sent.

I agree.

What I meant by "protocol-based notion" was an attribute by attribute
flagging mechanism, such as we have in Diameter.

> >I think that the most that can be said of an existing NAS that is
> RFC2865 compliant, but does not implement a new attribute is that it
is
> not RFCxxxx compliant.
>=20
> That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869,
RFC
> 3580, etc.).  But if each attribute is published in a separate RFC
then we
> end up with a tower of Babel -- creating lots of new RADIUS dialects.
> That's not helpful.

Um...  Yes, there is that practical side to the issue.  I would hope
that the number of new features (I'm explicitly avoiding the word
"application" because of the debate that's been going on over on the AAA
WG list), would be small, such that it might be practical to have an RFC
per feature.  Certainly not an RFC per attribute, as I see each new
feature as requiring a set of new attributes.

-- 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: Fri, 16 Jul 2004 15:41:06 +0000
To: [email-masked]
Subject: Re: MUST vs. SHOULD, Mandatory vs. Optional
Date: Fri, 16 Jul 2004 08:38:52 -0700
From: Bernard Aboba <[email-masked]>

>RADIUS has never had a protocol-based notion of >Mandatory vs. Optional Attributes.  

In RFC 2865, it says that attributes that aren't understood may be treated as optional.  On the other hand, a RADIUS client that receives a request for a service it does not implement must not provide that service.  So the question comes down to what attributes define a service (mandatory) and which don't (optional).  One take on this is that Service-Type is a mandatory attribute.  That is, if a NAS doesn't support the Service-Type value requested by the server, then it has to act as if an Access-Reject was sent. 

>I think that the most that can be said of an existing >NAS that is RFC2865 compliant, but does not implement >a new attribute is that it is not RFCxxxx compliant. 

That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC 3580, etc.).  But if each attribute is published in a separate RFC then we end up with a tower of Babel -- creating lots of new RADIUS dialects.  That's not helpful. 

--
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, 16 Jul 2004 15:40:57 +0000
To: [email-masked], [email-masked], David <[email-masked]>
Subject: Re: MUST vs. SHOULD, Mandatory vs. Optional
Date: Fri, 16 Jul 2004 08:38:35 -0700
From: Bernard Aboba <[email-masked]>

>RADIUS has never had a protocol-based notion of >Mandatory vs. Optional Attributes.  

In RFC 2865, it says that attributes that aren't understood may be treated as optional.  On the other hand, a RADIUS client that receives a request for a service it does not implement must not provide that service.  So the question comes down to what attributes define a service (mandatory) and which don't (optional).  One take on this is that Service-Type is a mandatory attribute.  That is, if a NAS doesn't support the Service-Type value requested by the server, then it has to act as if an Access-Reject was sent. 

>I think that the most that can be said of an existing >NAS that is RFC2865 compliant, but does not implement >a new attribute is that it is not RFCxxxx compliant. 

That is ok if RFCxxxx is a substantial body of work (e.g. RFC 2869, RFC 3580, etc.).  But if each attribute is published in a separate RFC then we end up with a tower of Babel -- creating lots of new RADIUS dialects.  That's not helpful. 

--
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, 16 Jul 2004 15:23:58 +0000
To: [email-masked]
Cc: [email-masked]
Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 08:21:25 -0700
From: Bernard Aboba <[email-masked]>

>the Intermediary would insert the Class attribute in 

To the RADIUS server, the "Intermediary" is just another RADIUS client.  So the question still exists. How does the server know the RADIUS client supports this?

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

Delivery-date: Fri, 16 Jul 2004 14:59:55 +0000
Date: Fri, 16 Jul 2004 17:54:43 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Deployment (Was: Re: NAI decoration: User Identity issues)

Avi Lior wrote:

> I think the MUST should be changed to SHOULD and thus not requiring any
> changes to NASes.

I can see the "legal" distinction between a MUST and a SHOULD, but
wouldn't the change still be needed in practise on the NASes, before
this functionality becomes operational?

In fact, I'd be happy even with a MUST -- NASes that don't support
that MUST don't support this particular RFC, which is of course
perfectly legal...

> In a situtaion where a NAS does not support this attribute yet an
> Intermediary needed to correlate accounting to the User-Alias-Identity, the
> Intermediary would insert the Class attribute in the Access Accept and if
> the NAS supported the Class attribute, problem solved.

I think the NASes must support the Class attribute if they are
compliant with RFC 2865/66.

Anyway, I think your compatibility scheme works. I just wish
we didn't need to have alternative modes of operation.

--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, 16 Jul 2004 14:59:04 +0000
Content-class: urn:content-classes:message
Subject: MUST vs. SHOULD, Mandatory vs. Optional
Date: Fri, 16 Jul 2004 10:57:57 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

RADIUS has never had a protocol-based notion of Mandatory vs. Optional
Attributes.  There is a proposal to add this feature, by means of an
explicit "M" bit in the format of certain classes of extended
attributes.  I'm going to withhold substantive comment on that proposal,
until I have had more time to contemplate the all implications. This
would be a useful feature.  OTOH, our charter is not to evolve RADIUS
into Diameter.

There has also been some discussion as to when to use MUST and when to
use SHOULD in describing new attributes defined within RADEXT documents.
One issue is with respect to conformance and whether a MUST implies that
existing NASes must be upgraded to implement the feature to be "RADIUS
compliant" or be useful in environment where the new attribute is in
use.

I think that the most that can be said of an existing NAS that is
RFC2865 compliant, but does not implement a new attribute is that it is
not RFCxxxx compliant (where RFCxxx defines the new feature and its
attributes).  RFCxxxx can specify a MUST only with respect to
implementation of the feature described in the document.  I think of
this as a "conditional MUST", which means MUST if and only if the
underlying extended feature has been implemented.=20

If the MUST language is appropriate to describing the need for specific
attribute handling or implementation with respect to the new feature,
then the language ought not to be softened to SHOULD, just because some
NASes will not implement the new feature. The scope of applicability of
the RFC should clearly indicate that the requirements of the document
apply to NASes that implement the feature described in the document.

The capabilities announcement functionality should be sufficient to
address global interoperability issues with respect to NASes that do and
do not implement the new feature.  These considerations should be part
of the respective document.

-- 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: Fri, 16 Jul 2004 14:43:31 +0000
Date: Fri, 16 Jul 2004 17:37:45 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 wrote:

> So potentially (if you didn't have the legacy issue with EAP), you would want to have an "EAP attribute" with all the related info as sub-attributes,  no?

Right. If current protocols did not exist, we could design a new one :-)

But since they do exist, we are not going to do extensions that
break backwards compatibility without a very good reason. This
I believe is independent of any potential attempts to extend
the data model: data model extensions, if any, would only apply
to new attributes.

--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, 16 Jul 2004 14:20:53 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Barney Wolff <[email-masked]>, "'Adrangi, Farid'" <[email-masked]>
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Fri, 16 Jul 2004 10:20:34 -0400

Bernard, Barney and Farid,

Bernard's point is well taken.

I checked the latest posted draft and it says that the User-Alias-Identity
MUST be placed in Accounting if it was received in an Access Accept.

I think the MUST should be changed to SHOULD and thus not requiring any
changes to NASes.

In a situtaion where a NAS does not support this attribute yet an
Intermediary needed to correlate accounting to the User-Alias-Identity, the
Intermediary would insert the Class attribute in the Access Accept and if
the NAS supported the Class attribute, problem solved.

Avi.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Friday, July 16, 2004 1:21 AM
> To: Barney Wolff
> Cc: [email-masked]
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> > > Class attributes could change over the lifetime of even a session 
> > > because class attribute may store stuff other then just  the User 
> > > Alias.  So you cant use it as the User's Identity.
> 
> Depends who "you" is.  Presumably, the RADIUS server can use 
> it, since it sent the Class attribute.  But I think the point 
> is that the RADIUS client can't be sure that the Class 
> attribute contains a billable identity. If in addition the 
> User-Name does not contain a billable identity (e.g.
> privacy) then the RADIUS client has no assurance of billability.
> 
> > all the world's NAS's have to be upgraded?
> 
> This raises the question about whether the billable-identity 
> is an optional or mandatory attribute.  My take is that it is 
> optional. Here's why. If it is sent by the RADIUS server and 
> not understood by the NAS, RFC 2865 states clearly that it 
> MAY be ignored.
> 
> My understanding is that the issue here is on the RADIUS 
> client side, because if the RADIUS server wanted to make sure 
> that got the opaque string back in the accounting record, it 
> could always send that opaque blob *both* in the 
> billable-identity attribute and in Class.  That way, if the 
> RADIUS client cared about billable-identity, it would have 
> it; if not, it would ignore it.
> 
> If you buy this logic, then no NAS upgrade is required.
> 
> > If all NAS's are not forced to upgrade, how will the server know 
> > whether it can include User-Alias?
> 
> If the above argument isn't convincing, and we conclude that 
> this attribute is Mandatory, then we have an issue.  RFC 2865 
> doesn't support Mandatory attributes.  There are a number of 
> proposals on the table to fix this, however (e.g. Jari's 
> proposal for a new attribute format with an 'M' bit).
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Fri, 16 Jul 2004 13:08:43 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Barney Wolff <[email-masked]>
Cc: [email-masked]
Subject: RE: RFC 2865 compatibility
Date: Fri, 16 Jul 2004 09:08:33 -0400

Bernard, Barney,

> 
> b) Respecify the attribute in a way that its use can be 
> negotiated and the RADIUS server can be guaranteed that if 
> sent and not understood, the right thing will happen (e.g. no 
> service will be granted to the user). There are proposals on 
> the table that provide for this (e.g. Jari's proposal for 
> extended attributes).

And also the capability exchange that is also on the table would help here.

Also note that the NAS may not support the extended attributes.
 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Fri, 16 Jul 2004 12:46:22 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Barney Wolff <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 08:46:16 -0400

Hi Jari and Barney,

See comments inserted

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: July 16, 2004 3:13 AM
> To: Barney Wolff
> Cc: Bernard Aboba; Avi Lior; [email-masked]
> Subject: Privacy (Was: Re: NAI decoration: User Identity issues)
> 
> 
> Barney Wolff wrote:
> 
> > I guess the question is whether there is a long-term one-to-one 
> > relationship between User-Alias and the user's "true" identity.  If 
> > there is, then attackers can gain information of some value by 
> > correlating different accesses resulting in the same User-Alias.

Absolutely.  
 
> This is an interesting issue. There is a very valid reason 
> for employing privacy at the network access protocol level 
> (say, in 802.1X/EAP/NAI). This is primarily to avoid being 
> exposed to other clients on the same network. Not so much 
> against the service provider.
> 
> But I think there is also interest in ensuring some level of 
> protection against the service provider, or at least parts of 
> it. Clearly, the home network is going to know who you are. 
> Maybe even the roaming consortium and the local access 
> network. But I'd rather not reveal my true identity to the 
> access point on the coffee shop wall. It is in an insecure 
> environment, often uses a wireless uplink or other weakly 
> protected physical medium. And if it runs RADIUS, the chances 
> are that its not running ESP so the contents of any new AVP 
> being returned from the home network would be relatively 
> easily visible to those who wanted to look.
> 
> On the other hand, there is also a valid business reason for 
> some intermediaries to relate different sessions to the same 
> entity so that fixed price model can be applied.

Yes this is the requirement that we received.  Some intermediaries are
indeed charged with ensuring policies such as the user is only logged in
once.
 
> One way to resolve these conflicting requirements is to (a) 
> explain that the attribute (be it Class or something new) is 
> to be returned with fixed contents only if the particular 
> business situation requires it, 

Agreed.  The operator will put it in if it needs it in.

>(b) in the proxy, strip off 
> the attribute from the packets going to the NAS and insert a 
> Class attribute with opaque and not-fixed contents instead, 
> and 

It is possible that the proxy may know that the User-Alias is not needed
past a particular point.  It could strip it off and insert it back in
accounting.  This is a normal behavior for some proxies already.  How it
does it is not important.  It could use class. 

>(c) when the accounting request comes back from the NAS, 
> take away the inserted Class and replace with the original attribute.

> But this is complicated. Feel free to suggests a more optimal 
> scheme :-)

Proxies already do this type of operations. It is complicated and may not be
necessary if the User-Alias contained a short lived handle to the user.
Long enough to support the business needs but not long enough to function as
a user identity.  I think if security was an issue that is the way to do
this.

Avi
 
> --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, 16 Jul 2004 12:36:09 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: 'Bernard Aboba' <[email-masked]>, [email-masked]
Subject: RE: Class vs. UserAlias (Was: Re: NAI decoration: User Identity i ssues)
Date: Fri, 16 Jul 2004 08:35:40 -0400

Jari,

I don't think it would be wise to specify what Class should or should not
contain.  IMO we must not touch class.  It will break too many
implementations.

User-Alias or Billable-Identity whatever you want to call it containing a
long lived or short lived handle to the user  (depending on the privacy
need) is the way to go.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: July 16, 2004 3:14 AM
> To: Avi Lior
> Cc: 'Bernard Aboba'; [email-masked]
> Subject: Class vs. UserAlias (Was: Re: NAI decoration: User 
> Identity issues)
> 
> 
> Avi Lior wrote:
> > A UserAlias can contain some opaque value provided that the 
> > HomeNetwork asserts that it represents a user for a period 
> of time.  
> > That is it will not change over a period of time.  The 
> period of time 
> > could be a month or even longer.
> > 
> > Class attributes could change over the lifetime of even a session 
> > because class attribute may store stuff other then just  the User 
> > Alias.
> 
> One of the problems is indeed that the Class attribute may 
> contain a lot of data, some of which could vary from message 
> to message. And there may be multiple Class attributes.
> 
> One could perhaps argue that if there's a business 
> relationship between X and Y, they should agree that a Class 
> attribute is used, and that the bytes 1-20 represent the true 
> identity. Not sure if that's reasonable, however. Particular 
> server implementations might currently use Class in ways that 
> are not compatible with this approach.
> 
> --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, 16 Jul 2004 10:43:24 +0000
Date: Fri, 16 Jul 2004 13:38:11 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Lothar Reith <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: AW: Privacy (Was: Re: NAI decoration: User Identity issues)

Lothar Reith wrote:
> Is there any reason that the roaming consortium or the local access 
> network *needs* to know the  *true" user identity, in case of the 
> authenticating user (or the home network) requesting privacy ?

I don't think so (except maybe for some some legal interception
purposes).

In any case, the discussion has focused around giving some stable
identity (not necessarily the true identity) to the access network.
The purpose of this is to implement some business models where
there's per-user fixed price for roaming.

So, it is not necessary to give the true identity but even having
a stable identity will make it possible to do some correlation
of the user's movements, *assiming* access to NASes or cleartext RADIUS
traffic from them. Of course, the main problem of revealing
the user's identity to everyone on the access link is already
solved, if the identity does not appear in clear on the access
link. Typical EAP methods handle this with tunneling or temporary
pseudonyms.

--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, 16 Jul 2004 10:33:53 +0000
From: "Lothar Reith" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "'Barney Wolff'" <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, "'Avi Lior'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: AW: Privacy (Was: Re: NAI decoration: User Identity issues)
Date: Fri, 16 Jul 2004 11:33:06 +0100

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_01C46B20.4839B626
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Is there any reason that the roaming consortium or the local access =
network
*needs* to know the  *true" user identity, in case of the =
authenticating
user (or the home network) requesting privacy ?

Lothar

-----Urspr=FCngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] =
Im
Auftrag von Jari Arkko
Gesendet: Freitag, 16. Juli 2004 09:13
An: Barney Wolff
Cc: Bernard Aboba; Avi Lior; [email-masked]
Betreff: Privacy (Was: Re: NAI decoration: User Identity issues)

Barney Wolff wrote:

> I guess the question is whether there is a long-term one-to-one=20
> relationship between User-Alias and the user's "true" identity.  If=20
> there is, then attackers can gain information of some value by=20
> correlating different accesses resulting in the same User-Alias.

This is an interesting issue. There is a very valid reason for =
employing
privacy at the network access protocol level (say, in 802.1X/EAP/NAI). =
This
is primarily to avoid being exposed to other clients on the same =
network.
Not so much against the service provider.

But I think there is also interest in ensuring some level of protection
against the service provider, or at least parts of it. Clearly, the =
home
network is going to know who you are. Maybe even the roaming consortium =
and
the local access network. But I'd rather not reveal my true identity to =
the
access point on the coffee shop wall. It is in an insecure environment,
often uses a wireless uplink or other weakly protected physical medium. =
And
if it runs RADIUS, the chances are that its not running ESP so the =
contents
of any new AVP being returned from the home network would be relatively
easily visible to those who wanted to look.

On the other hand, there is also a valid business reason for some
intermediaries to relate different sessions to the same entity so that =
fixed
price model can be applied.

One way to resolve these conflicting requirements is to (a) explain =
that the
attribute (be it Class or something new) is to be returned with fixed
contents only if the particular business situation requires it, (b) in =
the
proxy, strip off the attribute from the packets going to the NAS and =
insert
a Class attribute with opaque and not-fixed contents instead, and (c) =
when
the accounting request comes back from the NAS, take away the inserted =
Class
and replace with the original attribute.

But this is complicated. Feel free to suggests a more optimal scheme =
:-)

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

------_=_NextPart_001_01C46B20.4839B626
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.2656.31">
<TITLE>AW: Privacy (Was: Re: NAI decoration: User Identity =
issues)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Is there any reason that the roaming consortium or =
the local access network *needs* to know the&nbsp; *true&quot; user =
identity, in case of the authenticating user (or the home network) =
requesting privacy ?</FONT></P>

<P><FONT SIZE=3D2>Lothar</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>] Im Auftrag von Jari Arkko</FONT>
<BR><FONT SIZE=3D2>Gesendet: Freitag, 16. Juli 2004 09:13</FONT>
<BR><FONT SIZE=3D2>An: Barney Wolff</FONT>
<BR><FONT SIZE=3D2>Cc: Bernard Aboba; Avi Lior; =
[email-masked]</FONT>
<BR><FONT SIZE=3D2>Betreff: Privacy (Was: Re: NAI decoration: User =
Identity issues)</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Barney Wolff wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I guess the question is whether there is a =
long-term one-to-one </FONT>
<BR><FONT SIZE=3D2>&gt; relationship between User-Alias and the user's =
&quot;true&quot; identity.&nbsp; If </FONT>
<BR><FONT SIZE=3D2>&gt; there is, then attackers can gain information =
of some value by </FONT>
<BR><FONT SIZE=3D2>&gt; correlating different accesses resulting in the =
same User-Alias.</FONT>
</P>

<P><FONT SIZE=3D2>This is an interesting issue. There is a very valid =
reason for employing privacy at the network access protocol level (say, =
in 802.1X/EAP/NAI). This is primarily to avoid being exposed to other =
clients on the same network. Not so much against the service =
provider.</FONT></P>

<P><FONT SIZE=3D2>But I think there is also interest in ensuring some =
level of protection against the service provider, or at least parts of =
it. Clearly, the home network is going to know who you are. Maybe even =
the roaming consortium and the local access network. But I'd rather not =
reveal my true identity to the access point on the coffee shop wall. It =
is in an insecure environment, often uses a wireless uplink or other =
weakly protected physical medium. And if it runs RADIUS, the chances =
are that its not running ESP so the contents of any new AVP being =
returned from the home network would be relatively easily visible to =
those who wanted to look.</FONT></P>

<P><FONT SIZE=3D2>On the other hand, there is also a valid business =
reason for some intermediaries to relate different sessions to the same =
entity so that fixed price model can be applied.</FONT></P>

<P><FONT SIZE=3D2>One way to resolve these conflicting requirements is =
to (a) explain that the attribute (be it Class or something new) is to =
be returned with fixed contents only if the particular business =
situation requires it, (b) in the proxy, strip off the attribute from =
the packets going to the NAS and insert a Class attribute with opaque =
and not-fixed contents instead, and (c) when the accounting request =
comes back from the NAS, take away the inserted Class and replace with =
the original attribute.</FONT></P>

<P><FONT SIZE=3D2>But this is complicated. Feel free to suggests a more =
optimal scheme :-)</FONT>
</P>

<P><FONT SIZE=3D2>--Jari</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_01C46B20.4839B626--

--
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, 16 Jul 2004 09:22:18 +0000
Date: Fri, 16 Jul 2004 10:14:52 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Barney Wolff <[email-masked]>,  Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Deployment (Was: Re: NAI decoration: User Identity issues)

Barney Wolff wrote:

> So, to support a particular business model, namely fixed per-user billing,
> all the world's NAS's have to be upgraded?  The business model could be
> accomodated by a private agreement on the use of Class between the
> intermediary and its customers, with no impact on the NAS.
> 
> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

The primary problem is that RFC 2866 did not require that unrecognized
attributes be copied verbatim to the accounting request packets. (Or
am I missing some text somewhere?)

So I agree that the NAS support for a new attribute which would have
to be copied from Access-Accept to Accounting-Request is a problem.

There are proposals on the table (such as Radius capabilities
bit mask) which would enable the server to know what the NAS
can do.

The question is if this helps. What if the NAS does not support
this capability? Perhaps you could switch to sending a Class
attribute instead. But it isn't clear to me what value there
would be in doing the same thing in two ways. Why not do it
just in one way then, if that one way has to be done in certain
cases anyway? Or are we going to accept this because it
provides better functionality at least in those cases that the
NAS supports this new functionality?

There are also proposals on the table that would make it possible
to mark attributes as mandatory. Here too we have a question:
what to do if the NAS does not support the attribute? Obviously
we could fail the session, or fall back to an easier business
model. But the latter is hard to achieve in an Access-Accept that
gets rejected by the NAS; it seems that we have to make the
decision earlier, based on NAS capabilities.

In conclusion a new copied attribute is possible, but
it isn't clear what to _do_ in the case when the NAS does
not support it. I think this is a problem. (Unfortunately,
also the use of the Class attribute seems problematic
as has been pointed out in other e-mails.)

--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, 16 Jul 2004 07:39:06 +0000
Date: Fri, 16 Jul 2004 10:33:46 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Barney Wolff <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Deployment (Was: Re: NAI decoration: User Identity issues)

Barney Wolff wrote:

> So, to support a particular business model, namely fixed per-user billing,
> all the world's NAS's have to be upgraded?  The business model could be
> accomodated by a private agreement on the use of Class between the
> intermediary and its customers, with no impact on the NAS.
> 
> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

The primary problem is that RFC 2866 did not require that unrecognized
attributes be copied verbatim to the accounting request packets. (Or
am I missing some text somewhere?)

So I agree that the NAS support for a new attribute which would have
to be copied from Access-Accept to Accounting-Request is a problem.

There are proposals on the table (such as Radius capabilities
bit mask) which would enable the server to know what the NAS
can do.

The question is if this helps. What if the NAS does not support
this capability? Perhaps you could switch to sending a Class
attribute instead. But it isn't clear to me what value there
would be in doing the same thing in two ways. Why not do it
just in one way then, if that one way has to be done in certain
cases anyway? Or are we going to accept this because it
provides better functionality at least in those cases that the
NAS supports this new functionality?

There are also proposals on the table that would make it possible
to mark attributes as mandatory. Here too we have a question:
what to do if the NAS does not support the attribute? Obviously
we could fail the session, or fall back to an easier business
model. But the latter is hard to achieve in an Access-Accept that
gets rejected by the NAS; it seems that we have to make the
decision earlier, based on NAS capabilities.

In conclusion a new copied attribute is possible, but
it isn't clear what to _do_ in the case when the NAS does
not support it. I think this is a problem. (Unfortunately,
also the use of the Class attribute seems problematic
as has been pointed out in other e-mails.)

--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, 16 Jul 2004 07:19:10 +0000
Date: Fri, 16 Jul 2004 10:13:58 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  [email-masked]
Subject: Class vs. UserAlias (Was: Re: NAI decoration: User Identity issues)

Avi Lior wrote:
> A UserAlias can contain some opaque value provided that the HomeNetwork
> asserts that it represents a user for a period of time.  That is it will not
> change over a period of time.  The period of time could be a month or even
> longer.
> 
> Class attributes could change over the lifetime of even a session because
> class attribute may store stuff other then just  the User Alias.

One of the problems is indeed that the Class attribute may contain a
lot of data, some of which could vary from message to message. And
there may be multiple Class attributes.

One could perhaps argue that if there's a business relationship
between X and Y, they should agree that a Class attribute is used,
and that the bytes 1-20 represent the true identity. Not sure if
that's reasonable, however. Particular server implementations might
currently use Class in ways that are not compatible with this
approach.

--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, 16 Jul 2004 07:18:39 +0000
Date: Fri, 16 Jul 2004 10:13:27 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Barney Wolff <[email-masked]>
CC: Bernard Aboba <[email-masked]>,  Avi Lior <[email-masked]>, [email-masked]
Subject: Privacy (Was: Re: NAI decoration: User Identity issues)

Barney Wolff wrote:

> I guess the question is whether there is a long-term one-to-one relationship
> between User-Alias and the user's "true" identity.  If there is, then
> attackers can gain information of some value by correlating different
> accesses resulting in the same User-Alias. 

This is an interesting issue. There is a very valid reason for employing
privacy at the network access protocol level (say, in 802.1X/EAP/NAI).
This is primarily to avoid being exposed to other clients on the same
network. Not so much against the service provider.

But I think there is also interest in ensuring some level of protection
against the service provider, or at least parts of it. Clearly, the home
network is going to know who you are. Maybe even the roaming consortium
and the local access network. But I'd rather not reveal my true identity
to the access point on the coffee shop wall. It is in an insecure
environment, often uses a wireless uplink or other weakly protected
physical medium. And if it runs RADIUS, the chances are that its not
running ESP so the contents of any new AVP being returned from the
home network would be relatively easily visible to those who wanted
to look.

On the other hand, there is also a valid business reason for some
intermediaries to relate different sessions to the same entity
so that fixed price model can be applied.

One way to resolve these conflicting requirements is to (a) explain
that the attribute (be it Class or something new) is to be returned
with fixed contents only if the particular business situation
requires it, (b) in the proxy, strip off the attribute from
the packets going to the NAS and insert a Class attribute with
opaque and not-fixed contents instead, and (c) when the accounting
request comes back from the NAS, take away the inserted Class and
replace with the original attribute.

But this is complicated. Feel free to suggests a more optimal
scheme :-)

--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, 16 Jul 2004 07:16:01 +0000
Date: Fri, 16 Jul 2004 10:10:33 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
CC: "Blair T. Bullock" <[email-masked]>,  "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: NAIbis effects (Was: Re: NAI decoration: User Identity issues)

Bernard Aboba wrote:
>>And then a question from your NAIbis draft editor: does
>>this resolve the issue that Farid raised earlier about
>>suffix-based decoration being rewritten by proxies and
>>then returned in an Access-Accept, causing problems for
>>the accounting requests? I think it does, but it seems
>>that we may have to, in addition, publish an RFC 3579 errata
>>to indicate that returned User-Name attributes should not
>>be used for accounting requests. Comments?
> 
> 
> I'd say that it is at the descretion of the RADIUS server whether to
> return the User-Name in the Access-Accept or not.  If it is returned, the
> NAS includes it in accounting requests.  If not, it uses the original
> User-Name, + Class + Billable Identity if those are available.  I don't
> think there's any need for an RFC 3579 errata.

Fair enough (and the document to change would be RFC 2865 as it
specified the general behavior). But don't you think the reader
should be alerted to this potential feature interaction in some
document? Maybe in the naibis document? In fact,  we have two
choices:

1) Warn the reader about this interaction, and suggest not
using returned user name and routing syntax at the same
time.

2) Require intermediaries to redo the routing syntax
when the user name comes back in an Access-Accept.

I think the latter makes more sense. Here's the new text
in 2486bis (7th paragraph):

   http://www.arkko.com/publications/nai/naibis.html#realmcons

--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, 16 Jul 2004 06:07:30 +0000
Date: Thu, 15 Jul 2004 23:05:11 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: RFC 2865 compatibility

> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

Thank you for bringing up this very important issue, Barney.

RFC 2865 states in Section 5:

A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.

This means that if a new attribute cannot be safely ignored there
is a problem. An example would be a filter rule that if ignored, would
result in a security vulnerability.  In such a situation, the
security-critical attribute could be ignored by the RADIUS client,
granting the user filter-free access without the RADIUS server having
any inkling what has happened.  Not good.

RADIUS client and server configuration cannot fix this problem in a
scalable way.  In a large network it is not always possible to keep
track of the capabilities of every RADIUS client and if clients
ignore security-critical attributes without sending an error message
(as is allowable under RFC 2865), then some very ugly situations
can arise.

There are two possible avenues of repair:

a) Describe how the attribute can be safely ignored.  For example, the
RADIUS server might send *both* a new and old attribute and be guaranteed
some level of safety in case the new attribute is ignored.  Or the RADIUS
server could ignore the attribute when sent by a RADIUS client, with no
ill effect.

b) Respecify the attribute in a way that its use can be negotiated and
the RADIUS server can be guaranteed that if sent and not understood, the
right thing will happen (e.g. no service will be granted to the user).
There are proposals on the table that provide for this (e.g. Jari's
proposal for extended attributes).

--
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, 16 Jul 2004 05:23:32 +0000
Date: Thu, 15 Jul 2004 22:21:00 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Barney Wolff <[email-masked]>
cc: [email-masked]
Subject: Re: NAI decoration: User Identity issues

> > Class attributes could change over the lifetime of even a session because
> > class attribute may store stuff other then just  the User Alias.  So you
> > cant use it as the User's Identity.

Depends who "you" is.  Presumably, the RADIUS server can use it, since it
sent the Class attribute.  But I think the point is that the RADIUS client
can't be sure that the Class attribute contains a billable identity. If
in addition the User-Name does not contain a billable identity (e.g.
privacy) then the RADIUS client has no assurance of billability.

> all the world's NAS's have to be upgraded?

This raises the question about whether the billable-identity is an
optional or mandatory attribute.  My take is that it is optional.
Here's why. If it is sent by the RADIUS server and not understood
by the NAS, RFC 2865 states clearly that it MAY be ignored.

My understanding is that the issue here is on the RADIUS client side,
because if the RADIUS server wanted to make sure that got the opaque
string back in the accounting record, it could always send that opaque
blob *both* in the billable-identity attribute and in Class.  That way,
if the RADIUS client cared about billable-identity, it would have it;
if not, it would ignore it.

If you buy this logic, then no NAS upgrade is required.

> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

If the above argument isn't convincing, and we conclude that this
attribute is Mandatory, then we have an issue.  RFC 2865 doesn't
support Mandatory attributes.  There are a number of proposals
on the table to fix this, however (e.g. Jari's proposal for a
new attribute format with an 'M' bit).

--
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, 16 Jul 2004 01:15:50 +0000
Date: Thu, 15 Jul 2004 21:15:27 -0400
From: Barney Wolff <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: "'Bernard Aboba'" <[email-masked]>, "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: NAI decoration: User Identity issues

On Thu, Jul 15, 2004 at 04:39:22PM -0400, Avi Lior wrote:
> A UserAlias can contain some opaque value provided that the HomeNetwork
> asserts that it represents a user for a period of time.  That is it will not
> change over a period of time.  The period of time could be a month or even
> longer.
> 
> Class attributes could change over the lifetime of even a session because
> class attribute may store stuff other then just  the User Alias.  So you
> cant use it as the User's Identity.

So, to support a particular business model, namely fixed per-user billing,
all the world's NAS's have to be upgraded?  The business model could be
accomodated by a private agreement on the use of Class between the
intermediary and its customers, with no impact on the NAS.

If all NAS's are not forced to upgrade, how will the server know whether
it can include User-Alias?

-- 
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: Thu, 15 Jul 2004 20:46:38 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: Avi Lior <[email-masked]>, "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 16:46:26 -0400

Hi Barney,

See my comments inline:

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 3:56 PM
> To: Bernard Aboba
> Cc: Avi Lior; Blair T. Bullock; [email-masked]
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> On Thu, Jul 15, 2004 at 12:06:36PM -0700, Bernard Aboba wrote:
> > > The intent of User-Alias in the draft (note the draft calls it 
> > > User-Alias as opposed to Billable-Identity) is to allow 
> > > intermediaries to associate this AAA transaction with an 
> actual User 
> > > without revealing the identity of the user.  It's a handle to a 
> > > user.
> > 
> > So this atribute is only for use by proxies?
> > 
> > > Note the draft allows the home network to put anything it 
> wants in 
> > > there including the true identity of the user.
> > 
> > If there is no guarantee that this is a billable identity, it is 
> > indistinguishable from the Class atribute.
> 
> I guess the question is whether there is a long-term 
> one-to-one relationship between User-Alias and the user's 
> "true" identity.  If there is, then attackers can gain 
> information of some value by correlating different accesses 
> resulting in the same User-Alias.  If not, then indeed 
> User-Alias is no different than Class.

This is up to the home operator to determine.  He can put in the User-Alias
a long lived identity or he can choose a short lived on so that it becomes
more difficult to correlate between the User-Alias and the true identity.

> > > Class attribute would not work because Intermediaries 
> can't use the 
> > > class attribute generated by a server.
> > 
> > Why can't they use it? There is no obstacle.
> 
> I think the resistance is that Class is opaque.  But if 
> User-Alias is opaque too, in the sense that the server can 
> put anything in it, that might change from one access to the 
> next for the same user, then User-Alias is not useful for 
> aggregating session statistics.

Well Class is not usable because one the specification say that it should
not be used but also it can contain other things in it so that it can not be
used as a User-Alias.

For example on one invocation:
Class=123.45.234.134,JOE234
On another AAA transaction on behalf to the same user:
Class=789.34.453.122,JOE234

So although it's the same user the class attribute has some different values
in it.

The only way that class could be used is to specify what should go in it and
how it should be formatted. I don't think we want to go there.

--
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, 15 Jul 2004 20:39:28 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 16:39:22 -0400

A UserAlias can contain some opaque value provided that the HomeNetwork
asserts that it represents a user for a period of time.  That is it will not
change over a period of time.  The period of time could be a month or even
longer.

Class attributes could change over the lifetime of even a session because
class attribute may store stuff other then just  the User Alias.  So you
cant use it as the User's Identity.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 3:37 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > It would seem to me that in order to function as a billing 
> > reconciliation mechanism (see Roy Albert's response) such 
> an attribute
> > (User-Alias) MUST NOT be decorated or modified by intermediaries.
> 
> Yes.
> 
> > Could someone please review the technical (and business) 
> reasons that 
> > State could not serve this requirement?  Is it that State 
> is supposed 
> > to be an opaque object?  Is it that State is not required 
> to contain 
> > printable ASCII suitable for inclusion on billing statements?
> 
> I think that's the reason.  Basically, the local operator 
> needs to be assured that it has a billable identity on hand 
> before providing service. If privacy is being used, the 
> User-Name may not contain a billable identity, and the local 
> operator may not be able to determine from the Class, State, 
> etc. attribute whether a billable identity is present or not.
> 
> For example, what if the NAS receives 3 Class/State attributes:
> 
> [email-masked]
> 82673F0D2745037126@BH239487sdkd2jd
> ToBeOrNotToBe.Shakespeare
> 
> Which one of these 3 attribute is the billable identity?  
> Does the NAS have to parse the attributes and determine 
> which, if any, comply with the grammar of RFC 2486bis?  
> Remember, the problem exists not on the RADIUS server (which 
> presumably can sort things out) but on the RADIUS client that 
> is trying to figure out if it is going to get paid.
> 
> Of course, exactly the same problems occur if a new attribute 
> is defined that can contain "anything", and can be sent 
> multiple times by the RADIUS server.
> 
> In summary:
> 
> * The problem occurs when Privacy is used and the User-Name 
> cannot be used
>   as a billable identity by the local operator.
> 
> * If sent in the Access-Accept, the User-Name attribute is 
> included in the
>   accounting record.
> 
> * Since the User-Name attribute sent by the RADIUS server is 
> undecorated,
>   it may cause mis-routing of accounting packets. So the
>   RADIUS server may not wish to send the User-Name attribute.
> 
> * The Billable-Identity attribute if sent by the RADIUS server, is
>   guaranteed to contain a billable identity.  It MUST NOT be modified
>   by intermediaries, and if received, is placed in the 
> accounting record
>   by the NAS.
> 
> * In all cases, the User-Name MUST be included in the 
> Accounting-Record.
> 
> --
> 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, 15 Jul 2004 20:33:48 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Extension for Management Authorization Draft
Date: Thu, 15 Jul 2004 16:33:43 -0400
From: "Nelson, David" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff writes...=20

> I agree completely with split-horizon.  That's why I'm uncomfortable
with
> SSO.  I'd be much happier if the outside user had to go through two
> stages, one to get "inside" and the next to do things on the NAS.

I agree that three are potential security issues with SSO in a
multi-party proxy RADIUS environment.  I also believe that SSO has real
value and applicability in enterprise environments, which typically have
a single administrative domain.  For that reason, I think it is worthy
of consideration.  The issues you raise can be addressed effectively
using the split-horizon approach.

-- 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, 15 Jul 2004 20:33:11 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Bernard Aboba <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 16:33:08 -0400

Hi David,

As related to my previous comments, RADIUS is a hop by hop protocol not an
end to end protocol.

So a MUST may not work here.  A SHOULD would probably work.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 3:23 PM
> To: Bernard Aboba; Avi Lior
> Cc: [email-masked]
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > And if intermediaries decorate this attribute then you have 
> > re-introduced all the problems that already existed with User-Name.
> 
> It would seem to me that in order to function as a billing 
> reconciliation mechanism (see Roy Albert's response) such an attribute
> (User-Alias) MUST NOT be decorated or modified by intermediaries.
> 
> Could someone please review the technical (and business) 
> reasons that State could not serve this requirement?  Is it 
> that State is supposed to be an opaque object?  Is it that 
> State is not required to contain printable ASCII suitable for 
> inclusion on billing statements?

--
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, 15 Jul 2004 20:31:16 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 16:30:50 -0400

See inline.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 3:14 PM
> To: Avi Lior
> Cc: 'Nelson, David'; [email-masked]
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > The details of what is placed in the User-Alias will be worked out 
> > between the operators when they negotiate their roaming agreements.
> 
> If this were the case then the Class attribute would suffice. 
>  To distinguish itself from Class, the local operator MUST be 
> sure that a billable identity is contained within the 
> attribute.  If it "could be anything" then this assurance 
> does not exist (as it does not exist for Class).  Introducing 
> multiple attribute also clouds the picture. How does the 
> operator know which one (if any) of the operators contains a 
> billable identity?

Class attribute cannot function as the User Alias.

Intermediaries should not look at the contents of the class attribute. Or am
I missing something?  So if I cant look inside it how can I use it to
represent the User-Alias?
 
> And if intermediaries decorate this attribute then you have 
> re-introduced all the problems that already existed with User-Name.

I never said that intermediaries should decorate this attribute.

But remember that RADIUS is a hop by hop protocol and Intermediaries are
allowed to make changes to the packet (in either direction) as it progress
between the NAS and the Home server.

Related to this Bernard also stated:
>No. The User-Name attribute is not re-written by intermediaries when sent
in an Access-Accept. 

I disagree.  Can you show me where this is specified?

--
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, 15 Jul 2004 19:56:43 +0000
Date: Thu, 15 Jul 2004 15:56:27 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: Avi Lior <[email-masked]>, "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: Re: NAI decoration: User Identity issues

On Thu, Jul 15, 2004 at 12:06:36PM -0700, Bernard Aboba wrote:
> > The intent of User-Alias in the draft (note the draft calls it User-Alias as
> > opposed to Billable-Identity) is to allow intermediaries to associate this
> > AAA transaction with an actual User without revealing the identity of the
> > user.  It's a handle to a user.
> 
> So this atribute is only for use by proxies?
> 
> > Note the draft allows the home network to put anything it wants in there
> > including the true identity of the user.
> 
> If there is no guarantee that this is a billable identity, it is
> indistinguishable from the Class atribute.

I guess the question is whether there is a long-term one-to-one relationship
between User-Alias and the user's "true" identity.  If there is, then
attackers can gain information of some value by correlating different
accesses resulting in the same User-Alias.  If not, then indeed User-Alias
is no different than Class.

> > Class attribute would not work because Intermediaries can't use the class
> > attribute generated by a server.
> 
> Why can't they use it? There is no obstacle.

I think the resistance is that Class is opaque.  But if User-Alias is
opaque too, in the sense that the server can put anything in it, that
might change from one access to the next for the same user, then User-Alias
is not useful for aggregating session statistics.

> > The user-name can't be used because in an Access-Request it may contain no
> > useful information and in an Access- Accept it could be completely
> > re-written by intermediaries.
> 
> No. The User-Name attribute is not re-written by intermediaries when sent
> in an Access-Accept.  If it were, then Blair's problem wouldn't exist
> (mis-routing), and there would be no need for another attribute.
> 
> Bottom line:  User-Alias does not appear to meet the requirements of the
> problem that has been posed, and seems to introduce lots of new issues.

Agreed.
Barney

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

Delivery-date: Thu, 15 Jul 2004 19:40:01 +0000
Date: Thu, 15 Jul 2004 15:39:57 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Extension for Management Authorization Draft

On Thu, Jul 15, 2004 at 10:48:41AM -0400, Nelson, David wrote:
> A follow-up thought...
> 
> > > Suppose we're in a proxy situation and the user's home 
> > > RADIUS server decides to grant administrative access to
> > > a provider's NAS?
> > 
> > There may be additional text required in the Proxy Considerations
> > portion of the draft. However, today we have the Admin Service-Type
> that
> > grants "super-user" or privileged access to the management CLI of the
> > NAS.  How would the issues you raise be different for that attribute?
> 
> There's another way to think about this problem.  That is the concept of
> "split-horizon" RADIUS authentication, wherein one RADIUS server [farm]
> is used to provision network access through a NAS and a second RADIUS
> server [farm] is used to provision management access into the NAS.  The
> issue you raise is certainly valid in various Proxy RADIUS, multi-party
> environments.  It would likely not be an issue in most enterprise
> environments.  I do think the issue exists today with the NAS-Prompt and
> Admin Service-Types.

I agree completely with split-horizon.  That's why I'm uncomfortable with
SSO.  I'd be much happier if the outside user had to go through two
stages, one to get "inside" and the next to do things on the NAS.

Regards,
Barney

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

Delivery-date: Thu, 15 Jul 2004 19:39:00 +0000
Date: Thu, 15 Jul 2004 12:36:47 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Nelson, David" <[email-masked]>
cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues

> It would seem to me that in order to function as a billing
> reconciliation mechanism (see Roy Albert's response) such an attribute
> (User-Alias) MUST NOT be decorated or modified by intermediaries.

Yes.

> Could someone please review the technical (and business) reasons that
> State could not serve this requirement?  Is it that State is supposed to
> be an opaque object?  Is it that State is not required to contain
> printable ASCII suitable for inclusion on billing statements?

I think that's the reason.  Basically, the local operator needs to be
assured that it has a billable identity on hand before providing service.
If privacy is being used, the User-Name may not contain a billable
identity, and the local operator may not be able to determine from the
Class, State, etc. attribute whether a billable identity is present or
not.

For example, what if the NAS receives 3 Class/State attributes:

[email-masked]
82673F0D2745037126@BH239487sdkd2jd
ToBeOrNotToBe.Shakespeare

Which one of these 3 attribute is the billable identity?  Does the NAS
have to parse the attributes and determine which, if any, comply with the
grammar of RFC 2486bis?  Remember, the problem exists not on the RADIUS
server (which presumably can sort things out) but on the RADIUS client
that is trying to figure out if it is going to get paid.

Of course, exactly the same problems occur if a new attribute is defined
that can contain "anything", and can be sent multiple times by the RADIUS
server.

In summary:

* The problem occurs when Privacy is used and the User-Name cannot be used
  as a billable identity by the local operator.

* If sent in the Access-Accept, the User-Name attribute is included in the
  accounting record.

* Since the User-Name attribute sent by the RADIUS server is undecorated,
  it may cause mis-routing of accounting packets. So the
  RADIUS server may not wish to send the User-Name attribute.

* The Billable-Identity attribute if sent by the RADIUS server, is
  guaranteed to contain a billable identity.  It MUST NOT be modified
  by intermediaries, and if received, is placed in the accounting record
  by the NAS.

* In all cases, the User-Name MUST be included in the Accounting-Record.

--
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, 15 Jul 2004 19:37:10 +0000
Date: Thu, 15 Jul 2004 15:36:55 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Extension for Management Authorization Draft

On Thu, Jul 15, 2004 at 09:37:09AM -0400, Nelson, David wrote:
> Barney Wolff writes...
> 
> > It seems to in effect provide single-sign-on for NAS administration.
> 
> I had not thought of this proposal in terms of single-sign-on, as it
> does not include additional authentication elements, but rather
> additional authorization elements, but, that may indeed be a valid way
> to think about the issue.
> 
> > I infer
> > this, because if there were further authentication steps intended
> after
> > the user was communicating with the NAS, that could be accomplished
> > simply with an appropriate Filter-Id which allowed the necessary
> packets
> > to pass - on the assumption, which I consider the only sane one, that
> > ordinary users are prevented from sending any packets whatsoever to
> > the NAS itself.
> 
> One *could* implement such functionality (at least in part) using the
> Filter-ID attribute.  IMHO, this would be over-loading the Filter-ID
> semantics with additional functionality.  My interpretation is that the
> Filter-ID attribute provisions the packet forwarding service of the NAS.
> One *could* decide that the local management interfaces (e.g. the local
> IP stack) exist behind the filter, from any port on the NAS (Console,
> WAN, LAN, WLAN, etc).  I think it would be better to introduce explicit
> attributes to authorize various forms and levels of management access,
> rather than over-loading the definition of Filter-ID.

I'm not proposing overloading the definition of Filter-ID, simply that
filters can exist that allow access to nas-ip/udp/161, nas-ip/tcp/443,
etc.  That is a simple and straightforward use of Filter-Id without
changing its meaning.

> > But SSO for NAS administration strikes me as a bad idea.  The NAS
> already
> > has authentication and authorization procedures in place to enable and
> > control administration from within the network.
> 
> Yes, but at the level of granularity I'm proposing those control and
> authorization functions are entirely local to the NAS.  The intent of
> this proposal is to allow those local functions to be performed by
> RADIUS remote AAA.  The same reasons we found RADIUS was useful in the
> initial instance, e.g. network scalability and centralized control of
> access, motivate this proposal. 
> 
> > Why should these be
> > bypassed simply because the user has "dialed" in?
> 
> I'm confused about two points in this question.  First, the access
> control is being "bypassed" solely to the extent that RADIUS, as
> currently defined, "bypasses" local password authentication and moves it
> to a server-based system.  I think there is agreement that that is a
> Good Thing (tm).   Second, none of the elements of the proposal are tied
> in any way, that I can see, to "dial-in".  Could you please elaborate?

Ok, what I missed in reading the draft was that the NAS can send stuff
in the Access-Request to indicate what service is being requested.  That
covers the scenario where the user is inside, accesses the NAS via
telnet/ssh/http/ssl/snmpv{1,3} and the NAS uses RADIUS rather than eg
TACACS to authenticate+authorize the user.  I agree that extending the
service types to indicate how the user got to the NAS is helpful.  My
concern is really in the access from outside scenario.  I have a
superstitious fear of SSO.

> > Do we really trust
> > RADIUS authentication as much as the NAS's native procedures?
> 
> I would *hope* so.  Isn't that level of trust fundamental to the RADIUS
> model?
> 
> > Suppose
> > we're in a proxy situation and the user's home RADIUS server decides
> to
> > grant administrative access to a provider's NAS?
> 
> There may be additional text required in the Proxy Considerations
> portion of the draft. However, today we have the Admin Service-Type that
> grants "super-user" or privileged access to the management CLI of the
> NAS.  How would the issues you raise be different for that attribute?

The issues would be identical.  As I recall, the Admin service types go
back to a time before people had thought seriously about proxies.  I
wonder how many existing proxies check for servers authorizing more
than the access network owner would like.

> > Is dialup administration so common that it's important to allow SSO?
> 
> I did not have "dial-up" access in mind.  In fact, the primary driver is
> LAN access via Telnet, SSH, SNMPv3, etc.  Although the draft would apply
> to local console access and dial-up access, that isn't the design
> center.

Inside access seems fine, and reflects the reality that lots of people
have written RADIUS clients to do such things as Unix login validation.

Regards,
Barney

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

Delivery-date: Thu, 15 Jul 2004 19:23:06 +0000
Content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 15:22:38 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Avi Lior" <[email-masked]>
Cc: <[email-masked]>

> And if intermediaries decorate this attribute then you have
> re-introduced all the problems that already existed with User-Name.

It would seem to me that in order to function as a billing
reconciliation mechanism (see Roy Albert's response) such an attribute
(User-Alias) MUST NOT be decorated or modified by intermediaries.

Could someone please review the technical (and business) reasons that
State could not serve this requirement?  Is it that State is supposed to
be an opaque object?  Is it that State is not required to contain
printable ASCII suitable for inclusion on billing statements?

-- 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, 15 Jul 2004 19:16:43 +0000
Date: Thu, 15 Jul 2004 12:14:21 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues

> The details of what is placed in the User-Alias will be worked out between
> the operators when they negotiate their roaming agreements.

If this were the case then the Class attribute would suffice.  To
distinguish itself from Class, the local operator MUST be sure that a
billable identity is contained within the attribute.  If it "could be
anything" then this assurance does not exist (as it does not exist for
Class).  Introducing multiple attribute also clouds the picture. How does
the operator know which one (if any) of the operators contains a billable
identity?

And if intermediaries decorate this attribute then you have
re-introduced all the problems that already existed with User-Name.

--
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, 15 Jul 2004 19:08:52 +0000
Date: Thu, 15 Jul 2004 12:06:36 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Avi Lior <[email-masked]>
cc: "'Barney Wolff'" <[email-masked]>, "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues

> The intent of User-Alias in the draft (note the draft calls it User-Alias as
> opposed to Billable-Identity) is to allow intermediaries to associate this
> AAA transaction with an actual User without revealing the identity of the
> user.  It's a handle to a user.

So this atribute is only for use by proxies?

> Note the draft allows the home network to put anything it wants in there
> including the true identity of the user.

If there is no guarantee that this is a billable identity, it is
indistinguishable from the Class atribute.

> Class attribute would not work because Intermediaries can't use the class
> attribute generated by a server.

Why can't they use it? There is no obstacle.

> The user-name can't be used because in an Access-Request it may contain no
> useful information and in an Access- Accept it could be completely
> re-written by intermediaries.

No. The User-Name attribute is not re-written by intermediaries when sent
in an Access-Accept.  If it were, then Blair's problem wouldn't exist
(mis-routing), and there would be no need for another attribute.

Bottom line:  User-Alias does not appear to meet the requirements of the
problem that has been posed, and seems to introduce lots of new issues.

--
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, 15 Jul 2004 19:04:29 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 15:04:21 -0400

The Home Network can set the User Alias to a number of values depending on
the business need.

The User-Alias could be a long lived billing account or it could be the
subscribers phone number etc. 

But if privacy is an issue it can be set to some unique short lived value
that the home network asserts represents the user for a some period of time.
Long enough to serve the business purpose, short enough to offer privacy
protection.  This information can be used for business purposes that you
have described while maintain privacy.

The details of what is placed in the User-Alias will be worked out between
the operators when they negotiate their roaming agreements.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 2:19 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: RE: NAI decoration: User Identity issues
> 
> 
> > The intent of User-Alias in the draft (note the draft calls it
> User-Alias
> > as opposed to Billable-Identity) is to allow intermediaries to
> associate
> > this AAA transaction with an actual User without revealing the
> identity
> > of the user.  It's a handle to a user.
> 
> And from a business perspective the intermediates do what 
> with the User-Alias?  Use it to prepare a detailed monthly 
> billing statement for each home entity, including session 
> times for all the User-Aliases? Just curious.
> 
> -- 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, 15 Jul 2004 18:56:23 +0000
content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 11:53:03 -0700
From: "Roy Albert" <[email-masked]>
To: "Nelson, David" <[email-masked]>, "Avi Lior" <[email-masked]>
cc: [email-masked]

Speaking as a trusted intermediary:

iPass supports a variety of billing models including usage based,
per-user flat rate, and pooled flat rate. The flat rate billing plans
require that each unique user be identifiable, with the identification
being persistent over a billing period (most often a month).

Even for straight usage based billing plans, it is necessary to have a
unique persistent identification for each user in order to detect
unusual roaming patterns such as concurrent sessions or someone's
credentials being used in geographically distributed locations.

To specifically answer your question below, we produce detailed call
records for every session that runs across our network. Many of our
customers correlate the information we give them down to the individual
user level. Enterprises use this to understand what their power-users
are up to and ISPs use this to bill from.

In summary, whatever mechanisms are adopted for privacy protection need
to support persistent unique identification of a given user over an
arbitrary billing period/usage period and also need to maintain the
integrity of the routing information in the original NAI.

-Roy=20

Roy D. Albert
[email-masked]
=20

-----Original Message-----
From: Nelson, David [mailto:[email-masked]]=20
Sent: Thursday, July 15, 2004 11:19 AM
To: Avi Lior
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues

> The intent of User-Alias in the draft (note the draft calls it
User-Alias
> as opposed to Billable-Identity) is to allow intermediaries to
associate
> this AAA transaction with an actual User without revealing the
identity
> of the user.  It's a handle to a user.

And from a business perspective the intermediates do what with the
User-Alias?  Use it to prepare a detailed monthly billing statement for
each home entity, including session times for all the User-Aliases?
Just curious.

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

--
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, 15 Jul 2004 18:18:55 +0000
Content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 14:18:47 -0400
From: "Nelson, David" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Cc: <[email-masked]>

> The intent of User-Alias in the draft (note the draft calls it
User-Alias
> as opposed to Billable-Identity) is to allow intermediaries to
associate
> this AAA transaction with an actual User without revealing the
identity
> of the user.  It's a handle to a user.

And from a business perspective the intermediates do what with the
User-Alias?  Use it to prepare a detailed monthly billing statement for
each home entity, including session times for all the User-Aliases?
Just curious.

-- 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, 15 Jul 2004 18:10:03 +0000
From: Avi Lior <[email-masked]>
To: 'Barney Wolff' <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 14:09:48 -0400

Hi Barney,

Let me offer an explanation.

The intent of User-Alias in the draft (note the draft calls it User-Alias as
opposed to Billable-Identity) is to allow intermediaries to associate this
AAA transaction with an actual User without revealing the identity of the
user.  It's a handle to a user.

Note the draft allows the home network to put anything it wants in there
including the true identity of the user.

Class attribute would not work because Intermediaries can't use the class
attribute generated by a server.

The user-name can't be used because in an Access-Request it may contain no
useful information and in an Access- Accept it could be completely
re-written by intermediaries.

Hope this helps,

Avi

> -----Original Message-----
> From: Barney Wolff [mailto:[email-masked]] 
> Sent: Thursday, July 15, 2004 1:53 PM
> To: Bernard Aboba
> Cc: Blair T. Bullock; [email-masked]
> Subject: Re: NAI decoration: User Identity issues
> 
> 
> On Thu, Jul 15, 2004 at 09:38:12AM -0700, Bernard Aboba wrote:
> > 
> > In addition to the billable identity attribute though, I 
> think we will 
> > probably need to explain the logic behind it and provide 
> advice on how 
> > User-Name and Class can/should be used, to make sure people 
> understand 
> > the issues.  That might go in the "RADIUS issues and 
> solutions" draft.
> 
> I'm a little confused.  Can someone state clearly what 
> problem is being solved by Billing-Identity that would not 
> just as well be solved by leaving User-Name alone and putting 
> any altered name in Class?  Is it just that people perceive a 
> need for entities other than the home authentication and 
> accounting servers to know the "true" identity of the user?  
> If that were all, I'd push back, asking why it's anybody's 
> business other than those home servers'.
> 
> If Billing-Identity is intended for detailed cost 
> accumulation, perhaps it should be called 
> Billing-Accumulator-Id instead.  But in any case, it would 
> seem that it has meaning only within the scope of the server 
> that generates it; otherwise, ford.com's server can routinely 
> generate Billing-Identities that say @chevy.com.  Presumably 
> that's why we don't want to overwrite the original User-Id.  
> Is leaving User-Id alone enough to provide auditability, or 
> should we introduce a Diameter-style audit trail that records 
> how the Access-Accept got back to the NAS?
> 
> -- 
> Barney Wolff         http://www.databus.com/bwresume.pdf
> I'm available by contract or FT, in the NYC metro area or via 
> the 'Net.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

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

Delivery-date: Thu, 15 Jul 2004 17:53:39 +0000
Date: Thu, 15 Jul 2004 13:53:27 -0400
From: Barney Wolff <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: "Blair T. Bullock" <[email-masked]>, [email-masked]
Subject: Re: NAI decoration: User Identity issues

On Thu, Jul 15, 2004 at 09:38:12AM -0700, Bernard Aboba wrote:
> 
> In addition to the billable identity attribute though, I think we will
> probably need to explain the logic behind it and provide advice on how
> User-Name and Class can/should be used, to make sure people understand the
> issues.  That might go in the "RADIUS issues and solutions" draft.

I'm a little confused.  Can someone state clearly what problem is being
solved by Billing-Identity that would not just as well be solved by
leaving User-Name alone and putting any altered name in Class?  Is it
just that people perceive a need for entities other than the home
authentication and accounting servers to know the "true" identity of
the user?  If that were all, I'd push back, asking why it's anybody's
business other than those home servers'.

If Billing-Identity is intended for detailed cost accumulation, perhaps
it should be called Billing-Accumulator-Id instead.  But in any case,
it would seem that it has meaning only within the scope of the server
that generates it; otherwise, ford.com's server can routinely generate
Billing-Identities that say @chevy.com.  Presumably that's why we don't
want to overwrite the original User-Id.  Is leaving User-Id alone
enough to provide auditability, or should we introduce a Diameter-style
audit trail that records how the Access-Accept got back to the NAS?

-- 
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: Thu, 15 Jul 2004 17:04:19 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Blair T. Bullock'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 12:03:48 -0500

I must admit that some of that went over my head, but let me see if I understood the problem, I would appreciate it very much, if somebody can tell me if this is correct:

The user uses an aliased user-name (the decorated NAI) to hide its true identity from attackers. The decorated NAI (user-name (1), true?) is routable through AAA infrastructure.
However, the AAA server and its authentication and accounting mechanisms operate use a separate billable identity as the index to their record & databases. 
The user originally does not know its billable identity or won't signal it in the clear.
A NAS receiving an authentication/ service request from the user, gets a decorated NAI from the user, builds an access request with that identity. A NAS in the roaming environment does not have any state on the user, who is contacting the NAS for the first time, neither does the NAS have a mapping rule, so the auth. request only includes the decorated NAI.
The AAA server based on its records finds the billable identity from the decorated NAI and responds with an access accept that includes the billable identity (either tunneled inside the NAI or along with that NAI, i.e. as two attributes).
I have a hard time seeing how anybody else but the AAA server can do this translation or rewrite (during the first authentication request) without having a state and without breaking the signaling. It seems that the access accept would have to send both identities to the NAS for future use and only then in the following access requests, the NAS can do the rewrites itself.

Is this understanding correct?

Thanks in advance,

Madjid
-----Original Message-----
From: Blair T. Bullock [mailto:[email-masked]]
Sent: Wednesday, July 14, 2004 4:42 PM
To: Nakhjiri Madjid-MNAKHJI1; Adrangi, Farid; Bernard Aboba
Cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues

The problem with Home Authentication persistence of additional
decorations is that it must be provisioned that way from the start with
Aggregator and Reseller information in order to 'normalize' the
user-name.  A provisioning nightmare.

For the Aggregation proxy systems to re-decorate the user-name as it
returns in the Access-Accept requires statefulness between auth and acct
events; undesirable.

Someone said:

"In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute."

Hallelujah, I wholeheartedly concur with this statement.  It is
basically the same concept as the proposed Class usage for the purposes
of user-name accounting data reflection, but specifically dedicated to
the resolution of RADIUS-routable and billable identities in Tunneled
EAP methods.

There needs to be a distinction between the User-Name used for RADIUS
routing which must go unmodified and appear as originally presented to
the NAS and an Authenticated-User which is the Billable authenticated
user applied to the accounting in a separate attribute with a value
derived from the User-Name in the Access-Accept.  This way the OTA
transmitted routable user-name may be an anonymous/alias, decorated
promiscuously with no ill-effect and all AAA events take the same path
from a RADIUS standpoint...  While also maintaining an Authenticator
protected billable identity (or alias) which is not transmitted over the
air, but represented by the NAS from the value of the User-Name in the
Access-Accept.  

>From a Roaming Aggregation standpoint, the only other alternative is to
not pass the user-name back in the Access-accept to maintain the
originally presented NAI.  Also, to maintain service oversight and fraud
detection with Tunneled-Methods, there will most likely need to be
checking to ensure that the Inner and Outer identities are identical at
a 'root' NAI level (regardless of additional chained suffixes or
prefixes to facilitate routing and session data) to protect against
hackers.  Such equivalency checking would then preclude "anonymous"
transport unless specifically handled by the intermediary.

-Blair

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
Sent: Wednesday, July 14, 2004 12:30 PM
To: 'Adrangi, Farid'; Bernard Aboba
Cc: [email-masked]
Subject: NAI decoration: User Identity issues

Can somebody point me to a drafts/ literature describing different
methods of NAI decoration (prefix/ suffix based) and their rewrites by
the AAA infrastructure?

Thank you in advance,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: RE: User Identity issues

Hi Bernard,
Please see my responses inline.
BR,
Farid

> 
> As Blair notes, there are cases where the Accounting data needs to 
> follow the same path as Authorization, and User-Name rewriting can 
> break that.

It depends.  The routing is done based on the realm and/or prefix/suffix
used for NAI decoration.  In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI.  For example, if the AAA
server receives UserName value [email-masked] in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like [email-masked] , where 2345 is the billable
identity.  This should cause the accounting packets follow the same path
as the authorization.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
[email-masked].  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be [email-masked].  In this case, even if the AAA server puts
the received UserName value as is (i.e., [email-masked]) in the
Access-Accept, this will appear to NAS like UserName rewrite.  

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/[email-masked]) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/[email-masked].  The AAA server can return
intermediary.com/[email-masked] or preferably
intermediary.com/[email-masked] (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.

> This argument against User-Name rewrite is more compelling than NAS 
> compatibility or billing system compatibility since new attributes 
> will also require changes to NASen and billing systems.
> 
> I'd suggest that we need a discussion of the issues so that we can 
> understand when it is safe to do User-Name rewriting, and when this 
> can cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute.  

> 
> The major impetus for User-Name rewrite as I understand it is for use 
> in privacy.  There are also the cosmetic cases that Dave Mitton has 
> mentioned (e.g. changing case) but I think these are relatively 
> benign.
> 
> So how do we go forward?  There may need to be an errata submitted for

> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 is 
> somewhat misleading; User-Name rewriting is not required for the 
> routing of the Access-Accept back to the NAS;  Proxy State can handle 
> this.
> 

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept.  

> I'd also like to understand if there are guidelines that a server can 
> use to determine when User-Name rewrite is safe and when it isn't.  
> For example, what if a user attempts to protect Privacy in a network 
> set up as Blair has suggested?  What breaks?  Is there a way for the 
> server to detect the situation and not cause problems?
> 
> I also think that we need to discuss this in the Network Discovery 
> Problem Statement, since if a user desires to influence the mediating 
> network, then accounting supporting that decision needs to be carried 
> out.
> 
> 

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

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

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

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

Delivery-date: Thu, 15 Jul 2004 16:40:24 +0000
Date: Thu, 15 Jul 2004 09:38:12 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Blair T. Bullock" <[email-masked]>
cc: [email-masked]
Subject: RE: NAI decoration: User Identity issues

> Does everyone else have the distinct feeling we just avoided a huge train wreck?

In this case, I think there is an existing problem that people are just
beginning to appreciate.  So perhaps the train wreck hasn't happened yet.

In addition to the billable identity attribute though, I think we will
probably need to explain the logic behind it and provide advice on how
User-Name and Class can/should be used, to make sure people understand the
issues.  That might go in the "RADIUS issues and solutions" draft.

--
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, 15 Jul 2004 15:54:08 +0000
Date: Thu, 15 Jul 2004 08:51:32 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: "Blair T. Bullock" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: Re: NAI decoration: User Identity issues

> And then a question from your NAIbis draft editor: does
> this resolve the issue that Farid raised earlier about
> suffix-based decoration being rewritten by proxies and
> then returned in an Access-Accept, causing problems for
> the accounting requests? I think it does, but it seems
> that we may have to, in addition, publish an RFC 3579 errata
> to indicate that returned User-Name attributes should not
> be used for accounting requests. Comments?

I'd say that it is at the descretion of the RADIUS server whether to
return the User-Name in the Access-Accept or not.  If it is returned, the
NAS includes it in accounting requests.  If not, it uses the original
User-Name, + Class + Billable Identity if those are available.  I don't
think there's any need for an RFC 3579 errata.

--
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, 15 Jul 2004 14:49:01 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Extension for Management Authorization Draft
Date: Thu, 15 Jul 2004 10:48:41 -0400
From: "Nelson, David" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

A follow-up thought...

> > Suppose we're in a proxy situation and the user's home=20
> > RADIUS server decides to grant administrative access to
> > a provider's NAS?
>=20
> There may be additional text required in the Proxy Considerations
> portion of the draft. However, today we have the Admin Service-Type
that
> grants "super-user" or privileged access to the management CLI of the
> NAS.  How would the issues you raise be different for that attribute?

There's another way to think about this problem.  That is the concept of
"split-horizon" RADIUS authentication, wherein one RADIUS server [farm]
is used to provision network access through a NAS and a second RADIUS
server [farm] is used to provision management access into the NAS.  The
issue you raise is certainly valid in various Proxy RADIUS, multi-party
environments.  It would likely not be an issue in most enterprise
environments.  I do think the issue exists today with the NAS-Prompt and
Admin Service-Types.

Regards,

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, 15 Jul 2004 13:37:50 +0000
Content-class: urn:content-classes:message
Subject: RE: RADIUS Extension for Management Authorization Draft
Date: Thu, 15 Jul 2004 09:37:09 -0400
From: "Nelson, David" <[email-masked]>
To: "Barney Wolff" <[email-masked]>
Cc: <[email-masked]>

Barney Wolff writes...

> It seems to in effect provide single-sign-on for NAS administration.

I had not thought of this proposal in terms of single-sign-on, as it
does not include additional authentication elements, but rather
additional authorization elements, but, that may indeed be a valid way
to think about the issue.

> I infer
> this, because if there were further authentication steps intended
after
> the user was communicating with the NAS, that could be accomplished
> simply with an appropriate Filter-Id which allowed the necessary
packets
> to pass - on the assumption, which I consider the only sane one, that
> ordinary users are prevented from sending any packets whatsoever to
> the NAS itself.

One *could* implement such functionality (at least in part) using the
Filter-ID attribute.  IMHO, this would be over-loading the Filter-ID
semantics with additional functionality.  My interpretation is that the
Filter-ID attribute provisions the packet forwarding service of the NAS.
One *could* decide that the local management interfaces (e.g. the local
IP stack) exist behind the filter, from any port on the NAS (Console,
WAN, LAN, WLAN, etc).  I think it would be better to introduce explicit
attributes to authorize various forms and levels of management access,
rather than over-loading the definition of Filter-ID.

> But SSO for NAS administration strikes me as a bad idea.  The NAS
already
> has authentication and authorization procedures in place to enable and
> control administration from within the network.

Yes, but at the level of granularity I'm proposing those control and
authorization functions are entirely local to the NAS.  The intent of
this proposal is to allow those local functions to be performed by
RADIUS remote AAA.  The same reasons we found RADIUS was useful in the
initial instance, e.g. network scalability and centralized control of
access, motivate this proposal.=20

> Why should these be
> bypassed simply because the user has "dialed" in?

I'm confused about two points in this question.  First, the access
control is being "bypassed" solely to the extent that RADIUS, as
currently defined, "bypasses" local password authentication and moves it
to a server-based system.  I think there is agreement that that is a
Good Thing (tm).   Second, none of the elements of the proposal are tied
in any way, that I can see, to "dial-in".  Could you please elaborate?

> Do we really trust
> RADIUS authentication as much as the NAS's native procedures?

I would *hope* so.  Isn't that level of trust fundamental to the RADIUS
model?

> Suppose
> we're in a proxy situation and the user's home RADIUS server decides
to
> grant administrative access to a provider's NAS?

There may be additional text required in the Proxy Considerations
portion of the draft. However, today we have the Admin Service-Type that
grants "super-user" or privileged access to the management CLI of the
NAS.  How would the issues you raise be different for that attribute?

> Is dialup administration so common that it's important to allow SSO?

I did not have "dial-up" access in mind.  In fact, the primary driver is
LAN access via Telnet, SSH, SNMPv3, etc.  Although the draft would apply
to local console access and dial-up access, that isn't the design
center.

Thanks for your time to review the draft and for your thoughtful
comments.

Regards,

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, 15 Jul 2004 08:52:22 +0000
content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Thu, 15 Jul 2004 01:47:22 -0700
From: "Blair T. Bullock" <[email-masked]>
To: [email-masked], "Bernard Aboba" <[email-masked]>
cc: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C46A48.5819CA28
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C46A48.5819CA28
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C46A48.5819CA28--

--
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, 15 Jul 2004 05:17:04 +0000
Date: Thu, 15 Jul 2004 08:11:38 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>
Cc: "Blair T. Bullock" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: Re: NAI decoration: User Identity issues

I have now been convinced that the separation of billable
and routing identities is necessary. So, I support the
creation of an attribute that represents a billable
identity. A number of details still needs to be worked
on, such as exactly what do we say about privacy, what
format(s) are supported for the identity etc.

And then a question from your NAIbis draft editor: does
this resolve the issue that Farid raised earlier about
suffix-based decoration being rewritten by proxies and
then returned in an Access-Accept, causing problems for
the accounting requests? I think it does, but it seems
that we may have to, in addition, publish an RFC 3579 errata
to indicate that returned User-Name attributes should not
be used for accounting requests. Comments?

--Jari

Bernard Aboba wrote:
>>Hallelujah, I wholeheartedly concur with this statement.  It is
>>basically the same concept as the proposed Class usage for the purposes
>>of user-name accounting data reflection, but specifically dedicated to
>>the resolution of RADIUS-routable and billable identities in Tunneled
>>EAP methods.
> 
> 
> This is an important distinction because it allows the local ISP to know
> that a billable identity has been returned without having to parse the
> Class attibute which is supposed to be treated like opaque text.  After
> all, multiple Class attributes can be returned, some of which might
> represent a billable identity, some might not.  How is the local operator
> to know?  So I think a billable identity attribute is required here.
> 
> 
>>the NAS and an Authenticated-User which is the Billable authenticated
> 
> 
> The Billable Identity is an identity used for accounting purposes, not
> authentication.  I hope we're clear on that.
> 
> 
>>from a RADIUS standpoint...  While also maintaining an Authenticator
>>protected billable identity (or alias) which is not transmitted over the
>>air, but represented by the NAS from the value of the User-Name in the
>>Access-Accept.
> 
> 
> In the case of Privacy, it might not relate to the User-Name attribute at
> all.  There is no requirement that they match in any way.
> 
> 
>>not pass the user-name back in the Access-accept to maintain the
> 
> 
> That is always the RADIUS server choice, because it is optional.
> 
> 
>>checking to ensure that the Inner and Outer identities are identical at
>>a 'root' NAI level (regardless of additional chained suffixes or
> 
> 
> Careful.  These identities may not relate to each other.
> 
> 
> --
> 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, 15 Jul 2004 01:36:03 +0000
Date: Wed, 14 Jul 2004 21:35:44 -0400
From: Barney Wolff <[email-masked]>
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: RADIUS Extension for Management Authorization Draft

On Wed, Jul 14, 2004 at 05:20:45PM -0400, Nelson, David wrote:
> I have submitted an Internet-Draft entitled "RADIUS Extension for Management Authorization", located at the following URL:
> 
> http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-00.txt
> 
> This is based on work that I presented at the RADEXT BOF at IETF 58.  Interest in this area of work was expressed at the BOF.  I'd like to solicit comment on this initial draft on the list, and get an idea of the potential interest in making this a WG work item, and of others who may have an interest in contributing to the document.

I was not at the BOF, so perhaps am misjudging the intent of the draft.

It seems to in effect provide single-sign-on for NAS administration.
That is, based on RADIUS authentication, the user will be authorized
to administer the NAS without further authentication steps.  I infer
this, because if there were further authentication steps intended after
the user was communicating with the NAS, that could be accomplished
simply with an appropriate Filter-Id which allowed the necessary packets
to pass - on the assumption, which I consider the only sane one, that
ordinary users are prevented from sending any packets whatsoever to
the NAS itself.

But SSO for NAS administration strikes me as a bad idea.  The NAS already
has authentication and authorization procedures in place to enable and
control administration from within the network.  Why should these be
bypassed simply because the user has "dialed" in?  Do we really trust
RADIUS authentication as much as the NAS's native procedures?  Suppose
we're in a proxy situation and the user's home RADIUS server decides to
grant administrative access to a provider's NAS?

Is dialup administration so common that it's important to allow SSO?

Regards,
Barney

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

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

Delivery-date: Wed, 14 Jul 2004 23:16:49 +0000
content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Wed, 14 Jul 2004 16:13:44 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
cc: [email-masked]

Absolutely agreed, Bernard. Good deal.=20

What you describe makes loads of sense and provides a framework for the
necessary flexibility, consistent behavior and reliability when using
mixed standard and tunneled EAP methods.

Thanks y'all for your consideration,=20

Blair

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]=20
Sent: Wednesday, July 14, 2004 3:39 PM
To: Blair T. Bullock
Cc: Nakhjiri Madjid-MNAKHJI1; Adrangi, Farid; [email-masked]
Subject: RE: NAI decoration: User Identity issues

> Hallelujah, I wholeheartedly concur with this statement.  It is=20
> basically the same concept as the proposed Class usage for the=20
> purposes of user-name accounting data reflection, but specifically=20
> dedicated to the resolution of RADIUS-routable and billable identities

> in Tunneled EAP methods.

This is an important distinction because it allows the local ISP to know
that a billable identity has been returned without having to parse the
Class attibute which is supposed to be treated like opaque text.  After
all, multiple Class attributes can be returned, some of which might
represent a billable identity, some might not.  How is the local
operator to know?  So I think a billable identity attribute is required
here.

> the NAS and an Authenticated-User which is the Billable authenticated

The Billable Identity is an identity used for accounting purposes, not
authentication.  I hope we're clear on that.

> from a RADIUS standpoint...  While also maintaining an Authenticator=20
> protected billable identity (or alias) which is not transmitted over=20
> the air, but represented by the NAS from the value of the User-Name in

> the Access-Accept.

In the case of Privacy, it might not relate to the User-Name attribute
at all.  There is no requirement that they match in any way.

> not pass the user-name back in the Access-accept to maintain the

That is always the RADIUS server choice, because it is optional.

> checking to ensure that the Inner and Outer identities are identical=20
> at a 'root' NAI level (regardless of additional chained suffixes or

Careful.  These identities may not relate to each other.

--
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, 14 Jul 2004 22:41:13 +0000
Date: Wed, 14 Jul 2004 15:38:44 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: "Blair T. Bullock" <[email-masked]>
cc: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: RE: NAI decoration: User Identity issues

> Hallelujah, I wholeheartedly concur with this statement.  It is
> basically the same concept as the proposed Class usage for the purposes
> of user-name accounting data reflection, but specifically dedicated to
> the resolution of RADIUS-routable and billable identities in Tunneled
> EAP methods.

This is an important distinction because it allows the local ISP to know
that a billable identity has been returned without having to parse the
Class attibute which is supposed to be treated like opaque text.  After
all, multiple Class attributes can be returned, some of which might
represent a billable identity, some might not.  How is the local operator
to know?  So I think a billable identity attribute is required here.

> the NAS and an Authenticated-User which is the Billable authenticated

The Billable Identity is an identity used for accounting purposes, not
authentication.  I hope we're clear on that.

> from a RADIUS standpoint...  While also maintaining an Authenticator
> protected billable identity (or alias) which is not transmitted over the
> air, but represented by the NAS from the value of the User-Name in the
> Access-Accept.

In the case of Privacy, it might not relate to the User-Name attribute at
all.  There is no requirement that they match in any way.

> not pass the user-name back in the Access-accept to maintain the

That is always the RADIUS server choice, because it is optional.

> checking to ensure that the Inner and Outer identities are identical at
> a 'root' NAI level (regardless of additional chained suffixes or

Careful.  These identities may not relate to each other.

--
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, 14 Jul 2004 22:09:11 +0000
content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Wed, 14 Jul 2004 15:05:39 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
cc: [email-masked]

"The routing is done based on the realm and/or prefix/suffix used for
NAI decoration.  In the context of conveying a billable identity, the
UserName(1) rewrite does not have to impact the realm or prefix/suffix
parts of the decorated NAI.  For example, if the AAA server receives
UserName value [email-masked] in the Access-Request, the AAA
server can convey the billable identity via UserName (1) rewrite like
[email-masked] , where 2345 is the billable identity.  This should
cause the accounting packets follow the same path as the authorization.
"

Assumes that all routing is suffix based in a direct peer-to-peer
relationship.  We don't route every domain to every other domain.  The
constant realm add/remove process is a total nightmare!  Therefore a
chained suffix or prefix is typically used to aggregate unknown suffixes
under a roaming agency:

user@[email-masked]
Or
IPASS/[email-masked]

Either way, if the Access-Accept returns User-Name=[email-masked]
and the accounting is re-written with this User-Name value, it will not
route to the proper AAA exchange. =20

To reiterate some from my last email:

1- maintaining the re-decoration of the User-Name of the Access-Accept
User-Name by the intermediary proxy requires statefulness of all AAA
events.
2- To have the Access-Accept username return the decorated NAI from the
Home AS requires knowledge of the aggregation principles (suffix or
prefix) and provisioning of that information at the Home Authentication
Server so it will normalize the user-name and won't mess-up local
requests. (not to mention what if the Home Network uses multiple
aggregators with different aggregation suffixes and/or prefix).
3 - To route via suffix only with a root NAI as per the RFC user@realm
requires realm add/deletes ad nauseum from now until the end of time.  A
reseller adds a new enterprise realm and we have to update every RADIUS
proxy in the system to tell them it should be routed to our exchange?!
When you have hundreds of networks it is untenable.  Also, what if that
realm can be routed via multiple intermediaries?! =20

Thus the intermediary decoration of user@[email-masked] or
user@[email-masked] (or IPASS/[email-masked] or even
IPASS/[email-masked]@reseller.com) is necessary to address these
footprint aggregation, routing, reselling and billable user resolution
requirements for roaming.  Prefixes and suffix chains serve a very valid
business functions.  NAI decoration must be inclusive of all service
models and is primarily used to eliminate the constant ongoing
provisioning requirements of direct suffix peering.  User@realm is too
simplistic and doesn't reflect all of the business models that have
emerged in our space over the past eight years.

On a side note, what if the inner method authentication simply uses
"john" with no suffix in the user-name?  Accounting will be re-written
as just "john" and it will not route at all, even if there is a direct
suffix relationship between two networks.

Position swapping of any NAI element is right-out bad.

Blair

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]=20
Sent: Wednesday, July 14, 2004 12:30 PM
To: 'Adrangi, Farid'; Bernard Aboba
Cc: [email-masked]
Subject: NAI decoration: User Identity issues

Can somebody point me to a drafts/ literature describing different
methods of NAI decoration (prefix/ suffix based) and their rewrites by
the AAA infrastructure?

Thank you in advance,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: RE: User Identity issues

Hi Bernard,
Please see my responses inline.
BR,
Farid

>=20
> As Blair notes, there are cases where the Accounting data needs to=20
> follow the same path as Authorization, and User-Name rewriting can=20
> break that.

It depends.  The routing is done based on the realm and/or prefix/suffix
used for NAI decoration.  In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI.  For example, if the AAA
server receives UserName value [email-masked] in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like [email-masked] , where 2345 is the billable
identity.  This should cause the accounting packets follow the same path
as the authorization.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
[email-masked].  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be [email-masked].  In this case, even if the AAA server puts
the received UserName value as is (i.e., [email-masked]) in the
Access-Accept, this will appear to NAS like UserName rewrite. =20

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/[email-masked]) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/[email-masked].  The AAA server can return
intermediary.com/[email-masked] or preferably
intermediary.com/[email-masked] (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.

> This argument against User-Name rewrite is more compelling than NAS=20
> compatibility or billing system compatibility since new attributes=20
> will also require changes to NASen and billing systems.
>=20
> I'd suggest that we need a discussion of the issues so that we can=20
> understand when it is safe to do User-Name rewriting, and when this=20
> can cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute. =20

>=20
> The major impetus for User-Name rewrite as I understand it is for use=20
> in privacy.  There are also the cosmetic cases that Dave Mitton has=20
> mentioned (e.g. changing case) but I think these are relatively=20
> benign.
>=20
> So how do we go forward?  There may need to be an errata submitted for

> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 is=20
> somewhat misleading; User-Name rewriting is not required for the=20
> routing of the Access-Accept back to the NAS;  Proxy State can handle=20
> this.
>=20

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept. =20

> I'd also like to understand if there are guidelines that a server can=20
> use to determine when User-Name rewrite is safe and when it isn't. =20
> For example, what if a user attempts to protect Privacy in a network=20
> set up as Blair has suggested?  What breaks?  Is there a way for the=20
> server to detect the situation and not cause problems?
>=20
> I also think that we need to discuss this in the Network Discovery=20
> Problem Statement, since if a user desires to influence the mediating=20
> network, then accounting supporting that decision needs to be carried=20
> out.
>=20
>=20

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

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

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

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

Delivery-date: Wed, 14 Jul 2004 21:45:30 +0000
content-class: urn:content-classes:message
Subject: RE: NAI decoration: User Identity issues
Date: Wed, 14 Jul 2004 14:41:54 -0700
From: "Blair T. Bullock" <[email-masked]>
To: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>, "Adrangi, Farid" <[email-masked]>, "Bernard Aboba" <[email-masked]>
cc: [email-masked]

The problem with Home Authentication persistence of additional
decorations is that it must be provisioned that way from the start with
Aggregator and Reseller information in order to 'normalize' the
user-name.  A provisioning nightmare.

For the Aggregation proxy systems to re-decorate the user-name as it
returns in the Access-Accept requires statefulness between auth and acct
events; undesirable.

Someone said:

"In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute."

Hallelujah, I wholeheartedly concur with this statement.  It is
basically the same concept as the proposed Class usage for the purposes
of user-name accounting data reflection, but specifically dedicated to
the resolution of RADIUS-routable and billable identities in Tunneled
EAP methods.

There needs to be a distinction between the User-Name used for RADIUS
routing which must go unmodified and appear as originally presented to
the NAS and an Authenticated-User which is the Billable authenticated
user applied to the accounting in a separate attribute with a value
derived from the User-Name in the Access-Accept.  This way the OTA
transmitted routable user-name may be an anonymous/alias, decorated
promiscuously with no ill-effect and all AAA events take the same path
from a RADIUS standpoint...  While also maintaining an Authenticator
protected billable identity (or alias) which is not transmitted over the
air, but represented by the NAS from the value of the User-Name in the
Access-Accept. =20

>From a Roaming Aggregation standpoint, the only other alternative is to
not pass the user-name back in the Access-accept to maintain the
originally presented NAI.  Also, to maintain service oversight and fraud
detection with Tunneled-Methods, there will most likely need to be
checking to ensure that the Inner and Outer identities are identical at
a 'root' NAI level (regardless of additional chained suffixes or
prefixes to facilitate routing and session data) to protect against
hackers.  Such equivalency checking would then preclude "anonymous"
transport unless specifically handled by the intermediary.

-Blair

-----Original Message-----
From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]=20
Sent: Wednesday, July 14, 2004 12:30 PM
To: 'Adrangi, Farid'; Bernard Aboba
Cc: [email-masked]
Subject: NAI decoration: User Identity issues

Can somebody point me to a drafts/ literature describing different
methods of NAI decoration (prefix/ suffix based) and their rewrites by
the AAA infrastructure?

Thank you in advance,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: RE: User Identity issues

Hi Bernard,
Please see my responses inline.
BR,
Farid

>=20
> As Blair notes, there are cases where the Accounting data needs to=20
> follow the same path as Authorization, and User-Name rewriting can=20
> break that.

It depends.  The routing is done based on the realm and/or prefix/suffix
used for NAI decoration.  In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI.  For example, if the AAA
server receives UserName value [email-masked] in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like [email-masked] , where 2345 is the billable
identity.  This should cause the accounting packets follow the same path
as the authorization.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
[email-masked].  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be [email-masked].  In this case, even if the AAA server puts
the received UserName value as is (i.e., [email-masked]) in the
Access-Accept, this will appear to NAS like UserName rewrite. =20

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/[email-masked]) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/[email-masked].  The AAA server can return
intermediary.com/[email-masked] or preferably
intermediary.com/[email-masked] (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.

> This argument against User-Name rewrite is more compelling than NAS=20
> compatibility or billing system compatibility since new attributes=20
> will also require changes to NASen and billing systems.
>=20
> I'd suggest that we need a discussion of the issues so that we can=20
> understand when it is safe to do User-Name rewriting, and when this=20
> can cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute. =20

>=20
> The major impetus for User-Name rewrite as I understand it is for use=20
> in privacy.  There are also the cosmetic cases that Dave Mitton has=20
> mentioned (e.g. changing case) but I think these are relatively=20
> benign.
>=20
> So how do we go forward?  There may need to be an errata submitted for

> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 is=20
> somewhat misleading; User-Name rewriting is not required for the=20
> routing of the Access-Accept back to the NAS;  Proxy State can handle=20
> this.
>=20

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept. =20

> I'd also like to understand if there are guidelines that a server can=20
> use to determine when User-Name rewrite is safe and when it isn't. =20
> For example, what if a user attempts to protect Privacy in a network=20
> set up as Blair has suggested?  What breaks?  Is there a way for the=20
> server to detect the situation and not cause problems?
>=20
> I also think that we need to discuss this in the Network Discovery=20
> Problem Statement, since if a user desires to influence the mediating=20
> network, then accounting supporting that decision needs to be carried=20
> out.
>=20
>=20

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

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

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

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

Delivery-date: Wed, 14 Jul 2004 21:21:37 +0000
Content-class: urn:content-classes:message
Subject: RADIUS Extension for Management Authorization Draft
Date: Wed, 14 Jul 2004 17:20:45 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I have submitted an Internet-Draft entitled "RADIUS Extension for =
Management Authorization", located at the following URL:

http://www.ietf.org/internet-drafts/draft-nelson-radius-management-author=
ization-00.txt

This is based on work that I presented at the RADEXT BOF at IETF 58.  =
Interest in this area of work was expressed at the BOF.  I'd like to =
solicit comment on this initial draft on the list, and get an idea of =
the potential interest in making this a WG work item, and of others who =
may have an interest in contributing to the document.

Thanks!

-- Dave Nelson

=A0

--
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, 14 Jul 2004 19:41:46 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>, [email-masked]
Subject: Mobile IP support: draft-adrangi-radius-attributes-extension-00.t xt
Date: Wed, 14 Jul 2004 14:41:29 -0500

Hi,

I have a question regarding the Mobile IP HA support in Farid's draft:
Although adding attributes for carrying MIP HA address and IP addresses may be enough for support of base MIP RFC. Many other attributes would be required to support MIP-AAA specs are coming out. Given that Diameter-MIP application provides a large number of AVPs for this and it seems that Diameter compatibility is now a must for RADIUS extensions, shouldn't we allow for more MIP related information to be carried by RADIUS?
Since new data models are being planned, may be we should allow a VSA type attribute that can carry multiple pieces of information for Mobile IP support.

How does that sound?

Regards,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Jari Arkko
Sent: Wednesday, June 02, 2004 8:27 AM
To: Adrangi, Farid; [email-masked]
Subject: comments on draft-adrangi-radius-attributes-extension-00.txt

Hi Farid et al,

Most of the functions in this draft appear valid
and useful. I do have a number of comments again,
however ;-) Some of these comments have to do with
the User Alias Identity. I'm uncertain whether
it should be done like this, or if the existing User-Name
AVP is sufficient. Certainly the way that its now specified
in the draft appears to have some privacy issues. Other set
of comments involves making these attributes work with
Diameter too (surprisingly, even the RADIUS capabilities
discovery may be useful for Diameter). I also have
some issues with the 1-byte long enumerated fields.

In more detail:

Substantial:

>   This document describes additional Remote Authentication Dial In 
>   User Service (RADIUS) [1] attributes for use of RADIUS AAA 
>   (Authentication, Authorization, Accounting) in both Wireless and 
>   wired networks.

This is otherwise OK abstract, but I would like to have
it say something more about what the attributes do. Also
make it less-RADIUS specific. How about this:

   This document describes additional Authentication, Authorization,
   Accounting (AAA) attributes for network access. It provides
   an IPv4 address type control mechanism, mobile IPv4 home
   agent discovery mechanism, and a RADIUS capabilities discovery
   mechanism.

>    2. Operation 
>  
>      Operation is identical to that defined in [1] and [2]. 

Like in the other draft, this seems to say very little.
How about deleting this and adding the following text
to the end of the Introduction: "This document assumes
that the RADIUS protocol operates as specified in [1, 2]
and that the Diameter protocol operates as specified in
[RFC 3588, NASREQ, EAP].

>     This document describes a number of additional attributes that are 
>     needed to enable use of RADIUS AAA in various types of access 
>     network in an interoperable manner.   

First some editorials: s/access network/access networks/
and s/RADIUS AAA/the RADIUS and Diameter AAA protocols/.
Then to the substantive comment: I'm not sure I understand
what is claimed here. Is this the draft that makes RADIUS
interoperable? I'm pretty sure it adds new features.
It certainly is likely that this specification is more
interoperable than the existing VSAs, but lets state that
then:

     This document describes a number of additional attributes
     for the RADIUS and Diameter AAA protocols. These attributes
     are needed to provide <a set of functions> for wired and
     wireless access networks. Some of these functions already
     exist as vendor-specific solutions, but it is expected that
     this draft makes these functions interoperable among different
     vendors.

>    2.1 RADIUS Support for Specifying User Alias Identity 
>     
>       Rationale 
>         In certain authentication methods such as, EAP-PEAP or EAP-
>         TTLS, the true identity of the subscriber is hidden from the 
>         RADIUS AAA infrastructure.  In these methods the User-name(1) 
>         attribute contains an anonymous identity sufficient to route 
>         the RADIUS packets to the home network but otherwise 
>         insufficient to identify the subscriber.  While this mechanism 
>         is good practice there are situations where this creates 
>         problems.  For example, in certain roaming situations 
>         intermediaries and visited network require to be able to 
>         correlate an authentication session with a user identity;  A 
>         broker may require to implement a policy where by only session 
>         is allowed per user entity.  Third party billing brokers may 
>         require to match accounting records to a user identity. 
>          
>         The User Identity Alias provides a solution to the above 
>         problem.  When the home network assigns a value to the User 
>         Identity Alias it asserts that this value represents a user in 
>         the home network.  The assertion should be temporary.  Long 
>         enough to be useful for the external applications and not too 
>         long to such that it can be used to identify the user. 

Here's what RFC 3579 says: "The User-Name attribute within the Access-
Accept packet need not be the same as the User-Name attribute in the
Access-Request."

I wonder if this could be used to implement the functionality that
you want, without adding a new attribute. But you could still
include the explanation of the problem and guidelines for the
servers.

>      When the home network assigns a value to the User 
>      Identity Alias it asserts that this value represents a user in 
>      the home network.  The assertion should be temporary.  Long 
>      enough to be useful for the external applications and not too 
>      long to such that it can be used to identify the user. 

(snip)

>         00 � reserved 
>         01 � IMSI 
>         02 � NAI 
>         03 � E.164 number 
>         04 � SIP URL (as defined in [13]) 
>         05 � Opaque string 

I find the first statement and types 1, 3, and 4
contradictory. This appears to be another reason why
the RFC 3579 approach might be better. Alternatively,
define the opaque string case only.

(Type 2 is problematic too if not constructed the right way.)

>    2.2 RADIUS Support for Advertising Application-based capabilities  

I would add the following text somewhere: This discovery also
enables a Diameter translation agent to discover
whether it can initiate these functions and expect them to
succeed when translated to RADIUS. This attribute SHOULD
be translated as is to Diameter, to enable the server
make these decisions as well. A translation agent
converting a Diameter AAR command to a RADIUS Access-Request
packet SHOULD include this attribute iwith the
value <TBD> to indicate that Diameter can support, for instance,
dynamic authorization.

>         This attribute indicates IPv4 address type options. It can be 
>         present  in  Access-Request,  Access-Accept,  and  Accounting-
>         Request records where the Acc-Status-Type is set to Start or 
>         Stop.  When it is used in an Access-Accept and Accounting-
>         Request packets, the Address Type value MUST be 1 or 2.   

RADIUS-specific. Suggested rewrite:

      This attribute indicates IPv4 address type options. In RADIUS,
      it can be present  in  Access-Request,  and Access-Accept messages.
      In Diameter, it can be present in AAR, AAA, and RAR commands. In
      both protocols, it can be present in
      Accounting-Request messages where the Acc-Status-Type is set to Start or
      Stop.  When it is used in an Access-Accept and Accounting-
      Request packets, the Address Type value MUST be 1 or 2.

> A RADIUS server includes 
>         this attribute in the Access-Accept to specify an IP address 
>         type option for the PWLAN client.  

Rewrite:

         A server includes this attribute in the RADIUS Access-Accept
         packet or Diameter AAA and RAR commands to specify an IP address
         type option for the PWLAN client.

>         A RADIUS server MUST NOT include this attribute in the Access-
>         Accept if the IP Address Type options were not advertised in 

Why? Seems like this adds a rule to the server side, but
sending an attribute which the NAS will ignore does not
seem to harm anyone. Or am I missing something?

>         the Access-Request.  If an invalid IP Address Type option is 
>         received in the Access-Accept, then the AN MUST use its default 
>         IP Address Type option for the client.  Otherwise, the AN MUST 

In the other document an invalid attribute resulted in an
Access-Reject. Why is this different?

>         assign an IP address according to the specified type option.  
>         In either case it MUST include this attribute in Accounting-
>         Request packets to indicate the used IP address type option.  

Which one? The one that the server sent, or the one that the NAS
chose?

>         If an IP address type option is not specified in the Access-
>         Accept, the NAS MUST NOT include this attribute in Accounting-
>         Request packets. 

s/Access-Accept/RADIUS Access-Accept or Diameter RAR and
AAA commands/

>      This draft introduces new RADIUS Attributes.  Therefore, there is 
>      a need for obtaining new attribute TYPE numbers from IANA.  

I think the document should also say something about the
future allocations in the defined enumerated spaces.
How about this additional text:

    New enumerated values within the attributes defined here
    can be allocated using the policies defined in RFC 3575,
    i.e., Designated Expert.

>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>       |     Type      |    Length     |IP Address Type| 
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
>   
(snip)
>         Length 
>          
>           1 

This does not seem to match the usual (?) RADIUS style
where integer/enumerated attributes have a 32-bit
integer.

>    The format of this Integer is as follows: 
>     
>    0xCCCTSSSS 
>     
>    Where: 
>      CCC is a 12-bit indicator that identifies the capability ID.  
(snip)
>      SSSS is 16-bit indicator that identifies the sub-capabilities ID.  

Uh oh. This is getting pretty complicated, and requires server
side code (not just regexp) to handle. Are we really, really
sure that we couldn't survive without the sub-capability IDs?

Editorial:

>    4. Security Considerations 
>     
>      The attributes in this document have no additional security 
>      considerations beyond those already identified in [?]. 

Missing reference.

> PWLAN client

This seems a bit too WLAN specific. Just say network access
client.

(Multiple places.)

> RADIUS Attributes Extension

A bit generic name for the system.

> and sever are

s/sever/server/

>    2.1 RADIUS Support for Specifying User Alias Identity..............2 
>    2.2 RADIUS Support for Advertising Application-based capabilities..4 
>    2.3 RADIUS Support for Specifying a Mobile IP Home Agent...........6 
>    2.4 RADIUS Support for Specifying IP Address Type Options..........7 

Suggest s/RADIUS Support for Specifying// and
s/RADIUS Support for Advertising/ in order to make
the titles short.

>     Remote Access Dial In User Service (RADIUS) [1],[2],[3] is the 
>     dominant Authentication, Authorization, and Accounting (AAA) 
>     protocol in use across broadband wireless and wired networks 
>     globally.  

True, but not really relevant to the specification task at hand.
Suggestion: delete paragraph. Move references to the next paragraph.

> user�s

Non-ASCII char.

>            00 � reserved 
>            01 � IMSI 
>            02 � NAI 
>            03 � E.164 number 
>            04 � SIP URL (as defined in [13]) 
>            05 � Opaque string 
>  

Non-ASCII char.

>         later be indicated to the client through several means � for 
>         example, it can be relayed in the �home agent address� field of 

Non-ASCII chars.

>    Authors� Addresses 

Non-ASCII char.

--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: Wed, 14 Jul 2004 19:30:40 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Adrangi, Farid'" <[email-masked]>, Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: NAI decoration: User Identity issues
Date: Wed, 14 Jul 2004 14:30:22 -0500

Can somebody point me to a drafts/ literature describing different methods of NAI decoration (prefix/ suffix based) and their rewrites by the AAA infrastructure?

Thank you in advance,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Adrangi, Farid
Sent: Wednesday, June 16, 2004 12:10 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: RE: User Identity issues

Hi Bernard,
Please see my responses inline.
BR,
Farid

> 
> As Blair notes, there are cases where the Accounting data needs
> to follow the same path as Authorization, and User-Name rewriting
> can break that. 

It depends.  The routing is done based on the realm and/or prefix/suffix
used for NAI decoration.  In the context of conveying a billable
identity, the UserName(1) rewrite does not have to impact the realm or
prefix/suffix parts of the decorated NAI.  For example, if the AAA
server receives UserName value [email-masked] in the
Access-Request, the AAA server can convey the billable identity via
UserName (1) rewrite like [email-masked] , where 2345 is the billable
identity.  This should cause the accounting packets follow the same path
as the authorization.

When a decorated NAI is used, we have a problem even if the UserName(1)
rewrite is done by the AAA server.  Let's say the client uses a
decorated NAI as per syntax defined in 2486bis - for example
[email-masked].  Upon receipt of the
Access-Request, the intermediary strips off the decoration and forwards
the Access-Request.  Therefore, the UserName received by the AAA server
will be [email-masked].  In this case, even if the AAA server puts
the received UserName value as is (i.e., [email-masked]) in the
Access-Accept, this will appear to NAS like UserName rewrite.  

However, please note that if prefix-based NAI decoration (e.g.,
intermediary.com/[email-masked]) is used on contrary to what is
specified in 2486bis, the intermediary can forward the AccessRequest
without striping off the decoration -- that is, the AAA server will see
intermediary.com/[email-masked].  The AAA server can return
intermediary.com/[email-masked] or preferably
intermediary.com/[email-masked] (where 2345 is the billable identity).
This should cause the accounting packets follow the same path as the
authorization.

> This argument against User-Name rewrite is more
> compelling than NAS compatibility or billing system compatibility
> since new attributes will also require changes to NASen and 
> billing systems.
> 
> I'd suggest that we need a discussion of the issues so that we can
> understand when it is safe to do User-Name rewriting, and 
> when this can
> cause problems.

In my opinion, the cleanest approach is not to overload use of
UserName(1) with other things instead of doing analysis when it is safe
to do UserName (1) rewrite and hen it is not.  For example, if the
intent is to convey a billable identity to the NAS, use a separate
attribute.  

> 
> The major impetus for User-Name rewrite as I understand it is 
> for use in
> privacy.  There are also the cosmetic cases that Dave Mitton 
> has mentioned
> (e.g. changing case) but I think these are relatively benign.
> 
> So how do we go forward?  There may need to be an errata submitted for
> RFC 3579.  As Barney Wolff pointed out, the text of RFC 3579 
> is somewhat
> misleading; User-Name rewriting is not required for the
> routing of the Access-Accept back to the NAS;  Proxy State can handle
> this.
> 

RFC 3579 also needs to make it clear which identity the NAS should use
in the accounting requests -- the original identity sent in the
Access-Request, or the identity received in the Access-Accept.  

> I'd also like to understand if there are guidelines that a 
> server can use
> to determine when User-Name rewrite is safe and when it isn't.  For
> example, what if a user attempts to protect Privacy in a 
> network set up as
> Blair has suggested?  What breaks?  Is there a way for the server to
> detect the situation and not cause problems?
> 
> I also think that we need to discuss this in the Network 
> Discovery Problem
> Statement, since if a user desires to influence the mediating network,
> then accounting supporting that decision needs to be carried out.
> 
> 

Yes. And, I think use of prefix-based decorated NAI (as originally
specified in the mediating network discovery draft!) would solve this
problem - please see the argument above.

--
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, 14 Jul 2004 19:19:42 +0000
Date: Wed, 14 Jul 2004 12:17:24 -0700 (PDT)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: WG Action: RADIUS Extensions (radext)

A new IETF working group has been formed in the Operations and Management Area.
For additional information, please contact the Area Directors or the WG Chairs.

RADIUS Extensions (radext)
---------------------------

Current Status: Proposed Working Group

Chair(s):
Bernard Aboba <[email-masked]>
David Nelson <[email-masked]>

Operations and Management Area Director(s):
David Kessens <[email-masked]>
Bert Wijnen <[email-masked]>

Operations and Management Area Advisor:
David Kessens <[email-masked]>

Technical Advisor(s):
[email-masked]
Paul Congdon <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked], In Body: subscribe
Archive: http://ops.ietf.org/lists/radiusext

Description of Working Group:

The RADIUS Extensions Working Group will focus on extensions to the
RADIUS protocol required to enable its use in applications such as IP
telephony and Local Area Network authentication, authorization and
accounting.

The IETF has recently completed work on the Diameter Base protocol. In
order to support the deployment of Diameter, and enable interoperation
of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items
MUST contain a Diameter compatibility section, outlining how
interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS
implementations, as well as compatibility between RADIUS and Diameter,
the following restrictions are imposed on extensions considered by the
RADEXT WG:

- All RADIUS work MUST be backward compatible with existing RADIUS RFCs,
including RFCs 2618-2621, 2865-2869, 3162, 3575, 3576, 3579, and 3580.
- All RADIUS work MUST be compatible with equivalent facilities in
Diameter. Where possible, new attributes should be defined so that
the same attribute can be used in both RADIUS and Diameter without
translation. In other cases a translation considerations
section should be included in the specification.
- No new RADIUS transports (e.g. TCP, SCTP) will be defined.
- No new security mechanisms will be defined for protecting RADIUS.
- No new commands will be defined.

Work Items

The immediate goals of the RADEXT working group are to address the
following issues:

- RADIUS design guidelines. This document will provide guidelines for
design of RADIUS attributes. It will specifically consider how
complex data types may be introduced in a robust manner, maintaining
backwards compatibility with existing RADIUS RFCs, across all the
classes of attributes: Standard, Vendor-Specific and SDO-Specific.
In addition, it will review RADIUS data types and associated
backwards compatibility issues.

- RADIUS implementation issues and fixes. This document will address
common RADIUS implementation issues and describe proposed solutions.

- Revised NAI specification. This document, known as "RFC 2486bis"
will revise the NAI specification to correct known errors,
add support for privacy and internationalization, and provide
more details on routing.

- Pre-paid support. Prepaid services are contemplated in a number
of potential applications, including wireless LAN access and IP
telephony. In order to enable support of pre-paid services in
an interoperable way, the WG will provide definitions of the
attributes required to support operator service models for
pre-paid, as documented in liaison communications. This
document will include within it a specification for interoperation
with Diameter Credit Control.

- SIP support. RADIUS is currently used for SIP authentication,
authorization and accounting. Standardization of these attributes
will enable improved interoperability.

This document will be upwards compatible with the Diameter SIP
application, and conform to existing IETF RFCs on HTTP Digest,
including RFC 2617, 3261, and 3310.

- LAN attributes. New attributes have been proposed to enable use of
authentication, authorization and accounting in wired and
wireless LANs. Standardization of these attributes will enable
improved interoperability.

- RADIUS MIB update. RFC 2618-2621 lack IPv6 compatibility, and modest
changes are required to address this issue. MIBs for RFC 3576 are
also needed.

Goals and Milestones:

Dec 04 Updates to RFC 2618-2621 RADIUS MIBs submitted for publication.
Dec 04 RADIUS design guidelines submitted as an Informational RFC.
Dec 04 SIP RADIUS authentication draft submitted as a Proposed Standard
RFC.
Feb 05 RADIUS implementation issues and fixes submitted as an
Informational RFC.
Feb 05 WLAN attributes draft submitted as a Proposed Standard RFC.
Feb 05 RFC 2486bis submitted as a Proposed Standard RFC.
Dec 05 LAN attributes draft submitted as a Proposed Standard RFC.
Dec 05 RADIUS Prepaid draft submitted as a Proposed Standard RFC.
Dec 05 RFC 3576 MIBs submitted as an Informational RFC.

--
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, 13 Jul 2004 19:21:13 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: RE: questions on draft-mariblanca-aaa-eap-lla-00.txt
Date: Tue, 13 Jul 2004 14:20:37 -0500

Hi Jari,

Well, I am not sure if I agree with all you say down there.
Isn't the "Proposal for an IETF extended attribute space" as Bernard sent out a few weeks ago, an attempt to extend the type space?

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |  Length       |            Vendor-Id
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Vendor-Id (cont)           |M|R|      Vendor type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Vendor length |  Attribute-Specific...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

I understand that the proposal also supports the need for sub-attributes (which by itself is an implicit way of saving attribute space?), but still...

So potentially (if you didn't have the legacy issue with EAP), you would want to have an "EAP attribute" with all the related info as sub-attributes,  no?

The same goes with Farid's draft that suggests Mobile IP HA to be sent as a new attribute. I feel that Mobile IP may need a whole lot more info from the RADIUS server than just HA information. I will send another email about that to keep the threads separate, although thought process is similar.

Regards,

Madjid

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Tuesday, July 13, 2004 1:09 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; David Mariblanca (EE/EEM)
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 wrote:

> I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work.

I believe there is sufficient attribute space available to complete
all standards work currently on the table. The discussion about new
attribute formats and datatypes was related more to the unification of
vendor, SDO, and IETF spaces and datatypes than running out of
numbers for immediate needs.

--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: Tue, 13 Jul 2004 06:14:34 +0000
Date: Tue, 13 Jul 2004 09:09:09 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 wrote:

> I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work.

I believe there is sufficient attribute space available to complete
all standards work currently on the table. The discussion about new
attribute formats and datatypes was related more to the unification of
vendor, SDO, and IETF spaces and datatypes than running out of
numbers for immediate needs.

--Jari

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

Delivery-date: Mon, 12 Jul 2004 20:08:26 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: RE: questions on draft-mariblanca-aaa-eap-lla-00.txt
Date: Mon, 12 Jul 2004 15:08:15 -0500

Hi Jari,

Thank you for your quick response. I guessed that the EAP-IKEv2 had some drafts behind it. Thank you for the links, I will look at those drafts.

As far as the attribute format on the EAP-message attribute, I understand the legacy deployment issues. I was just wondering how the new attribute datatypes discussions (a while ago) went on this list. I guess this is still part of the data model work.

BR,

Madjid
 
-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, July 12, 2004 2:01 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]; David Mariblanca (EE/EEM)
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 wrote:

> I can understand that one may want to signal the info on the
> kind of L2 that is carrying the EAP messages over the link
> from end device to Access node, so PPP and 802.1x make sense.

Yes.

> But what is the purpose of IKEv2 and PANA? Are we saying we
> expanded the L2 concept to L3 and EAP is carried over IKEv2
> for protection over the single hop?

The EAP concept has already been expanded from L2 to L3 with the
introduction of things like IKEv2 or PANA. But this is really
not related to David's draft -- the expansion comes from
documents such as draft-ietf-ipsec-ikev2-nn.txt or draft-ietf-
pana-pana-mm.txt.

By the way, such usage of EAP in IKEv2 is not necessarily
limited to a single hop.

> If yes, then why nothing on IKEv1? Would you care to explain?

Because there is no current specification which would extend
IKEv1 so that it could use EAP authentication. (PIC did something
like that but my understanding is that PIC work is no longer
alive; please feel free to correct me if I have been mistaken.)

> I also have a general question: RFC 3579 defines an EAP-message
> attribute for RADIUS with an IANA type of 79. So far I have not
> understood how grouping of attributes works for RADIUS, but it
> feels like the EAP-message attribute and L2 info attribute 
> should be grouped together somehow, especially if the attribute
> space is tight. Anybody cares to explain?

The problem is that EAP-Message has already been implemented
and deployed, so its hard to add anything into that attribute
without breaking everyone's devices.

--Jari

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

Delivery-date: Mon, 12 Jul 2004 19:05:42 +0000
Date: Mon, 12 Jul 2004 22:00:33 +0300
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked], "David Mariblanca (EE/EEM)" <[email-masked]>
Subject: Re: questions on draft-mariblanca-aaa-eap-lla-00.txt

Nakhjiri Madjid-MNAKHJI1 wrote:

> I can understand that one may want to signal the info on the
> kind of L2 that is carrying the EAP messages over the link
> from end device to Access node, so PPP and 802.1x make sense.

Yes.

> But what is the purpose of IKEv2 and PANA? Are we saying we
> expanded the L2 concept to L3 and EAP is carried over IKEv2
> for protection over the single hop?

The EAP concept has already been expanded from L2 to L3 with the
introduction of things like IKEv2 or PANA. But this is really
not related to David's draft -- the expansion comes from
documents such as draft-ietf-ipsec-ikev2-nn.txt or draft-ietf-
pana-pana-mm.txt.

By the way, such usage of EAP in IKEv2 is not necessarily
limited to a single hop.

> If yes, then why nothing on IKEv1? Would you care to explain?

Because there is no current specification which would extend
IKEv1 so that it could use EAP authentication. (PIC did something
like that but my understanding is that PIC work is no longer
alive; please feel free to correct me if I have been mistaken.)

> I also have a general question: RFC 3579 defines an EAP-message
> attribute for RADIUS with an IANA type of 79. So far I have not
> understood how grouping of attributes works for RADIUS, but it
> feels like the EAP-message attribute and L2 info attribute 
> should be grouped together somehow, especially if the attribute
> space is tight. Anybody cares to explain?

The problem is that EAP-Message has already been implemented
and deployed, so its hard to add anything into that attribute
without breaking everyone's devices.

--Jari

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

Delivery-date: Mon, 12 Jul 2004 18:55:16 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: [email-masked]
Subject: questions on draft-mariblanca-aaa-eap-lla-00.txt
Date: Mon, 12 Jul 2004 13:54:22 -0500

Hi David and others,

I am going through the draft that have slots for San Diego meeting, so I am sorry if there has been discussions regarding this draft and I have missed those threads.

My question regarding the EAP lower layer attributes is:

I can understand that one may want to signal the info on the kind of L2 that is carrying the EAP messages over the link from end device to Access node, so PPP and 802.1x make sense. But what is the purpose of IKEv2 and PANA? Are we saying we expanded the L2 concept to L3 and EAP is carried over IKEv2 for protection over the single hop? If yes, then why nothing on IKEv1? Would you care to explain?

I also have a general question: RFC 3579 defines an EAP-message attribute for RADIUS with an IANA type of 79. So far I have not understood how grouping of attributes works for RADIUS, but it feels like the EAP-message attribute and L2 info attribute should be grouped together somehow, especially if the attribute space is tight. Anybody cares to explain?

Thanks,

Madjid

--
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, 02 Jul 2004 18:03:17 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Ashwin Palekar'" <[email-masked]>, <[email-masked]>, "'Joseph Salowey'" <[email-masked]>, <[email-masked]>
Subject: RE: issues about Keyreq/keywrap drafts
Date: Fri, 2 Jul 2004 11:02:06 -0700
Organization: Cisco Systems

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

> Some issues/questions about these drafts:
> 
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-01.txt
> 
> http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt
> <http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-00.txt>
> 
> 1. How is support for the "applications" signaled between the peer
> and NAS and between the NAS and AAA server?  Without specifying the
> signaling mechanisms, the end result is breaking interoperability
> both in EAP and in AAA as well.  For example, even if the NAS
> Requests an application specific key via the Naming AVP 

Do you mean the EAP-Key-Name AVP?

> in Diameter
> or an equivalent in RADIUS, what happens if the server doesn't
> support the particular naming scheme in use? As far as I can tell,
> the Diameter EAP name request can only be used interoperably with a
> standardized key naming mechanism, not with this "extension"
> mechanism.   

The application ID may be specified in the Key attribute.  It's format
has been left unspecified both in the hope of sparking discussion and
because it's not completely clear (to me, anyway) that binding the Key
attribute to EAP is a good idea (there are currently no standard EAP
methods that generate keys of any kind).  

> 
> 2. Why create new RADIUS codes - can't we use existing radius codes
> (Access-request) with new service type? 

We're not requesting access (presumably access has already been
granted).  It just seems cleaner to me.
 
> 
> Thanks, Ashwin

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

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