Subject: Proposed resolution to guidelines document

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 14:24:48 +0100

I have put a proposed draft on my web site.  It *should* address the
(cough) minor comments discussed here:

http://git.freeradius.org/ietf/10-11-diff.html

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  Changes are:

1) delete unused definition of RADIUS proxy as pointed out by Avi

2) add missing line as pointed out by Avi

3) change text about "complex" types to "new" types.

4) move "Complex attributes and security" to the "Security" section

5) remove all text referencing "applications" from that section,
   and change the text to "other, non-RADIUS systems".  This makes
   the text generic enough to apply to application layers, or to
   the practice of storing RADIUS data in SQL tables

6) add text about modern systems:

  Some systems permit complex attributes to be defined via a method	
  that is more capable than traditional RADIUS dictionaries.  These	
  systems can reduce the security threat of new types significantly,	
  but they do not remove it entirely.	

7) it doesn't address Joe's comments or Bernard's suggestion.  That
   text will come later.

  I believe that this addresses *all* of controversial points.  The
document no longer relies on traditional RADIUS dictionaries to motivate
its recommendations.  It no longer discusses *any* processing model of
RADIUS, other than to say that systems other than RADIUS may use the
data produced by RADIUS.

  All it says is "prefer simple types to complex ones, but allow complex
ones if everything else is worse".  And it says that change has risk.

  If this text is deemed to be not applicable to the majority of
"RADIUS" implementations, then I suggest that those systems are no
longer implementing RADIUS.

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

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 08:43:43 -0500

Alan DeKok writes...

> The document no longer relies on traditional RADIUS dictionaries
> to motivate its recommendations.  It no longer discusses *any* 
> processing model of RADIUS, other than to say that systems other
> than RADIUS may use the data produced by RADIUS.
> 
>   All it says is "prefer simple types to complex ones, but allow
> complex ones if everything else is worse".  And it says that change
> has risk.
> 

My concern with this solution is that it's more than an editorial revision,
and potentially overturns some elements of RADEXT WG, IETF and IESG
consensus.  If we are to consider changing the the document in such a way,
can this *really* be handled as an RFC Editor Note?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 15:00:58 +0100

> can this *really* be handled as an RFC Editor Note?

  It's also a way to show that the alleged large problems can be
completely resolved with small changes.

  If the fixes are so small, the problems cannot be that large.

  Alan Dekok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 19 Jan 2010 08:48:13 -0800

Do these changes address Issue #325?  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan DeKok
Sent: Tuesday, January 19, 2010 5:25 AM
To: 'radext mailing list'
Subject: Proposed resolution to guidelines document

  Changes are:

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 18:12:24 +0100

> Do these changes address Issue #325?  

  Comments:

  (A) addressed by updated text on "new" data types, rather than
"complex" types

  (B) addressed by moving the text to the security section, and
replacing discussion of "application" with "other systems".  Also
addressed security issues of complex types by noting more clearly that
*change* has security implications.

  (C) previously fixed

  (D) Not addressed.  We seem to disagree on the utility of the
recommendations.

  (E) previously answered && acknowledged as closed on-list.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Jan 2010 14:29:36 +0100

>   (D) Not addressed.  We seem to disagree on the utility of the

  How about adding some text to Section 2.1.3:

  There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located.  Each situation has to be decided on a
case-by-case basis.

  Alan DeKok.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 20 Jan 2010 07:58:00 -0800

Alan said:

"  There may be situations where complex attributes are beneficial,
because they reduce complexity in the non-RADIUS systems.
Unfortunately, there are no "hard and fast" rules for where the
complexity would best be located.  Each situation has to be decided on a
case-by-case basis."

[BA] Is this referring to the "opaque data" case?  Elsewhere in 2.1.3 it
talks about these attribute being defined as type "String":

   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 those fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Jan 2010 17:50:43 +0100

Bernard Aboba wrote:
> [BA] Is this referring to the "opaque data" case?

  Not really.  There are cases discussed in Appendix B where it's deemed
"acceptable" to have non-opaque data in complex types.

  I think the discussion on the list highlights that we could make it
clearer that the SHOULD recommendations for using simple data types are
not "bats with which to attack people".

  Adding text to explain the meaning of "SHOULD" in excruciating detail
could negate a lot of the worries about the terrible impact of
recommending simplicity.

  Alan DeKok.

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 21 Jan 2010 21:03:19 -0800

I think the suggested text is helpful.  

Joe