Subject: Last look at "RADIUS Design Guidelines" document

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Feb 2009 08:27:40 -0800

This is an announcement of a "Last Look" at the RADIUS Design Guidelines document, prior to sending this back to the IESG for publication as a Best Current Practice (BCP). 

The document is available for inspection here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-06.txt

This "last look" will last until March 10, 2009.  Please send comments to the RADEXT WG mailing list in the Issue format used by the RADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/).

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 25 Feb 2009 12:38:38 +0100

Does the new version of the document address the issues raised by the
Secdir review? 
 
If the answer is positive it would be good to prompt the revised I-D to
the reviewer and ask him to confirm that the issues were addressed by
the document or clarified some other way. 
 
Thanks and Regards,
 
Dan

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba
	Sent: Tuesday, February 24, 2009 6:28 PM
	To: [email-masked]
	Subject: Last look at "RADIUS Design Guidelines" document

	This is an announcement of a "Last Look" at the RADIUS Design
Guidelines document, prior to sending this back to the IESG for
publication as a Best Current Practice (BCP). 

	
	This "last look" will last until March 10, 2009.  Please send
comments to the RADEXT WG mailing list in the Issue format used by the
RADEXT Issues list (http://www.drizzle.com/~aboba/RADEXT/). 

	
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>

---

From: Alan DeKok <[email-masked]>
Date: Wed, 25 Feb 2009 15:16:53 +0100

Romascanu, Dan (Dan) wrote:
> */Does the new version of the document address the issues raised by the
> Secdir review? /*

  Yes.

> *//* 
> */If the answer is positive it would be good to prompt the revised I-D
> to the reviewer and ask him to confirm that the issues were addressed by
> the document or clarified some other way. /*

  I'll send him a link.

  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: Bernard Aboba <[email-masked]>
Date: Wed, 25 Feb 2009 08:10:43 -0800

Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

This document includes quotes from pre-5738 RFCs.  Should we be using
the new "pre-5738" boilerplate?

   It is RECOMMENDED that SDOs and vendors seek review of RADIUS
   attribute specifications from the IETF.  However, when specifications
   are SDO specific, re-use existing data types, and follow these
   guidelines, they do not require IETF review.

 . . .

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  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 .  Such changes SHOULD
   NOT be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption, as noted in [RFC3575] Section
   2.1.

This would seem to suggest that support for new authentication mechanisms
can be standardized outside the IETF, as long as the guidelines are followed.
Also, the use of SHOULD NOT implies that there are circumstances in which
protocol changes or new commands can be standardized outside the IETF. Is
this what was intended?

   Note that the Vendor type field in the recommended VSA format is only
   a single octet, like the RADIUS type field.  While this limitation
   results in an efficient encoding, there are situations in which a
   vendor or SDO will eventually wish to define more than 255
   attributes.  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:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Length       |            Vendor-Id
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        Vendor-Id (cont)           |           Vendor type         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Vendor length |   Attribute-Specific...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   If additional functionality is required, the format defined in
   [EXTEN] SHOULD be used.

Since [EXTEN] defines extensions to the standard RADIUS attribute
space and this section is talking about VSAs, the reference is a bit
confusing.  Is the intent to suggest that VSAs other than type 0
can also use the [EXTEN] format?

        As a last resort, where
        the above techniques cannot be made to work, it may be possible
        to apply the techniques described in [RFC4821] to discovery the
        maximum supported RADIUS packet size on the path between a
        RADIUS client and a home server.

s/discovery/discover/

   Even though the type is Text, the rest of the description indicates
   that it is a complex attribute:

Since accounting data is typically only written to stable storage without
examination, does the reasoning against complex attributes really apply
here?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Feb 2009 09:16:29 +0100

Bernard Aboba wrote:
...
> the new "pre-5738" boilerplate?

  Likely, yes.

> can be standardized outside the IETF, as long as the guidelines are

  If it's SDO specific...

> protocol changes or new commands can be standardized outside the IETF. Is

  No.  We can change this to a MUST NOT.

  Yes.

> s/discovery/discover/

  Fixed, thanks.

> examination, does the reasoning against complex attributes really apply

  RFC 2869, Section 5.19 (Table of Attributes) indicates that
Connect-Info is permitted in Access-Request packets.  Admins would like
to use this information to perform policy checks.

  e.g. Customer X has service Y, which doesn't permit them access to the
"high bandwidth" connection.

  Right now, they have to write regular expressions to parse the
Connect-Info attribute into multiple fields, and then apply the
bandwidth checks.

  This text was added as a direct result of seeing this problem occur in
the field.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Feb 2009 08:58:03 -0800

> > can also use the [EXTEN] format?

You might say, "with a different vendor-type" to make that clear. 

> to use this information to perform policy checks.

OK.  The question still remains, though.  If an attribute is only used in
Accounting-Request packets, does the argument against complex
attributes still apply?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 26 Feb 2009 18:05:11 +0100

> You might say, "with a different vendor-type" to make that clear.

  OK.  I'll add some text to that effect.

> Accounting-Request packets, does the argument against complex

  My preference would be to say yes, especially where the contents of
that attribute are interpreted by *later* policies on the server.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 26 Feb 2009 09:23:14 -0800

> that attribute are interpreted by *later* policies on the server.

Now that we have RFC 5176, accounting data can be kept as "state" that is
later used to construct CoA/Disconnect-Requests.  Is this what you mean?