Subject: Straw-man draft of the guidelines document
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Date: Fri, 26 Oct 2007 15:43:58 +0200

http://deployingradius.com/ietf/draft-ietf-radext-design-01a.txt

  Containing the text as discussed here, along with some wordsmithing
and clarifications.

  Alan DeKok.

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

Delivery-date: Tue, 23 Oct 2007 20:19:37 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Greg Weber'" <[email-masked]>, "'David Harrington'" <[email-masked]>
Subject: RE: review of NAS-Management-authorization
Date: Tue, 23 Oct 2007 16:17:45 -0400
Organization: Elbrys Networks, Inc.

David Harrington writes...

> Why do we want to not conflate it with the named policy approach?

I have answers on several levels.

Generally speaking, conflating similar but distinct objects leads to the
potential for confusion.

The integer-valued CLI privilege level has a well established and widely
deployed set of semantics, which cannot be modified in order to make it fit
within a generalized network management access policy framework.

One data object is an Integer type and the other object is a Text string
type.  Their native formats are incompatible.

I firmly believe that structured attributes, if we are to do them, need to
be represented as grouped attributes pursuant to the RADIIUS Extended
Attribute proposal.  Structured attributes represented as sub-strings to be
parsed out from other strings is bad design (IMO).

Quite frankly, I see no need for structured attributes in this case.

--
to unsubscribe send a message 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, 23 Oct 2007 14:34:31 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'Greg Weber'" <[email-masked]>, "'David Harrington'" <[email-masked]>
Subject: RE: review of NAS-Management-authorization
Date: Tue, 23 Oct 2007 10:32:21 -0400
Organization: Elbrys Networks, Inc.

Dave Harrington writes...

> My approach is to think of privilege level as being a "policy"
> that could be named for a particular management protocol type
> (e.g. CLI).

There is a widely deployed use case of numeric (integer) privilege levels
for CLI use.  The desire is to support that scheme, without conflating it
with the more general named policy approach.

> From the ISMS perspective, we want the policy-ID to be access
> control model independent - a single policyID identifies a policy
> to be applied, and then it is up to the specific access control 
> model that decides what the policy name actually means...

Sure.

> ... (and we will produce standards, like RFC3415's VACM, for 
> specification and interpretation of named policies).

The name of a policy means nothing.  It's just a label.  It's a name for
something that is locally defined and configured within the NAS.  The types
of rules in the policy set, and their interpretation by the NAS, will be
dependent upon the capabilities of the NAS.  If we desire to standardize the
way the rules in a policy are to be specified and provisioned, we could
write a MIB, or we could look to a document such as
http://www.ietf.org/internet-drafts/draft-ietf-radext-filter-rules-03.txt
for a description of a formal syntax for rule specification.

> Maybe the structured parameter approach should be allowed, and 
> then some standards should be defined to make those structured 
> parameters interoperable across vendors.

I think that is needlessly complex, but that is my opinion.

> Or we can require a single word as the policy, and then people can
> make up names like "operator-priv12", which they would do anyway if
> we don't support structured parameters.

There is nothing to prevent folks from using mnemonic names for polices that
describe their effect.  I think we should disallow the parsing of
sub-strings (structured parameters) in a single policy name in an attempt to
apply a compound policy synthesized from multiple individual policy
definitions.  If we want to do that, it is much better, IMO, to have
multiple instances of the attribute.

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

Delivery-date: Mon, 22 Oct 2007 18:49:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'David Harrington'" <[email-masked]>, "'Greg Weber'" <[email-masked]>
Subject: RE: review of NAS-Management-authorization
Date: Mon, 22 Oct 2007 14:47:34 -0400
Organization: Elbrys Networks, Inc.

Greg Weber writes...

> It seems fine to offer this as a separate attribute from Management-
> Policy-Id.
> 
> If we want this to be useful for non-framed management sessions 
> (with Service-Type values other than Framed-Management), I wonder
> if we want to limit this new attribute's use to sessions where 
> Service-Type is NAS-Prompt (not Administrative).

That would certainly support the use case this attribute is intended to
address.  There may be value in limiting the applicability of 
Management-Privilege-Level to CLI interfaces, since it is not clear how one
would apply both Management-Policy-Id and Management-Privilege-Level to a
framed management session.  The only question in my mind is whether this
should be a SHOULD NOT or MUST NOT.

> If we limit Management-Privilege-Level to Service-Type=NAS-Prompt,
> it would only have the effect of increasing privilege level when
> understood.  But, if Management-Privilege-Level were used with
> Service-Type=Administrative to restrict privileges, *and* the
> particular did not understand (and ignored) the
> Management-Privilege-Level attribute, the effect would be to avoid
> privilege restrictions.

Sounds good to me.

> And alternative would be to have the server use the
> Management-Privilege-Level only when the NAS had hinted that it
> was supported (a la Chargeable-User-Identity, if I recall).

The proposed text already indicates that it may appear in an Access-Request
message, as a hint to the RADIUS server that the NAS supports this
attribute.

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

Delivery-date: Mon, 22 Oct 2007 17:27:20 +0000
Date: Mon, 22 Oct 2007 13:26:20 -0400
From: "Greg Weber" <[email-masked]>
To: "David B. Nelson" <[email-masked]>
Subject: Re: review of NAS-Management-authorization
Cc: "David Harrington" <[email-masked]>, [email-masked]

> Since this is a common use case, I propose to add and additional attribute
> to explicitly provision integer privilege level.  That text would look like:
>
> 7.x.  Management-Privilege-Level
>
>    The Management-Privilege-Level attribute indicates the integer
>    Privilege level to be assigned for management access for the
>    Authenticated user.   Many NASes provide the notion of
>    differentiated management privilege levels denoted by an integer
>    value.  The specific access rights conferred by each value are
>    implementation dependent.  It MAY be used in both Access-Request
>    and Access-Accept packets.
>
>    A summary of the Management-Privilege-Level attribute format is
>    Show below.  The fields are transmitted from left to right.
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     Type      |    Length     |             Value
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                  Value (cont)         |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>       Type
>
>          (TBA) for Management-Privilege-Level.
>
>       Length
>
>          6
>
>
>       Value
>
>          The Value field is an Integer, denoting a management
>            privilege level.
>
> Further thoughts on this proposal?
>

It seems fine to offer this as a separate attribute from Management-Policy-Id.

If we want this to be useful for non-framed management sessions (with
Service-Type values other than Framed-Management), I wonder if we want
to limit this new attribute's use to sessions where Service-Type is
NAS-Prompt (not Administrative).  I think typically, NASes treat
NAS-Prompt as minimal privilege and Administrative as full privilege.
If we limit Management-Privilege-Level to Service-Type=NAS-Prompt, it
would only have the effect of increasing privilege level when
understood.  But, if Management-Privilege-Level were used with
Service-Type=Administrative to restrict privileges, *and* the
particular did not understand (and ignored) the
Management-Privilege-Level attribute, the effect would be to avoid
privilege restrictions.

And alternative would be to have the server use the
Management-Privilege-Level only when the NAS had hinted that it was
supported (a la Chargeable-User-Identity, if I recall).

Greg

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

Delivery-date: Mon, 22 Oct 2007 12:39:47 +0000
To: [email-masked]
From: [email-masked]
Date: Thu, 18 Oct 2007 14:20:01 -0400
Cc: [email-masked]
Subject: I-D Action:draft-ietf-radext-rfc3576bis-12.txt 
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)       : M. Chiba, et al.
	Filename        : draft-ietf-radext-rfc3576bis-12.txt
	Pages           : 29
	Date            : 2007-10-18

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-12.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-rfc3576bis-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-12.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-12.txt"; site="ftp.ietf.org";
	access-type="anon-ftp"; directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2007-10-18141958.I-D\@ietf.org>

--OtherAccess--

--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--NextPart--

--
to unsubscribe send a message 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, 21 Oct 2007 06:01:14 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-rfc3576bis-13.txt 
Date: Sun, 21 Oct 2007 02:00:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)       : M. Chiba, et al.
	Filename        : draft-ietf-radext-rfc3576bis-13.txt
	Pages           : 29
	Date            : 2007-10-21

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-13.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-rfc3576bis-13.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-13.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-13.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-13.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-10-21015315.I-D\@ietf.org>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message 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, 19 Oct 2007 20:15:32 +0000
From: "David B. Nelson" <[email-masked]>
To: "'David Harrington'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: review of NAS-Management-authorization
Date: Fri, 19 Oct 2007 16:07:53 -0400
Organization: Elbrys Networks, Inc.

David Harrington writes...

> I think limiting it to one policy name would be the simplest, 
> and most deterministic, approach.

<snip>

> I would rather see a single policy-name so there is no ambiguity
> in the RADIUS authorization.

If there is no objection, I will include language to that effect, making
this consistent with the Filter-Id usage.

> > I propose that we add language indicating that such usages
( sub-fields)
> > are NOT RECOMMENDED or SHOULD NOT, in the interests of multi-
> > vendor interoperability.
> 
> I agree.>

If there is no objection, I will add language to that effect, as well.

> > If there are requirements for other forms of management access
> > control policy, such as the commonly used integer privilege level
> > indicator, I think we should add a separate attribute to cover 
> > that use case, using a RADIUS data type of Integer.
> 
> I agree.

Since this is a common use case, I propose to add and additional attribute
to explicitly provision integer privilege level.  That text would look like:

7.x.  Management-Privilege-Level

   The Management-Privilege-Level attribute indicates the integer
   Privilege level to be assigned for management access for the
   Authenticated user.   Many NASes provide the notion of 
   differentiated management privilege levels denoted by an integer
   value.  The specific access rights conferred by each value are
   implementation dependent.  It MAY be used in both Access-Request
   and Access-Accept packets.

   A summary of the Management-Privilege-Level attribute format is 
   Show below.  The fields are transmitted from left to right.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |             Value
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Value (cont)         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Type

         (TBA) for Management-Privilege-Level.

      Length

         6

      Value

         The Value field is an Integer, denoting a management
	   privilege level.

Further thoughts on this proposal?

> I thought about this a bit more. If the assumption is that the
> Management Policy ID is only provided when RADIUS is doing the
> authentication, and this only occurs if the mgmt protocol is using
> a RADIUS-secured transport, then this should be explained. This 
> should be true of any mgmt protocol, not just SNMP, so you probably
> should not specify SNMP-Transport-Model, but simply SNMP. The 
> Transport-Model attribute identifies the transport, and SNMP can 
> use that to determine the transport model.

You mean the Management-Transport-Protocol (nee Transport-Protocol)
attribute?

That seems reasonable to me.

> The (database) access control subsystem in the RFC3411 SNMP
> architecture requires a securityModel, and the VACM model uses
> the securityModel in making its authorization decision. So requiring
> a particular securityModel would make architectural (and security)
> sense.

OK.
 
> So, if the intent is to specify the required security mechanism to
> qualify for this authorization (which makes more sense than 
> required transport), then this should be the SNMP SecurityModel 
> rather than the transport-model. In SNMP, we have an SNMPv1 security
> model plus and SNMPv2c security model, and potentially multiple
> security models that can be used with an SNMPv3 message (currently
> USM and the ISMS TSM).  These are designed to be independent of the
> transport used. So using the security model could allow in an 
> authorization-only mode for "raw" SNMP.

Um...  That makes sense for SNMP, but may not be applicable to other
management protocols.  We could add an attribute specifically for SNMP to
carry the SNMP securityModel, but it might be more general to specify the
security "wrapper" in a management protocol independent fashion.  I agree
that this is not exactly the same thing as specifying the [secure]
transport, since some of the SNMP securityModels do not use a distinct
transport (e.g. SNMP V1 and V2c both use UDP).

I'll need to give this a little more thought.

> There is a desire to have an authorization-only mode for SNMP 
> (and possibly other mgmt protocols). So I think being able to ask
> RADIUS for the mgmt policy ID even when the transport is non-secure
> makes sense. I think it makes sense to allow for UDP, TCP, SCTP, etc.
> The mgmt-protocol security "model" (regardless of protocol) might 
> utilize assumptions about the transport used in making a security 
> decision, so I think we should not just lump them together as 
> "generic non-secure", but allow the specification of which is 
> actually used.

OK.  If there is no objection, I will add commonly used transports you
mention to the enumeration.

> I would avoid requiring a session, since some SNMP is sessionless.
> Other mgmt protocols built atop UDP, such as syslog, also might be
> sessionless, and I would prefer not to limit the policy-ID to
> session-based mgmt.

OK.

> The phrasing that recommends "using" UDP-8 is not inconsistent
> with mandatory-to-implement UDP-8.  There is a real 
> interoperability problem if a sender uses UDP-8 and the receiver
> does not support it. If you want to recommend using UDP-8, then 
> receivers should be required to accept UDP-8 when it is used.

What you say makes sense.  Is there any objection to making UTF-8 mandatory
to implement, in this document, even though the base RADIUS documents do not
go that far?

--
to unsubscribe send a message 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, 19 Oct 2007 20:15:07 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: New Issue: MGMT-00 -command privilege levels
Date: Fri, 19 Oct 2007 16:13:51 -0400
Organization: Elbrys Networks, Inc.

Greg Weber writes...

> From section 4:
> "The local application of the Management-Policy-Id within the managed
>    entity may take the form of (a) one of an enumeration of command
>    privilege levels, ..."
> The draft does not currently describe valid values for the case when
> Management-Policy-Id is supposed to represent a privilege level.  
> The excerpt above mentions an enumeration; the attribute value is 
> later defined as type Text.

Yes.  We've just been discussing this same issue in the context of review
comments from Dave Harrington.

> Requested change:
> I would suggest removing references to command privilege levels and
> let the NASes map Management-Policy-Id based on what functionality is
> locally supported.  Privilege level (if supported on the client) may
> be one of many types of local policy, e.g. time of day restrictions on
> command execution.  I don't think we want to address all these, do we?
> In the excerpted sentence, I think (a) is just a subset of (c).

There are at least a couple of ways to resolve this.  One is to do as you
suggest and remove the text that talks about privilege levels in terms of
the Management-Policy-Id attribute, and leave it at that.  The approach that
I've proposed in the other thread is to add an explicit attribute to convey
an Integer-valued management privilege level, given that this construct
seems fairly popular and widely deployed.

Is there a good reason that we should avoid an explicit attribute to cover
this common use case?

--
to unsubscribe send a message 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, 19 Oct 2007 19:36:29 +0000
Date: Fri, 19 Oct 2007 15:35:44 -0400
From: "Greg Weber" <[email-masked]>
To: [email-masked]
Subject: New Issue: MGMT-00 -command privilege levels

Description: command privilege level mapping
Submitter name: Greg Weber
Submitter email address: [email-masked]
Date first submitted: 10/19/07
Reference: n/a
Document: MGMT-00
Comment type: Technical
Priority: Should fix
Section: 4
Rationale/Explanation of issue:
>From section 4:
"The local application of the Management-Policy-Id within the managed
   entity may take the form of (a) one of an enumeration of command
   privilege levels, ..."
The draft does not currently describe valid values for the case when Management-
Policy-Id is supposed to represent a privilege level.  The excerpt
above mentions an enumeration; the attribute value is later defined as
type Text.

Requested change:
I would suggest removing references to command privilege levels and
let the NASes map Management-Policy-Id based on what functionality is
locally supported.  Privilege level (if supported on the client) may
be one of many types of local policy, e.g. time of day restrictions on
command execution.  I don't think we want to address all these, do we?
 In the excerpted sentence, I think (a) is just a subset of (c).

--
to unsubscribe send a message 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, 19 Oct 2007 14:25:14 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Guidelines suggested text for checklist:
Date: Fri, 19 Oct 2007 07:24:24 -0700

>   That appears to be backwards from your first comment.  Maybe SHOULD.
>allocate from vendor-specific, or else IANA if wider inter-operability
>is desired.

Here is what RFC 3575 says about value allocations:

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute.  Additional values can be
   allocated by the Designated Expert.  The exception to this policy is
   the Service-Type attribute (6), whose values define new modes of
   operation for RADIUS.  Values 1-16 of the Service-Type attribute have
   been allocated.  Allocation of new Service-Type values are by IETF
   Consensus.  The intention is that any allocation will be accompanied
   by a published RFC.

Given this, a vendor or SDO can request allocation of a value by "Designated 
Expert", unless we are talking about a value that can be used to create new 
commands (e.g. Service-Type).  Given this, I'm not sure why it would be 
desirable for an SDO to create a VSA for a normal value allocation.

If we are talking about creation of new commands, that is a major protocol 
change whether it is occurring via VSAs or new values -- and I'd suggest 
that this is the kind of "extension" that is outside the scope of the 
document.

--
to unsubscribe send a message 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, 19 Oct 2007 12:57:48 +0000
From: "David B. Nelson" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Fri, 19 Oct 2007 08:57:34 -0400

Alan DeKok writes...

> David B. Nelson wrote:
> > Suffice it to say that we really want VSAs used for SDO-standardized
> > attributes to be published as an RFC, while we really don't care 
> > whether VSAs used for vendor proprietary attributes are published 
> > (unless it's a sufficiently influential vendor, and the feature 
> > becomes a de facto industry standard).
> 
>   I agree.

Back-pedaling just a bit... I don't know that we care whether it's an RFC or
some RFC-like freely available standard. The current practice with MIB
modules is to not publish them as RFCs if they're freely available from the
SDO.  There is a cost to publishing RFCs, and while it might be nice to have
all RADIUS related material published in a single document series, that may
be something of a luxury. 

--
to unsubscribe send a message 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, 19 Oct 2007 12:55:52 +0000
Date: Fri, 19 Oct 2007 14:54:51 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
> Given all the discussion, proposals and counter proposals, I suggest that a
> straw-man draft be made available for additional review, prior to formally
> submitting -01.

  I'll put it online, and post a URL separately.

>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.
> 
> DBN: I think what we are saying here is that work not brought to the IETF
> should not request IANA assignments.  We are implicitly reserving the
> IANA-controlled standard RADIUS attribute ID space for use for work
> published via the IETF, or by the Independent RFC-Editor Submission route.
> If that is the case, perhaps we should say so in so many words.

  Yes.  Suggested text:

   Vendors and SDOs are reminded that the standard RADIUS attribute ID
   space, and the enumerated value space for enumerated attributes, are
   reserved for allocation through work published via the IETF, as noted
   in [RFC3575] Section 2.1.  Some vendors and SDOs have historically
   performed self-allocation by assigning vendor-specific meaning to
   "unused" values from the standard RADIUS attribute ID or enumerated
   value space.  This practice MUST NOT be followed.  The IETF process
   discussed above MUST be used instead for allocations from the
   standard spaces.

> DBN:  If the SDOs have an open publication policy, whereby all interested
> parties can obtain a copy of the relevant portions of these standards
> documents, containing the description of RADIUS attributes, this would seem
> redundant.  For example the IEEE, while restricting access to draft
> standards and newly published standards, will typically make the MIB modules
> from their works freely available in text format.

  Good point.

...
>    All other specifications, including new authentication and/or
>    security methods SHOULD be allocated via the standard RADIUS space,
>    via "IETF Consensus" as noted in [RFC3575] Section 2.1.
> 
> DBN: Is this duplicate text, or is the text I've annotated above proposed to
> be replaced by this text?

  I've re-arranged it so that vendors and SDO's have their own sections,
as the guidelines were diverging slightly for them.  As such, some text
is duplicated, with minor edits.  This should be clearer once I post a
proposed draft.

>    Note that the first bullet point above relaxes many of the previous
>    guidelines on data types, but only within a narrowly defined scope.
> 
> DBN:  What exactly do we mean here?  Why are we relaxing previously defined
> guidelines and in what scope?

  I'll post the draft, which will make this clear.

>    Extensions to RADIUS that may not be appropriate for widespread use
>    may be acceptable within a limited context.
> 
> DBN:  This sounds like the start of a slippery slope, especially for a BCP
> document.  :-)

  It's a recognition that site-specific nonsense has a limited scope.

> DBN:  I'm not sure that I can find the most recent text proposed for
> Sections 3.1.1, 3.1.2 and 3.1.3.

  I'll post the draft.

> DBN:  I think it would be useful, however, to insert somewhere among those
> sections a bit of text that describes the "level of care" that is expected
> for RADIUS attributes, encoded as VSAs, but intended for standardization in
> non-IETF SDOs, for use by multiple vendors within an industry segment, or
> within the global Internet community.  I would suggest that the design,
> review and interoperability guidelines for any such VSAs (what I have called
> SSAs) be the same as for full standard RADIUS attributes under IANA
> allocation and IETF review.  The review mechanism would differ, but the
> criteria should not.

  I agree.

> DBN:  Without attempting to specify a particular section, let me suggest
> some additional clarifying text:
...

  OK.  I'll word smith it and integrate it in.

  While I like the term SSA, I'm not sure introducing another acronym
here would help.

  I'll do another pass over the document for consistency and flow of
thought, then post a URL to this list.

  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, 19 Oct 2007 07:09:20 +0000
Date: Fri, 19 Oct 2007 09:09:04 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
> Suffice it to say that we really want VSAs used for SDO-standardized
> attributes to be published as an RFC, while we really don't care whether
> VSAs used for vendor proprietary attributes are published (unless it's a
> sufficiently influential vendor, and the feature becomes a de facto industry
> standard).

  I agree.

  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, 19 Oct 2007 07:06:22 +0000
Date: Fri, 19 Oct 2007 09:05:33 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

Bernard Aboba wrote:
> Reading the text, I'm still not sure if we want them to create their own
> new VSA or to get a proper IANA allocation.  Most vendors seem to prefer
> the latter, and is to be discouraged, I think we need more explanation
> about why.
> 
> How about "Rather than self-allocating new values for attribute of
> enumerated type (as described by the Vendor Specific Enumerations
> proposal in [RFC2882] Section 2.2.1), vendors SHOULD obtain an
> allocation under the IANA guidelines of [RFC3575] Section 2.1.  If this
> is not possible, vendors should allocate an attribute from their
> Vendor-Specific space, and define an appropriate value for it."

  That appears to be backwards from your first comment.  Maybe SHOULD.
allocate from vendor-specific, or else IANA if wider inter-operability
is desired.

  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, 19 Oct 2007 01:08:36 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 21:07:54 -0400

Bernard Aboba writes...

> IANA assignments are governed by RFC 3575, not anything in this
> document (which is only a BCP).
>
> The issue is whether an SDO (or vendor) requesting IETF review 
> should be required to re-host their attributes into the IETF 
> standards space.  The answer should be "no" -- IETF review is 
> orthogonal to IANA allocation policy.

The term "re-host" assumes that there is an already initial hosting in VSA
space.  While that may often be the case, especially if the work is
standardizing something already deployed by one or more vendors, it may not
be the case if it is new work.  My issue is whether other SDOs are to be
advised to "stay away" from the IETF process and seeking RFC 3575
allocations, when no previous VSA allocation exists.  Nothing in RFC 3575
says that today.  SDOs are presumably free to seek IETF Consensus for IANA
assignments.

> In terms of public availability, the main issue is that the IETF 
> cannot review a document that is not made available to it.  So the
> train of logic here is:
> 
> * The SDO wants their document reviewed by the IETF.
> * To get IETF review, the SDO needs to make the document available 
> to the reviewers.
> * One way to make the document available for wide review is to make it
> openly available, either on the SDO site, or by publishing it as an I-D
> (and eventually, RFC).

There's more to this issue that IETF review.  There's the issue of open
availability for implementers.  Some "country club SDOs" (no, I don't mean
the IEEE) only allow members to get standards, or don't have any program for
free access.  That may be a reason to want to re-publish work as an RFC,
just to make the full collection of RADIUS attributes freely 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: Thu, 18 Oct 2007 22:36:16 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 15:35:04 -0700

>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.
>
>DBN: I think what we are saying here is that work not brought to the IETF
>should not request IANA assignments.

IANA assignments are governed by RFC 3575, not anything in this document 
(which is only a BCP).
The issue is whether an SDO (or vendor) requesting IETF review should be 
required to re-host their attributes into the IETF standards space.  The 
answer should be "no" -- IETF review is orthogonal to IANA allocation 
policy.

>We are implicitly reserving the IANA-controlled standard RADIUS attribute 
>ID space for use for work published via the IETF, or by the Independent 
>RFC-Editor Submission route.

This document does not update RFC 3575, so it can't change IANA allocation 
policy.

>If that is the case, perhaps we should say so in so many words.

I hope that is *not* the case -- because the document doesn't say that it 
updates RFC 3575.

>    SDOs are encouraged to submit their RADIUS specifications to the IETF
>    for publication as an informational RFC.
>
>DBN:  If the SDOs have an open publication policy, whereby all interested
>parties can obtain a copy of the relevant portions of these standards
>documents, containing the description of RADIUS attributes, this would seem
>redundant.

I would agree.  We need to think about the potential RFC Editor impact here. 
  If the SDO documents are already publicly available, is there value in 
having them published as RFCs that is commensurate to the cost imposed on 
the RFC Editor?  The IAOC budget is finite, after all.

In terms of public availability, the main issue is that the IETF cannot 
review a document that is not made available to it.  So the train of logic 
here is:

* The SDO wants their document reviewed by the IETF.
* To get IETF review, the SDO needs to make the document available to the 
reviewers.
* One way to make the document available for wide review is to make it 
openly available, either on the SDO site, or by publishing it as an I-D (and 
eventually, RFC).

>For example the IEEE, while restricting access to draft
>standards and newly published standards, will typically make the MIB 
>modules
>from their works freely available in text format.

Actually, RFC 4441 states that the IEEE 802 will make "work in progress" 
available to IETF reviewers (the whole document) as well as by making the 
MIB public.  After 6 months, IEEE 802 documents are available on the web 
site free of charge (via the Get IEEE 802 program).

--
to unsubscribe send a message 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, 18 Oct 2007 22:35:50 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 15:35:04 -0700

>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.
>
>DBN: I think what we are saying here is that work not brought to the IETF
>should not request IANA assignments.

IANA assignments are governed by RFC 3575, not anything in this document 
(which is only a BCP).
The issue is whether an SDO (or vendor) requesting IETF review should be 
required to re-host their attributes into the IETF standards space.  The 
answer should be "no" -- IETF review is orthogonal to IANA allocation 
policy.

>We are implicitly reserving the IANA-controlled standard RADIUS attribute 
>ID space for use for work published via the IETF, or by the Independent 
>RFC-Editor Submission route.

This document does not update RFC 3575, so it can't change IANA allocation 
policy.

>If that is the case, perhaps we should say so in so many words.

I hope that is *not* the case -- because the document doesn't say that it 
updates RFC 3575.

>    SDOs are encouraged to submit their RADIUS specifications to the IETF
>    for publication as an informational RFC.
>
>DBN:  If the SDOs have an open publication policy, whereby all interested
>parties can obtain a copy of the relevant portions of these standards
>documents, containing the description of RADIUS attributes, this would seem
>redundant.

I would agree.  We need to think about the potential RFC Editor impact here. 
  If the SDO documents are already publicly available, is there value in 
having them published as RFCs that is commensurate to the cost imposed on 
the RFC Editor?  The IAOC budget is finite, after all.

In terms of public availability, the main issue is that the IETF cannot 
review a document that is not made available to it.  So the train of logic 
here is:

* The SDO wants their document reviewed by the IETF.
* To get IETF review, the SDO needs to make the document available to the 
reviewers.
* One way to make the document available for wide review is to make it 
openly available, either on the SDO site, or by publishing it as an I-D (and 
eventually, RFC).

>For example the IEEE, while restricting access to draft
>standards and newly published standards, will typically make the MIB 
>modules
>from their works freely available in text format.

Actually, RFC 4441 states that the IEEE 802 will make "work in progress" 
available to IETF reviewers (the whole document) as well as by making the 
MIB public.  After 6 months, IEEE 802 documents are available on the web 
site free of charge (via the Get IEEE 802 program).

--
to unsubscribe send a message 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, 18 Oct 2007 21:48:12 +0000
From: "David B. Nelson" <[email-masked]>
To: "'David Harrington'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: review of NAS-Management-authorization
Date: Thu, 18 Oct 2007 17:46:40 -0400
Organization: Elbrys Networks, Inc.

David Harrington writes...

> section 3.
> Should netconf be included in the list of framed-protocols?

Yes, I suppose it should.  

> section 4.
> "contain the name of a management access rights policy"
> "containing policy name"
> can this be more than one policy name?

That's a good question, especially in light of the clarifications we've
included in the RADIUS Issues & Fixes draft regarding interpretation of
multiple instances of the Filter-Id attribute within an Access-Accept.

Here's what we say about that:

   In practice the behavior of a RADIUS client receiving multiple
   Filter-ID attributes is implementation dependent.  For example, some
   implementations treat multiple instances of the Filter-ID attribute
   as alternative filters; the first Filter-ID attribute having a name
   matching a locally defined filter is used, and the remaining ones are
   discarded.  Other implementations may combine matching filters. 

I could support defining the Management-Policy-Id in one of the following
ways:

(1) Similar to Filter-ID, as modified above, i.e. multiple instances provide
undefined behavior at the NAS, and ought to be avoided.

(2) Multiple alternative policies, from which the NAS selects the first
occurrence of this attribute that matches the name of a locally configured
policy.  All other occurrences of this attribute are ignored.

(3) Multiple additive policies, which the NAS will attempt to apply in a
consolidated form.  Any conflicts in the underlying rules contained in the
named policies stored in the NAS will be resolved based on the precedence of
attribute occurrence, wherein rules from polices named by the earlier
instances of this attribute that appear in an Access-Accept take precedence
over rules from policies named by later instances of the attribute.  This
relies on the fact that RADIUS proxies are prohibited form re-ordering
instances of the same attribute type within messages.

Does anyone have a preference?

On a related note, I had a side conversation regarding the content of the
Management-Policy-Id, in which the question was asked whether this was
always a "single, flat name" that maps to a single policy-set in the NAS, or
whether implementers could define separate sub-fields, along the lines of
"filter=some_filter_name, privilege_level=4, access_type=remote".  I think
it would lead to very poor interoperability if implementers were to create
sub-fields of this attribute.  I propose that we add language indicating
that such usages are NOT RECOMMENDED or SHOULD NOT, in the interests of
multi-vendor interoperability.

If there are requirements for other forms of management access control
policy, such as the commonly used integer privilege level indicator, I think
we should add a separate attribute to cover that use case, using a RADIUS
data type of Integer.

> section 5
> Is Transport-Protocol really only valid for the CLI?

No, that's an editing mistake.  In the second sentence it indicates that it
applies to Framed-Management.  I'll remove the restriction to CLI usages.

> section 7.1
> I have not yet walked through the various combinations of SNMP
> components (message formats vs transports).
> I think SNMP-Transport-Model only covers a small set of possibilities.
> More research is needed on this.

Well, earlier versions of this draft included enumerated values for SNMP
(both V1/v2c and V3).  It was pointed out that there were no standardized
ways for RADIUS to provision "generic" SNMP engines, and that the only
standards work in this area is the ISMS work on SNMP Transport Models.

If it is useful to specify "raw" SNMP as a Framed-Management-Protocol as
provisioned by RADIUS, we can certainly put these values back into the
enumeration.  Thoughts?

> section 7.2
> Should this be named Management-Transport-Protocol to differentiate
> it from other service-related parameters?

Given that the RADIUS data dictionary is "flat", yes, I think that change
would be a good idea to reduce possible confusion.

> While we definitely want this with SSH and TLS, is there a case for
> having this with SNMPv1/UDP and other non-secure transports?

The value of "None" was intended to indicate that no _secure_ transport was
required, not that no transport is to be used (that would be silly).  Does
the usage of "None" to indicate non-secure transport(s) work for you?
Should we change that to "Generic-Non-Secure-Transport"?  Or do you really
think we need to specify each non-secure transport by name?

> section 7.3
> SNMP does not support sessions, although the transport over which SNMP
> runs may have sessions.
> Does the term session here refer to an SNMP session? If so, that is a
> problem.

It refers to the session of the underlying secure transport (e.g. SSH), as
used in the ISMS work.  If we want to open up the usage to "raw" SNMP as a
protocol/transport, then this indeed becomes an issue.

> /NAS SHOULD treat the packet/NAS MUST treat the packet/? Under what
> circumstances would it be acceptable to not reject?

Is the consensus that we want to change this to MUST?
 
> "It is recommended" to use UTF-8. Should UTF-8 support be mandatory to
> implement?

This phrasing is pervasive throughout RADIUS.  I'm not sure if we want to
start down that path now.  Thoughts?

> section 9
> "what this specification says" and "what is said" seem quaint ways of
> describing this. Would it be better to specify the sections where
> things are said, or is this language a common approach for
> RADIUS-Diameter coordination?

This language is a common approach, and this text was purloined from other
drafts.
 
> section 10
> /proxy environments/RADIUS proxy environments/ to differentiate this
> from SNMP proxy environments.

Good point.  Will do.
 
> section 13
> "within local area networks" - I'm not sure this can be justified.
> Many protocols originally designed for use only within local area
> networks actually get used over the Internet. Do we actually have any
> mechanism to prevent this from happening, or is it just recommended
> that it be restricted to use in a LAN?

No, this text is taken from elsewhere.  I don't think that the scope of this
document is limited to LANs.  If there is no objection, I'll delete that
text.

> I think the last paragraph should include a statement at the end,
> recommending that management protocols should support data access
> controls to prevent the disclosure of information to help prevent
> unauthorized management access.

This document specifies how to provision management access to NASes and
similar devices, using RADIUS attributes.  We are always careful to avoid
creating requirements for, or specifications of, the underlying service that
we are provisioning in a RADIUS document.  That specification has to occur
elsewhere, in a document that specifies the service.  While what you suggest
is a Good Idea (tm), I think it is out of scope for this document.
 
> Throughout
> There are mentions of VACM. These should be couched as examples, since
> SNMP can theoretically support multiple ACMs.

Yes.  Good Point.  I'll make it clear that VACM is just an example.

--
to unsubscribe send a message 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, 18 Oct 2007 18:32:08 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 14:31:07 -0400
Organization: Elbrys Networks, Inc.

Please bear with me here, I'm attempting to track the state of the existing
and proposed text, as it is evolving in this discussion.

Given all the discussion, proposals and counter proposals, I suggest that a
straw-man draft be made available for additional review, prior to formally
submitting -01.

My comments, in-line, below, are flagged with "DBN:".

>From the last paragraph of Section 3.1 (-00 draft):

   In particular, it is RECOMMENDED that RADIUS Attribute specifications
   allocate attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:
      * attributes relying on data types not defined within RADIUS 
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

As proposed during discussion in this thread:

Suggested text:

   In particular, RADIUS Attribute specifications SHOULD allocate
   attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:

      * attributes defined by vendors and not suitable for general use,
        as per [RFC2865] Section 5.26.

DBN: Clearly, yes.

      * attributes relying on data types not defined within RADIUS

DBN: To the extent that someone really needs to do this, given the existence
of the RADIUS Extended Attribute work, yes.

      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

DBN: I think what we are saying here is that work not brought to the IETF
should not request IANA assignments.  We are implicitly reserving the
IANA-controlled standard RADIUS attribute ID space for use for work
published via the IETF, or by the Independent RFC-Editor Submission route.
If that is the case, perhaps we should say so in so many words.

   SDOs are encouraged to submit their RADIUS specifications to the IETF
   for publication as an informational RFC.

DBN:  If the SDOs have an open publication policy, whereby all interested
parties can obtain a copy of the relevant portions of these standards
documents, containing the description of RADIUS attributes, this would seem
redundant.  For example the IEEE, while restricting access to draft
standards and newly published standards, will typically make the MIB modules
from their works freely available in text format.

   Vendors defining Vendor-
   Specific dictionaries for their own use SHOULD make their
   specification publicly available, but there is no need to publish
   their specification as an RFC.

DBN:  Sure.

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

>From the proposed Section 3.1.3 (intended for the -01 draft):

3.1.3.  Publication of specifications

   SDOs are encouraged to seek review of VSA specifications by the IETF.
   Once reviewed, the specifications may be published as Informational
   RFCs.  This process should be followed instead of requesting IANA
   allocations from within the standard RADIUS attribute space.  Vendors
   wishing to make their specifications publicly available may also
   request publication of their VSA specifications as Informational RFCs
   by the IETF, instead of requesting IANA allocations for proprietary
   attributes

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

DBN: Is this duplicate text, or is the text I've annotated above proposed to
be replaced by this text?

>From the proposed Appendix A (intended for the -01 draft):

A.6. Allocation of attributes

   RADIUS attribute specifications SHOULD allocate attributes from the
   vendor space, rather than requesting an allocation from the RADIUS
   standard attribute space, for attributes matching any of the
   following criteria:

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   Even if attributes are allocated from the vendor space, it is often
   useful for SDOs to publish the specification as an informational RFC,
   as with [RFC4679].

   Note that the first bullet point above relaxes many of the previous
   guidelines on data types, but only within a narrowly defined scope.

DBN:  What exactly do we mean here?  Why are we relaxing previously defined
guidelines and in what scope?

   Extensions to RADIUS that may not be appropriate for widespread use
   may be acceptable within a limited context.

DBN:  This sounds like the start of a slippery slope, especially for a BCP
document.  :-)

DBN:  I'm not sure that I can find the most recent text proposed for
Sections 3.1.1, 3.1.2 and 3.1.3.

DBN:  I think it would be useful, however, to insert somewhere among those
sections a bit of text that describes the "level of care" that is expected
for RADIUS attributes, encoded as VSAs, but intended for standardization in
non-IETF SDOs, for use by multiple vendors within an industry segment, or
within the global Internet community.  I would suggest that the design,
review and interoperability guidelines for any such VSAs (what I have called
SSAs) be the same as for full standard RADIUS attributes under IANA
allocation and IETF review.  The review mechanism would differ, but the
criteria should not.

DBN:  Without attempting to specify a particular section, let me suggest
some additional clarifying text:

	"In recognizing the utility of Vendor Specific Attributes (VSAs)
	for defining RADIUS extensions standardized in various SDOs, 
	for use by multiple vendors within an industry segment or within
	the global Internet community, it is important to make a 
	distinction in terms of the expected level of design guideline
	adherence and attention to interoperability considerations.
	The design and specification of VSAs for multi-vendor usages,
	by non-IETF SDOs, should be undertaken with the same level of 
	care as Standard RADIUS attributes.  Specifically, the provisions
	of this document that apply to Standard RADIUS attributes SHOULD
	apply to any such VSAs."

	"In this regard, the term Vendor Specific Attribute is perhaps
	unfortunate.  When used by an SDO, such an attribute is not 
	specific to any singe vendor.  It might be useful to think in 
	terms of two categories of VSAs, one for vendor proprietary 
	features and one for non-IETF standardization.  The latter 
	might be though of as an SDO-Specific Attribute (SSA), which
	just happens to use the same encoding format as the Vendor 
	Specific Attribute."

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

Delivery-date: Thu, 18 Oct 2007 18:28:36 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Bcc: 
Subject: RE: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
Date: Thu, 18 Oct 2007 11:28:14 -0700

With respect to the DISCUSS comments on Section 6.2, it would appear that 
identical text is present in RFC 3579, Section 4.3.7.  Therefore there is no 
need to include Section 6.2 in the document; RFC 3579 can be referenced 
instead.

Similarly, the IESG has also filed DISCUSS comments on text that is included 
in [RFC3579] Section 4.2.  That text has also been deleted.

Deleting the redundant text shortens the document by several pages, and 
should make it more readable.

--
to unsubscribe send a message 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, 18 Oct 2007 18:20:16 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-rfc3576bis-12.txt 
Date: Thu, 18 Oct 2007 14:20:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)       : M. Chiba, et al.
	Filename        : draft-ietf-radext-rfc3576bis-12.txt
	Pages           : 29
	Date            : 2007-10-18

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-12.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-rfc3576bis-12.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-12.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-12.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-12.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-10-18141958.I-D\@ietf.org>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message 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, 18 Oct 2007 18:10:44 +0000
From: "Bernard Aboba" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
Date: Thu, 18 Oct 2007 11:10:07 -0700

Also, RFC 3576bis has normative references to Informational documents (such
as RFC 3579). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bernard Aboba
Sent: Thursday, October 18, 2007 8:50 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis

>I have no objection to it being made standards track.  On the other
>hand, RFC 2866 (accounting) is still informational.  It would be odd to
>have a decade-old core RADIUS feature as informational, and a newer
>feature as standards track.

A bit of RADIUS WG folklore.  RFC 2866 was not allowed on the Standards 
Track because Mike O'Dell pronounced its design "Criminally negligent" 
(mostly due to lack of transport guidance).

There are aspects of RFC 3576's original design which probably merited a 
similar judgment, such as lack of replay protection.  RFC 3576bis doesn't 
outlaw those old practices in order to maintain backward compatibility.

>
> >> (2) The security considerations section on Impersonation (section 6.2)
> >> seem to apply to
> >> implementations of RFC 2865, rather than this specification:
> >>
> >>    To address these vulnerabilities RADIUS proxies one hop from the NAS
> >>    SHOULD check whether NAS identification attributes (see Section 3)
> >>    match the packet source address.  Where one or more attributes do 
>not
> >>
> >> As far as I can tell, the RADIUS proxy that SHOULD perform this check 
>may
> >> be entirely unaware of this specification.  Is that correct?
>
>   Yes.
>
> >> This is a carryover from RFC 3576, so there is no value in blocking the
> >> progression of this specification.
>
>   The text appears identical to RFC 3576, Section 5.2.

Similar text is also included in RFC 3579, Section 4.3.7:

"  To address these vulnerabilities RADIUS proxies SHOULD check whether
   NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
   NAS-Identifier) match the source address of packets originating from
   the NAS.  Where a match is not found, an Access-Reject SHOULD be
   sent, and an error SHOULD be logged."

We could just quote from that.

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

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

Delivery-date: Thu, 18 Oct 2007 17:47:17 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 13:46:10 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   SDO inter-operability is an issue strictly for the SDOs, not 
> for the IETF.

Yes and no.  RADIUS is an IETF protocol.  The IETF has some interest in what
happens to it.  Defining extensions to RADIUS (new attributes) is not
exactly like defining new MIB modules, in that RADIUS has nothing akin to
SMI.  This document is intended to provide guidance for RADIUS attribute
design, much as the MIB design guidelines documents does for new MIB
modules.

I think that the IETF has a role to play in defining such guidelines, and
potentially in providing review of new RADIUS work against these guidelines.
That includes issue of interoperability.  The role of the IETF is therefore
consultative.  That's different from having no role. 

I would call your attention to RFC 4775, BCP 125 "Procedures for Protocol
Extensions and Variations".

--
to unsubscribe send a message 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, 18 Oct 2007 16:56:53 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 12:55:39 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>   I've word-smithed it a little to break up long sentences, and put it
> into a separate section.  I've also changed a "should" to a "may", for
> publication of vendor specifications.  Given the number of vendors,
> there may be dozens of requests for informational RFC's, which is not
> efficient or necessary.

Well, than depends upon whether it's a VSA for a vendor proprietary feature
or a VSA for a non-IETF SDO-standardized feature.  What I call a VSA vs. an
SSA.  I owe you some suggested text to help differentiate these cases, which
I will send under separate cover.

Suffice it to say that we really want VSAs used for SDO-standardized
attributes to be published as an RFC, while we really don't care whether
VSAs used for vendor proprietary attributes are published (unless it's a
sufficiently influential vendor, and the feature becomes a de facto industry
standard).

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

Delivery-date: Thu, 18 Oct 2007 16:34:33 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 12:33:26 -0400
Organization: Elbrys Networks, Inc.

Bernard Aboba writes...

> How about "Rather than self-allocating new values for attribute of
> enumerated type (as described by the Vendor Specific Enumerations
> proposal in [RFC2882] Section 2.2.1), vendors SHOULD obtain an 
> allocation under the IANA guidelines of [RFC3575] Section 2.1. 
> If this is not possible, vendors should allocate an attribute from
> their Vendor-Specific space, and define an appropriate value for
> it."

I agree that this text is better.

I don't think that the VSE, as reported in RFC 2882, is so much a proposal
as it a description of [dubious] behavior observed in the field.  Let's not
go down the path of assuming that RFC 2882 describes desirable behaviors,
for future use, as much as it describes "stupid RADIUS tricks" seen in the
field.

I would go so far as to say "VSE Considered Harmful".

--
to unsubscribe send a message 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, 18 Oct 2007 16:11:04 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: FW: DISCUSS: draft-ietf-radext-rfc3576bis
Date: Thu, 18 Oct 2007 09:10:41 -0700

>Discuss:
>The RFC 2401 IPsec model does not actually support the concept of a
>security policy entry that is "accept protected traffic but don't
>require it."  Some of the suggested policies in the security
>considerations section seem to rely on this.

In large "mixed" deployment, it can be cumbersome to configure IPsec filters 
for every NAS.

>Since we have no mechanism for an application to find out if traffic is 
>protected

That is only necessary if the RADIUS shared secret isn't configured when 
RADIUS/IPsec is used.  Otherwise, the server just checks the incoming 
packets using existing RADIUS security -- it doesn't care if the packet was 
protected by IPsec or not.

In any case, some shipping products do support "traffic protection" 
awareness.

>I don't think that you can actually have a secure setup if you sometimes 
>use IPsec
>with a given source and sometimes do not.

If all  NASes are known to support IPsec, then the server can configure a 
global filter that says "only accept IPsec from these addresses."  However, 
during a transition period the server may be willing to accept either 
conventional RADIUS from some NASes or RADIUS over IPsec.   In that case, 
all the server has to do is carry out existing RADIUS security checks.

>You don't seem to say what IKE authentication modes need to be
>supported. You may get a long way by referring to RFC 4945.

This is covered in RFC 3579, so we could reference that.

>I'm confused by section 6.2.  Does the attack described there actually
>happen if the first-hop proxy uses a different secret for each DAS/NAS
>and confirms that the right secret is used?  I.E. confirms that the NAS
>identity matches the expected NAS identity for the secret?

The attack can still happen if different shared secrets are used if the 
first hop proxy doesn't check the source address against the NAS-Identifier. 
   For example, the NAS could claim to be another NAS in the NAS-Identifier, 
but use the correct (and different) RADIUS shared secret.  When the proxy 
forwards the packet, it has now been "laundered" -- the server can't 
determine whether it came from a "lying NAS" or not.

--
to unsubscribe send a message 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, 18 Oct 2007 15:50:01 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
Date: Thu, 18 Oct 2007 08:49:50 -0700

>I have no objection to it being made standards track.  On the other
>hand, RFC 2866 (accounting) is still informational.  It would be odd to
>have a decade-old core RADIUS feature as informational, and a newer
>feature as standards track.

A bit of RADIUS WG folklore.  RFC 2866 was not allowed on the Standards 
Track because Mike O'Dell pronounced its design "Criminally negligent" 
(mostly due to lack of transport guidance).

There are aspects of RFC 3576's original design which probably merited a 
similar judgment, such as lack of replay protection.  RFC 3576bis doesn't 
outlaw those old practices in order to maintain backward compatibility.

>
> >> (2) The security considerations section on Impersonation (section 6.2)
> >> seem to apply to
> >> implementations of RFC 2865, rather than this specification:
> >>
> >>    To address these vulnerabilities RADIUS proxies one hop from the NAS
> >>    SHOULD check whether NAS identification attributes (see Section 3)
> >>    match the packet source address.  Where one or more attributes do 
>not
> >>
> >> As far as I can tell, the RADIUS proxy that SHOULD perform this check 
>may
> >> be entirely unaware of this specification.  Is that correct?
>
>   Yes.
>
> >> This is a carryover from RFC 3576, so there is no value in blocking the
> >> progression of this specification.
>
>   The text appears identical to RFC 3576, Section 5.2.

Similar text is also included in RFC 3579, Section 4.3.7:

"  To address these vulnerabilities RADIUS proxies SHOULD check whether
   NAS identification attributes (NAS-IP-Address, NAS-IPv6-Address,
   NAS-Identifier) match the source address of packets originating from
   the NAS.  Where a match is not found, an Access-Reject SHOULD be
   sent, and an error SHOULD be logged."

We could just quote from that.

--
to unsubscribe send a message 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, 18 Oct 2007 15:39:40 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Guidelines suggested text for checklist:
Date: Thu, 18 Oct 2007 08:39:08 -0700

>   Because they're poaching on the IANA allocation space.  If a VSE is
>useful, a vendor can update their edge equipment to support
>Vendor-Service-Type, with vendor-specific values.

Right.

>   Suggested replacement text for the two paragraphs:
>
>    Vendor RADIUS Attribute specifications SHOULD allocate attributes
>    from the vendor space, rather than requesting an allocation from the
>    RADIUS standard attribute space.  Vendors are reminded that
>    allocations from the standard space MUST follow the process described
>    in [RFC3575] Section 2.1.  Vendor RADIUS Attribute specifications
>    MUST NOT allocate attributes with vendor-specific meaning from the
>    standard space (i.e. attributes 1 through 255).  Uncoordinated
>    allocations from the standard space would prevent inter-operation
>    with later standards that follow the IETF process.
>...
>    Vendors SHOULD NOT allocate new values for attributes of enumerated
>    type (e.g. Service-Type), despite the Vendor Specific Enumerations
>    proposal in [RFC2882] Section 2.2.1.  Such allocations may only be
>    performed under the guidelines of [RFC3575] Section 2.1.  Instead,
>    vendors SHOULD allocate an attribute from their Vendor-Specific
>    space, and define an appropriate value for it.

Reading the text, I'm still not sure if we want them to create their own new 
VSA or to get a proper IANA allocation.  Most vendors seem to prefer the 
latter, and is to be discouraged, I think we need more explanation about 
why.

How about "Rather than self-allocating new values for attribute of 
enumerated type (as described by the Vendor Specific Enumerations proposal 
in [RFC2882] Section 2.2.1), vendors SHOULD obtain an allocation under the 
IANA guidelines of [RFC3575] Section 2.1.  If this is not possible, vendors 
should allocate an attribute from their Vendor-Specific space, and define an 
appropriate value for it."

--
to unsubscribe send a message 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, 18 Oct 2007 14:33:32 +0000
Content-class: urn:content-classes:message
Subject: FW: DISCUSS: draft-ietf-radext-rfc3576bis 
Date: Thu, 18 Oct 2007 16:31:42 +0200
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: "radext mailing list" <[email-masked]>

=20

=20

-----Original Message-----
From: Sam Hartman [mailto:[email-masked]]=20
Sent: Thursday, October 18, 2007 2:56 PM
To: [email-masked]
Cc: [email-masked]
Subject: DISCUSS: draft-ietf-radext-rfc3576bis=20

Discuss:
The RFC 2401 IPsec model does not actually support the concept of a
security policy entry that is "accept protected traffic but don't
require it."  Some of the suggested policies in the security
considerations section seem to rely on this.  Since we have no mechanism
for an application to find out if traffic is protected, I don't think
that you can actually have a secure setup if you sometimes use IPsec
with a given source and sometimes do not.  Please make the sample
policies consistent with RFC 2401.  Also, please take a look at
draft-bellovin-use-ipsec and include the information specified by that
draft.  You don't seem to say what IKE authentication modes need to be
supported. You may get a long way by referring to RFC 4945.

I'm confused by section 6.2.  Does the attack described there actually
happen if the first-hop proxy uses a different secret for each DAS/NAS
and confirms that the right secret is used?  I.E. confirms that the NAS
identity matches the expected NAS identity for the secret?

--
to unsubscribe send a message 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, 18 Oct 2007 00:03:44 +0000
Date: Thu, 18 Oct 2007 02:03:06 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

Bernard Aboba wrote:
...
>>    Vendor RADIUS Attribute specifications SHOULD allocate attributes
>>    from the vendor space, rather than requesting an allocation from the
>>    RADIUS standard attribute space.  Vendor RADIUS Attribute
>>    specifications MUST NOT allocate attributes from the standard space
>>    (i.e. attributes 1 through 255).
> 
> I would delete the above sentence since we can't change IANA allocation
> policy within a BCP.

  Perhaps that was badly phrased.  The intent isn't to change IANA
allocations.  The intent is to make it clear to vendors that poaching on
the IANA space is wrong.

>>    Vendor allocations from the
>>    standard space would prevent inter-operation with later standards
>>    that follow the IETF process.
> 
> Not if the vendor requested and received an IANA allocation, correct? 

  Correct.

> Or do we mean to say "self-allocate"?

  Yes.  I can clarify the text.

>>    Vendors SHOULD NOT allocate new values for attributes of enumerated
>>    type (e.g. Service-Type), despite the Vendor Specific Enumerations
>>    proposal in [RFC2882] Section 2.2.1.
> 
> I would not specifically mention Service-Type since this has its own
> IANA allocation policy.  Also, we might say more about why VSEs are a
> bad idea elsewhere in the document.

  Because they're poaching on the IANA allocation space.  If a VSE is
useful, a vendor can update their edge equipment to support
Vendor-Service-Type, with vendor-specific values.

  Suggested replacement text for the two paragraphs:

   Vendor RADIUS Attribute specifications SHOULD allocate attributes
   from the vendor space, rather than requesting an allocation from the
   RADIUS standard attribute space.  Vendors are reminded that
   allocations from the standard space MUST follow the process described
   in [RFC3575] Section 2.1.  Vendor RADIUS Attribute specifications
   MUST NOT allocate attributes with vendor-specific meaning from the
   standard space (i.e. attributes 1 through 255).  Uncoordinated
   allocations from the standard space would prevent inter-operation
   with later standards that follow the IETF process.
...
   Vendors SHOULD NOT allocate new values for attributes of enumerated
   type (e.g. Service-Type), despite the Vendor Specific Enumerations
   proposal in [RFC2882] Section 2.2.1.  Such allocations may only be
   performed under the guidelines of [RFC3575] Section 2.1.  Instead,
   vendors SHOULD allocate an attribute from their Vendor-Specific
   space, and define an appropriate value for it.

  I think that's clearer: Allocations from the standard space requires
that the standard process be followed.

  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, 17 Oct 2007 23:38:36 +0000
Date: Thu, 18 Oct 2007 01:37:55 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis

David B. Nelson wrote:
> IESG DISCUSS and COMMENT.
...
>> (1) Paul Hoffman has suggested that standards track would be more
>> appropriate than
>> informational for this specification.  I understand this would necessitate
>> an issue-specific
>> IETF Last Call, but I tend to agree with Paul.  Is there another reason
>> that I am missing
>> to stay at informational?

  I have no objection to it being made standards track.  On the other
hand, RFC 2866 (accounting) is still informational.  It would be odd to
have a decade-old core RADIUS feature as informational, and a newer
feature as standards track.

>> (2) The security considerations section on Impersonation (section 6.2)
>> seem to apply to
>> implementations of RFC 2865, rather than this specification:
>>
>>    To address these vulnerabilities RADIUS proxies one hop from the NAS
>>    SHOULD check whether NAS identification attributes (see Section 3)
>>    match the packet source address.  Where one or more attributes do not
>>
>> As far as I can tell, the RADIUS proxy that SHOULD perform this check may
>> be entirely
>> unaware of this specification.  Is that correct? 

  Yes.

>> This is a carryover from RFC 3567, so there is no value in blocking the
>> progression
>> of this specification.

  The text appears identical to RFC 3576, Section 5.2.

  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, 17 Oct 2007 20:44:57 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis 
Date: Wed, 17 Oct 2007 16:44:21 -0400

IESG DISCUSS and COMMENT.

> -----Original Message-----
> From: Tim Polk [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 4:23 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
> 
> Discuss:
> This is a discuss discuss in two parts.  To be clear, it is not blocking;
> I will clear immediately
> after the document comes up on the agenda.
> 
> (1) Paul Hoffman has suggested that standards track would be more
> appropriate than
> informational for this specification.  I understand this would necessitate
> an issue-specific
> IETF Last Call, but I tend to agree with Paul.  Is there another reason
> that I am missing
> to stay at informational?
> 
> (2) The security considerations section on Impersonation (section 6.2)
> seem to apply to
> implementations of RFC 2865, rather than this specification:
> 
>    To address these vulnerabilities RADIUS proxies one hop from the NAS
>    SHOULD check whether NAS identification attributes (see Section 3)
>    match the packet source address.  Where one or more attributes do not
> 
> As far as I can tell, the RADIUS proxy that SHOULD perform this check may
> be entirely
> unaware of this specification.  Is that correct?  If so, publishing the
> security considerations
> here seems unlikely to have much impact.  (I checked RFC 2685, and these
> considerations
> do not seem to be present.)
> 
> This is a carryover from RFC 3567, so there is no value in blocking the
> progression
> of this specification.  (Besides, the following paragraph notes that this
> check cannot always
> be performed.)  I would like to hear other ADs thoughts on handling this
> sort of situation
> in the future, though.
> 
> Comment:
> The figures in sections 2.1 and 2.2 use Disconnect-Response and CoA-
> Response as shorthand
> for "Disconnect-ACK or Disconnect-NAK" and "CoA-ACK or CoA-NAK"
> respectively.  These
> terms are never defined, and in fact are never used again.  I can't claim
> it was too hard to figure
> out, but it might be better if the meaning was explicitly stated.
> 
> Perhaps the terms could be introduced in the text following the figures
> and implicitly defined
> in a parenthetical, in the same way that "Response packet" was introduced
> in section 2.3:
> 
>            The  Authenticator field in a Response Packet (e.g. Disconnect-
> ACK,
>             Disconnect-NAK, CoA-ACK, or CoA-NAK).

--
to unsubscribe send a message 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, 17 Oct 2007 19:20:30 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-rfc3576bis-11.txt 
Date: Wed, 17 Oct 2007 15:20:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)       : M. Chiba, et al.
	Filename        : draft-ietf-radext-rfc3576bis-11.txt
	Pages           : 33
	Date            : 2007-10-17

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-11.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-rfc3576bis-11.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-11.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-11.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-11.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-10-17151036.I-D\@ietf.org>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message 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, 17 Oct 2007 18:22:23 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: New ISSUE on RADIUS NAS Management Authorization draft
Date: Wed, 17 Oct 2007 14:21:09 -0400
Organization: Elbrys Networks, Inc.

Description of issue
Submitter name: David Harrington
Submitter email address: [email-masked]
Date first submitted: 17-Oct-2007
Reference: https://ops.ietf.org/lists/radiusext/2007/msg00859.html
Document: NAS Management Authorization

Comment type: Technical
Priority: '1' Should fix
Section: 3
Rationale/Explanation of issue:

> > Should netconf be included in the list of framed-protocols?

Requested change:

Comment type: Editorial
Priority: '1' Should fix
Section: 3
Rationale/Explanation of issue:

> > The second paragraph feels a bit rambling.

Comment type: Technical
Priority: '1' Should fix
Section: 4
Rationale/Explanation of issue:

> > "contain the name of a management access rights policy"
> > "containing policy name" can this be more than one policy name?

Comment type: Technical
Priority: '1' Should fix
Section: 5
Rationale/Explanation of issue:

> > Is Transport-Protocol really only valid for the CLI?
> > Should it be named CLI-Transport-Protocol to help make that
> > unambiguous?
> > The examples in section 8 show it applies to more than just CLI.

Comment type: Technical
Priority: '1' Should fix
Section: 7.1
Rationale/Explanation of issue:

> > I have not yet walked through the various combinations of SNMP
> > components (message formats vs. transports).
> > I think SNMP-Transport-Model only covers a small set of 
> > possibilities.  More research is needed on this.

Comment type: Technical
Priority: '1' Should fix
Section: 7.2
Rationale/Explanation of issue:

> > Should this be named Management-Transport-Protocol to differentiate
> > it from other service-related parameters?

> > While we definitely want this with SSH and TLS, is there a case for
> > having this with SNMPv1/UDP and other non-secure transports?

Comment type: Editorial
Priority: '1' Should fix
Section: 7.2
Rationale/Explanation of issue:

> > /managemetn/management/

Comment type: Technical
Priority: '1' Should fix
Section: 7.3
Rationale/Explanation of issue:

> > SNMP does not support sessions, although the transport over which
> > SNMP runs may have sessions.
> > Does the term session here refer to an SNMP session? If so, that is
> > a problem.
> >
> > /NAS SHOULD treat the packet/NAS MUST treat the packet/? Under what
> > circumstances would it be acceptable to not reject?
> >
> > "It is recommended" to use UTF-8. Should UTF-8 support be 
> > mandatory to implement?

Comment type: Editorial
Priority: '1' Should fix
Section: 9
Rationale/Explanation of issue:

> > "what this specification says" and "what is said" seem quaint ways
> > of describing this. Would it be better to specify the sections
> > where things are said, or is this language a common approach for
> > RADIUS-Diameter coordination?

Comment type: Editorial
Priority: '1' Should fix
Section: 10
Rationale/Explanation of issue:

> > /proxy environments/RADIUS proxy environments/ to differentiate
> > this from SNMP proxy environments.

Comment type: Technical
Priority: '1' Should fix
Section: 13
Rationale/Explanation of issue:

> > "within local area networks" - I'm not sure this can be justified.
> > Many protocols originally designed for use only within local area
> > networks actually get used over the Internet. Do we actually have 
> > any mechanism to prevent this from happening, or is it just 
> > recommended that it be restricted to use in a LAN?
> >
> > I think the last paragraph should include a statement at the end,
> > recommending that management protocols should support data access
> > controls to prevent the disclosure of information to help prevent
> > unauthorized management access.

Comment type: Editorial
Priority: '1' Should fix
Section: (various)
Rationale/Explanation of issue:

> > There are mentions of VACM. These should be couched as examples,
> > since SNMP can theoretically support multiple ACMs.

--
to unsubscribe send a message 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, 17 Oct 2007 18:03:33 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: FW: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis 
Date: Wed, 17 Oct 2007 14:02:49 -0400

IESG DISCUSS and GenArt COMMENT.

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 1:41 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: DISCUSS and COMMENT: draft-ietf-radext-rfc3576bis
> 
> Discuss:
> 
>   Includes comments from the Gen-ART Review by Ben Campbell.
> 
>   Section 3, first paragraph, says:
>   >
>   > All NAS and session identification attributes included in a
>   > CoA-Request or Disconnect-Request packet MUST match at least one
>   > session in order for a Request to be successful; otherwise a
>   > Disconnect-NAK or CoA-NAK MUST be sent.
>   >
>   What does it mean for a NAS identification attribute to match a
>   session? I assume we are using the NAS identifiers as a scope in
>   which the session identifiers have meaning, so that all sessions
>   could be considered of having an implied NAS property?  This is
>   ambiguous.  Please clarify.
> 
>   Section 3.1, last paragraph, says:
>   >
>   > Since Disconnect and CoA responses are authenticated on the
>   > entire packet contents, the stripping of the Proxy-State
>   > Attribute invalidates the integrity check - so the proxy needs
>   > to recompute it.
>   >
>   Please say the proxy MUST recompute...
> 
>   Section 3.5, 5th paragraph, says:
>   >
>   > When the HMAC-MD5 message integrity check is calculated the
>   > Request Authenticator field and Message-Authenticator Attribute
>   > should be considered to be sixteen octets of zero.
>   >
>   Both of these are set to 16 zero octets.  That is not clear.
>   Also, please reword to use MUST.
> 
> Comment:
> 
>   From Gen-ART Review by Ben Campbell.
> 
>   In Section 3.2, It would be helpful to mention how Authorize Only
>   is used to ease mapping to Diameter, and reference the Diameter
>   Considerations section.  As it is, the reader wonders what the
>   semantic effect of the resulting Access-Request message is
>   supposed to be.
> 
>   Section 6.2, 4th paragraph, raises a question.  Can a proxy be
>   expected to easily know if it is one-hop away from the NAS?  Is the
>   mechanism for determining this well-known or documented somewhere
>   that could be referenced here?

--
to unsubscribe send a message 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, 17 Oct 2007 16:59:25 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Cc: "'David Harrington'" <[email-masked]>
Subject: FW: review of NAS-MManagement-authroization
Date: Wed, 17 Oct 2007 12:57:43 -0400
Organization: Elbrys Networks, Inc.

> -----Original Message-----
> From: David Harrington [mailto:[email-masked]]
> Sent: Wednesday, October 17, 2007 1:29 AM
> To: 'David B. Nelson'
> Cc: [email-masked]
> Subject: review of NAS-MManagement-authroization
> 
> Hi,
> 
> I'm not sure of the radext ML address. Please forward to radext if it
> isn't [email-masked]
> 
> Overall this document looks good. I strongly support its development.
> A few comments:
> 
> section 3.
> Should netconf be included in the list of framed-protocols?
> 
> The second paragraph feels a bit rambling.
> 
> section 4.
> "contain the name of a management access rights policy"
> "containing policy name"
> can this be more than one policy name?
> 
> section 5
> Is Transport-Protocool really only valid for the CLI?
> Should it be named CLI-Transport-Protocol to help make that
> unambiguous?
> The examples in section 8 show it applies to more than just CLI.
> 
> section 7.1
> I have not yet walked through the various combinations of SNMP
> components (message formats vs transports).
> I think SNMP-Transport-Model only covers a small set of possibilities.
> More research is needed on this.
> 
> section 7.2
> Should this be named MManagement-Transport-Protocol to differentiate
> it from other service-related parameters?
> /managemetn/management/
> 
> While we definitely want this with SSH and TLS, is there a case for
> having this with SNMPv1/UDP and other non-secure transports?
> 
> section 7.3
> SNMP does not support sessions, although the transport over which SNMP
> runs may have sessions.
> Does the term session here refer to an SNMP session? If so, that is a
> problem.
> 
> /NAS SHOULD treat the packet/NAS MUST treat the packet/? Under what
> circumstances would it be acceptable to not reject?
> 
> "It is recommended" to use UTF-8. Should UTF-8 support be mandatory to
> implement?
> 
> section 9
> "what this specification says" and "what is said" seem quaint ways of
> describing this. Would it be better to specify the sections where
> things are said, or is this language a common approach for
> RADIUS-Diameter coordination?
> 
> section 10
> /proxy environments/RADIUS proxy environments/ to differentiate this
> from SNMP proxy environments.
> 
> section 13
> "within local area networks" - I'm not sure this can be justified.
> Many protocols originally designed for use only within local araea
> networks actually get used over the Internet. Do we actually have any
> mechanism to prevent this from happening, or is it just recommended
> that it be restricted to use in a LAN?
> 
> I think the last paragraph should include a statement at the end,
> recommending that management protocols should support data access
> controls to prevent the disclosure of inofrmation to help prevent
> unauthorized management access.
> 
> Throughout
> There are mentions of VACM. These should be couched as examples, since
> SNMP can theoretically support multiple ACMs.
> 
> David Harrington
> [email-masked]
> [email-masked]
> 

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

Delivery-date: Wed, 17 Oct 2007 10:05:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Bcc: 
Subject: Re: Guidelines suggested text for checklist:
Date: Wed, 17 Oct 2007 03:05:45 -0700

>    All other specifications, including new authentication and/or
>    security methods SHOULD be allocated via the standard RADIUS space,
>    via "IETF Consensus" as noted in [RFC3575] Section 2.1.

I would delete "via IETF Consensus" since we're not setting IANA allocations 
policy here.

--
to unsubscribe send a message 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, 17 Oct 2007 10:04:18 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Bcc: 
Subject: Re: Guidelines suggested text for checklist:
Date: Wed, 17 Oct 2007 03:03:36 -0700

>3.1.1.  Vendor Allocations
>
>    Vendor RADIUS Attribute specifications SHOULD allocate attributes
>    from the vendor space, rather than requesting an allocation from the
>    RADIUS standard attribute space.  Vendor RADIUS Attribute
>    specifications MUST NOT allocate attributes from the standard space
>    (i.e. attributes 1 through 255).

I would delete the above sentence since we can't change IANA allocation 
policy within a BCP.

>    Vendor allocations from the
>    standard space would prevent inter-operation with later standards
>    that follow the IETF process.

Not if the vendor requested and received an IANA allocation, correct?  Or do 
we mean to say "self-allocate"?

>
>    As discussed in [RFC2865] Section 5.26, the vendor space is intended
>    for Vendors to support their own extended attributes not suitable for
>    general use.  However, it is RECOMMENDED that Vendors follow the
>    guidelines outlined here, which are intended to enable maximum
>    interoperability with minimal changes to existing systems.
>
>    Following these guidelines means that RADIUS servers can be updated
>    to support the vendor's equipment by editing a RADIUS dictionary.  If
>    these guidelines are not followed, then the vendor's equipment can
>    only be supported via code changes in RADIUS server implementations.
>    Such code changes add complexity and delay to implementations.
>
>    Vendors SHOULD NOT allocate new values for attributes of enumerated
>    type (e.g. Service-Type), despite the Vendor Specific Enumerations
>    proposal in [RFC2882] Section 2.2.1.

I would not specifically mention Service-Type since this has its own IANA 
allocation policy.  Also, we might say more about why VSEs are a bad idea 
elsewhere in the document.

>    Instead, vendors SHOULD
>    allocate an attribute from their Vendor-Specific space, and define an
>    appropriate value to it.
>
>    If Vendors require multi-vendor interoperability for some RADIUS
>    specification, then the guidelines given below for SDO allocations
>    SHOULD be followed.
>
>3.1.2.  SDO Allocations
>
>    SDO RADIUS Attribute specifications SHOULD allocate attributes from
>    the vendor space, rather than requesting an allocation from the
>    RADIUS standard attribute space, for attributes matching any of the
>    following criteria:
>...
>
>   ... as posted previously.
>
>   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, 17 Oct 2007 08:52:20 +0000
Date: Wed, 17 Oct 2007 10:51:46 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

Bernard Aboba wrote:
> I think that the issue of IANA assignment could be addressed more
> explicitly.  How about this?
> 
> "SDOs are encouraged to seek review of VSA specifications by the IETF,
> and once reviewed, to publish them as Informational RFCs, rather than
> requesting IANA allocations within the standard RADIUS attribute
> space.   Vendors wishing to make their specifications publicly available
> should also  request publication of their VSA specifications as
> Informational RFCs by the IETF, rather than requesting IANA allocations
> for proprietary attributes."

  I've word-smithed it a little to break up long sentences, and put it
into a separate section.  I've also changed a "should" to a "may", for
publication of vendor specifications.  Given the number of vendors,
there may be dozens of requests for informational RFC's, which is not
efficient or necessary.

...
3.1.3.  Publication of specifications

   SDOs are encouraged to seek review of VSA specifications by the IETF.
   Once reviewed, the specifications may be published as Informational
   RFCs.  This process should be followed instead of requesting IANA
   allocations from within the standard RADIUS attribute space.  Vendors
   wishing to make their specifications publicly available may also
   request publication of their VSA specifications as Informational RFCs
   by the IETF, instead of requesting IANA allocations for proprietary
   attributes

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

  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, 17 Oct 2007 07:16:53 +0000
From: Mike McCauley <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: RFC3580 Clarification / Tunnel-Medium-Type / Clarification
Date: Wed, 17 Oct 2007 17:16:17 +1000
Cc: Alan DeKok <[email-masked]>, "Connault, Jean-Fabien" <[email-masked]>

On Wednesday 17 October 2007 16:23, Alan DeKok wrote:
> Connault, Jean-Fabien wrote:
> > Could someone please clarify the value being sent back through the
> > Tunnel-Medium-Type RADIUS attribute?
> > .......
> > It appears that some RADIUS servers are sending back 802 while others
> > are sending back 6. Does anyone have a list of which RADIUS server is
> > sending which value?

I can tell you that Radiator sends 6.

Cheers.

>
>   It's not just the server.  Many servers permit the value for
> enumerated types to be given as integers, in addition to names.  This is
> for non-standard and/or local extensions.  So "802" is a valid value, as
> is 803, 804, 805....
>
>   Administrators can enter integer values manually, and cause the server
> to send back non-standard values, even if the dictionary contains a
> non-integer name such as "IEEE-802".
>
>   My $0.02 is that the client should accept both 802 (because it's not
> used elsewhere, and it's a common problem), and 6.
>
>   I also think that the guidelines document could be updated with a
> sentence or two on naming values: Names for enumerated values SHOULD NOT
> be integers, as it results in precisely this kind of confusion.
>
>   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/>

-- 
Mike McCauley                               [email-masked]
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

Radiator: the most portable, flexible and configurable RADIUS server 
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, 
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, 
TTLS, PEAP etc on Unix, Windows, MacOS, NetWare etc.

--
to unsubscribe send a message 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, 17 Oct 2007 06:24:20 +0000
Date: Wed, 17 Oct 2007 08:23:13 +0200
From: Alan DeKok <[email-masked]>
To: "Connault, Jean-Fabien" <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: RFC3580 Clarification / Tunnel-Medium-Type / Clarification

Connault, Jean-Fabien wrote:
> Could someone please clarify the value being sent back through the
> Tunnel-Medium-Type RADIUS attribute?
> 
> RFC3580 states as follow:
> 
> Tunnel-Type=VLAN (13)
> Tunnel-Medium-Type=802
> Tunnel-Private-Group-ID=VLANID
> 
> So it seems that the integer value is 802, but in other places the 6
> value is listed, so it appears that "(6)" has been left out and that it
> should be "Tunnel-Medium-Type=802 (6)".

  I agree.  I this context, 802 is a name, not an integer value.

>>From a RADIUS client (switch here) perspective, should we support both 802 and
> 6 integer values? Probably yes.

  Ugh.  Yes, that's likely.

> It appears that some RADIUS servers are sending back 802 while others
> are sending back 6. Does anyone have a list of which RADIUS server is
> sending which value?

  It's not just the server.  Many servers permit the value for
enumerated types to be given as integers, in addition to names.  This is
for non-standard and/or local extensions.  So "802" is a valid value, as
is 803, 804, 805....

  Administrators can enter integer values manually, and cause the server
to send back non-standard values, even if the dictionary contains a
non-integer name such as "IEEE-802".

  My $0.02 is that the client should accept both 802 (because it's not
used elsewhere, and it's a common problem), and 6.

  I also think that the guidelines document could be updated with a
sentence or two on naming values: Names for enumerated values SHOULD NOT
be integers, as it results in precisely this kind of confusion.

  Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 20:30:23 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 16:29:16 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>  It's substantially the same as the last draft.

Yeah, but I substantially complained about it before:
http://ops.ietf.org/lists/radiusext/2007/msg00788.html  :-)

>   I await your suggestion.

Thanks.  I'll send my suggestion in the next day (or two).

--
to unsubscribe send a message 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, 16 Oct 2007 19:52:29 +0000
From: "Connault, Jean-Fabien" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 16 Oct 2007 15:51:28 -0400
Subject: RFC3580 Clarification / Tunnel-Medium-Type / Clarification
Accept-Language: en-US
acceptlanguage: en-US

--_000_508FE7926BB2734AB141E0D27F7463421F565A41e2k7mbx2etsente_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

Could someone please clarify the value being sent back through the Tunnel-M=
edium-Type RADIUS attribute?

RFC3580 states as follow:

Tunnel-Type=3DVLAN (13)
Tunnel-Medium-Type=3D802
Tunnel-Private-Group-ID=3DVLANID

So it seems that the integer value is 802, but in other places the 6 value =
is listed, so it appears that "(6)" has been left out and that it should be=
 "Tunnel-Medium-Type=3D802 (6)".

>From a RADIUS client (switch here) perspective, should we support both 802 =
and 6 integer values? Probably yes.

It appears that some RADIUS servers are sending back 802 while others are s=
ending back 6. Does anyone have a list of which RADIUS server is sending wh=
ich value?

Thanks.

JEFF

Jean-Fabien Connault
Enterasys Networks

--_000_508FE7926BB2734AB141E0D27F7463421F565A41e2k7mbx2etsente_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m=
icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office=
:access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"=
uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof=
t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co=
m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee=
t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.w3.org/TR/REC-html40" xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope=
/" xmlns:D=3D"DAV:" xmlns:x2=3D"http://schemas.microsoft.com/office/excel/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sps=3D"http://schemas=
.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSch=
ema-instance" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile"=
 xmlns:wf=3D"http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:=
mver=3D"http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:=
m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels=3D"http:=
//schemas.openxmlformats.org/package/2006/relationships" xmlns:ex12t=3D"htt=
p://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m=3D"http=
://schemas.microsoft.com/exchange/services/2006/messages" xmlns=3D"http://w=
ww.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"=
>
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Courier New";
	color:windowtext;
	font-weight:normal;
	font-style:normal;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'>Hi,<br>
<br>
Could someone please clarify the value being sent back through the
Tunnel-Medium-Type RADIUS attribute?<br>
<br>
RFC3580 states as follow:<br>
<br>
Tunnel-Type=3DVLAN (13)<br>
Tunnel-Medium-Type=3D802<br>
Tunnel-Private-Group-ID=3DVLANID<br>
<br>
So it seems that the integer value is 802, but in other places the 6 value =
is
listed, so it appears that &quot;(6)&quot; has been left out and that it sh=
ould
be &quot;Tunnel-Medium-Type=3D802 (6)&quot;.<br>
<br>
>From a RADIUS client (switch here) perspective, should we support both 802 =
and
6 integer values? Probably yes.<br>
<br>
It appears that some RADIUS servers are sending back 802 while others are
sending back 6. Does anyone have a list of which RADIUS server is sending w=
hich
value?<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-family:"Courier New"'><br>
Thanks.<br>
<br>
JEFF<br>
<br>
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-family:"Courier New"'>Je=
an-Fabien
Connault<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DFR style=3D'font-family:"Courier New"'>En=
terasys
Networks<o:p></o:p></span></p>

</div>

</body>

</html>

--_000_508FE7926BB2734AB141E0D27F7463421F565A41e2k7mbx2etsente_--

--
to unsubscribe send a message 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, 16 Oct 2007 17:09:59 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Bcc: 
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 10:09:50 -0700

Looks good to me, too.

>From: "David B. Nelson" <[email-masked]>
>To: "'radext mailing list'" <[email-masked]>
>Subject: RE: Guidelines suggested text for checklist:
>Date: Tue, 16 Oct 2007 09:01:34 -0400
>
>Alan DeKok writes...
>
> >   Suggested text (long quote for context)
> >
> >    Code changes can also be required in the RADIUS server's receive
> >    path, due to limitations in RADIUS server policy languages, which
> >    typically only provide for limited operations (such as comparisons or
> >    arithmetic operations) on the basic data types.  Most existing RADIUS
> >    policy languages typically are not capable of parsing sub-elements,
> >    or providing sophisticated matching functionality.
> >
> >    Given these limitations, the introduction of complex attributes can
> >    require code changes on the RADIUS server which would be unnecessary
> >    if basic data types had been used instead.  In addition, attribute-
> >    specific parsing means more complex software to develop and maintain.
> >    More complexity can lead to more error prone implementations, and
> >    inter-operatibility problems.  This issues can increase costs to
> >    network administrators as well as reducing reliability and
> >    introducing deployment barriers.  As a result, the introduction of
> >    new complex data types within RADIUS attribute specifications SHOULD
> >    be avoided.
> >
> >    The exception to this recommendation is for complex types that can be
> >    treated as opaque data by the RADIUS server.  For example, the EAP-
> >    Message attribute, defined in [RFC3579] Section 3.1 contains a
> >    complex data type that is an EAP packet.  Since these complex types
> >    do not need to be parsed by the RADIUS server, the issues arising
> >    from policy language limitations do not arise.  Similarly, since
> >    attributes of these complex types can be configured on the server
> >    using a data type of String, dictionary limitations are also not
> >    encountered.  Appendix A includes a series of checklists that may be
> >    used to analyze a design for RECOMMENDED and NOT RECOMMENDED
> >    behavior.
> >
> >    If the RADIUS Server simply passes the contents of an attribute to
> >    some non-RADIUS portion of the network, then the data is opaque, and
> >    SHOULD be defined to be of type "string".  A concrete way of judging
> >    this requirement is whether or not the attribute definition in the
> >    RADIUS document contains delineated fields for sub-parts of the data.
> >    If fields need to be delineated in RADIUS, then the data is not
> >    opaque, and it SHOULD be separated into individual RADIUS attributes.
> >
> >    An examination of existing RADIUS RFCs discloses a number of complex
> >    attributes that have already been defined.  Appendix B includes a
> >    listing of complex attributes utilized within [RFC2865], [RFC2868],
> >    [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
> >    these attributes includes reasons why a complex type is acceptable,
> >    or suggestions for how the attribute could have followed the RADIUS
> >    data model.
> >
> >    As can be seen in Appendix B, most of the complex attributes involve
> >    authentication or security functionality.  Supporting this
> >    functionality requires code changes on both the RADIUS client and
> >    server, regardless of the attribute format.  As a result, in most
> >    cases, the use of complex attributes to represent these methods is
> >    acceptable, and does not create additional interoperability or
> >    deployment issues.
>
>Excellent!
>
> >   Suggested text:
> >
> > 2.1.4.  Service definitions and RADIUS
> >
> >    New specifications SHOULD avoid defining message formats for services
> >    inside a RADIUS document.  In addition, the service being provisioned
> >    SHOULD NOT be defined in a RADIUS specification.  RADIUS attributes
> >    are intended to
> >
> >       * authenticate users
> >       * authorize users (i.e. service provisioning or changes to
> >         provisioning)
> >       * account for user activity (i.e. logging of session activity)
> >
> >    RADIUS also SHOULD NOT be extended to new commands via attributes.
> >    New commands (i.e. the Code field in the packet header) are allocated
> >    only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
> >    Specifications SHOULD NOT use new attributes to modify the
> >    interpretation of existing RADIUS commands.
> >
> >    For new services using RADIUS, the service SHOULD be defined
> >    elsewhere, and provisioned in RADIUS.
>
>This looks good to me.
>
>
>
>
>--
>to unsubscribe send 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, 16 Oct 2007 17:06:25 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 10:05:51 -0700

>   Suggested text:
>
>    SDOs are encouraged to submit their RADIUS specifications to the IETF
>    for publication as an informational RFC.  Vendors defining Vendor-
>    Specific dictionaries for their own use SHOULD make their
>    specification publicly available, but there is no need to publish
>    their specification as an RFC.
>
>   i.e. IANA should do nothing in either case.

I think that the issue of IANA assignment could be addressed more 
explicitly.  How about this?

"SDOs are encouraged to seek review of VSA specifications by the IETF, and 
once reviewed, to publish them as Informational RFCs, rather than requesting 
IANA allocations within the standard RADIUS attribute space.   Vendors 
wishing to make their specifications publicly available should also  request 
publication of their VSA specifications as Informational RFCs by the IETF, 
rather than requesting IANA allocations for proprietary attributes."

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

Delivery-date: Tue, 16 Oct 2007 15:43:28 +0000
Date: Tue, 16 Oct 2007 17:42:33 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
> Alan DeKok writes...
...
>>       * attributes defined by vendors and not suitable for general use,
>>         as per [RFC2865] Section 5.26.
>>       * attributes relying on data types not defined within RADIUS
>>       * attributes intended primarily for use within an SDO
>>       * attributes intended primarily for use within a group of SDOs.
> 
> I find this text very troubling.

  It's substantially the same as the least draft.

>  It infers that one type of
> interoperability is required for use in IETF documents (i.e. global Internet
> usage) while something less is required for other SDOs.  What is the IETF,
> after all, but yet another SDO?  We even slight "groups of SDOs".  I think
> this is highly inappropriate.

  No... it means that the IETF does not assert change control over SDO
specifications.  Given 3GPP2, WiMAX, etc. extensions of the RADIUS data
model, it makes sense to acknowledge this reality.

> If what we are trying to say is something like "If you're not doing this
> work in the IETF, we don't want to share our IANA-assigned code points with
> you.", then maybe I understand where this coming from.  (Still don't like
> it, though.)

  Yes, that's true, too.  The standard RADIUS attribute space is
available for allocation through IANA, which requires publication of
specifications via the IETF process, as per RFC 3575.

  Why is this problematic?

> I think we need to be very careful here.  The general implication that I
> take away from the juxtaposition of:
> 
>>       * attributes defined by vendors and not suitable for general use,
>>         as per [RFC2865] Section 5.26.
> 
> with
> 
>>       * attributes intended primarily for use within an SDO
>>       * attributes intended primarily for use within a group of SDOs.
> 
> Is that we think that the work done is other SDOs is less serious that the
> work done in the IETF, and need not be done with as much care.  That
> inference bothers me very much.

  Text can be added to clarify this.  How about the following text added
just after that list above:

   The recommendation for SDOs to allocate attributes from a vendor
   space rather than via IETF process is a recognition that SDOs may
   desire to assert change control over their own RADIUS specifications.
   This change control can be obtained by requesting a Private
   Enterprise Number (PEN) from the Internet Assigned Number Authority
   (IANA), for use as a Vendor id within a Vendor-Specific attribute.
   Further allocation of attributes inside of the VSA space defined by
   that Vendor id is subject solely to the discretion of the SDO.
   Similarly, the use of data types (complex or not) within that VSA
   space is solely under the discretion of the SDO.  It is RECOMMENDED
   that SDOs follow the guidelines outlined here, which are intended to
   enable maximum interoperability with minimal changes to existing
   systems.

>>    All other specifications, including new authentication and/or
>>    security methods SHOULD be allocated via the standard RADIUS space,
>>    via "IETF Consensus" as noted in [RFC3575] Section 2.1.
> 
> If what we are trying to accomplish is to carve out of the traditional VSA,
> something more akin to a Standard Attribute, in terms of rigor of design and
> scope of applicability, then I think we need better text.

  I'd like to add suggestions for rigor.  Failing that, pointing out
bone-headed mistakes would be sufficient.

>  A few years ago,
> I was promoting use of the term "SDO Specific Attribute" (SSA), to highlight
> the distinction between VSAs defined for proprietary vendor features and
> VSAs (SSAs) defined by SDOs for multi-vendor interoperability within an
> industry segment, or more globally for wide spread LAN or Internet usage.
> That term never quite caught on.  I think that making the distinction is
> important, however, and even if we don't like coining a new term, I think
> the text needs to mode clearly delineate the usage distinctions.

  It sounds like a reasonable term to me.

> If there is general agreement with this philosophy, I'll volunteer to
> suggest some specific text.

  I await your suggestion.

  Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 13:08:36 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 09:08:15 -0400

Alan DeKok writes...

>   Suggested text:
> 
>    SDOs are encouraged to submit their RADIUS specifications to the IETF
>    for publication as an informational RFC.  Vendors defining Vendor-
>    Specific dictionaries for their own use SHOULD make their
>    specification publicly available, but there is no need to publish
>    their specification as an RFC.

I think that text is fine.  It doesn't address the decision to undertake the
work in the IETF or in another SDO, but that is really outside the scope of
this document.

However, please see my recent posting about the "beefing up" the distinction
between requirements for Standard Attributes and Vendor Specific Attributes,
when the VSAs are to expected to exhibit for multi-vendor interoperability.
I would always expect that to be case whether the work is done in the IETF
or in another SDO.

--
to unsubscribe send a message 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, 16 Oct 2007 13:05:49 +0000
From: "David B. Nelson" <[email-masked]>
To: "'radext mailing list'" <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 09:01:34 -0400

Alan DeKok writes...

>   Suggested text (long quote for context)
> 
>    Code changes can also be required in the RADIUS server's receive
>    path, due to limitations in RADIUS server policy languages, which
>    typically only provide for limited operations (such as comparisons or
>    arithmetic operations) on the basic data types.  Most existing RADIUS
>    policy languages typically are not capable of parsing sub-elements,
>    or providing sophisticated matching functionality.
> 
>    Given these limitations, the introduction of complex attributes can
>    require code changes on the RADIUS server which would be unnecessary
>    if basic data types had been used instead.  In addition, attribute-
>    specific parsing means more complex software to develop and maintain.
>    More complexity can lead to more error prone implementations, and
>    inter-operatibility problems.  This issues can increase costs to
>    network administrators as well as reducing reliability and
>    introducing deployment barriers.  As a result, the introduction of
>    new complex data types within RADIUS attribute specifications SHOULD
>    be avoided.
> 
>    The exception to this recommendation is for complex types that can be
>    treated as opaque data by the RADIUS server.  For example, the EAP-
>    Message attribute, defined in [RFC3579] Section 3.1 contains a
>    complex data type that is an EAP packet.  Since these complex types
>    do not need to be parsed by the RADIUS server, the issues arising
>    from policy language limitations do not arise.  Similarly, since
>    attributes of these complex types can be configured on the server
>    using a data type of String, dictionary limitations are also not
>    encountered.  Appendix A includes a series of checklists that may be
>    used to analyze a design for RECOMMENDED and NOT RECOMMENDED
>    behavior.
> 
>    If the RADIUS Server simply passes the contents of an attribute to
>    some non-RADIUS portion of the network, then the data is opaque, and
>    SHOULD be defined to be of type "string".  A concrete way of judging
>    this requirement is whether or not the attribute definition in the
>    RADIUS document contains delineated fields for sub-parts of the data.
>    If fields need to be delineated in RADIUS, then the data is not
>    opaque, and it SHOULD be separated into individual RADIUS attributes.
> 
>    An examination of existing RADIUS RFCs discloses a number of complex
>    attributes that have already been defined.  Appendix B includes a
>    listing of complex attributes utilized within [RFC2865], [RFC2868],
>    [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
>    these attributes includes reasons why a complex type is acceptable,
>    or suggestions for how the attribute could have followed the RADIUS
>    data model.
> 
>    As can be seen in Appendix B, most of the complex attributes involve
>    authentication or security functionality.  Supporting this
>    functionality requires code changes on both the RADIUS client and
>    server, regardless of the attribute format.  As a result, in most
>    cases, the use of complex attributes to represent these methods is
>    acceptable, and does not create additional interoperability or
>    deployment issues.

Excellent!

>   Suggested text:
> 
> 2.1.4.  Service definitions and RADIUS
> 
>    New specifications SHOULD avoid defining message formats for services
>    inside a RADIUS document.  In addition, the service being provisioned
>    SHOULD NOT be defined in a RADIUS specification.  RADIUS attributes
>    are intended to
> 
>       * authenticate users
>       * authorize users (i.e. service provisioning or changes to
>         provisioning)
>       * account for user activity (i.e. logging of session activity)
> 
>    RADIUS also SHOULD NOT be extended to new commands via attributes.
>    New commands (i.e. the Code field in the packet header) are allocated
>    only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
>    Specifications SHOULD NOT use new attributes to modify the
>    interpretation of existing RADIUS commands.
> 
>    For new services using RADIUS, the service SHOULD be defined
>    elsewhere, and provisioned in RADIUS.

This looks good to me.

--
to unsubscribe send a message 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, 16 Oct 2007 12:54:19 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 08:53:59 -0400

Alan DeKok writes...

>   Suggested text:
> 
>    In particular, RADIUS Attribute specifications SHOULD allocate
>    attributes from the vendor space, rather than requesting an
>    allocation from the RADIUS standard attribute space, for attributes
>    matching any of the following criteria:
> 
>       * attributes defined by vendors and not suitable for general use,
>         as per [RFC2865] Section 5.26.
>       * attributes relying on data types not defined within RADIUS
>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.

I find this text very troubling.  It infers that one type of
interoperability is required for use in IETF documents (i.e. global Internet
usage) while something less is required for other SDOs.  What is the IETF,
after all, but yet another SDO?  We even slight "groups of SDOs".  I think
this is highly inappropriate.

If what we are trying to say is something like "If you're not doing this
work in the IETF, we don't want to share our IANA-assigned code points with
you.", then maybe I understand where this coming from.  (Still don't like
it, though.)

I think we need to be very careful here.  The general implication that I
take away from the juxtaposition of:

>       * attributes defined by vendors and not suitable for general use,
>         as per [RFC2865] Section 5.26.

with

>       * attributes intended primarily for use within an SDO
>       * attributes intended primarily for use within a group of SDOs.

Is that we think that the work done is other SDOs is less serious that the
work done in the IETF, and need not be done with as much care.  That
inference bothers me very much.

>    SDOs are encouraged to submit their RADIUS specifications to the IETF
>    for publication as an informational RFC.  Vendors defining Vendor-
>    Specific dictionaries for their own use SHOULD make their
>    specification publicly available, but there is no need to publish
>    their specification as an RFC.
> 
>    All other specifications, including new authentication and/or
>    security methods SHOULD be allocated via the standard RADIUS space,
>    via "IETF Consensus" as noted in [RFC3575] Section 2.1.

If what we are trying to accomplish is to carve out of the traditional VSA,
something more akin to a Standard Attribute, in terms of rigor of design and
scope of applicability, then I think we need better text.  A few years ago,
I was promoting use of the term "SDO Specific Attribute" (SSA), to highlight
the distinction between VSAs defined for proprietary vendor features and
VSAs (SSAs) defined by SDOs for multi-vendor interoperability within an
industry segment, or more globally for wide spread LAN or Internet usage.
That term never quite caught on.  I think that making the distinction is
important, however, and even if we don't like coining a new term, I think
the text needs to mode clearly delineate the usage distinctions.

If there is general agreement with this philosophy, I'll volunteer to
suggest some specific text.

--
to unsubscribe send a message 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, 16 Oct 2007 12:20:35 +0000
Date: Tue, 16 Oct 2007 14:19:40 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
>> As long as a VSA conforms to the checklist, it can be added to 
>> existing RADIUS servers, so that there is no reason for the IETF to 
>> force the SDO to use the RADIUS standard space solely in order to 
>> get the document reviewed.
> 
> Sure, but that still doesn't tell me as a reader of this guideline when to
> use a VSA allocation and when to use an IANA allocation.  Do I use an IANA
> allocation only when publishing my new attribute via the IETF?

  Suggested text:

   SDOs are encouraged to submit their RADIUS specifications to the IETF
   for publication as an informational RFC.  Vendors defining Vendor-
   Specific dictionaries for their own use SHOULD make their
   specification publicly available, but there is no need to publish
   their specification as an RFC.

  i.e. IANA should do nothing in either case.

  Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 12:19:21 +0000
Date: Tue, 16 Oct 2007 14:18:18 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'radext mailing list' <[email-masked]>
Subject: Re: Guidelines suggested text for checklist:

David B. Nelson wrote:
>>       * string (i.e. binary data), totalling 253 octets or less in
>>         length. This includes the opaque encapsulation of data
>>         structures defined outside of RADIUS.
> 
> I think it might make sense to add some text in the body of the document to
> expand on the notion of "opaque encapsulation of data structures defined
> outside of RADIUS".

  Suggested text (long quote for context)

   Code changes can also be required in the RADIUS server's receive
   path, due to limitations in RADIUS server policy languages, which
   typically only provide for limited operations (such as comparisons or
   arithmetic operations) on the basic data types.  Most existing RADIUS
   policy languages typically are not capable of parsing sub-elements,
   or providing sophisticated matching functionality.

   Given these limitations, the introduction of complex attributes can
   require code changes on the RADIUS server which would be unnecessary
   if basic data types had been used instead.  In addition, attribute-
   specific parsing means more complex software to develop and maintain.
   More complexity can lead to more error prone implementations, and
   inter-operatibility problems.  This issues can increase costs to
   network administrators as well as reducing reliability and
   introducing deployment barriers.  As a result, the introduction of
   new complex data types within RADIUS attribute specifications SHOULD
   be avoided.

   The exception to this recommendation is for complex types that can be
   treated as opaque data by the RADIUS server.  For example, the EAP-
   Message attribute, defined in [RFC3579] Section 3.1 contains a
   complex data type that is an EAP packet.  Since these complex types
   do not need to be parsed by the RADIUS server, the issues arising
   from policy language limitations do not arise.  Similarly, since
   attributes of these complex types can be configured on the server
   using a data type of String, dictionary limitations are also not
   encountered.  Appendix A includes a series of checklists that may be
   used to analyze a design for RECOMMENDED and NOT RECOMMENDED
   behavior.

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type "string".  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

   An examination of existing RADIUS RFCs discloses a number of complex
   attributes that have already been defined.  Appendix B includes a
   listing of complex attributes utilized within [RFC2865], [RFC2868],
   [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
   these attributes includes reasons why a complex type is acceptable,
   or suggestions for how the attribute could have followed the RADIUS
   data model.

   As can be seen in Appendix B, most of the complex attributes involve
   authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

> What should clearly be avoided is defining message formats for services
> inside a RADIUS document.  RADIUS attributes are for (a) authenticating
> users, (b) service provisioning and (c) accounting logging.  We want to be
> careful that the service being provisioned isn't being _defined_ in a RADIUS
> document.  Define it elsewhere, and provision it in RADIUS.

  Suggested text:

2.1.4.  Service definitions and RADIUS

   New specifications SHOULD avoid defining message formats for services
   inside a RADIUS document.  In addition, the service being provisioned
   SHOULD NOT be defined in a RADIUS specification.  RADIUS attributes
   are intended to

      * authenticate users
      * authorize users (i.e. service provisioning or changes to
        provisioning)
      * account for user activity (i.e. logging of session activity)

   RADIUS also SHOULD NOT be extended to new commands via attributes.
   New commands (i.e. the Code field in the packet header) are allocated
   only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
   Specifications SHOULD NOT use new attributes to modify the
   interpretation of existing RADIUS commands.

   For new services using RADIUS, the service SHOULD be defined
   elsewhere, and provisioned in RADIUS.

> At one point we had come to consensus on the list about some criteria for
> the use of "opaque encapsulations".  IIRC, the criteria hinged on whether
> the RADIUS Server would need to take any action based on the purportedly
> opaque information.  If it would, then the information didn't qualify for
> treatment as an "opaque encapsulation".  If the RADIUS Server simply passed
> the data to some "plug-in" module, and relied on a result from the "plug-in"
> module to make a decision, then the data is opaque.  A concrete way of
> judging this is whether the attribute definition in the RADIUS document
> contains delineated fields for sub-parts of the data.  If fields need to be
> delineated, then the data is not opaque.

  See long quote above.

  Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 12:16:38 +0000
Date: Tue, 16 Oct 2007 14:15:40 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

Bernard Aboba wrote:
> I think that the issue is that there is no inherent interoperability
> benefit from rehosting VSAs that already conform to the criteria
> expressed in the document into the RADIUS standard attribute space.
> Creating two ways to express the same attribute does not help
> interoperability -- it hurts it.  As long as a VSA conforms to the
> checklist, it can be added to existing RADIUS servers, so that there is
> no reason for the IETF to force the SDO to use the RADIUS standard space
> solely in order to get the document reviewed.

  Suggested text:

   In particular, RADIUS Attribute specifications SHOULD allocate
   attributes from the vendor space, rather than requesting an
   allocation from the RADIUS standard attribute space, for attributes
   matching any of the following criteria:

      * attributes defined by vendors and not suitable for general use,
        as per [RFC2865] Section 5.26.
      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   SDOs are encouraged to submit their RADIUS specifications to the IETF
   for publication as an informational RFC.  Vendors defining Vendor-
   Specific dictionaries for their own use SHOULD make their
   specification publicly available, but there is no need to publish
   their specification as an RFC.

   All other specifications, including new authentication and/or
   security methods SHOULD be allocated via the standard RADIUS space,
   via "IETF Consensus" as noted in [RFC3575] Section 2.1.

 Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 12:07:40 +0000
Date: Tue, 16 Oct 2007 14:06:13 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: Guidelines suggested text for checklist:

  After some weeks...

Bernard Aboba wrote:
> For a checklist, I was think of a list of questions, with references to
> the document itself.  So I'd prefer that this list not be repeated
> twice.  Instead you could say "Does the attribute match a type described
> in Section X?"

  I've updated the document to follow that suggestion:

   Does the data fit within the existing RADIUS data model, as outlined
   below?  If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA.

>>    For [RFC2865] RADIUS VSAs, the length limitation of the "string" and
>>    "text" types is 247 octets instead of 253 octets, due to the
>>    additional information included in the Vendor-Specific attribute.
> 
> This sentence should probably be in the main text.

  Done.

>> A.2. Transport of new authentication protocols
>>
>>    New authentication or security functionality in RADIUS requires
>>    require code changes on both the RADIUS client and server, regardless
>>    of the attribute format.  As a result, in most cases the use of
>>    complex attributes to represent these methods is acceptable.
> 
> This statement should be moved to the main text.  Here you could put the
> question "Does the attribute define a complex data type for purposes
> other than authentication or security?  See Section Y for a description
> of why this is problematic."

  Text:

   As can be seen in Appendix B, most of the complex attributes involve
   authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

  Appendix:

   Does the attribute define a complex data type for purposes other than
   authentication or security?  If so, this data type SHOULD be replaced
   with simpler types, as discussed above in Section A.2.1.  Also see
   Section 2.1.3 for a discussion of why complex types are problematic.

>> A.3. Improper data types
...
> I'd consolidate this with the previous data type section, and rephrase
> as a question:
> "Does the attribute use any of the following data types?"
> 
> Example:
> 
> * Signed integers of any size?  These SHOULD NOT be used.

  Having per-type questions is fatiguing for the reader.  How about this:

   Does the attribute use any of the following data types?  If so, the
   data type SHOULD be replaced with the suggested alternatives, or
   SHOULD NOT be used at all.

      * Signed integers of any size.
        SHOULD NOT be used.  SHOULD be replaced with one or more
        unsigned integer attributes.  The definition of the attribute
        can contain information that would otherwise go into the sign
        value of the integer.
  ...

>> A.4. Vendor-Specific formats
...
> Large SDOs with multiple groups would probably do better with a 16-bit
> attribute space.  Given this, is the suggested format still a SHOULD, or
> do we say "suggested format, using an 8 or 16-bit attribute space."

  Text:

   Also, an SDO can be comprised of multiple subgroups,
   each of whom can desire autonomy over the definition of attributes
   within their group.  In such a situation, a 16-bit Vendor type field
   would be more appropriate:

  Appendix:

   We recognize that SDOs may require more than 256 attributes, which is
   the limit of the 8-bit [RFC2865] Vendor-Specific space.  Those SDOs
   SHOULD use Vendor types of 16 bits.  However, SDOs SHOULD NOT use
   Vendor types of 16 bits unless there are immediate requirements.
   Future-proofing a specification is insufficient grounds for using
   16-bit Vendor types.

>> A.5. New functionality in RADIUS.
...
> Since the document is about attributes, I think this should say
> "Defining new RADIUS commands using attributes."  We're not talking
> about restricting new standards-track documents defining new commands
> (e.g. RFC 3576).

  Text:

   RADIUS also SHOULD NOT be extended to new commands via attributes.
   New commands (i.e. the Code field in the packet header) are allocated
   only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
   Specifications SHOULD NOT use new attributes to modify the
   interpretation of existing RADIUS commands.

>>       * Using RADIUS as a transport protocol.
>>         This restriction is partially a subset of the previous one.
>>         Note that using RADIUS to transport authentication methods
>>         (e.g. EAP) is explicitly permitted, even if those methods
>>         require the transport of relatively large amounts of data.
> 
> Since the focus is on attributes, I'm not sure what this refers to. 
> Would this apply to the GEOPRIV document, for example?

  No.  It's for people who decide "well, we have a protocol between A
and B, we might as well overload it to do something else..."

  Maybe saying "... transport protocol for non-AAA data" would be better.

>>       * attributes relying on data types not defined within RADIUS
>>       * attributes intended primarily for use within an SDO
>>       * attributes intended primarily for use within a group of SDOs.
> 
> This duplicates existing text, so I'd rephrase as a question:  "Does the
> attribute match any of the following critiera?  If so, then...."

  Updated and clarified:

   Does the attribute have a limited scope of applicability, as outlined
   below?  If so, then the attributes SHOULD be allocated from the
   Vendor-Specific space.

      * attributes relying on data types not defined within RADIUS
      * attributes intended primarily for use within an SDO
      * attributes intended primarily for use within a group of SDOs.

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead, they recognize that the RADIUS
   data model has limitations.  In certain situations where inter-
   operability can be strongly constrained, a data model extended by the
   SDO or vendor MAY be used.  We recommend, however, that the RADIUS
   data model SHOULD be used, even if it is marginally less efficient
   than alternatives.

  Alan DeKok.

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

Delivery-date: Tue, 16 Oct 2007 10:01:22 +0000
From: Stefan Winter <[email-masked]>
Organization: Fondation RESTENA
To: [email-masked]
Subject: F'up IETF69: Patents on RADIUS over TCP and TLS?
Date: Tue, 16 Oct 2007 12:01:24 +0200

--nextPart3236002.iY925FeMa0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,

after listening to the IETF69 audio stream on=20
http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf69/ietf69-ch7-thurs=
=2Dam.mp3,=20
I realised that there still a few unanswered questions from back then, and=
=20
I'd like to pick at least one of them up right now:

Glen mentioned, around audio mark 2:22:xy, that he knows that a big=20
international roaming consortium exists which is running RADIUS over TCP, a=
nd=20
possibly TLS, and that they might have patents on it.

Now, since I am not very much into the commercial telco market, I have no c=
lue=20
who this consortium is and find out about their patent status. So, could=20
someone (Glen?) name that consortium? It would also be nice if I could get=
=20
some pointers on where to find out about their patents. Even though I reali=
se=20
that finding patents is not exactly easy - I've been hunting for a copy of=
=20
Nokia's AU patent on Diameter and it is a pain. I tend to think that some=20
patents are not meant to be found - until their holder can use them to bash=
=20
other people ;-)

Greetings,

Stefan Winter

=2D-=20
Stefan WINTER

Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e=
t de=20
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked] =A0 =A0 Tel.:  =A0 =A0+352 424409-1
http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0  =A0 Fax: =A0 =A0 =A0+352 422=
473

--nextPart3236002.iY925FeMa0
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

--nextPart3236002.iY925FeMa0--

--
to unsubscribe send a message 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, 16 Oct 2007 07:54:34 +0000
Date: Tue, 16 Oct 2007 10:53:57 +0300
From: Hannes Tschofenig <[email-masked]>
To: Roland Bless <[email-masked]>
CC:  [email-masked], 'radext mailing list' <[email-masked]>,  "[email-masked]" <[email-masked]>, tsvwg IETF list <[email-masked]>
Subject: Re: [NSIS] WGLC for draft-ietf-dime-qos-parameters-01

Hi Roland,

thanks for your review. Please find a few comments below:

Roland Bless wrote:
> Hi Hannes and all,
>
> Hannes Tschofenig wrote:
>
>   
>> http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01
>>     
>
> I'm not a AAA expert, so probably I don't get the point.
> Unfortunately, I'm not very content with the draft, so I have some major
> comments:
> 1) The draft says:
>    "The payloads used to carry these QoS parameters are opaque for the
>    AAA client and the AAA server itself and interpreted by the
>    respective Resource Management Function."
>
>    Since the rest of the draft seems to contain larger copy&paste
>    regions from the NSIS-QSPEC-Draft I'd like to ask: why is it not
>    sufficient to use a QSPEC object as it is. To me it makes no sense
>    to do another format rewriting when creating a Diameter request
>    (QAR) from an NSIS RESERVE for example. Is there any technical
>    reason to not use a QSPEC object as it is? This would allow for
>    an easy interworking between NSIS and AAA and to re-use larger parts
>    of the RMF code. Conveying the parameters for AAA
>    in a different way is IMHO not necessary and source for new
>    implementation errors...
>    If there are technical reasons why using the QSPEC directly doesn't
>    work, please state it in the draft.
>   

There are a couple of reasons why we did not want to re-use the QSPEC 
draft as is.

The first reason is that the Diameter QoS attribute document and the 
Diameter QoS application document, see
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-qos-01.txt
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-attributes-02.txt
are independent of NSIS. There is no dependency between NSIS and these 
documents although the Diameter interworking may also be used for NSIS.

The second reason is that the QSPEC draft has a different focus in the 
sense that the description that is used for the front-end protocol (in 
this case NSIS) is somewhat different to the interaction that takes 
place at the backend. If you go through the QSPEC draft then you will 
notice that many aspects in the draft are so specific to the NSIS 
interactions. Unfortunately, the QSPEC is not just a collection of 
parameters. We did not want to let the reader figure out which parts of 
the document are relevant for them even if they use the Diameter QoS 
work for a different purpose (such as in the interaction with RSVP). In 
fact, in previous draft versions we just made references to the QSPEC 
and when this was brought to other SDOs then this was a real show 
stopper since people got totally confused.

The third reason is that we are changing the format of the QSPEC 
headers. We tried to keep the changes at a minimum but still they are 
different. Some time back we even considered to use a Diameter specific 
format. There are still comments floating around suggesting it but at 
the moment the plain QoS parameters are still in the format of the 
QSPEC. We also make use of the registry created for the QoS parameters; 
some of my recent mails referred to the mismatch between the QSPEC 
registry and the registry created by a document in the TSVWG.

The final reason is that we are changing the semantic of the 
extensibility mechanism. The concept of QoS models (QoSM) as defined in 
the QSPEC and the requirements for defining a QoSM does not work with 
the Diameter usage. Hence, we had to change it. See Section 5 and 6 of 
http://www.ietf.org/internet-drafts/draft-ietf-dime-qos-parameters-01.txt

I believe these reasons justify a new document.

> 2) The draft doesn't provide a meaningful definition of which parameters
>    should be present together etc. It is only an unstructured list of
>    parameter objects and there is no hint given about which combinations
>    are allowed or meaningful etc.
>   
That's true and I don't think draft-ietf-dime-qos-parameters-01 needs to 
say anything about it. draft-ietf-dime-diameter-qos-01.txt and 
draft-ietf-dime-qos-attributes-02.txt provide some minimum semantic. For 
example, when someone wants to use the IntServ Controlled-Load Service QoSM
http://tools.ietf.org/wg/nsis/draft-kappler-nsis-qosmodel-controlledload-05.txt 
and if an interaction with the Diameter backend infrastructure is 
desired then they would take the respective parameters from the received 
NSIS message and copy them into a Diameter message. The QoS profile 
would be set to a value as defined in the IntServ Controlled-Load 
Service QoSM (note that it has not been done yet). If there are specific 
issues that need to be said about the backend infrastructure interaction 
then they may be discussed in the respective QoSM but so far I have not 
heard about anything.

For some other QoSMs, such as RMD, I have never heard that a AAA 
interaction would be desired. There, the usage model is different.

Does this make sense to you?

Ciao
Hannes

> Regards,
>  Roland
>
>
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>   

--
to unsubscribe send a message 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, 15 Oct 2007 21:22:38 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Vendor-Id for radext extended attributes
Date: Mon, 15 Oct 2007 17:20:52 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> > I could see having a PEN for RADIUS Extended Attributes on a per
> > organization (i.e. per SDO) basis.  It seems to me that having a 
> > PEN per working group is overly granular.
> [gwz]
> Perhaps, but it opens the possibility of treating "blocks" of 
> attributes in much the same way as Class C IP addresses: once the
> PEN is assigned, the types "beneath" it could be self-managed ...

Self-managed by whom?  By WG consensus?  What happens after the WG closes?
Would it then be by Designated Expert?  Or would it revert back to IANA?  In
the absence of a long-lived organization (longer than WGs), I don't see how
the delegated assignment authority would work. 

Additionally, I would hope that individual WGs aren't going to each need
blocks of 255 attributes.  That's a pretty scary thought...  :-)

--
to unsubscribe send a message 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, 11 Oct 2007 15:45:11 +0000
From: "Glen Zorn" <[email-masked]>
To: "'David B. Nelson'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Vendor-Id for radext extended attributes
Date: Thu, 11 Oct 2007 22:44:05 +0700

> I think that it might be a better idea ... for the radext extended
> attributes to instead request a separate Vendor-Id for the radext
> WG & encourage other WGs that need new attributes to do the same.

I could see having a PEN for RADIUS Extended Attributes on a per
organization (i.e. per SDO) basis.  It seems to me that having a PEN per
working group is overly granular.
[gwz] 
Perhaps, but it opens the possibility of treating "blocks" of attributes in
much the same way as Class C IP addresses: once the PEN is assigned, the
types "beneath" it could be self-managed (with the caveat that their usage
be documented in a freely available form (e.g., an RFC) of course.
[/gwz]
...

--
to unsubscribe send a message 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, 10 Oct 2007 08:57:22 +0000
Date: Wed, 10 Oct 2007 10:56:16 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  [email-masked]
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located

Glen Zorn wrote:
> How is that possible, given that there is no "logoff" message in RADIUS?
> Surely you mean that the RADIUS _Accounting_ server tracks sessions, no?

  Sure.  In most systems deploying CoA, I expect that there will be a
strong relationship between CoA, authentication, and accounting systems.

> OK, I give: how does the DAC even know that there is a session to modify if
> it has no access to session state?

  If the DAC client is co-located, or has access to the session DB,
there's no problem.

  Otherwise, (as was discussed here), the DAC may be trying to
disconnect a TCP session, or an IP session based on data in the IP
traffic.  The DAC can send the IP session information to the RADIUS
server, which uses it's database to discover the underlying RADIUS
session.  It can then send a properly formatted CoA to the NAS.

  The NAS may not be able to ascertain RADIUS session solely from IP
parameters, because it may need additional information.  (port, vlan, etc.)

  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, 10 Oct 2007 08:14:33 +0000
From: "Glen Zorn" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Wed, 10 Oct 2007 15:13:48 +0700

...

>> > Since the DAC needs access to a database of State in order to track
>> > sessions, that database could contain the required State attribute.
>>
>>   The RADIUS server already tracks sessions.  
[gwz] 

How is that possible, given that there is no "logoff" message in RADIUS?
Surely you mean that the RADIUS _Accounting_ server tracks sessions, no?

[gwz] 

>>I would recommend against
>> DACs re-implementing that.
> 
> Some how the DAC needs to know which NAS to send the
> CoA/Disconnect-Request to, correct?

  Normally, yes.  If it sends the request to the RADIUS server, we
presume that the RADIUS server figures it out.
[gwz] 

OK, I give: how does the DAC even know that there is a session to modify if
it has no access to session state?

[gwz] 

--
to unsubscribe send a message 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, 08 Oct 2007 14:23:58 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'radext mailing list'" <[email-masked]>
Subject: RE: RFC 2866 clarifications
Date: Mon, 8 Oct 2007 10:22:40 -0400
Organization: Elbrys Networks, Inc.

Alan DeKok writes...

>  How do we clarify it for everyone else?

Well, this would be a natural item for the RADIUS Issues and Fixes draft.
Too bad that draft is already approved and in the RRC Editor's queue.

One alternative is to issue an RFC Errata to RFC 2866.  One may argue about
how effective such errata are, but it is one available mechanism.

>  How do we deal with vendors who have it defined the opposite way?

That's an entirely different question.  The IETF publishes standards and
other memos for the industry to use, or not, as they choose.  There's
nothing that the RADEXT WG or the IETF can do to "deal with" incorrect
implementation, based on misinterpretation of the RFC, even when the RFC
text is admittedly somewhat confusing.

As to your initial query, I think it would be reasonable for the RADEXT WG
to attempt to come to consensus on the "correct" interpretation of these
attributes.

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

Delivery-date: Mon, 08 Oct 2007 13:41:40 +0000
Date: Mon, 08 Oct 2007 15:40:26 +0200
From: Alan DeKok <[email-masked]>
To: David Bird <[email-masked]>
CC: radext mailing list <[email-masked]>
Subject: Re: RFC 2866 clarifications

David Bird wrote:
> To make matters worse, some vendors allow the meaning to be reversed.

  Having it configurable is preferred to having it wrong.

> The only smooth way I see is if there was another attribute, say
> Acct-View-Point, which specified the perspective (or direction) being
> taken. This way, vendors can update their firmware becoming "compliant"
> while not requiring all the back-end systems and roaming partners they
> work with to change over night.

  Without having strong opinions... that way lies madness.  There are
many, many, potential points to fail interoperability.  Putting
inter-operability claims in a protocol is *itself* subject to
inter-operability.

  It's easier to clarify the term, and to push vendors to correctly
implement it in future products.

  Alan DeKok.

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

Delivery-date: Mon, 08 Oct 2007 13:01:18 +0000
From: David Bird <[email-masked]>
Subject: Re: RFC 2866 clarifications
Date: Mon, 8 Oct 2007 15:01:27 +0200
To: radext mailing list <[email-masked]>

>> Given that RFC 2866 specifies NAS behavior, the word "input" in the
>> attribute name should guide us.  These are octets that have been  
>> received as
>> "input" on the NAS.
>
>   I agree.
>
>   How do we clarify it for everyone else?  How do we deal with vendors
> who have it defined the opposite way?
>

To make matters worse, some vendors allow the meaning to be reversed.  
The only smooth way I see is if there was another attribute, say Acct- 
View-Point, which specified the perspective (or direction) being  
taken. This way, vendors can update their firmware becoming  
"compliant" while not requiring all the back-end systems and roaming  
partners they work with to change over night.

David

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

Delivery-date: Mon, 08 Oct 2007 12:27:07 +0000
Date: Mon, 08 Oct 2007 14:25:55 +0200
From: Alan DeKok <[email-masked]>
To: "David B. Nelson" <[email-masked]>
CC: 'Alan DeKok' <[email-masked]>,  'radext mailing list' <[email-masked]>
Subject: Re: RFC 2866 clarifications

David B. Nelson wrote:
> This terminology may be confusing, especially in light of the wider use of

  s/may be/is/

> Given that RFC 2866 specifies NAS behavior, the word "input" in the
> attribute name should guide us.  These are octets that have been received as
> "input" on the NAS. 

  I agree.

  How do we clarify it for everyone else?  How do we deal with vendors
who have it defined the opposite way?

  Alan DeKok.

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

Delivery-date: Mon, 08 Oct 2007 12:10:41 +0000
From: "David B. Nelson" <[email-masked]>
To: "'Alan DeKok'" <[email-masked]>, "'radext mailing list'" <[email-masked]>
Subject: RE: RFC 2866 clarifications
Date: Mon, 8 Oct 2007 08:10:21 -0400

>   RFC 2866
>   http://freeradius.org/rfc/rfc2866.html#Acct-Input-Octets
>    ...This attribute indicates how many octets have been received from
> the port ...
> 
>   i.e. In a dial-up context, a user connects TO a port, which recieves
> octets FROM that user.

This terminology may be confusing, especially in light of the wider use of
"to" and "from" directionality, in similar contexts.  

Given that RFC 2866 specifies NAS behavior, the word "input" in the
attribute name should guide us.  These are octets that have been received as
"input" on the NAS.  The "from", in this context, probably means received
internally from the port, by the forwarding engine, indirectly "from" the
user.  Yes, the text is a little confusing, if you assume that the "to" and
"from" are taken to mean the direction on the wire connecting the client and
the NAS, viewed from the perspective of the NAS.  I think we need to focus
on the name of the attribute, be it "input" or "output", again with
reference to the NAS.

--
to unsubscribe send a message 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, 08 Oct 2007 11:19:29 +0000
Date: Mon, 08 Oct 2007 13:17:51 +0200
From: Alan DeKok <[email-masked]>
To: 'radext mailing list' <[email-masked]>
Subject: RFC 2866 clarifications

  I've been having some discussions (public and private) with people
about RFC 2866 recently.  There are apparently disagreements about the
meaning of Acct-Input-Octets (and related attributes).  The following is
a summary of the discussion, based on specifications and references:

  RFC 2866
  http://freeradius.org/rfc/rfc2866.html#Acct-Input-Octets
   ...This attribute indicates how many octets have been received from
the port ...

  i.e. In a dial-up context, a user connects TO a port, which recieves
octets FROM that user.  This interpretation is validated by the
Livingston Portmaster documentation:

  Portmaster documentation:
  http://portmasters.com/tech/docs/radius/accounting.html
  ... Acct-Input-Octets records the number of bytes received from the
user ...

  Which appears to be clearer than the text in RFC 2866.  RFC 4005 also
defines Accounting-Input-Octets this way.

  Some more discussion, and a table of conflicting meaning by vendor:
  http://coova.org/wiki/index.php/Template:NASVendorAccountingTable

  3GPP Specification:
  http://www.3gpp.org/ftp/Specs/archive/29_series/29.234/29234-770.zip
  Table 4.5.1:

  Acc-Input-Octets: Indicates the number of octets sent by the WLAN UE
over the course of the session. According to IETF RFC 2866 [20], shall
only be present if ACC Status Type is set to "Stop".

  There appears to be some confusion over the meaning of this attribute,
and related ones.  Does this WG have consensus over the interpretation?
 Is additional clarification necessary?

  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, 04 Oct 2007 18:40:53 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-radext-rfc3576bis-10.txt 
Date: Thu, 04 Oct 2007 14:40:02 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
	Author(s)       : M. Chiba, et al.
	Filename        : draft-ietf-radext-rfc3576bis-10.txt
	Pages           : 33
	Date            : 2007-10-04

This document describes a currently deployed extension to the Remote
Authentication Dial In User Service (RADIUS) protocol, allowing
dynamic changes to a user session, as implemented by network access
server products.  This includes support for disconnecting users and
changing authorizations applicable to a user session.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-10.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-ietf-radext-rfc3576bis-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-radext-rfc3576bis-10.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

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

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

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

ENCODING mime
FILE /internet-drafts/draft-ietf-radext-rfc3576bis-10.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-radext-rfc3576bis-10.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:     <2007-10-04143944.I-D\@ietf.org>

--OtherAccess--

--NextPart--

--
to unsubscribe send a message 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, 03 Oct 2007 21:31:27 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Wed, 03 Oct 2007 14:30:17 -0700

Looks good.  I'll include this text in -11.

>From: Alan DeKok <[email-masked]>
>To: Bernard Aboba <[email-masked]>
>CC: [email-masked]
>Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
>Date: Wed, 03 Oct 2007 18:08:04 +0200
>
>Bernard Aboba wrote:
> > Yet another revision:
>
>   It's a little complicated.  If I try to shorten the sentences and chop
>it into paragraphs, I get:
>
>---
>The DAC may require access to data from the RADIUS authentication or
>accounting packets.  It uses this data to compose compliant
>CoA-Request or Disconnect-Request packets.  For example, as described
>in Section 3.3, a CoA-Request packet containing a Service-Type
>Attribute with value "Authorize Only" is required to contain a State
>Attribute.  The NAS will subsequently transmit this attribute to the
>RADIUS server in an Access-Request.  In order for the DAC to include a
>State Attribute that the RADIUS server will subsequently accept, some
>coordination between the two parties may be required.
>
>This coordination may be acheived in multiple ways.  The DAC may be
>co-located with a RADIUS server, in which case it is presumed to have
>access to the necessary data.  The RADIUS server may also store that
>information in a common database.  The DAC may then be separated from
>the RADIUS server, so long as it has access to that common database.
>
>Where the DAC is not co-located with a RADIUS server, and does not have
>access to a common database, the DAC SHOULD send CoA- Request or
>Disconnect-Request packets to a RADIUS server acting as a proxy, rather
>than sending them directly to the NAS.
>
>A RADIUS server receiving a CoA-Request or Disconnect-Request packet
>from the DAC MAY then add or update attributes (such as adding NAS or
>session identification attributes or appending a State Attribute),
>prior to forwarding the packet.  Having CoA/Disconnect-Requests
>forwarded by a RADIUS server can also enable upstream RADIUS proxies
>to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).
>
>
>   Alan DeKok.
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

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

Delivery-date: Wed, 03 Oct 2007 16:08:57 +0000
Date: Wed, 03 Oct 2007 18:08:04 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located

Bernard Aboba wrote:
> Yet another revision:

  It's a little complicated.  If I try to shorten the sentences and chop
it into paragraphs, I get:

---
The DAC may require access to data from the RADIUS authentication or
accounting packets.  It uses this data to compose compliant
CoA-Request or Disconnect-Request packets.  For example, as described
in Section 3.3, a CoA-Request packet containing a Service-Type
Attribute with value "Authorize Only" is required to contain a State
Attribute.  The NAS will subsequently transmit this attribute to the
RADIUS server in an Access-Request.  In order for the DAC to include a
State Attribute that the RADIUS server will subsequently accept, some
coordination between the two parties may be required.

This coordination may be acheived in multiple ways.  The DAC may be
co-located with a RADIUS server, in which case it is presumed to have
access to the necessary data.  The RADIUS server may also store that
information in a common database.  The DAC may then be separated from
the RADIUS server, so long as it has access to that common database.

Where the DAC is not co-located with a RADIUS server, and does not have
access to a common database, the DAC SHOULD send CoA- Request or
Disconnect-Request packets to a RADIUS server acting as a proxy, rather
than sending them directly to the NAS.

A RADIUS server receiving a CoA-Request or Disconnect-Request packet
from the DAC MAY then add or update attributes (such as adding NAS or
session identification attributes or appending a State Attribute),
prior to forwarding the packet.  Having CoA/Disconnect-Requests
forwarded by a RADIUS server can also enable upstream RADIUS proxies
to perform a Reverse Path Forwarding (RPF) check (see Section 6.1).

  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, 03 Oct 2007 16:00:14 +0000
From: "David B. Nelson" <[email-masked]>
To: <[email-masked]>
Subject: RE: Vendor-Id for radext extended attributes
Date: Wed, 3 Oct 2007 11:59:12 -0400
Organization: Elbrys Networks, Inc.

Glen Zorn writes...

> I think that it might be a better idea ... for the radext extended
> attributes to instead request a separate Vendor-Id for the radext
> WG & encourage other WGs that need new attributes to do the same.

I could see having a PEN for RADIUS Extended Attributes on a per
organization (i.e. per SDO) basis.  It seems to me that having a PEN per
working group is overly granular.

--
to unsubscribe send a message 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, 03 Oct 2007 15:49:19 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Wed, 03 Oct 2007 08:48:42 -0700

Yet another revision:

"  In order to compose CoA-Request or Disconnect-Request packets, the
   DAC is assumed to have access to data (such as NAS and session
   identification attributes) which is typically gleaned from RADIUS
   authentication or accounting packets.  While access to this
   information does not require the DAC to be co-located with a RADIUS
   server (e.g. the data could be stored in a database accessed by the
   DAC), where the DAC is not co-located with a RADIUS server some
   information necessary to build a compliant CoA-Request or Disconnect-
   Request packet may not be available.  For example, as described in
   Section 3.3, a CoA-Request packet containing a Service-Type Attribute
   with value "Authorize Only" is required to contain a State Attribute
   that the NAS will subsequently transmit to the RADIUS server in an
   Access-Request.  In order for the DAC to include a State Attribute
   that the RADIUS server will subsequently accept, some coordination
   may be required.  In these situations, the DAC SHOULD send CoA-
   Request or Disconnect-Request packets to a RADIUS server acting as a
   proxy, rather than sending them directly to the NAS.  A RADIUS server
   receiving a CoA-Request or Disconnect-Request packet from the DAC MAY
   then add or update attributes (such as adding NAS or session
   identification attributes or appending a State Attribute), prior to
   forwarding the packet.  Having CoA/Disconnect-Requests forwarded by a
   RADIUS server can also enable upstream RADIUS proxies to perform a
   Reverse Path Forwarding (RPF) check (see Section 6.1)."

--
to unsubscribe send a message 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, 02 Oct 2007 08:36:14 +0000
Date: Tue, 02 Oct 2007 10:35:16 +0200
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked], tsvwg IETF list <[email-masked]>,  "[email-masked]" <[email-masked]>, 'radext mailing list' <[email-masked]>
Subject: WGLC for draft-ietf-dime-qos-attributes-02

Hi all,

this message marks the issuance of a working group last call (WGLC) on 
DIME's Internet Draft entitled "Quality of Service Attributes for 
Diameter" (draft-ietf-dime-qos-attributes-02). You may view this document at
http://tools.ietf.org/html/draft-ietf-dime-qos-attributes-02

Please post comments and questions to the DIME mailing list (or to the 
authors) no later than 16 October 2007.

Ciao
Hannes & Dave

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

Delivery-date: Tue, 02 Oct 2007 08:36:06 +0000
Date: Tue, 02 Oct 2007 10:35:11 +0200
From: Hannes Tschofenig <[email-masked]>
To:  [email-masked], 'radext mailing list' <[email-masked]>,  "[email-masked]" <[email-masked]>, tsvwg IETF list <[email-masked]>
Subject: WGLC for draft-ietf-dime-qos-parameters-01

Hi all,

this message marks the issuance of a working group last call (WGLC) on 
DIME's Internet Draft entitled "Quality of Service Parameters for Usage 
with the AAA Framework " (draft-ietf-dime-qos-parameters-01). You may 
view this document at
http://tools.ietf.org/html/draft-ietf-dime-qos-parameters-01

Please post comments and questions to the DIME mailing list (or to the 
authors) no later than 16 October 2007.

Ciao
Hannes & Dave

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

Delivery-date: Mon, 01 Oct 2007 16:11:56 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Mon, 01 Oct 2007 09:11:35 -0700

Looking over the text, it still seems a bit rough.  How about this?

"Regardless of whether it is co-located with a RADIUS server, the DAC is 
typically assumed
to have access to data gleaned from the flow of RADIUS authentication or 
accounting
packets (such as NAS and session identification attributes) in order to 
compose
CoA-Request or Disconnect-Request packets.   However, where the DAC is not
co-located with a RADIUS server, in some circumstances it may not have 
access to data
necessary to build a compliant CoA-Request or Disconnect-Request packet
(such as the information necessary to construct a State Attribute
that a RADIUS server would subsequently accept).
In these deployments, the DAC SHOULD send CoA or Disconnect-Requests to a
RADIUS server acting as a proxy, rather than
sending them directly to the NAS.

A RADIUS server receiving a CoA or Disconnect-Request from the DAC may then 
add or
update attributes (such as adding NAS or session identification attributes 
or
appending a State Attribute), prior to forwarding the
packet.  Having CoA/Disconnect-Requests forwarded by a RADIUS server may
also  enable upstream RADIUS proxies to perform a Reverse Path Forwarding 
(RPF) check
(see Section 6.1)."

--
to unsubscribe send a message 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, 01 Oct 2007 15:32:57 +0000
From: "Bernard Aboba" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Bcc: 
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located
Date: Mon, 01 Oct 2007 08:32:16 -0700

The DAC is normally assumed to have access to data gleaned from the RADIUS 
traffic flow (such as mapping of User-Names to NASes), regardless of whether 
it is co-located with the RADIUS server.  However, this would not 
necessarily allow it to construct a valid State Attibute.

Note that the RADIUS server/proxy cannot do an RPF check on the incoming 
packet, since the DAC would presumably not be a acting as a RADIUS server 
and therefore would fail the RPF check.  However, an upstream RADIUS proxy 
could successfully conduct the check.

How about this?

"Regardless of whether it is co-located with a RADIUS server, the DAC is 
assumed
to have access to data gleaned from the RADIUS traffic flow (such as the NAS 
and
NAS-Port corresponding to a User-Name) in order to use that data to compose
CoA-Request or Disconnect-Request packets.   However, where the DAC is not
co-located with a RADIUS server, it may not have access to all the data
necessary to build a compliant CoA-Request or Disconnect-Request packet
(such as the ability to construct a State Attribute that the RADIUS server 
can
subsequently validate).  In those deployments, the DAC SHOULD send
CoA or Disconnect-Requests to a RADIUS server acting as a proxy, rather than
sending them directly to the NAS.

A RADIUS server receiving a CoA or Disconnect-Request from the DAC may then 
add or
update attributes (such as adding a State Attribute), prior to forwarding 
the
packet.  Having CoA/Disconnect-Requests forwarded by a RADIUS server may
also enable upstream RADIUS proxies to perform an RPF check.
The result is a simpler and more flexible network configuration."

--
to unsubscribe send a message 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, 01 Oct 2007 12:29:13 +0000
Date: Mon, 01 Oct 2007 14:27:44 +0200
From: Alan DeKok <[email-masked]>
To: Bernard Aboba <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC 3576bis Question: DAC and RADIUS server not co-located

Bernard Aboba wrote:
>...
>>   It would be easier to have the DAC proxy through the RADIUS server,
>> which would in turn supply a State in the CoA packet.
> 
> Yes, I think this makes sense.  Can you suggest some text that would
> make this clear?

...
  A DAC is normally co-located with a RADIUS server.  This close
relationship permits the DAC to obtain information from the RADIUS
traffic flow, and then use that data to make informed decisions about
the contents of the CoA-Request or Disconnect-Request packets.  When a
DAC client is not co-located with a RADIUS server, it may not have
access to the data necessary to build a compliant CoA-Request or
Disconnect-Request packet.  In those deployments, the DAC SHOULD send
its request to a RADIUS proxy that is acting as a DAS, rather than
directly to the NAS.

  When the DAC's request is sent in this way, the DAS may use its
knowledge of the RADIUS traffic to add or update attributes in the
request.  It may also perform RPF checks, and direct the request to the
appropriate NAS.  The result is a simpler and more flexible network
configuration.

>> > Since the DAC needs access to a database of State in order to track
>> > sessions, that database could contain the required State attribute.
>>
>>   The RADIUS server already tracks sessions.  I would recommend against
>> DACs re-implementing that.
> 
> Some how the DAC needs to know which NAS to send the
> CoA/Disconnect-Request to, correct?

  Normally, yes.  If it sends the request to the RADIUS server, we
presume that the RADIUS server figures it out.

  Alan DeKok.

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

Delivery-date: Mon, 01 Oct 2007 08:54:02 +0000
Date: Mon, 01 Oct 2007 10:52:43 +0200
From: Alan DeKok <[email-masked]>
To: Glen Zorn <[email-masked]>
CC: 'Bernard Aboba' <[email-masked]>,  [email-masked]
Subject: Re: RFC 3576bis Question:  DAC and RADIUS server not co-located

Glen Zorn wrote:
> I have always assumed that "DAC" was just another name for "RADIUS server",
> i.e., the same entity acting in two different roles.

  Normally, yes.  However, there are conceivably deployments where they
are separate machines.  We should have recommendations for those situations.

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