Subject: Protocol Action: 'Chargeable User Identity' to Proposed Standard (fwd)
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Date: Mon, 31 Oct 2005 13:03:20 -0800

>---------- Forwarded message ----------
>Date: Mon, 31 Oct 2005 15:52:55 -0500
>From: The IESG <[email-masked]>
>To: IETF-Announce <[email-masked]>
>Cc: Internet Architecture Board <[email-masked]>,
>     RFC Editor <[email-masked]>,
>     radext mailing list <[email-masked]>,
>     radext chair <[email-masked]>, radext chair 
><[email-masked]>
>Subject: Protocol Action: 'Chargeable User Identity' to Proposed
>     Standard
>
>The IESG has approved the following document:
>
>- 'Chargeable User Identity '
>    <draft-ietf-radext-chargeable-user-id-06.txt> as a Proposed Standard
>
>This document is the product of the RADIUS EXTensions Working Group.
>
>The IESG contact persons are David Kessens and Bert Wijnen.
>
>A URL of this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-radext-chargeable-user-id-06.txt
>
>Technical Summary
>
>  This document describes a new RADIUS attribute, Chargeable-User-
>  Identity.  This attribute can be used by a home network to identify a
>  user for the purpose of roaming transactions that occur outside of
>  the home network.
>
>Working Group Summary
>
>  The RADEXT Working Group came to consensus on this document.
>
>Protocol Quality
>
>  This document was reviewed for the IESG by David Kessens.

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

Delivery-date: Mon, 31 Oct 2005 15:07:53 +0000
Content-class: urn:content-classes:message
Subject: AW: Draft update: draft-lior-radius-prepaid-extensions-09.txt
Date: Mon, 31 Oct 2005 16:07:34 +0100
From: "Tschofenig, Hannes" <[email-masked]>
To: "Pashalidis, Andreas" <[email-masked]>, <[email-masked]>

hi david,=20
hi bernard,=20
hi all,=20

i think we should also spend a few minutes to discuss this work at the =
next ietf meeting since this is part of the charter:
"
Dec 05    RADIUS Prepaid draft submitted as a Proposed Standard RFC =20
"

ciao
hannes

> -----Urspr=FCngliche Nachricht-----
> Von: [email-masked]=20
> [mailto:[email-masked]] Im Auftrag von=20
> Pashalidis, Andreas
> Gesendet: Montag, 31. Oktober 2005 15:56
> An: [email-masked]
> Betreff: Draft update: draft-lior-radius-prepaid-extensions-09.txt
>=20
>=20
> Dear all,
>=20
> A new update of the "Prepaid extensions for RADIUS" Internet draft is
> available at
> http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-
extensions
-09.txt

Changes from the previous version include the following (not exhaustive
list).

=3D> The functionality of RADIUS prepaid has been aligned with that of =
the
Diameter Credit Control application, as discussed at IETF #63. In
particular, RADIUS prepaid now supports "balance check" and "price
enquiry" (in addition to what what supported in the previous version of
the draft).

=3D> Several worked through example flows appear in the appendix.

=3D> RADIUS prepaid / Diameter Credit Control translation function has
been partially specified.

=3D> Various issues have been fixed.

Your comments are solicited.

Best Regards,
Andreas Pashalidis

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

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

Delivery-date: Mon, 31 Oct 2005 14:56:17 +0000
Content-class: urn:content-classes:message
Subject: Draft update: draft-lior-radius-prepaid-extensions-09.txt
Date: Mon, 31 Oct 2005 15:55:44 +0100
From: "Pashalidis, Andreas" <[email-masked]>
To: <[email-masked]>

Dear all,

A new update of the "Prepaid extensions for RADIUS" Internet draft is
available at
http://www.ietf.org/internet-drafts/draft-lior-radius-prepaid-extensions
-09.txt

Changes from the previous version include the following (not exhaustive
list).

=3D> The functionality of RADIUS prepaid has been aligned with that of =
the
Diameter Credit Control application, as discussed at IETF #63. In
particular, RADIUS prepaid now supports "balance check" and "price
enquiry" (in addition to what what supported in the previous version of
the draft).

=3D> Several worked through example flows appear in the appendix.

=3D> RADIUS prepaid / Diameter Credit Control translation function has
been partially specified.

=3D> Various issues have been fixed.

Your comments are solicited.

Best Regards,
Andreas Pashalidis

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

Delivery-date: Thu, 27 Oct 2005 20:54:51 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: FW: New Version Notification - draft-ietf-radext-digest-auth-06.txt
Date: Thu, 27 Oct 2005 13:54:22 -0700

>From: ID Tracker <[email-masked]>
>To: [email-masked], [email-masked], 
>[email-masked],[email-masked]
>Subject: New Version Notification - draft-ietf-radext-digest-auth-06.txt 
>Date: Thu, 27 Oct 2005 15:50:02 -0400
>
>New version (-06) has been submitted for 
>draft-ietf-radext-digest-auth-06.txt.
>http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt
>
>
>
>IETF Secretariat.
>

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

Delivery-date: Thu, 27 Oct 2005 06:33:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for pre-work item review: RADIUS Issues & Fixes
Date: Wed, 26 Oct 2005 23:32:57 -0700

This is a request for pre-work item review of "RADIUS Issues & Fixes".  The 
document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt

Please post your comments to the RADEXT WG mailing list by November 13, 
2005.

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

Delivery-date: Thu, 27 Oct 2005 06:32:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Request for Pre-Work Item Review of RADIUS Design Guidelines
Date: Wed, 26 Oct 2005 23:31:57 -0700

This is a request for a pre-work item review of "RADIUS Design  Guidelines". 
  The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt

Please post your comments to the RADEXT WG mailing list by November 13,  
2005.

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

Delivery-date: Wed, 26 Oct 2005 22:34:29 +0000
Content-class: urn:content-classes:message
Subject: RE: capabilities problem
Date: Wed, 26 Oct 2005 18:34:59 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: "Emile van Bergen" <[email-masked]>, <[email-masked]>

Okay good.

Then I think I am happy.
=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Wednesday, October 26, 2005 1:05 PM
> To: Avi Lior
> Cc: Emile van Bergen; [email-masked]
> Subject: Re: capabilities problem
>=20
> "Avi Lior" <[email-masked]> wrote:
> > The second round trip should not happen unless the NAS=20
> indicates that=20
> > it supports location fetching via a challenge.
>=20
>   Yes, that's what I intended to communicate.
>=20
>   Alan DeKok.
>=20

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

Envelope-to: [email-masked]
Delivery-date: Wed, 26 Oct 2005 17:02:45 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: capabilities problem 
Cc: "Emile van Bergen" <[email-masked]>, [email-masked]
Date: Wed, 26 Oct 2005 13:05:28 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> The second round trip should not happen unless the NAS indicates that it
> supports location fetching via a challenge.

  Yes, that's what I intended to communicate.

  Alan DeKok.

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

Delivery-date: Wed, 26 Oct 2005 11:47:31 +0000
Content-class: urn:content-classes:message
Subject: RE: capabilities problem
Date: Wed, 26 Oct 2005 07:48:21 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Emile van Bergen" <[email-masked]>
Cc: <[email-masked]>

See inline please: I think we are darn close....

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Friday, October 21, 2005 2:02 PM
> To: Emile van Bergen
> Cc: [email-masked]
> Subject: Re: capabilities problem
>=20
> Emile van Bergen <[email-masked]> wrote:
> > Ok. So can we conclude that the inefficiency objection of a second=20
> > round trip in case of GEOPRIV is moot, because it's needed=20
> anyway, and=20
> > that this is solved perfectly by your proposal with my refinements?
>=20
>   Yes.

Unless I am missing something I don't agree.

The second round trip should not happen unless the NAS indicates that it
supports location fetching via a challenge.

If  the NAS happens to supported fetching of location via challenge then
its everything is okay.  But if the NAS did not support fetching of
location via challenge then the challenge was wasteful, and worse, it
can result in the termination of the session which may not be desired.
Therefore an initial advertizement will give the RADIUS server an
indication whether a challenge for location will be fruitfull.

> > Agreed. Problably the misunderstanding lies in that I take=20
> > 'advertising a capability', as 'This party implements standards=20
> > document X, containing numberous clauses with musts, shoulds and=20
> > mays', which I find problematic. That's perhaps my biggest=20
> objection.
>=20
>   Which is why I avoided implementation and semantic=20
> problems, by saying "advertises a capability".

Yes.

>   First, we can decide what we need from capabilities and=20
> their advertisement, independent of the definitions for each=20
> capability.
> Then, we can define the capabilities.  Finally, we can=20
> describe their on-wire formate.

Agreed.
=20
> > But I want to get rid of the explosion of possible states that a=20
> > system can get when two parties state their abilities,=20
> their wishes,=20
> > and then have to do a form of negotiation.
> >=20
> > It took numerous endless looping implementations of PPP to get that=20
> > right in PPP.
>=20
>   Agreed.  I vew capability negotiations a bit like the final=20
> "show of hands" in poker.  Everyone's cards go on the table,=20
> and everyone runs the same algorithm on the available data.  Once.

Agreed....Nobody has suggested a multi-round negotiation.
=20
> > If the use of challenges to get at information that can be=20
> put in the=20
> > first access request was Avi's worry too, then I completely agree.
>=20
>   To put it more strongly, if we don't have *any* capability=20
> advertisement in the first packet, we're back to today's=20
> RADIUS, and we can't break that by changing server behavior.

Yes.  Thankyou.

> > Luckily here, you've misunderstood. I'm surprised. Am I=20
> really so bad=20
> > at explaining my position clearly?
>=20
>   There was significant opposition to allowing Avi's scenario.
>=20
> > So I think we may have complete agreement on the problem=20
> and abstract=20
> > solution for GEOPRIV and alike future cases, at least=20
> between you, Avi=20
> > and myself.
> >=20
> > We only need to work out the attributes and values
>=20
>   I disagree.  I think we're pretty close, but I don't think=20
> we're ready to design a solution based on the stated=20
> requirements.  I would like to ensure that *all* capability=20
> requirements are spelled out, to ensure that the solution is=20
> applicable to later capabilities.

I agree.  And unless I am missing something the first issue above is
still problematic.

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

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

Delivery-date: Wed, 26 Oct 2005 10:57:18 +0000
Date: Wed, 26 Oct 2005 12:56:38 +0200
To: "Bernard Aboba" <[email-masked]>, [email-masked]
Subject: Re: ISSUE, SIP, authentication parameters (fwd)
From: "[email-masked]" <[email-masked]>

See inline

> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 25 October, 2005 15:19
> > To: [email-masked]
> > Subject: [AAA-WG]: ISSUE, SIP, authentication parameters
> >
> >
> > Description of issue: Authentication parameters
> > Submitter name: Mikko Aittola
> > Submitter email address: [email-masked]
> > Date first submitted: 25 Oct 05
> > Document: sip (v. 10)
> > Comment type: T
> > Priority: S
> > Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5
> > Rationale/Explanation of issue:
> >
> > SIP-Method is defined to be required AVP in MAR-command.
> > Is there really need for this to be required AVP?
> > I think Diameter server doesn't necessarily need to consider
> > what is the SIP-method the SIP-server is asking to authenticate.
> >
> > Furthermore, there is already optional Digest-Method AVP
> > in SIP-Authorization grouped AVP. This can be used for
> > the same purpose as SIP-Method AVP.
> >
The radext draft defines only Digest-Method, not SIP method.

> > SIP-Authorization grouped AVP contains required AVP
> > Digest-Username. This is duplicate information with
> > the User-Name AVP sent in the MAR-command.
> >
I am not sure wether the User-Name syntax (think of NAI) won't
interfere with the syntax of Digest-Username (white space?).
Let's keep them separate.

> > PS. Sorry for the late submission..
> >
http://en.wikipedia.org/wiki/Sisyphos

Wolfgang

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

Delivery-date: Wed, 26 Oct 2005 10:04:48 +0000
Content-Class: urn:content-classes:message
Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
Date: Wed, 26 Oct 2005 06:04:40 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

BTW, we looked at RFC3575 for guidance regarding IANA allocation of new
values for Framed-Compression attribute and it was not clear what we had
to do.

-Kuntal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 26, 2005 3:02 AM
> To: Chowdhury, Kuntal; [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
>=20
> Kuntal,
>=20
>
>http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu
> tes-00.txt
>=20
> I gave this a quick read, but I actually don't understand what this
> attribute would be used for.  Could you explain a little bit about
what
> it does, some examples of signaling, etc?
>=20
> What is the NAS & RADIUS server signaling - is there any reason for
them
> to be involved in ROHC?
>=20
> thanks,
> John

"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
[email-masked] -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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

Delivery-date: Wed, 26 Oct 2005 09:57:20 +0000
Content-Class: urn:content-classes:message
Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
Date: Wed, 26 Oct 2005 05:56:52 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi John,

The idea is to additional value for the already existing
Framed-Compression attribute that is defined in 2865. The attribute is
used by the NAS to give a hint to the RADIUS server about its capability
to support a particular type of compression. The RADIUS server returns
this attribute to indicate which compression scheme needs to be used by
the NAS for bearer flows of the user.

Here is the description from RFC 2865:

"
This Attribute indicates a compression protocol to be used for the
      link.  It MAY be used in Access-Accept packets.  It MAY be used in
      an Access-Request packet as a hint to the server that the NAS
      would prefer to use that compression, but the server is not
      required to honor the hint.

      More than one compression protocol Attribute MAY be sent.  It is
      the responsibility of the NAS to apply the proper compression
      protocol to appropriate link traffic.

"

Note that we are not changing this definition in our draft. We are just
defining a new value for it for ROHC.

Hope this clarifies your question.

-Kuntal

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, October 26, 2005 3:02 AM
> To: Chowdhury, Kuntal; [email-masked];
[email-masked]
> Cc: [email-masked]
> Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
>=20
> Kuntal,
>=20
>
>http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu
> tes-00.txt
>=20
> I gave this a quick read, but I actually don't understand what this
> attribute would be used for.  Could you explain a little bit about
what
> it does, some examples of signaling, etc?
>=20
> What is the NAS & RADIUS server signaling - is there any reason for
them
> to be involved in ROHC?
>=20
> thanks,
> John

"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
[email-masked] -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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

Delivery-date: Wed, 26 Oct 2005 08:02:25 +0000
Content-class: urn:content-classes:message
Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
Date: Wed, 26 Oct 2005 11:02:04 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Kuntal,

>http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribu
tes-00.txt

I gave this a quick read, but I actually don't understand what this
attribute would be used for.  Could you explain a little bit about what
it does, some examples of signaling, etc?

What is the NAS & RADIUS server signaling - is there any reason for them
to be involved in ROHC?

thanks,
John

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

Delivery-date: Wed, 26 Oct 2005 07:30:42 +0000
Content-Class: urn:content-classes:message
Subject: RE: IETF 64 RADEXT WG Agenda, Take 1
Date: Wed, 26 Oct 2005 03:30:13 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Chairs,

Would you please assign slots for the following?

http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-00.txt
http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribut
es-00.txt

Both were submitted before the (-00) cutoff date. Please note that I
made request for slots earlier when topics for the agenda were
solicited.

Thank you very much.

Kuntal

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Wednesday, October 26, 2005 12:29 AM
> To: [email-masked]
> Subject: IETF 64 RADEXT WG Agenda, Take 1
>=20
> IETF-64 RADEXT WG Agenda
>=20
> Chairs: Bernard Aboba <[email-masked]>
> David Nelson <[email-masked]>
>=20
> Preliminaries (10 minutes)
>   Bluesheets
>   Agenda Bash
>   Document Status
>   Open Issue Summary:
>      http://www.drizzle.com/~aboba/RADEXT
>   Presentations and agenda online at:
>      http://www.drizzle.com/~aboba/IETF64/radext/
>=20
> WORK ITEMS IN IETF Last Call
>=20
> - Digest Authentication, Wolfgang Beck (10 minutes)
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt
>=20
> WORK ITEMS COMPLETING WG LAST CALL
>=20
> - Dynamic Authorization MIBs, Greg Weber (10 minutes)
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib
-
> 02.txt
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib
-
> 02.txt
>=20
> - RADIUS IPv6 MIBs, Dave Nelson (10 minutes)
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt
>
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt
>=20
> - VLAN/Priority, Paul Congdon (30 minutes)
> http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-02.txt
>=20
> - Common Radius Implementation Issues and Suggested Fixes, Bernard
Aboba
> (10
> minutes)
> http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt
>=20
> - Design Guidelines, Greg Weber (20 minutes)
>
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-
> 01.txt
>=20
> - RADIUS NAS-Management Authorization, Greg Weber (10 minutes)
> http://www.ietf.org/internet-drafts/draft-nelson-radius-management-
> authorization-02.txt
>=20
> - RADIUS/GEOPRIV, Hannes Tschofenig (20 minutes)
>
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt
>=20
> - RADIUS Capabilities Problem Statement, Emile Van Bergen (20 minutes)
>=20
> - RADIUS/MIPv4 Extensions, Madjid Nakhjiri (10 minutes)
> http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.txt
>=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/>

"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
[email-masked] -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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

Delivery-date: Wed, 26 Oct 2005 05:48:30 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF 64 Registration Cutoff
Date: Tue, 25 Oct 2005 22:48:14 -0700

>From: IETF Registrar <ietf-registrar at ietf.org>
>To: IETF Announcement list <ietf-announce at ietf.org>
>Subject: 64th IETF - Pre-registration/payment Cut Off
>Date: Mon, 24 Oct 2005 12:06:29 -0400
>
>The cutoff to pre-register and pre-pay for the 64th IETF Meeting in 
>Vancouver,
>BC is this Wednesday, October 26 at 12:00 noon ET.  If you do not 
>pre-register
>and pre-pay by this time, you will need to register onsite in Vancouver and 
>pay
>the onsite registration fee of $650.00
>
>You can register on line at: http://www.ietf.org/meetings/notewell.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: Wed, 26 Oct 2005 05:29:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: IETF 64 RADEXT WG Agenda, Take 1
Date: Tue, 25 Oct 2005 22:28:31 -0700

IETF-64 RADEXT WG Agenda

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

Preliminaries (10 minutes)
  Bluesheets
  Agenda Bash
  Document Status
  Open Issue Summary:
     http://www.drizzle.com/~aboba/RADEXT
  Presentations and agenda online at:
     http://www.drizzle.com/~aboba/IETF64/radext/

WORK ITEMS IN IETF Last Call

- Digest Authentication, Wolfgang Beck (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-digest-auth-06.txt

WORK ITEMS COMPLETING WG LAST CALL

- Dynamic Authorization MIBs, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt

- RADIUS IPv6 MIBs, Dave Nelson (10 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt

- VLAN/Priority, Paul Congdon (30 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-radext-ieee802-02.txt

- Common Radius Implementation Issues and Suggested Fixes, Bernard Aboba (10 
minutes)
http://www.ietf.org/internet-drafts/draft-aboba-radext-fixes-01.txt

- Design Guidelines, Greg Weber (20 minutes)
http://www.ietf.org/internet-drafts/draft-weber-radius-attr-guidelines-01.txt

- RADIUS NAS-Management Authorization, Greg Weber (10 minutes)
http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-02.txt

- RADIUS/GEOPRIV, Hannes Tschofenig (20 minutes)
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-radius-lo-05.txt

- RADIUS Capabilities Problem Statement, Emile Van Bergen (20 minutes)

- RADIUS/MIPv4 Extensions, Madjid Nakhjiri (10 minutes)
http://www.watersprings.org/pub/id/draft-nakhjiri-radius-mip4-02.txt

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

Delivery-date: Tue, 25 Oct 2005 21:43:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: ISSUE, SIP, authentication parameters (fwd)
Date: Tue, 25 Oct 2005 14:42:08 -0700

Does compatibility with this issue require any changes in the RADIUS Digest 
document?

>---------- Forwarded message ----------
>Date: Tue, 25 Oct 2005 15:19:05 +0300
>From: [email-masked]
>To: [email-masked]
>Subject: [AAA-WG]: ISSUE, SIP, authentication parameters
>
>Description of issue: Authentication parameters
>Submitter name: Mikko Aittola
>Submitter email address: [email-masked]
>Date first submitted: 25 Oct 05
>Document: sip (v. 10)
>Comment type: T
>Priority: S
>Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5
>Rationale/Explanation of issue:
>
>SIP-Method is defined to be required AVP in MAR-command.
>Is there really need for this to be required AVP?
>I think Diameter server doesn't necessarily need to consider
>what is the SIP-method the SIP-server is asking to authenticate.
>
>Furthermore, there is already optional Digest-Method AVP
>in SIP-Authorization grouped AVP. This can be used for
>the same purpose as SIP-Method AVP.
>
>SIP-Authorization grouped AVP contains required AVP
>Digest-Username. This is duplicate information with
>the User-Name AVP sent in the MAR-command.
>
>It seems the case where Diameter server sends HA1 in MAA
>and client calculates and checks the response has not been
>taken into account when the required contents of SIP-Authorization,
>SIP-Authenticate, and SIP-Authentication-Info AVP have been defined.
>
>It is not clear what is included to MAA message in case
>Diameter server has checked the response successfully.
>It might be useful if the Diameter client receives a confirmation
>of the auth-scheme applied by the Diameter-server.
>
>
>Requested changes:
>
>1. Remove SIP-Method AVP from the spec
>2. Remove Digest-Username from the spec. (If needed add text where
>    it is explained that Digest-Username is translated to
>    User-Name in the case of Radius-Diameter translation.)
>3. Change Digest-Nonce to optional in SIP-Authenticate
>4. Change the following AVPs to optional in SIP-Authorization AVP:
>    Digest-Nonce, Digest-URI, Digest-Response
>5. Change Digest-Nextnonce to optional in SIP-Authentication-Info AVP
>6. After Diameter server has checked that the response is ok
>    it returns MAA where result-code is SUCCESS, and SIP-Auth-Data-Item
>    with the SIP-Authentication-Scheme AVP.
>
>7. Change the following text in Section 7.8:
>    If the SIP-Methods AVP value of the Diameter MAR message is set to
>    REGISTER and a User-Name AVP is present, then the Diameter server
>    MUST authorize that User-Name AVP value is able to use the URI
>    included in the SIP-AOR AVP.  If this authorization fails, the
>    Diameter server must set the Result-Code AVP to
>    DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
>    Multimedia-Auth-Answer (MAA) message.
>  To:
>    If the Digest-Method AVP value is either absent or received with a
>    value REGISTER in the Diameter MAR message and a User-Name AVP is
>    present, then the Diameter server MUST authorize that User-Name AVP
>    value is able to use the URI included in the SIP-AOR AVP.  If this
>    authorization fails, the Diameter server must set the Result-Code AVP 
>to
>    DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
>    Multimedia-Auth-Answer (MAA) message.
>
>
>BR,
>Mikko
>
>
>PS. Sorry for the late submission..

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

Delivery-date: Tue, 25 Oct 2005 21:43:37 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: ISSUE, SIP, authentication parameters (fwd)
Date: Tue, 25 Oct 2005 14:42:43 -0700

More below.

>---------- Forwarded message ----------
>Date: Tue, 25 Oct 2005 15:32:16 +0300
>From: [email-masked]
>To: [email-masked]
>Subject: RE: [AAA-WG]: ISSUE, SIP, authentication parameters
>
>Hi,
>
>There is an error in the proposed text in my previous message.
>The corrected version is:
>
>If the Digest-Method AVP is either absent or received with a
>value REGISTER in the Diameter MAR message and a User-Name AVP is
>present, then the Diameter server MUST authorize that User-Name AVP
>value is able to use the URI included in the SIP-AOR AVP.  If this
>authorization fails, the Diameter server must set the Result-Code AVP to
>DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
>Multimedia-Auth-Answer (MAA) message.
>
>
>BR,
>Mikko
>
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: 25 October, 2005 15:19
> > To: [email-masked]
> > Subject: [AAA-WG]: ISSUE, SIP, authentication parameters
> >
> >
> > Description of issue: Authentication parameters
> > Submitter name: Mikko Aittola
> > Submitter email address: [email-masked]
> > Date first submitted: 25 Oct 05
> > Document: sip (v. 10)
> > Comment type: T
> > Priority: S
> > Sections: 7.7, 7.8, 8.5.3, 8.5.4, 8.5.5
> > Rationale/Explanation of issue:
> >
> > SIP-Method is defined to be required AVP in MAR-command.
> > Is there really need for this to be required AVP?
> > I think Diameter server doesn't necessarily need to consider
> > what is the SIP-method the SIP-server is asking to authenticate.
> >
> > Furthermore, there is already optional Digest-Method AVP
> > in SIP-Authorization grouped AVP. This can be used for
> > the same purpose as SIP-Method AVP.
> >
> > SIP-Authorization grouped AVP contains required AVP
> > Digest-Username. This is duplicate information with
> > the User-Name AVP sent in the MAR-command.
> >
> > It seems the case where Diameter server sends HA1 in MAA
> > and client calculates and checks the response has not been
> > taken into account when the required contents of SIP-Authorization,
> > SIP-Authenticate, and SIP-Authentication-Info AVP have been defined.
> >
> > It is not clear what is included to MAA message in case
> > Diameter server has checked the response successfully.
> > It might be useful if the Diameter client receives a confirmation
> > of the auth-scheme applied by the Diameter-server.
> >
> >
> > Requested changes:
> >
> > 1. Remove SIP-Method AVP from the spec
> > 2. Remove Digest-Username from the spec. (If needed add text where
> >    it is explained that Digest-Username is translated to
> >    User-Name in the case of Radius-Diameter translation.)
> > 3. Change Digest-Nonce to optional in SIP-Authenticate
> > 4. Change the following AVPs to optional in SIP-Authorization AVP:
> >    Digest-Nonce, Digest-URI, Digest-Response
> > 5. Change Digest-Nextnonce to optional in SIP-Authentication-Info AVP
> > 6. After Diameter server has checked that the response is ok
> >    it returns MAA where result-code is SUCCESS, and SIP-Auth-Data-Item
> >    with the SIP-Authentication-Scheme AVP.
> >
> > 7. Change the following text in Section 7.8:
> >    If the SIP-Methods AVP value of the Diameter MAR message is set to
> >    REGISTER and a User-Name AVP is present, then the Diameter server
> >    MUST authorize that User-Name AVP value is able to use the URI
> >    included in the SIP-AOR AVP.  If this authorization fails, the
> >    Diameter server must set the Result-Code AVP to
> >    DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
> >    Multimedia-Auth-Answer (MAA) message.
> >  To:
> >    If the Digest-Method AVP value is either absent or received with a
> >    value REGISTER in the Diameter MAR message and a User-Name AVP is
> >    present, then the Diameter server MUST authorize that User-Name AVP
> >    value is able to use the URI included in the SIP-AOR AVP.  If this
> >    authorization fails, the Diameter server must set the
> > Result-Code AVP to
> >    DIAMETER_ERROR_IDENTITIES_DONT_MATCH and send it in a Diameter
> >    Multimedia-Auth-Answer (MAA) message.
> >
> >
> > BR,
> > Mikko
> >
> >
> > PS. Sorry for the late submission..
> >

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

Delivery-date: Tue, 25 Oct 2005 17:22:01 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue 113: Attribute Concatenation
Date: Tue, 25 Oct 2005 10:19:48 -0700
From: "Congdon, Paul T (ProCurve)" <[email-masked]>
To: "Glen Zorn (gwz)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

I'd like to revive this thread a bit.  I never finished the response to
Glenn about QoS-Filter-Rule for Radius...

As a warm-up, remember, what we are trying to do is simply import the
QoS-Filter-Rule AVP from Diameter into Radius.  We felt since it was
defined for Diameter (and presumable implemented), that we could easily
define it for Radius by addressing the differences and missing
funcationality.

>=20
> > Taking Glen's suggested text, I'd like to close this issue out with=20
> > the following proposed text for the Text field in section 3.6.
> > Please let me know if this will work. =20
> >=20
> >=20
> >      Text
> >=20
> >         The Text field contains a QoS filter, utilizing the syntax
> >         defined for the QoSFilterRule derived data type defined in
> >         [RFC3588], Section 4.3.  Note that this definition contained
> >         an error, so that the complete syntax is described in the
> >         definition of the QoS-Filter-Rule AVP, defined in [NASREQ].
>=20
> Are you _sure_ that you want to use this syntax?  It's=20
> awfully verbose.  Even if you really do want to use it, I=20
> would suggest that you reproduce it (or rather, adapt it to=20
> use w/RADIUS) in this document, rather than incorporating it=20
> by reference.  There are several problems with the Diameter=20
> definitions, not least of which is that the definition of the=20
> QoS-Filter-Rule AVP depends upon the definition of=20
> IPFilterRule which is derived from OctetString which doesn't=20
> exist in RADIUS.
>=20

Seems like we have a couple of options here:

1. completely define the attribute syntax, as we have done for
NAS-Filter-Rule.  Perhaps leveraging much of the same definition, but
providing new actions that match QoS-Filter-Rule actions.  The actions
are mark and meter.  The mark action could also take-on L2 functionality
such as setting 802.1p bits in addition to setting DSCP.

2. provide text that defines the missing pieces from IPFilterRule, such
as OctetString.

3. Drop the attribute all together.  I don't believe any other SDOs are
depending upon this attributre.  I'm sure the TNC is not currently using
it.  Also, there have been a number of concerns with QoS functionality
in general (as seen in the simple bandwidth draft).  However, Diamater
successfully has defined this AVP.

Option 1 would be most consistent with the rest of the document.  Option
3 is the easy way out.  I'm not sure exactly what would be needed for
option 2.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 21 Oct 2005 17:59:52 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: capabilities problem 
Cc: [email-masked]
Date: Fri, 21 Oct 2005 14:02:17 -0400
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> Ok. So can we conclude that the inefficiency objection of a second
> round trip in case of GEOPRIV is moot, because it's needed anyway, and 
> that this is solved perfectly by your proposal with my refinements?

  Yes.

> Agreed. Problably the misunderstanding lies in that I take 'advertising
> a capability', as 'This party implements standards document X,
> containing numberous clauses with musts, shoulds and mays', which I find
> problematic. That's perhaps my biggest objection.

  Which is why I avoided implementation and semantic problems, by
saying "advertises a capability".

  First, we can decide what we need from capabilities and their
advertisement, independent of the definitions for each capability.
Then, we can define the capabilities.  Finally, we can describe their
on-wire formate.

> But I want to get rid of the explosion of possible states that a system
> can get when two parties state their abilities, their wishes, and then
> have to do a form of negotiation.
> 
> It took numerous endless looping implementations of PPP to get that
> right in PPP.

  Agreed.  I vew capability negotiations a bit like the final "show of
hands" in poker.  Everyone's cards go on the table, and everyone runs
the same algorithm on the available data.  Once.

> If the use of challenges to get at information that can be put in the
> first access request was Avi's worry too, then I completely agree.

  To put it more strongly, if we don't have *any* capability
advertisement in the first packet, we're back to today's RADIUS, and
we can't break that by changing server behavior.

> Luckily here, you've misunderstood. I'm surprised. Am I really so bad at
> explaining my position clearly?

  There was significant opposition to allowing Avi's scenario.

> So I think we may have complete agreement on the problem and abstract
> solution for GEOPRIV and alike future cases, at least between you, Avi
> and myself. 
> 
> We only need to work out the attributes and values

  I disagree.  I think we're pretty close, but I don't think we're
ready to design a solution based on the stated requirements.  I would
like to ensure that *all* capability requirements are spelled out, to
ensure that the solution is applicable to later capabilities.

  Alan DeKok.

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

Delivery-date: Fri, 21 Oct 2005 10:48:14 +0000
Date: Fri, 21 Oct 2005 12:47:32 +0200
To: "Emile van Bergen" <[email-masked]>, "[email-masked]"@t-online.de
Subject: Re: draft-ietf-radext-digest-auth-06, secure connection
Cc: [email-masked]
From: "[email-masked]" <[email-masked]>

Emile,

several versions ago I've used "secure connection" instead of IPsec.
This
was considered as too vague. Is an unencrypted MPLS VPN secure? How
secure is a dedicated leased line, if you don't know how it is
implemented?

Wolfgang

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

Delivery-date: Fri, 21 Oct 2005 09:28:34 +0000
Date: Fri, 21 Oct 2005 11:27:30 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: capabilities problem
Mail-Followup-To: Alan DeKok <[email-masked]>, Bernard Aboba <[email-masked]>, [email-masked]

Hi,

On Thu, Oct 20, 2005 at 07:01:22PM -0400, Alan DeKok wrote:

> 
> > Indeed.  To put the point more forcefully -- continued attempts to advocate 
> > for the original capabilities advertisement draft are not productive.
> 
>   I don't understand.
> 
>   From my reading of recent messages and the draft, even Avi isn't
> advocating the solution proposed in the draft.  And I'm certainly
> opposed to much of what the draft says, for reasons I've articulated
> previously.
> 
>   To address one of Emile's points:
> 
> > In the case of GEOPRIV, and we've been at this at length, the case
> > of service being dependent on Location information CANNOT be
> > implemented in a single round trip AT ALL, because the NAS first
> > needs to be informed of the user's privacy policy -- in short,
> > whether or not that NAS is allowed to send the user's Location at
> > all.
> 
>   There is no conflict that I can see between this requirement and my
> position, or Avi's position.

Ok. So can we conclude that the inefficiency objection of a second
round trip in case of GEOPRIV is moot, because it's needed anyway, and 
that this is solved perfectly by your proposal with my refinements?

(In short, the NAS indicates (let's go of advertise for a moment, as
that has a broadcasting association with it) in its access request
support for Access-Challenges containing the Challenge-Cause attribute,
telling the server it can send a Challenge without fear of rejection,
and that the NAS will repeat its original access request if it doesn't
understand the Challenge-Cause).

Note that I'm not saying this solves the /other/ issue, that of
mandatory session limiting attributes ('prepaid'). There we /do/ want to
avoid a second round trip if possible, because its necessity has not
been demonstrated on other grounds.

>   The ability to perform multi-round negotiation of data to include in
> a packet is itself a capability that can be advertised.  That
> capability MUST (IMHO) be advertised in the first packet, otherwise
> the server may send an Access-Challenge to a NAS that doesn't support
> it.  The user then ends up with no service rather than limited service.

Agreed. Problably the misunderstanding lies in that I take 'advertising
a capability', as 'This party implements standards document X,
containing numberous clauses with musts, shoulds and mays', which I find
problematic. That's perhaps my biggest objection.

If you understand the advertised capability as semantically narrow as I
explained it ('the capability indicates that the NAS will behave as
follows when presented with information as follows'), then we are on the
same page.

>   The only disagreement I can see is that Avi and I believe that
> multi-round capability negotiation is itself a capability that has to
> be advertised, and others believe it's OK to send Access-Challenge
> without knowing if the NAS supports it.

I agree that it has to be advertised. In numerous messages about this
subject, including the one where I expanded on your suggestion that for
GEOPRIV, the NAS mainly has to advertise that it won't reject on
challenges that are properly labeled, I've said so.

>   For the record, my original position was that I was OK with blindly
> sending Access-Challenge, as it was fail safe.  But if there are
> use-cases where it's useful to offer limited services, then sending
> Access-Challenge is itself a capability that has to be negotiated or
> advertised.  The alternative is to make it impossible to "fail
> gracefully", and offer limited service.  The choice will be all or
> nothing.

We completely agree. I just want to make the semantics of the
advertisement as narrow as possible, without loss of generality (even
gaining it, because this support for 'reason-explained challenges' can
also be used for future things).

But I want to get rid of the explosion of possible states that a system
can get when two parties state their abilities, their wishes, and then
have to do a form of negotiation.

It took numerous endless looping implementations of PPP to get that
right in PPP.

If not absolutely needed, I definitely don't want negotiation, and I
want advertisements to be very narrow and with very well defined results
in case it does not sent or is not understood by the receiver, and so
on.

>   To put it another way:
> 
>   If Emile's NAS supports multi-round negotiation, then it advertises
> that, and the NAS and server perform the negotiation that Emile wants.

Inquiries, using particularly formed challenges, not negotiation. My
mechanism (Challenge-Supported = Yes and Challenge-Cause) could be used
for multi-round negotiation, but I'm not proposing that.

It's wasteful to use inquiries for information that can be included in
the first and final access request. It's only needed where the NAS MUST
withhold information from the first access request, as is the case with
GEOPRIV. 

If the use of challenges to get at information that can be put in the
first access request was Avi's worry too, then I completely agree.

I'm NOT proposing these challenges as the mechanism for all cases where the
server requires information from the NAS it currently doesn't have.

I am ONLY proposing these challenges as a mechanism for the cases where
the server requires information from the NAS that the NAS IS NOT ABLE to
send in its first Access-Request. Case in point: GEOPRIV, reason:
location privacy.

The 'advertisement' of support of a certain set of session limiting
attributes (and this is only a single bit of information per attribute
at most and a single bit of information per set of attributes at
minimum) can be done in the first access request. No extra roundtrips
necessary.

>   If Avi's NAS doesn't support multi-round negotiation, then it
> advertises that, and rather than doing negotiation, the server offers
> limited service, which is what Avi wants.

That phrase, 'multi-round negotiation', sends shivers down my spine as
it evokes the thought of endlessly debugging negotiations that don't
converge in certain implementations due to /very/ subtle bugs, and
admins having to fine tuning the advertisements so that the other side
responds correctly, and on and on.

>   I don't see any disagreement between the two positions, and I don't
> see how this relates to the original draft, which didn't talk about
> these issues.
> 
>   Avi's position (I believe), and mine, is to allow both scenarios.
> Emile's position (from what I can understand) would appear to prevent
> Avi from deploying his scenario.

Luckily here, you've misunderstood. I'm surprised. Am I really so bad at
explaining my position clearly?

I totally agree that the NAS must advertise that it will respond in a
certain defined way to challenges, for them to be useful as a mechanism
for GEOPRIV and related things.

(And to prevent all misunderstanding here: 'related things' DOES NOT
include CUI, session limiting attributes and and other static
information about the NAS!).

So I think we may have complete agreement on the problem and abstract
solution for GEOPRIV and alike future cases, at least between you, Avi
and myself. 

We only need to work out the attributes and values, but I suggest we
postpone that for a second and work on the problem statement for servers
requiring advance knowledge about the NAS' response to certain session
limiting attributes.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Fri, 21 Oct 2005 01:28:16 +0000
Content-class: urn:content-classes:message
Subject: RE: capabilities problem
Date: Thu, 20 Oct 2005 21:28:39 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

This email and the previous one from Emile seems to be suggesting that I
am promoting a solution --  That I am "pounding on it" I resent that
strongly.=20

Since Bernard's email I have been discussion only requirements!!!

But I also want to point out for the record that it is only few that are
opposing the solution proposed in the draft.=20

For example, in Paris there was lots of support and I don't belive
anyone rejected it.

But be that as it may, as I have demonstrated I am willing to shed the
old and discuss requirements.

So lets move on and both Emile and Bernard stop the presonal attacks!!!

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Thursday, October 20, 2005 6:08 PM
> To: [email-masked]
> Subject: Re: capabilities problem
>=20
> Emile Bergen said:
>=20
> "Few seem to have joined you in blessing the original=20
> capabilities advertising draft as a candidate for a solution=20
> that even reaches the required level of precision and generality.
>=20
> To do so is premature, and it would help if you didn't keep=20
> pounding on it."
>=20
> Indeed.  To put the point more forcefully -- continued=20
> attempts to advocate for the original capabilities=20
> advertisement draft are not productive.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Oct 2005 22:58:26 +0000
From: "Alan DeKok" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>
Subject: Re: capabilities problem 
Cc: [email-masked]
Message-Id: <[email-masked]>
Date: Thu, 20 Oct 2005 19:01:22 -0400 (EDT)

> Indeed.  To put the point more forcefully -- continued attempts to advocate 
> for the original capabilities advertisement draft are not productive.

  I don't understand.

  From my reading of recent messages and the draft, even Avi isn't
advocating the solution proposed in the draft.  And I'm certainly
opposed to much of what the draft says, for reasons I've articulated
previously.

  To address one of Emile's points:

> In the case of GEOPRIV, and we've been at this at length, the case
> of service being dependent on Location information CANNOT be
> implemented in a single round trip AT ALL, because the NAS first
> needs to be informed of the user's privacy policy -- in short,
> whether or not that NAS is allowed to send the user's Location at
> all.

  There is no conflict that I can see between this requirement and my
position, or Avi's position.

  The ability to perform multi-round negotiation of data to include in
a packet is itself a capability that can be advertised.  That
capability MUST (IMHO) be advertised in the first packet, otherwise
the server may send an Access-Challenge to a NAS that doesn't support
it.  The user then ends up with no service rather than limited service.

  The only disagreement I can see is that Avi and I believe that
multi-round capability negotiation is itself a capability that has to
be advertised, and others believe it's OK to send Access-Challenge
without knowing if the NAS supports it.

  For the record, my original position was that I was OK with blindly
sending Access-Challenge, as it was fail safe.  But if there are
use-cases where it's useful to offer limited services, then sending
Access-Challenge is itself a capability that has to be negotiated or
advertised.  The alternative is to make it impossible to "fail
gracefully", and offer limited service.  The choice will be all or
nothing.

  To put it another way:

  If Emile's NAS supports multi-round negotiation, then it advertises
that, and the NAS and server perform the negotiation that Emile wants.

  If Avi's NAS doesn't support multi-round negotiation, then it
advertises that, and rather than doing negotiation, the server offers
limited service, which is what Avi wants.

  I don't see any disagreement between the two positions, and I don't
see how this relates to the original draft, which didn't talk about
these issues.

  Avi's position (I believe), and mine, is to allow both scenarios.
Emile's position (from what I can understand) would appear to prevent
Avi from deploying his scenario.

  Alan DeKok.

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

Delivery-date: Thu, 20 Oct 2005 22:30:28 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call on RFC 3576 MIBs
Date: Thu, 20 Oct 2005 15:30:13 -0700

This is an announcement of RADEXT WG last call on the RFC 3576 MIBs, prior 
to sending the documents on to the IESG for publication as Informational 
RFCs. The documents will be available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-client-mib-02.txt
http://www.ietf.org/internet-drafts/draft-ietf-radext-dynauth-server-mib-02.txt

RADEXT WG last call will last until Monday, November 14, 2005. Please send 
comments to the RADEXT WG mailing list ([email-masked]) in the 
format described in the RADEXT Issues list:

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

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

Delivery-date: Thu, 20 Oct 2005 22:08:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: capabilities problem
Date: Thu, 20 Oct 2005 15:08:19 -0700

Emile Bergen said:

"Few seem to have joined you in blessing the original capabilities 
advertising draft as a candidate for a solution that even reaches the 
required level of precision and generality.

To do so is premature, and it would help if you didn't keep pounding on it."

Indeed.  To put the point more forcefully -- continued attempts to advocate 
for the original capabilities advertisement draft are not productive.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Oct 2005 21:05:22 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: Capabilities: Moving forward - to the problem, please 
Cc: [email-masked]
Date: Thu, 20 Oct 2005 17:08:15 -0400
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> But for the life of me, I did not see any connection between the two
> problematic scenarios and even C1, leave alone the rest.

  I tried to explain the connection.

  Avi's requirement is that we can't send Access-Challenge unless we
*know* the NAS won't treat it as Access-Reject.  That pretty much
forces some kind of capability advertisement in the first
Access-Request.  Add to that the belief that multiple round trips are
inefficient, and you have C1.

> If that's deduction, then I'm missing it, but I sure could do with some
> more steps in the line of reasoning there. It doesn't help to say, we've
> want GEOPRIV, we want mandatory session limiting, therefore all
> capabilties need to be advertised. QED.

  My previous proposal of a "challenge-capable" attribute minimizes
the capability advertisements in the first packet, and maximizes the
resulting traffic.

  If that's fine for you, OK.  But it's not fine for Avi, and I agree
with him here.

> Agreed. I'll do my best, but I was really surprised at what I saw as
> your complete ignoring of Bernard's suggestion to leave the solutions
> aside for a while and to focus on the problem first.

  I wasn't proposing a solution.  I was proposing a list of
requirements that would enable a capability solution to be
implemented.  My $0.02 is that if one of those requirements is not
satisfied, we probably will not be able to implement *any*
interoperable solution.

  There is a very big difference between saying "bits on the wire look
like X", and saying "in order for two parties to agree, they have to
exchange information".  Bernard wanted to avoid the first kind of
discussion, and I agree with him.  My requirements were solely of the
second kind.

> You repeated the two problems I've described too, without responding
> to my description of them, without adding any detail, scope or
> implications, and then skipping straight to a set of requirements
> for a solution.

  Uh, no.  I responded to Bernard's post, not yours.  The list
archives indicate that there have been no followups to your response.

> Not in a vague, general sense; but as in "for GEOPRIV, the NAS needs to
> know a single bit that says whether a user's privacy policy allows it to
> send Location information. The NAS currently has no way of obtaining
> that bit. In most cases the RADIUS server will have it, because that's
> generally where the user's profile is stored. Therefore GEOPRIV requires
> a roundtrip to the RADIUS server before an access request containing
> Location information can be sent, to obtain the bit. One way, but
> perhaps not the only way, of implementing that first roundtrip is as an
> Access-Request/Access-Challenge transaction".

  That contains a lot of implementation details, and is substantially
a proposed solution.

  My preference is to discuss the *concept* of capability exchange and
advertisement.  i.e. how two parties can mutually agree on *any*
capabilities via some general method.  i.e. what are the minimum
requirements for that agreement to be reached, like "the parties must
communicate".

  Alan DeKok.

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

Delivery-date: Thu, 20 Oct 2005 20:54:52 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RADEXT WG last call on RFC 2618bis-2621bis
Date: Thu, 20 Oct 2005 13:54:47 -0700

This is an announcement of RADEXT WG last call on RFC 2618bis-2621bis, prior 
to sending the documents on to the IESG for consideration as Proposed 
Standards (2618bis, 26819bis) and Informational (2620bis, 2621bis).  The 
documents are available for inspection here:

http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2618bis-01.txt 
(Proposed Standard)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2619bis-01.txt 
(Proposed Standard)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2620bis-01.txt 
(Informational)
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc2621bis-01.txt 
(Informational)

RADEXT WG last call will last until Monday, November 14, 2005.  Please send 
comments to the RADEXT WG mailing list ([email-masked]) in the 
format described in the RADEXT Issues list:

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

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

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Oct 2005 20:51:03 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Capabilities: Moving forward - to the problem, please 
Cc: Barney Wolff <[email-masked]>
Date: Thu, 20 Oct 2005 16:53:43 -0400
Message-Id: <[email-masked]>

Barney Wolff <[email-masked]> wrote:
> If we want to solve the general problem that the NAS and server
> belonging to two different administrations need to understand what
> features of RADIUS each supports and requires, we should be looking
> for solutions that solve the general problem, while also solving
> the specific problems we know about today.

  I'm working on a "capabilities model" draft.  It's pretty rough
right now, but it should cover the general scenario.

  Some assumptions: Both NAS & server have capabilities.  Each may try
to discover the capabilities of each other.  The capability
information is exchanged via advertisements in packets.  The NAS
initiates the conversation.  The server cannot negotiate capabilities
with the NAS if the NAS capabilities do not include "capability
negotiation".  RADIUS conversations do not currently include
capability advertisement.

  A *lot* of conclusions come from those assumptions, including the
ones presented in my previous message.  I also believe that those
assumptions are reasonable, and are taken from discussions on this list.

  If anyone disagrees with one or more of those assumptions, I'd love
to hear it.

  Alan DeKok.

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

Delivery-date: Thu, 20 Oct 2005 20:02:03 +0000
Date: Thu, 20 Oct 2005 16:01:41 -0400
From: Barney Wolff <[email-masked]>
To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Capabilities: Moving forward - to the problem, please

On Thu, Oct 20, 2005 at 09:50:14PM +0200, Emile van Bergen wrote:
> 
> Unless we start doing that, explaining the *problem* at the bit level,
> without immediately going to broad generalities, I don't think we'll
> ever reach consensus about any solution.

With all due respect, I think this approach is completely wrong.  If
we want to solve individual problems with individual solutions, fine
and dandy, but we'll never be done.

If we want to solve the general problem that the NAS and server
belonging to two different administrations need to understand what
features of RADIUS each supports and requires, we should be looking
for solutions that solve the general problem, while also solving
the specific problems we know about today.

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

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

Delivery-date: Thu, 20 Oct 2005 19:50:43 +0000
Date: Thu, 20 Oct 2005 21:50:14 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Capabilities: Moving forward - to the problem, please
Mail-Followup-To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]

Alan, Avi,

On Thu, Oct 20, 2005 at 12:34:46PM -0400, Alan DeKok wrote:

> Emile van Bergen <[email-masked]> wrote:
> > Are you being serious? You're *seriously* claiming each item follows
> > from the previous one?
> 
>   I would prefer that you discuss the content of my message, rather
> than the manner in which it was presented.  That would be much more
> productive.

I did. I read the content as a list of requirements for a solution to
the two problems we seem to agree on.

But for the life of me, I did not see any connection between the two
problematic scenarios and even C1, leave alone the rest.

If that's deduction, then I'm missing it, but I sure could do with some
more steps in the line of reasoning there. It doesn't help to say, we've
want GEOPRIV, we want mandatory session limiting, therefore all
capabilties need to be advertised. QED.

> > I think you missed Bernard's line that shopping lists make bad design
> > documents. You seem to try and distill requirements from every shopping
> > list item that has ever floated here.
> 
>   No.  I started with the two scenairos as stated in my message.  The
> first requirement (C1) followed from that.  You haven't presented
> concrete objections to that, or any of the other statements.

My concrete objection is that it's a /very/ broad statement, presented
without much explanation as THE requirement for ANY sane solution to the
two problems.

The steps you took to arrive at that conclusion were perhaps present in
one the 10-20 earlier attempts, but I didn't find them in the version
you sent.

> > So, if we FIRST get a SHORT list of real world problems that are
> > currently fundamentally impossible to solve due to lack of information
> > at the client or server AND clearly describe the decision that cannot be
> > made correctly due to the lacking information,
> 
>   My message did so.  You haven't responded to it.
> 
>   I think part of the problem here is that we're talking at cross
> purposes.  I've been reading the different posts, and trying to
> distill a common set of scenarios.  I presented those, and some
> requirements in my post.  Rather than address those, you've responded
> with your own set of requirements.

I didn't respond with my own set of requirements to the solution. I
responded with a set of suggestions for the /process/ to arrive at a
solution, starting from Bernard's suggestion to focus on a clear problem
statement first.

I also added the capabilities-related problems I've been able to gather
from the discussion, and tried to describe them in terms of missing
information at either party.

>   If the conversation is going to be nothing more than people
> presenting what they want, and ignoring what other people say, I don't
> see any point in continuing.

Agreed. I'll do my best, but I was really surprised at what I saw as
your complete ignoring of Bernard's suggestion to leave the solutions
aside for a while and to focus on the problem first.

You repeated the two problems I've described too, without responding to
my description of them, without adding any detail, scope or
implications, and then skipping straight to a set of requirements for a
solution. My reaction is basically that you haven't demonstrated at all
that those requirements follow from the problem.

Avi, I also think it doesn't help to make broad references to features
('prepaid', 'cui', 'geopriv') to make a case for any capabilities
design. What does help is to describe, in excruciating detail, who needs
what information when (and why). 

Not in a vague, general sense; but as in "for GEOPRIV, the NAS needs to
know a single bit that says whether a user's privacy policy allows it to
send Location information. The NAS currently has no way of obtaining
that bit. In most cases the RADIUS server will have it, because that's
generally where the user's profile is stored. Therefore GEOPRIV requires
a roundtrip to the RADIUS server before an access request containing
Location information can be sent, to obtain the bit. One way, but
perhaps not the only way, of implementing that first roundtrip is as an
Access-Request/Access-Challenge transaction".

Unless we start doing that, explaining the *problem* at the bit level,
without immediately going to broad generalities, I don't think we'll
ever reach consensus about any solution.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Thu, 20 Oct 2005 17:20:48 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Moving forward - to the problem, please
Date: Thu, 20 Oct 2005 13:21:50 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Hi Alan,=20

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf=20
> Of Alan DeKok
> Sent: Thursday, October 20, 2005 1:19 PM
> To: Avi Lior
> Cc: [email-masked]
> Subject: Re: Capabilities: Moving forward - to the problem, please
>=20
> "Avi Lior" <[email-masked]> wrote:
> > So how about the above as a concise package of requirements......
>=20
>   I agree.  I'd just add (D) as efficiency.

Thanx...

>   I think my requirement list follows from yours.  I'll=20
> update my list, and map it to your requirments.

Great.
=20
>   My list was *not* intended to be a laundry list of requirements.
> For example, if you look at the MUST's and SHOULD's in a=20
> standard, you could easily concluse that the spec is nothing=20
> more than a laundry list of requirements.

Understood...
=20
>   My list was meant to satisfy another, unspoken requirement:=20
> we have to be able to deploy this, and to have interoperable=20
> implementations.

I think we are on a convergent path...
=20
>   Alan DeKok.
>=20

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

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Oct 2005 17:15:56 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: Capabilities: Moving forward - to the problem, please 
Cc: [email-masked]
Date: Thu, 20 Oct 2005 13:18:44 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> So how about the above as a concise package of requirements......

  I agree.  I'd just add (D) as efficiency.

  I think my requirement list follows from yours.  I'll update my
list, and map it to your requirments.

  My list was *not* intended to be a laundry list of requirements.
For example, if you look at the MUST's and SHOULD's in a standard, you
could easily concluse that the spec is nothing more than a laundry
list of requirements.

  My list was meant to satisfy another, unspoken requirement: we have
to be able to deploy this, and to have interoperable implementations.

  Alan DeKok.

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

Envelope-to: [email-masked]
Delivery-date: Thu, 20 Oct 2005 16:31:56 +0000
From: "Alan DeKok" <[email-masked]>
To: Emile van Bergen <[email-masked]>
Subject: Re: Capabilities: Moving forward - to the problem, please 
Cc: [email-masked]
Date: Thu, 20 Oct 2005 12:34:46 -0400
Message-Id: <[email-masked]>

Emile van Bergen <[email-masked]> wrote:
> Are you being serious? You're *seriously* claiming each item follows
> from the previous one?

  I would prefer that you discuss the content of my message, rather
than the manner in which it was presented.  That would be much more
productive.

> I think you missed Bernard's line that shopping lists make bad design
> documents. You seem to try and distill requirements from every shopping
> list item that has ever floated here.

  No.  I started with the two scenairos as stated in my message.  The
first requirement (C1) followed from that.  You haven't presented
concrete objections to that, or any of the other statements.

> So, if we FIRST get a SHORT list of real world problems that are
> currently fundamentally impossible to solve due to lack of information
> at the client or server AND clearly describe the decision that cannot be
> made correctly due to the lacking information,

  My message did so.  You haven't responded to it.

  I think part of the problem here is that we're talking at cross
purposes.  I've been reading the different posts, and trying to
distill a common set of scenarios.  I presented those, and some
requirements in my post.  Rather than address those, you've responded
with your own set of requirements.

  If the conversation is going to be nothing more than people
presenting what they want, and ignoring what other people say, I don't
see any point in continuing.

> Can we please, pretty please, get clarity about this? Do you, others,
> agree that these are the only two real problems related to missing
> information at either client or server side?

  Since you ignored my requirement statement, I'm not sure how my
addressing yours would move the discussion forward.

  Alan DeKok.

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

Delivery-date: Thu, 20 Oct 2005 16:07:51 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Moving forward - to the problem, please
Date: Thu, 20 Oct 2005 12:08:21 -0400
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>, "Bernard Aboba" <[email-masked]>

There are a minimum of three cases - all of which have been evident in
recent work:

A) One from Prepaid.
B) One from Geopriv.
C) One from CUI.=20

A) The AAA server needs to know what the NAS supports so that it can
send the appropriate authorization attributes to the NAS or take  other
action (make adjustments).

B) The AAA server needs to obtain some information form the NAS inorder
to correctly authenticate and properly authorize the user session.

C) The NAS needs some information from the AAA-Server inorder to satsify
some business relationship requirements.

Also I don't think your GEOPRIV is statement is stated correctly.  It's
the AAA server that needs the information, the NAS could careless.

There are also other requiremetns that we cant forget and that is that
we want to make sure that we don't use excessive messages to achieve
these goals.

So how about the above as a concise package of requirements......

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Emile van Bergen
> Sent: Thursday, October 20, 2005 5:39 AM
> To: Alan DeKok
> Cc: [email-masked]; Bernard Aboba
> Subject: Re: Capabilities: Moving forward - to the problem, please
>=20
> Alan,
>=20
> Are you being serious? You're *seriously* claiming each item=20
> follows from the previous one?
>=20
> I think you missed Bernard's line that shopping lists make=20
> bad design documents. You seem to try and distill=20
> requirements from every shopping list item that has ever floated here.
>=20
> I've understood Bernard's call for concentrating on "The=20
> Problem" as a request to weed out the ones that have real=20
> substance, in my mind the problems that fundamentally require=20
> information at either the client or server side that's=20
> currently missing. The ones where no implementation can=20
> currently behave correctly.
>=20
> So, if we FIRST get a SHORT list of real world problems that=20
> are currently fundamentally impossible to solve due to lack=20
> of information at the client or server AND clearly describe=20
> the decision that cannot be made correctly due to the lacking=20
> information, we can THEN worry about where the information=20
> must come from, next about when it should be provided, and=20
> lastly how it should be represented on the wire.
>=20
> So far, I've seen only two:
>=20
> * A NAS that cannot decide what information it is allowed to=20
> put in the
>   access request because it first needs information about the user
>   (GEOPRIV);
>=20
> * A server that cannot decide what information it must put in its
>   access accept, or whether to send an accept at all, because it does
>   not know if the NAS will act upon a set of session limiting
>   attributes deemed critical by the server ('prepaid').
>=20
> Can we please, pretty please, get clarity about this? Do you,=20
> others, agree that these are the only two real problems=20
> related to missing information at either client or server side?
>=20
> Cheers,
>=20
>=20
> Emile.
>=20
> On Wed, Oct 19, 2005 at 07:26:40PM -0400, Alan DeKok wrote:
>=20
> > "Bernard Aboba" <[email-masked]> wrote:
> > > Rather, the hallmark of a good problem statement is=20
> brevity, leading=20
> > > to solutions which do what is necessary and little more.
> >=20
> >   << 10-20 attempts later >>
> >=20
> >   The server cannot send Access-Accept in some cases unless=20
> it is sure=20
> > that the NAS will behave appropriately (i.e. prepaid).  Otherwise,=20
> > services may be offered, but not billed to someone.
> >=20
> >   The server cannot send Access-Challenge to the NAS, because it=20
> > doesn't know if the NAS will treat that as Access-Reject, or as=20
> > extended capability negotiation.
> >=20
> >   Therefore, the ONLY requirement that matters here is the=20
> first one=20
> > listed below.  Later capabilites are follow-ons from it.  These=20
> > requirements also avoid the issue raised on the capability=20
> draft of a=20
> > NAS "rejecting" a response from a server, which can't happen in=20
> > RADIUS.
> >=20
> >     C1: For new capabilities, Access-Request MUST ALWAYS contain a
> >         capability advertisement.
> >=20
> >   For efficiency, and to avoid unecessary Access-Challenge:
> >=20
> >     C2: The advertisement MUST include advertisement of all
> >         capabilities
> >=20
> >   For GEOPRIV and related issues:
> >=20
> >     C3: The advertisement MAY include data for only some of the
> >         capabilities (i.e. location capability, but no=20
> location data)
> >=20
> >   To later get GEOPRIV location data:
> >=20
> >     C4: The advertisement MUST include indication of support for
> >         Access-Challenge responses to Access-Request with PAP.
> >=20
> >   To deal with mandatory and requested capabilities:
> >=20
> >     C5: The advertisement implementation MUST support both mandatory
> >         and requested capabilities.
> >=20
> >   To deal with server's capabilities:
> >=20
> >     C6: A server MUST be able to send capabilities, just like a NAS
> >=20
> >   To deal with backwards compatibilty:
> >=20
> >     C7: A server MUST NOT send capability advertisement to a NAS
> >         if the Access-Request did not contain a capability=20
> advertisement
> >         (modulo EAP, etc, where capabilities can be cached=20
> per-session,
> >          and therefore don't have to be sent in each packet)
> >=20
> >   To deal with information leak:
> >=20
> >     C8: A server MUST NOT advertise to a NAS that the=20
> server is capable
> >         of services that the NAS did not advertise as being=20
> mandatory
> >         or requested
> >=20
> >   To ensure security:
> >=20
> >     C9: A server MUST send an Access-Reject if a capability it deems
> >         mandatory is not advertised by the NAS.
> >=20
> >   To help with debugging:
> >=20
> >     C10: A server MAY advertise mandatory capabilities in=20
> an Access-Reject,
> >          as a hint to the NAS about why the request was rejected.
> >=20
> >   To deal with per-capability data (also see C4).
> >=20
> >     C11: The capability negotiation MUST include support for
> >          per-capability data.
> >=20
> >   To deal with the content of the data:
> >=20
> >     C12: The capability negotiation MUST include the ability for
> >          the server to indicate to the NAS that the data supplied is
> >          inadequate or improper.
> >=20
> >   To deal with proxying:
> >=20
> >     C13: Packets containing capability advertisements MAY be proxied
> >=20
> >   To deal with proxy security:
> >=20
> >     C14: Proxied Access-Request packets MUST have their capability
> >          advertisements updated with the intersection of=20
> capabilities
> >          of the NAS and the proxying server.  (i.e. the NAS supports
> >          CoA, but the proxy doesn't)
> >=20
> >   To deal with proxying by servers unaware of new capabilities:
> >=20
> >     C15: Capabilities MUST be validated per-hop.
> >          e.g. signed, or containing information that will not be
> >          updated by a capability un-aware proxy
> >=20
> >   <whew> Comments?  Did anyone read this far?
> >=20
> >   That's all I have for now.  I think it covers a lot of=20
> the problem=20
> > space and discussion.
> >=20
> >   Alan DeKok.
> >=20
> > --
> > to unsubscribe send a message to=20
> [email-masked] with=20
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
>=20
> --=20
> E-Advies - Emile van Bergen           [email-masked]     =20
> tel. +31 (0)78 6136282           http://www.e-advies.nl   =20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Thu, 20 Oct 2005 09:39:56 +0000
Date: Thu, 20 Oct 2005 11:39:11 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: [email-masked], Bernard Aboba <[email-masked]>
Subject: Re: Capabilities: Moving forward - to the problem, please
Mail-Followup-To: Alan DeKok <[email-masked]>, [email-masked], Bernard Aboba <[email-masked]>

Alan,

Are you being serious? You're *seriously* claiming each item follows
from the previous one?

I think you missed Bernard's line that shopping lists make bad design
documents. You seem to try and distill requirements from every shopping
list item that has ever floated here.

I've understood Bernard's call for concentrating on "The Problem" as a
request to weed out the ones that have real substance, in my mind the
problems that fundamentally require information at either the client or
server side that's currently missing. The ones where no implementation
can currently behave correctly.

So, if we FIRST get a SHORT list of real world problems that are
currently fundamentally impossible to solve due to lack of information
at the client or server AND clearly describe the decision that cannot be
made correctly due to the lacking information, we can THEN worry about
where the information must come from, next about when it should be
provided, and lastly how it should be represented on the wire.

So far, I've seen only two:

* A NAS that cannot decide what information it is allowed to put in the
  access request because it first needs information about the user
  (GEOPRIV);

* A server that cannot decide what information it must put in its
  access accept, or whether to send an accept at all, because it does
  not know if the NAS will act upon a set of session limiting
  attributes deemed critical by the server ('prepaid').

Can we please, pretty please, get clarity about this? Do you, others,
agree that these are the only two real problems related to missing
information at either client or server side?

Cheers,

Emile.

On Wed, Oct 19, 2005 at 07:26:40PM -0400, Alan DeKok wrote:

> "Bernard Aboba" <[email-masked]> wrote:
> > Rather, the hallmark of a good problem statement is brevity, leading to 
> > solutions which do what is necessary and little more.
> 
>   << 10-20 attempts later >>
> 
>   The server cannot send Access-Accept in some cases unless it is sure
> that the NAS will behave appropriately (i.e. prepaid).  Otherwise,
> services may be offered, but not billed to someone.
> 
>   The server cannot send Access-Challenge to the NAS, because it
> doesn't know if the NAS will treat that as Access-Reject, or as
> extended capability negotiation.
> 
>   Therefore, the ONLY requirement that matters here is the first one
> listed below.  Later capabilites are follow-ons from it.  These
> requirements also avoid the issue raised on the capability draft of a
> NAS "rejecting" a response from a server, which can't happen in
> RADIUS.
> 
>     C1: For new capabilities, Access-Request MUST ALWAYS contain a
>         capability advertisement.
> 
>   For efficiency, and to avoid unecessary Access-Challenge:
> 
>     C2: The advertisement MUST include advertisement of all
>         capabilities
> 
>   For GEOPRIV and related issues:
> 
>     C3: The advertisement MAY include data for only some of the
>         capabilities (i.e. location capability, but no location data)
> 
>   To later get GEOPRIV location data:
> 
>     C4: The advertisement MUST include indication of support for
>         Access-Challenge responses to Access-Request with PAP.
> 
>   To deal with mandatory and requested capabilities:
> 
>     C5: The advertisement implementation MUST support both mandatory
>         and requested capabilities.
> 
>   To deal with server's capabilities:
> 
>     C6: A server MUST be able to send capabilities, just like a NAS
> 
>   To deal with backwards compatibilty:
> 
>     C7: A server MUST NOT send capability advertisement to a NAS
>         if the Access-Request did not contain a capability advertisement
>         (modulo EAP, etc, where capabilities can be cached per-session,
>          and therefore don't have to be sent in each packet)
> 
>   To deal with information leak:
> 
>     C8: A server MUST NOT advertise to a NAS that the server is capable
>         of services that the NAS did not advertise as being mandatory
>         or requested
> 
>   To ensure security:
> 
>     C9: A server MUST send an Access-Reject if a capability it deems
>         mandatory is not advertised by the NAS.
> 
>   To help with debugging:
> 
>     C10: A server MAY advertise mandatory capabilities in an Access-Reject,
>          as a hint to the NAS about why the request was rejected.
> 
>   To deal with per-capability data (also see C4).
> 
>     C11: The capability negotiation MUST include support for
>          per-capability data.
> 
>   To deal with the content of the data:
> 
>     C12: The capability negotiation MUST include the ability for
>          the server to indicate to the NAS that the data supplied is
>          inadequate or improper.
> 
>   To deal with proxying:
> 
>     C13: Packets containing capability advertisements MAY be proxied
> 
>   To deal with proxy security:
> 
>     C14: Proxied Access-Request packets MUST have their capability
>          advertisements updated with the intersection of capabilities
>          of the NAS and the proxying server.  (i.e. the NAS supports
>          CoA, but the proxy doesn't)
> 
>   To deal with proxying by servers unaware of new capabilities:
> 
>     C15: Capabilities MUST be validated per-hop.
>          e.g. signed, or containing information that will not be
>          updated by a capability un-aware proxy
> 
>   <whew> Comments?  Did anyone read this far?
> 
>   That's all I have for now.  I think it covers a lot of the problem
> space and discussion.
> 
>   Alan DeKok.
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Envelope-to: [email-masked]
Delivery-date: Wed, 19 Oct 2005 23:24:27 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Capabilities: Moving forward 
Cc: "Bernard Aboba" <[email-masked]>
Date: Wed, 19 Oct 2005 19:26:40 -0400
Message-Id: <[email-masked]>

"Bernard Aboba" <[email-masked]> wrote:
> Rather, the hallmark of a good problem statement is brevity, leading to 
> solutions which do what is necessary and little more.

  << 10-20 attempts later >>

  The server cannot send Access-Accept in some cases unless it is sure
that the NAS will behave appropriately (i.e. prepaid).  Otherwise,
services may be offered, but not billed to someone.

  The server cannot send Access-Challenge to the NAS, because it
doesn't know if the NAS will treat that as Access-Reject, or as
extended capability negotiation.

  Therefore, the ONLY requirement that matters here is the first one
listed below.  Later capabilites are follow-ons from it.  These
requirements also avoid the issue raised on the capability draft of a
NAS "rejecting" a response from a server, which can't happen in
RADIUS.

    C1: For new capabilities, Access-Request MUST ALWAYS contain a
        capability advertisement.

  For efficiency, and to avoid unecessary Access-Challenge:

    C2: The advertisement MUST include advertisement of all
        capabilities

  For GEOPRIV and related issues:

    C3: The advertisement MAY include data for only some of the
        capabilities (i.e. location capability, but no location data)

  To later get GEOPRIV location data:

    C4: The advertisement MUST include indication of support for
        Access-Challenge responses to Access-Request with PAP.

  To deal with mandatory and requested capabilities:

    C5: The advertisement implementation MUST support both mandatory
        and requested capabilities.

  To deal with server's capabilities:

    C6: A server MUST be able to send capabilities, just like a NAS

  To deal with backwards compatibilty:

    C7: A server MUST NOT send capability advertisement to a NAS
        if the Access-Request did not contain a capability advertisement
        (modulo EAP, etc, where capabilities can be cached per-session,
         and therefore don't have to be sent in each packet)

  To deal with information leak:

    C8: A server MUST NOT advertise to a NAS that the server is capable
        of services that the NAS did not advertise as being mandatory
        or requested

  To ensure security:

    C9: A server MUST send an Access-Reject if a capability it deems
        mandatory is not advertised by the NAS.

  To help with debugging:

    C10: A server MAY advertise mandatory capabilities in an Access-Reject,
         as a hint to the NAS about why the request was rejected.

  To deal with per-capability data (also see C4).

    C11: The capability negotiation MUST include support for
         per-capability data.

  To deal with the content of the data:

    C12: The capability negotiation MUST include the ability for
         the server to indicate to the NAS that the data supplied is
         inadequate or improper.

  To deal with proxying:

    C13: Packets containing capability advertisements MAY be proxied

  To deal with proxy security:

    C14: Proxied Access-Request packets MUST have their capability
         advertisements updated with the intersection of capabilities
         of the NAS and the proxying server.  (i.e. the NAS supports
         CoA, but the proxy doesn't)

  To deal with proxying by servers unaware of new capabilities:

    C15: Capabilities MUST be validated per-hop.
         e.g. signed, or containing information that will not be
         updated by a capability un-aware proxy

  <whew> Comments?  Did anyone read this far?

  That's all I have for now.  I think it covers a lot of the problem
space and discussion.

  Alan DeKok.

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

Delivery-date: Wed, 19 Oct 2005 21:40:52 +0000
Date: Wed, 19 Oct 2005 23:40:06 +0200
From: Emile van Bergen <[email-masked]>
To: Avi Lior <[email-masked]>
Cc: Alan DeKok <[email-masked]>, [email-masked]
Subject: Re: Capabilities: Summary - refined proposal
Mail-Followup-To: Avi Lior <[email-masked]>, Alan DeKok <[email-masked]>, [email-masked]

Hi,

On Wed, Oct 19, 2005 at 12:06:58PM -0400, Avi Lior wrote:

> Alan and Emile see below: 
> 
> First of all you are advertizing but you are advertizing one capability.
> 
> But the affect of doing what you suggest is to force a challenge
> everytime.  This is problematic since we try to reduce the number of
> messages exchanged.  
> 
> Consider the prepaid case.  Here the AAA-Server will need to send
> attributes to the NAS to control the session.  Simply sending the
> prepaid attributes to the NAS could result in giving the user free
> service.  Since a NAS that does not understand the attributes will
> simply ignore them.
> 
> In the scheme proposed above the AAA-Server will always have to
> challenge for the NAS to see if it supports Prepaid.  So for the
> millions of prepaid users that attempt to login we will have to send
> millions of extra messages.
> 
> In our proposal the NAS will simply indicate right up front whether it
> supports prepaid or not.  Saving millions of messages a day.

I am not addressing prepaid here. Service limiting attributes are
another discussion. Please see my post to the 'Problem statement'
thread.

> I strongly encourage all of us to be mindful of sending extra messages
> because in large deployements this makes a big difference.

What makes you think we're not? "Won't somebody please mind the
roundtrips!" is getting, frankly, a bit repetitive.

> Yes but your proposal requires extra messaging.  And I think you are
> being over dramatic about an infitie list of implementations to manage.

My proposal is about the case where the NAS withholds information from
the initial access request, for privacy reasons. I'm talking about
GEOPRIV and related things, NOT prepaid.

In the case of GEOPRIV, and we've been at this at length, the case of
service being dependent on Location information CANNOT be implemented in
a single round trip AT ALL, because the NAS first needs to be informed
of the user's privacy policy -- in short, whether or not that NAS is
allowed to send the user's Location at all.

> > >   The above proposal should keep all of the capability 
> > exchange within 
> > > the current RADIUS data model, and won't require a new bit-array.
> 
> I don't see this.  You still need to define attributes for each
> capability.  For example,  you need to define an attribute for
> Location-Required  this is wasteful in two aspects:
> 1) It is wasteful on the attribute space (which is limited)
> 2) It is wasteful in the space required in the RADIUS messages.
> 3) And back to your IANA issue, IANA still needs to manage a potentially
> infinite number of attributes for this feature.

In my proposal, and that was the 'refinement' you were replying to,
there is no potentially infinite list of challenge cause attributes,
because that has other problems (the NAS ignoring attributes it does not
know about). See the mail you replied to.

Rather, there is a /single/ Challenge-Cause attribute with a potentially
'infinite' list of values. There are 4294967296 challenge causes
available, so I don't see the number space as a problem.

> So while it works -- I don't think this is a better apporach then what
> we have been proposing.

Alan's first attempt may not be, and it does not address mandatory
session limiting (can we please talk about that instead of including a
whole range of other issues by reference to the prepaid draft), but the
current proposal does solve GEOPRIV, in a generic way that also solves
other issues /that would already need challenges anyway/.

The best way to implement mandatory session limiting attributes is still
to be discussed, however, let's try to get agreement on the problem
statements first.

It would be a good start if you'd separate the two issues of GEOPRIV and
Prepaid. They have entirely different problem statements. I believe
Bernard suggested we get the problems clearly enumerated and defined
first, and then come up with precise, targeted solutions that are also
as generic as possible. A proposed solution may, may cover both
problems, but we're not nearly there yet.

Few seem to have joined you in blessing the original capabilities
advertising draft as a candidate for a solution that even reaches the
required level of precision and generality.

To do so is premature, and it would help if you didn't keep pounding on
it.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Wed, 19 Oct 2005 16:06:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary - refined proposal
Date: Wed, 19 Oct 2005 12:06:58 -0400
From: "Avi Lior" <[email-masked]>
To: "Emile van Bergen" <[email-masked]>, "Alan DeKok" <[email-masked]>
Cc: <[email-masked]>

Alan and Emile see below:=20

> -----Original Message-----
> From: Emile van Bergen [mailto:[email-masked]]=20
> Sent: Wednesday, October 19, 2005 6:22 AM
> To: Alan DeKok
> Cc: Avi Lior; [email-masked]
> Subject: Re: Capabilities: Summary - refined proposal
>=20
> Alan,
>=20
> On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote:
>=20
> >   The capability being advertised, then, isn't location, but "can=20
> > handled Access-Challenge responses to PAP, CHAP, MSCHAP requests".
> >=20
> >   Once an implementation supports that, any server can=20
> challenge the=20
> > client with "hints", as described above.  A possible workflow is:
> >=20
> >   C -> S: Access-Request
> > 		User-Name =3D foo
> > 		User-Password =3D bar
> > 		Capability =3D yes
> >   S -> C: Access-Challenge
> > 		Require-Location =3D yes   =20
> > 		State =3D abcd
> >   C -> S: Access-Request
> > 		User-Name =3D foo
> > 		User-Password =3D bar
> > 		Capability =3D yes
> > 		location =3D "moe's tavern"
> > 		State =3D abcd
> >=20
> >   That proposal removes all of the functionality advertisement from=20
> > the capability exchange.  I think the potentially infinite=20
> list of "I=20
> > support functionality foo" is the source of the disagreement.

First of all you are advertizing but you are advertizing one capability.

But the affect of doing what you suggest is to force a challenge
everytime.  This is problematic since we try to reduce the number of
messages exchanged. =20

Consider the prepaid case.  Here the AAA-Server will need to send
attributes to the NAS to control the session.  Simply sending the
prepaid attributes to the NAS could result in giving the user free
service.  Since a NAS that does not understand the attributes will
simply ignore them.

In the scheme proposed above the AAA-Server will always have to
challenge for the NAS to see if it supports Prepaid.  So for the
millions of prepaid users that attempt to login we will have to send
millions of extra messages.

In our proposal the NAS will simply indicate right up front whether it
supports prepaid or not.  Saving millions of messages a day.

I strongly encourage all of us to be mindful of sending extra messages
because in large deployements this makes a big difference.

> >   In most situations, one party or other other will care=20
> about 10% of=20
> > the advertised capabilities, meaning the other 90% are irrelevant.
> > And having a potentially infinite list is problematic for=20
> > implementations to manage, to say nothing of IANA.

Yes but your proposal requires extra messaging.  And I think you are
being over dramatic about an infitie list of implementations to manage.

> >   The above proposal should keep all of the capability=20
> exchange within=20
> > the current RADIUS data model, and won't require a new bit-array.

I don't see this.  You still need to define attributes for each
capability.  For example,  you need to define an attribute for
Location-Required  this is wasteful in two aspects:
1) It is wasteful on the attribute space (which is limited)
2) It is wasteful in the space required in the RADIUS messages.
3) And back to your IANA issue, IANA still needs to manage a potentially
infinite number of attributes for this feature.

> >   Comments?  Does this match your needs?

So while it works -- I don't think this is a better apporach then what
we have been proposing.

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

Delivery-date: Wed, 19 Oct 2005 10:21:52 +0000
Date: Wed, 19 Oct 2005 12:21:31 +0200
From: Emile van Bergen <[email-masked]>
To: Alan DeKok <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Capabilities: Summary - refined proposal
Mail-Followup-To: Alan DeKok <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]

Alan,

On Wed, Oct 12, 2005 at 07:50:36PM -0400, Alan DeKok wrote:

>   The capability being advertised, then, isn't location, but "can
> handled Access-Challenge responses to PAP, CHAP, MSCHAP requests".
> 
>   Once an implementation supports that, any server can challenge the
> client with "hints", as described above.  A possible workflow is:
> 
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
>   S -> C: Access-Challenge
> 		Require-Location = yes    
> 		State = abcd
>   C -> S: Access-Request
> 		User-Name = foo
> 		User-Password = bar
> 		Capability = yes
> 		location = "moe's tavern"
> 		State = abcd
> 
>   That proposal removes all of the functionality advertisement from
> the capability exchange.  I think the potentially infinite list of "I
> support functionality foo" is the source of the disagreement.
> 
>   In most situations, one party or other other will care about 10% of
> the advertised capabilities, meaning the other 90% are irrelevant.
> And having a potentially infinite list is problematic for
> implementations to manage, to say nothing of IANA.
> 
>   The above proposal should keep all of the capability exchange within
> the current RADIUS data model, and won't require a new bit-array.
> 
>   Comments?  Does this match your needs?

I think this is an excellent idea, but a problem arises where a NAS does
support the 'Capability = Yes' (or more accurately, 'Challenge-Supported
= Yes') scheme, but does not understand the particular cause for the
challenge, which may be given in the challenge by an attribute or value
it does not know about. 

If you create a generic mechanism for NASes to indicate their support
for challenges for more information, then at some point NASes will exist
that support the generic mechanism, but not the particular challenge
cause. In your example, they will send Capability = Yes, but will not
understand the Require-Location attribute and therefore ignore it.

So, the question is what a NAS should do when it is challenged for
something it does not know about or something it does not have for that
particular session. It should definitely not reject, otherwise we're
back to square one.

My suggestion is that instead of a scheme-dependent and potentially
unknown response attribute, a single response attribute must be used to
describe the challenge cause, one that MUST be supported if
Challenge-Supported = Yes is sent.

The semantics for Challenge-Cause would be that *if and only if* a NAS
sent Challenge-Supported, *and* it sees Challenge-Cause *and* it does
not understand its value (eg. Location-Required), the NAS MUST repeat
its initial access request (adding the received State and updating
Authenticator and Id as per RFC 2865, of course), *without prompting the
user*.

This is quite specific, but it only has to be defined in a single
document describing NAS inquiries using these two attributes, and does
not require any retroactively updated behaviour to operate smoothly in a
heterogenous environment.

Note that a NAS that sends Challenge-Supported = Yes cannot always
resend its access request if it does not understand from the response
packet why it was challenged, because it needs to distinguish a
challenge for information it does not have (resend as-is) from a classic
one time password challenge (prompt user first). Hence Challenge-Cause.
It also helps debugging by server administrators, I guess.

When seeing State in an authentication request that still lacks the
wanted information, the server can conclude that it won't get anymore
information than it just got, and that it will have to make its decision
based on what it has (modulo unfinished EAP conversations, of course).

The server will only have to be careful to avoid sending a challenge for
the missing information if the presence of State indicates that the
challenge has already been done, to prevent endless ping-pongs.

However, I think that with this addition, your idea completely solves
the 'unknown NAS may withhold needed information' issue as present in
GEOPRIV, and also paves an excellent way for future authentication or
authorisation schemes that require tentative challenges.

Cheers,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Wed, 19 Oct 2005 08:37:45 +0000
Date: Wed, 19 Oct 2005 10:37:11 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>, [email-masked]
Subject: Re: Capabilities: Moving forward
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Sorry for following up to myself, but I made a few typo's that may cause
confusion.

On Wed, Oct 19, 2005 at 10:18:45AM +0200, Emile van Bergen wrote:

>    The rationale for a capabilities advertising capability in this
>    scenario is as follows:
> 
>    - A server needs to know in advance how the NAS will respond to a

insert 'challenge'

>      for the withheld information, because a NAS may not support
>      challenges, causing premature rejection of the user per RFC 2685
>      section 4.4 ([44]), or it may misunderstand the reason for the
>      challenge, causing other unintended behaviour.
> 
>      To expand on this, according to [44], a NAS that supports PAP but
>      that is not willing or able to forward the challenge in the of

replace 'the of' with 'the form of a'

>      Reply-Message to the user, MUST treat the Access-Challenge as an
>      Access-Reject. A NAS that supports classic challenges for PAP
>      requests to implement one time passwords, would effectively forward
>      the challenge to the user, which is not intended here.

[skipping]

> 2. The second problem: some server policies require an Access-Accept

insert 'to be'

>    conditional on the NAS' support for certain session limiting
>    attributes, and on the proxy chain's transparency for them.

Thanks,

Emile.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Wed, 19 Oct 2005 08:19:27 +0000
Date: Wed, 19 Oct 2005 10:18:45 +0200
From: Emile van Bergen <[email-masked]>
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: Capabilities: Moving forward
Mail-Followup-To: Bernard Aboba <[email-masked]>, [email-masked]

Bernard, others,

On Mon, Oct 17, 2005 at 09:14:15PM -0700, Bernard Aboba wrote:

> After dozens and dozens of messages, there is very little to show for the 
> discussion of Capabilities Solutions, so it's time to take a step backward 
> and focus for a while on The Problem.  Let's all take a breather from 
> solution discussions for a while.
> 
> I'd note that we've taken this approach before in RADEXT WG, with 
> encouraging results.  Discussion on the CUI document seemed hopelessly 
> wedged until we were able to focus on the problem statement, which turned 
> out to be relatively straight forward.
> 
> A good problem statement is not just the union of all possible needs;  
> shopping lists make poor design documents.   Rather, a good problem 
> statement seeks to get at the one or two core issues, which, if addressed, 
> will enable solution of mutiple important problems.
> 
> As a result, the goal in coming up with a problem statement is not to 
> enumerate every possible corner condition and scenario, regardless of 
> relevance;  doing so will merely drive the development of as complex and 
> unwieldly a solution as possible.
> 
> Rather, the hallmark of a good problem statement is brevity, leading to 
> solutions which do what is necessary and little more.

This is an excellent idea, and I'd be happy to provide a kickoff. 

>From the earlier exchanges here, I see two non-imaginary problems for
which a form of capabilities advertising has been proposed. 

1. A NAS may withhold information required for proper authorization from
   its access requests, because it is only allowed to provide that
   information after some indication from the server.

   (Case in point: GEOPRIV, where a NAS is only allowed to provide
   Location information if the RADIUS server indicates that the user
   allows that information to be transmitted; at all, or specifically
   from the specific NAS, RADIUS client or combination thereof).

   The problem is that a server that intends to make its response
   dependent on the initially withheld information cannot
   unconditionally challenge the NAS for it.

   (Note that this scenario only applies if the server's response to the
   Access-Request packet is in any way dependent on the information
   that's initially withheld. If only the sending of the information in
   accounting requests is to be controlled, the indication to allow
   sending it can simply be put in the Access-Accept).

   The rationale for a capabilities advertising capability in this
   scenario is as follows:

   - A server needs to know in advance how the NAS will respond to a
     for the withheld information, because a NAS may not support
     challenges, causing premature rejection of the user per RFC 2685
     section 4.4 ([44]), or it may misunderstand the reason for the
     challenge, causing other unintended behaviour.

     To expand on this, according to [44], a NAS that supports PAP but
     that is not willing or able to forward the challenge in the of
     Reply-Message to the user, MUST treat the Access-Challenge as an
     Access-Reject. A NAS that supports classic challenges for PAP
     requests to implement one time passwords, would effectively forward
     the challenge to the user, which is not intended here.

   The required semantics for a capability advertisement capability in
   this scenario is that a NAS indicates:

     a. that it supports a challenge for withheld information, using
        a mutually understood mechanism for the server to identify the
	wanted information (eg. GEOPRIV information)

     b. the list of withheld information elements (eg. GEOPRIV Location
	attributes) -- it makes no sense to create this capability for
	one feature alone. (But on the other hand, I cannot think of any
	other case that desires that the NAS withholds available
	information from its initial access request).

2. The second problem: some server policies require an Access-Accept
   conditional on the NAS' support for certain session limiting
   attributes, and on the proxy chain's transparency for them.

   If the NAS and/or proxy chain are in an administrative domain that's
   different from the home AAA's, the home AAA has no way of knowing
   whether the NAS will implement a given session limit. 
   
   This is a real world problem that I've had to deal with (if you're
   curious: the limited EUNet self-subscription accounts on Nokia 9110
   communicators that would allow access through a large number of 3rd
   party dialup POPs, but only to access one particular web server. Ah,
   those were the days).

   Current examples of such session limiting attributes are packet
   filtering (Filter-Id and the new ones), bandwidth control (TBD), and
   volume capping attributes (currently vendor specific).

   An somewhat extensive analysis of this case has been posted earlier.

   The core issue here is that a response attribute filtering proxy
   must modify the NAS' advertisement in order for the advertisement to
   be correct when it is received by the home server.

   If advertising is be done using the well understood hints mechanism,
   response attribute filtering proxies are be required to reflect that
   in their request attribute filtering as well.

   The problem with that is that some attributes that a proxy may wish
   to filter from responses, cannot be filtered from Access-Requests.
   The most prominent case is User-Name, which may be present in
   responses to ask the NAS to change the User-Name to be used in
   accounting requests for the session. Many NASes support this, and
   some roaming contracts such as WISPr even require it. CUI or better
   use of Class may obsolete that practice, but both contracts with
   User-Name overwriting and NASes without CUI still exist.

   One point to add is that in the case of a server requiring certain
   Filter-Ids with certain names to be present, both the namespace
   (defining a name to semantics mapping) and the list of names will
   have to be advertised, in order for a NAS advertising its support for
   Filter-Id to be of any use.

   Modern server defined packet filters may be less problematic in this
   respect, but the advertising of values in addition to attributes may
   be required for other cases as well. A proposed mechanism should have
   provisions for that where that's required. It does not have to be
   complex, the hints mechanism eg. already allows a list of values to
   be sent by virtue of it using standard response A/V pairs in access
   requests.

Of course, a well mapped migration path is crucial for capabilities
advertising to offer any help in solving either of these problems, and
some of the proposals seem to assume a magic big bang update.

I hope that was brief enough. It would be great if followup posts would
tell me whether I've missed a real problem or whether I'm stating either
of the two incorrectly.

Best regards,

Emile van Bergen.

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Tue, 18 Oct 2005 20:09:00 +0000
Content-class: urn:content-classes:message
Subject: RE: Call for RADEXT submissions and agenda items for IETF-64
Date: Tue, 18 Oct 2005 16:08:39 -0400
From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi David,

The following draft (an upcoming V02 is to be uploaded in a few days) is
on its way to become a working group item in MIPv4 WG.=20

http://www.ietf.org/internet-drafts/draft-nakhjiri-radius-mip4-01.txt

I think early reviews by RADEXT will help us create a better spec even
before it comes to RADEXT for formal review. It would be nice to have
3-5 minutes to bring this to RADEXT attention at the next meeting.

Thanks,

Madjid Nakhjiri

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Nelson, David
Sent: Tuesday, October 18, 2005 12:12 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: Call for RADEXT submissions and agenda items for IETF-64

This is the second call for RADEXT WG agenda items.  WG agendas are
being posted now, and MUST be posted by October 31.  To date, the chairs
have received three agenda slot requests.  Please don't wait until the
last minute.

> This is a general call for WG submissions and WG agenda items for the=20
> RADEXT session at IETF-64 in Vancouver.
>=20
> Please reply to the chairs if you would like to make a presentation to
the
> RADEXT WG, including the subject mater, Internet-Draft URL, and
requested
> time allocation.
>=20
> Note that for IETF-64 we have on-line WG agendas, updatable by the WG=20
> chairs, located on the IETF web site:
>
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
4

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

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

Delivery-date: Tue, 18 Oct 2005 19:36:21 +0000
Date: Tue, 18 Oct 2005 22:35:38 +0300
From: Miguel Garcia <[email-masked]>
To: "Nelson, David" <[email-masked]>
CC: [email-masked]
Subject: Re: draft-ietf-radext-digest-auth-06

As far as I know version -06 is not available yet. The latest available 
version is -05, where the issue is still present.

Once we have seen version -06 or a preliminary version I can comment.

/Miguel

Nelson, David wrote:
> Does this resolve RADEXT Issue 138?
> 
> 
>>The latest version of the draft does no longer contain a link between
>>sips/https and
>>RADIUS. However, the Security Considerations section names refusing
>>sips/https request as one non-normative option to avoid the security
>>level mismatch of sips/https and unencrypted RADIUS:
>>
>>"To prevent RADIUS from representing the weak link, a RADIUS
>>client receiving an HTTP-style request via TLS or IPsec could use an
>>equally secure connection to the RADIUS server.  There are several
>>ways to achieve this, for example:
>>   o  the RADIUS client may reject HTTP-style requests received over
> 
> TLS
> 
>>      or IPsec
>>   o  the RADIUS client require that traffic be sent and received over
>>      IPsec.
>>RADIUS over IPsec, if used, MUST conform to the requirements
>>described in [RFC3579] section 4.2."
> 
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

Delivery-date: Tue, 18 Oct 2005 18:37:44 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Moving forward
Date: Tue, 18 Oct 2005 14:38:24 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Here is the motivation statement for capabilities exchange with some
added text to provide further explanations.

   There is a need for a RADIUS server to discover capabilities of a NAS
   that has initiated a connection to it. =20

   The  RADIUS server may require that the NAS supports a particular
RADIUS application. =20

   For example, if the user being authenticated and authorized is a
prepaid
   user, then the  RADIUS needs to be assured that the NAS supports
   prepaid capabilities as defined in [I-D.lior-radius-prepaid-
   extensions]. =20

   This is critical to correct operation.  Because if the user is a
prepaid user, then the AAA server will reply back to the NAS with
authroization attributes that are designed to control the prepaid
session (see the prepaid work).  If the NAS does not support these
attributes the NAS will simply ignore the attributes.  This will result
with the prepaid user getting free service.

***
Whether or not a NAS supports a particular capability could impact if
the user is allowed on the network; or which attributes are delivered
and perhaps the value of those attributes;

We therefore need a mechansim for the NAS to indicate with Applications
it supports.
***  =20

Similarly, the  network may need to know whether or not the NAS supports
a particular RADIUS feature such as  Dymanic Authorization Extensions as
defined in [RFC3576]. =20

This is more from an efficiency point of view and may also be required
for correct operation.

Using 3576 as an example.  AAA server may wish to terminate a session.
If it knows that the NAS does not support 3576 it can use
Session-Timeout to have the NAS periodically re-authenticate and those
can control to some degree when it will terminate the session.  However,
if it knows that the NAS supports 3576 DM messages then the AAA server
knows it can count on the DM message to percisely disconnect the
session.

Not having this knowledge if the AAA assumed that it can use 3576 it
will issue a DM message and the NAS which does not support 3576 would
reply back with an ICMP message indicating that that port is not in use
(or something like that).  This is information is not useful since the
user session has already been allocated and we just found out that the
NAS does not support DM messages.

The same scenario could be used to illustrate why its important to know
that the NAS supports 3576 CoA messages.

***
Knowing the that a NAS supports a particular feature is very helpful.
It helps the AAA determine which features can be used to control the
session.

We therefore need a mechanism for the NAS to indicate which RADIUS
features it supports
***

In some cases, the NAS itself may also need to communicate that it
requires that the  RADIUS server deliver a particular capability.

For example, the *NAS* may require that the  server deliver the
Chargeable User Identity attribute as defined in [I-D.ietf-radext-
chargeable-user-id].   Here the NAS not only indicates that it can
support the CUI but requests that the CUI *MUST* be provided otherwise
it will reject the session.

***
Having a way for the NAS to specify that the Server needs to provide it
with some infomration is also useful.

We therefore need a scheme to have the NAS indicate to the Server that
it needs particular infomration.
***

Similarly, the RADIUS server may require that the NAS deliver certain
feature that the RADIUS server requires for the session. =20

For example, the  network may require that the NAS deliver location
information as defined by [I-D.ietf-geopriv-radius-lo] before it can
authenticate the session.

In this case it the NAS would advertize support for particular
application or information.  The NAS does not have to provide that
information in the Access-Request.  A RADIUS server can then subscribe
to the particular information by challenging the NAS to provide the
information.=20

The NAS should be able to request the information either during the
initial authentication -- since the availablity of the information may
determine whether or not the user is authenticated or whether or not the
user will be provided with a certain capabilities.
=20

****
We therefore need a scheme to have the NAS indicate what it supports and
a scheme for RADIUS Server to request that the NAS provide that
information.  This needs to be provided for during the initial
access-request or subsequently by using CoA etc...
****

In summary:

   o  The NAS to specify which capabilities it supports.
   o  The NAS to specify which capabilities that are required to be
      delivered by the RADIUS server.
   o  The RADIUS server to express the capabilities desired from the
      NAS.
   o  The RADIUS server to express the capabilities that the RADIUS
      server requires from the NAS.

NOTE:

   The End-to-End-Capability is different then the capability exchange
defined in Base Diameter [RFC3588].  The purpose of the Diameter based
capability exchange is
   support routing of Diameter messages.  Whereas, the functionality
   defined by here is designed to ensure whether we can send an
   attribute or command or expect a behavior relating to this specific
   user's session.

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, October 18, 2005 12:14 AM
> To: [email-masked]
> Subject: Capabilities: Moving forward
>=20
> >I do agree with Bernard that we first need to come to=20
> consensus on the=20
> >problem statement.  I think your summary, quoted above, is one=20
> >reasonable candidate.
>=20
> After dozens and dozens of messages, there is very little to=20
> show for the discussion of Capabilities Solutions, so it's=20
> time to take a step backward and focus for a while on The=20
> Problem.  Let's all take a breather from solution discussions=20
> for a while.
>=20
> I'd note that we've taken this approach before in RADEXT WG,=20
> with encouraging results.  Discussion on the CUI document=20
> seemed hopelessly wedged until we were able to focus on the=20
> problem statement, which turned out to be relatively straight forward.
>=20
> A good problem statement is not just the union of all=20
> possible needs; =20
> shopping lists make poor design documents.   Rather, a good problem=20
> statement seeks to get at the one or two core issues, which,=20
> if addressed, will enable solution of mutiple important problems.
>=20
> As a result, the goal in coming up with a problem statement=20
> is not to enumerate every possible corner condition and=20
> scenario, regardless of relevance;  doing so will merely=20
> drive the development of as complex and unwieldly a solution=20
> as possible.
>=20
> Rather, the hallmark of a good problem statement is brevity,=20
> leading to solutions which do what is necessary and little more.
>=20
>=20
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 18 Oct 2005 17:35:03 +0000
Content-Class: urn:content-classes:message
Subject: RE: Call for RADEXT submissions and agenda items for IETF-64
Date: Tue, 18 Oct 2005 13:34:49 -0400
From: "Chowdhury, Kuntal" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Dear Chairs,

I request for two slots the following drafts:

1. Proposed update to Framed-Compression attribute to support ROHC:

http://www.ietf.org/internet-drafts/draft-chowdhury-rohc-radius-attribut
es-00.txt

This is a short draft, so a 5 mins slot will suffice.

2. RADIUS MIP6 support:

The draft is not yet posted on the IETF I-D repository, but it was
submitted before the deadline (on 16th Oct).=20

http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-radius-00.txt

Here is the abstract:

   A Mobile IPv6 node requires a home agent address, a home address, and
   IPsec security association with its home agent before it can start
   utilizing Mobile IPv6 service.  RFC 3775 requires that some or all of
   these parameters are statically configured.  Ongoing work aims to
   make this information dynamically available to the mobile node.  An
   important aspect of the Mobile IPv6 bootstrapping solution is to
   support interworking with existing authentication, authorization and
   accounting infrastructure.  This document defines the new attributes
   to facilitate Mobile IPv6 bootstrapping via a RADIUS infrastructure.
   This information exchange may take place as part of the initial
   network access authentication procedure or as part of a separate
   protocol exchange between the mobile node, the home agent and the AAA
   infrastructure.
-----------------------------------------------------------------

A 10 mins slot is requested for this one.

Regards,
Kuntal

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Nelson, David
> Sent: Tuesday, October 18, 2005 12:12 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Call for RADEXT submissions and agenda items for IETF-64
>=20
> This is the second call for RADEXT WG agenda items.  WG agendas are
> being posted now, and MUST be posted by October 31.  To date, the
chairs
> have received three agenda slot requests.  Please don't wait until the
> last minute.
>=20
> > This is a general call for WG submissions and WG agenda items for
the
> > RADEXT session at IETF-64 in Vancouver.
> >
> > Please reply to the chairs if you would like to make a presentation
to
> the
> > RADEXT WG, including the subject mater, Internet-Draft URL, and
> requested
> > time allocation.
> >
> > Note that for IETF-64 we have on-line WG agendas, updatable by the
WG
> > chairs, located on the IETF web site:
> >
>
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
4
>=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/>

"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
[email-masked] -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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

Delivery-date: Tue, 18 Oct 2005 17:27:27 +0000
Content-class: urn:content-classes:message
Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document
Date: Tue, 18 Oct 2005 13:28:20 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>

Bernard,

Please don't forget the other use cases for the bandwidth attributes as
well.  As you correctly pointed out on the bandwidth teleconference call
recently these attributes are needed for features such as bandwidth on
demand. We deploy these capabilities today in the field and we would
like to see this simple bandwidth model standerdized.

The sense of frustration amongst us is that we keep getting instruction
from the WG to keep it simple and then to make it more complex. This has
been going on for the last year.

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Tuesday, October 18, 2005 12:03 AM
> To: [email-masked]
> Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document
>=20
> >[FA] It is not deployed because we just started seeing WMM/802.11e=20
> >(with admission control) capable APs coming to the market.
>=20
> With all due respect, that is *not* what the industry is telling us.
> Almost two years ago, the WFA standardized bandwidth=20
> attributes, but we were unable to locate any vendor who had=20
> implemented those attributes, nor any customer who had deployed them.
>=20
> The reason why the attributes have not been deployed is *not*=20
> merely because of lack of hardware support, though that is=20
> certainly part of the issue.  802.11 vendors who already=20
> support 802.11 QoS schemes also have not implemented the=20
> specification, and do not plan to do so in the future,=20
> because the current specification does not provide=20
> functionality equivalent to what is already supported on their APs.
>=20
> Similarly, switch vendors who have support IEEE 802.1Q also=20
> have not implemented the specification -- and have indicated=20
> that they also do not plan to implement it in the future.
>=20
> The "good news" is that there does appear to be significant=20
> interest in the general concept of bandwidth limitation, and=20
> were the document to be modified to address the issues=20
> developed in the review, it seems likely that vendor interest=20
> would increase substantially.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Tue, 18 Oct 2005 17:22:08 +0000
Content-class: urn:content-classes:message
Subject: Issues 134 and 135
Date: Tue, 18 Oct 2005 13:21:45 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

I have just today submitted -01 revisions of the I-Ds for IPv6
compatible RADIUS MIBs: draft-ietf-radext-rfc26nnbis-01.txt, where nn =
=3D
{18, 19, 20, 21}.  The -01 revision addresses the issues described in
RADEXT Issues 134 and 135.  I will post another notice when the drafts
are in the I-D repository.  If anyone wishes "advance" copies for
review, please contact me directly.

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

Delivery-date: Tue, 18 Oct 2005 17:16:32 +0000
Content-class: urn:content-classes:message
Subject: RE: Call for RADEXT submissions and agenda items for IETF-64
Date: Tue, 18 Oct 2005 13:12:18 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

This is the second call for RADEXT WG agenda items.  WG agendas are
being posted now, and MUST be posted by October 31.  To date, the chairs
have received three agenda slot requests.  Please don't wait until the
last minute.

> This is a general call for WG submissions and WG agenda items for the
> RADEXT session at IETF-64 in Vancouver.
>=20
> Please reply to the chairs if you would like to make a presentation to
the
> RADEXT WG, including the subject mater, Internet-Draft URL, and
requested
> time allocation.
>=20
> Note that for IETF-64 we have on-line WG agendas, updatable by the WG
> chairs, located on the IETF web site:
>
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
4

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

Delivery-date: Tue, 18 Oct 2005 14:58:03 +0000
Content-class: urn:content-classes:message
Subject: RE: draft-ietf-radext-digest-auth-06
Date: Tue, 18 Oct 2005 10:56:34 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Does this resolve RADEXT Issue 138?

> The latest version of the draft does no longer contain a link between
> sips/https and
> RADIUS. However, the Security Considerations section names refusing
> sips/https request as one non-normative option to avoid the security
> level mismatch of sips/https and unencrypted RADIUS:
>=20
> "To prevent RADIUS from representing the weak link, a RADIUS
> client receiving an HTTP-style request via TLS or IPsec could use an
> equally secure connection to the RADIUS server.  There are several
> ways to achieve this, for example:
>    o  the RADIUS client may reject HTTP-style requests received over
TLS
>       or IPsec
>    o  the RADIUS client require that traffic be sent and received over
>       IPsec.
> RADIUS over IPsec, if used, MUST conform to the requirements
> described in [RFC3579] section 4.2."

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

Delivery-date: Tue, 18 Oct 2005 04:14:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Capabilities: Moving forward
Date: Mon, 17 Oct 2005 21:14:15 -0700

>I do agree with Bernard that we first need to come to consensus on
>the problem statement.  I think your summary, quoted above, is one
>reasonable candidate.

After dozens and dozens of messages, there is very little to show for the 
discussion of Capabilities Solutions, so it's time to take a step backward 
and focus for a while on The Problem.  Let's all take a breather from 
solution discussions for a while.

I'd note that we've taken this approach before in RADEXT WG, with 
encouraging results.  Discussion on the CUI document seemed hopelessly 
wedged until we were able to focus on the problem statement, which turned 
out to be relatively straight forward.

A good problem statement is not just the union of all possible needs;  
shopping lists make poor design documents.   Rather, a good problem 
statement seeks to get at the one or two core issues, which, if addressed, 
will enable solution of mutiple important problems.

As a result, the goal in coming up with a problem statement is not to 
enumerate every possible corner condition and scenario, regardless of 
relevance;  doing so will merely drive the development of as complex and 
unwieldly a solution as possible.

Rather, the hallmark of a good problem statement is brevity, leading to 
solutions which do what is necessary and little more.

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

Delivery-date: Tue, 18 Oct 2005 04:04:00 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document
Date: Mon, 17 Oct 2005 21:03:29 -0700

>[FA] It is not deployed because we just started seeing WMM/802.11e (with
>admission control) capable APs coming to the market.

With all due respect, that is *not* what the industry is telling us.
Almost two years ago, the WFA standardized bandwidth attributes, but we
were unable to locate any vendor who had implemented those attributes, nor
any customer who had deployed them.

The reason why the attributes have not been deployed is *not* merely  
because of lack of hardware support, though that is certainly part of the 
issue.  802.11 vendors who already support 802.11 QoS schemes also have not 
implemented the specification, and do not plan to do
so in the future, because the current specification does not provide 
functionality equivalent to what is already supported on their APs.

Similarly, switch vendors who have support IEEE 802.1Q also have not 
implemented the specification -- and have indicated that they also do not 
plan to implement it in the future.

The "good news" is that there does appear to be significant interest in the 
general concept of bandwidth limitation, and were the document to be 
modified to address the issues developed in the review, it seems likely that 
vendor interest would increase substantially.

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

Delivery-date: Tue, 18 Oct 2005 00:16:07 +0000
Content-class: urn:content-classes:message
Subject: RE: Conclusion of Pre-Work Item Review on Bandwidth Document
Date: Mon, 17 Oct 2005 17:11:31 -0700
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Thanks!  Please see my comments inline.
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]]
> On Behalf Of Bernard Aboba
> Sent: Saturday, October 08, 2005 8:42 PM
> To: [email-masked]
> Subject: Conclusion of Pre-Work Item Review on Bandwidth Document
>=20
> Just to clarify the status of the Bandwidth Document=20
> deployment review.
>=20
> The reponses appear to indicate there is interest in=20
> standardization of
> Bandwidth-related attributes, particularly within the switch community
> (IEEE 802.1).
>=20
> However, the deployment review also concluded that this=20
> community would
> not deploy the document as it currently exists.
>=20
> Also, review from the IEEE 802.11 community indicates that legacy APs
> are not capable of carrying out Bandwidth Limitation as=20
> specified in the
> document, due to hardware limitations.  This explains why the existing
> WFA-defined VSAs have not been deployed.
>=20

[FA] It is not deployed because we just started seeing WMM/802.11e (with
admission control) capable APs coming to the market.  IMO, these
attributes make sense only for WMM/802.11e (with admission control)
capable APs deployed in public hotspots to provide QoS w/admission for
real-time services  -- e.g., VoIP.  For example, When the QoS capable AP
receives a TSPEC request from a client, the AP can decide whether to
accept or reject the TSPEC based the bandwidth attributes or Profile ID
received in the Access-Accept. =20

> However, newer APs that are capable of carrying out Bandwidth=20
> Limitation
> have adopted more sophisticated VSAs, and as a result, these newer APs
> would also not be likely to adopt the approach described in=20
> the existing
> document.

[FA] Can you name these new AP vendors supporting BW VSAs?  Using VSAs
will not promote interoperability -- I thought the interoperability was
one of the key goals that we wanted to accomplish in this WG - no?

>=20
> Based on the responses, the authors of the document are urged to
> incorporate the comments from the switch and 802.11 AP communities in
> order to develop a document that is likely to be deployed and
> implemented.
>=20
> Once that revision has been completed, and deployment=20
> feedback indicates
> that the revision addresses industry/customer needs, the=20
> RADEXT WG will
> once again consider the document for adoption as a RADEXT WG=20
> work item.
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 17 Oct 2005 15:25:39 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities complexity summary
Date: Mon, 17 Oct 2005 11:26:43 -0400
From: "Avi Lior" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Bernard,
=20
> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, October 14, 2005 10:56 AM
> To: [email-masked]
> Subject: Re: Capabilities complexity summary
>=20
> >I think that Avi's point is that the desired result is *not*=20
> >Access-Reject in the particular scenario he describes: a roaming=20
> >consortium which contains none legacy, non-GEOPRIV NASes.  The home=20
> >provider would *like* to use GEOPRIV information to authorize its=20
> >roaming customers, but doesn't want to risk annoying the customer by=20
> >denying any form of access when they happen to be roaming via a=20
> >non-home ISP that has legacy NASes.
>=20
> It would appear to me that there are multiple ways to address=20
> this scenario without additional complexity.  At least four=20
> potential solutions come to mind.
>=20
> As has been pointed out, this problem would not exist if=20
> location information were made available in the=20
> Access-Request.  It's not clear to me that the granularity of=20
> information required to make authorization decisions=20
> represents a legitimate privacy concern.
>=20
> It's worth pointing out that RFC 2865 requires that an=20
> Access-Request contain at least one NAS identificaiton=20
> attribute: NAS-Identifier, NAS-IP-Address, or=20
> NAS-IPv6-Address. Therefore some location-relevant=20
> information is always present in an Access-Request.   It is=20
> fairly routine=20
> for providers to include location information in the=20
> NAS-Identifier attribute, or to include a PTR RR in the DNS=20
> that maps the NAS-IP-Address to a city, state and country. =20
> For example, "4.68.127.109" has a PTR RR for=20
> "so-3-2-0.gar1.Seattle1.Level3.net".
>=20
> Given this, it would seem that course-grained location=20
> information (e.g.=20
> information at the state/city level) could be included in the=20
> Access-Request by default without representing an additional=20
> privacy risk.

You would think so but this has been discussed in Geopriv at length and
they felt that knowning the IP address of the NAS does not compromize
the user's location.

Note I am crossposting to Geopriv so that they can respond to your
assertion.

=20
> There are also ways to address the issue that do not require=20
> sending location in the initial Access-Request.  Since=20
> location is not required for initial authorization, an=20
> Access-Accept is sent requesting location.  This=20
> allows the user to access the  network.   Location information, if=20
> available, is then sent within the Accounting-Request and may=20
> be stored for the duration of the session.

But what if an Authorization to use the network requires location
information?
=20
> Access to location services can then be made available by one=20
> of the following mechanisms:
>=20
> 1. An application-specific request can then be sent for the=20
> location-aware services, which will be granted by a RADIUS=20
> server that has access to the location information sent in=20
> previous Accounting-Requests.
=20
> 2. An RFC 3576 DAC can upgrade the user authorizations once=20
> location information is available.

But what if I didn't want to authorize the user if I don't have location
information?
Or what if the NAS does not support 3576?
=20
> 3. The original Access-Request can contain a Session-Timeout=20
> attribute, allowing re-authentication/re-authorization to=20
> occur once the location information has been made available.

All of the above solution ignore the fact that we may need location
information during authorization.  In all the cases the user gets
service while location is being sorted out. As well each method is
complex requiring additional message exchanges and or schemes.

I don't understand why you would suggest these schemes over the
simplicity of  Access-Request with an advertizement and Challenge
mechanism.

NAS
---   Access-Request with indication to support location  Server
 +---------------------------------------------------------->|
 |                                                           |
 |    Acess-Challenge with request of location               |
 |<----------------------------------------------------------|
 |    Access-Request with Location Information               |
 |---------------------------------------------------------->|
 |    Access-Accept  or Access-Reject                        |
 |<----------------------------------------------------------|

Seems to me that the above callflow is pretty darn straightforward vs.
the complexities of your proposals.

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

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

Delivery-date: Mon, 17 Oct 2005 15:24:18 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Mon, 17 Oct 2005 11:22:58 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> Therefore, the conclusion that Farid and I came (and others) came to
was
> not to express capabilities as support for individual attributes but
> rather as "features" and "modes" (I don't know how to express it).

Then perhaps what is really needed is a single new attribute called
Supported-Application-Environment which is an enumerated type, with an
appropriate IANA registry.  If SDOs, consortia, vendors and system
operators can agree on a finite set of business scenarios or application
environments (i.e. bundles of attributes, commands, and related values
and feature support) they can name them.  For example
"3GPP2-Roaming-Feature-Set-One".  Multiple instances of this attribute
would be allowed in Access-request messages.

The argument against this, of course, is that every consortia, vendor
and system operator will want to create custom bundles of RADIUS
behavior for their one "unique" environments and needs.  I would like to
suggest that the set of truly unique business scenarios is finite and
fairly limited in number.  Following the KISS philosophy, and resisting
the urge to tweak and customize, I assert that this could be a viable
solution.

OTHO, I do agree with Bernard that we first need to come to consensus on
the problem statement.  I think your summary, quoted above, is one
reasonable candidate.

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

Delivery-date: Mon, 17 Oct 2005 15:07:33 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Mon, 17 Oct 2005 11:08:20 -0400
From: "Avi Lior" <[email-masked]>
To: "Alan DeKok" <[email-masked]>, "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Alan,

I don't think that Capabilities are always about support for a given
attribute or attribute(s).

Sometimes capabilities are about support for a feature like Disconnect
Message or the ability to support change of authorization message.  Note
someone will surely remind me that a NAS that does not support DM or COA
will respond negatively.

But that "Negative" response comes after the fact --- after trying the
command and way after authorizing the session. =20

In some cases we would like to know if the NAS supports these
capabilities *during* authentication/authorization time.  3GPP2 for
example have an VSA that communicates the NASes capability in an
Access-Request.

In other cases, it is not the support of the specific attribute but
rather what type of values the attribute can take on.  So its how the
attribute is to be interpreted or assigned values.

Therefore, the conclusion that Farid and I came (and others) came to was
not to express capabilities as support for individual attributes but
rather as "features" and "modes" (I don't know how to express it).

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Alan DeKok
> Sent: Thursday, October 13, 2005 9:19 PM
> To: Nelson, David
> Cc: [email-masked]
> Subject: Re: Capabilities: Summary
>=20
> "Nelson, David" <[email-masked]> wrote:
> > This could be addressed by encapsulating the existing attributes in=20
> > the extended attribute format.
>=20
>   Ugh.
>=20
> > >  Or, *requested* information like location?
> >=20
> > I wonder how many attributes will end up falling into this category?
>=20
>   Not many.  See "hints" currently sent from NAS to server.
>=20
> > I am operating under the impression that the Access-Challenge=20
> > mechanism was deemed to be a sufficient solution for the desired=20
> > attributes use cases.  Is that not so?
>=20
>   Servers may offer limited services to clients that don't=20
> support Access-Challenge.  Requiring Access-Challenge means=20
> offering *no* service to some clients, because they will=20
> treat it like Access-Reject.
>=20
> > Well, yes, customers worry about functionality.  OTOH, if=20
> we were to=20
> > communicate functionality, it would require a new IANA registry and=20
> > corresponding RFCs for each code point to define *exactly* what the=20
> > functionality was.  The nice thing about attributes is that that (we
> > expect) that the associated functionality is already well defined.
>=20
>   Yes.  Which is why I proposed the "list of attributes"=20
> capability, which supports both client-server, and=20
> server-client exchanges, and the "mandatory versus requested"=20
> capability.
>=20
> > > The mandatory bit in Diameter is nice, but I don't see it=20
> as being=20
> > > incredibly useful in deployments.
> >=20
> > Given that Diameter interoperability is a charter requirement, what=20
> > does this say about the requirements for such a feature in RADIUS?
>=20
>   If we're extending RADIUS to have features diameter=20
> doesn't, then that would be a problem.
>=20
>   I'm not sure how Avi's deployment scenarios would work in Diameter.
>=20
>   Alan DeKok.
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 17 Oct 2005 10:31:18 +0000
Date: Mon, 17 Oct 2005 12:30:56 +0200
From: Emile van Bergen <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: draft-ietf-radext-digest-auth-06
Mail-Followup-To: "[email-masked]" <[email-masked]>, [email-masked], [email-masked], [email-masked]

Hi,

On Mon, Oct 17, 2005 at 12:07:09PM +0200, [email-masked] wrote:

> The latest version of the draft does no longer contain a link between
> sips/https and
> RADIUS. However, the Security Considerations section names refusing
> sips/https request as one non-normative option to avoid the security
> level mismatch of sips/https and unencrypted RADIUS:
> 
> "To prevent RADIUS from representing the weak link, a RADIUS
> client receiving an HTTP-style request via TLS or IPsec could use an
> equally secure connection to the RADIUS server.  There are several
> ways to achieve this, for example:
>    o  the RADIUS client may reject HTTP-style requests received over TLS
>       or IPsec
>    o  the RADIUS client require that traffic be sent and received over
>       IPsec.
> RADIUS over IPsec, if used, MUST conform to the requirements
> described in [RFC3579] section 4.2."

s/weak/weakest, I guess?

and I suggest another option:

  o the RADIUS traffic only passes networks secured by other means,
    eg. networks that are separated from the internet on the IP layer or
    below.

Cheers,

Emile

-- 
E-Advies - Emile van Bergen           [email-masked]      
tel. +31 (0)78 6136282           http://www.e-advies.nl    

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

Delivery-date: Mon, 17 Oct 2005 10:07:43 +0000
Date: Mon, 17 Oct 2005 12:07:09 +0200
To: [email-masked]
Subject: draft-ietf-radext-digest-auth-06
Cc: [email-masked], [email-masked]
From: "[email-masked]" <[email-masked]>

The latest version of the draft does no longer contain a link between
sips/https and
RADIUS. However, the Security Considerations section names refusing
sips/https request as one non-normative option to avoid the security
level mismatch of sips/https and unencrypted RADIUS:

"To prevent RADIUS from representing the weak link, a RADIUS
client receiving an HTTP-style request via TLS or IPsec could use an
equally secure connection to the RADIUS server.  There are several
ways to achieve this, for example:
   o  the RADIUS client may reject HTTP-style requests received over TLS
      or IPsec
   o  the RADIUS client require that traffic be sent and received over
      IPsec.
RADIUS over IPsec, if used, MUST conform to the requirements
described in [RFC3579] section 4.2."

Wolfgang

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

Delivery-date: Fri, 14 Oct 2005 14:55:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Re: Capabilities complexity summary
Date: Fri, 14 Oct 2005 07:55:30 -0700

>I think that Avi's point is that the desired result is *not*
>Access-Reject in the particular scenario he describes: a roaming
>consortium which contains none legacy, non-GEOPRIV NASes.  The home
>provider would *like* to use GEOPRIV information to authorize its
>roaming customers, but doesn't want to risk annoying the customer by
>denying any form of access when they happen to be roaming via a non-home
>ISP that has legacy NASes.

It would appear to me that there are multiple ways to address this scenario 
without additional complexity.  At least four potential solutions come to 
mind.

As has been pointed out, this problem would not exist if location 
information were made available in the Access-Request.  It's not clear to me 
that the granularity of information required to make authorization decisions 
represents a legitimate privacy concern.

It's worth pointing out that RFC 2865 requires that an Access-Request 
contain at least one NAS identificaiton attribute: NAS-Identifier, 
NAS-IP-Address, or NAS-IPv6-Address. Therefore some location-relevant 
information is always present in an Access-Request.   It is fairly routine 
for providers to include location information in the NAS-Identifier 
attribute, or to include a PTR RR in the DNS that maps the NAS-IP-Address to 
a city, state and country.  For example, "4.68.127.109" has a PTR RR for 
"so-3-2-0.gar1.Seattle1.Level3.net".

Given this, it would seem that course-grained location information (e.g. 
information at the state/city level) could be included in the Access-Request 
by default without representing an additional privacy risk.

There are also ways to address the issue that do not require sending 
location in the initial Access-Request.  Since location is not required for 
initial authorization, an Access-Accept is sent requesting location.  This 
allows the user to access the  network.   Location information, if 
available, is then sent within the Accounting-Request and may be stored for 
the duration of the session.

Access to location services can then be made available by one of the 
following mechanisms:

1. An application-specific request can then be sent for the location-aware 
services, which will be granted by a RADIUS server that has access to the 
location information sent in previous Accounting-Requests.

2. An RFC 3576 DAC can upgrade the user authorizations once location 
information is available.

3. The original Access-Request can contain a Session-Timeout attribute, 
allowing re-authentication/re-authorization to occur once the location 
information has been made available.

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

Delivery-date: Fri, 14 Oct 2005 07:27:32 +0000
Date: Fri, 14 Oct 2005 10:27:06 +0300
From: Miguel Garcia <[email-masked]>
To: "[email-masked]" <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Issue 138

Hi Wolfgang.

I think your proposed solution does not move in the direction where 
Bernard and me have been indicating: "the security of the RADIUS 
exchange is a somewhat orthogonal issue from the security of the 
HTTP/SIP Digest exchange."

There are connections betweeen the secure URI (https or sips) and the 
presence/lack of security in the RADIUS interface. We indicated that 
ther is no such link.

So, in my opinion, the issue is still open.

/Miguel

[email-masked] wrote:

> Proposed text in section "RADIUS Client Behavior":
>    "If all of the following conditions are true, the RADIUS client MUST
>    act as if it had sent an Access-Request and the RADIUS server had
>    rejected the credentials with an Access-Reject packet:
>    o  the scheme in the digest-uri directive indicates a secure HTTP-
>       style connection (e.g. sip or https).
>    o  the packets between RADIUS client and RADIUS server are not
>       protected with IPsec.
>    Under those conditions, a typical implementation would reject the
>    HTTP-style request."
> 
> replaces:
>    "If the packets between RADIUS client and RADIUS server are not
>    protected with IPsec, the RADIUS client MUST NOT accept secured
>    connections (like https or sips) from its HTTP-style clients, so that
>    HTTP-style clients are not provided with a false sense of security."
> 
> The Security Consideration section gives some additional explanations.
> The section contains a part:
>   "There are two ways to achieve this:
>    o  the RADIUS client may reject HTTP-style requests received over TLS
>       or IPsec
>    o  the RADIUS client require that traffic be sent and received over
>       IPsec.
>    RADIUS over IPsec, if used, MUST conform to the requirements
>    described in [RFC3579] section 4.2.
> 
> I think it's weak enough with respect to the "don't mandate SIP / HTTP
> behaviour" requirement.
> 
> 
> Wolfgang

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland

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

Delivery-date: Fri, 14 Oct 2005 06:43:43 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Outcome of RADEXT WG  Consensus call on draft-lior-radext-end-to-end-caps-01.txt
Date: Thu, 13 Oct 2005 23:43:21 -0700

This is a summary of the RADEXT WG consensus call with respect to adoption 
of draft-lior-radext-end-to-end-caps-01.txt as a RADEXT WG work item.

After analyzing the discussion on the RADEXT WG mailing list starting in 
January 2005 and going forward to the present time,  it appears that there 
is NO CONSENSUS to adopt this document as a WG work item within the RADEXT 
WG.

The mailing list discussion evidences both lack of consensus with respect to 
the problem statement, as well as the proposed solution to the problem.

Since it is unlikely for consensus to be reached with respect to a solution 
without first coming to consensus about the problem statement, it is 
requested that short-term work focus on a problem statement document.  Once 
the WG has come to consensus on a problem statement document, solutions to 
that problem statement will be solicited.

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

Envelope-to: [email-masked]
Delivery-date: Fri, 14 Oct 2005 01:16:14 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Capabilities: Summary 
Cc: [email-masked]
Date: Thu, 13 Oct 2005 21:18:39 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> This could be addressed by encapsulating the existing attributes in the
> extended attribute format.

  Ugh.

> >  Or, *requested* information like location?
> 
> I wonder how many attributes will end up falling into this category?

  Not many.  See "hints" currently sent from NAS to server.

> I am operating under the impression that the Access-Challenge mechanism
> was deemed to be a sufficient solution for the desired attributes use
> cases.  Is that not so?

  Servers may offer limited services to clients that don't support
Access-Challenge.  Requiring Access-Challenge means offering *no*
service to some clients, because they will treat it like Access-Reject.

> Well, yes, customers worry about functionality.  OTOH, if we were to
> communicate functionality, it would require a new IANA registry and
> corresponding RFCs for each code point to define *exactly* what the
> functionality was.  The nice thing about attributes is that that (we
> expect) that the associated functionality is already well defined.

  Yes.  Which is why I proposed the "list of attributes" capability,
which supports both client-server, and server-client exchanges, and
the "mandatory versus requested" capability.

> > The mandatory bit in Diameter is nice, but I don't see it as being
> > incredibly useful in deployments.
> 
> Given that Diameter interoperability is a charter requirement, what does
> this say about the requirements for such a feature in RADIUS?

  If we're extending RADIUS to have features diameter doesn't, then
that would be a problem.

  I'm not sure how Avi's deployment scenarios would work in Diameter.

  Alan DeKok.

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

Delivery-date: Thu, 13 Oct 2005 22:17:57 +0000
To: [email-masked]
cc: [email-masked], [email-masked]
Subject: Issue 138
Date: Fri, 14 Oct 2005 00:13:04 +0200
From: [email-masked]

Proposed text in section "RADIUS Client Behavior":
   "If all of the following conditions are true, the RADIUS client MUST
   act as if it had sent an Access-Request and the RADIUS server had
   rejected the credentials with an Access-Reject packet:
   o  the scheme in the digest-uri directive indicates a secure HTTP-
      style connection (e.g. sip or https).
   o  the packets between RADIUS client and RADIUS server are not
      protected with IPsec.
   Under those conditions, a typical implementation would reject the
   HTTP-style request."

replaces:
   "If the packets between RADIUS client and RADIUS server are not
   protected with IPsec, the RADIUS client MUST NOT accept secured
   connections (like https or sips) from its HTTP-style clients, so that
   HTTP-style clients are not provided with a false sense of security."

The Security Consideration section gives some additional explanations.
The section contains a part:
  "There are two ways to achieve this:
   o  the RADIUS client may reject HTTP-style requests received over TLS
      or IPsec
   o  the RADIUS client require that traffic be sent and received over
      IPsec.
   RADIUS over IPsec, if used, MUST conform to the requirements
   described in [RFC3579] section 4.2.

I think it's weak enough with respect to the "don't mandate SIP / HTTP
behaviour" requirement.

Wolfgang

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

Delivery-date: Thu, 13 Oct 2005 21:24:10 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary 
Date: Thu, 13 Oct 2005 17:23:09 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

>   Backwards compatibility in existing attributes being "mandatory" for
> an implementation?  Existing Vendor-Specific extensions that don't
> have a mandatory bit?

This could be addressed by encapsulating the existing attributes in the
extended attribute format.

>  Or, *requested* information like location?

I wonder how many attributes will end up falling into this category?
That is to say, informative attributes that the server would like to see
included in Access-Requests as hints to the authorization process.

I am operating under the impression that the Access-Challenge mechanism
was deemed to be a sufficient solution for the desired attributes use
cases.  Is that not so?  I proposed the Mandatory bit to address the
required (to be obeyed, feature to be implemented, service to be
provided) attributes (server to client), not the required to be supplied
attributes (client to server).

>   I don't think the issue is "required attribute support", so much as
> "required and optional functionality support".=20

Well, yes, customers worry about functionality.  OTOH, if we were to
communicate functionality, it would require a new IANA registry and
corresponding RFCs for each code point to define *exactly* what the
functionality was.  The nice thing about attributes is that that (we
expect) that the associated functionality is already well defined.

> The mandatory bit in Diameter is nice, but I don't see it as being
> incredibly useful in deployments.=20

Given that Diameter interoperability is a charter requirement, what does
this say about the requirements for such a feature in RADIUS?

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

Envelope-to: [email-masked]
Delivery-date: Thu, 13 Oct 2005 20:55:24 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Capabilities: Summary 
Cc: [email-masked]
Date: Thu, 13 Oct 2005 16:57:46 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> What if we were to re-examine the extended RADIUS attribute format,
> complete with a Mandatory bit?  Could we then simplify the whole
> capabilities issue down to detection of support for (a) Access-Challenge
> and (b) Extended Attribute format?

  Backwards compatibility in existing attributes being "mandatory" for
an implementation?  Existing Vendor-Specific extensions that don't
have a mandatory bit?  Or, *requested* information like location?

  e.g. "If you have location, provide it, otherwise it's still OK".
That appears to be the use-case Avi is addressing.  A mandatory bit in
an extended attribute doesn't support his use-case.  Adding an
"requested" bit does address it, though.  You're then back to 2 bits
per attribute, which is pretty much what Avi was suggesting in a
different layout.

  To address your comments out of order:

> While the syntax is concise, formal and parse-able, the overall level of
> complexity to satisfy both clients and servers as to desired and
> required attribute support is growing again.

  I don't think the issue is "required attribute support", so much as
"required and optional functionality support".  The mandatory bit in
Diameter is nice, but I don't see it as being incredibly useful in
deployments.  Customers want functionality-based solutions, not
attribute-based solutions.

  To that end, Avi's functionality-based capability draft addresses
the problem directly.  It's just the format and future concerns that
concern me.

  If we focus on functionality support, two attributes would suffice:

  Mandatory-Functionality
  Requested-Functionality

  Make them enumerated int32's, and allow zero or more in
Access-Request and Access-Challenge.  Even allow them in
Access-Reject, as a hint as to why the request was rejected.  Start
off with value 1 meaning "understands Access-Challenge for PAP, etc",
and go on from there.  This would be fully compatible with existing
implementations, vendor-specific solutions, etc.

  The use cases Avi had in the end-to-end document looked like they
would have a very limited number of functionality advertisements.  So
making them int32's versus bits would have little protocol impact.

  Alan DeKok.

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

Delivery-date: Thu, 13 Oct 2005 17:29:22 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary 
Date: Thu, 13 Oct 2005 13:28:37 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

>   If this is satisfactory to the group, I'll write up something more
> formal.

While the syntax is concise, formal and parse-able, the overall level of
complexity to satisfy both clients and servers as to desired and
required attribute support is growing again.

What if we were to re-examine the extended RADIUS attribute format,
complete with a Mandatory bit?  Could we then simplify the whole
capabilities issue down to detection of support for (a) Access-Challenge
and (b) Extended Attribute format?

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

Envelope-to: [email-masked]
Delivery-date: Thu, 13 Oct 2005 17:08:16 +0000
From: "Alan DeKok" <[email-masked]>
To: "Nelson, David" <[email-masked]>
Subject: Re: Capabilities: Summary 
Cc: [email-masked]
Date: Thu, 13 Oct 2005 13:10:45 -0400
Message-Id: <[email-masked]>

"Nelson, David" <[email-masked]> wrote:
> Might I suggest one solution to this objection would be to create a
> single new attribute called Required-Attribute, whose value is the
> attribute ID of the required attribute.  Zero or more instances of
> Required-Attribute would be allowed in Access-Challenge messages.

  This was discussed earlier.  We would also need to address the issue
of required values.  i.e. "Service-Type = foo" is required.  And this
wouldn't address functionality that requires multiple attributes,
though one attribute could be used as a place-holder.

  My interest here is to get clarification of the requirements.  If
the sample exchange I gave satisfies the requirements, then that's a
step forward.  The next step is to determine what kinds of
capabilities (or server-side hints) are needed.

  We could define an "attribute list" type, where the content would be
a sequence of attribute numbers, possibly with VSA's in the vendor
format.  e.g.

  0x50 Message-Authenticator
  0x1a Vendor-Specific
    0x00 00 00 09 Cisco
    0x01          Cisco AVPair
  0x1a  Vendor-Specific
    0x00 00 01 ad USR
    0x00 00 00 66 Last number dialed out

  That would simple, clear, and wouldn't require IANA involvement.  It
would avoid the bitstrings of the current proposal, which scare me.

  We could then define:

  Necessary-Attributes of type "attribute number sequence"
  Requested-Attributes of type "attribute number sequence"

  I suggest "Necessary" rather than "required", because I can't think
of another synonym for "requested".  Having both "required" and
"requests" is a recipe for confusion.

  We could so something similar for values.  Extend the "attribute
sequence list" idea by adding a 32-bit integer after each listed
attribute.  e.g.

  0x06  Service-Type
    0x00 00 00 0a Call Check
  0x1a  Vendor-Specific
    0x00 00 01 ad USR
    0x00 00 98 10 Bridging
    0x00 00 00 02 disabled

  This proposal could take up more space than Avi's proposal, but it's
clearer to parse and understand.  And, it has the benefit that you can
address capabilities directly by number, rather than giving a long
string with one capability at the end.

  It also avoids the ACK problem I saw in the original proposal.
There wasn't a way to ACK capabilities there, but in this proposal,
the existing of an attribute is itself the ACK to the request.

  To get the functionality-based implementation that Avi suggested, we
could add another attribute of type "enumeration":

  Supported-Functionality
	foo 1
	bar 2
	...

  Which could be used as part of the above scheme to implement what
Avi was suggesting.

  If this is satisfactory to the group, I'll write up something more
formal.  If Avi is OK with it, the text could go into the end-to-end
capability draft.

  Alan DeKok.

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

Delivery-date: Thu, 13 Oct 2005 16:14:11 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary 
Date: Thu, 13 Oct 2005 12:13:07 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Further to my last comment...

> > Once an implementation supports that, any server can challenge the
> > client with "hints", as described above.  A possible workflow is:
> >
> >   C -> S: Access-Request
> > 		User-Name =3D foo
> > 		User-Password =3D bar
> > 		Capability =3D yes
> >   S -> C: Access-Challenge
> > 		Require-Location =3D yes
> > 		State =3D abcd
> >   C -> S: Access-Request
> > 		User-Name =3D foo
> > 		User-Password =3D bar
> > 		Capability =3D yes
> > 		location =3D "moe's tavern"
> > 		State =3D abcd
>=20
> This works well, for the specific case of GEOPRIV.
>=20
> For the general case of a server requiring a client to support
> <arbitrary-attribute>, this method would require a new attribute
called
> Require-<arbitrary-attribute> for every value of <arbitrary-attribute>
> of interest.  Surely this would lead to attribute bloat.

Might I suggest one solution to this objection would be to create a
single new attribute called Required-Attribute, whose value is the
attribute ID of the required attribute.  Zero or more instances of
Required-Attribute would be allowed in Access-Challenge messages.

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

Delivery-date: Thu, 13 Oct 2005 16:08:15 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary 
Date: Thu, 13 Oct 2005 12:06:54 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Alan DeKok writes...

> Once an implementation supports that, any server can challenge the
> client with "hints", as described above.  A possible workflow is:
>=20
>   C -> S: Access-Request
> 		User-Name =3D foo
> 		User-Password =3D bar
> 		Capability =3D yes
>   S -> C: Access-Challenge
> 		Require-Location =3D yes
> 		State =3D abcd
>   C -> S: Access-Request
> 		User-Name =3D foo
> 		User-Password =3D bar
> 		Capability =3D yes
> 		location =3D "moe's tavern"
> 		State =3D abcd

This works well, for the specific case of GEOPRIV.

For the general case of a server requiring a client to support
<arbitrary-attribute>, this method would require a new attribute called
Require-<arbitrary-attribute> for every value of <arbitrary-attribute>
of interest.  Surely this would lead to attribute bloat.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Oct 2005 23:48:17 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>
Subject: Re: Capabilities: Summary 
Cc: [email-masked]
Date: Wed, 12 Oct 2005 19:50:36 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> First, cap-advert is a way for the NAS to indicate to the server
> what features it supports so the Server can return attribs to the
> NAS and be assured that the NAS won't discard them.  This has
> nothing to do with challenge or the auth scheme.

  I agree.

> Second the chalange issue does not arise from the cap-advert.  In
> one particular instance it arises from the way geopriv set up their
> location exchange.  That is, not sending the location info on the
> original access request.  Here the cap-advert helps the protocol by
> informing the server that the NAS supports location (and challenge)
> so that the server that requires (or needs) location does not
> challenge a nas that doesn't support location and/or a challenge.

  The capability being advertised, then, isn't location, but "can
handled Access-Challenge responses to PAP, CHAP, MSCHAP requests".

  Once an implementation supports that, any server can challenge the
client with "hints", as described above.  A possible workflow is:

  C -> S: Access-Request
		User-Name = foo
		User-Password = bar
		Capability = yes
  S -> C: Access-Challenge
		Require-Location = yes    
		State = abcd
  C -> S: Access-Request
		User-Name = foo
		User-Password = bar
		Capability = yes
		location = "moe's tavern"
		State = abcd

  That proposal removes all of the functionality advertisement from
the capability exchange.  I think the potentially infinite list of "I
support functionality foo" is the source of the disagreement.

  In most situations, one party or other other will care about 10% of
the advertised capabilities, meaning the other 90% are irrelevant.
And having a potentially infinite list is problematic for
implementations to manage, to say nothing of IANA.

  The above proposal should keep all of the capability exchange within
the current RADIUS data model, and won't require a new bit-array.

  Comments?  Does this match your needs?

  Alan DeKok.

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

Delivery-date: Wed, 12 Oct 2005 22:22:00 +0000
Content-class: urn:content-classes:message
Subject: Re: Capabilities: Summary
Date: Wed, 12 Oct 2005 18:22:36 -0400
From: "Avi Lior" <[email-masked]>
To: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C5CF7B.72C1F2FB
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5CF7B.72C1F2FB
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C5CF7B.72C1F2FB--

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

Envelope-to: [email-masked]
Delivery-date: Wed, 12 Oct 2005 18:54:26 +0000
From: "Alan DeKok" <[email-masked]>
To: "Avi Lior" <[email-masked]>, [email-masked]
Subject: Re: Capabilities: Summary 
Date: Wed, 12 Oct 2005 14:56:39 -0400
Message-Id: <[email-masked]>

"Avi Lior" <[email-masked]> wrote:
> So forgive me but, the approach of advetizing takes the quess work out
> of the protocol and  I don't understand why we need to discuss this
> issue over and over again.

  My only concern with advertising is the possibility of an endless
list of things to advertise.

  Authentication protocols that already use Access-Challenge can be
extended to have the server request information in an
Access-Challenge, and the NAS supply it in a later Access-Request.  I
don't think there's any argument there.

  The only issue, then, is around authentication protocols such as
PAP, CHAP, or MS-CHAP.  Adding an additional Access-Challenge step is
awkward, just as adding capability advertising is awkward.

  So, is using capabilities with PAP, etc. a requirement?

  If so, is *any* capability advertising scheme acceptable to the WG?
(My $0.02 is yes)

  If so, what should it look like?

  Alan DeKok.

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

Delivery-date: Wed, 12 Oct 2005 15:15:51 +0000
Content-class: urn:content-classes:message
Subject: RE: AW: Capabilities: Summary
Date: Wed, 12 Oct 2005 11:14:41 -0400
From: "Nelson, David" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

Bernard Aboba writes...

> The problem with this is that it violates a MUST of RFC 2865. =20
> If the server is ok without location in the Access-Request,
> then it can send an Access-Accept instead of a Challenge.

Yes, I think it is appropriate for the server to make the decision to
provide limited access or full access, using one of the existing or
proposed attributes, such as including a Filter-ID attribute in the
Access-Accept.

The problem with this, however, is if the only way that the server can
find out if a NAS has or supports location information is to send an
Access-Challenge, there is no way for the server to make this informed
decision in some scenarios, as the NAS will automatically treat an
un-expected Access-Challenge as an Access-Reject.  The server cannot
know, from the initial Access-Request, whether to send an
Access-Challenge or send an Access-Accept (possibly with a Filter-ID).

This discussion presumes two facts: (a) the NAS never includes location
information in its initial Access-Request and (b) RADIUS authentication
mechanisms that do not already support Access-Challenge need to be use
in conjunction with GEOPRIV.  I think (a) is a requirement of GEOPRIV
and (b) is something that needs to be validated.

--
to unsubscribe send a message 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, 12 Oct 2005 15:03:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: RE: AW: Capabilities: Summary
Date: Wed, 12 Oct 2005 08:02:34 -0700

>this was actually one of the last bullets in my summary. in the usage
>scenario avi described the outcome of this interaction would not be
>equal to an access-reject. instead the aaa server would just grant
>access to the basic services and access to enhanced services is offered
>only if location information is provided.

The problem with this is that it violates a MUST of RFC 2865.  If the server 
is ok without location in the Access-Request, then it can send an 
Access-Accept instead of a Challenge.

--
to unsubscribe send a message 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, 12 Oct 2005 07:33:03 +0000
Content-class: urn:content-classes:message
Subject: AW: Capabilities: Summary
Date: Wed, 12 Oct 2005 09:30:55 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>

hi bernard,=20

in a discussion with jouni i was told that in the 3GPP Rel-6 I-WLAN
deployment scenario eap is mandatory.=20
for the GSMA IR.61 WLAN roaming scenario a challenge is not mandated but
the specification requires that location information is sent to the home
network. as such, there is no "capability negotiation" there. the work
in wimax is in progress and therefore this issues can be dealt with.=20

for a further comment please see below:=20

> > > a) problems seem to appear if the nas does not support=20
> the challenge.
> > > then the challenge will be treated as a reject.
> >
> >Yes.  However, we know that the RADIUS EAP method requires support in
> >the NAS for challenges.  Are there any deployment scenarios=20
> of interest
> >for GEOPRIV that expect to use the RADIUS PAP or CHAP=20
> methods?  If not,
> >this may well be a moot point.
>=20
> PAP implementations may well support challenges, since the=20
> User-Password=20
> attribute has been used with token cards.
>=20
> In any case, the issue only arises with NASes that don't=20
> support GEOPRIV,=20
> since presumably ones that do will support Challenges.  In=20
> the case of=20
> legacy devices that support neither GEOPRIV nor Challenges,=20
> the issue is=20
> moot, because treating the Challenge as an Access-Reject is=20
> the desired=20
> result.

this was actually one of the last bullets in my summary. in the usage
scenario avi described the outcome of this interaction would not be
equal to an access-reject. instead the aaa server would just grant
access to the basic services and access to enhanced services is offered
only if location information is provided.=20

ciao
hannes

--
to unsubscribe send a message 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, 11 Oct 2005 18:15:38 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Tue, 11 Oct 2005 14:15:27 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi Lior writes...

> I don't understand why we need to discuss this
> issue over and over again.

Because we have not yet reached rough consensus?  :-)

--
to unsubscribe send a message 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, 11 Oct 2005 18:11:31 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Tue, 11 Oct 2005 14:11:48 -0400
From: "Avi Lior" <[email-masked]>
To: "Nelson, David" <[email-masked]>, <[email-masked]>

I don't think this is a valid question to ask.  We should not be
designing protocols based on assumptions such as the one you want us to
make.

Furthermore, sending a challenge to a node that supports challenges but
does not support location is just wastefull.

Having an advertizement in the access request does not add any new
attributes (since the attribute for requesting location and advertizng
location is the same) and does not requires any extra messages. =20

So forgive me but, the approach of advetizing takes the quess work out
of the protocol and  I don't understand why we need to discuss this
issue over and over again.

=20

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Nelson, David
> Sent: Monday, October 10, 2005 11:52 AM
> To: [email-masked]
> Subject: RE: Capabilities: Summary
>=20
> Hannes Tschofenig writes...
>=20
> > a) problems seem to appear if the nas does not support the=20
> challenge.
> > then the challenge will be treated as a reject.
>=20
> Yes.  However, we know that the RADIUS EAP method requires=20
> support in the NAS for challenges.  Are there any deployment=20
> scenarios of interest for GEOPRIV that expect to use the=20
> RADIUS PAP or CHAP methods?  If not, this may well be a moot point.
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

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

Delivery-date: Mon, 10 Oct 2005 18:49:03 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Mon, 10 Oct 2005 14:48:56 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Bernard Aboba writes...
=20
> In any case, the issue only arises with NASes that don't support
GEOPRIV,
> since presumably ones that do will support Challenges.  In the case of
> legacy devices that support neither GEOPRIV nor Challenges, the issue
is
> moot, because treating the Challenge as an Access-Reject is the
desired
> result.

I think that Avi's point is that the desired result is *not*
Access-Reject in the particular scenario he describes: a roaming
consortium which contains none legacy, non-GEOPRIV NASes.  The home
provider would *like* to use GEOPRIV information to authorize its
roaming customers, but doesn't want to risk annoying the customer by
denying any form of access when they happen to be roaming via a non-home
ISP that has legacy NASes.

Or at least I think that's the scenario.

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

Delivery-date: Mon, 10 Oct 2005 18:41:08 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Capabilities: Summary
Date: Mon, 10 Oct 2005 11:40:37 -0700

> > a) problems seem to appear if the nas does not support the challenge.
> > then the challenge will be treated as a reject.
>
>Yes.  However, we know that the RADIUS EAP method requires support in
>the NAS for challenges.  Are there any deployment scenarios of interest
>for GEOPRIV that expect to use the RADIUS PAP or CHAP methods?  If not,
>this may well be a moot point.

PAP implementations may well support challenges, since the User-Password 
attribute has been used with token cards.

In any case, the issue only arises with NASes that don't support GEOPRIV, 
since presumably ones that do will support Challenges.  In the case of 
legacy devices that support neither GEOPRIV nor Challenges, the issue is 
moot, because treating the Challenge as an Access-Reject is the desired 
result.

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

Delivery-date: Mon, 10 Oct 2005 15:53:49 +0000
Content-class: urn:content-classes:message
Subject: RE: Capabilities: Summary
Date: Mon, 10 Oct 2005 11:52:22 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Hannes Tschofenig writes...

> a) problems seem to appear if the nas does not support the challenge.
> then the challenge will be treated as a reject.

Yes.  However, we know that the RADIUS EAP method requires support in
the NAS for challenges.  Are there any deployment scenarios of interest
for GEOPRIV that expect to use the RADIUS PAP or CHAP methods?  If not,
this may well be a moot point.

--
to unsubscribe send a message 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, 09 Oct 2005 20:21:41 +0000
Content-class: urn:content-classes:message
Subject: Capabilities: Summary
Date: Sun, 9 Oct 2005 22:19:17 +0200
From: "Tschofenig, Hannes" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>

hi all,

i would like to finalize the discussions about the capabilities in the
draft-ietf-geopriv-radius-lo-04.txt document. in this draft we suggested
an attribute that is sent in both directions (from nas -> aaa server and
from aaa server -> nas). bernard suggested an alternative solution that
basically avoided the attribute from the nas -> aaa server.=20

here is the summary of bernards proposal (provided by himself):=20

------------

a. RADIUS Server REQUIRES location in Access-Request or=20
Accounting-Request:  server sends an Access-Challenge with an attribute=20
that expresses what is required.=20

b. RADIUS server would like location information in the
Accounting-Request=20
but does not require it:  RADIUS server sends an Access-Accept with an=20
attribute that expresses what is desired.=20

c. RADIUS server REQUIRES location in Access-Request, but has not
received=20
it after sending an Access-Challenge:  RADIUS server=20
sends an Access-Reject with an Error-Cause attribute with value "Missing

Location Information"

------------

avi raised a few other issues, namely:

a) problems seem to appear if the nas does not support the challenge.
then the challenge will be treated as a reject.
=20
b) avi presented a use case that seems to require the usage of a
capability attribute sent from the nas -> aaa server:=20

the provided service depends on the availability of location information
in the access-request. the aaa server will not reject the request if
location information is not provided but the authorization decision
depends on whether location information is present at all and based on
the specific location information itself. a default service will be
provided if location is not available and more services will be enabled
depending on the specific location information provided to the aaa
server.=20

is my summary correct?=20

ciao
hannes

--
to unsubscribe send a message 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, 09 Oct 2005 00:42:03 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Conclusion of Pre-Work Item Review on Bandwidth Document
Date: Sat, 08 Oct 2005 17:41:52 -0700

Just to clarify the status of the Bandwidth Document deployment review.

The reponses appear to indicate there is interest in standardization of 
Bandwidth-related attributes, particularly within the switch community (IEEE 
802.1).

However, the deployment review also concluded that this community would not 
deploy the document as it currently exists.

Also, review from the IEEE 802.11 community indicates that legacy APs are 
not capable of carrying out Bandwidth Limitation as specified in the 
document, due to hardware limitations.  This explains why the existing 
WFA-defined VSAs have not been deployed.

However, newer APs that are capable of carrying out Bandwidth Limitation 
have adopted more sophisticated VSAs, and as a result, these newer APs would 
also not be likely to adopt the approach described in the existing document.

Based on the responses, the authors of the document are urged to incorporate 
the comments from the switch and 802.11 AP communities in order to develop a 
document that is likely to be deployed and implemented.

Once that revision has been completed, and deployment feedback indicates 
that the revision addresses industry/customer needs, the RADEXT WG will once 
again consider the document for adoption as a RADEXT WG work item.

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

Delivery-date: Sun, 09 Oct 2005 00:28:07 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: Issue 139: Nonce Attribute
Date: Sat, 08 Oct 2005 17:27:24 -0700

Issue 139: Nonce Attribute
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: October 10, 2005
Reference:
Document: RFC3576bis-00
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

It has been pointed out that the replay protection mechanisms
recommended in RFC 3576 may be difficult to deploy.

For example, the Event-Timestamp attribute requires time synchronization
between the RADIUS server and NAS. In roaming situations this would
require all networks between the RADIUS server and NAS to be running
NTP, synchronized to the same clock.

Similarly, IPsec with replay protection may not be deployable on all
hops in the path.

To provide more deployable replay protection it has been suggested that
a Nonce attribute be introduced. This attribute would be sent by the DAC
in a CoA/Disconnect-Request. If the DAS understands the attribute it would
be copied into the CoA/Disconnect ACK/NAK (possibly along with another
Nonce-attribute inserted by the DAS).

The Nonce attribute could also be used to enhance replay protection
in Accounting-Request packets. Since the receiver of the packet
with a Nonce attribute doesn't need to understand it, this attribute
is backward compatible with existing RFC 3576 implementations.

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

Delivery-date: Fri, 07 Oct 2005 18:23:02 +0000
Content-class: urn:content-classes:message
Subject: Call for RADEXT submissions and agenda items for IETF-64
Date: Fri, 7 Oct 2005 14:21:27 -0400
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "Nelson, David" <[email-masked]>

This is a general call for WG submissions and WG agenda items for the =
RADEXT session at IETF-64 in Vancouver.

Please reply to the chairs if you would like to make a presentation to =
the RADEXT WG, including the subject mater, Internet-Draft URL, and =
requested time allocation.

Note that for IETF-64 we have on-line WG agendas, updatable by the WG =
chairs, located on the IETF web site: =
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6=
4

Regards,
=A0
Dave Nelson

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

Delivery-date: Thu, 06 Oct 2005 06:36:28 +0000
Content-class: urn:content-classes:message
Subject: RE: FW: I-D ACTION:draft-salowey-radext-delegated-prefix-00.txt
Date: Thu, 6 Oct 2005 12:05:55 +0530
From: "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Joseph Salowey \(jsalowey\)" <[email-masked]>
Cc: <[email-masked]>

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: Friday, September 30, 2005 11:42 AM
> To: Joseph Salowey (jsalowey)
> Cc: [email-masked]
> Subject: RE: FW: I-D=20
> ACTION:draft-salowey-radext-delegated-prefix-00.txt
>=20
> > [Joe] My understanding is that Framed-IPv6-Prefix causes a=20
> route to be=20
> > added in the NAS and I would expect that route to be advertised in a
> > Router Advertisement messages.  =20
>=20
> RFC 3162 Section 2.3 states about Framed-IPv6-Prefix:
>=20
> "     This Attribute indicates an IPv6 prefix (and=20
> corresponding route)
>       to be configured for the user. "
>=20
> For Framed-IPv6-Route, RFC 3162, Section 2.5 states:=20
>=20
> "     This Attribute provides routing information to be configured for
>       the user on the NAS.  It is used in the Access-Accept packet and
>       can appear multiple times."
>=20
> RFC 2865, Section 5.10 describes Framed-Routing:
>=20
> "     This Attribute indicates the routing method for the=20
> user, when the
>       user is a router to a network.  It is only used in Access-Accept
>       packets."
>=20
> Based on this, I think Framed-IPv6-Prefix causes a route to=20
> be added on the NAS and advertised to the user via Router=20
> Advertisement, but not via routing packets (e.g. RIPv2)=20
> unless indicated in Framed-Routing.=20

My understanding is that the user can get an IP address locally=20
on the NAS or can get one from Radius server via=20
Framed-IP-Address(for IPv4)or  Framed-IPv6-Prefix(for IPv6) AVPs.

Now the question is, who determines whether the route should be
advertised or not. IMO, it is the local policy on the
NAS. For instance, a user's machine can be a web server and=20
it should be reachable from the upstream network side.

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

Delivery-date: Tue, 04 Oct 2005 14:52:48 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Issue:  RFC 2486bis Typos
Date: Tue, 04 Oct 2005 07:52:10 -0700

Section 2.3:

Change:

"In some situations NAIs are are used together with a separate"

To:

"In some situations NAIs are used together with a separate"

Section 2.4

Change:

" The realm part internationalization is
   based on International Domain Name (IDN) [RFC3490].

To:

"Internationalization of the realm part is based on
'Internationalizing Domain Names in Applications (IDNA) [RFC3490]."

Change:

"Similarly, we expect domain name comparisons,
   matching, resolution, and AAA routing to be performed on the ASCII
   versions of the international domain names.  "

To:

"Similarly, we expect domain name comparisons,
   matching, resolution, and AAA routing to be performed on the ASCII
   versions of the internationalized domain names.  "

Section 2.8

Change:

"           [email-masked]
           \(user\)@example.net

   The last example uses an IDN converted into an ASCII representation."

To:

"
           \(user\)@example.net
           [email-masked]

   The last example uses an IDN converted to an ASCII representation."

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

Delivery-date: Tue, 04 Oct 2005 05:52:41 +0000
Content-class: urn:content-classes:message
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 MIBS
Date: Mon, 3 Oct 2005 22:49:32 -0700
From: "Murtaza Chiba \(mchiba\)" <[email-masked]>
To: "Bernard Aboba" <[email-masked]>, "Nagi Reddy Jonnala \(njonnala\)" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

This is a multi-part message in MIME format.

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

So, basically we want a table of Error counters?  Or do we want =
something just for "Unknown Session Identifier"?   Plus we need an =
object to count NAKs for Diameter RAR.

Murtaza

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Fri 30-Sep-05 8:15
To: Nagi Reddy Jonnala (njonnala)
Cc: Murtaza Chiba (mchiba); [email-masked]; =
[email-masked]
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 =
MIBS
=20
I think I was going to go on to talk about Error Messages.  Some of them =

might be useful to count.=20

On Fri, 30 Sep 2005, Nagi Reddy Jonnala (njonnala) wrote:

> =20
> > > Alternative, is to maintain a counter for requests that are=20
> > for Diameter RAR capabilities.
> >=20
> > I do think it may make sense to count "Authorization Only" CoA and=20
> > Disconnect-Requests.  In terms of the=20
>=20
>  Did Bernard miss anything in the last line? I don't think we agreed =
for
> any "Authorize-only" Dyn auth requests. Could you guys conclude this
> conversation as well?
>=20
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

------_=_NextPart_001_01C5C8A7.C3B0D80D
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 =
6.5.7233.8">
<TITLE>RE: Issue: Counters for Session Contexts not found in RFC3576 =
MIBS</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>So, basically we want a table of Error counters?&nbsp; =
Or do we want something just for &quot;Unknown Session =
Identifier&quot;?&nbsp;&nbsp; Plus we need an object to count NAKs for =
Diameter RAR.<BR>
<BR>
Murtaza<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Bernard Aboba [<A =
HREF=3D"mailto:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Fri 30-Sep-05 8:15<BR>
To: Nagi Reddy Jonnala (njonnala)<BR>
Cc: Murtaza Chiba (mchiba); [email-masked]; =
[email-masked]<BR>
Subject: RE: Issue: Counters for Session Contexts not found in RFC3576 =
MIBS<BR>
<BR>
I think I was going to go on to talk about Error Messages.&nbsp; Some of =
them<BR>
might be useful to count.<BR>
<BR>
On Fri, 30 Sep 2005, Nagi Reddy Jonnala (njonnala) wrote:<BR>
<BR>
&gt;&nbsp;<BR>
&gt; &gt; &gt; Alternative, is to maintain a counter for requests that =
are<BR>
&gt; &gt; for Diameter RAR capabilities.<BR>
&gt; &gt;<BR>
&gt; &gt; I do think it may make sense to count &quot;Authorization =
Only&quot; CoA and<BR>
&gt; &gt; Disconnect-Requests.&nbsp; In terms of the<BR>
&gt;<BR>
&gt;&nbsp; Did Bernard miss anything in the last line? I don't think we =
agreed for<BR>
&gt; any &quot;Authorize-only&quot; Dyn auth requests. Could you guys =
conclude this<BR>
&gt; conversation as well?<BR>
&gt;<BR>
&gt; --<BR>
&gt; to unsubscribe send a message to [email-masked] =
with<BR>
&gt; the word 'unsubscribe' in a single line as the message text =
body.<BR>
&gt; archive: &lt;<A =
HREF=3D"http://psg.com/lists/radiusext/">http://psg.com/lists/radiusext/<=
/A>&gt;<BR>
&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C5C8A7.C3B0D80D--

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