From owner-radiusext@ops.ietf.org Fri Dec 4 02:11:15 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E9743A691C for ; Fri, 4 Dec 2009 02:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.372 X-Spam-Level: X-Spam-Status: No, score=-1.372 tagged_above=-999 required=5 tests=[AWL=-0.877, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXB+6wOAio3i for ; Fri, 4 Dec 2009 02:11:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 744E63A6906 for ; Fri, 4 Dec 2009 02:11:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGV2w-000JUh-Lm for radiusext-data0@psg.com; Fri, 04 Dec 2009 10:05:54 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGV2w-000JUW-1N for radiusext@ops.ietf.org; Fri, 04 Dec 2009 10:05:54 +0000 Message-ID: <4B18DEFD.9040004@deployingradius.com> Date: Fri, 04 Dec 2009 11:05:49 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: Revised Resolution to Issue 319 References: <4AEB2E57.7040007@deployingradius.com> <4AEB42AB.8090505@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > In Section 1.3: > > The uses of "MUST" and "MUST NOT" in this document are limited to (a) > requirements to follow the IETF process for IETF standards, and (b) > quotes from other documents. As a result, the use of MUST and MUST > NOT in this document does not prescribe new mandatory behavior within > implementations. > > Wasn't this to have gone in Section 1.2? OK. > Section 2.1.1 states: ... > Yet Section A.1.1 says: > > * Interface-Id (8 octets in network byte order) > > > Should this say: > > * Interface-Id (8 octet string in network byte order) Yes. I'll post an updated draft shortly. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 4 02:17:41 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B515C3A691C for ; Fri, 4 Dec 2009 02:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.196 X-Spam-Level: X-Spam-Status: No, score=-102.196 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK+VX4p9egXc for ; Fri, 4 Dec 2009 02:17:37 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EC0C23A69D8 for ; Fri, 4 Dec 2009 02:17:35 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGVBg-000KOO-5d for radiusext-data0@psg.com; Fri, 04 Dec 2009 10:14:56 +0000 Received: from [2001:1890:1112:1::20] (helo=mail.ietf.org) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGVBf-000KO9-2Y for radiusext@ops.ietf.org; Fri, 04 Dec 2009 10:14:55 +0000 Received: by core3.amsl.com (Postfix, from userid 0) id 2D2123A68B3; Fri, 4 Dec 2009 02:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091204101502.2D2123A68B3@core3.amsl.com> Date: Fri, 4 Dec 2009 02:15:02 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --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 : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-10.txt Pages : 38 Date : 2009-12-04 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-radext-design-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-04020741.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 4 07:26:29 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8721528C0FF for ; Fri, 4 Dec 2009 07:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.527 X-Spam-Level: X-Spam-Status: No, score=0.527 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCTKnM-0Pc2U for ; Fri, 4 Dec 2009 07:26:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3A7F728C0E6 for ; Fri, 4 Dec 2009 07:26:26 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGZz6-000NNN-Mf for radiusext-data0@psg.com; Fri, 04 Dec 2009 15:22:16 +0000 Received: from [65.55.116.33] (helo=blu0-omc1-s22.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NGZz4-000NMy-2P for radiusext@ops.ietf.org; Fri, 04 Dec 2009 15:22:14 +0000 Received: from BLU137-DS7 ([65.55.116.8]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Dec 2009 07:22:13 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Subject: "Last Look" at the RADIUS Design Guidelines document Date: Fri, 4 Dec 2009 07:22:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CA74B2.8AD695C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp09Zho7Z6q9obOQnuMatn86znM0Q== Content-Language: en-us X-OriginalArrivalTime: 04 Dec 2009 15:22:13.0825 (UTC) FILETIME=[8E64A310:01CA74F5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0038_01CA74B2.8AD695C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is announcing a "Last Look" at the RADIUS Design Guidelines document. This "Last Look" will last until Friday, December 18, 2009. Since the Design Guidelines document has already completed RADEXT WG last call (twice), IETF last call, and IESG review (no outstanding DISCUSS comments), the purpose of this "Last Look" is to confirm that all Issues brought up in IETF last call and the IESG Issues list (as noted in Draft Tracker) have been resolved. The document is available here: http://www.ietf.org/id/draft-ietf-radext-design-10.txt Please send comments relating to the document to the RADEXT WG mailing list (radiusext@ietf.org). As usual, if you are submitting Issues, please utilize the Issue format described in the RADIUS WG Issue list (http://www.drizzle.com/~aboba/RADEXT ) ------=_NextPart_000_0038_01CA74B2.8AD695C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is announcing a “Last Look” at the = RADIUS Design Guidelines document.  This “Last Look” will last = until

Friday, December 18, 2009. 

 

Since the Design Guidelines document has already = completed RADEXT WG last call (twice), IETF last call,

and IESG review (no outstanding DISCUSS comments), = the purpose of this “Last Look” is to confirm = that

all Issues brought up in IETF last call and the = IESG Issues list (as noted in Draft Tracker) have been resolved.

 

The document is available here:

http://ww= w.ietf.org/id/draft-ietf-radext-design-10.txt

 

Please send comments relating to the document to = the RADEXT WG mailing list (radiusext@ietf.org). =

As usual, if you are submitting Issues, please = utilize the Issue format described in the RADIUS WG

Issue list (http://www.drizzle.com/~abo= ba/RADEXT )

 

------=_NextPart_000_0038_01CA74B2.8AD695C0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 18 20:27:24 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E22B3A67A7 for ; Fri, 18 Dec 2009 20:27:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.504 X-Spam-Level: X-Spam-Status: No, score=-106.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 428x8zsygztX for ; Fri, 18 Dec 2009 20:27:23 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 28EA13A66B4 for ; Fri, 18 Dec 2009 20:27:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NLqlP-000LKn-7i for radiusext-data0@psg.com; Sat, 19 Dec 2009 04:17:55 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NLqlH-000LJy-Mp for radiusext@ops.ietf.org; Sat, 19 Dec 2009 04:17:47 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFjiK0urR7Hu/2dsb2JhbAC/EZcHhC4E X-IronPort-AV: E=Sophos;i="4.47,422,1257120000"; d="scan'208";a="452653295" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 19 Dec 2009 04:17:46 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBJ4Hk8K019190; Sat, 19 Dec 2009 04:17:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Dec 2009 20:17:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Fri, 18 Dec 2009 20:17:45 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Last Look" at the RADIUS Design Guidelines document Thread-Index: Acp09Zho7Z6q9obOQnuMatn86znM0QLaM+Uw References: From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , X-OriginalArrivalTime: 19 Dec 2009 04:17:46.0897 (UTC) FILETIME=[380C7010:01CA8062] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: I gave the RADIUS Design Guidelines document a "last look". I had not looked at the document for a while and have not really been following discussions on the document. In general I think the document provides some useful information. There are a few places where I had issues with the document. I'm not sure if these are part of the IESG and Last call comments or not. =20 A. Section 2.1.3 =20 I did not find the discussion of complex attributes very compelling. Its not clear to me what the difference between string and complex attribute is. If your RADIUS server supports string then it seems that it would be possible to support a complex attribute without requiring a "code change". =20 B. Section 2.1.4 I'm not really sure what this section is trying to accomplish. It seems to be a lot about deployment guidelines instead of design guidelines. I'm also not convinced that the use of complex attributes makes things less secure. It does not seem this section belongs in this document.=20 C. Section 5 This section references section 2.1.4, however it does not seem there is anything actionable for a protocol document to do with section 2.1.4.=20 D. Section A.2.2 Since I did not agree with the motivation for section 2.1.3, I don't find this section compelling.=20 E. Section A.2.1 I don't see how defining a polymorphic attribute as multiple attributes helps. I'm probably missing something, do you have an example?=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, December 04, 2009 7:23 AM > To: radiusext@ops.ietf.org > Subject: "Last Look" at the RADIUS Design Guidelines document >=20 > This is announcing a "Last Look" at the RADIUS Design=20 > Guidelines document. This "Last Look" will last until=20 >=20 > Friday, December 18, 2009. =20 >=20 > =20 >=20 > Since the Design Guidelines document has already completed=20 > RADEXT WG last call (twice), IETF last call, >=20 > and IESG review (no outstanding DISCUSS comments), the=20 > purpose of this "Last Look" is to confirm that >=20 > all Issues brought up in IETF last call and the IESG Issues=20 > list (as noted in Draft Tracker) have been resolved.=20 >=20 > =20 >=20 > The document is available here: >=20 > http://www.ietf.org/id/draft-ietf-radext-design-10.txt >=20 > =20 >=20 > Please send comments relating to the document to the RADEXT=20 > WG mailing list (radiusext@ietf.org).=20 >=20 > As usual, if you are submitting Issues, please utilize the=20 > Issue format described in the RADIUS WG >=20 > Issue list (http://www.drizzle.com/~aboba/RADEXT ) >=20 > =20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Dec 18 23:54:55 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 485DB3A6942 for ; Fri, 18 Dec 2009 23:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.389 X-Spam-Level: X-Spam-Status: No, score=-104.389 tagged_above=-999 required=5 tests=[AWL=2.210, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhbOYCGHvXbs for ; Fri, 18 Dec 2009 23:54:54 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 383CA3A68E5 for ; Fri, 18 Dec 2009 23:54:54 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NLu3y-000E81-2j for radiusext-data0@psg.com; Sat, 19 Dec 2009 07:49:18 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NLu3r-000E7L-Dk for radiusext@ops.ietf.org; Sat, 19 Dec 2009 07:49:11 +0000 Message-ID: <4B2C8571.8020800@deployingradius.com> Date: Sat, 19 Dec 2009 08:49:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: "Last Look" at the RADIUS Design Guidelines document References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Joseph Salowey (jsalowey) wrote: > A. Section 2.1.3 > > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". It depends on what you mean by "support". There is no question that a RADIUS server can *transport* any complex attribute if the attribute is treated as type "string". However, having the RADIUS server parse that attribute requires much more work. Perhaps a better argument is to ask "why?". i.e. Why is a data structure being sent when the contents could have been broken out into separate attributes with standard data types? The document tries to suggest that where possible, complex attributes should be replaced by attributes with standard data types. Where that is not possible, complex attributes could be used. > B. Section 2.1.4 > > I'm not really sure what this section is trying to accomplish. It seems > to be a lot about deployment guidelines instead of design guidelines. > I'm also not convinced that the use of complex attributes makes things > less secure. It does not seem this section belongs in this document. Using complex attributes does not make things less secure. *Code changes* make things less secure. The intent of this section is to explain some of the reasons behind the recommendations, rather than to have them appear out of thin air. > C. Section 5 > > This section references section 2.1.4, however it does not seem there is > anything actionable for a protocol document to do with section 2.1.4. I think the reference should be to 2.1.3. > D. Section A.2.2 > > Since I did not agree with the motivation for section 2.1.3, I don't > find this section compelling. This is one point where I strongly disagree. It can be summarized as "keep things simple". Would you counter this section by suggesting it's a *good* idea to have complex attributes, where standard ones would do just as well? If so, why? > E. Section A.2.1 > > I don't see how defining a polymorphic attribute as multiple attributes > helps. I'm probably missing something, do you have an example? See Section 3.2 for a larger explanation. In short: - Attribute X means "integer", unless there is another attribute Y in the packet, in which case Attribute X means "mac address" Both the size and contents of the attribute changes. There's really no good reason. Instead, two standard attributes can be used, with no magical meanings. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 20 21:40:42 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F03A3A6826 for ; Sun, 20 Dec 2009 21:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.512 X-Spam-Level: X-Spam-Status: No, score=-106.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlDNlPa-nB9o for ; Sun, 20 Dec 2009 21:40:41 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 6CC9F3A67B6 for ; Sun, 20 Dec 2009 21:40:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMas5-000Hlt-6J for radiusext-data0@psg.com; Mon, 21 Dec 2009 05:31:53 +0000 Received: from [171.71.176.117] (helo=sj-iport-6.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NMary-000HlU-UY for radiusext@ops.ietf.org; Mon, 21 Dec 2009 05:31:47 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO6WLkurR7Hu/2dsb2JhbAC9dZUyhC4E X-IronPort-AV: E=Sophos;i="4.47,429,1257120000"; d="scan'208";a="453630320" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 Dec 2009 05:31:46 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nBL5Vk1H021833; Mon, 21 Dec 2009 05:31:46 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Dec 2009 21:31:46 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 21:31:44 -0800 Message-ID: In-Reply-To: <4B2C8571.8020800@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "Last Look" at the RADIUS Design Guidelines document Thread-Index: AcqAf8Pf+3gF9QjuQw+1pOpfdHWRtABexdZw References: <4B2C8571.8020800@deployingradius.com> From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" Cc: "Bernard Aboba" , X-OriginalArrivalTime: 21 Dec 2009 05:31:46.0208 (UTC) FILETIME=[E2E90A00:01CA81FE] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Friday, December 18, 2009 11:49 PM > To: Joseph Salowey (jsalowey) > Cc: Bernard Aboba; radiusext@ops.ietf.org > Subject: Re: "Last Look" at the RADIUS Design Guidelines document >=20 > Joseph Salowey (jsalowey) wrote: > > A. Section 2.1.3 > >=20 > > I did not find the discussion of complex attributes very compelling. > > Its not clear to me what the difference between string and complex=20 > > attribute is. If your RADIUS server supports string then it seems=20 > > that it would be possible to support a complex attribute without=20 > > requiring a "code change". >=20 > It depends on what you mean by "support". >=20 > There is no question that a RADIUS server can *transport*=20 > any complex attribute if the attribute is treated as type=20 > "string". However, having the RADIUS server parse that=20 > attribute requires much more work. >=20 [Joe] It seems a type "string" attribute would have the same parsing requirement. =20 > Perhaps a better argument is to ask "why?". i.e. Why is a=20 > data structure being sent when the contents could have been=20 > broken out into separate attributes with standard data types? >=20 [Joe] To me it seems like you are just pushing the problem around. If the RADIUS server doesn't have to validate or parse the attribute then it doesn't make a difference. If the RADIUS server does need to process it then you need code to do the validation and parsing across several basic attributes. =20 > The document tries to suggest that where possible, complex=20 > attributes should be replaced by attributes with standard=20 > data types. Where that is not possible, complex attributes=20 > could be used. > > > B. Section 2.1.4 > >=20 > > I'm not really sure what this section is trying to accomplish. It=20 > > seems to be a lot about deployment guidelines instead of=20 > design guidelines. > > I'm also not convinced that the use of complex attributes=20 > makes things=20 > > less secure. It does not seem this section belongs in this=20 > document. >=20 > Using complex attributes does not make things less secure. *Code > changes* make things less secure. >=20 [Joe] Complex attributes don't always require code changes and if you are adding several new basic attributes that need to be validated together then you need code to do that.=20 > The intent of this section is to explain some of the=20 > reasons behind the recommendations, rather than to have them=20 > appear out of thin air. >=20 > > C. Section 5 > >=20 > > This section references section 2.1.4, however it does not=20 > seem there=20 > > is anything actionable for a protocol document to do with=20 > section 2.1.4. >=20 > I think the reference should be to 2.1.3. >=20 [Joe] OK, I think that makes more sense.=20 > > D. Section A.2.2 > >=20 > > Since I did not agree with the motivation for section=20 > 2.1.3, I don't=20 > > find this section compelling. >=20 > This is one point where I strongly disagree. It can be=20 > summarized as "keep things simple". >=20 > Would you counter this section by suggesting it's a *good*=20 > idea to have complex attributes, where standard ones would do=20 > just as well? If so, why? >=20 [Joe] That does not seem to be what section A.2.2 states. It talks about whether attributes need dynamic computation or not. It seems the second and third bullet outlaw all cases, since the first covers dynamic computation and the second covers static attributes. =20 > > E. Section A.2.1 > >=20 > > I don't see how defining a polymorphic attribute as multiple=20 > > attributes helps. I'm probably missing something, do you=20 > have an example? >=20 > See Section 3.2 for a larger explanation. In short: >=20 > - Attribute X means "integer", unless there is another=20 > attribute Y in the packet, in which case Attribute X means=20 > "mac address" >=20 > Both the size and contents of the attribute changes. =20 > There's really no good reason. Instead, two standard=20 > attributes can be used, with no magical meanings. >=20 [Joe] OK, got it.=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Dec 20 23:51:53 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2AEBE3A6860 for ; Sun, 20 Dec 2009 23:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.647 X-Spam-Level: X-Spam-Status: No, score=-103.647 tagged_above=-999 required=5 tests=[AWL=2.951, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CCvKYEBjJif for ; Sun, 20 Dec 2009 23:51:51 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 67F8B28C0D7 for ; Sun, 20 Dec 2009 23:51:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMcvG-0002uF-3T for radiusext-data0@psg.com; Mon, 21 Dec 2009 07:43:18 +0000 Received: from [65.55.111.142] (helo=blu0-omc4-s3.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NMcvA-0002th-AU for radiusext@ops.ietf.org; Mon, 21 Dec 2009 07:43:12 +0000 Received: from BLU137-W2 ([65.55.111.135]) by blu0-omc4-s3.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Dec 2009 23:43:12 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a1e3b434-d744-461d-aa49-3c97ae410fda_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 23:43:11 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2009 07:43:12.0074 (UTC) FILETIME=[3F40B2A0:01CA8211] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_a1e3b434-d744-461d-aa49-3c97ae410fda_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > A. Section 2.1.3 =20 >=20 > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". =20 There are several distinct aspects that are discussed in Section 2.1.3: a. Enabling a RADIUS server to send a complex attribute=3B b. Enabling a RADIUS server to receive a complex attribute=3B=20 c. Enabling a RADIUS client to send a complex attribute=3B d. Enabling a RADIUS client to receive a complex attribute.=20 However=2C rather than examining each of these aspects separately=2C the se= ction appears to switch between the aspects=2C sometimes within the same paragrap= h.=20 As a result=2C it is not always clear what aspects are being discussed. Si= nce the arguments made depend on what aspect is being discussed=2C it can be hard t= o follow.=20 For example=2C the second paragraph of Section 2.1.3 seems to focus largely= on a). As you say=2C in this case=2C a RADIUS server can send a complex attribute without a code= change=20 (merely by encoding it as a string). =20 However=2C while the first bullet appears to apply to aspect a) (e.g. ease = of data entry)=2C=20 the second and third bullets appear to relate either to aspect b) or d). =20 On reading the second and third bullets=2C I'm not sure which aspect is bei= ng referred to.=20 In paragraph 4=2C it is noted that RADIUS clients require code changes to s= upport any=20 attribute=2C regardless of whether it is complex or not. Therefore one ca= nnot make an argument about additional code changes arising from aspect c) or d)=2C o= nly=20 aspect b).=20 Presumably=2C with respect to aspect d)=2C a RADIUS client receiving a comp= lex attribute=20 would also implement the required parsing and validation routes for that=20 attribute (if not=2C then the client would either ignore the attribute=2C o= r possibly reject the=20 Access-Response). So on reading this=2C I'm not sure that the "additional= error checking" applies to=2C exactly.=20 In reading paragraph 3 about server code changes=2C there does not appear t= o be a distinction between aspect a (in which code changes are not required) and a= spect b (in which a code change would be necessary). =20 Paragraph 4 does make the distinction between aspects c and d.=20 However=2C paragraph 6 mixes aspects a) and b). Paragraph 4 seems to asser= t that code changes are not required for aspect a)=2C while this paragraph does seem to= say that this is possible=2C though it is not clear in what circumstances this = would be necessary.=20 = --_a1e3b434-d744-461d-aa49-3c97ae410fda_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B A. Section 2.1.3
>=3B
>=3B I did not find the discussio= n of complex attributes very compelling.
>=3B Its not clear to me what= the difference between string and complex
>=3B attribute is. If your= RADIUS server supports string then it seems that
>=3B it would be pos= sible to support a complex attribute without requiring a
>=3B "code ch= ange".

There are several distinct aspects that are discussed in Se= ction 2.1.3:

a. Enabling a RADIUS server to send a complex attribute= =3B
b. Enabling a RADIUS server to receive a complex attribute=3B
c.= Enabling a RADIUS client to send a complex attribute=3B
d. Enabling a R= ADIUS client to receive a complex attribute.

However=2C rather than= examining each of these aspects separately=2C the section
appears to sw= itch between the aspects=2C sometimes within the same paragraph.
As a r= esult=2C it is not always clear what aspects are being discussed. =3B S= ince the
arguments made depend on what aspect is being discussed=2C it c= an be hard to
follow.

For example=2C the second paragraph of Sec= tion 2.1.3 seems to focus largely on a). =3B As you say=2C
in this c= ase=2C a RADIUS server can send a complex attribute without a code change <= br>(merely by encoding it as a string). =3B

However=2C while th= e first bullet appears to apply to aspect a) (e.g. ease of data entry)=2C <= br>the second and third bullets appear to relate either to aspect b) or d).=  =3B

On reading the second and third bullets=2C I'm not sure wh= ich aspect is being referred to.
In paragraph 4=2C it is noted that RAD= IUS clients require code changes to support any
attribute=2C regardless= of whether it is complex or not. =3B =3B Therefore one cannot make=
an argument about additional code changes arising from aspect c) or d)= =2C only
aspect b).

Presumably=2C with respect to aspect d)=2C = a RADIUS client receiving a complex attribute
would also implement the = required parsing and validation routes for that
attribute (if not=2C th= en the client would either ignore the attribute=2C or possibly reject the <= br>Access-Response). =3B =3B So on reading this=2C I'm not sure tha= t the "additional error checking"
applies to=2C exactly.

In read= ing paragraph 3 about server code changes=2C there does not appear to be a<= br>distinction between aspect a (in which code changes are not required) an= d aspect b
(in which a code change would be necessary). =3B

= Paragraph 4 does make the distinction between aspects c and d.

Howe= ver=2C paragraph 6 mixes aspects a) and b). =3B Paragraph 4 seems to as= sert that code
changes are not required for aspect a)=2C while this para= graph does seem to say
that this is possible=2C though it is not clear i= n what circumstances this would be
necessary.
= --_a1e3b434-d744-461d-aa49-3c97ae410fda_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 21 00:02:06 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 592DE3A69C6 for ; Mon, 21 Dec 2009 00:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.76 X-Spam-Level: X-Spam-Status: No, score=-102.76 tagged_above=-999 required=5 tests=[AWL=1.979, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2Ie6AeSvoJa for ; Mon, 21 Dec 2009 00:02:05 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id DC94E3A689B for ; Mon, 21 Dec 2009 00:02:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMd8L-0004Mp-Mm for radiusext-data0@psg.com; Mon, 21 Dec 2009 07:56:49 +0000 Received: from [65.55.111.164] (helo=blu0-omc4-s25.blu0.hotmail.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NMd86-0004Le-S3 for radiusext@ops.ietf.org; Mon, 21 Dec 2009 07:56:34 +0000 Received: from BLU137-W31 ([65.55.111.136]) by blu0-omc4-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 20 Dec 2009 23:56:34 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_6666a5ed-cc32-42ea-933d-c9eaa80ea201_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 23:56:34 -0800 Importance: Normal In-Reply-To: References: , MIME-Version: 1.0 X-OriginalArrivalTime: 21 Dec 2009 07:56:34.0729 (UTC) FILETIME=[1DAC2190:01CA8213] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > B. Section 2.1.4 >=20 > I'm not really sure what this section is trying to accomplish. It seems > to be a lot about deployment guidelines instead of design guidelines. > I'm also not convinced that the use of complex attributes makes things > less secure. It does not seem this section belongs in this document.=20 I think this section is trying to make a point relating to the security properties of complex or opaque attributes=2C particularly in the case of attributes sent from the RADIUS client to server. =20 However=2C it occurs to me that the security risks depend quite a bit on how the complex or opaque attribute is structured. An "opaque" attribut= e that=20 contains complex structures such as ASN.1 or XML would represent a considerably larger security risk than say=2C a complex attribute=20 including multiple 32-bit fields.=20 It also occurs to me that some of the same security risks could be present in simple attributes. For example=2C even though a "string" attribute might be widely implemented=2C if an attribute incorporates a new concatenation mechanism=2C then such an attribute might introduce a buffer-overun vulnerability that would be unlikely to occur in the case of a complex attribute consisting of fixed fields.=20 = --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B B. Section 2.1.4
>=3B
>=3B I'm not really sure what t= his section is trying to accomplish. It seems
>=3B to be a lot about = deployment guidelines instead of design guidelines.
>=3B I'm also not = convinced that the use of complex attributes makes things
>=3B less se= cure. It does not seem this section belongs in this document.

I th= ink this section is trying to make a point relating to the security
prop= erties of complex or opaque attributes=2C particularly in the case of
at= tributes sent from the RADIUS client to server. =3B

However=2C = it occurs to me that the security risks depend quite a bit
on how the co= mplex or opaque attribute is structured. =3B An "opaque" attribute that=
contains complex structures such as ASN.1 or XML would represent
a = considerably larger security risk than say=2C a complex attribute
inclu= ding multiple 32-bit fields.

It also occurs to me that some of the = same security risks could be
present in simple attributes. =3B For e= xample=2C even though a "string"
attribute might be widely implemented= =2C if an attribute incorporates
a new concatenation mechanism=2C then s= uch an attribute might
introduce a buffer-overun vulnerability that woul= d be unlikely
to occur in the case of a complex attribute consisting of = fixed fields.




= --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 21 00:18:28 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0813A68A7 for ; Mon, 21 Dec 2009 00:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.527 X-Spam-Level: X-Spam-Status: No, score=-104.527 tagged_above=-999 required=5 tests=[AWL=2.072, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nS1aWAGmtIlf for ; Mon, 21 Dec 2009 00:18:13 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1762D3A69D3 for ; Mon, 21 Dec 2009 00:17:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMdOJ-0006Qf-Iu for radiusext-data0@psg.com; Mon, 21 Dec 2009 08:13:19 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NMdOD-0006P8-F5 for radiusext@ops.ietf.org; Mon, 21 Dec 2009 08:13:13 +0000 Message-ID: <4B2F2E17.2080301@deployingradius.com> Date: Mon, 21 Dec 2009 09:13:11 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: "Last Look" at the RADIUS Design Guidelines document References: <4B2C8571.8020800@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Joseph Salowey (jsalowey) wrote: >> There is no question that a RADIUS server can *transport* >> any complex attribute if the attribute is treated as type >> "string". However, having the RADIUS server parse that >> attribute requires much more work. >> > [Joe] It seems a type "string" attribute would have the same parsing > requirement. If the RADIUS server needs to understand it, and it carries a complex data type. e.g. There are no parsing requirements for the Proxy-State attribute. It is a "string" attribute, but the contents are treated as an opaque blob by proxies and clients. > [Joe] To me it seems like you are just pushing the problem around. If > the RADIUS server doesn't have to validate or parse the attribute then > it doesn't make a difference. If the RADIUS server does need to process > it then you need code to do the validation and parsing across several > basic attributes. Partly. The validation and parsing of the basic data types has already been done. Any additional validation and parsing is not needed at the RADIUS attribute level. Instead, it is needed to ensure that the right set of attributes is sent and/or received. > [Joe] Complex attributes don't always require code changes and if you > are adding several new basic attributes that need to be validated > together then you need code to do that. Of course. >> Would you counter this section by suggesting it's a *good* >> idea to have complex attributes, where standard ones would do >> just as well? If so, why? >> > [Joe] That does not seem to be what section A.2.2 states. It talks > about whether attributes need dynamic computation or not. It seems the > second and third bullet outlaw all cases, since the first covers dynamic > computation and the second covers static attributes. I think you have the bullet references wrong... but I understand your point. However, the section is trying to say: a) re-using existing complex types is likely OK b) creating new complex types for security is likely OK c) transporting complex types that can be ignored RADIUS is likely OK (e.g. EAP-Message) d) If the complex type can be instead be replaced by multiple attributes of the basic types, this is the preferred approach e) Anything else is likely not a good use of RADIUS Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Dec 21 00:26:29 2009 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A7963A690C for ; Mon, 21 Dec 2009 00:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.649 X-Spam-Level: X-Spam-Status: No, score=-104.649 tagged_above=-999 required=5 tests=[AWL=1.950, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW3xZrNR2jSX for ; Mon, 21 Dec 2009 00:26:28 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 090333A69C6 for ; Mon, 21 Dec 2009 00:26:27 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NMdTz-00071Q-03 for radiusext-data0@psg.com; Mon, 21 Dec 2009 08:19:11 +0000 Received: from [88.191.76.128] (helo=liberty.deployingradius.com) by psg.com with esmtp (Exim 4.70 (FreeBSD)) (envelope-from ) id 1NMdTt-00070r-Bh for radiusext@ops.ietf.org; Mon, 21 Dec 2009 08:19:05 +0000 Message-ID: <4B2F2F78.5080209@deployingradius.com> Date: Mon, 21 Dec 2009 09:19:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: Re: "Last Look" at the RADIUS Design Guidelines document References: , In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > It also occurs to me that some of the same security risks could be > present in simple attributes. For example, even though a "string" > attribute might be widely implemented, if an attribute incorporates > a new concatenation mechanism, Then it involves changes to the basic operating model of RADIUS, where attributes are independent. This requires code changes, and all that implies. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 21 Dec 2009 08:19:29 +0000 Message-ID: <4B2F2F78.5080209@deployingradius.com> Date: Mon, 21 Dec 2009 09:19:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: Re: "Last Look" at the RADIUS Design Guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > It also occurs to me that some of the same security risks could be > present in simple attributes. For example, even though a "string" > attribute might be widely implemented, if an attribute incorporates > a new concatenation mechanism, Then it involves changes to the basic operating model of RADIUS, where attributes are independent. This requires code changes, and all that implies. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 21 Dec 2009 08:13:43 +0000 Message-ID: <4B2F2E17.2080301@deployingradius.com> Date: Mon, 21 Dec 2009 09:13:11 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: "Last Look" at the RADIUS Design Guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joseph Salowey (jsalowey) wrote: >> There is no question that a RADIUS server can *transport* >> any complex attribute if the attribute is treated as type >> "string". However, having the RADIUS server parse that >> attribute requires much more work. >> > [Joe] It seems a type "string" attribute would have the same parsing > requirement. If the RADIUS server needs to understand it, and it carries a complex data type. e.g. There are no parsing requirements for the Proxy-State attribute. It is a "string" attribute, but the contents are treated as an opaque blob by proxies and clients. > [Joe] To me it seems like you are just pushing the problem around. If > the RADIUS server doesn't have to validate or parse the attribute then > it doesn't make a difference. If the RADIUS server does need to process > it then you need code to do the validation and parsing across several > basic attributes. Partly. The validation and parsing of the basic data types has already been done. Any additional validation and parsing is not needed at the RADIUS attribute level. Instead, it is needed to ensure that the right set of attributes is sent and/or received. > [Joe] Complex attributes don't always require code changes and if you > are adding several new basic attributes that need to be validated > together then you need code to do that. Of course. >> Would you counter this section by suggesting it's a *good* >> idea to have complex attributes, where standard ones would do >> just as well? If so, why? >> > [Joe] That does not seem to be what section A.2.2 states. It talks > about whether attributes need dynamic computation or not. It seems the > second and third bullet outlaw all cases, since the first covers dynamic > computation and the second covers static attributes. I think you have the bullet references wrong... but I understand your point. However, the section is trying to say: a) re-using existing complex types is likely OK b) creating new complex types for security is likely OK c) transporting complex types that can be ignored RADIUS is likely OK (e.g. EAP-Message) d) If the complex type can be instead be replaced by multiple attributes of the basic types, this is the preferred approach e) Anything else is likely not a good use of RADIUS Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 21 Dec 2009 07:57:09 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_6666a5ed-cc32-42ea-933d-c9eaa80ea201_" From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 23:56:34 -0800 MIME-Version: 1.0 --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > B. Section 2.1.4 >=20 > I'm not really sure what this section is trying to accomplish. It seems > to be a lot about deployment guidelines instead of design guidelines. > I'm also not convinced that the use of complex attributes makes things > less secure. It does not seem this section belongs in this document.=20 I think this section is trying to make a point relating to the security properties of complex or opaque attributes=2C particularly in the case of attributes sent from the RADIUS client to server. =20 However=2C it occurs to me that the security risks depend quite a bit on how the complex or opaque attribute is structured. An "opaque" attribut= e that=20 contains complex structures such as ASN.1 or XML would represent a considerably larger security risk than say=2C a complex attribute=20 including multiple 32-bit fields.=20 It also occurs to me that some of the same security risks could be present in simple attributes. For example=2C even though a "string" attribute might be widely implemented=2C if an attribute incorporates a new concatenation mechanism=2C then such an attribute might introduce a buffer-overun vulnerability that would be unlikely to occur in the case of a complex attribute consisting of fixed fields.=20 = --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
>=3B B. Section 2.1.4
>=3B
>=3B I'm not really sure what t= his section is trying to accomplish. It seems
>=3B to be a lot about = deployment guidelines instead of design guidelines.
>=3B I'm also not = convinced that the use of complex attributes makes things
>=3B less se= cure. It does not seem this section belongs in this document.

I th= ink this section is trying to make a point relating to the security
prop= erties of complex or opaque attributes=2C particularly in the case of
at= tributes sent from the RADIUS client to server. =3B

However=2C = it occurs to me that the security risks depend quite a bit
on how the co= mplex or opaque attribute is structured. =3B An "opaque" attribute that=
contains complex structures such as ASN.1 or XML would represent
a = considerably larger security risk than say=2C a complex attribute
inclu= ding multiple 32-bit fields.

It also occurs to me that some of the = same security risks could be
present in simple attributes. =3B For e= xample=2C even though a "string"
attribute might be widely implemented= =2C if an attribute incorporates
a new concatenation mechanism=2C then s= uch an attribute might
introduce a buffer-overun vulnerability that woul= d be unlikely
to occur in the case of a complex attribute consisting of = fixed fields.




= --_6666a5ed-cc32-42ea-933d-c9eaa80ea201_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 21 Dec 2009 07:44:07 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_a1e3b434-d744-461d-aa49-3c97ae410fda_" From: Bernard Aboba To: "Joseph Salowey (jsalowey)" , "radiusext@ops.ietf.org" Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 23:43:11 -0800 MIME-Version: 1.0 --_a1e3b434-d744-461d-aa49-3c97ae410fda_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > A. Section 2.1.3 =20 >=20 > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". =20 There are several distinct aspects that are discussed in Section 2.1.3: a. Enabling a RADIUS server to send a complex attribute=3B b. Enabling a RADIUS server to receive a complex attribute=3B=20 c. Enabling a RADIUS client to send a complex attribute=3B d. Enabling a RADIUS client to receive a complex attribute.=20 However=2C rather than examining each of these aspects separately=2C the se= ction appears to switch between the aspects=2C sometimes within the same paragrap= h.=20 As a result=2C it is not always clear what aspects are being discussed. Si= nce the arguments made depend on what aspect is being discussed=2C it can be hard t= o follow.=20 For example=2C the second paragraph of Section 2.1.3 seems to focus largely= on a). As you say=2C in this case=2C a RADIUS server can send a complex attribute without a code= change=20 (merely by encoding it as a string). =20 However=2C while the first bullet appears to apply to aspect a) (e.g. ease = of data entry)=2C=20 the second and third bullets appear to relate either to aspect b) or d). =20 On reading the second and third bullets=2C I'm not sure which aspect is bei= ng referred to.=20 In paragraph 4=2C it is noted that RADIUS clients require code changes to s= upport any=20 attribute=2C regardless of whether it is complex or not. Therefore one ca= nnot make an argument about additional code changes arising from aspect c) or d)=2C o= nly=20 aspect b).=20 Presumably=2C with respect to aspect d)=2C a RADIUS client receiving a comp= lex attribute=20 would also implement the required parsing and validation routes for that=20 attribute (if not=2C then the client would either ignore the attribute=2C o= r possibly reject the=20 Access-Response). So on reading this=2C I'm not sure that the "additional= error checking" applies to=2C exactly.=20 In reading paragraph 3 about server code changes=2C there does not appear t= o be a distinction between aspect a (in which code changes are not required) and a= spect b (in which a code change would be necessary). =20 Paragraph 4 does make the distinction between aspects c and d.=20 However=2C paragraph 6 mixes aspects a) and b). Paragraph 4 seems to asser= t that code changes are not required for aspect a)=2C while this paragraph does seem to= say that this is possible=2C though it is not clear in what circumstances this = would be necessary.=20 = --_a1e3b434-d744-461d-aa49-3c97ae410fda_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B A. Section 2.1.3
>=3B
>=3B I did not find the discussio= n of complex attributes very compelling.
>=3B Its not clear to me what= the difference between string and complex
>=3B attribute is. If your= RADIUS server supports string then it seems that
>=3B it would be pos= sible to support a complex attribute without requiring a
>=3B "code ch= ange".

There are several distinct aspects that are discussed in Se= ction 2.1.3:

a. Enabling a RADIUS server to send a complex attribute= =3B
b. Enabling a RADIUS server to receive a complex attribute=3B
c.= Enabling a RADIUS client to send a complex attribute=3B
d. Enabling a R= ADIUS client to receive a complex attribute.

However=2C rather than= examining each of these aspects separately=2C the section
appears to sw= itch between the aspects=2C sometimes within the same paragraph.
As a r= esult=2C it is not always clear what aspects are being discussed. =3B S= ince the
arguments made depend on what aspect is being discussed=2C it c= an be hard to
follow.

For example=2C the second paragraph of Sec= tion 2.1.3 seems to focus largely on a). =3B As you say=2C
in this c= ase=2C a RADIUS server can send a complex attribute without a code change <= br>(merely by encoding it as a string). =3B

However=2C while th= e first bullet appears to apply to aspect a) (e.g. ease of data entry)=2C <= br>the second and third bullets appear to relate either to aspect b) or d).=  =3B

On reading the second and third bullets=2C I'm not sure wh= ich aspect is being referred to.
In paragraph 4=2C it is noted that RAD= IUS clients require code changes to support any
attribute=2C regardless= of whether it is complex or not. =3B =3B Therefore one cannot make=
an argument about additional code changes arising from aspect c) or d)= =2C only
aspect b).

Presumably=2C with respect to aspect d)=2C = a RADIUS client receiving a complex attribute
would also implement the = required parsing and validation routes for that
attribute (if not=2C th= en the client would either ignore the attribute=2C or possibly reject the <= br>Access-Response). =3B =3B So on reading this=2C I'm not sure tha= t the "additional error checking"
applies to=2C exactly.

In read= ing paragraph 3 about server code changes=2C there does not appear to be a<= br>distinction between aspect a (in which code changes are not required) an= d aspect b
(in which a code change would be necessary). =3B

= Paragraph 4 does make the distinction between aspects c and d.

Howe= ver=2C paragraph 6 mixes aspects a) and b). =3B Paragraph 4 seems to as= sert that code
changes are not required for aspect a)=2C while this para= graph does seem to say
that this is possible=2C though it is not clear i= n what circumstances this would be
necessary.
= --_a1e3b434-d744-461d-aa49-3c97ae410fda_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 21 Dec 2009 05:33:11 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Sun, 20 Dec 2009 21:31:44 -0800 Message-ID: Thread-Topic: "Last Look" at the RADIUS Design Guidelines document Thread-Index: AcqAf8Pf+3gF9QjuQw+1pOpfdHWRtABexdZw From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" Cc: "Bernard Aboba" , =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Friday, December 18, 2009 11:49 PM > To: Joseph Salowey (jsalowey) > Cc: Bernard Aboba; radiusext@ops.ietf.org > Subject: Re: "Last Look" at the RADIUS Design Guidelines document >=20 > Joseph Salowey (jsalowey) wrote: > > A. Section 2.1.3 > >=20 > > I did not find the discussion of complex attributes very compelling. > > Its not clear to me what the difference between string and complex=20 > > attribute is. If your RADIUS server supports string then it seems=20 > > that it would be possible to support a complex attribute without=20 > > requiring a "code change". >=20 > It depends on what you mean by "support". >=20 > There is no question that a RADIUS server can *transport*=20 > any complex attribute if the attribute is treated as type=20 > "string". However, having the RADIUS server parse that=20 > attribute requires much more work. >=20 [Joe] It seems a type "string" attribute would have the same parsing requirement. =20 > Perhaps a better argument is to ask "why?". i.e. Why is a=20 > data structure being sent when the contents could have been=20 > broken out into separate attributes with standard data types? >=20 [Joe] To me it seems like you are just pushing the problem around. If the RADIUS server doesn't have to validate or parse the attribute then it doesn't make a difference. If the RADIUS server does need to process it then you need code to do the validation and parsing across several basic attributes. =20 > The document tries to suggest that where possible, complex=20 > attributes should be replaced by attributes with standard=20 > data types. Where that is not possible, complex attributes=20 > could be used. > > > B. Section 2.1.4 > >=20 > > I'm not really sure what this section is trying to accomplish. It=20 > > seems to be a lot about deployment guidelines instead of=20 > design guidelines. > > I'm also not convinced that the use of complex attributes=20 > makes things=20 > > less secure. It does not seem this section belongs in this=20 > document. >=20 > Using complex attributes does not make things less secure. *Code > changes* make things less secure. >=20 [Joe] Complex attributes don't always require code changes and if you are adding several new basic attributes that need to be validated together then you need code to do that.=20 > The intent of this section is to explain some of the=20 > reasons behind the recommendations, rather than to have them=20 > appear out of thin air. >=20 > > C. Section 5 > >=20 > > This section references section 2.1.4, however it does not=20 > seem there=20 > > is anything actionable for a protocol document to do with=20 > section 2.1.4. >=20 > I think the reference should be to 2.1.3. >=20 [Joe] OK, I think that makes more sense.=20 > > D. Section A.2.2 > >=20 > > Since I did not agree with the motivation for section=20 > 2.1.3, I don't=20 > > find this section compelling. >=20 > This is one point where I strongly disagree. It can be=20 > summarized as "keep things simple". >=20 > Would you counter this section by suggesting it's a *good*=20 > idea to have complex attributes, where standard ones would do=20 > just as well? If so, why? >=20 [Joe] That does not seem to be what section A.2.2 states. It talks about whether attributes need dynamic computation or not. It seems the second and third bullet outlaw all cases, since the first covers dynamic computation and the second covers static attributes. =20 > > E. Section A.2.1 > >=20 > > I don't see how defining a polymorphic attribute as multiple=20 > > attributes helps. I'm probably missing something, do you=20 > have an example? >=20 > See Section 3.2 for a larger explanation. In short: >=20 > - Attribute X means "integer", unless there is another=20 > attribute Y in the packet, in which case Attribute X means=20 > "mac address" >=20 > Both the size and contents of the attribute changes. =20 > There's really no good reason. Instead, two standard=20 > attributes can be used, with no magical meanings. >=20 [Joe] OK, got it.=20 > Alan DeKok. >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 19 Dec 2009 07:50:33 +0000 Message-ID: <4B2C8571.8020800@deployingradius.com> Date: Sat, 19 Dec 2009 08:49:05 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" CC: Bernard Aboba , radiusext@ops.ietf.org Subject: Re: "Last Look" at the RADIUS Design Guidelines document Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Joseph Salowey (jsalowey) wrote: > A. Section 2.1.3 > > I did not find the discussion of complex attributes very compelling. > Its not clear to me what the difference between string and complex > attribute is. If your RADIUS server supports string then it seems that > it would be possible to support a complex attribute without requiring a > "code change". It depends on what you mean by "support". There is no question that a RADIUS server can *transport* any complex attribute if the attribute is treated as type "string". However, having the RADIUS server parse that attribute requires much more work. Perhaps a better argument is to ask "why?". i.e. Why is a data structure being sent when the contents could have been broken out into separate attributes with standard data types? The document tries to suggest that where possible, complex attributes should be replaced by attributes with standard data types. Where that is not possible, complex attributes could be used. > B. Section 2.1.4 > > I'm not really sure what this section is trying to accomplish. It seems > to be a lot about deployment guidelines instead of design guidelines. > I'm also not convinced that the use of complex attributes makes things > less secure. It does not seem this section belongs in this document. Using complex attributes does not make things less secure. *Code changes* make things less secure. The intent of this section is to explain some of the reasons behind the recommendations, rather than to have them appear out of thin air. > C. Section 5 > > This section references section 2.1.4, however it does not seem there is > anything actionable for a protocol document to do with section 2.1.4. I think the reference should be to 2.1.3. > D. Section A.2.2 > > Since I did not agree with the motivation for section 2.1.3, I don't > find this section compelling. This is one point where I strongly disagree. It can be summarized as "keep things simple". Would you counter this section by suggesting it's a *good* idea to have complex attributes, where standard ones would do just as well? If so, why? > E. Section A.2.1 > > I don't see how defining a polymorphic attribute as multiple attributes > helps. I'm probably missing something, do you have an example? See Section 3.2 for a larger explanation. In short: - Attribute X means "integer", unless there is another attribute Y in the packet, in which case Attribute X means "mac address" Both the size and contents of the attribute changes. There's really no good reason. Instead, two standard attributes can be used, with no magical meanings. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 19 Dec 2009 04:19:19 +0000 Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: "Last Look" at the RADIUS Design Guidelines document Date: Fri, 18 Dec 2009 20:17:45 -0800 Message-ID: Thread-Topic: "Last Look" at the RADIUS Design Guidelines document Thread-Index: Acp09Zho7Z6q9obOQnuMatn86znM0QLaM+Uw From: "Joseph Salowey (jsalowey)" To: "Bernard Aboba" , I gave the RADIUS Design Guidelines document a "last look". I had not looked at the document for a while and have not really been following discussions on the document. In general I think the document provides some useful information. There are a few places where I had issues with the document. I'm not sure if these are part of the IESG and Last call comments or not. =20 A. Section 2.1.3 =20 I did not find the discussion of complex attributes very compelling. Its not clear to me what the difference between string and complex attribute is. If your RADIUS server supports string then it seems that it would be possible to support a complex attribute without requiring a "code change". =20 B. Section 2.1.4 I'm not really sure what this section is trying to accomplish. It seems to be a lot about deployment guidelines instead of design guidelines. I'm also not convinced that the use of complex attributes makes things less secure. It does not seem this section belongs in this document.=20 C. Section 5 This section references section 2.1.4, however it does not seem there is anything actionable for a protocol document to do with section 2.1.4.=20 D. Section A.2.2 Since I did not agree with the motivation for section 2.1.3, I don't find this section compelling.=20 E. Section A.2.1 I don't see how defining a polymorphic attribute as multiple attributes helps. I'm probably missing something, do you have an example?=20 > -----Original Message----- > From: owner-radiusext@ops.ietf.org=20 > [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba > Sent: Friday, December 04, 2009 7:23 AM > To: radiusext@ops.ietf.org > Subject: "Last Look" at the RADIUS Design Guidelines document >=20 > This is announcing a "Last Look" at the RADIUS Design=20 > Guidelines document. This "Last Look" will last until=20 >=20 > Friday, December 18, 2009. =20 >=20 > =20 >=20 > Since the Design Guidelines document has already completed=20 > RADEXT WG last call (twice), IETF last call, >=20 > and IESG review (no outstanding DISCUSS comments), the=20 > purpose of this "Last Look" is to confirm that >=20 > all Issues brought up in IETF last call and the IESG Issues=20 > list (as noted in Draft Tracker) have been resolved.=20 >=20 > =20 >=20 > The document is available here: >=20 > http://www.ietf.org/id/draft-ietf-radext-design-10.txt >=20 > =20 >=20 > Please send comments relating to the document to the RADEXT=20 > WG mailing list (radiusext@ietf.org).=20 >=20 > As usual, if you are submitting Issues, please utilize the=20 > Issue format described in the RADIUS WG >=20 > Issue list (http://www.drizzle.com/~aboba/RADEXT ) >=20 > =20 >=20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Dec 2009 15:22:50 +0000 Message-ID: From: "Bernard Aboba" To: Subject: "Last Look" at the RADIUS Design Guidelines document Date: Fri, 4 Dec 2009 07:22:30 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0038_01CA74B2.8AD695C0" Thread-Index: Acp09Zho7Z6q9obOQnuMatn86znM0Q== Content-Language: en-us ------=_NextPart_000_0038_01CA74B2.8AD695C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is announcing a "Last Look" at the RADIUS Design Guidelines document. This "Last Look" will last until Friday, December 18, 2009. Since the Design Guidelines document has already completed RADEXT WG last call (twice), IETF last call, and IESG review (no outstanding DISCUSS comments), the purpose of this "Last Look" is to confirm that all Issues brought up in IETF last call and the IESG Issues list (as noted in Draft Tracker) have been resolved. The document is available here: http://www.ietf.org/id/draft-ietf-radext-design-10.txt Please send comments relating to the document to the RADEXT WG mailing list (radiusext@ietf.org). As usual, if you are submitting Issues, please utilize the Issue format described in the RADIUS WG Issue list (http://www.drizzle.com/~aboba/RADEXT ) ------=_NextPart_000_0038_01CA74B2.8AD695C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is announcing a “Last Look” at the = RADIUS Design Guidelines document.  This “Last Look” will last = until

Friday, December 18, 2009. 

 

Since the Design Guidelines document has already = completed RADEXT WG last call (twice), IETF last call,

and IESG review (no outstanding DISCUSS comments), = the purpose of this “Last Look” is to confirm = that

all Issues brought up in IETF last call and the = IESG Issues list (as noted in Draft Tracker) have been resolved.

 

The document is available here:

http://ww= w.ietf.org/id/draft-ietf-radext-design-10.txt

 

Please send comments relating to the document to = the RADEXT WG mailing list (radiusext@ietf.org). =

As usual, if you are submitting Issues, please = utilize the Issue format described in the RADIUS WG

Issue list (http://www.drizzle.com/~abo= ba/RADEXT )

 

------=_NextPart_000_0038_01CA74B2.8AD695C0-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Dec 2009 10:15:07 +0000 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-design-10.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20091204101502.2D2123A68B3@core3.amsl.com> Date: Fri, 4 Dec 2009 02:15:02 -0800 (PST) --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 : RADIUS Design Guidelines Author(s) : G. Weber, A. DeKok Filename : draft-ietf-radext-design-10.txt Pages : 38 Date : 2009-12-04 This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, both within the IETF as well as other Standards Development Organizations (SDOs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-design-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ 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: Message/External-body; name="draft-ietf-radext-design-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-12-04020741.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Dec 2009 10:06:55 +0000 Message-ID: <4B18DEFD.9040004@deployingradius.com> Date: Fri, 04 Dec 2009 11:05:49 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Bernard Aboba CC: "radiusext@ops.ietf.org" Subject: Re: Revised Resolution to Issue 319 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > In Section 1.3: > > The uses of "MUST" and "MUST NOT" in this document are limited to (a) > requirements to follow the IETF process for IETF standards, and (b) > quotes from other documents. As a result, the use of MUST and MUST > NOT in this document does not prescribe new mandatory behavior within > implementations. > > Wasn't this to have gone in Section 1.2? OK. > Section 2.1.1 states: ... > Yet Section A.1.1 says: > > * Interface-Id (8 octets in network byte order) > > > Should this say: > > * Interface-Id (8 octet string in network byte order) Yes. I'll post an updated draft shortly. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: