Subject: REMINDER: RADEXT WG Last Call on Design Guidelines Document

From: Bernard Aboba <[email-masked]>
Date: Sat, 5 Jul 2008 11:59:25 -0700 (PDT)

This is a reminder of the ongoing RADEXT WG Last Call on "RADIUS Design 
Guidelines" prior to requesting that the IESG publish it as a Best
Current Practice RFC. 
 
The document is available here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-03.txt
 
WG Last Call will last until July 10, 2008.   Please review the document 
and post your comments to the RADEXT WG mailing list 
([email-masked]) in the format described on the RADEXT WG Issues 
list (http://www.drizzle.com/~aboba/RADEXT/).   
 
If you have read the document and approve of its publication, but have no
comments, please also post this to the list. 

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

---

From: "David B. Nelson" <[email-masked]>
Date: Mon, 7 Jul 2008 13:59:30 -0400

My review comments on the -04 version as are follows:

(1) Short-lived reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

* Reviews of specifications are posted to the RADEXT WG or
equivalent IETF mailing list;

The RADEXT WG mailing list is a relatively short-lived entity.  We hope the
WG completes its charter and closes one of these days.  :-)  This text
provides no guidance to the reader as to how to determine what constitutes
an "equivalent" IETF mailing list.

Requested change:

* Reviews of specifications are posted to the RADEXT WG mailing list or
another IETF mailing list suggested by the Operations & Management Area
Directors of the IETF;

(2) Misplaced modifier.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 1.1
Rationale/Explanation of issue:

   RADIUS protocol changes, or specification of attributes that
   can be used to, in effect, provide new RADIUS commands (such as
   Service-Type) require greater expertise and deeper review, as
   do changes to the RADIUS operational model, as described in
   Section 3.3.

Service-Type is an attribute, not a command.

Requested change:

   RADIUS protocol changes, or specification of attributes (such
   as Service-Type) that can be used to, in effect, provide new
   RADIUS commands, require greater expertise and deeper review,
   As do changes to the RADIUS operational model, as described in
   Section 3.3.

(3) Undefined term.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 2.1.3
Rationale/Explanation of issue:

   As a result, the introduction of new complex data types
   within RADIUS attribute specifications SHOULD be avoided,
   except in the case of complex attributes involving authentication
   or security functionality.

"Security functionality" is a term that could be assigned a fairly broad
range of possible meanings.  Well intentioned RADIUS Attribute designers
might think this applies to any attribute that they wish to remain "secure"
or which has security implications for their product, e.g. important service
provisioning parameters.  While the term is defined by various examples in
Appendix B, I think a better "normative" definition is required here.

Requested change:

Add a definition of what constitutes "security functionality".  Given that
I'm having difficulty in suggesting specific text to accomplish this, I'm
thinking it's not all that obvious.  Do we need to reference "security
functionality" at all, or is an exception for "authentication credentials"
sufficient?

(4) Needlessly IETF-centric viewpoint.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: 3.1.3
Rationale/Explanation of issue:

  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:

   * 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 leads me to believe that the authors think that other (non-IETF) SDOs
(or worse yet, groups of SDOs) are unlikely to define attributes that are
useful to the broad Internet Community.  That may or may not be true.  I'm
guessing that what this really means is that only the IETF ought to be
consuming standard RADIUS attribute IDs, based on IANA allocation, and all
other bodies need to host attributes in a private code-point space (i.e. the
assigned VSA block).  Does this document intend to Update RFC 3575?

I think the conditional phrase "for attributes matching any of the following
criteria" will almost always evaluate to TRUE because of the second and
third bullet items, so the whole paragraph makes little sense to me.

If the issue is standard attribute scarcity, isn't this addressed by the
RADIUS Extended Attribute format [EXTEN]?

I think that this document should provide better guidance as to when an IANA
allocation from the standard RADIUS Attribute code-point space is
appropriate.  Does the need for interoperability between multiple SDOs meet
that threshold?  Or must the usage be of general applicability to the
Internet Community?  How does the existence of the Extended RADIUS Attribute
(a VSA with a code-point block assigned to the IETF) change the distinction
between "standard" and "VSA" allocations?

Requested change:

  SDO RADIUS Attribute specifications SHOULD allocate attributes from
  the vendor space, rather than requesting an allocation from the
  RADIUS standard attribute space, unless the attributes match any of the
  following criteria:

   * attributes intended for interoperable use across multiple SDOs.
   * attributes intended for interoperable use across a broad spectrum 
     of the Internet Community.

(5) Format issues.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: 3.3
Rationale/Explanation of issue:

      * The RADIUS protocol is stateless; * Provisioning of services is
      not possible within an Access-Reject; * Distinction between
      authorization checks and user authentication; * Authentication and
      integrity protection of RADIUS packets; * The RADIUS protocol is a
      Request/Response protocol.

Bulleted list not well formatted.

Requested change:

  * The RADIUS protocol is stateless;
  * Provisioning of services is not possible within an Access-Reject;
  * Distinction between authorization checks and user authentication;
  * Authentication and integrity protection of RADIUS packets;
  * The RADIUS protocol is a Request/Response protocol.

(6) Bad reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Requested change:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

A.1.2 --> A.1.1

(7) Missing definition/reference.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.2
Rationale/Explanation of issue:

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types SHOULD be used only where there is
   no clear method of expressing the data using existing types.

Where do we normatively define the term "extended data types"?

Requested change:

Add a definition, or a reference to a definition.  Does this, in fact, mean
the RADIUS Attribute format defined in [EXTEN]?

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.2 SHOULD
   be used.  The extended data types [EXTEN] SHOULD be used only where 
   there is no clear method of expressing the data using existing types.

(8) Duplicate section title.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Editorial
Priority: '1' Should fix 
Section: A.1.3, A.2.2
Rationale/Explanation of issue:

Both of these sections are entitled "Complex data types".  One of them is
permissive and the other prohibitive.

Requested change:

Clarify the subject of each of these sections in its title.

(9) Confusion over allocation policy.

Submitter name: Dave Nelson
Submitter email address: [email-masked]
Date first submitted: July 7, 2008
Document: draft-ietf-radext-design-04.txt
Comment type: Technical
Priority: '1' Should fix 
Section: A.5
Rationale/Explanation of issue:

A.5. Allocation of attributes

   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 intended for a vendor to support their own systems,
      and not suitable for general usage
      * 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 discussed in comment (4), above, attributes intended for interoperable
use across multiple SDOs *could* qualify for allocation from the standard
RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)
space.

Requested change:

A.5. Allocation of attributes

   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 intended for a vendor to support their own systems,
      and not suitable for general usage
      * attributes relying on data types not defined within RADIUS
      * attributes intended for use within an single SDO

---

From: Alan DeKok <[email-masked]>
Date: Tue, 08 Jul 2008 15:20:55 +0200

> (1) Short-lived reference.
...
> an "equivalent" IETF mailing list.

  The introduction references the AAA doctors list.  A similar reference
should be added here.

> another IETF mailing list suggested by the Operations & Management Area

  I think that referencing the AAA doctors list would be useful, too.

> (2) Misplaced modifier.
...
> Requested change:

  OK.

> (3) Undefined term.
...
> functionality" at all, or is an exception for "authentication credentials"

  The Message-Authenticator attribute provides authentication of RADIUS
packets that is independent of any user authentication credentials.

> (4) Needlessly IETF-centric viewpoint.
..
> useful to the broad Internet Community.

  SDOs don't have a problem referencing RADIUS specifications from other
SDOs.  That's not the issue.  The issue is whether or not everyone
*else* finds the specifications useful.

  e.g. 3GPP2 defines a number of RADIUS attributes.  I haven't seen them
implemented in a Wifi hotspot or in a low-end Wifi home router... and I
don't expect to see them there.  As such, the 3GPP2 specifications
belong in the SDO space, and not in the IETF space.

>  That may or may not be true.  I'm

  Yes (to the first sentence), and no (to the second).  Pointing out
that IETF and IANA are responsible for standard-space allocations isn't
an update to IETF processes.  It's a re-iteration that vendors and SDOs
SHOULD NOT stomp on the IETF space for vendor-specific, or SDO-specific
allocations.

> third bullet items, so the whole paragraph makes little sense to me.

  If SDOs need functionality that is useful to *everyone*, they can
request standard space allocation.  If SDOs are defining their own
specifications, they do not need standard space allocation.

> RADIUS Extended Attribute format [EXTEN]?

  No.  While the guidelines document was started when [EXTEN] had 8-bit
attributes, the issue isn't attribute scarcity.  The issue as I see it
is requesting "standard" space allocation for SDO-specific
functionality.  I'm not sure many SDOs would agree to cede change
control over their allocations to IANA.  I'm not sure that IANA wants
that work, either.

> that threshold? 

  I don't think so.  WiMAX is referencing 3GPP attributes.  There's no
need to re-host the 3GPP attributes in the IETF standard space just
because another SDO decides to reference them.

> Or must the usage be of general applicability to the
> Internet Community?

  Yes.  And it should be *new* functionality.

>  How does the existence of the Extended RADIUS Attribute

  How about adding 2.1.6:

  The extended RADIUS attribute document [EXTEN] defines a number of
  extensions to RADIUS.  The standard attribute space is extended by
  permitting standard allocations from within a specific subset of the
  VSA space; the format of extended attributes is defined; and
  extended data types are defined within that format.

  New specifications seeking to extend the standard RADIUS data model
  SHOULD examine [EXTEN] to see if their needs fit within the extended
  RADIUS data model.

> Requested change:

  We could add the following sentence after the existing bullet points
that discuss "SDOs or groups of SDOs".

  Any new RADIUS attributes or values intended for interoperable use
  across a broad spectrum of the Internet Community SHOULD follow the
  normal IETF process, and SHOULD result in allocations from the RADIUS
  standard space.

> (5) Format issues.

  Fixed.

> (6) Bad reference.

  Fixed.

> (7) Missing definition/reference.
...
> Where do we normatively define the term "extended data types"?

  I would suggest in a new section, 2.1.6, as shown above.

> (8) Duplicate section title.
...
> permissive and the other prohibitive.

  The first talks about Opaque data types being OK.  I've changed the
title to "Opaque data types".  The second is about Complex data types in
RADIUS being NOT RECOMMENDED.

> (9) Confusion over allocation policy.
...
> RADIUS attribute space, or from the Extended RADIUS Attribute (IETF/SDO)

  As noted in my response, there are many uses of attributes *outside*
of SDOs and groups of SDOs.  The text here can be clarified a bit, but I
 think it's relatively good.

  How about this text:

  When attributes are used primarily withing a group of SDOs, and are
  not applicable to the wider Internet community, we expect that one SDO
  will be responsible for allocation from their own private space.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 8 Jul 2008 14:11:05 -0400

Alan DeKok writes...

> > (3) Undefined term.
> ...
> > Add a definition of what constitutes "security functionality". 
> > Given that I'm having difficulty in suggesting specific text to 
> > accomplish this, I'm thinking it's not all that obvious.  Do we
> > need to reference "security functionality" at all, or is an 
> > exception for "authentication credentials" sufficient?
> 
>   The Message-Authenticator attribute provides authentication of 
> RADIUS packets that is independent of any user authentication 
> credentials.

OK, so that's not a viable simplification.  I'm still fishing for a
definition of "security functionality", as used in this context, that's less
open-ended than the plain meaning as found in the dictionary.

> specifications, they do not need standard space allocation.

How, exactly, do we define "everyone"?

> I'm not sure many SDOs would agree to cede change control over
> their allocations to IANA.  I'm not sure that IANA wants that work,
> either.

Isn't IANA funded to allocate code points to anyone who presents a valid
request, even individuals?

To some extent, I think this is a matter of nomenclature.  If we say that
the RADIUS code space is divided between "standard" space and "Vendor
Specific" space, we effectively lump SDO uses, would could be very broadly
adopted, with proprietary vendor uses, which could have minimal, if any,
deployment.  That's why I've been touting the term SDO Specific Attribute.
True, it uses the Vendor Specific Attribute format (and top-level ID), but
it allows for a distinction between proprietary vendor uses and standardized
uses.  The distinction between "IETF standard" space and "other SDO
standard" space then becomes merely a matter of which registry is used, and
not a matter of "standard" vs. "non-standard".

I'm an engineer but I recognize that sometimes marketing considerations are
important.  :-)

>   SHOULD examine [EXTEN] to see if their needs fit within the extended

Yes, I think that would be helpful.

>   normal IETF process, and SHOULD result in allocations from the RADIUS

I think that would also helpful, although the interpretation of "broad"
remains subjective.  I'm not sure ewe can do much better, though.

>   When attributes are used primarily within a group of SDOs, and are

I guess this OK.   See my discussion, above.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jul 2008 11:28:29 +0200

> open-ended than the plain meaning as found in the dictionary.

  Leaving it open ended might not be catastrophic.  The rest of RADIUS
is open ended.

  e.g. I just ran into devices with multiple interfaces that send
Accounting-Requests from IP (1) for Start/Stop, and from IP (2) for
Interim-Updates.

  Since this isn't forbidden by the specs, they have no interest in
fixing it.  It's everyone *else* that has to butcher their systems in
order to deal with such nonsense.

> How, exactly, do we define "everyone"?

  "The wider Internet community".

> request, even individuals?

  Yes.. but change control?  I don't think any SDO forum would be
willing to go through IANA for SDO specific attribute allocation.

> deployment.

  Yes.  That's the reality, unfortunately.

>  That's why I've been touting the term SDO Specific Attribute.

  The document already refers to SSA's.  I think that's good enough.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 11 Jul 2008 08:36:37 -0400

>   Leaving it open ended might not be catastrophic.  The rest of RADIUS

It might not be catastrophic.  OTOH, just because there are so many "issues"
that arise because RADIUS is so open-ended, the engineer in me wants to
"fix" some of that, at least in any new features we introduce.

> order to deal with such nonsense.

Yeah, well that's the kind of thing that motivates me to craft tighter
specifications for new features we're adding to RADIUS.  We can't fix the
past, but we don't need to add fuel to the fire, either.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 11 Jul 2008 07:01:44 -0700 (PDT)

> > order to deal with such nonsense.

Ugh.  I wonder how the RADSEC proxy would function when receiving packets 
from an implementation like that.

RFC 5080 does suggest that NAS-Identifier be used to avoid 
multi-homing confusion, at least within the RADIUS packet itself.  
Using different source addresses does seem "novel" - and quite 
likely to confuse.  One can imagine quite bizarre scenarios for an interop 
torture test - like having a NAS sending RADIUS/EAP packets within the 
same session from different IP addresses.  The RFC 5080 algorithm in 
Section 2.1.2 references "source IP", so it would be confused by this, 
wouldn't it?

---

From: Alan DeKok <[email-masked]>
Date: Fri, 11 Jul 2008 16:19:41 +0200

> from an implementation like that.

  If both IP's are listed as clients, then all the packets get processed.

> Section 2.1.2 references "source IP", so it would be confused by this, 

  Yes.  Luckily so far, devices do this only for accounting packets.

  Anyone crazy enough to do this for EAP will quickly discover that it
Just Doesn't Work.  They'll then fix their implementation.

  For accounting packets, it's harder to claim that this behavior
violates the spec.

  Alan DeKok.