From owner-radiusext@ops.ietf.org Mon Nov 05 18:23:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpBHa-0003yz-Cg for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 05 Nov 2007 18:23:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpBHW-0008Bu-3f for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 05 Nov 2007 18:23:02 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBBV-000JCG-56 for radiusext-data@psg.com; Mon, 05 Nov 2007 23:16:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, TRACKER_ID autolearn=no version=3.2.3 Received: from [65.54.246.101] (helo=bay0-omc1-s29.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpBBK-000JBS-52 for radiusext@ops.ietf.org; Mon, 05 Nov 2007 23:16:39 +0000 Received: from hotmail.com ([207.46.8.107]) by bay0-omc1-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 15:16:33 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 5 Nov 2007 15:16:33 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 05 Nov 2007 23:16:31 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review of Management Authorization -00 document Date: Mon, 05 Nov 2007 15:16:31 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 05 Nov 2007 23:16:33.0561 (UTC) FILETIME=[E7C5B890:01C82001] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -1.3 (-) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Section 3 Framed Management means management of an entity by means of a non- interactive, non-CLI-style method. The management information is typically formatted in a binary or textual protocol, such as HTTP or SNMP. While remote management by interactive CLI sessions are carried over protocols, such as Telnet, Rlogin, and SSH, these protocols are primarily for the delivery of terminal, or pseudo-TTY services. Command Line Interface, Menu Interface, or other ASCII (UTF-8) terminal emulation interfaces are not considered to be Framed Management protocols, as used in this document. Examples of Framed Management protocols include HTTP, HTTPS, and SNMP. To support the authorization and provisioning of Framed Management access to managed entities, this document introduces a new value for the Service-Type attribute [RFC2865], and one new attribute. The new value for the Service-Type attribute is Framed-Management. The definition of this service is the provisioning of remote device management via a Framed Management protocol, as described in this section. The new attribute is Framed-Management-Protocol, the value of which specifies a particular protocol for use in the remote management session. This seems to imply that SSH would not be an acceptable value for Framed-Management-Protocol. Is that right? Section 7.2 I am not clear that all combinations of Framed-Management-Protocol and Transport-Protocol make sense. For example, are the following combinations possible? Example 1: Framed-Management-Protocol = HTTPS/TLS (3) Transport-Protocol != TLS (3) Example 2: Framed-Management-Protocol = HTTP (2) Transport-Protocol = TLS (3) How is this different from Framed-Management-Protocol = HTTPS/TLS? Example 3: Framed-Management-Protocol = SFTP (4) or SCP (5) Transport-Protocol != SSH (2) If Framed-Management-Protocol and Transport-Protocol are really orthogonal, then I'd suggest that Framed-Management-Protocol not include any implied transports and that the Transport-Protocol list be expanded. For example: Framed-Management-Protocol 1 SNMP 2 HTTP 3 FTP 4 CP Transport-Protocol 1 UDP 2 TCP 3 SSH over TCP 4 TLS over TCP 5 TLS over UDP Section 7.3 The Management-Policy-Id attribute indicates the name of the management access policy for this user. Zero or more Management- Policy-Id attributes MAY be sent in an Access-Accept packet. Identifying a policy by name allows the policy to be used on different NASes without regard to implementation details. What does it mean if multiple Management-Policy-Id attributes are included? How are the policies merged? If this is implementation-specific, isn't the result undefined? Section 8 * Service-Type (6) = Administrative (6) * Transport-Protocol (xx) = None (1) Is the Transport-Protocol really none?? Section 9 What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA- Answer or Diameter-EAP-Answer messages that indicate failure. What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005]. I'm not clear that these statements make sense because there typically is no authentication in these AAA exchanges, right? Section 12 This document contains placeholders ("TBA") for assigned numbers within the RADIUS Attributes registry, to be assigned by IANA at the time this document should be published as an RFC. Assignement of additional values for attributes defined in this document are to be processed as described in [RFC3575]. RFC 3575 specifies "First come, first served", which requires no review. Is this really what you want? -- 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 Tue Nov 06 10:45:20 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQcC-0001VV-1O for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 06 Nov 2007 10:45:20 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpQcA-0007Um-Dq for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 06 Nov 2007 10:45:20 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpQVr-000DnD-Rk for radiusext-data@psg.com; Tue, 06 Nov 2007 15:38:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IpQVc-000DlR-SF for radiusext@ops.ietf.org; Tue, 06 Nov 2007 15:38:42 +0000 Received: (qmail 26025 invoked from network); 6 Nov 2007 10:39:04 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.23.9) by gumby.elbrysnetworks.com with SMTP; 6 Nov 2007 10:39:04 -0500 From: "David B. Nelson" To: "'Bernard Aboba'" , References: Subject: RE: Review of Management Authorization -00 document Date: Tue, 6 Nov 2007 10:37:20 -0500 Organization: Elbrys Networks, Inc. Message-ID: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcggAq6EA9/fFUL9TIajw07MWHm45QAhuQIg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 I'm on the road currently, so I'll comment only briefly, and follow up later in the week. Thank you for the thoughtful and thorough review. Regards, Dave > Section 3 > > This seems to imply that SSH would not be an acceptable value for > Framed-Management-Protocol. Is that right? SSH delivers a secure transport service and a remote login (terminal emulation service). That does not seem to be the same thing as a specific management protocol, of which SNMP is the most obvious example. Should SHH (alone) be considered a framed management protocol, or should it be considered a remote form of CLI access? > Section 7.2 > > I am not clear that all combinations of Framed-Management-Protocol > and Transport-Protocol make sense. I'll take a look at this in detail and follow up. > Section 7.3 > > The Management-Policy-Id attribute indicates the name of the > management access policy for this user. Zero or more Management- > Policy-Id attributes MAY be sent in an Access-Accept packet. > Identifying a policy by name allows the policy to be used on > different NASes without regard to implementation details. > > What does it mean if multiple Management-Policy-Id attributes are > included? > How are the policies merged? If this is implementation-specific, isn't > the result undefined? This issues was raided by others. The proposed resolution is to threat it in the same way as we treat Filter-Id in the Issues & Fixes draft, i.e. multiple instances are NOT RECOMMENDED and the result is undefined. > Section 8 > > > * Service-Type (6) = Administrative (6) > * Transport-Protocol (xx) = None (1) > > Is the Transport-Protocol really none?? Hmmm... > Section 9 > > I'm not clear that these statements make sense because there typically is > no authentication in these AAA exchanges, right? I'll take a closer look. Probably wanton application of boilerplate text. > Section 12 > > This document contains placeholders ("TBA") for assigned numbers > within the RADIUS Attributes registry, to be assigned by IANA at the > time this document should be published as an RFC. Assignement of > additional values for attributes defined in this document are to be > processed as described in [RFC3575]. > > RFC 3575 specifies "First come, first served", which requires no review. > Is this really what you want? Should we tighten up on some of these allocations, above any beyond the provisions of RFC 3575? I thought we didn't want to go down that path... -- 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 Thu Nov 08 13:14:42 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqBtq-0001DQ-Hp for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 08 Nov 2007 13:14:42 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqBtn-0006Xy-B6 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 08 Nov 2007 13:14:42 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqBmS-0002ej-55 for radiusext-data@psg.com; Thu, 08 Nov 2007 18:07:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqBmG-0002dX-Qr for radiusext@ops.ietf.org; Thu, 08 Nov 2007 18:06:58 +0000 Received: (qmail 1029 invoked from network); 8 Nov 2007 13:07:29 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 8 Nov 2007 13:07:29 -0500 From: "David B. Nelson" To: Cc: , "'Bernard Aboba'" Subject: Call for RADEXT agenda items for IETF-70 Date: Thu, 8 Nov 2007 13:05:43 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002201c82231$faa972d0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcgiMfqRLSgQjh5aR+6rc3ZNfcsytQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The RADEXT WG will be meeting during IETF-70 in Vancouver, on Wednesday, December 5, 2007 from 9:00 - 11:30 AM, in the Cypress Room (time and room still subject to change). The chairs will be posting the WG meeting agenda in the next week or so. We'd like to solicit requests for presentation time slots. If you have any items for discussion during the RADEXT WG session at IETF-70, please send a note to the chairs, including the topic, the requested slot duration, and a pointer to any related Interned Draft(s). Thanks! -- 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 Thu Nov 08 14:43:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqDI8-00025t-5O for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 08 Nov 2007 14:43:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqDI2-00012b-4e for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 08 Nov 2007 14:43:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqDDQ-0008XM-1u for radiusext-data@psg.com; Thu, 08 Nov 2007 19:39:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.230] (helo=bay0-omc3-s30.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqDDF-0008WN-I0 for radiusext@ops.ietf.org; Thu, 08 Nov 2007 19:38:54 +0000 Received: from hotmail.com ([207.46.8.111]) by bay0-omc3-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Nov 2007 11:38:49 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 8 Nov 2007 11:38:48 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Thu, 08 Nov 2007 19:38:43 GMT X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: dromasca@avaya.com, radext-chairs@tools.ietf.org Cc: radiusext@ops.ietf.org Bcc: Subject: RE: 3576bis Date: Thu, 08 Nov 2007 11:38:43 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 08 Nov 2007 19:38:48.0982 (UTC) FILETIME=[FBEA6B60:01C8223E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 As far as I know, there are no remaining open issues on RFC 3576bis. >From: "Romascanu, Dan (Dan)" >To: >Subject: 3576bis >Date: Thu, 8 Nov 2007 12:02:25 +0100 > > >David, Bernard, > >Sam Hartman changed his DISCUSS in ABSTAIN after the publication of >draft-13. At this point in time with no pending DISCUSSes I can ask the >IESG secretary to send the approval announcement and forward the >document to the RFC Editor. Do you need to do anything else with the >document? Any RFC Editor notes I am not aware about? > >Dan > > -- 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 Nov 09 11:24:28 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IqWei-0007Ix-3y for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 09 Nov 2007 11:24:28 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IqWee-0003bV-8P for radext-archive-IeZ9sae2@lists.ietf.org; Fri, 09 Nov 2007 11:24:28 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqWZ4-0007eO-7r for radiusext-data@psg.com; Fri, 09 Nov 2007 16:18:38 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IqWYU-0007aM-QY for radiusext@ops.ietf.org; Fri, 09 Nov 2007 16:18:22 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id B487B26E5D; Fri, 9 Nov 2007 15:54:20 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IqWBY-0003Fi-Ki; Fri, 09 Nov 2007 10:54:20 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair Subject: Document Action: 'Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)' to Informational RFC Message-Id: Date: Fri, 09 Nov 2007 10:54:20 -0500 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 The IESG has approved the following document: - 'Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) ' as an Informational RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-13.txt Technical Summary This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. Working Group Summary This document represents an update to RFC 3576, addressing issues and fixes that have been identified since the document was originally published. Originally, these issues were included in the RADIUS Issues and Fixes document, but were sufficient in number and size to require a revision to RFC 3576. Protocol Quality This document describes issues that were encountered by implementers of RFC 3576. As a result, it has been reviewed by implementers as well as operators. Dan Romascanu reviewed the document on behalf of the IESG. -- 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 Nov 11 00:29:36 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir5O4-0001wN-5E for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 11 Nov 2007 00:29:36 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ir5O0-0000D0-Ii for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 11 Nov 2007 00:29:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ir5FR-0001SQ-Kf for radiusext-data@psg.com; Sun, 11 Nov 2007 05:20:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.24.139] (helo=ns4.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Ir5Es-0001Od-2k for radiusext@ops.ietf.org; Sun, 11 Nov 2007 05:20:25 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id DDE682AC78; Sun, 11 Nov 2007 05:20:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ir5En-00050O-NV; Sun, 11 Nov 2007 00:20:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-extended-attributes-00.txt Message-Id: Date: Sun, 11 Nov 2007 00:20:01 -0500 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 --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 : Extended Remote Authentication Dial In User Service (RADIUS) Attributes Author(s) : Y. Li, et al. Filename : draft-ietf-radext-extended-attributes-00.txt Pages : 13 Date : 2007-11-10 In order for the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with existing RADIUS implementations. This document defines a mechanism to accomplish that task, along with standard methods to group related attributes together and to encode values that don't fit into 253 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-extended-attributes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-extended-attributes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-11001208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-extended-attributes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-extended-attributes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-11001208.I-D\@ietf.org> --OtherAccess-- --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 Mon Nov 12 17:27:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Irhl6-0003YZ-9X for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:27:56 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Irhl3-00009b-Gt for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:27:56 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irhcp-000E9f-PW for radiusext-data@psg.com; Mon, 12 Nov 2007 22:19:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, UNPARSEABLE_RELAY autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrhcG-000E5H-SX for radiusext@ops.ietf.org; Mon, 12 Nov 2007 22:19:02 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B32C8A12E for ; Mon, 12 Nov 2007 23:18:48 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20103-03 for ; Mon, 12 Nov 2007 23:18:43 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C415855C7C for ; Mon, 12 Nov 2007 23:18:43 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B8D473DB56F; Mon, 12 Nov 2007 23:18:43 +0100 (CET) Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Thu, 06 Sep 2007 15:20:19 +0200 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id 2C78327803 for ; Thu, 6 Sep 2007 15:20:19 +0200 (CEST) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 280AD6DB67 for ; Thu, 6 Sep 2007 15:20:19 +0200 (CEST) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19709-05-29; Thu, 6 Sep 2007 15:20:10 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A15F15AD6D; Thu, 6 Sep 2007 15:16:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4E3D32A107; Thu, 6 Sep 2007 15:16:30 +0200 (CEST) Date: Thu, 6 Sep 2007 15:16:30 +0200 From: Juergen Schoenwaelder To: radiusext@ops.ietf.org Subject: review of draft-ietf-radext-management-authorization-00.txt Message-ID: <20070906131630.GB2529@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hi, I have read and in general I believe this document is in good shape and useful. I have some issues which I tried to write up in the radiusext WG way... --- Description: mention NETCONF as framed management protocol Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E Priority: 2 Section: 3 Rationale/Explanation of issue: I think the first paragraph should also mention NETCONF as a Framed Management protocol. -- Description: add missing article Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E Priority: 2 Section: 4 Rationale/Explanation of issue: s/containing policy name/containing a policy name/ -- Description: SNMP-Transport-Model vs. SNMP Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 1 Section: 7.1 Rationale/Explanation of issue: Why is the value 1 associated with "SNMP-Transport-Model"? Should this not be just "SNMP", perhaps implying SNMPv3? This would be more consistent with example #4, no? In fact, the proposed RADIUS attributes do not carry what really counts - the security level, e.g. I might accept SNMP access as long as the actual security level is providing authPriv, regardless how this is achieved. Well, since we do not have a defined way to utilize RADIUS from SNMPv3/USM, this is probably a mood point. Still, I think calling this enum just SNMP is the better approach. -- Description: SNMP policy mapping and the reality Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 2 Section: 8 Rationale/Explanation of issue: Example #4 is nice but there is no agreement/specification how this would work with SNMPv3 and ISMS is not chartered to figure this out. Perhaps this can be addressed by adding a note saying. Note that there is currently no standardized way of implementing this management policy mapping for SNMPv3. -- Description: rules for extending enumerations Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 2 Section: 12 Rationale/Explanation of issue: The two new attributes Framed-Management-Protocol and Transport-Protocol are enumerations that may need to be extended (e.g. NETCONF is missing in the first one already). I suggest that the IANA section spells out the rules for extending these enumerations, e.g. by requiring a specification. -- Description: local or not so local area networks Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E/T Priority: 2 Section: 13 Rationale/Explanation of issue: The first sentence in the security considerations kind of restricts RADIUS and DIAMETER to "local area networks". I am not sure why this should be useful or what breaks if the network is not a local area network (however this is defined). I suggest to simple remove the phrase "within local area networks" or if there is a reason for having this restriction, then please add text which spells the reasons out. -- /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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 Nov 12 17:28:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrhlX-0003d8-3O for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:28:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrhlT-0000AK-8O for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:28:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IrhcQ-000E7j-Ka for radiusext-data@psg.com; Mon, 12 Nov 2007 22:18:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, UNPARSEABLE_RELAY autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Irhbt-000E3x-Qe for radiusext@ops.ietf.org; Mon, 12 Nov 2007 22:18:43 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0BBCA8A12E for ; Mon, 12 Nov 2007 23:18:25 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 19893-07 for ; Mon, 12 Nov 2007 23:18:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E7A3555C7C for ; Mon, 12 Nov 2007 23:18:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DCACC3DB568; Mon, 12 Nov 2007 23:18:20 +0100 (CET) Received: from merkur.jacobs-university.de ([unix socket]) by merkur (Cyrus v2.2.13) with LMTPA; Sun, 11 Nov 2007 23:21:09 +0100 X-Sieve: CMU Sieve 2.2 Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by merkur.jacobs-university.de (Postfix) with ESMTP id 67D8633C9E for ; Sun, 11 Nov 2007 23:20:56 +0100 (CET) Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58F5A8A148 for ; Sun, 11 Nov 2007 23:20:56 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 24534-05; Sun, 11 Nov 2007 23:20:51 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7EC128A13D; Sun, 11 Nov 2007 23:20:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 167BA3D540A; Sun, 11 Nov 2007 23:20:52 +0100 (CET) Date: Sun, 11 Nov 2007 23:20:51 +0100 From: Juergen Schoenwaelder To: radiusext@ops.ietf.org Subject: review of draft-ietf-radext-management-authorization-00.txt Message-ID: <20071111222051.GB18374@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi, I have reviewed . a) p1: s/more granular/granular/ If you keep the word more, you have to make it clear to what you compare things... b) I am generally not clear what HTTP means as a management protocol and think this should be defined. I assume you mean a human GUI interface running over HTTP but since you just say HTTP, it becomes confusing if you have for instance NETCONF/SOAP/HTTP. c) p3: s/ASCII-text/text-based/ I think it does not really matter whether its ASCII or UTF8 or... d) Are HTTP and HTTPS really two different framed management protocols? Or is HTTPS just HTTP with a transport of TLS? e) p3: Add NETCONF to the examples of framed management protocols and include RFC 4741 in the references. f) p4: s/containing policy name/containing a policy name/ g) p6: The list of framed management protocols probably needs some thought. Here is what is in the ID: The Value field is four octets. 1 SNMP-Transport-Model 2 HTTP 3 HTTPS/TLS 4 SFTP (via SSH) 5 SCP (via SSH) As mentioned above, why are HTTP and HTTPS different management protocols? If you include file transfer protocols, you should perhaps also include FTP and TFTP (as many existing boxes use them). Perhaps we should call "SNMP-Transport-Model" simply SNMP/TSM. Perhaps we should also add SNMP/USM (even though we currently do not have a defined way to generate RADIUS requests from USM). And as mentioned above, we should include NETCONF (but then I note that NETCONF can run over SSH, BEEP, and SOAP). h) p6: s/Telnet carried within Secure Shell/Secure Shell/ I do not think SSH really carries telnet in the sense of the telnet protocol. i) p7 says: The Management-Policy-Id attribute indicates the name of the management access policy for this user. Zero or more Management- Policy-Id attributes MAY be sent in an Access-Accept packet. Why is the expected behaviour when sending multiple Management-Policy-Id attributes? Can the client choose one of them in whatever way and apply it? Or was the client allowed to cache this information and to switch freely between these policies without further request to the Radius server? j) p8: s|SSH/telnet|SSH|g k) p9: Would it be possible to indicate CLI access via telnet over tls? l) p12 has text that says: This specification describes the use of RADIUS and Diameter for purposes of authentication, authorization and accounting for management access to devices within local area networks. Why restrict this to "local area networks"? Does it really matter whether this is used on a LAN, MAN, or WAN? If yes, explain why. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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 Nov 12 17:48:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iri57-0005CM-6n for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:48:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iri53-00018F-Hw for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 17:48:37 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iri1b-000GwY-JP for radiusext-data@psg.com; Mon, 12 Nov 2007 22:44:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iri1L-000GtW-9R for radiusext@ops.ietf.org; Mon, 12 Nov 2007 22:44:54 +0000 Received: (qmail 32327 invoked from network); 12 Nov 2007 17:45:30 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 12 Nov 2007 17:45:30 -0500 From: "David B. Nelson" To: , References: <20070906131630.GB2529@elstar.local> Subject: RE: review of draft-ietf-radext-management-authorization-00.txt Date: Mon, 12 Nov 2007 17:43:21 -0500 Organization: Elbrys Networks, Inc. Message-ID: <011801c8257d$6d0ac060$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acgle1NfxLNDmFKzR5ysQq1kh59b3AAAQTVg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20070906131630.GB2529@elstar.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Juergen Schoenwaelder writes... > I think the first paragraph should also mention NETCONF as a Framed > Management protocol. Others have suggested this as well. Will do. > s/containing policy name/containing a policy name/ OK. > Why is the value 1 associated with "SNMP-Transport-Model"? Should this > not be just "SNMP", perhaps implying SNMPv3? Others have made s similar suggestion, so I think something along the lines of your recommendation is called for. > This would be more consistent with example #4, no? In fact, the > proposed RADIUS attributes do not carry what really counts - the > security level, e.g. I might accept SNMP access as long as the > actual security level is providing authPriv, regardless how this is > achieved. That may indeed be useful... > Well, since we do not have a defined way to utilize RADIUS from > SNMPv3/USM, this is probably a mood point. Still, I think calling this > enum just SNMP is the better approach. Yes. > Example #4 is nice but there is no agreement/specification how this > would work with SNMPv3 and ISMS is not chartered to figure this out. > Perhaps this can be addressed by adding a note saying. > > Note that there is currently no standardized way of implementing > this management policy mapping for SNMPv3. OK. This is currently something implementation specific. > The two new attributes Framed-Management-Protocol and > Transport-Protocol are enumerations that may need to be extended > (e.g. NETCONF is missing in the first one already). I suggest that > the IANA section spells out the rules for extending these > enumerations, e.g. by requiring a specification. Another reviewer commented in a similar fashion, that this draft should provide more specific guidance to IANA than simply falling back on RFC 3775. I'll add some text. > The first sentence in the security considerations kind of restricts > RADIUS and DIAMETER to "local area networks". I am not sure why this > should be useful or what breaks if the network is not a local area > network (however this is defined). I suggest to simple remove the > phrase "within local area networks" or if there is a reason for > having this restriction, then please add text which spells the > reasons out. No reason. I'll remove the restriction. Thanks for the through review. -- 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 Nov 12 18:14:50 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IriUU-0003H6-VD for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 18:14:50 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IriUS-000223-6K for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 12 Nov 2007 18:14:50 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IriDN-000I2q-Jb for radiusext-data@psg.com; Mon, 12 Nov 2007 22:57:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IriDC-000I2J-MB for radiusext@ops.ietf.org; Mon, 12 Nov 2007 22:57:04 +0000 Received: (qmail 32460 invoked from network); 12 Nov 2007 17:57:47 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 12 Nov 2007 17:57:47 -0500 From: "David B. Nelson" To: , References: <20071111222051.GB18374@elstar.local> Subject: RE: review of draft-ietf-radext-management-authorization-00.txt Date: Mon, 12 Nov 2007 17:55:38 -0500 Organization: Elbrys Networks, Inc. Message-ID: <011901c8257f$24861360$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acgle1i8nMlci7Y0RvuPpxalRNp8ggAAhecQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <20071111222051.GB18374@elstar.local> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Juergen Schoenwaelder writes... > I have reviewed . Thanks! > a) p1: s/more granular/granular/ > > If you keep the word more, you have to make it clear to what you > compare things... "More" is subjective and I'll remove it. > b) I am generally not clear what HTTP means as a management protocol > and think this should be defined. I assume you mean a human GUI > interface running over HTTP but since you just say HTTP, it becomes > confusing if you have for instance NETCONF/SOAP/HTTP. It means a web-based interface, which may be graphical or may be tabular. I think this should refer to any presentation in which the NAS is managed via an embedded web server (in the NAS) and the management station is simply any web browser. > c) p3: s/ASCII-text/text-based/ > > I think it does not really matter whether its ASCII or UTF8 or... OK. > d) Are HTTP and HTTPS really two different framed management > protocols? Or is HTTPS just HTTP with a transport of TLS? Right. This needs to be clarified. Others have registered similar comments. I'll propose some revised text to the list that better separates the selection of application layer protocols from the selection of transport layer protocols. > e) p3: Add NETCONF to the examples of framed management protocols > and include RFC 4741 in the references. OK. > f) p4: s/containing policy name/containing a policy name/ OK. > g) p6: The list of framed management protocols probably needs some > thought. Here is what is in the ID: > > The Value field is four octets. > > 1 SNMP-Transport-Model > 2 HTTP > 3 HTTPS/TLS > 4 SFTP (via SSH) > 5 SCP (via SSH) > > As mentioned above, why are HTTP and HTTPS different management > protocols? If you include file transfer protocols, you should > perhaps also include FTP and TFTP (as many existing boxes use > them). Perhaps we should call "SNMP-Transport-Model" simply > SNMP/TSM. Perhaps we should also add SNMP/USM (even though we > currently do not have a defined way to generate RADIUS requests > from USM). And as mentioned above, we should include NETCONF (but > then I note that NETCONF can run over SSH, BEEP, and SOAP). Agreed. See above. > h) p6: s/Telnet carried within Secure Shell/Secure Shell/ > > I do not think SSH really carries telnet in the sense of the telnet > protocol. Yes. Better text is required to distinguish the remote terminal service of SSH from the secure transport service of SSH. > i) p7 says: > > The Management-Policy-Id attribute indicates the name of the > management access policy for this user. Zero or more Management- > Policy-Id attributes MAY be sent in an Access-Accept packet. > > Why is the expected behaviour when sending multiple > Management-Policy-Id attributes? Can the client choose one of them > in whatever way and apply it? Or was the client allowed to cache > this information and to switch freely between these policies > without further request to the Radius server? Others have raised this issue. The proposed resolution is to follow the guidance of the RADIUS Issues and Fixes draft with regard to Filter-ID, i.e. it is NOT RECOMMENDED to include multiple instances in one Access-Accept message, because the behavior is undefined. > j) p8: s|SSH/telnet|SSH|g OK, taking into account (h) above. > k) p9: Would it be possible to indicate CLI access via telnet over > tls? Umm. I don't see why not. Is this a common use case? Let me craft some proposed text. > l) p12 has text that says: > > This specification describes the use of RADIUS and Diameter for > purposes of authentication, authorization and accounting for > management access to devices within local area networks. > > Why restrict this to "local area networks"? Does it really matter > whether this is used on a LAN, MAN, or WAN? If yes, explain why. Should not be restricted to LANs. Will fix. -- 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 Tue Nov 13 11:04:31 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IryFb-0004EX-JE for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 11:04:31 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IryFW-0000Go-Cs for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 11:04:31 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iry6T-000DWM-2d for radiusext-data@psg.com; Tue, 13 Nov 2007 15:55:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iry6I-000DU4-Er for radiusext@ops.ietf.org; Tue, 13 Nov 2007 15:54:59 +0000 Received: (qmail 14218 invoked from network); 13 Nov 2007 10:55:43 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 13 Nov 2007 10:55:43 -0500 From: "David B. Nelson" To: Subject: ID submission cutoff reminder Date: Tue, 13 Nov 2007 10:53:30 -0500 Organization: Elbrys Networks, Inc. Message-ID: <013201c8260d$5626c1b0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcgmDVYMlDRXcmDUTEGLIloW5pwcdg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Reminder: The cutoff date for submission of -01 and later versions of Internet-Drafts, prior to IETF-70, is this coming Monday, November 19. -- 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 Tue Nov 13 16:09:02 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is30H-0005Bx-W9 for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 16:09:02 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is30D-0004St-PL for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 16:09:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Is2u0-000Lk3-3b for radiusext-data@psg.com; Tue, 13 Nov 2007 21:02:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Is2tK-000LdN-Bx for radiusext@ops.ietf.org; Tue, 13 Nov 2007 21:02:14 +0000 Received: (qmail 19192 invoked from network); 13 Nov 2007 16:02:34 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 13 Nov 2007 16:02:34 -0500 From: "David B. Nelson" To: Subject: Request for review of RADIUS Attributes for IEEE 802 Networks Date: Tue, 13 Nov 2007 16:00:19 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015501c82638$33295530$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcgmODLyeeG1TRSFS16Yc4EGw4p4Cg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was revised on July 30, 2007, after incorporating review from the IEEE 802.11 WG. This document appears on the RADEXT WG charter as a June 2006 milestone "WLAN Attributes draft submitted as a Proposed Standard RFC". It would be good to make additional progress on this document. It appears that all the required external (i.e. IEEE) review has been completed. Please review this draft to determine if it is ready to be taken on as a RADEXT WG work item. The draft is to be found at: http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt In light of the upcoming IETF-70 meeting, this request for review will last until December 7, 2007, i.e. approximately four weeks, including the IETF week. Please indicate whether you would like this document to be taken on as a WG work item. Please respond even if you have no issues with the document. If you have comments, please send the issues to the RADEXT WG mailing list in the format provided here: http://www.drizzle.com/~aboba/RADEXT/ Thanks! Regards, Dave Nelson -- 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 Tue Nov 13 16:30:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3L3-0005kE-2b for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 16:30:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is3Kz-0004v8-Lu for radext-archive-IeZ9sae2@lists.ietf.org; Tue, 13 Nov 2007 16:30:28 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Is3El-000ORR-4C for radiusext-data@psg.com; Tue, 13 Nov 2007 21:23:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Is3EA-000OMZ-EY for radiusext@ops.ietf.org; Tue, 13 Nov 2007 21:23:39 +0000 Received: (qmail 19562 invoked from network); 13 Nov 2007 16:24:12 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 13 Nov 2007 16:24:12 -0500 From: "David B. Nelson" To: Cc: References: Subject: RE: Reminder: automated key management is often required for new protocols Date: Tue, 13 Nov 2007 16:21:58 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcfkLUQR9s/rX/ZkS86EKAeRkGn6qRCC/nag X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi Sam, The RADIUS Extensions (RADEXT) WG chairs forwarded the attached message (from you) to the RADEXT WG list back in August, requesting that the WG members review RFC 4107 as it may apply to the RADIUS Crypto-Agility work item. RADEXT is considering a few proposals to introduce crypto-agility, i.e. the ability to incorporate new cipher suites and cryptographic methods into the legacy RADIUS protocol. We are doing this based on the general request from the Security Area Directorate for all WGs to undertake an analysis of the crypto-agility properties of existing IETF protocols, and recommended enhancements where feasible. As it currently exists, RADIUS relies on message digests and stream ciphers based on MD5. The scope of the RADEXT Crypto-Agility work item is summarized here: http://ops.ietf.org/lists/radiusext/2007/msg00185.html The WG has not been able to determine if your guidance on the applicability of requirements for automated key management in new protocols would extend to crypto-agility "retro-fit" efforts such as this. We seek further clarification on this issue, so that we can make some progress in determining which (if any) of the current proposals for RADIUS Crypto-Agility will be acceptable. Not all of them embrace automated key management. Regards, Dave Nelson Co-Chair RADEXT WG > >From: Sam Hartman > >To: wgchairs@ietf.org > >Subject: Reminder: automated key management is often required for > >new protocols > >Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT) > > > >I wanted to send out a brief reminder to working group chairs about > >RFC 4107. This BCP, published in June of 2005, gives guidance on when > >our protocols need to have an automated key management mechanism. > > > >By this point, you should expect to need to follow RFC 4107 for any > >new protocols and should not be surprised when you are required to > >update protocols to comply with RFC 4107 in order to significantly > >increase their applicability. > > > >In many cases, this means you will need to have an automated mechanism > >for doing key management for security mechanisms your protocol. This > >does not mean you need to support PKIs or even public-key operations. > > > >If you have not already taken a look at RFC 4107 in the context of > >your working group, please do so. If you have any questions Tim and I > >would be happy to answer them. > > > >I'm writing because it looks like I will file a number of discuss > >positions this week asking for significant additional security work to > >be done on protocols before they can be published. I'd like to avoid > >such late surprises for future work. > > > > > >Sam Hartman > >Security Area Director -- 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 Wed Nov 14 10:29:48 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsKBY-0001ZZ-Ds for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 10:29:48 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsKBV-0005by-0c for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 10:29:48 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsK5Q-000107-Mc for radiusext-data@psg.com; Wed, 14 Nov 2007 15:23:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsK5G-0000zN-0a for radiusext@ops.ietf.org; Wed, 14 Nov 2007 15:23:23 +0000 Received: (qmail 2305 invoked from network); 14 Nov 2007 10:24:10 -0500 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.3) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 10:24:10 -0500 Message-ID: <473B1309.8010405@elbrysnetworks.com> Date: Wed, 14 Nov 2007 10:23:53 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: [Fwd: Re: Reminder: automated key management is often required for new protocols] Content-Type: multipart/mixed; boundary="------------030907010500050105060508" Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b This is a multi-part message in MIME format. --------------030907010500050105060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarding to the RADEXT list for a non-subscriber. Sam Hartman wrote: > Hi. > > I think that the applicability of RFC 4107 to radius crypto agility > work is kind of complicated. > > I guess my main question is who is driving the work, who will use it. > > My personal opinion is that updating radius crypto agility without > adding some form of automated key management doesn't have a lot of > value and may not be worth doing. > > However if there are users and implementers who see the value in doing > the crypto agility updates, then perhaps it makes sense to do. > > So, my question to you is what is driving this work besides a desire > to be good security citizens? > --------------030907010500050105060508 Content-Type: message/rfc822; name="Re: Reminder: automated key management is often required for new protocols.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Reminder: automated key management is often required for"; filename*1=" new protocols.eml" Return-Path: Delivered-To: dnelson@elbrysnetworks.com Received: (qmail 1791 invoked from network); 14 Nov 2007 09:48:29 -0500 Received: from unknown (HELO ns1.elbrysnetworks.com) (64.140.243.162) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 09:48:29 -0500 Received: (qmail 17440 invoked by uid 508); 14 Nov 2007 09:02:52 -0500 Received: from carter-zimmerman.suchdamage.org (69.25.196.178) by ns1.elbrysnetworks.com with SMTP; 14 Nov 2007 09:02:52 -0500 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 06E644A45; Wed, 14 Nov 2007 09:47:33 -0500 (EST) From: Sam Hartman To: "David B. Nelson" Cc: Subject: Re: Reminder: automated key management is often required for new protocols References: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> Date: Wed, 14 Nov 2007 09:47:33 -0500 In-Reply-To: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> (David B. Nelson's message of "Tue, 13 Nov 2007 16:21:58 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi. I think that the applicability of RFC 4107 to radius crypto agility work is kind of complicated. I guess my main question is who is driving the work, who will use it. My personal opinion is that updating radius crypto agility without adding some form of automated key management doesn't have a lot of value and may not be worth doing. However if there are users and implementers who see the value in doing the crypto agility updates, then perhaps it makes sense to do. So, my question to you is what is driving this work besides a desire to be good security citizens? --------------030907010500050105060508-- -- 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 Wed Nov 14 11:38:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsLFh-0000P0-JD for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 11:38:09 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsLFf-0005RA-2C for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 11:38:09 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsLBA-0009JB-Gg for radiusext-data@psg.com; Wed, 14 Nov 2007 16:33:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsLAz-0009Hm-Pg for radiusext@ops.ietf.org; Wed, 14 Nov 2007 16:33:23 +0000 Received: (qmail 3781 invoked from network); 14 Nov 2007 11:34:10 -0500 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.3) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 11:34:10 -0500 Message-ID: <473B2372.90007@elbrysnetworks.com> Date: Wed, 14 Nov 2007 11:33:54 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman CC: radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols References: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Sam, > So, my question to you is what is driving this work besides a desire > to be good security citizens? Well, besides that, some folks at Cisco expressed a desire to replace the crypto elements of RADIUS (e.g. key wrap, MAC, etc.) with algorithms and modes that would allow systems including RADIUS to receive FIPS certification, for solutions in government and financial services markets. Additionally, the folks behind the EduRoam consortium in Europe have deployed RADIUS over TLS for inter-university roaming authentication. There may be other use cases. I encourage anyone on the RADEXT list to add their perspective. -- 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 Wed Nov 14 15:29:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsOrC-00069m-Fl for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 15:29:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsOr8-0006ST-VG for radext-archive-IeZ9sae2@lists.ietf.org; Wed, 14 Nov 2007 15:29:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsOlD-0008jx-UA for radiusext-data@psg.com; Wed, 14 Nov 2007 20:22:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsOkv-0008fX-4e for radiusext@ops.ietf.org; Wed, 14 Nov 2007 20:22:50 +0000 Received: (qmail 8194 invoked from network); 14 Nov 2007 15:23:28 -0500 Received: from unknown (HELO ?127.0.0.1?) (172.22.23.3) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 15:23:28 -0500 Message-ID: <473B592F.7050300@elbrysnetworks.com> Date: Wed, 14 Nov 2007 15:23:11 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: [Fwd: Re: Reminder: automated key management is often required for new protocols] Content-Type: multipart/mixed; boundary="------------030902000805070105060203" Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 386e0819b1192672467565a524848168 This is a multi-part message in MIME format. --------------030902000805070105060203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Once again, channeling Sam Hartman's response to the RADEXT list. > David> Well, besides that, some folks at Cisco expressed a desire > David> to replace the crypto elements of RADIUS (e.g. key wrap, > David> MAC, etc.) with algorithms and modes that would allow > David> systems including RADIUS to receive FIPS certification, for > David> solutions in government and financial services markets. > > David> Additionally, the folks behind the EduRoam consortium in > David> Europe have deployed RADIUS over TLS for inter-university > David> roaming authentication. > > I think automated key management is important for both of these use > cases. Based on this response from Sam, it seems to me that we need to ask the authors of the various RADIUS Crypto-Agility proposals (Key Wrap, RADIUS over DTLS, RADIUS over TLS) to submit a write-up of how their proposal provides for automated key management, per RFC 4107, or why they think RFC 4107 requirements do not apply. In the latter case, the authors and the WG would need to be prepared to address any DISCUSS that might come from Sam during IESG review. Another use case that I've recently become aware of is RADIUS Key Wrap for use in the HOKEY WG. We should address that, as well. --------------030902000805070105060203 Content-Type: message/rfc822; name="Re: Reminder: automated key management is often required for new protocols.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Reminder: automated key management is often required for"; filename*1=" new protocols.eml" Return-Path: Delivered-To: dnelson@elbrysnetworks.com Received: (qmail 7537 invoked from network); 14 Nov 2007 14:43:59 -0500 Received: from unknown (HELO ns1.elbrysnetworks.com) (64.140.243.162) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 14:43:59 -0500 Received: (qmail 17784 invoked by uid 508); 14 Nov 2007 13:58:21 -0500 Received: from dhcp-18-188-10-61.dyn.mit.edu (HELO carter-zimmerman.suchdamage.org) (18.188.10.61) by ns1.elbrysnetworks.com with SMTP; 14 Nov 2007 13:58:21 -0500 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EAB104A4B; Wed, 14 Nov 2007 14:43:03 -0500 (EST) From: Sam Hartman To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols References: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> <473B2372.90007@elbrysnetworks.com> Date: Wed, 14 Nov 2007 14:43:03 -0500 In-Reply-To: <473B2372.90007@elbrysnetworks.com> (David B. Nelson's message of "Wed, 14 Nov 2007 11:33:54 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "David" == David B Nelson writes: David> Well, besides that, some folks at Cisco expressed a desire David> to replace the crypto elements of RADIUS (e.g. key wrap, David> MAC, etc.) with algorithms and modes that would allow David> systems including RADIUS to receive FIPS certification, for David> solutions in government and financial services markets. David> Additionally, the folks behind the EduRoam consortium in David> Europe have deployed RADIUS over TLS for inter-university David> roaming authentication. I think automated key management is important for both of these use cases. --------------030902000805070105060203-- -- 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 Thu Nov 15 05:50:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IscJ1-0000TI-1b for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 05:50:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IscIx-0006LI-G7 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 05:50:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IscCt-000P92-5P for radiusext-data@psg.com; Thu, 15 Nov 2007 10:44:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IscCh-000P82-3K for radiusext@ops.ietf.org; Thu, 15 Nov 2007 10:44:17 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id CDC87A704E; Thu, 15 Nov 2007 02:43:56 -0800 (PST) Message-ID: <473C22CB.4040707@nitros9.org> Date: Thu, 15 Nov 2007 11:43:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: [Fwd: Re: Reminder: automated key management is often required for new protocols] References: <473B592F.7050300@elbrysnetworks.com> In-Reply-To: <473B592F.7050300@elbrysnetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 David B. Nelson wrote: >> I think automated key management is important for both of these use >> cases. > > Based on this response from Sam, it seems to me that we need to ask the > authors of the various RADIUS Crypto-Agility proposals (Key Wrap, RADIUS > over DTLS, RADIUS over TLS) to submit a write-up of how their proposal > provides for automated key management, per RFC 4107, or why they think > RFC 4107 requirements do not apply. In the latter case, the authors and > the WG would need to be prepared to address any DISCUSS that might come > from Sam during IESG review. From RFC 4107: Examples of automated key management systems include IPsec IKE and Kerberos. S/MIME and TLS also include automated key management functions. Yes: DTLS uses TLS, which passes the RFC 4107 requirements for automated key management. Long-term keys (e.g. certificates) can be distributed manually to each RADIUS device, which is permitted by RFC 4107. From Section 2.1, DTLS uses stream ciphers, which means that automated key management must be used. From Section 2.2, RADIUS over DTLS meets none of the criteria for permitting manual key management. 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 Thu Nov 15 08:05:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IseP5-0004Rs-DJ for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 08:05:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IseP2-0002RS-3w for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 08:05:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IseIf-0008M3-Fd for radiusext-data@psg.com; Thu, 15 Nov 2007 12:58:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [216.240.42.17] (helo=deployingradius.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IseIA-0008KW-1q for radiusext@ops.ietf.org; Thu, 15 Nov 2007 12:58:13 +0000 Received: from [10.0.1.49] (alexander.quiconnect.net [213.30.156.62]) by deployingradius.com (Postfix) with ESMTP id 61285A704E; Thu, 15 Nov 2007 04:57:55 -0800 (PST) Message-ID: <473C422D.6090807@nitros9.org> Date: Thu, 15 Nov 2007 13:57:17 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Review of Design-01 Strawman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Bernard Aboba wrote: > Section 2.1.3 > > This section makes a recommendation that complex data types SHOULD > be avoided, and then goes on to say that complex attributes are > acceptable for authentication mechanisms. These two recommendations > seem to be in conflict; my recommendation is that an exception for > authentication mechanisms be inserted into the first paragraph and > that the two paragraphs be placed closer together: The suggested text looks fine. I will make the changes. > Section 2.1.4 > > New specifications SHOULD avoid defining message formats for services > inside a RADIUS document. In addition, the service being provisioned > SHOULD NOT be defined in a RADIUS specification... > > For new services using RADIUS, the service SHOULD be defined > elsewhere, and provisioned in RADIUS. > > Could be rephrased to: The suggested text looks fine. I will make the changes. > Section 2.2 > > The high-order octet of the Vendor-Id field is 0 and the low-order 3 > octets are the SMI Network Management Private Enterprise Code of the > Vendor in network byte order. > > Actually, I believe that the SMI Enterprise code is 4 octets, no? Perhaps now. In RFC 2865, it was the lower 3 octets. > Other attribute formats are NOT RECOMMENDED. Examples of NOT > RECOMMENDED formats include Vendor types of more than 16 bits, Vendor > lengths of less than 8 bits, Vendor lengths of more than 8 bits, and > Vendor-Specific contents that are not in Type-Length-Value format. > > Is there a recommendation that RADIUS servers support the 16 bit vendor > type format? Yes: In order to be compatible with the above recommendations for attribute definitions, it is RECOMMENDED that RADIUS servers support attributes using a 16-bit Vendor type field. > Section 3.1.1 > > Vendors and SDOs are reminded that the standard RADIUS attribute ID > space, and the ennumerated > > Recommend changing to: The suggested text looks fine. I will make the changes. > The following paragraphs are a bit awkward: ... > Recommend changing to: The suggested text looks fine. I will make the changes. > Section 3.1.2 > > However, it is RECOMMENDED that Vendors follow the > guidelines outlined here, which are intended to enable maximum > interoperability with minimal changes to existing systems. > > Recommend changing to: OK. ... > These paragraphs seem like they belong in Section 3.1.1. Is there a way > to integrate them there? Yes, > Section 3.1.3 ... > The term PEN is used here, but earlier, the term SMI vendor code is used. > Can we make the usage consistent? Yes. I'll fix it. > " This process means that SDOs do not have to rehost VSAs into the ... > How about this? OK. > Section 3.1.4 ... > How about this? Ok. > Section 4 > > This document requires no action by IANA. [RFC4005]. > > What is the [RFC4005] reference for? Dangling typo. > Section 5 ... > Can we reference FIPS 140 here? There is currently a draft FIPS 140-3 > document available from NIST. I can add a reference to FIPS. I'll submit the updated document today. Until it's published, it will be available at: http://deployingradius.com/ietf/draft-ietf-radext-design-01.txt 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 Thu Nov 15 12:31:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsiYx-0004AL-39 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 12:31:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsiYu-0007O9-CA for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 12:31:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsiJZ-0002J2-9q for radiusext-data@psg.com; Thu, 15 Nov 2007 17:15:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-201.9 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.158] (helo=ns0.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsiIz-0002FU-Mz for radiusext@ops.ietf.org; Thu, 15 Nov 2007 17:15:25 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 117683289E; Thu, 15 Nov 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IsiIv-0001xz-VO; Thu, 15 Nov 2007 12:15:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-design-01.txt Message-Id: Date: Thu, 15 Nov 2007 12:15:01 -0500 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 --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-01.txt Pages : 31 Date : 2007-11-15 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-design-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-design-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15110955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-design-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-design-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15110955.I-D@ietf.org> --OtherAccess-- --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 Thu Nov 15 13:44:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isjhe-0000J9-W6 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 13:44:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isjha-00022L-M3 for radext-archive-IeZ9sae2@lists.ietf.org; Thu, 15 Nov 2007 13:44:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsjVi-0009hN-QN for radiusext-data@psg.com; Thu, 15 Nov 2007 18:32:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.142] (helo=bay0-omc2-s6.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IsjVA-0009eB-1e for radiusext@ops.ietf.org; Thu, 15 Nov 2007 18:32:01 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s6.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 10:31:41 -0800 X-Originating-IP: [208.48.21.10] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: RADEXT WG last call on RADIUS Design Guidelines Document Date: Thu, 15 Nov 2007 10:31:58 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C82772.C0419E60" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 15 Nov 2007 18:31:41.0647 (UTC) FILETIME=[C4541DF0:01C827B5] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C82772.C0419E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the=20 "RADIUS Design Guidelines" document, prior to sending=20 it to the IESG for publication as a Proposed=20 Standard. The document is available for inspection here:=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt RADEXT WG last call will complete on December 15, 2007. Please respond to this solicitation if you have read the document, regardless of = whether you have comments to provide or not. In your email, please state whether = you=20 believe that the document is ready for publication. =20 If you have comments to provide, please send them to the=20 RADEXT WG mailing list (radiusext@ops.ietf.org), prior December 15, 2007, using the format described in the RADEXT Issues = tracker: http://www.drizzle.com/~aboba/RADEXT/ ------=_NextPart_000_0063_01C82772.C0419E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is an announcement = of RADEXT WG=20 last call on the
"RADIUS Design=20 Guidelines" document, prior to sending
it to the IESG for = publication as a=20 Proposed
Standard.  The = document is=20 available for = inspection=20 here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt

RADEXT=20 WG last call will complete on December 15, 2007.  Please=20 respond
to this solicitation if = you have read=20 the document, regardless of whether you
have comments to provide or not.  In your = email,=20 please state whether you
believe that the document is ready=20 for publication. 
 
If you have comments to provide, please send = them to the=20
RADEXT WG mailing list = (radiusext@ops.ietf.org),=20 prior
December 15, 2007, using = the format=20 described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/
------=_NextPart_000_0063_01C82772.C0419E60-- -- 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 Nov 18 12:05:01 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItnZt-00051q-BH for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 12:05:01 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItnZq-0000rw-54 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 12:05:01 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItnR9-0001bd-VV for radiusext-data@psg.com; Sun, 18 Nov 2007 16:55:59 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItnQy-0001Zz-Qk for radiusext@ops.ietf.org; Sun, 18 Nov 2007 16:55:54 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id EFtz1Y00317dt5G0504p00; Sun, 18 Nov 2007 16:55:47 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA13.westchester.pa.mail.comcast.net with comcast id EGvj1Y00424Kx1C0300000; Sun, 18 Nov 2007 16:55:47 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=Ki6YxSCL28Wll1An1_kA:9 a=4dE_79refl0YJGeAKwa5crAnbgwA:4 a=-ZQhYGXY2L8A:10 From: "David B. Nelson" To: "'Bernard Aboba'" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 11:56:28 -0500 Message-ID: <092b01c82a03$f70a1240$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcggAq6EA9/fFUL9TIajw07MWHm45QAhuQIgAl4gQKA= In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Following up .... > > Section 3 > > > > This seems to imply that SSH would not be an acceptable value for > > Framed-Management-Protocol. Is that right? > > SSH delivers a secure transport service and a remote login (terminal > emulation service). That does not seem to be the same thing as a specific > management protocol, of which SNMP is the most obvious example. Should > SHH > (alone) be considered a framed management protocol, or should it be > considered a remote form of CLI access? I think that the way you would specify the secure remote terminal service of SSH would be using Service-Type=NAS-Prompt, Management-Transport-Protocol=SSH. > > Section 7.2 > > > > I am not clear that all combinations of Framed-Management-Protocol > > and Transport-Protocol make sense. These sections will be revised in the -01 version. > > Section 8 > > > > > > * Service-Type (6) = Administrative (6) > > * Transport-Protocol (xx) = None (1) > > > > Is the Transport-Protocol really none?? This will be changed to Default (1), which means use any supported transport. > > Section 9 > > > > I'm not clear that these statements make sense because there typically > > is no authentication in these AAA exchanges, right? Well, these attributes can appear as hints in Access-Requests. I'll snip out some of the unrelated boilerplate text, especially that relating to EAP. -- 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 Nov 18 12:14:03 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itnid-0007Yq-P0 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 12:14:03 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itnia-00015D-CQ for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 12:14:03 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItneJ-0002iZ-4G for radiusext-data@psg.com; Sun, 18 Nov 2007 17:09:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itne7-0002hw-OJ for radiusext@ops.ietf.org; Sun, 18 Nov 2007 17:09:29 +0000 Received: from OMTA13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA08.westchester.pa.mail.comcast.net with comcast id EFtz1Y00617dt5G0505q00; Sun, 18 Nov 2007 17:09:22 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA13.westchester.pa.mail.comcast.net with comcast id EH9K1Y00624Kx1C0300000; Sun, 18 Nov 2007 17:09:22 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=bYDhkV_czI0l4ZHxXrgA:9 a=Zf9qzx-06lPmb9pfgTop8b8crkwA:4 a=EvFsD9_1mWgA:10 From: "David B. Nelson" To: "'Bernard Aboba'" Cc: References: Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:10:04 -0500 Message-ID: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcggApasiS9uNXFrS4qtGsStu11DLAKAcd4A In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 More follow up ... > Framed-Management-Protocol > > 1 SNMP > 2 HTTP > 3 FTP > 4 CP OK. What I'm proposing in the -01 version is: 1 SNMP 2 Web-based 3 NETCONF 4 FTP 5 TFTP 6 CP > Transport-Protocol > > 1 UDP > 2 TCP > 3 SSH over TCP > 4 TLS over TCP > 5 TLS over UDP I don't think we want to be specifying the "real" transport layer, e.g. TCP, UDP, SCTP, etc. What we need to specify there is the "secure transport" (which doesn't exactly fit into the classical ISO 7-layer model), e.g. SSH, TLS, etc. What I'm proposing for the -01 version is: 1 Default 2 SSH 3 TLS 4 DTLS 5 BEEP 6 SOAP > What does it mean if multiple Management-Policy-Id attributes are > included? > How are the policies merged? If this is implementation-specific, isn't > the result undefined? Proposed text for the -01 version: No precedence relationship is defined for multiple occurrences of the Management-Policy-Id attribute. NAS behavior in such cases is not predictable. Therefore, two or more occurrences of this attribute SHOULD NOT be included in a single service provisioning message, such as Access-Accept or CoA. The content of the Management-Policy-Id attribute is expected to be the name of a management access policy of local significance to the NAS, within a flat namespace of significance to the NAS. Overloading or subdividing this flat name with multi-part specifiers (e.g. Access=remote, Level=7) is likely to lead to poor multi-vendor interoperability and SHOULD NOT be utilized. If a simple flat policy name is not sufficient to the anticipated use case, it is RECOMMEDNED that a Vendor Specific Attribute be used instead, rather than overloading the semantics of Management-Policy-Id. -- 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 Nov 18 15:08:09 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItqR5-00058V-JH for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 15:08:08 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItqR1-0006PF-6U for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 15:08:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItqLu-000Gnz-DD for radiusext-data@psg.com; Sun, 18 Nov 2007 20:02:46 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.166] (helo=bay0-omc2-s30.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItqLZ-000Gmb-N8 for radiusext@ops.ietf.org; Sun, 18 Nov 2007 20:02:40 +0000 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s30.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 12:02:25 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> To: "David B. Nelson" Cc: References: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:02:37 -0800 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 18 Nov 2007 20:02:25.0184 (UTC) FILETIME=[F02B3200:01C82A1D] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 >> Framed-Management-Protocol >> >> 1 SNMP >> 2 HTTP >> 3 FTP >> 4 CP > > OK. What I'm proposing in the -01 version is: > > 1 SNMP > 2 Web-based > 3 NETCONF > 4 FTP > 5 TFTP > 6 CP What does Web-based mean? Is it something other than HTTP? > I don't think we want to be specifying the "real" transport layer, e.g. > TCP, > UDP, SCTP, etc. What we need to specify there is the "secure transport" > (which doesn't exactly fit into the classical ISO 7-layer model), e.g. > SSH, > TLS, etc. > > What I'm proposing for the -01 version is: > > 1 Default > 2 SSH > 3 TLS > 4 DTLS > 5 BEEP > 6 SOAP What does default mean? Insecure transport (e.g. TCP/UDP)? Does SNMP over Default mean SNMP over UDP or TCP? With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? Server-only auth? TLS-PSK? >> What does it mean if multiple Management-Policy-Id attributes are >> included? >> How are the policies merged? If this is implementation-specific, isn't >> the result undefined? > > Proposed text for the -01 version: > > > No precedence relationship is defined for multiple occurrences of the > Management-Policy-Id attribute. NAS behavior in such cases is not > predictable. Therefore, two or more occurrences of this attribute SHOULD > NOT be included in a single service provisioning message, such as > Access-Accept or CoA. > > > The content of the Management-Policy-Id attribute is expected to be the > name > of a management access policy of local significance to the NAS, within a > flat namespace of significance to the NAS. Overloading or subdividing > this > flat name with multi-part specifiers (e.g. Access=remote, Level=7) is > likely > to lead to poor multi-vendor interoperability and SHOULD NOT be utilized. > If a simple flat policy name is not sufficient to the anticipated use > case, > it is RECOMMEDNED that a Vendor Specific Attribute be used instead, rather > than overloading the semantics of Management-Policy-Id. > This looks OK. -- 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 Nov 18 15:15:29 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItqYD-0003vE-VZ for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 15:15:29 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItqYA-0006eX-Mj for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 15:15:29 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItqOI-000H1a-Jv for radiusext-data@psg.com; Sun, 18 Nov 2007 20:05:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.160] (helo=bay0-omc2-s24.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItqO8-000GzQ-1R for radiusext@ops.ietf.org; Sun, 18 Nov 2007 20:05:09 +0000 Received: from BAY117-DS3 ([207.46.8.30]) by bay0-omc2-s24.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 12:05:01 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> To: "David B. Nelson" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:05:11 -0800 X-Unsent: 1 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 18 Nov 2007 20:05:02.0008 (UTC) FILETIME=[4DA4A380:01C82A1E] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 > I think that the way you would specify the secure remote terminal service > of > SSH would be using Service-Type=NAS-Prompt, > Management-Transport-Protocol=SSH. You might say that in the document. Would Service-Type = NAS-Prompt and Transport=TLS mean telnet over TLS? -- 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 Nov 18 23:46:40 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItyWu-00066r-Rf for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:46:40 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyWs-0005nE-B4 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:46:40 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItyR6-0009r4-Sm for radiusext-data@psg.com; Mon, 19 Nov 2007 04:40:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-202.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, USER_IN_ALL_SPAM_TO,USER_IN_WHITELIST autolearn=no version=3.2.3 Received: from [156.154.16.138] (helo=ns1.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItyQX-0009lh-AM for radiusext@ops.ietf.org; Mon, 19 Nov 2007 04:40:24 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 414DA26E3F; Mon, 19 Nov 2007 04:40:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItyQU-0001Qt-5f; Sun, 18 Nov 2007 23:40:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-01.txt Message-Id: Date: Sun, 18 Nov 2007 23:40:02 -0500 Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --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 : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-01.txt Pages : 19 Date : 2007-11-18 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, and for granular levels of access rights and management privileges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-management-authorization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-management-authorization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18233716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-management-authorization-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18233716.I-D\@ietf.org> --OtherAccess-- --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 Sun Nov 18 23:51:38 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itybi-0000a1-GU for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:51:38 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itybf-0005t0-2t for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:51:38 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItyY6-000AJV-M9 for radiusext-data@psg.com; Mon, 19 Nov 2007 04:47:54 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1ItyXv-000AIi-Uw for radiusext@ops.ietf.org; Mon, 19 Nov 2007 04:47:49 +0000 Received: from OMTA02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA01.westchester.pa.mail.comcast.net with comcast id EUV81Y0020QuhwU0500x00; Mon, 19 Nov 2007 04:47:43 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA02.westchester.pa.mail.comcast.net with comcast id EUnf1Y00524Kx1C0300000; Mon, 19 Nov 2007 04:47:42 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=cnG0VI7-L9hlel0x0CgA:9 a=rDRm5eYzv_P1BMi56I7p3Yyq8hEA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: Cc: References: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 23:48:25 -0500 Message-ID: <0ba801c82a67$6bd7ec10$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgqHgRTLTPpPgYNQ4GKJpjIYTzACAASIxOA In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Bernard Aboba writes... > > 1 SNMP > > 2 Web-based > > 3 NETCONF > > 4 FTP > > 5 TFTP > > 6 CP > > What does Web-based mean? Is it something other than HTTP? No, but HTTP can be used for other things that a web page (HTML), for example NETCONF (XML) over HTTP. This was to distinguish "classic" web-based management interfaces from other things that might use the HTTP transport. > > 1 Default > > 2 SSH > > 3 TLS > > 4 DTLS > > 5 BEEP > > 6 SOAP > > What does default mean? Insecure transport (e.g. TCP/UDP)? It might mean that, assuming that the standard transport used is one of those. For example, for web-based management (HTML over HTTP) the default transport is TCP. > Does SNMP over Default mean SNMP over UDP or TCP? The default transport for SNMP is UDP. > With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? > Server-only auth? TLS-PSK? This document doesn't go into that level of NAS configuration detail. Do you think those parameters ought to be provisioned via RADIUS attributes? -- 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 Nov 18 23:55:39 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ityfb-0007Hu-QK for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:55:39 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItyfY-0005wX-GV for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 18 Nov 2007 23:55:39 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itycq-000AiQ-6u for radiusext-data@psg.com; Mon, 19 Nov 2007 04:52:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.24] (helo=QMTA02.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Itycd-000Ahw-14 for radiusext@ops.ietf.org; Mon, 19 Nov 2007 04:52:42 +0000 Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA02.westchester.pa.mail.comcast.net with comcast id ERQA1Y00A1GhbT8050CW00; Mon, 19 Nov 2007 04:52:34 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA07.westchester.pa.mail.comcast.net with comcast id EUsV1Y00324Kx1C0300000; Mon, 19 Nov 2007 04:52:33 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=kV1ilVmmlkccd7kw9k0A:9 a=qZYI3ZH25ukS3Rp62e5B-ZpcbYEA:4 a=zoKOyUDlhksA:10 From: "David B. Nelson" To: , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 23:53:15 -0500 Message-ID: <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgqHmV604qf7Zb7TfOvqC1wpmFiUwASR+/A In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Bernard Aboba writes... > > I think that the way you would specify the secure remote terminal > > service of SSH would be using Service-Type=NAS-Prompt, > > Management-Transport-Protocol=SSH. > > You might say that in the document. Yes. From examples section of the -01 version, just now submitted: 2. CLI access, via the secure remote terminal service of SSH, to the non-privileged user access level: * Service-Type (6) = NAS-Prompt (7) * Management-Transport-Protocol (xx) = SSH (2) > Would Service-Type = NAS-Prompt and Transport=TLS mean telnet > over TLS? It would probably mean telnet, although it could also mean some other form of remote terminal service (e.g. rlogin). It would certainly mean "over TLS". -- 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 Nov 19 01:54:23 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0WV-0004cx-Dj for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 01:54:23 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu0WO-0001cv-OQ for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 01:54:23 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0Rl-000IMK-JJ for radiusext-data@psg.com; Mon, 19 Nov 2007 06:49:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.144] (helo=bay0-omc2-s8.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0Ra-000ILn-BB for radiusext@ops.ietf.org; Mon, 19 Nov 2007 06:49:23 +0000 Received: from BAY117-DS3 ([207.46.8.30]) by bay0-omc2-s8.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 22:49:13 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> <0ba801c82a67$6bd7ec10$6401a8c0@NEWTON603> To: "David B. Nelson" Cc: References: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> <0ba801c82a67$6bd7ec10$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document X-Unsent: 1 Date: Sun, 18 Nov 2007 22:49:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 19 Nov 2007 06:49:13.0320 (UTC) FILETIME=[4B9ECE80:01C82A78] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d >> What does Web-based mean? Is it something other than HTTP? > > No, but HTTP can be used for other things that a web page (HTML), for > example NETCONF (XML) over HTTP. This was to distinguish "classic" > web-based management interfaces from other things that might use the HTTP > transport. OK. You might say "HTTP/HTML" or something like that. > It might mean that, assuming that the standard transport used is one of > those. For example, for web-based management (HTML over HTTP) the default > transport is TCP. I thought you need to specify what "default" means for each Framed-Management entry. >> Does SNMP over Default mean SNMP over UDP or TCP? > > The default transport for SNMP is UDP. Is it possible to specify SNMP over TCP? TCP is not on the list of transports. >> With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? >> Server-only auth? TLS-PSK? > > This document doesn't go into that level of NAS configuration detail. Do > you think those parameters ought to be provisioned via RADIUS attributes? Personally, I prefer that they not be. But without specifying exactly what is meant, it's not clear what "TLS" means. For example, you might say "TLS with server-side authentication". -- 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 Nov 19 02:00:49 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0cj-0000SI-VE for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:00:49 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu0cg-0001n4-MC for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:00:49 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0V0-000Icz-Ko for radiusext-data@psg.com; Mon, 19 Nov 2007 06:52:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.172] (helo=bay0-omc2-s36.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0Uq-000IcG-4K for radiusext@ops.ietf.org; Mon, 19 Nov 2007 06:52:45 +0000 Received: from BAY117-DS3 ([207.46.8.30]) by bay0-omc2-s36.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 22:50:16 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> To: "David B. Nelson" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document X-Unsent: 1 Date: Sun, 18 Nov 2007 22:50:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 19 Nov 2007 06:50:16.0048 (UTC) FILETIME=[71025700:01C82A78] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 >> Would Service-Type = NAS-Prompt and Transport=TLS mean telnet >> over TLS? > > It would probably mean telnet, although it could also mean some other form > of remote terminal service (e.g. rlogin). It would certainly mean "over > TLS". I think that the meaning needs to be well defined. -- 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 Nov 19 02:14:52 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0qK-00041a-3X for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:14:52 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu0qG-0002bd-Od for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:14:52 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0mg-000KMQ-88 for radiusext-data@psg.com; Mon, 19 Nov 2007 07:11:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.16] (helo=QMTA01.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu0mV-000KL6-Bh for radiusext@ops.ietf.org; Mon, 19 Nov 2007 07:11:00 +0000 Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA01.westchester.pa.mail.comcast.net with comcast id EXAu1Y00N0EZKEL0500000; Mon, 19 Nov 2007 07:10:54 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA01.westchester.pa.mail.comcast.net with comcast id EXAh1Y00124Kx1C0300000; Mon, 19 Nov 2007 07:10:54 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=GnfJFMB0AvHw9lZtBxQA:9 a=gtJiV0OiAD-gmqbREwcOo1DbEfQA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 02:11:27 -0500 Message-ID: <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgqeH/hCU8qps57S4ydjLKBGtgTjQAAWD2Q In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 > > It would probably mean telnet, although it could also mean some > > other form of remote terminal service (e.g. rlogin). It would > > certainly mean "over TLS". > > I think that the meaning needs to be well defined. Hmmm. The NAS-Prompt Service-Type works for all of: local console connections, telnet, rlogin, ssh, (and more) remote connections. The only thing we are trying to specify here is whether the remote terminal service is being carried over a secure transport. Do we really care what the application layer protocol is? I think that what we care about is whether it over a secure or non-secure transport. This feature relies on the authorization module of the NAS being aware of the transport layer being used by the remote terminal connection, and ensuring that it matches the provisioned parameters. For SSH and TLS I believe that is possible. -- 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 Nov 19 02:29:07 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu147-0004tO-Lx for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:29:07 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu144-0003L1-AH for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 02:29:07 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu10T-000LRy-Nh for radiusext-data@psg.com; Mon, 19 Nov 2007 07:25:21 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.56] (helo=QMTA06.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu10I-000LQO-UP for radiusext@ops.ietf.org; Mon, 19 Nov 2007 07:25:16 +0000 Received: from OMTA09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA06.westchester.pa.mail.comcast.net with comcast id EXQj1Y00E0SCNGk0500100; Mon, 19 Nov 2007 07:25:09 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA09.westchester.pa.mail.comcast.net with comcast id EXQz1Y00824Kx1C0300000; Mon, 19 Nov 2007 07:25:09 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=eSEwHZiNjdAfzkAh100A:9 a=jnsHDjsa_JIcxiXLK4l-VtQjytEA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: , References: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> <0ba801c82a67$6bd7ec10$6401a8c0@NEWTON603> Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 02:25:45 -0500 Message-ID: <0c7f01c82a7d$692acb70$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgqeEyfdTNUFVzHQYyCzmX3VW9ygQAAx9mA In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > OK. You might say "HTTP/HTML" or something like that. If that's more clear, then sure. I though web-based management was pretty clear, though. > I thought you need to specify what "default" means for each > Framed-Management entry. Oh. That could easily be done, for ease of reference, although it is normatively defined in other documents. > Is it possible to specify SNMP over TCP? TCP is not on the list of > transports. No. The enumerated values of the Management-Transport-Protocol attribute are intended to describe the _secure_ transport (e.g. TLS), that sits on top of the transport (e.g. TCP). Why would it be valuable to be able to specify the transport? Should we have a better name for things like SSH and TLS than "secure transport"? Does that cause confusion with "classic" transports? > Personally, I prefer that they not be. But without specifying exactly > what is meant, it's not clear what "TLS" means. For example, you might > say "TLS with server-side authentication". One might say that. Is it important to know how the TLS session keys were derived or just that a TLS session is being used to protect the management protocol? I see this as supporting a high-level policy that system administrators use protected methods of managing the NAS, as opposed to unprotected methods. Do we need to go deeper than that? -- 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 Nov 19 08:52:59 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu73Z-0001bV-GV for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 08:52:57 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu73A-00024E-6k for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 08:52:57 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu6wH-000Nj5-2F for radiusext-data@psg.com; Mon, 19 Nov 2007 13:45:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.168] (helo=bay0-omc2-s32.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu6w6-000NhW-7F for radiusext@ops.ietf.org; Mon, 19 Nov 2007 13:45:19 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 05:45:13 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> To: "David B. Nelson" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document X-Unsent: 1 Date: Mon, 19 Nov 2007 05:45:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 19 Nov 2007 13:45:13.0508 (UTC) FILETIME=[690D3E40:01C82AB2] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab > Hmmm. The NAS-Prompt Service-Type works for all of: local console > connections, telnet, rlogin, ssh, (and more) remote connections. The only > thing we are trying to specify here is whether the remote terminal service > is being carried over a secure transport. Do we really care what the > application layer protocol is? In current usage, is it possible to send a Server-Type=NAS-Prompt attribute to a NAS without a serial port? As I recall, NAS-Prompt originally did not specify any "application layer protocol" at all. Wasn't the purpose to allow an admin connecting to a terminal server to administer it over a serial connection? Assuming that, I'm puzzled as to what it means to specify Server-Type=NAS-Prompt along with an underlying framed transport, like TLS. With the RFC 2865 definition of the NAS-Prompt service, when I hook a terminal emulator to a console port, or dialin to a terminal server on a port, I'm going to get an unframed serial stream of bits suitable for viewing on a terminal emulator. Once I specify a Transport Protocol for NAS-Prompt, (say TLS) what am I going to get? First off, this is a serial link, so I'd assume that if there is IP flowing over the link that we need framing of some kind, either SLIP or PPP. That seems intrinsically at odds with a Service-Type=NAS-Port. So I guess I don't understand the idea of running the NAS-Port or administrative service over a Transport Protocol. If we are talking about a framed management service, then Servce-Type = Framed-Management seems like it makes more sense. >I think that what we care about is whether it over a secure or non-secure >transport. Does NAS-Prompt as defined in RFC 2865 have a transport? I thought it was just a non-frmaed serial stream of bits. > This feature relies on the authorization module of the NAS being aware of > the transport layer being used by the remote terminal connection, and > ensuring that it matches the provisioned parameters. When Service-Type=NAS-Prompt, there is no transport layer to be aware of right? -- 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 Nov 19 10:35:46 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu8f3-0001ao-VF for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 10:35:45 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu8ey-0001e7-UZ for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 10:35:45 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu8Z7-0006zD-8j for radiusext-data@psg.com; Mon, 19 Nov 2007 15:29:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.153] (helo=bay0-omc2-s17.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1Iu8Yw-0006yF-Hd for radiusext@ops.ietf.org; Mon, 19 Nov 2007 15:29:31 +0000 Received: from BAY117-DS1 ([207.46.8.28]) by bay0-omc2-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 07:29:25 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> To: "David B. Nelson" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> Subject: Re: Review of Management Authorization -00 document X-Unsent: 1 Date: Mon, 19 Nov 2007 07:29:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 19 Nov 2007 15:29:25.0986 (UTC) FILETIME=[F7D1AC20:01C82AC0] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >> Wasn't the purpose to allow an admin connecting to a terminal >> server to administer it over a serial connection? > > Yes, among other options. I've always implemented NAS-Prompt and > Administrative for access to the CLI, regardless of whether the connection > was to the local console (e.g. serial RS-232) or via a remote terminal > protocol (e.g. via telnet over TCP/IP. Most NASes that I'm familiar with > have a host-IP address and (at least) a telnet listener. My experience with Service-Type=NAS-Prompt (if memory serves) was for administering a NAS over a serial port, with authentication protected by a token system. As I recall, it was possible to utilize Service-Type=NAS-Prompt alongside token authentication. In those scenarios, I would guess that the NAS would send Service-Type=NAS-Prompt in the Access-Request, along with no Transport-Protocol attribute. If the user came in via Telnet or SSH, the Transport-Protocol would change depending on what was used. Is this more or less the usage model that is envisaged, where the NAS tells the RADIUS server what type of access is being requested, and the server decides whether to authorize it? -- 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 Nov 19 13:39:44 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuBX6-0006b8-Ha for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 13:39:44 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBX4-0002iK-2k for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 13:39:44 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuBKh-000NrJ-M1 for radiusext-data@psg.com; Mon, 19 Nov 2007 18:26:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuBKW-000NqA-Rz for radiusext@ops.ietf.org; Mon, 19 Nov 2007 18:26:50 +0000 Received: (qmail 12169 invoked from network); 19 Nov 2007 13:27:50 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 19 Nov 2007 13:27:50 -0500 From: "David B. Nelson" To: , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 13:25:12 -0500 Organization: Elbrys Networks, Inc. Message-ID: <00ed01c82ad9$86031d40$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: Acgqwc021mQ1i9q/RO6emF6TT6zhkwAE2nHw Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 > My experience with Service-Type=NAS-Prompt (if memory serves) was > for administering a NAS over a serial port, with authentication > protected by a token system. As I recall, it was possible to > utilize Service-Type=NAS-Prompt alongside token authentication. That may well be one use case. There are others. Password authentication is commonly used. The NAS-Prompt Service-Type has been used to authorize local console access to the CLI as well as remote console access to the CLI. Many implementations distinguish the two cases by the value of NAS-Port-Type, which may be Async (0) for the physical console or Virtual (5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.). > In those scenarios, I would guess that the NAS would send > Service-Type=NAS-Prompt in the Access-Request, along with no > Transport-Protocol attribute. If the user came in via Telnet or > SSH, the Transport-Protocol would change depending on what > was used. The Management-Transport-Protocol attribute could certainly be used in conjunction with the NAS-Port-Type attribute of Virtual (5), as is the current practice. > Is this more or less the usage model that is envisaged, where > the NAS tells the RADIUS server what type of access is being > requested, and the server decides whether to authorize it? Yes, that's an important element of this proposal. Just because someone is authorized to obtain network service from the NAS doesn't mean they are authorized to manage the NAS. If a single RADIUS server (or set of primary/backup servers) is used to handle all authentication requests, it is important for the server to be able to authorize management access only for those in the system administration group. In that sense, the usage of the Management-Transport-Protocol attribute usage as a hint is as important, or more important, than the provisioning usage. Do you think it is important to have an attribute that says "telnet" or "rlogin" in addition to one that says "over SSH" or "over TLS"? -- 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 Nov 19 14:09:37 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuC01-0004dm-0D for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 14:09:37 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuBzy-0005fv-Gy for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 14:09:36 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuBo4-0000VM-9N for radiusext-data@psg.com; Mon, 19 Nov 2007 18:57:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [64.140.243.164] (helo=gumby.elbrysnetworks.com) by psg.com with smtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuBnt-0000Tf-BD for radiusext@ops.ietf.org; Mon, 19 Nov 2007 18:57:10 +0000 Received: (qmail 12815 invoked from network); 19 Nov 2007 13:58:12 -0500 Received: from unknown (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 19 Nov 2007 13:58:12 -0500 From: "David B. Nelson" To: References: Subject: RE: I-D Action:draft-ietf-radext-management-authorization-01.txt Date: Mon, 19 Nov 2007 13:55:33 -0500 Organization: Elbrys Networks, Inc. Message-ID: <00f901c82add$c396fb50$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: Thread-Index: AcgqZxHgUyG5MRQARCOUU/AJHM19LgAdi3vQ Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > 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 : Remote Authentication Dial-In User Service > (RADIUS) Authorization for Network Access Server (NAS) Management > Author(s) : D. Nelson, G. Weber > Filename : draft-ietf-radext-management-authorization-01.txt > Pages : 19 > Date : 2007-11-18 It is my belief that the -01 version addresses all comments and issues raised on the -00 document during the recent WGLC, except for the issues Bernard and I have been discussing within the last 24 hours. It would be great if folks could take a look at a "diff" to see that their issues have been addressed, that that the resolutions don't raise new issues. Thanks! -- 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 Nov 19 14:33:35 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuCND-0002sU-Cb for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 14:33:35 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuCNA-0007og-SB for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 14:33:35 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuCDu-0002oi-NJ for radiusext-data@psg.com; Mon, 19 Nov 2007 19:23:58 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [212.201.44.23] (helo=hermes.jacobs-university.de) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuCDO-0002mO-WE for radiusext@ops.ietf.org; Mon, 19 Nov 2007 19:23:43 +0000 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1F9344C5B3; Mon, 19 Nov 2007 20:23:26 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 27732-02-6; Mon, 19 Nov 2007 20:23:21 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 498A34D8E5; Mon, 19 Nov 2007 20:23:10 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7B5403EB3DD; Mon, 19 Nov 2007 20:23:09 +0100 (CET) Date: Mon, 19 Nov 2007 20:23:09 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-01.txt Message-ID: <20071119192309.GA1604@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org References: <00f901c82add$c396fb50$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00f901c82add$c396fb50$5d1216ac@xpsuperdvd2> User-Agent: Mutt/1.5.16 (2007-06-09) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 On Mon, Nov 19, 2007 at 01:55:33PM -0500, David B. Nelson wrote: > It would be great if folks could take a look at a "diff" to see that their > issues have been addressed, that that the resolutions don't raise new > issues. Thanks! I am fine with the changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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 Nov 19 20:01:06 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuHUA-0002xo-NA for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 20:01:06 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuHU6-0001e2-1p for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 20:01:06 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuHMG-00021w-GM for radiusext-data@psg.com; Tue, 20 Nov 2007 00:52:56 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, STOX_REPLY_TYPE autolearn=no version=3.2.3 Received: from [65.54.246.82] (helo=bay0-omc1-s10.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuHM5-00021U-SP for radiusext@ops.ietf.org; Tue, 20 Nov 2007 00:52:51 +0000 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc1-s10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Nov 2007 16:52:45 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: In-Reply-To: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> <00ed01c82ad9$86031d40$5d1216ac@xpsuperdvd2> To: "David B. Nelson" , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> <00ed01c82ad9$86031d40$5d1216ac@xpsuperdvd2> Subject: Re: Review of Management Authorization -00 document X-Unsent: 1 Date: Mon, 19 Nov 2007 16:52:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 20 Nov 2007 00:52:45.0194 (UTC) FILETIME=[A9B786A0:01C82B0F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -2.3 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > That may well be one use case. There are others. Password authentication > is commonly used. What attributes go along with that? User-Password? CHAP-Password? >The NAS-Prompt Service-Type has been used to authorize > local console access to the CLI as well as remote console access to the > CLI. > Many implementations distinguish the two cases by the value of > NAS-Port-Type, which may be Async (0) for the physical console or Virtual > (5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.). OK. My memory is returning... > The Management-Transport-Protocol attribute could certainly be used in > conjunction with the NAS-Port-Type attribute of Virtual (5), as is the > current practice. OK. It would make sense to say that in the document;. Is there a situation where NAS-Port-Type = Async (0) would make much sense along with a Management-Transport-Protocol, attribute? > Yes, that's an important element of this proposal. Just because someone > is > authorized to obtain network service from the NAS doesn't mean they are > authorized to manage the NAS. If a single RADIUS server (or set of > primary/backup servers) is used to handle all authentication requests, it > is > important for the server to be able to authorize management access only > for > those in the system administration group. > > In that sense, the usage of the Management-Transport-Protocol attribute > usage as a hint is as important, or more important, than the provisioning > usage. OK. It might be useful to have an example or two to make this clear. > Do you think it is important to have an attribute that says "telnet" or > "rlogin" in addition to one that says "over SSH" or "over TLS"? The scenario here is to provide more info in the case where NAS-Port-Type=virtual, and Server-Type=NAS-Prompt, right? I guess there are scenarios where this could make a difference to the RADIUS server (e.g. router mistakenly enables an insecure management protocol and RADIUS server wants to make sure it that only secure protocols are authorized). -- 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 Nov 19 22:42:10 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuK02-0005HK-PC for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 22:42:10 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuJzz-0005Q0-Ac for radext-archive-IeZ9sae2@lists.ietf.org; Mon, 19 Nov 2007 22:42:10 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuJwV-000H5u-Ms for radiusext-data@psg.com; Tue, 20 Nov 2007 03:38:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.2.3 Received: from [76.96.62.80] (helo=QMTA08.westchester.pa.mail.comcast.net) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IuJwK-000H4d-N7 for radiusext@ops.ietf.org; Tue, 20 Nov 2007 03:38:26 +0000 Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA08.westchester.pa.mail.comcast.net with comcast id Er3n1Y0040vyq2s0503B00; Tue, 20 Nov 2007 03:38:19 +0000 Received: from NEWTON603 ([24.61.11.96]) by OMTA05.westchester.pa.mail.comcast.net with comcast id EreF1Y00524Kx1C0300000; Tue, 20 Nov 2007 03:38:19 +0000 X-Authority-Analysis: v=1.0 c=1 a=kTRvQ71aqNsA:10 a=asEH97W-zXPlC14EHcsA:9 a=Yy4O67-U6EXoDT8vVSkA:7 a=fx2hy-g4GdzK6ug0TKwkKwwaJXsA:4 a=MxZ3bB5I4kYA:10 From: "David B. Nelson" To: , References: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> <092b01c82a03$f70a1240$6401a8c0@NEWTON603> <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> <107301c82ab8$e8be16e0$6401a8c0@NEWTON603> <00ed01c82ad9$86031d40$5d1216ac@xpsuperdvd2> Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 22:39:03 -0500 Message-ID: <129a01c82b26$e5b030a0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQ In-Reply-To: Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 > What attributes go along with that? User-Password? CHAP-Password? For the Access-Request, it is usually User-Name and User-Password, although I suppose CHAP-Password is possible. > > The Management-Transport-Protocol attribute could certainly be > > used in conjunction with the NAS-Port-Type attribute of Virtual > > (5), as is the current practice. > > OK. It would make sense to say that in the document. That can easily be added, as explanatory material. > Is there a situation where NAS-Port-Type = Async (0) would make > much sense along with a Management-Transport-Protocol, attribute? No. That should also be called out in the document. > > In that sense, the usage of the Management-Transport-Protocol attribute > > usage as a hint is as important, or more important, than the > > provisioning usage. > > OK. It might be useful to have an example or two to make this clear. OK. > The scenario here is to provide more info in the case where > NAS-Port-Type=virtual, and Server-Type=NAS-Prompt, right? I guess > there are scenarios where this could make a difference to the RADIUS > server (e.g. router mistakenly enables an insecure management protocol > and RADIUS server wants to make sure it that only secure protocols are > authorized). Exactly. -- 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 Nov 25 04:12:56 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDXr-00056o-Vg for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 25 Nov 2007 04:12:55 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwDXo-00007r-68 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 25 Nov 2007 04:12:55 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IwDT6-00044i-W9 for radiusext-data@psg.com; Sun, 25 Nov 2007 09:08:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.149] (helo=bay0-omc2-s13.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IwDSX-000422-MY for radiusext@ops.ietf.org; Sun, 25 Nov 2007 09:07:43 +0000 Received: from BAY117-DS3 ([207.46.8.30]) by bay0-omc2-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 01:07:25 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: Strawman Agenda for IETF 70 Date: Sun, 25 Nov 2007 01:07:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C82EFF.914CB240" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 25 Nov 2007 09:07:25.0183 (UTC) FILETIME=[986F30F0:01C82F42] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C82EFF.914CB240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG Agenda Wednesday December 5, 2007 9 AM - 11:30 AM, Cypress Room =20 9 AM - 9:10 AM Preliminaries Blue Sheets Note Takers Jabber Scribe Agenda bashing Document status =20 Documents completing RADEXT WG last call (10 minutes) =20 9:20 - 9:35 AM RADIUS Design Guidelines, Alan DeKok http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt 9:30 - 9:45 AM RADIUS Authorization for NAS Management http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz= ation-01.txt WG Work items 9:45 - 10:00 Extended RADIUS Attributes, Glen Zorn http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes= -00.txt =20 Pre-WG Work Item Review 10:00- 10:10 IEEE 802 Attributes, Bernard Aboba http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt RADIUS Crypto-Agility (50 minutes) =20 10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process, = David Nelson =20 10:20 - 10:30 RADIUS + DTLS (Alan DeKoK) http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt =20 10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey) http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt =20 10:50 - 11:10 Discussion =20 Miscellaneous (10 minutes) =20 11:10 - 11:20 RADSEC (Stefan Winter) http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt Discussion & Wrapup (10 minutes)=20 ------=_NextPart_000_0008_01C82EFF.914CB240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IETF 70 RADEXT WG = Agenda
Wednesday December 5, 2007
9 AM - 11:30 AM, Cypress=20 Room
 
9 AM - 9:10 AM Preliminaries
   Blue=20 Sheets
   Note Takers
   Jabber = Scribe
  =20 Agenda bashing
   Document status
 
Documents completing RADEXT WG last = call (10=20 minutes)
 
9:20 - 9:35 AM  RADIUS Design Guidelines, Alan=20 DeKok
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt
 
9:30 - 9:45 AM   RADIUS = Authorization=20 for NAS Management
http://www.ietf.org/internet-drafts/draft-ietf-radext-mana= gement-authorization-01.txt

WG Work = items
 
9:45 - 10:00 Extended RADIUS = Attributes, Glen=20 Zorn
http://www.ietf.org/internet-drafts/draft-ietf-radext-exte= nded-attributes-00.txt
   
Pre-WG Work Item Review
 
10:00- 10:10 IEEE 802 = Attributes,=20 Bernard Aboba
http://www.ietf.org/internet-drafts/draft-aboba-radext-wla= n-04.txt
RADIUS Crypto-Agility (50=20 minutes)
 
10:10 - 10:20 RADEXT Crypto-agility Requirements = and=20 Selection Process, David Nelson
 
10:20 - 10:30 RADIUS + DTLS = (Alan=20 DeKoK)
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt
 
10:30 - 10:50 RADIUS Crypto-agility (Joe=20 Salowey)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-enca= ttr-06.txt
 
10:50 - 11:10 = Discussion
 
Miscellaneous (10=20 minutes)
 
11:10 - 11:20 RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-00= .txt
 
Discussion & Wrapup (10=20 minutes) 
------=_NextPart_000_0008_01C82EFF.914CB240-- -- 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 Nov 25 04:19:43 2007 Return-path: Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwDeR-00032z-Fi for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 25 Nov 2007 04:19:43 -0500 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwDeN-0000Fn-44 for radext-archive-IeZ9sae2@lists.ietf.org; Sun, 25 Nov 2007 04:19:43 -0500 Received: from majordom by psg.com with local (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IwDaN-0004cm-2h for radiusext-data@psg.com; Sun, 25 Nov 2007 09:15:31 +0000 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE, RDNS_NONE autolearn=no version=3.2.3 Received: from [65.54.246.162] (helo=bay0-omc2-s26.bay0.hotmail.com) by psg.com with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1IwDaC-0004b1-Ix for radiusext@ops.ietf.org; Sun, 25 Nov 2007 09:15:25 +0000 Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s26.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 01:15:20 -0800 X-Originating-IP: [76.108.50.110] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: To: Subject: REMINDER: Call for IETF 70 Agenda Items Date: Sun, 25 Nov 2007 01:15:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C82F00.AC575850" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 12.0.1606 X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1606 X-OriginalArrivalTime: 25 Nov 2007 09:15:20.0103 (UTC) FILETIME=[B3823B70:01C82F43] Sender: owner-radiusext@ops.ietf.org Precedence: bulk X-Spam-Score: -4.0 (----) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C82F00.AC575850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be meeting during IETF-70 in Vancouver, on Wednesday, December 5, 2007 from 9:00 - 11:30 AM, in the Cypress Room (time and = room still subject to change). A strawman agenda has been posted.=20 We'd like to solicit additional requests for presentation time slots. = If you have any items for discussion during the RADEXT WG session at IETF-70, please = send a note to the chairs, including the topic, the requested slot duration, = and a pointer to any related Internet Draft(s). Thanks! ------=_NextPart_000_004B_01C82F00.AC575850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The RADEXT WG will be meeting during IETF-70 in = Vancouver,=20 on Wednesday,
December 5, 2007 from 9:00 - 11:30 AM, in the Cypress = Room=20 (time and room
still subject to change).

A strawman agenda has = been=20 posted.
 
We'd like to solicit additional requests = for=20 presentation time slots.  If you have any
items for discussion = during=20 the RADEXT WG session at IETF-70, please send a
note to the chairs, = including=20 the topic, the requested slot duration, and a
pointer to any related = Internet=20 Draft(s).

Thanks!

------=_NextPart_000_004B_01C82F00.AC575850-- -- 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-data@psg.com Delivery-date: Sun, 25 Nov 2007 09:15:43 +0000 Message-ID: From: To: Subject: REMINDER: Call for IETF 70 Agenda Items Date: Sun, 25 Nov 2007 01:15:31 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01C82F00.AC575850" This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C82F00.AC575850 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The RADEXT WG will be meeting during IETF-70 in Vancouver, on Wednesday, December 5, 2007 from 9:00 - 11:30 AM, in the Cypress Room (time and = room still subject to change). A strawman agenda has been posted.=20 We'd like to solicit additional requests for presentation time slots. = If you have any items for discussion during the RADEXT WG session at IETF-70, please = send a note to the chairs, including the topic, the requested slot duration, = and a pointer to any related Internet Draft(s). Thanks! ------=_NextPart_000_004B_01C82F00.AC575850 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The RADEXT WG will be meeting during IETF-70 in = Vancouver,=20 on Wednesday,
December 5, 2007 from 9:00 - 11:30 AM, in the Cypress = Room=20 (time and room
still subject to change).

A strawman agenda has = been=20 posted.
 
We'd like to solicit additional requests = for=20 presentation time slots.  If you have any
items for discussion = during=20 the RADEXT WG session at IETF-70, please send a
note to the chairs, = including=20 the topic, the requested slot duration, and a
pointer to any related = Internet=20 Draft(s).

Thanks!

------=_NextPart_000_004B_01C82F00.AC575850-- -- 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-data@psg.com Delivery-date: Sun, 25 Nov 2007 09:09:05 +0000 Message-ID: From: To: Subject: Strawman Agenda for IETF 70 Date: Sun, 25 Nov 2007 01:07:36 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C82EFF.914CB240" This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C82EFF.914CB240 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable IETF 70 RADEXT WG Agenda Wednesday December 5, 2007 9 AM - 11:30 AM, Cypress Room =20 9 AM - 9:10 AM Preliminaries Blue Sheets Note Takers Jabber Scribe Agenda bashing Document status =20 Documents completing RADEXT WG last call (10 minutes) =20 9:20 - 9:35 AM RADIUS Design Guidelines, Alan DeKok http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt 9:30 - 9:45 AM RADIUS Authorization for NAS Management http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authoriz= ation-01.txt WG Work items 9:45 - 10:00 Extended RADIUS Attributes, Glen Zorn http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes= -00.txt =20 Pre-WG Work Item Review 10:00- 10:10 IEEE 802 Attributes, Bernard Aboba http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-04.txt RADIUS Crypto-Agility (50 minutes) =20 10:10 - 10:20 RADEXT Crypto-agility Requirements and Selection Process, = David Nelson =20 10:20 - 10:30 RADIUS + DTLS (Alan DeKoK) http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt =20 10:30 - 10:50 RADIUS Crypto-agility (Joe Salowey) http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt http://www.ietf.org/internet-drafts/draft-zorn-radius-encattr-06.txt =20 10:50 - 11:10 Discussion =20 Miscellaneous (10 minutes) =20 11:10 - 11:20 RADSEC (Stefan Winter) http://www.ietf.org/internet-drafts/draft-winter-radsec-00.txt Discussion & Wrapup (10 minutes)=20 ------=_NextPart_000_0008_01C82EFF.914CB240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
IETF 70 RADEXT WG = Agenda
Wednesday December 5, 2007
9 AM - 11:30 AM, Cypress=20 Room
 
9 AM - 9:10 AM Preliminaries
   Blue=20 Sheets
   Note Takers
   Jabber = Scribe
  =20 Agenda bashing
   Document status
 
Documents completing RADEXT WG last = call (10=20 minutes)
 
9:20 - 9:35 AM  RADIUS Design Guidelines, Alan=20 DeKok
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt
 
9:30 - 9:45 AM   RADIUS = Authorization=20 for NAS Management
http://www.ietf.org/internet-drafts/draft-ietf-radext-mana= gement-authorization-01.txt

WG Work = items
 
9:45 - 10:00 Extended RADIUS = Attributes, Glen=20 Zorn
http://www.ietf.org/internet-drafts/draft-ietf-radext-exte= nded-attributes-00.txt
   
Pre-WG Work Item Review
 
10:00- 10:10 IEEE 802 = Attributes,=20 Bernard Aboba
http://www.ietf.org/internet-drafts/draft-aboba-radext-wla= n-04.txt
RADIUS Crypto-Agility (50=20 minutes)
 
10:10 - 10:20 RADEXT Crypto-agility Requirements = and=20 Selection Process, David Nelson
 
10:20 - 10:30 RADIUS + DTLS = (Alan=20 DeKoK)
http://www.ietf.org/internet-drafts/draft-dekok-radext-dtls-00.txt
 
10:30 - 10:50 RADIUS Crypto-agility (Joe=20 Salowey)
http://www.ietf.org/internet-drafts/draft-zorn-radius-keywrap-13.txt
http://www.ietf.org/internet-drafts/draft-zorn-radius-enca= ttr-06.txt
 
10:50 - 11:10 = Discussion
 
Miscellaneous (10=20 minutes)
 
11:10 - 11:20 RADSEC (Stefan Winter)
http://www.ietf.org/internet-drafts/draft-winter-radsec-00= .txt
 
Discussion & Wrapup (10=20 minutes) 
------=_NextPart_000_0008_01C82EFF.914CB240-- -- 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-data@psg.com Delivery-date: Tue, 20 Nov 2007 03:39:19 +0000 From: "David B. Nelson" To: , Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 22:39:03 -0500 Message-ID: <129a01c82b26$e5b030a0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcgrEIwZmoj6ZgafSFqg/87RWLDNmQAFXaoQ > What attributes go along with that? User-Password? CHAP-Password? For the Access-Request, it is usually User-Name and User-Password, although I suppose CHAP-Password is possible. > > The Management-Transport-Protocol attribute could certainly be > > used in conjunction with the NAS-Port-Type attribute of Virtual > > (5), as is the current practice. > > OK. It would make sense to say that in the document. That can easily be added, as explanatory material. > Is there a situation where NAS-Port-Type = Async (0) would make > much sense along with a Management-Transport-Protocol, attribute? No. That should also be called out in the document. > > In that sense, the usage of the Management-Transport-Protocol attribute > > usage as a hint is as important, or more important, than the > > provisioning usage. > > OK. It might be useful to have an example or two to make this clear. OK. > The scenario here is to provide more info in the case where > NAS-Port-Type=virtual, and Server-Type=NAS-Prompt, right? I guess > there are scenarios where this could make a difference to the RADIUS > server (e.g. router mistakenly enables an insecure management protocol > and RADIUS server wants to make sure it that only secure protocols are > authorized). Exactly. -- 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-data@psg.com Delivery-date: Tue, 20 Nov 2007 00:53:56 +0000 Message-ID: From: To: "David B. Nelson" , Subject: Re: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 16:52:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > That may well be one use case. There are others. Password authentication > is commonly used. What attributes go along with that? User-Password? CHAP-Password? >The NAS-Prompt Service-Type has been used to authorize > local console access to the CLI as well as remote console access to the > CLI. > Many implementations distinguish the two cases by the value of > NAS-Port-Type, which may be Async (0) for the physical console or Virtual > (5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.). OK. My memory is returning... > The Management-Transport-Protocol attribute could certainly be used in > conjunction with the NAS-Port-Type attribute of Virtual (5), as is the > current practice. OK. It would make sense to say that in the document;. Is there a situation where NAS-Port-Type = Async (0) would make much sense along with a Management-Transport-Protocol, attribute? > Yes, that's an important element of this proposal. Just because someone > is > authorized to obtain network service from the NAS doesn't mean they are > authorized to manage the NAS. If a single RADIUS server (or set of > primary/backup servers) is used to handle all authentication requests, it > is > important for the server to be able to authorize management access only > for > those in the system administration group. > > In that sense, the usage of the Management-Transport-Protocol attribute > usage as a hint is as important, or more important, than the provisioning > usage. OK. It might be useful to have an example or two to make this clear. > Do you think it is important to have an attribute that says "telnet" or > "rlogin" in addition to one that says "over SSH" or "over TLS"? The scenario here is to provide more info in the case where NAS-Port-Type=virtual, and Server-Type=NAS-Prompt, right? I guess there are scenarios where this could make a difference to the RADIUS server (e.g. router mistakenly enables an insecure management protocol and RADIUS server wants to make sure it that only secure protocols are authorized). -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 19:24:29 +0000 Date: Mon, 19 Nov 2007 20:23:09 +0100 From: Juergen Schoenwaelder To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-management-authorization-01.txt Message-ID: <20071119192309.GA1604@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: "David B. Nelson" , radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) On Mon, Nov 19, 2007 at 01:55:33PM -0500, David B. Nelson wrote: > It would be great if folks could take a look at a "diff" to see that their > issues have been addressed, that that the resolutions don't raise new > issues. Thanks! I am fine with the changes. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 18:58:12 +0000 From: "David B. Nelson" To: Subject: RE: I-D Action:draft-ietf-radext-management-authorization-01.txt Date: Mon, 19 Nov 2007 13:55:33 -0500 Organization: Elbrys Networks, Inc. Message-ID: <00f901c82add$c396fb50$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: AcgqZxHgUyG5MRQARCOUU/AJHM19LgAdi3vQ > 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 : Remote Authentication Dial-In User Service > (RADIUS) Authorization for Network Access Server (NAS) Management > Author(s) : D. Nelson, G. Weber > Filename : draft-ietf-radext-management-authorization-01.txt > Pages : 19 > Date : 2007-11-18 It is my belief that the -01 version addresses all comments and issues raised on the -00 document during the recent WGLC, except for the issues Bernard and I have been discussing within the last 24 hours. It would be great if folks could take a look at a "diff" to see that their issues have been addressed, that that the resolutions don't raise new issues. Thanks! -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 18:28:02 +0000 From: "David B. Nelson" To: , Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 13:25:12 -0500 Organization: Elbrys Networks, Inc. Message-ID: <00ed01c82ad9$86031d40$5d1216ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Thread-Index: Acgqwc021mQ1i9q/RO6emF6TT6zhkwAE2nHw > My experience with Service-Type=NAS-Prompt (if memory serves) was > for administering a NAS over a serial port, with authentication > protected by a token system. As I recall, it was possible to > utilize Service-Type=NAS-Prompt alongside token authentication. That may well be one use case. There are others. Password authentication is commonly used. The NAS-Prompt Service-Type has been used to authorize local console access to the CLI as well as remote console access to the CLI. Many implementations distinguish the two cases by the value of NAS-Port-Type, which may be Async (0) for the physical console or Virtual (5) for any form of remote console (e.g. telnet, shh, rlogin, et. al.). > In those scenarios, I would guess that the NAS would send > Service-Type=NAS-Prompt in the Access-Request, along with no > Transport-Protocol attribute. If the user came in via Telnet or > SSH, the Transport-Protocol would change depending on what > was used. The Management-Transport-Protocol attribute could certainly be used in conjunction with the NAS-Port-Type attribute of Virtual (5), as is the current practice. > Is this more or less the usage model that is envisaged, where > the NAS tells the RADIUS server what type of access is being > requested, and the server decides whether to authorize it? Yes, that's an important element of this proposal. Just because someone is authorized to obtain network service from the NAS doesn't mean they are authorized to manage the NAS. If a single RADIUS server (or set of primary/backup servers) is used to handle all authentication requests, it is important for the server to be able to authorize management access only for those in the system administration group. In that sense, the usage of the Management-Transport-Protocol attribute usage as a hint is as important, or more important, than the provisioning usage. Do you think it is important to have an attribute that says "telnet" or "rlogin" in addition to one that says "over SSH" or "over TLS"? -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 15:30:15 +0000 Message-ID: From: To: "David B. Nelson" , Subject: Re: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 07:29:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> Wasn't the purpose to allow an admin connecting to a terminal >> server to administer it over a serial connection? > > Yes, among other options. I've always implemented NAS-Prompt and > Administrative for access to the CLI, regardless of whether the connection > was to the local console (e.g. serial RS-232) or via a remote terminal > protocol (e.g. via telnet over TCP/IP. Most NASes that I'm familiar with > have a host-IP address and (at least) a telnet listener. My experience with Service-Type=NAS-Prompt (if memory serves) was for administering a NAS over a serial port, with authentication protected by a token system. As I recall, it was possible to utilize Service-Type=NAS-Prompt alongside token authentication. In those scenarios, I would guess that the NAS would send Service-Type=NAS-Prompt in the Access-Request, along with no Transport-Protocol attribute. If the user came in via Telnet or SSH, the Transport-Protocol would change depending on what was used. Is this more or less the usage model that is envisaged, where the NAS tells the RADIUS server what type of access is being requested, and the server decides whether to authorize it? -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 13:46:13 +0000 Message-ID: From: To: "David B. Nelson" , Subject: Re: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 05:45:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > Hmmm. The NAS-Prompt Service-Type works for all of: local console > connections, telnet, rlogin, ssh, (and more) remote connections. The only > thing we are trying to specify here is whether the remote terminal service > is being carried over a secure transport. Do we really care what the > application layer protocol is? In current usage, is it possible to send a Server-Type=NAS-Prompt attribute to a NAS without a serial port? As I recall, NAS-Prompt originally did not specify any "application layer protocol" at all. Wasn't the purpose to allow an admin connecting to a terminal server to administer it over a serial connection? Assuming that, I'm puzzled as to what it means to specify Server-Type=NAS-Prompt along with an underlying framed transport, like TLS. With the RFC 2865 definition of the NAS-Prompt service, when I hook a terminal emulator to a console port, or dialin to a terminal server on a port, I'm going to get an unframed serial stream of bits suitable for viewing on a terminal emulator. Once I specify a Transport Protocol for NAS-Prompt, (say TLS) what am I going to get? First off, this is a serial link, so I'd assume that if there is IP flowing over the link that we need framing of some kind, either SLIP or PPP. That seems intrinsically at odds with a Service-Type=NAS-Port. So I guess I don't understand the idea of running the NAS-Port or administrative service over a Transport Protocol. If we are talking about a framed management service, then Servce-Type = Framed-Management seems like it makes more sense. >I think that what we care about is whether it over a secure or non-secure >transport. Does NAS-Prompt as defined in RFC 2865 have a transport? I thought it was just a non-frmaed serial stream of bits. > This feature relies on the authorization module of the NAS being aware of > the transport layer being used by the remote terminal connection, and > ensuring that it matches the provisioned parameters. When Service-Type=NAS-Prompt, there is no transport layer to be aware of right? -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 07:25:50 +0000 From: "David B. Nelson" To: , Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 02:25:45 -0500 Message-ID: <0c7f01c82a7d$692acb70$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcgqeEyfdTNUFVzHQYyCzmX3VW9ygQAAx9mA > OK. You might say "HTTP/HTML" or something like that. If that's more clear, then sure. I though web-based management was pretty clear, though. > I thought you need to specify what "default" means for each > Framed-Management entry. Oh. That could easily be done, for ease of reference, although it is normatively defined in other documents. > Is it possible to specify SNMP over TCP? TCP is not on the list of > transports. No. The enumerated values of the Management-Transport-Protocol attribute are intended to describe the _secure_ transport (e.g. TLS), that sits on top of the transport (e.g. TCP). Why would it be valuable to be able to specify the transport? Should we have a better name for things like SSH and TLS than "secure transport"? Does that cause confusion with "classic" transports? > Personally, I prefer that they not be. But without specifying exactly > what is meant, it's not clear what "TLS" means. For example, you might > say "TLS with server-side authentication". One might say that. Is it important to know how the TLS session keys were derived or just that a TLS session is being used to protect the management protocol? I see this as supporting a high-level policy that system administrators use protected methods of managing the NAS, as opposed to unprotected methods. Do we need to go deeper than that? -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 07:11:37 +0000 From: "David B. Nelson" To: , Subject: RE: Review of Management Authorization -00 document Date: Mon, 19 Nov 2007 02:11:27 -0500 Message-ID: <0c5a01c82a7b$67697e50$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcgqeH/hCU8qps57S4ydjLKBGtgTjQAAWD2Q > > It would probably mean telnet, although it could also mean some > > other form of remote terminal service (e.g. rlogin). It would > > certainly mean "over TLS". > > I think that the meaning needs to be well defined. Hmmm. The NAS-Prompt Service-Type works for all of: local console connections, telnet, rlogin, ssh, (and more) remote connections. The only thing we are trying to specify here is whether the remote terminal service is being carried over a secure transport. Do we really care what the application layer protocol is? I think that what we care about is whether it over a secure or non-secure transport. This feature relies on the authorization module of the NAS being aware of the transport layer being used by the remote terminal connection, and ensuring that it matches the provisioned parameters. For SSH and TLS I believe that is possible. -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 06:53:11 +0000 Message-ID: From: To: "David B. Nelson" , Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 22:50:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> Would Service-Type = NAS-Prompt and Transport=TLS mean telnet >> over TLS? > > It would probably mean telnet, although it could also mean some other form > of remote terminal service (e.g. rlogin). It would certainly mean "over > TLS". I think that the meaning needs to be well defined. -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 06:50:18 +0000 Message-ID: From: To: "David B. Nelson" Cc: Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 22:49:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> What does Web-based mean? Is it something other than HTTP? > > No, but HTTP can be used for other things that a web page (HTML), for > example NETCONF (XML) over HTTP. This was to distinguish "classic" > web-based management interfaces from other things that might use the HTTP > transport. OK. You might say "HTTP/HTML" or something like that. > It might mean that, assuming that the standard transport used is one of > those. For example, for web-based management (HTML over HTTP) the default > transport is TCP. I thought you need to specify what "default" means for each Framed-Management entry. >> Does SNMP over Default mean SNMP over UDP or TCP? > > The default transport for SNMP is UDP. Is it possible to specify SNMP over TCP? TCP is not on the list of transports. >> With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? >> Server-only auth? TLS-PSK? > > This document doesn't go into that level of NAS configuration detail. Do > you think those parameters ought to be provisioned via RADIUS attributes? Personally, I prefer that they not be. But without specifying exactly what is meant, it's not clear what "TLS" means. For example, you might say "TLS with server-side authentication". -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 04:53:13 +0000 From: "David B. Nelson" To: , Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 23:53:15 -0500 Message-ID: <0ba901c82a68$193ca7b0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcgqHmV604qf7Zb7TfOvqC1wpmFiUwASR+/A Bernard Aboba writes... > > I think that the way you would specify the secure remote terminal > > service of SSH would be using Service-Type=NAS-Prompt, > > Management-Transport-Protocol=SSH. > > You might say that in the document. Yes. >From examples section of the -01 version, just now submitted: 2. CLI access, via the secure remote terminal service of SSH, to the non-privileged user access level: * Service-Type (6) = NAS-Prompt (7) * Management-Transport-Protocol (xx) = SSH (2) > Would Service-Type = NAS-Prompt and Transport=TLS mean telnet > over TLS? It would probably mean telnet, although it could also mean some other form of remote terminal service (e.g. rlogin). It would certainly mean "over TLS". -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 04:48:21 +0000 From: "David B. Nelson" To: Cc: Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 23:48:25 -0500 Message-ID: <0ba801c82a67$6bd7ec10$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcgqHgRTLTPpPgYNQ4GKJpjIYTzACAASIxOA Bernard Aboba writes... > > 1 SNMP > > 2 Web-based > > 3 NETCONF > > 4 FTP > > 5 TFTP > > 6 CP > > What does Web-based mean? Is it something other than HTTP? No, but HTTP can be used for other things that a web page (HTML), for example NETCONF (XML) over HTTP. This was to distinguish "classic" web-based management interfaces from other things that might use the HTTP transport. > > 1 Default > > 2 SSH > > 3 TLS > > 4 DTLS > > 5 BEEP > > 6 SOAP > > What does default mean? Insecure transport (e.g. TCP/UDP)? It might mean that, assuming that the standard transport used is one of those. For example, for web-based management (HTML over HTTP) the default transport is TCP. > Does SNMP over Default mean SNMP over UDP or TCP? The default transport for SNMP is UDP. > With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? > Server-only auth? TLS-PSK? This document doesn't go into that level of NAS configuration detail. Do you think those parameters ought to be provisioned via RADIUS attributes? -- 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-data@psg.com Delivery-date: Mon, 19 Nov 2007 04:41:38 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-management-authorization-01.txt Message-Id: Date: Sun, 18 Nov 2007 23:40:02 -0500 --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 : Remote Authentication Dial-In User Service (RADIUS) Authorization for Network Access Server (NAS) Management Author(s) : D. Nelson, G. Weber Filename : draft-ietf-radext-management-authorization-01.txt Pages : 19 Date : 2007-11-18 This document describes Remote Authentication Dial-In User Service (RADIUS) attributes for the authorization and service provisioning of local and remote management of embedded systems and other managed entities, generally referred to as Network Access Servers (NASes). Specific provisions are made for remote management via framed management protocols, and for granular levels of access rights and management privileges. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-management-authorization-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-management-authorization-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-management-authorization-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-18233716.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-management-authorization-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-management-authorization-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-18233716.I-D\@ietf.org> --OtherAccess-- --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-data@psg.com Delivery-date: Sun, 18 Nov 2007 20:05:34 +0000 Message-ID: From: To: "David B. Nelson" , Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:05:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit > I think that the way you would specify the secure remote terminal service > of > SSH would be using Service-Type=NAS-Prompt, > Management-Transport-Protocol=SSH. You might say that in the document. Would Service-Type = NAS-Prompt and Transport=TLS mean telnet over TLS? -- 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-data@psg.com Delivery-date: Sun, 18 Nov 2007 20:03:35 +0000 Message-ID: From: To: "David B. Nelson" Cc: Subject: Re: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:02:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit >> Framed-Management-Protocol >> >> 1 SNMP >> 2 HTTP >> 3 FTP >> 4 CP > > OK. What I'm proposing in the -01 version is: > > 1 SNMP > 2 Web-based > 3 NETCONF > 4 FTP > 5 TFTP > 6 CP What does Web-based mean? Is it something other than HTTP? > I don't think we want to be specifying the "real" transport layer, e.g. > TCP, > UDP, SCTP, etc. What we need to specify there is the "secure transport" > (which doesn't exactly fit into the classical ISO 7-layer model), e.g. > SSH, > TLS, etc. > > What I'm proposing for the -01 version is: > > 1 Default > 2 SSH > 3 TLS > 4 DTLS > 5 BEEP > 6 SOAP What does default mean? Insecure transport (e.g. TCP/UDP)? Does SNMP over Default mean SNMP over UDP or TCP? With respect to TLS/DTLS, what mode is intended? Mutual auth with certs? Server-only auth? TLS-PSK? >> What does it mean if multiple Management-Policy-Id attributes are >> included? >> How are the policies merged? If this is implementation-specific, isn't >> the result undefined? > > Proposed text for the -01 version: > > > No precedence relationship is defined for multiple occurrences of the > Management-Policy-Id attribute. NAS behavior in such cases is not > predictable. Therefore, two or more occurrences of this attribute SHOULD > NOT be included in a single service provisioning message, such as > Access-Accept or CoA. > > > The content of the Management-Policy-Id attribute is expected to be the > name > of a management access policy of local significance to the NAS, within a > flat namespace of significance to the NAS. Overloading or subdividing > this > flat name with multi-part specifiers (e.g. Access=remote, Level=7) is > likely > to lead to poor multi-vendor interoperability and SHOULD NOT be utilized. > If a simple flat policy name is not sufficient to the anticipated use > case, > it is RECOMMEDNED that a Vendor Specific Attribute be used instead, rather > than overloading the semantics of Management-Policy-Id. > This looks OK. -- 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-data@psg.com Delivery-date: Sun, 18 Nov 2007 17:10:00 +0000 From: "David B. Nelson" To: "'Bernard Aboba'" Cc: Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 12:10:04 -0500 Message-ID: <092c01c82a05$dcc091f0$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcggApasiS9uNXFrS4qtGsStu11DLAKAcd4A More follow up ... > Framed-Management-Protocol > > 1 SNMP > 2 HTTP > 3 FTP > 4 CP OK. What I'm proposing in the -01 version is: 1 SNMP 2 Web-based 3 NETCONF 4 FTP 5 TFTP 6 CP > Transport-Protocol > > 1 UDP > 2 TCP > 3 SSH over TCP > 4 TLS over TCP > 5 TLS over UDP I don't think we want to be specifying the "real" transport layer, e.g. TCP, UDP, SCTP, etc. What we need to specify there is the "secure transport" (which doesn't exactly fit into the classical ISO 7-layer model), e.g. SSH, TLS, etc. What I'm proposing for the -01 version is: 1 Default 2 SSH 3 TLS 4 DTLS 5 BEEP 6 SOAP > What does it mean if multiple Management-Policy-Id attributes are > included? > How are the policies merged? If this is implementation-specific, isn't > the result undefined? Proposed text for the -01 version: No precedence relationship is defined for multiple occurrences of the Management-Policy-Id attribute. NAS behavior in such cases is not predictable. Therefore, two or more occurrences of this attribute SHOULD NOT be included in a single service provisioning message, such as Access-Accept or CoA. The content of the Management-Policy-Id attribute is expected to be the name of a management access policy of local significance to the NAS, within a flat namespace of significance to the NAS. Overloading or subdividing this flat name with multi-part specifiers (e.g. Access=remote, Level=7) is likely to lead to poor multi-vendor interoperability and SHOULD NOT be utilized. If a simple flat policy name is not sufficient to the anticipated use case, it is RECOMMEDNED that a Vendor Specific Attribute be used instead, rather than overloading the semantics of Management-Policy-Id. -- 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-data@psg.com Delivery-date: Sun, 18 Nov 2007 16:57:14 +0000 From: "David B. Nelson" To: "'Bernard Aboba'" , Subject: RE: Review of Management Authorization -00 document Date: Sun, 18 Nov 2007 11:56:28 -0500 Message-ID: <092b01c82a03$f70a1240$6401a8c0@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit thread-index: AcggAq6EA9/fFUL9TIajw07MWHm45QAhuQIgAl4gQKA= Following up .... > > Section 3 > > > > This seems to imply that SSH would not be an acceptable value for > > Framed-Management-Protocol. Is that right? > > SSH delivers a secure transport service and a remote login (terminal > emulation service). That does not seem to be the same thing as a specific > management protocol, of which SNMP is the most obvious example. Should > SHH > (alone) be considered a framed management protocol, or should it be > considered a remote form of CLI access? I think that the way you would specify the secure remote terminal service of SSH would be using Service-Type=NAS-Prompt, Management-Transport-Protocol=SSH. > > Section 7.2 > > > > I am not clear that all combinations of Framed-Management-Protocol > > and Transport-Protocol make sense. These sections will be revised in the -01 version. > > Section 8 > > > > > > * Service-Type (6) = Administrative (6) > > * Transport-Protocol (xx) = None (1) > > > > Is the Transport-Protocol really none?? This will be changed to Default (1), which means use any supported transport. > > Section 9 > > > > I'm not clear that these statements make sense because there typically > > is no authentication in these AAA exchanges, right? Well, these attributes can appear as hints in Access-Requests. I'll snip out some of the unrelated boilerplate text, especially that relating to EAP. -- 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-data@psg.com Delivery-date: Thu, 15 Nov 2007 18:33:19 +0000 Message-ID: From: To: Subject: RADEXT WG last call on RADIUS Design Guidelines Document Date: Thu, 15 Nov 2007 10:31:58 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0063_01C82772.C0419E60" This is a multi-part message in MIME format. ------=_NextPart_000_0063_01C82772.C0419E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This is an announcement of RADEXT WG last call on the=20 "RADIUS Design Guidelines" document, prior to sending=20 it to the IESG for publication as a Proposed=20 Standard. The document is available for inspection here:=20 http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt RADEXT WG last call will complete on December 15, 2007. Please respond to this solicitation if you have read the document, regardless of = whether you have comments to provide or not. In your email, please state whether = you=20 believe that the document is ready for publication. =20 If you have comments to provide, please send them to the=20 RADEXT WG mailing list (radiusext@ops.ietf.org), prior December 15, 2007, using the format described in the RADEXT Issues = tracker: http://www.drizzle.com/~aboba/RADEXT/ ------=_NextPart_000_0063_01C82772.C0419E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This is an announcement = of RADEXT WG=20 last call on the
"RADIUS Design=20 Guidelines" document, prior to sending
it to the IESG for = publication as a=20 Proposed
Standard.  The = document is=20 available for = inspection=20 here:
http://www.ietf.org/internet-drafts/draft-ietf-radext-design-01.txt

RADEXT=20 WG last call will complete on December 15, 2007.  Please=20 respond
to this solicitation if = you have read=20 the document, regardless of whether you
have comments to provide or not.  In your = email,=20 please state whether you
believe that the document is ready=20 for publication. 
 
If you have comments to provide, please send = them to the=20
RADEXT WG mailing list = (radiusext@ops.ietf.org),=20 prior
December 15, 2007, using = the format=20 described in the RADEXT Issues tracker:
http://www.drizzle.com/~aboba/RADEXT/
------=_NextPart_000_0063_01C82772.C0419E60-- -- 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-data@psg.com Delivery-date: Thu, 15 Nov 2007 17:17:06 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-radext-design-01.txt Message-Id: Date: Thu, 15 Nov 2007 12:15:01 -0500 --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-01.txt Pages : 31 Date : 2007-11-15 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-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-design-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-design-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-15110955.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-design-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-design-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-15110955.I-D@ietf.org> --OtherAccess-- --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-data@psg.com Delivery-date: Thu, 15 Nov 2007 12:59:22 +0000 Message-ID: <473C422D.6090807@nitros9.org> Date: Thu, 15 Nov 2007 13:57:17 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org Subject: Re: Review of Design-01 Strawman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Section 2.1.3 > > This section makes a recommendation that complex data types SHOULD > be avoided, and then goes on to say that complex attributes are > acceptable for authentication mechanisms. These two recommendations > seem to be in conflict; my recommendation is that an exception for > authentication mechanisms be inserted into the first paragraph and > that the two paragraphs be placed closer together: The suggested text looks fine. I will make the changes. > Section 2.1.4 > > New specifications SHOULD avoid defining message formats for services > inside a RADIUS document. In addition, the service being provisioned > SHOULD NOT be defined in a RADIUS specification... > > For new services using RADIUS, the service SHOULD be defined > elsewhere, and provisioned in RADIUS. > > Could be rephrased to: The suggested text looks fine. I will make the changes. > Section 2.2 > > The high-order octet of the Vendor-Id field is 0 and the low-order 3 > octets are the SMI Network Management Private Enterprise Code of the > Vendor in network byte order. > > Actually, I believe that the SMI Enterprise code is 4 octets, no? Perhaps now. In RFC 2865, it was the lower 3 octets. > Other attribute formats are NOT RECOMMENDED. Examples of NOT > RECOMMENDED formats include Vendor types of more than 16 bits, Vendor > lengths of less than 8 bits, Vendor lengths of more than 8 bits, and > Vendor-Specific contents that are not in Type-Length-Value format. > > Is there a recommendation that RADIUS servers support the 16 bit vendor > type format? Yes: In order to be compatible with the above recommendations for attribute definitions, it is RECOMMENDED that RADIUS servers support attributes using a 16-bit Vendor type field. > Section 3.1.1 > > Vendors and SDOs are reminded that the standard RADIUS attribute ID > space, and the ennumerated > > Recommend changing to: The suggested text looks fine. I will make the changes. > The following paragraphs are a bit awkward: ... > Recommend changing to: The suggested text looks fine. I will make the changes. > Section 3.1.2 > > However, it is RECOMMENDED that Vendors follow the > guidelines outlined here, which are intended to enable maximum > interoperability with minimal changes to existing systems. > > Recommend changing to: OK. ... > These paragraphs seem like they belong in Section 3.1.1. Is there a way > to integrate them there? Yes, > Section 3.1.3 ... > The term PEN is used here, but earlier, the term SMI vendor code is used. > Can we make the usage consistent? Yes. I'll fix it. > " This process means that SDOs do not have to rehost VSAs into the ... > How about this? OK. > Section 3.1.4 ... > How about this? Ok. > Section 4 > > This document requires no action by IANA. [RFC4005]. > > What is the [RFC4005] reference for? Dangling typo. > Section 5 ... > Can we reference FIPS 140 here? There is currently a draft FIPS 140-3 > document available from NIST. I can add a reference to FIPS. I'll submit the updated document today. Until it's published, it will be available at: http://deployingradius.com/ietf/draft-ietf-radext-design-01.txt 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-data@psg.com Delivery-date: Thu, 15 Nov 2007 10:45:36 +0000 Message-ID: <473C22CB.4040707@nitros9.org> Date: Thu, 15 Nov 2007 11:43:23 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: "David B. Nelson" CC: radiusext@ops.ietf.org Subject: Re: [Fwd: Re: Reminder: automated key management is often required for new protocols] Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit David B. Nelson wrote: >> I think automated key management is important for both of these use >> cases. > > Based on this response from Sam, it seems to me that we need to ask the > authors of the various RADIUS Crypto-Agility proposals (Key Wrap, RADIUS > over DTLS, RADIUS over TLS) to submit a write-up of how their proposal > provides for automated key management, per RFC 4107, or why they think > RFC 4107 requirements do not apply. In the latter case, the authors and > the WG would need to be prepared to address any DISCUSS that might come > from Sam during IESG review. From RFC 4107: Examples of automated key management systems include IPsec IKE and Kerberos. S/MIME and TLS also include automated key management functions. Yes: DTLS uses TLS, which passes the RFC 4107 requirements for automated key management. Long-term keys (e.g. certificates) can be distributed manually to each RADIUS device, which is permitted by RFC 4107. From Section 2.1, DTLS uses stream ciphers, which means that automated key management must be used. From Section 2.2, RADIUS over DTLS meets none of the criteria for permitting manual key management. 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-data@psg.com Delivery-date: Wed, 14 Nov 2007 20:23:46 +0000 Message-ID: <473B592F.7050300@elbrysnetworks.com> Date: Wed, 14 Nov 2007 15:23:11 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: [Fwd: Re: Reminder: automated key management is often required for new protocols] Content-Type: multipart/mixed; boundary="------------030902000805070105060203" This is a multi-part message in MIME format. --------------030902000805070105060203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Once again, channeling Sam Hartman's response to the RADEXT list. > David> Well, besides that, some folks at Cisco expressed a desire > David> to replace the crypto elements of RADIUS (e.g. key wrap, > David> MAC, etc.) with algorithms and modes that would allow > David> systems including RADIUS to receive FIPS certification, for > David> solutions in government and financial services markets. > > David> Additionally, the folks behind the EduRoam consortium in > David> Europe have deployed RADIUS over TLS for inter-university > David> roaming authentication. > > I think automated key management is important for both of these use > cases. Based on this response from Sam, it seems to me that we need to ask the authors of the various RADIUS Crypto-Agility proposals (Key Wrap, RADIUS over DTLS, RADIUS over TLS) to submit a write-up of how their proposal provides for automated key management, per RFC 4107, or why they think RFC 4107 requirements do not apply. In the latter case, the authors and the WG would need to be prepared to address any DISCUSS that might come from Sam during IESG review. Another use case that I've recently become aware of is RADIUS Key Wrap for use in the HOKEY WG. We should address that, as well. --------------030902000805070105060203 Content-Type: message/rfc822; name="Re: Reminder: automated key management is often required for new protocols.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Reminder: automated key management is often required for"; filename*1=" new protocols.eml" Return-Path: Delivered-To: dnelson@elbrysnetworks.com Received: (qmail 7537 invoked from network); 14 Nov 2007 14:43:59 -0500 Received: from unknown (HELO ns1.elbrysnetworks.com) (64.140.243.162) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 14:43:59 -0500 Received: (qmail 17784 invoked by uid 508); 14 Nov 2007 13:58:21 -0500 Received: from dhcp-18-188-10-61.dyn.mit.edu (HELO carter-zimmerman.suchdamage.org) (18.188.10.61) by ns1.elbrysnetworks.com with SMTP; 14 Nov 2007 13:58:21 -0500 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EAB104A4B; Wed, 14 Nov 2007 14:43:03 -0500 (EST) From: Sam Hartman To: "David B. Nelson" Cc: radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols References: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> <473B2372.90007@elbrysnetworks.com> Date: Wed, 14 Nov 2007 14:43:03 -0500 In-Reply-To: <473B2372.90007@elbrysnetworks.com> (David B. Nelson's message of "Wed, 14 Nov 2007 11:33:54 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii >>>>> "David" == David B Nelson writes: David> Well, besides that, some folks at Cisco expressed a desire David> to replace the crypto elements of RADIUS (e.g. key wrap, David> MAC, etc.) with algorithms and modes that would allow David> systems including RADIUS to receive FIPS certification, for David> solutions in government and financial services markets. David> Additionally, the folks behind the EduRoam consortium in David> Europe have deployed RADIUS over TLS for inter-university David> roaming authentication. I think automated key management is important for both of these use cases. --------------030902000805070105060203-- -- 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-data@psg.com Delivery-date: Wed, 14 Nov 2007 16:34:27 +0000 Message-ID: <473B2372.90007@elbrysnetworks.com> Date: Wed, 14 Nov 2007 11:33:54 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sam Hartman CC: radiusext@ops.ietf.org Subject: Re: Reminder: automated key management is often required for new protocols Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sam, > So, my question to you is what is driving this work besides a desire > to be good security citizens? Well, besides that, some folks at Cisco expressed a desire to replace the crypto elements of RADIUS (e.g. key wrap, MAC, etc.) with algorithms and modes that would allow systems including RADIUS to receive FIPS certification, for solutions in government and financial services markets. Additionally, the folks behind the EduRoam consortium in Europe have deployed RADIUS over TLS for inter-university roaming authentication. There may be other use cases. I encourage anyone on the RADEXT list to add their perspective. -- 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-data@psg.com Delivery-date: Wed, 14 Nov 2007 15:24:15 +0000 Message-ID: <473B1309.8010405@elbrysnetworks.com> Date: Wed, 14 Nov 2007 10:23:53 -0500 From: "David B. Nelson" User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: [Fwd: Re: Reminder: automated key management is often required for new protocols] Content-Type: multipart/mixed; boundary="------------030907010500050105060508" This is a multi-part message in MIME format. --------------030907010500050105060508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Forwarding to the RADEXT list for a non-subscriber. Sam Hartman wrote: > Hi. > > I think that the applicability of RFC 4107 to radius crypto agility > work is kind of complicated. > > I guess my main question is who is driving the work, who will use it. > > My personal opinion is that updating radius crypto agility without > adding some form of automated key management doesn't have a lot of > value and may not be worth doing. > > However if there are users and implementers who see the value in doing > the crypto agility updates, then perhaps it makes sense to do. > > So, my question to you is what is driving this work besides a desire > to be good security citizens? > --------------030907010500050105060508 Content-Type: message/rfc822; name="Re: Reminder: automated key management is often required for new protocols.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="Re: Reminder: automated key management is often required for"; filename*1=" new protocols.eml" Return-Path: Delivered-To: dnelson@elbrysnetworks.com Received: (qmail 1791 invoked from network); 14 Nov 2007 09:48:29 -0500 Received: from unknown (HELO ns1.elbrysnetworks.com) (64.140.243.162) by gumby.elbrysnetworks.com with SMTP; 14 Nov 2007 09:48:29 -0500 Received: (qmail 17440 invoked by uid 508); 14 Nov 2007 09:02:52 -0500 Received: from carter-zimmerman.suchdamage.org (69.25.196.178) by ns1.elbrysnetworks.com with SMTP; 14 Nov 2007 09:02:52 -0500 Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 06E644A45; Wed, 14 Nov 2007 09:47:33 -0500 (EST) From: Sam Hartman To: "David B. Nelson" Cc: Subject: Re: Reminder: automated key management is often required for new protocols References: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> Date: Wed, 14 Nov 2007 09:47:33 -0500 In-Reply-To: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> (David B. Nelson's message of "Tue, 13 Nov 2007 16:21:58 -0500") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi. I think that the applicability of RFC 4107 to radius crypto agility work is kind of complicated. I guess my main question is who is driving the work, who will use it. My personal opinion is that updating radius crypto agility without adding some form of automated key management doesn't have a lot of value and may not be worth doing. However if there are users and implementers who see the value in doing the crypto agility updates, then perhaps it makes sense to do. So, my question to you is what is driving this work besides a desire to be good security citizens? --------------030907010500050105060508-- -- 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-data@psg.com Delivery-date: Tue, 13 Nov 2007 21:24:27 +0000 From: "David B. Nelson" To: Cc: Subject: RE: Reminder: automated key management is often required for new protocols Date: Tue, 13 Nov 2007 16:21:58 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015901c8263b$38ff71d0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcfkLUQR9s/rX/ZkS86EKAeRkGn6qRCC/nag Hi Sam, The RADIUS Extensions (RADEXT) WG chairs forwarded the attached message (from you) to the RADEXT WG list back in August, requesting that the WG members review RFC 4107 as it may apply to the RADIUS Crypto-Agility work item. RADEXT is considering a few proposals to introduce crypto-agility, i.e. the ability to incorporate new cipher suites and cryptographic methods into the legacy RADIUS protocol. We are doing this based on the general request from the Security Area Directorate for all WGs to undertake an analysis of the crypto-agility properties of existing IETF protocols, and recommended enhancements where feasible. As it currently exists, RADIUS relies on message digests and stream ciphers based on MD5. The scope of the RADEXT Crypto-Agility work item is summarized here: http://ops.ietf.org/lists/radiusext/2007/msg00185.html The WG has not been able to determine if your guidance on the applicability of requirements for automated key management in new protocols would extend to crypto-agility "retro-fit" efforts such as this. We seek further clarification on this issue, so that we can make some progress in determining which (if any) of the current proposals for RADIUS Crypto-Agility will be acceptable. Not all of them embrace automated key management. Regards, Dave Nelson Co-Chair RADEXT WG > >From: Sam Hartman > >To: wgchairs@ietf.org > >Subject: Reminder: automated key management is often required for > >new protocols > >Date: Tue, 21 Aug 2007 12:38:10 -0400 (EDT) > > > >I wanted to send out a brief reminder to working group chairs about > >RFC 4107. This BCP, published in June of 2005, gives guidance on when > >our protocols need to have an automated key management mechanism. > > > >By this point, you should expect to need to follow RFC 4107 for any > >new protocols and should not be surprised when you are required to > >update protocols to comply with RFC 4107 in order to significantly > >increase their applicability. > > > >In many cases, this means you will need to have an automated mechanism > >for doing key management for security mechanisms your protocol. This > >does not mean you need to support PKIs or even public-key operations. > > > >If you have not already taken a look at RFC 4107 in the context of > >your working group, please do so. If you have any questions Tim and I > >would be happy to answer them. > > > >I'm writing because it looks like I will file a number of discuss > >positions this week asking for significant additional security work to > >be done on protocols before they can be published. I'd like to avoid > >such late surprises for future work. > > > > > >Sam Hartman > >Security Area Director -- 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-data@psg.com Delivery-date: Tue, 13 Nov 2007 21:03:32 +0000 From: "David B. Nelson" To: Subject: Request for review of RADIUS Attributes for IEEE 802 Networks Date: Tue, 13 Nov 2007 16:00:19 -0500 Organization: Elbrys Networks, Inc. Message-ID: <015501c82638$33295530$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcgmODLyeeG1TRSFS16Yc4EGw4p4Cg== The Internet-Draft "RADIUS Attributes for IEEE 802 Networks" was revised on July 30, 2007, after incorporating review from the IEEE 802.11 WG. This document appears on the RADEXT WG charter as a June 2006 milestone "WLAN Attributes draft submitted as a Proposed Standard RFC". It would be good to make additional progress on this document. It appears that all the required external (i.e. IEEE) review has been completed. Please review this draft to determine if it is ready to be taken on as a RADEXT WG work item. The draft is to be found at: http://www.ietf.org/internet-drafts/draft-aboba-radext-wlan-06.txt In light of the upcoming IETF-70 meeting, this request for review will last until December 7, 2007, i.e. approximately four weeks, including the IETF week. Please indicate whether you would like this document to be taken on as a WG work item. Please respond even if you have no issues with the document. If you have comments, please send the issues to the RADEXT WG mailing list in the format provided here: http://www.drizzle.com/~aboba/RADEXT/ Thanks! Regards, Dave Nelson -- 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-data@psg.com Delivery-date: Tue, 13 Nov 2007 15:56:14 +0000 From: "David B. Nelson" To: Subject: ID submission cutoff reminder Date: Tue, 13 Nov 2007 10:53:30 -0500 Organization: Elbrys Networks, Inc. Message-ID: <013201c8260d$5626c1b0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcgmDVYMlDRXcmDUTEGLIloW5pwcdg== Reminder: The cutoff date for submission of -01 and later versions of Internet-Drafts, prior to IETF-70, is this coming Monday, November 19. -- 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-data@psg.com Delivery-date: Mon, 12 Nov 2007 22:57:55 +0000 From: "David B. Nelson" To: , Subject: RE: review of draft-ietf-radext-management-authorization-00.txt Date: Mon, 12 Nov 2007 17:55:38 -0500 Organization: Elbrys Networks, Inc. Message-ID: <011901c8257f$24861360$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: Acgle1i8nMlci7Y0RvuPpxalRNp8ggAAhecQ Juergen Schoenwaelder writes... > I have reviewed . Thanks! > a) p1: s/more granular/granular/ > > If you keep the word more, you have to make it clear to what you > compare things... "More" is subjective and I'll remove it. > b) I am generally not clear what HTTP means as a management protocol > and think this should be defined. I assume you mean a human GUI > interface running over HTTP but since you just say HTTP, it becomes > confusing if you have for instance NETCONF/SOAP/HTTP. It means a web-based interface, which may be graphical or may be tabular. I think this should refer to any presentation in which the NAS is managed via an embedded web server (in the NAS) and the management station is simply any web browser. > c) p3: s/ASCII-text/text-based/ > > I think it does not really matter whether its ASCII or UTF8 or... OK. > d) Are HTTP and HTTPS really two different framed management > protocols? Or is HTTPS just HTTP with a transport of TLS? Right. This needs to be clarified. Others have registered similar comments. I'll propose some revised text to the list that better separates the selection of application layer protocols from the selection of transport layer protocols. > e) p3: Add NETCONF to the examples of framed management protocols > and include RFC 4741 in the references. OK. > f) p4: s/containing policy name/containing a policy name/ OK. > g) p6: The list of framed management protocols probably needs some > thought. Here is what is in the ID: > > The Value field is four octets. > > 1 SNMP-Transport-Model > 2 HTTP > 3 HTTPS/TLS > 4 SFTP (via SSH) > 5 SCP (via SSH) > > As mentioned above, why are HTTP and HTTPS different management > protocols? If you include file transfer protocols, you should > perhaps also include FTP and TFTP (as many existing boxes use > them). Perhaps we should call "SNMP-Transport-Model" simply > SNMP/TSM. Perhaps we should also add SNMP/USM (even though we > currently do not have a defined way to generate RADIUS requests > from USM). And as mentioned above, we should include NETCONF (but > then I note that NETCONF can run over SSH, BEEP, and SOAP). Agreed. See above. > h) p6: s/Telnet carried within Secure Shell/Secure Shell/ > > I do not think SSH really carries telnet in the sense of the telnet > protocol. Yes. Better text is required to distinguish the remote terminal service of SSH from the secure transport service of SSH. > i) p7 says: > > The Management-Policy-Id attribute indicates the name of the > management access policy for this user. Zero or more Management- > Policy-Id attributes MAY be sent in an Access-Accept packet. > > Why is the expected behaviour when sending multiple > Management-Policy-Id attributes? Can the client choose one of them > in whatever way and apply it? Or was the client allowed to cache > this information and to switch freely between these policies > without further request to the Radius server? Others have raised this issue. The proposed resolution is to follow the guidance of the RADIUS Issues and Fixes draft with regard to Filter-ID, i.e. it is NOT RECOMMENDED to include multiple instances in one Access-Accept message, because the behavior is undefined. > j) p8: s|SSH/telnet|SSH|g OK, taking into account (h) above. > k) p9: Would it be possible to indicate CLI access via telnet over > tls? Umm. I don't see why not. Is this a common use case? Let me craft some proposed text. > l) p12 has text that says: > > This specification describes the use of RADIUS and Diameter for > purposes of authentication, authorization and accounting for > management access to devices within local area networks. > > Why restrict this to "local area networks"? Does it really matter > whether this is used on a LAN, MAN, or WAN? If yes, explain why. Should not be restricted to LANs. Will fix. -- 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-data@psg.com Delivery-date: Mon, 12 Nov 2007 22:45:47 +0000 From: "David B. Nelson" To: , Subject: RE: review of draft-ietf-radext-management-authorization-00.txt Date: Mon, 12 Nov 2007 17:43:21 -0500 Organization: Elbrys Networks, Inc. Message-ID: <011801c8257d$6d0ac060$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: Acgle1NfxLNDmFKzR5ysQq1kh59b3AAAQTVg Juergen Schoenwaelder writes... > I think the first paragraph should also mention NETCONF as a Framed > Management protocol. Others have suggested this as well. Will do. > s/containing policy name/containing a policy name/ OK. > Why is the value 1 associated with "SNMP-Transport-Model"? Should this > not be just "SNMP", perhaps implying SNMPv3? Others have made s similar suggestion, so I think something along the lines of your recommendation is called for. > This would be more consistent with example #4, no? In fact, the > proposed RADIUS attributes do not carry what really counts - the > security level, e.g. I might accept SNMP access as long as the > actual security level is providing authPriv, regardless how this is > achieved. That may indeed be useful... > Well, since we do not have a defined way to utilize RADIUS from > SNMPv3/USM, this is probably a mood point. Still, I think calling this > enum just SNMP is the better approach. Yes. > Example #4 is nice but there is no agreement/specification how this > would work with SNMPv3 and ISMS is not chartered to figure this out. > Perhaps this can be addressed by adding a note saying. > > Note that there is currently no standardized way of implementing > this management policy mapping for SNMPv3. OK. This is currently something implementation specific. > The two new attributes Framed-Management-Protocol and > Transport-Protocol are enumerations that may need to be extended > (e.g. NETCONF is missing in the first one already). I suggest that > the IANA section spells out the rules for extending these > enumerations, e.g. by requiring a specification. Another reviewer commented in a similar fashion, that this draft should provide more specific guidance to IANA than simply falling back on RFC 3775. I'll add some text. > The first sentence in the security considerations kind of restricts > RADIUS and DIAMETER to "local area networks". I am not sure why this > should be useful or what breaks if the network is not a local area > network (however this is defined). I suggest to simple remove the > phrase "within local area networks" or if there is a reason for > having this restriction, then please add text which spells the > reasons out. No reason. I'll remove the restriction. Thanks for the through review. -- 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-data@psg.com Delivery-date: Mon, 12 Nov 2007 22:20:26 +0000 Date: Sun, 11 Nov 2007 23:20:51 +0100 From: Juergen Schoenwaelder To: radiusext@ops.ietf.org Subject: review of draft-ietf-radext-management-authorization-00.txt Message-ID: <20071111222051.GB18374@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Hi, I have reviewed . a) p1: s/more granular/granular/ If you keep the word more, you have to make it clear to what you compare things... b) I am generally not clear what HTTP means as a management protocol and think this should be defined. I assume you mean a human GUI interface running over HTTP but since you just say HTTP, it becomes confusing if you have for instance NETCONF/SOAP/HTTP. c) p3: s/ASCII-text/text-based/ I think it does not really matter whether its ASCII or UTF8 or... d) Are HTTP and HTTPS really two different framed management protocols? Or is HTTPS just HTTP with a transport of TLS? e) p3: Add NETCONF to the examples of framed management protocols and include RFC 4741 in the references. f) p4: s/containing policy name/containing a policy name/ g) p6: The list of framed management protocols probably needs some thought. Here is what is in the ID: The Value field is four octets. 1 SNMP-Transport-Model 2 HTTP 3 HTTPS/TLS 4 SFTP (via SSH) 5 SCP (via SSH) As mentioned above, why are HTTP and HTTPS different management protocols? If you include file transfer protocols, you should perhaps also include FTP and TFTP (as many existing boxes use them). Perhaps we should call "SNMP-Transport-Model" simply SNMP/TSM. Perhaps we should also add SNMP/USM (even though we currently do not have a defined way to generate RADIUS requests from USM). And as mentioned above, we should include NETCONF (but then I note that NETCONF can run over SSH, BEEP, and SOAP). h) p6: s/Telnet carried within Secure Shell/Secure Shell/ I do not think SSH really carries telnet in the sense of the telnet protocol. i) p7 says: The Management-Policy-Id attribute indicates the name of the management access policy for this user. Zero or more Management- Policy-Id attributes MAY be sent in an Access-Accept packet. Why is the expected behaviour when sending multiple Management-Policy-Id attributes? Can the client choose one of them in whatever way and apply it? Or was the client allowed to cache this information and to switch freely between these policies without further request to the Radius server? j) p8: s|SSH/telnet|SSH|g k) p9: Would it be possible to indicate CLI access via telnet over tls? l) p12 has text that says: This specification describes the use of RADIUS and Diameter for purposes of authentication, authorization and accounting for management access to devices within local area networks. Why restrict this to "local area networks"? Does it really matter whether this is used on a LAN, MAN, or WAN? If yes, explain why. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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-data@psg.com Delivery-date: Mon, 12 Nov 2007 22:20:08 +0000 Date: Thu, 6 Sep 2007 15:16:30 +0200 From: Juergen Schoenwaelder To: radiusext@ops.ietf.org Subject: review of draft-ietf-radext-management-authorization-00.txt Message-ID: <20070906131630.GB2529@elstar.local> Reply-To: j.schoenwaelder@jacobs-university.de Mail-Followup-To: radiusext@ops.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) Hi, I have read and in general I believe this document is in good shape and useful. I have some issues which I tried to write up in the radiusext WG way... --- Description: mention NETCONF as framed management protocol Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E Priority: 2 Section: 3 Rationale/Explanation of issue: I think the first paragraph should also mention NETCONF as a Framed Management protocol. -- Description: add missing article Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E Priority: 2 Section: 4 Rationale/Explanation of issue: s/containing policy name/containing a policy name/ -- Description: SNMP-Transport-Model vs. SNMP Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 1 Section: 7.1 Rationale/Explanation of issue: Why is the value 1 associated with "SNMP-Transport-Model"? Should this not be just "SNMP", perhaps implying SNMPv3? This would be more consistent with example #4, no? In fact, the proposed RADIUS attributes do not carry what really counts - the security level, e.g. I might accept SNMP access as long as the actual security level is providing authPriv, regardless how this is achieved. Well, since we do not have a defined way to utilize RADIUS from SNMPv3/USM, this is probably a mood point. Still, I think calling this enum just SNMP is the better approach. -- Description: SNMP policy mapping and the reality Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 2 Section: 8 Rationale/Explanation of issue: Example #4 is nice but there is no agreement/specification how this would work with SNMPv3 and ISMS is not chartered to figure this out. Perhaps this can be addressed by adding a note saying. Note that there is currently no standardized way of implementing this management policy mapping for SNMPv3. -- Description: rules for extending enumerations Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: T Priority: 2 Section: 12 Rationale/Explanation of issue: The two new attributes Framed-Management-Protocol and Transport-Protocol are enumerations that may need to be extended (e.g. NETCONF is missing in the first one already). I suggest that the IANA section spells out the rules for extending these enumerations, e.g. by requiring a specification. -- Description: local or not so local area networks Submitter name: Juergen Schoenwaelder Submitter email address: j.schoenwaelder@jacobs-university.de Date first submitted: Thu Sep 6 14:47:36 CEST 2007 Reference: Document: draft-ietf-radext-management-authorization Comment type: E/T Priority: 2 Section: 13 Rationale/Explanation of issue: The first sentence in the security considerations kind of restricts RADIUS and DIAMETER to "local area networks". I am not sure why this should be useful or what breaks if the network is not a local area network (however this is defined). I suggest to simple remove the phrase "within local area networks" or if there is a reason for having this restriction, then please add text which spells the reasons out. -- /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 -- 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-data@psg.com Delivery-date: Sun, 11 Nov 2007 05:21:54 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D Action:draft-ietf-radext-extended-attributes-00.txt Message-Id: Date: Sun, 11 Nov 2007 00:20:01 -0500 --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 : Extended Remote Authentication Dial In User Service (RADIUS) Attributes Author(s) : Y. Li, et al. Filename : draft-ietf-radext-extended-attributes-00.txt Pages : 13 Date : 2007-11-10 In order for the Remote Authentication Dial In User Service (RADIUS) protocol to continue to support new applications the RADIUS attribute type space must be extended beyond the current limit of 255 possible attribute types while maintaining backwards compatibility with existing RADIUS implementations. This document defines a mechanism to accomplish that task, along with standard methods to group related attributes together and to encode values that don't fit into 253 octets. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-extended-attributes-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radext-extended-attributes-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radext-extended-attributes-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-11-11001208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radext-extended-attributes-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radext-extended-attributes-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-11001208.I-D\@ietf.org> --OtherAccess-- --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-data@psg.com Delivery-date: Fri, 09 Nov 2007 16:19:34 +0000 From: The IESG To: IETF-Announce Cc: Internet Architecture Board , RFC Editor , radext mailing list , radext chair Subject: Document Action: 'Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)' to Informational RFC Message-Id: Date: Fri, 09 Nov 2007 10:54:20 -0500 The IESG has approved the following document: - 'Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) ' as an Informational RFC This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-rfc3576bis-13.txt Technical Summary This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. Working Group Summary This document represents an update to RFC 3576, addressing issues and fixes that have been identified since the document was originally published. Originally, these issues were included in the RADIUS Issues and Fixes document, but were sufficient in number and size to require a revision to RFC 3576. Protocol Quality This document describes issues that were encountered by implementers of RFC 3576. As a result, it has been reviewed by implementers as well as operators. Dan Romascanu reviewed the document on behalf of the IESG. -- 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-data@psg.com Delivery-date: Thu, 08 Nov 2007 19:39:52 +0000 Message-ID: From: "Bernard Aboba" To: dromasca@avaya.com, radext-chairs@tools.ietf.org Cc: radiusext@ops.ietf.org Bcc: Subject: RE: 3576bis Date: Thu, 08 Nov 2007 11:38:43 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed As far as I know, there are no remaining open issues on RFC 3576bis. >From: "Romascanu, Dan (Dan)" >To: >Subject: 3576bis >Date: Thu, 8 Nov 2007 12:02:25 +0100 > > >David, Bernard, > >Sam Hartman changed his DISCUSS in ABSTAIN after the publication of >draft-13. At this point in time with no pending DISCUSSes I can ask the >IESG secretary to send the approval announcement and forward the >document to the RFC Editor. Do you need to do anything else with the >document? Any RFC Editor notes I am not aware about? > >Dan > > -- 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-data@psg.com Delivery-date: Thu, 08 Nov 2007 18:08:06 +0000 From: "David B. Nelson" To: Cc: , "'Bernard Aboba'" Subject: Call for RADEXT agenda items for IETF-70 Date: Thu, 8 Nov 2007 13:05:43 -0500 Organization: Elbrys Networks, Inc. Message-ID: <002201c82231$faa972d0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit thread-index: AcgiMfqRLSgQjh5aR+6rc3ZNfcsytQ== The RADEXT WG will be meeting during IETF-70 in Vancouver, on Wednesday, December 5, 2007 from 9:00 - 11:30 AM, in the Cypress Room (time and room still subject to change). The chairs will be posting the WG meeting agenda in the next week or so. We'd like to solicit requests for presentation time slots. If you have any items for discussion during the RADEXT WG session at IETF-70, please send a note to the chairs, including the topic, the requested slot duration, and a pointer to any related Interned Draft(s). Thanks! -- 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-data@psg.com Delivery-date: Tue, 06 Nov 2007 15:39:43 +0000 From: "David B. Nelson" To: "'Bernard Aboba'" , Subject: RE: Review of Management Authorization -00 document Date: Tue, 6 Nov 2007 10:37:20 -0500 Organization: Elbrys Networks, Inc. Message-ID: <000a01c8208a$ebde28c0$091716ac@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcggAq6EA9/fFUL9TIajw07MWHm45QAhuQIg I'm on the road currently, so I'll comment only briefly, and follow up later in the week. Thank you for the thoughtful and thorough review. Regards, Dave > Section 3 > > This seems to imply that SSH would not be an acceptable value for > Framed-Management-Protocol. Is that right? SSH delivers a secure transport service and a remote login (terminal emulation service). That does not seem to be the same thing as a specific management protocol, of which SNMP is the most obvious example. Should SHH (alone) be considered a framed management protocol, or should it be considered a remote form of CLI access? > Section 7.2 > > I am not clear that all combinations of Framed-Management-Protocol > and Transport-Protocol make sense. I'll take a look at this in detail and follow up. > Section 7.3 > > The Management-Policy-Id attribute indicates the name of the > management access policy for this user. Zero or more Management- > Policy-Id attributes MAY be sent in an Access-Accept packet. > Identifying a policy by name allows the policy to be used on > different NASes without regard to implementation details. > > What does it mean if multiple Management-Policy-Id attributes are > included? > How are the policies merged? If this is implementation-specific, isn't > the result undefined? This issues was raided by others. The proposed resolution is to threat it in the same way as we treat Filter-Id in the Issues & Fixes draft, i.e. multiple instances are NOT RECOMMENDED and the result is undefined. > Section 8 > > > * Service-Type (6) = Administrative (6) > * Transport-Protocol (xx) = None (1) > > Is the Transport-Protocol really none?? Hmmm... > Section 9 > > I'm not clear that these statements make sense because there typically is > no authentication in these AAA exchanges, right? I'll take a closer look. Probably wanton application of boilerplate text. > Section 12 > > This document contains placeholders ("TBA") for assigned numbers > within the RADIUS Attributes registry, to be assigned by IANA at the > time this document should be published as an RFC. Assignement of > additional values for attributes defined in this document are to be > processed as described in [RFC3575]. > > RFC 3575 specifies "First come, first served", which requires no review. > Is this really what you want? Should we tighten up on some of these allocations, above any beyond the provisions of RFC 3575? I thought we didn't want to go down that path... -- 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-data@psg.com Delivery-date: Mon, 05 Nov 2007 23:17:39 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review of Management Authorization -00 document Date: Mon, 05 Nov 2007 15:16:31 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Section 3 Framed Management means management of an entity by means of a non- interactive, non-CLI-style method. The management information is typically formatted in a binary or textual protocol, such as HTTP or SNMP. While remote management by interactive CLI sessions are carried over protocols, such as Telnet, Rlogin, and SSH, these protocols are primarily for the delivery of terminal, or pseudo-TTY services. Command Line Interface, Menu Interface, or other ASCII (UTF-8) terminal emulation interfaces are not considered to be Framed Management protocols, as used in this document. Examples of Framed Management protocols include HTTP, HTTPS, and SNMP. To support the authorization and provisioning of Framed Management access to managed entities, this document introduces a new value for the Service-Type attribute [RFC2865], and one new attribute. The new value for the Service-Type attribute is Framed-Management. The definition of this service is the provisioning of remote device management via a Framed Management protocol, as described in this section. The new attribute is Framed-Management-Protocol, the value of which specifies a particular protocol for use in the remote management session. This seems to imply that SSH would not be an acceptable value for Framed-Management-Protocol. Is that right? Section 7.2 I am not clear that all combinations of Framed-Management-Protocol and Transport-Protocol make sense. For example, are the following combinations possible? Example 1: Framed-Management-Protocol = HTTPS/TLS (3) Transport-Protocol != TLS (3) Example 2: Framed-Management-Protocol = HTTP (2) Transport-Protocol = TLS (3) How is this different from Framed-Management-Protocol = HTTPS/TLS? Example 3: Framed-Management-Protocol = SFTP (4) or SCP (5) Transport-Protocol != SSH (2) If Framed-Management-Protocol and Transport-Protocol are really orthogonal, then I'd suggest that Framed-Management-Protocol not include any implied transports and that the Transport-Protocol list be expanded. For example: Framed-Management-Protocol 1 SNMP 2 HTTP 3 FTP 4 CP Transport-Protocol 1 UDP 2 TCP 3 SSH over TCP 4 TLS over TCP 5 TLS over UDP Section 7.3 The Management-Policy-Id attribute indicates the name of the management access policy for this user. Zero or more Management- Policy-Id attributes MAY be sent in an Access-Accept packet. Identifying a policy by name allows the policy to be used on different NASes without regard to implementation details. What does it mean if multiple Management-Policy-Id attributes are included? How are the policies merged? If this is implementation-specific, isn't the result undefined? Section 8 * Service-Type (6) = Administrative (6) * Transport-Protocol (xx) = None (1) Is the Transport-Protocol really none?? Section 9 What this specification says about the applicability of the attributes for RADIUS Access-Request packets applies in Diameter to AA-Request [RFC4005] or Diameter-EAP-Request [RFC4072]. What is said about Access-Challenge applies in Diameter to AA-Answer [RFC4005] or Diameter-EAP-Answer [RFC4072] with Result-Code AVP set to DIAMETER_MULTI_ROUND_AUTH. What is said about Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer messages that indicate success. Similarly, what is said about RADIUS Access-Reject packets applies in Diameter to AA- Answer or Diameter-EAP-Answer messages that indicate failure. What is said about COA-Request applies in Diameter to Re-Auth-Request [RFC4005]. I'm not clear that these statements make sense because there typically is no authentication in these AAA exchanges, right? Section 12 This document contains placeholders ("TBA") for assigned numbers within the RADIUS Attributes registry, to be assigned by IANA at the time this document should be published as an RFC. Assignement of additional values for attributes defined in this document are to be processed as described in [RFC3575]. RFC 3575 specifies "First come, first served", which requires no review. Is this really what you want? -- 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-data@psg.com Delivery-date: Mon, 05 Nov 2007 17:34:31 +0000 Message-ID: From: "Bernard Aboba" To: radiusext@ops.ietf.org Bcc: Subject: Review of Design-01 Strawman Date: Mon, 05 Nov 2007 09:33:08 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Section 2.1.3 This section makes a recommendation that complex data types SHOULD be avoided, and then goes on to say that complex attributes are acceptable for authentication mechanisms. These two recommendations seem to be in conflict; my recommendation is that an exception for authentication mechanisms be inserted into the first paragraph and that the two paragraphs be placed closer together: Given these limitations, the introduction of complex attributes can require code changes on the RADIUS server which would be unnecessary if basic data types had been used instead. In addition, attribute- specific parsing means more complex software to develop and maintain. More complexity can lead to more error prone implementations, and interoperatibility problems. This issues can increase costs to network administrators as well as reducing reliability and introducing deployment barriers. As a result, the introduction of new complex data types within RADIUS attribute specifications SHOULD be avoided. .... As can be seen in Appendix B, most of the complex attributes involve authentication or security functionality. Supporting this functionality requires code changes on both the RADIUS client and server, regardless of the attribute format. As a result, in most cases, the use of complex attributes to represent these methods is acceptable, and does not create additional interoperability or deployment issues. Section 2.1.4 New specifications SHOULD avoid defining message formats for services inside a RADIUS document. In addition, the service being provisioned SHOULD NOT be defined in a RADIUS specification... For new services using RADIUS, the service SHOULD be defined elsewhere, and provisioned in RADIUS. Could be rephrased to: RADIUS specifications define how an existing service or protocol can be provisioned using RADIUS. Therefore, it is expected that a RADIUS attribute specification will reference documents defining the protocol or service to be provisioned. Within the IETF, a RADIUS attribute specification SHOULD NOT be used to define the protocol or service being provisioned. New services using RADIUS for provisioning SHOULD be defined elsewhere and referenced in the RADIUS specification. Section 2.2 The high-order octet of the Vendor-Id field is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Code of the Vendor in network byte order. Actually, I believe that the SMI Enterprise code is 4 octets, no? Other attribute formats are NOT RECOMMENDED. Examples of NOT RECOMMENDED formats include Vendor types of more than 16 bits, Vendor lengths of less than 8 bits, Vendor lengths of more than 8 bits, and Vendor-Specific contents that are not in Type-Length-Value format. Is there a recommendation that RADIUS servers support the 16 bit vendor type format? Section 3.1.1 Vendors and SDOs are reminded that the standard RADIUS attribute ID space, and the ennumerated Recommend changing to: Vendors and SDOs are reminded that the standard RADIUS attribute space and the ennumerated The following paragraphs are a bit awkward: The VSA space is intended to enable self-allocation of RADIUS extensions for use by one or more vendors within an industry segment or within the global Internet community. As the use-cases for VSAs vary considerably, it is important to make a distinction between use- cases in terms of the expected level of design guideline adherence and attention to interoperability considerations. The design and specification of VSAs for multi-vendor usages, and/or by non-IETF SDOs, SHOULD be undertaken with the same level of care as standard RADIUS attributes. Specifically, the provisions of this document that apply to Standard RADIUS attributes SHOULD apply to any such VSAs. In this regard, the term "Vendor-Specific Attribute" is perhaps unfortunate. The term refers both to the encoding format, and to the common use case where individual vendors allocate attributes not suitable for general usage. When used by an SDO, a VSA is intended to have a significant level of interoperability, just like the standard RADIUS attributes. As such, those SDO attributes are not specific to any single vendor, and the term "Vendor-Specific" may be misleading. An alternate term which better describes the SDO use-case is SDO-Specific Attribute (SSA). For interoperability, the SSAs happen to use the same encoding format as those VSAs that are defined by an individual vendor. Recommend changing to: [RFC2865] Section 5.26 uses the term "Vendor-Specific Attribute" to refer to an encoding format which can be used by individual vendors to define attributes not suitable for general usage. However, since then VSAs have also become widely used by SDOs defining attributes intended for multi-vendor interoperability. As such, these attributes are not specific to any single vendor, and the term "Vendor-Specific" may be misleading. An alternate term which better describes this use case is SDO-Specific Attribute (SSA). The design and specification of VSAs for multi-vendor usage SHOULD be undertaken with the same level of care as standard RADIUS attributes. Specifically, the provisions of this document that apply to standard RADIUS attributes also apply to SSAs or VSAs for multi-vendor usage. Section 3.1.2 However, it is RECOMMENDED that Vendors follow the guidelines outlined here, which are intended to enable maximum interoperability with minimal changes to existing systems. Recommend changing to: However, it is RECOMMENDED that vendors follow the guidelines outlined here, which are intended to enable maximum interoperability with minimal changes to existing systems. " Vendors are reminded that allocations of attributes or values for attributes of enumerated type from the standard space MUST follow the process described in [RFC3575] Section 2.1. If this is not possible, they SHOULD self-allocate an attribute from their Vendor-Specific space, and define an appropriate value for it. If Vendors require multi-vendor interoperability for some RADIUS specification, then the guidelines given below for SDO allocations SHOULD be followed." These paragraphs seem like they belong in Section 3.1.1. Is there a way to integrate them there? Section 3.1.3 This change control can be obtained by requesting a Private Enterprise Number (PEN) from the Internet Assigned Number Authority (IANA), for use as a Vendor-Id within a Vendor-Specific attribute. The term PEN is used here, but earlier, the term SMI vendor code is used. Can we make the usage consistent? " This process means that SDOs do not have to rehost VSAs into the standards space solely for the purpose of obtaining IETF review. Rehosting puts pressure on the standards space, and may be harmful to interoperability, since it can create two ways to configure the same functionality. Rehosting may also require changes to the RADIUS data model which will affect implementations that do not intend to support the SDO specifications." How about this? " It should be understood that SDOs do not have to rehost VSAs into the standards space solely for the purpose of obtaining IETF review. Rehosting puts pressure on the standards space, and may be harmful to interoperability, since it can create two ways to provision the same service. Rehosting may also require changes to the RADIUS data model which will affect implementations that do not intend to support the SDO specifications." Section 3.1.4 " SDOs are encouraged to seek review of VSA specifications by the IETF, prior to finalization of a proposed specification. Once reviewed, the specifications SHOULD be made publicly available, for maximum interoperability. Where the full specifications cannot be made public, the RADIUS attribute and value definitions SHOULD be published instead as an Informational RFC, as with [RFC4679]. This process SHOULD be followed instead of requesting IANA allocations from within the standard RADIUS attribute space. Similarly, vendors SHOULD make their specifications publicly available, for maximum interoperability. Due to the large number of vendors, it is not necessary for them to request publication of their VSA specifications as Informational RFCs by the IETF. All other specifications, including new authentication and/or security methods SHOULD be allocated via the standard RADIUS space, as noted in [RFC3575] Section 2.1." How about this? " SDOs are encouraged to seek early review of SSA specifications by the IETF. This review may be initiated by sending mail to the AAA Doctors list. Since the IETF is not a membership organization, in order to enable the RADIUS SSA specification to be reviewed, it is RECOMMENDED that it be made publicly available; this also encourages interoperability. Where the RADIUS SSA specification is embedded within a larger document which cannot be made public, the RADIUS attribute and value definitions SHOULD be published instead as an Informational RFC, as with [RFC4679]. This process SHOULD be followed instead of requesting IANA allocations from within the standard RADIUS attribute space. Similarly, vendors are encouraged to make their specifications publicly available, for maximum interoperability. However, it is not necessary for them to request publication of their VSA specifications as Informational RFCs by the IETF. All other specifications, including new authentication and/or security mechanisms SHOULD be allocated via the standard RADIUS space, as noted in [RFC3575] Section 2.1." Section 4 This document requires no action by IANA. [RFC4005]. What is the [RFC4005] reference for? Section 5 Where new RADIUS attributes use cryptographic algorithms, algorithm negotiation SHOULD be supported. Specification of a mandatory-to- implement algorithm is REQUIRED, and it is RECOMMENDED that the mandatory-to-implement algorithm be certifiable under FIPS 140. Can we reference FIPS 140 here? There is currently a draft FIPS 140-3 document available from NIST. -- 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: