From wwwrun@core3.amsl.com Wed Apr 1 07:28:08 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8984328C1B7; Wed, 1 Apr 2009 07:28:08 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090401142808.8984328C1B7@core3.amsl.com> Date: Wed, 1 Apr 2009 07:28:08 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-secshell (Secure Shell Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:28:08 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Secure Shell Transport Model for SNMP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-15.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13827&rfc_flag=0 The following IPR Declarations may be related to this I-D: From wwwrun@core3.amsl.com Wed Apr 1 07:40:16 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2542E28C1DD; Wed, 1 Apr 2009 07:40:16 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090401144016.2542E28C1DD@core3.amsl.com> Date: Wed, 1 Apr 2009 07:40:16 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-tmsm (Transport Subsystem for the Simple Network Management Protocol (SNMP)) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:40:16 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Transport Subsystem for the Simple Network Management Protocol (SNMP) ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-16.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=13828&rfc_flag=0 The following IPR Declarations may be related to this I-D: From wwwrun@core3.amsl.com Wed Apr 1 07:40:56 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B17F528C0F2; Wed, 1 Apr 2009 07:40:56 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090401144056.B17F528C0F2@core3.amsl.com> Date: Wed, 1 Apr 2009 07:40:56 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-transport-security-model (Transport Security Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2009 14:40:56 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Transport Security Model for SNMP ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15419&rfc_flag=0 The following IPR Declarations may be related to this I-D: From wjhns1@hardakers.net Fri Apr 3 13:25:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C12E28C0F2 for ; Fri, 3 Apr 2009 13:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id me-sHgzM30Hg for ; Fri, 3 Apr 2009 13:25:21 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 91C073A6A7F for ; Fri, 3 Apr 2009 13:25:16 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 68C4A39A118 for ; Fri, 3 Apr 2009 13:26:19 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Fri, 03 Apr 2009 13:26:18 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 20:25:26 -0000 I wanted to submit my suggested charter text immediately for potential consideration. I believe some of the author document authors, chairs, etc will likely want to comment on the contents. I'm going to be away on vacation next week, so in the end I decided to submit it directly to the list. There is a number of things that are certainly not finalized (like the two chairs, to say the least... One roughly volunteered and the other expressed a desire to step down at some point so I'll let them answer if they want to continue together as co-chairs). I'm also personally less familiar with the new body of RADIUS authorization work, so the text describing that work needs to be carefully reviewed as I may not have summarized the problem and solution space perfectly. The previous charter was directly worded to discuss radius rather than generic AAA terminology, so I stuck to using RADIUS directly as well. The dates are also fairly randomly made up. They're currently aligned on a time-schedule wise, which I'm not sure is appropriate since I suspect the solution spaces are at different current levels of completeness. ---- Begin proposed charter text ---- Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * Juergen Schoenwaelder * David Harrington Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS to its full extent, the authorization configuration or decision making needs to be outsourced to the RADIUS as well. The result will be a new method of outsourced authorization or centralized administration of View-based Access Control Model (VACM) rules via a RADIUS. Additionally, new work will be undertaken to define a DTLS-based transport that can offer support for environments that prefer certificate authentication and/or datagram-based transmissions. Certificate based authentication is desirable for many environments with a centralized authentication service. Datagram based transports may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A DTLS-based transport would offer a solution that addresses both of these situations. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop a DTLS-based Transport Subsystem. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control rules via a RADIUS. - Specify the DTLS transport for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the DTLS transport for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2009 Submit documentation on the DTLS transport for SNMP to IESG Jan 2009 Submit documentation for the centralized access control to IESG -- Wes Hardaker From dnelson@elbrysnetworks.com Fri Apr 3 15:13:14 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EDC93A6A04 for ; Fri, 3 Apr 2009 15:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.861 X-Spam-Level: X-Spam-Status: No, score=-0.861 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znCTDcyhqq82 for ; Fri, 3 Apr 2009 15:13:13 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 5AF453A6806 for ; Fri, 3 Apr 2009 15:12:50 -0700 (PDT) Received: (qmail 15778 invoked from network); 3 Apr 2009 17:13:52 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Apr 2009 17:13:52 -0400 From: "David B. Nelson" To: References: Date: Fri, 3 Apr 2009 17:13:46 -0400 Organization: Elbrys Networks, Inc. Message-ID: <5EDFC935D6D14C3493F361F8C7ABC476@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.5579 Thread-Index: Acm0mnqACvUdb7wwR8e4eUqxQC/z5AABAMSw In-Reply-To: Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:13:14 -0000 Wes Hardaker writes... > I'm going to be away on vacation next week... Enjoy! > The result will be a new method of outsourced authorization > or centralized administration of View-based Access Control > Model (VACM) rules via a RADIUS. Trying to pick my words carefully here... Would we end up with a new Access Control Model? Or would we attempt to extend an existing one -- VACM? We could define a new Access Control Model -- call it VACM-R -- that is basically the same thing as existing VACM, but it knows to outsource the identity lookup function to RADIUS, rather than referencing a table in the local configuration data store. The document could liberally reference the VACM RFC. I'm suggesting that it follows the modular nature of the SNMP architecture better if we simply substitute VACM-R for VACM as the ACM in a particular deployment, rather than attempting to specify that an enhanced version of VACM is being used. Do models in the SNMP architecture even have version numbers? :-) > The current goal of the ISMS working group is two-fold: to > develop a method for allowing for access control decisions to > be based on information provide by an AAA provisioning service > and to develop a DTLS-based Transport Subsystem. Looks good. s/provide/provided/ > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control rules via a RADIUS. > - Specify the DTLS transport for SNMP. We may want to wordsmith this a little bit. My vision of the solution is that the rules themselves, the OID-by-OID access rights, are still stored in local configuration data store and provisioned as they are today. What I think we want to outsource to RADIUS in the mapping of securityName to access control group name. That is to say, the mapping of an authenticated principal name to a pre-defined role. If we want to [optionally] provision the detailed rules via RADIUS, we can perhaps do that, but I think the charter wording should not mandate that particular solution choice. From j.schoenwaelder@jacobs-university.de Fri Apr 3 15:28:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760D728C19D for ; Fri, 3 Apr 2009 15:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2iZKiOeyhnr for ; Fri, 3 Apr 2009 15:28:26 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 310C128C193 for ; Fri, 3 Apr 2009 15:28:26 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE3F3C0053; Sat, 4 Apr 2009 00:29:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wC-vJq9pwURA; Sat, 4 Apr 2009 00:29:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EFBC2C001B; Sat, 4 Apr 2009 00:29:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id ECDF0A4D71F; Sat, 4 Apr 2009 00:29:10 +0200 (CEST) Date: Sat, 4 Apr 2009 00:29:10 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20090403222910.GB26360@elstar.local> Mail-Followup-To: "David B. Nelson" , "isms@ietf.org" References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:28:27 -0000 On Fri, Apr 03, 2009 at 11:13:46PM +0200, David B. Nelson wrote: > Trying to pick my words carefully here... > > Would we end up with a new Access Control Model? Or would we attempt to > extend an existing one -- VACM? We could define a new Access Control Model > -- call it VACM-R -- that is basically the same thing as existing VACM, but > it knows to outsource the identity lookup function to RADIUS, rather than > referencing a table in the local configuration data store. The document > could liberally reference the VACM RFC. I'm suggesting that it follows the > modular nature of the SNMP architecture better if we simply substitute > VACM-R for VACM as the ACM in a particular deployment, rather than > attempting to specify that an enhanced version of VACM is being used. I believe to recall from previous discussions (probably around the ISMS interim in Boston some years ago) that the current EoPs in the SNMP RFCs do not really allow to have multiple access control models in place since there is no defined way to select which access control model is in charge for a given access control decision. If my recollection is correct, taking this path might involve much more work than one might expect... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Fri Apr 3 15:38:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0D463A67EC for ; Fri, 3 Apr 2009 15:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.958 X-Spam-Level: X-Spam-Status: No, score=-1.958 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-lt8TAZi4la for ; Fri, 3 Apr 2009 15:38:50 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 51A2C3A657C for ; Fri, 3 Apr 2009 15:38:50 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 81F2839A118; Fri, 3 Apr 2009 15:39:53 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> Date: Fri, 03 Apr 2009 15:39:53 -0700 In-Reply-To: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> (David B. Nelson's message of "Fri, 3 Apr 2009 17:13:46 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:38:51 -0000 >>>>> On Fri, 3 Apr 2009 17:13:46 -0400, "David B. Nelson" said: DBN> Would we end up with a new Access Control Model? I'd assume not, but I tried to the leave the wording not pointing to a specific solution. I personally believe, as Juergen has already stated, that opening the "what if we define something totally new" bag of worms will explode because of the lack of standardization for how a management station selects which ACM a given agent should be using (and what happens when you have two). I personally didn't have a huge amount of knowledge about what the solution-space definers wish so I left it a bit generic. I'd *much* prefer that someone else more knowledgeable about the draft write replacement text for my proposal. -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From dnelson@elbrysnetworks.com Fri Apr 3 15:40:16 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 525D23A6810 for ; Fri, 3 Apr 2009 15:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.63 X-Spam-Level: X-Spam-Status: No, score=-1.63 tagged_above=-999 required=5 tests=[AWL=0.969, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9CMYcwuAiL68 for ; Fri, 3 Apr 2009 15:40:15 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 58FFE3A657C for ; Fri, 3 Apr 2009 15:40:15 -0700 (PDT) Received: (qmail 17997 invoked from network); 3 Apr 2009 18:41:18 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Apr 2009 18:41:18 -0400 From: "David B. Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> Date: Fri, 3 Apr 2009 18:41:12 -0400 Organization: Elbrys Networks, Inc. Message-ID: 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.5579 Thread-Index: Acm0q6eJOp0E2FG6TjC7jq2nViuIBQAAD5wQ In-Reply-To: <20090403222910.GB26360@elstar.local> Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:40:16 -0000 Juergen Schoenwaelder writes... > I believe to recall from previous discussions (probably around > the ISMS interim in Boston some years ago) that the current > EoPs in the SNMP RFCs do not really allow to have multiple > access control models in place... Multiple ACMs in place / use at one time? In a single implementation? Ever? I have to assume that the notion of an Access Control Subsystem abstraction implies that there can be multiple Access Control Models, each of which could serve the as the "implementation"" of the ACS. Are you saying that is *not* the case? > ... since there is no defined way to select which access > control model is in charge for a given access control decision. OK, so this could be a matter of local configuration, right? One could [statically] "config out" VACM and "config in" VACM-R? > If my recollection is correct, taking this path might involve > much more work than one might expect... In which case we could attach an "extension" onto VACM? I suppose that's no different from the "config out" / "config in" scenario, just a little less modular and elegant. Does anyone else have insight into the modularity constraints on ACMs? From wjhns1@hardakers.net Fri Apr 3 15:59:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E70B03A6912 for ; Fri, 3 Apr 2009 15:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkAq4FEB141W for ; Fri, 3 Apr 2009 15:59:36 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id CD7EF28C0FF for ; Fri, 3 Apr 2009 15:59:35 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id D912339A118; Fri, 3 Apr 2009 16:00:37 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> Date: Fri, 03 Apr 2009 16:00:36 -0700 In-Reply-To: (David B. Nelson's message of "Fri, 3 Apr 2009 18:41:12 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2009 22:59:37 -0000 >>>>> On Fri, 3 Apr 2009 18:41:12 -0400, "David B. Nelson" said: DBN> I have to assume that the notion of an Access Control Subsystem DBN> abstraction implies that there can be multiple Access Control DBN> Models, each of which could serve the as the "implementation"" of DBN> the ACS. Are you saying that is *not* the case? Lets back up and forget that train. Because it is that complex (not because it's not interesting or possible). The real perceived goal, as you stated earlier, is to have RADIUS bootstrap VACM with data, right? That's what the current draft does (I haven't read it)? And that's what the solution space will be? If so, that's what we should write into the charter. DBN> Does anyone else have insight into the modularity constraints on ACMs? (The quickest summary is that the M in ACM does mean "module". Which means it was, in theory, designed to be able to be swapped out and replaced with something else. But the operational aspects of actually doing that aren't easy, to say the least.) -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From dnelson@elbrysnetworks.com Fri Apr 3 17:17:59 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69D6B3A6883 for ; Fri, 3 Apr 2009 17:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 tagged_above=-999 required=5 tests=[AWL=0.881, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09xdJkH-d+f6 for ; Fri, 3 Apr 2009 17:17:58 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 3A8693A68F2 for ; Fri, 3 Apr 2009 17:17:57 -0700 (PDT) Received: (qmail 18853 invoked from network); 3 Apr 2009 19:18:59 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 3 Apr 2009 19:18:59 -0400 From: "David B. Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local> Date: Fri, 3 Apr 2009 19:18:53 -0400 Organization: Elbrys Networks, Inc. Message-ID: 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.5579 Thread-Index: Acm0sADz2jN1k556SEy9Yzz5FgJaiwAAC+Og In-Reply-To: Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 00:17:59 -0000 > Wes Hardaker writes... > The real perceived goal, as you stated earlier, is to have > RADIUS bootstrap VACM with data, right? Yes. As a security / AAA guy, I'm cool with that. I guess I was anticipating a polite "dope-slap" from the SNMP guys around my lack of sensitivity to maintaining the modularity of the SNMP architecture. :-) What I'm hearing is that there really isn't so much modularity in the Access Control Subsystem, when you get down to implementation details, so we don't need to sweat too much about that. Sweet! > If so, that's what we should write into the charter. Right. How about this? OLD: In order to leverage a centralized RADIUS to its full extent, the authorization configuration or decision making needs to be outsourced to the RADIUS as well. The result will be a new method of outsourced authorization or centralized administration of View-based Access Control Model (VACM) rules via a RADIUS. NEW: In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be a new method of outsourced authorization of an authenticated principal, for use within the View-based Access Control Model (VACM). And this? OLD: The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control rules via a RADIUS. - Specify the DTLS transport for SNMP. NEW: The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions based on authorization information for an authenticated principal obtained via RADIUS. - Specify the DTLS transport for SNMP. From wjhns1@hardakers.net Fri Apr 3 17:44:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 500753A68CF for ; Fri, 3 Apr 2009 17:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVtwRTFBBAfW for ; Fri, 3 Apr 2009 17:44:39 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C60553A6869 for ; Fri, 3 Apr 2009 17:44:31 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id ABF7D39A118; Fri, 3 Apr 2009 17:45:26 -0700 (PDT) From: Wes Hardaker To: "David B. Nelson" Organization: Sparta References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> Date: Fri, 03 Apr 2009 17:45:26 -0700 In-Reply-To: (David B. Nelson's message of "Fri, 3 Apr 2009 19:18:53 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 00:44:40 -0000 >>>>> On Fri, 3 Apr 2009 19:18:53 -0400, "David B. Nelson" said: DBN> In order to leverage a centralized RADIUS service to its DBN> full extent, the access control decision in the Access Control DBN> Subsystem needs to be based on authorization information DBN> received from RADIUS as well. The result will be a new DBN> method of outsourced authorization of an authenticated DBN> principal, for use within the View-based Access Control DBN> Model (VACM). Sounds good, at least from the high level :-) DBN> - Specify a mechanism to support centralization of DBN> SNMPv3 Access Control decisions based on authorization DBN> information for an authenticated principal obtained DBN> via RADIUS. Yep. -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Fri Apr 3 22:52:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33CB3A6816 for ; Fri, 3 Apr 2009 22:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.091 X-Spam-Level: X-Spam-Status: No, score=-2.091 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRh1-H10ffbx for ; Fri, 3 Apr 2009 22:52:28 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id F31783A67DD for ; Fri, 3 Apr 2009 22:52:27 -0700 (PDT) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A32B6C001B; Sat, 4 Apr 2009 07:53:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DDFRApCibz8d; Sat, 4 Apr 2009 07:53:28 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2A8CFC0004; Sat, 4 Apr 2009 07:53:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06734A4DA38; Sat, 4 Apr 2009 07:53:10 +0200 (CEST) Date: Sat, 4 Apr 2009 07:53:10 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Message-ID: <20090404055310.GA26696@elstar.local> Mail-Followup-To: Wes Hardaker , "David B. Nelson" , "isms@ietf.org" References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 05:52:29 -0000 On Sat, Apr 04, 2009 at 01:00:36AM +0200, Wes Hardaker wrote: > >>>>> On Fri, 3 Apr 2009 18:41:12 -0400, "David B. Nelson" said: > > DBN> I have to assume that the notion of an Access Control Subsystem > DBN> abstraction implies that there can be multiple Access Control > DBN> Models, each of which could serve the as the "implementation"" of > DBN> the ACS. Are you saying that is *not* the case? > > Lets back up and forget that train. Because it is that complex (not > because it's not interesting or possible). > > The real perceived goal, as you stated earlier, is to have RADIUS > bootstrap VACM with data, right? That's what the current draft does (I > haven't read it)? And that's what the solution space will be? If so, > that's what we should write into the charter. Which current draft? I think it is crucial to decide what the WG wants to do so that it is possible to get a feeling of the obstacles on the path and how long it will take to move the obstacles away. There are likely significant difference between (1) populating a complete VACM configuration via RADIUS, (2) creating a new ACM (and fixing any existing SNMP shortcomings to make that work), or (3) patching data into the VACM security name to group name mapping (this is what I think the EUSM proposal written by Kaushik several years ago suggested). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From j.schoenwaelder@jacobs-university.de Fri Apr 3 23:28:50 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC3283A6921 for ; Fri, 3 Apr 2009 23:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbXx+1y9ddNr for ; Fri, 3 Apr 2009 23:28:50 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id B6AD73A67AA for ; Fri, 3 Apr 2009 23:27:55 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7A39C001B; Sat, 4 Apr 2009 08:28:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GWfwpOkVBdSw; Sat, 4 Apr 2009 08:28:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFB00C0004; Sat, 4 Apr 2009 08:28:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DB8A4A4DA8D; Sat, 4 Apr 2009 08:28:40 +0200 (CEST) Date: Sat, 4 Apr 2009 08:28:40 +0200 From: Juergen Schoenwaelder To: "David B. Nelson" Message-ID: <20090404062840.GB26696@elstar.local> Mail-Followup-To: "David B. Nelson" , "isms@ietf.org" References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 06:28:51 -0000 On Sat, Apr 04, 2009 at 12:41:12AM +0200, David B. Nelson wrote: > I have to assume that the notion of an Access Control Subsystem > abstraction implies that there can be multiple Access Control > Models, each of which could serve the as the "implementation"" of > the ACS. Are you saying that is *not* the case? Being able to support multiple ACMs was clearly the intention but I believe that this currently does not really work and if I am right, then we would have to fix this part of the SNMP specs (like we had to introduce a transport subsytem since the SNMP architecture did not really provide one). I believe the problem are the EoPs in RFC 3413, they simply state that the isAccessAllowed ASI is called and there is nothing spelling out how an ACM is selected (that is which isAccessAllowed ASI is actually called if there are multiple ACMs). Consequently, there are also no configuration datastore objects to control the ACM selection process. I personally believe this is a bug in the SNMP specifications. Whether it is worth fixing and who should be in charge of fixing it, I can't tell right now. Note that this "shortcoming" of the SNMP specifications also affects the SVACM proposal (which BTW includes some text on interaction with RADIUS in section 3 people might want to look at). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Sat Apr 4 02:58:49 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D793A686D for ; Sat, 4 Apr 2009 02:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-0.485, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuLpS6A5Qc9j for ; Sat, 4 Apr 2009 02:58:49 -0700 (PDT) Received: from QMTA01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by core3.amsl.com (Postfix) with ESMTP id E68E03A686E for ; Sat, 4 Apr 2009 02:58:39 -0700 (PDT) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA01.emeryville.ca.mail.comcast.net with comcast id bMy31b0021GXsucA1MzB3n; Sat, 04 Apr 2009 09:59:11 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id bMzi1b00G4H2mdz8TMzj6Q; Sat, 04 Apr 2009 09:59:44 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local> <20090404055310.GA26696@elstar.local> Date: Sat, 4 Apr 2009 05:59:52 -0400 Message-ID: <2398E68522364E91A075E03451B6299E@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090404055310.GA26696@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acm06bOUp6/0PlTvTXC9Ue+l5L1ZUgAIj0Ag Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 09:58:49 -0000 > Juergen Schoenwaelder writes... > (3) patching data into the VACM security name to group name mapping > (this is what I think the EUSM proposal written by Kaushik several > years ago suggested). I prefer this approach. From d.b.nelson@comcast.net Sat Apr 4 03:01:41 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775F23A67D8 for ; Sat, 4 Apr 2009 03:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.084 X-Spam-Level: X-Spam-Status: No, score=-1.084 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2grIBqyaHcwr for ; Sat, 4 Apr 2009 03:01:40 -0700 (PDT) Received: from QMTA14.emeryville.ca.mail.comcast.net (qmta14.emeryville.ca.mail.comcast.net [76.96.27.212]) by core3.amsl.com (Postfix) with ESMTP id B91953A67D2 for ; Sat, 4 Apr 2009 03:01:40 -0700 (PDT) Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA14.emeryville.ca.mail.comcast.net with comcast id bN2G1b00317UAYkAEN2ll1; Sat, 04 Apr 2009 10:02:45 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id bN2j1b00C4H2mdz8ZN2kje; Sat, 04 Apr 2009 10:02:45 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local> <20090404062840.GB26696@elstar.local> Date: Sat, 4 Apr 2009 06:02:53 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090404062840.GB26696@elstar.local> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acm07sb2XMvL3XzQSX+ZXpZG9lySQQAHW8mw Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Apr 2009 10:01:41 -0000 > Juergen Schoenwaelder writes... > Being able to support multiple ACMs was clearly the intention but I > believe that this currently does not really work and if I am right, > then we would have to fix this part of the SNMP specs (like we had to > introduce a transport subsytem since the SNMP architecture did not > really provide one). Perhaps in some *other* SNMP maintenance WG someday? I agreed that we should skirt around this issue, if possible. From ietfdbh@comcast.net Sun Apr 5 20:38:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C28A3A6AE8 for ; Sun, 5 Apr 2009 20:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpIGFDZ-1YzU for ; Sun, 5 Apr 2009 20:38:52 -0700 (PDT) Received: from QMTA12.emeryville.ca.mail.comcast.net (qmta12.emeryville.ca.mail.comcast.net [76.96.27.227]) by core3.amsl.com (Postfix) with ESMTP id C4D533A6ADD for ; Sun, 5 Apr 2009 20:38:49 -0700 (PDT) Received: from OMTA05.emeryville.ca.mail.comcast.net ([76.96.30.43]) by QMTA12.emeryville.ca.mail.comcast.net with comcast id c2iP1b0050vp7WLAC3fwbi; Mon, 06 Apr 2009 03:39:56 +0000 Received: from Harrington73653 ([63.146.75.9]) by OMTA05.emeryville.ca.mail.comcast.net with comcast id c3fh1b00Q0C1ymP8R3fkF0; Mon, 06 Apr 2009 03:39:53 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" , "'David B. Nelson'" References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local> <20090404062840.GB26696@elstar.local> Date: Sun, 5 Apr 2009 20:39:41 -0700 Message-ID: <005901c9b669$58b92600$508613ac@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20090404062840.GB26696@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acm07sb2qORVItzNQw+tOzoTRUAO/gBeIxEg Cc: isms@ietf.org Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 03:38:54 -0000 Hi, Just returning from a vacation. SNMPv3 was designed architecturally to support multiple coexistent ACMs, but we screwed up the EOPs and presumably the message format, and failed to define a selector mechanism. I believe this would be significant work to correct, as was the lack of a transport subsystem, and we should NOT take on this work at this time. I think SVACM might work as a simplified approach to VACM, rather than a new ACM, although I have not studied interoperability issues. The NMS:agent relations (1:M, M:1, M:M) need to be considered. I recommend that the RADIUS support be treated as a VACM extension, rather than a separate AC model. This will allow us to avoid the selector problem. Like DaveN, I believe we should focus on an extension that provides only a username-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. I think the main goal is to simplify the configuration requirements for SNMP authroization for employee adds/drops/changes and equipment adds/drops/changes. I think AAA has the ability to specify a time limit for access decisions, and such a timelimit should be used to garbage collect expired dynamic securityToGroup mappings. dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Juergen Schoenwaelder > Sent: Friday, April 03, 2009 11:29 PM > To: David B. Nelson > Cc: isms@ietf.org > Subject: Re: [Isms] potential charter text > > On Sat, Apr 04, 2009 at 12:41:12AM +0200, David B. Nelson wrote: > > > I have to assume that the notion of an Access Control Subsystem > > abstraction implies that there can be multiple Access Control > > Models, each of which could serve the as the "implementation"" of > > the ACS. Are you saying that is *not* the case? > > Being able to support multiple ACMs was clearly the intention but I > believe that this currently does not really work and if I am right, > then we would have to fix this part of the SNMP specs (like we had to > introduce a transport subsytem since the SNMP architecture did not > really provide one). > > I believe the problem are the EoPs in RFC 3413, they simply state that > the isAccessAllowed ASI is called and there is nothing spelling out > how an ACM is selected (that is which isAccessAllowed ASI is actually > called if there are multiple ACMs). Consequently, there are also no > configuration datastore objects to control the ACM selection process. > > I personally believe this is a bug in the SNMP specifications. Whether > it is worth fixing and who should be in charge of fixing it, I can't > tell right now. > > Note that this "shortcoming" of the SNMP specifications also affects > the SVACM proposal (which BTW includes some text on interaction with > RADIUS in section 3 people might want to look at). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From d.b.nelson@comcast.net Mon Apr 6 04:53:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2999528C157 for ; Mon, 6 Apr 2009 04:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-0.532, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iw6-6QoatIrO for ; Mon, 6 Apr 2009 04:53:04 -0700 (PDT) Received: from QMTA15.emeryville.ca.mail.comcast.net (qmta15.emeryville.ca.mail.comcast.net [76.96.27.228]) by core3.amsl.com (Postfix) with ESMTP id BDF683A69E8 for ; Mon, 6 Apr 2009 04:53:04 -0700 (PDT) Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA15.emeryville.ca.mail.comcast.net with comcast id cAxu1b0070b6N64AFBuBRb; Mon, 06 Apr 2009 11:54:11 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id cBu91b00S4H2mdz8PBuARt; Mon, 06 Apr 2009 11:54:11 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local><20090404062840.GB26696@elstar.local> <005901c9b669$58b92600$508613ac@china.huawei.com> Date: Mon, 6 Apr 2009 07:54:24 -0400 Message-ID: <1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm07sb2qORVItzNQw+tOzoTRUAO/gBeIxEgABGlx0A= In-Reply-To: <005901c9b669$58b92600$508613ac@china.huawei.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 11:53:10 -0000 David Harrington writes... > I recommend that the RADIUS support be treated as a VACM extension, > rather than a separate AC model. This will allow us to avoid the > selector problem. We seem to be developing some consensus on that. What do you think of the proposed charter text I had sent out last week (reproduced below)? In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be a new method of outsourced authorization of an authenticated principal, for use within the View-based Access Control Model (VACM). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions based on authorization information for an authenticated principal obtained via RADIUS. - Specify the DTLS transport for SNMP. From j.schoenwaelder@jacobs-university.de Mon Apr 6 05:04:08 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 786F03A6B65 for ; Mon, 6 Apr 2009 05:04:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRB5JQK4a559 for ; Mon, 6 Apr 2009 05:04:07 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0A2FF3A6A77 for ; Mon, 6 Apr 2009 05:04:07 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5EE69C003B; Mon, 6 Apr 2009 14:05:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LiWJuVCBEDlM; Mon, 6 Apr 2009 14:05:11 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11713C000A; Mon, 6 Apr 2009 14:05:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 06602A5F446; Mon, 6 Apr 2009 14:04:53 +0200 (CEST) Date: Mon, 6 Apr 2009 14:04:53 +0200 From: Juergen Schoenwaelder To: Dave Nelson Message-ID: <20090406120453.GA20706@elstar.local> Mail-Followup-To: Dave Nelson , "isms@ietf.org" References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> <20090404062840.GB26696@elstar.local> <005901c9b669$58b92600$508613ac@china.huawei.com> <1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:04:08 -0000 On Mon, Apr 06, 2009 at 01:54:24PM +0200, Dave Nelson wrote: > David Harrington writes... > > > I recommend that the RADIUS support be treated as a VACM extension, > > rather than a separate AC model. This will allow us to avoid the > > selector problem. > > We seem to be developing some consensus on that. What do you think of the > proposed charter text I had sent out last week (reproduced below)? > > In order to leverage a centralized RADIUS service to its > full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information > received from RADIUS as well. The result will be a new > method of outsourced authorization of an authenticated > principal, for use within the View-based Access Control > Model (VACM). I find the usage of "outsourcing" confusing, at least for people having knowledge how this term has been used in the COPS context. It seems people really want to provision authorization policies. And in general, I love charter text that spell out what a WG is not going to do. If there is agreement that we the goal is not to provision access policies (view tree families etc.), then this should be spelled out. The tighter the charter text, the more useful it is going to be (especially in the absence of an ID to start from - hint hint). > The working group will cover the following work items: > > - Specify a mechanism to support centralization of > SNMPv3 Access Control decisions based on authorization > information for an authenticated principal obtained > via RADIUS. This can be read to fully populate ACM information (which not VACM?) and I believe this is not what this WG wants to do. If the goal is to get the mapping to VACM group names (policies) from RADIUS, then we should say so. It would also be good to know if any additional RADIUS attributes will be needed and if so, who is going to standardize them, that is what the interplay of ISMS and RADEXT would be in this case. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Apr 6 05:22:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9199E3A6C4C for ; Mon, 6 Apr 2009 05:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OjYCa+Lriwf for ; Mon, 6 Apr 2009 05:22:04 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 970B13A6C12 for ; Mon, 6 Apr 2009 05:22:04 -0700 (PDT) Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id cBvo1b0090QkzPwA8CPBBb; Mon, 06 Apr 2009 12:23:11 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA02.emeryville.ca.mail.comcast.net with comcast id cCP91b00C4H2mdz8NCPAuK; Mon, 06 Apr 2009 12:23:10 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> <20090404062840.GB26696@elstar.local> <005901c9b669$58b92600$508613ac@china.huawei.com> <1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603> <20090406120453.GA20706@elstar.local> Date: Mon, 6 Apr 2009 08:23:24 -0400 Message-ID: <3E29FC2011924E3F8046A2F9EAE312EE@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm2r/MM+xc932DaTMamIELmB34vzAAAWC2w In-Reply-To: <20090406120453.GA20706@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:22:05 -0000 Juergen Schoenwaelder writes... > > In order to leverage a centralized RADIUS service to its > > full extent, the access control decision in the Access Control > > Subsystem needs to be based on authorization information > > received from RADIUS as well. The result will be a new > > method of outsourced authorization of an authenticated > > principal, for use within the View-based Access Control > > Model (VACM). > > I find the usage of "outsourcing" confusing, at least for people > having knowledge how this term has been used in the COPS context. OK. I tend to agree. That was wording that Wes introduced. I think we can be more specific. > If there is agreement that we the goal is not to provision access > policies (view tree families etc.), then this should be spelled out. OK. > The tighter the charter text, the more useful it is going to be > (especially in the absence of an ID to start from - hint hint). We could turn the charter text into the outline of ID. Just kidding. :-) > > The working group will cover the following work items: > > > > - Specify a mechanism to support centralization of > > SNMPv3 Access Control decisions based on authorization > > information for an authenticated principal obtained > > via RADIUS. > > This can be read to fully populate ACM information (which not > VACM?) and I believe this is not what this WG wants to do. Right. > If the goal is to get the mapping to VACM group names (policies) > from RADIUS, then we should say so. Perhaps I can purloin some text from Dave H's last message. > It would also be good to know if any additional RADIUS > attributes will be needed ... Hmmm. I think that goes a bit beyond what one would normally find in a charter, into the realm of solution details. > ... and if so, who is going to standardize them, that is what > the interplay of ISMS and RADEXT would be in this case. However, I believe that all the RADIUS attributes that we will need are already defined in the "radman" draft, or defined in an existing RFC and discussed in the "radman" draft. I think we're all set in that regard. I send some further modified proposed charter text in a separate message. From d.b.nelson@comcast.net Mon Apr 6 05:36:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FC673A6C55 for ; Mon, 6 Apr 2009 05:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGWrW+mZ2jCM for ; Mon, 6 Apr 2009 05:36:18 -0700 (PDT) Received: from QMTA09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by core3.amsl.com (Postfix) with ESMTP id 93F6C3A6C0A for ; Mon, 6 Apr 2009 05:36:18 -0700 (PDT) Received: from OMTA14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by QMTA09.emeryville.ca.mail.comcast.net with comcast id cBWP1b0061HpZEsA9CdREk; Mon, 06 Apr 2009 12:37:25 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA14.emeryville.ca.mail.comcast.net with comcast id cCdP1b0074H2mdz8aCdQ0y; Mon, 06 Apr 2009 12:37:25 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2> <20090403222910.GB26360@elstar.local> <20090404062840.GB26696@elstar.local> <005901c9b669$58b92600$508613ac@china.huawei.com> <1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603> <20090406120453.GA20706@elstar.local> Date: Mon, 6 Apr 2009 08:37:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm2r/MM+xc932DaTMamIELmB34vzAAAo5IQ In-Reply-To: <20090406120453.GA20706@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:36:19 -0000 Further refined proposed charter text (addresses comments from Dave Harrington and Juergen Schoenwaelder): ..... In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. ..... The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. Note, this is a modification of the text sent out by Wes hardaker last week. From d.b.nelson@comcast.net Mon Apr 6 05:46:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB563A6902 for ; Mon, 6 Apr 2009 05:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.973 X-Spam-Level: X-Spam-Status: No, score=-0.973 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DN-E9HHZfyh for ; Mon, 6 Apr 2009 05:46:40 -0700 (PDT) Received: from QMTA13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by core3.amsl.com (Postfix) with ESMTP id 05AD73A6782 for ; Mon, 6 Apr 2009 05:46:39 -0700 (PDT) Received: from OMTA10.emeryville.ca.mail.comcast.net ([76.96.30.28]) by QMTA13.emeryville.ca.mail.comcast.net with comcast id cCi21b0050cQ2SLADCnmP8; Mon, 06 Apr 2009 12:47:46 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA10.emeryville.ca.mail.comcast.net with comcast id cCnk1b00K4H2mdz8WCnl9F; Mon, 06 Apr 2009 12:47:46 +0000 From: "Dave Nelson" To: References: <5EDFC935D6D14C3493F361F8C7ABC476@xpsuperdvd2><20090403222910.GB26360@elstar.local><20090404062840.GB26696@elstar.local><005901c9b669$58b92600$508613ac@china.huawei.com><1BA1CA3CF4CD4780BD310A38D42CD392@NEWTON603><20090406120453.GA20706@elstar.local> <3E29FC2011924E3F8046A2F9EAE312EE@NEWTON603> Date: Mon, 6 Apr 2009 08:47:59 -0400 Message-ID: <71B9BDA72A6A4070AC7DA0E0D2D5F8BA@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm2r/MM+xc932DaTMamIELmB34vzAAAWC2wAAD/KwA= In-Reply-To: <3E29FC2011924E3F8046A2F9EAE312EE@NEWTON603> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 12:46:40 -0000 > However, I believe that all the RADIUS attributes that we will need are > already defined in the "radman" draft, or defined in an existing RFC and > discussed in the "radman" draft. I think we're all set in that regard. We could turn this into additional proposed charter text, to formally address any RADIUS dependencies. For example: It is expected that all the RADIUS Attributes needed for this work have already been defined in existing RFCs or in draft-ietf-radext-management-authorization-06.txt. From kaushik@cisco.com Mon Apr 6 07:29:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C51B3A6902 for ; Mon, 6 Apr 2009 07:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp0bLzIR+DaO for ; Mon, 6 Apr 2009 07:29:35 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A6EB53A6CAB for ; Mon, 6 Apr 2009 07:27:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.39,330,1235952000"; d="scan'208";a="151399655" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 06 Apr 2009 14:28:32 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n36ESWbU014294; Mon, 6 Apr 2009 07:28:32 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n36ESW3C015568; Mon, 6 Apr 2009 14:28:32 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Apr 2009 07:28:31 -0700 Received: from 10.21.119.57 ([10.21.119.57]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 6 Apr 2009 14:28:31 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Mon, 06 Apr 2009 07:28:29 -0700 From: kaushik To: Dave Nelson , Message-ID: Thread-Topic: [Isms] potential charter text Thread-Index: Acm06bOUp6/0PlTvTXC9Ue+l5L1ZUgAIj0AgAG4A7I8= In-Reply-To: <2398E68522364E91A075E03451B6299E@NEWTON603> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 06 Apr 2009 14:28:32.0129 (UTC) FILETIME=[F6255710:01C9B6C3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=496; t=1239028112; x=1239892112; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20[Isms]=20potential=20charter=20text |Sender:=20; bh=0D61j5eBitDdUUN9axhIp3YzTwEehzruXIJxsiyR6+k=; b=I1LYpHCBhATW0/1ClawUgEI/GRmKPNyFZD6iGMp1DIiI89HIUa0a+VH9xd H8UyXGa4eaal/sZO5PXgV10346Ncv7DLtTfXTXZ7NLpgQ4n/MfN+rrbYljUf 7ARf+MkwQ2; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Isms] potential charter text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Apr 2009 14:29:36 -0000 I prefer this approach as well. On 4/4/09 2:59 AM, "Dave Nelson" wrote: >> Juergen Schoenwaelder writes... > >> (3) patching data into the VACM security name to group name mapping >> (this is what I think the EUSM proposal written by Kaushik several >> years ago suggested). > > I prefer this approach. > > > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms From Pasi.Eronen@nokia.com Tue Apr 7 00:55:33 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16E313A6892 for ; Tue, 7 Apr 2009 00:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQMg7kYxhaDA for ; Tue, 7 Apr 2009 00:55:32 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id E8A133A6816 for ; Tue, 7 Apr 2009 00:55:31 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n377uT0Y017239 for ; Tue, 7 Apr 2009 10:56:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 10:56:25 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Apr 2009 10:56:24 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Tue, 7 Apr 2009 09:56:22 +0200 From: To: Date: Tue, 7 Apr 2009 09:56:27 +0200 Thread-Topic: AD review comments for draft-ietf-isms-radius-usage-05 Thread-Index: Acm3VlsPGOPvUjq6SuiGhqG4ZeescA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F22151E9@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Apr 2009 07:56:24.0951 (UTC) FILETIME=[5944A070:01C9B756] X-Nokia-AV: Clean Subject: [Isms] AD review comments for draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 07:55:33 -0000 I've now done my AD review for draft-ietf-isms-radius-usage-05. All my comments are very minor, so I've requested the secretariat to start IETF last call (these can be considered as the first last call comments): - Section 2.3 equates "secure transport" with "authPriv". While SSHTM requires encryption, can't some future secure transport model provide integrity/authentication only? Perhaps this could be rephrased as "...SNMP over a secure transport which provides both integrity and encryption (i.e. authPriv)". - I'd suggest removing NAS-IP-Address from the table in Section 3 (otherwise, we probably should add NAS-IPv6-Address and NAS-Identifier, too). - The table in Section 3 lists Management-Policy-Id, but this attribute is not mentioned anywhere else in the document. Perhaps the document should just say something like "[I-D.ietf-radext-management- authorization] defines Management-Policy-Id and Management-Privilege-Level attributes. How these are mapped into e.g. an SNMP Access Control Model is beyond the scope of this document" ? - The table shows the User-Password attribute, but it's possible that some SNMP transport model could support other authentication mechanisms with RADIUS (like EAP or Digest). Perhaps Section 3 should say something like "SSH integration with RADIUS traditionally uses passwords (with the User-Password attribute), but other secure=20 transports could use other authentication mechanisms (such as EAP or=20 HTTP Digest), and would include appropriate authentication attributes instead of User-Password" ? Best regards, Pasi= From d.b.nelson@comcast.net Tue Apr 7 05:43:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AAD3A6886 for ; Tue, 7 Apr 2009 05:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.712, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWOCJ1JXpHJm for ; Tue, 7 Apr 2009 05:43:37 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 891653A687F for ; Tue, 7 Apr 2009 05:43:37 -0700 (PDT) Received: from OMTA03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA05.westchester.pa.mail.comcast.net with comcast id ccUy1b00U0bG4ec55ckk0j; Tue, 07 Apr 2009 12:44:44 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA03.westchester.pa.mail.comcast.net with comcast id cckG1b0194H2mdz3PckHxC; Tue, 07 Apr 2009 12:44:17 +0000 From: "Dave Nelson" To: References: <808FD6E27AD4884E94820BC333B2DB7727F22151E9@NOK-EUMSG-01.mgdnok.nokia.com> Date: Tue, 7 Apr 2009 08:44:44 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F22151E9@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: Acm3VlsPGOPvUjq6SuiGhqG4ZeescAAJft0g Subject: Re: [Isms] AD review comments for draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 12:43:38 -0000 Pasi Eronen writes... > - Section 2.3 equates "secure transport" with "authPriv". > While SSHTM requires encryption, can't some future secure > transport model provide integrity/authentication only? Possibly... > Perhaps this could be rephrased as "...SNMP over a secure > transport which provides both integrity and encryption > (i.e. authPriv)". OK. That makes sense. > - I'd suggest removing NAS-IP-Address from the table in > Section 3 (otherwise, we probably should add NAS-IPv6-Address > and NAS-Identifier, too). Hmmm... I'm trying to remember why that attribute was included. Either suggestion may be OK, but let's think for a while as to whether there is a use case for this information. > - The table in Section 3 lists Management-Policy-Id, but this > attribute is not mentioned anywhere else in the document. Perhaps > the document should just say something like "[I-D.ietf-radext- > management-authorization] defines Management-Policy-Id and > Management-Privilege-Level attributes. How these are mapped > into e.g. an SNMP Access Control Model is beyond the scope of > this document" ? We purged any [veiled] references to access control authorization from this draft in the very last revision, and this item was missed. We should probably remove the attribute from the table. > - The table shows the User-Password attribute, but it's possible > that some SNMP transport model could support other authentication > mechanisms with RADIUS (like EAP or Digest). Ahem. I realize there has been a recent change of Security AD staff, but when this work was beginning we were *firmly* informed that the applicability statement for EAP prohibited it from being used for anything except network access authentication, and certainly not for application authentication, e.g. for SNMP. There was a bit of a fuss, but it soon subsided. Are you now telling us this would be OK? If so, then we could consider adding it as possibility. I suppose some *could* use Digest Authentication... > Perhaps Section 3 should say something like "SSH integration with > RADIUS traditionally uses passwords (with the User-Password > attribute), but other secure transports could use other authentication > mechanisms (such as EAP or HTTP Digest), and would include appropriate > authentication attributes instead of User-Password" ? Yes, that would make sense, assuming we are really allowed to use EAP. From wwwrun@core3.amsl.com Tue Apr 7 07:59:32 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 486C43A6C05; Tue, 7 Apr 2009 07:59:31 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090407145932.486C43A6C05@core3.amsl.com> Date: Tue, 7 Apr 2009 07:59:32 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Apr 2009 14:59:32 -0000 The IESG has received a request from the Integrated Security Model for SNMP WG (isms) to consider the following document: - 'Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-04-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16427&rfc_flag=0 From j.schoenwaelder@jacobs-university.de Thu Apr 9 06:44:33 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83B683A6B86 for ; Thu, 9 Apr 2009 06:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBO30dZQK-kh for ; Thu, 9 Apr 2009 06:44:32 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8F2683A6AC8 for ; Thu, 9 Apr 2009 06:44:32 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E464BC0030 for ; Thu, 9 Apr 2009 15:45:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id NVfc1aocIWfu; Thu, 9 Apr 2009 15:45:39 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A2D5C0043; Thu, 9 Apr 2009 15:45:39 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1C37FA6E560; Thu, 9 Apr 2009 15:45:22 +0200 (CEST) Date: Thu, 9 Apr 2009 15:45:21 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090409134521.GB26085@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] mib module names and mib copyright statements X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2009 13:44:33 -0000 Hi, it was suggested that the MIB module name SSHTM-MIB in the secshell draft should be prefixed with "SNMP-" since all SNMP related MIB modules have this "SNMP-" prefix. Given the way existing SNMP MIB module names were constructed, it seems the naming scheme most consistent with the SNMPv3 standards would be: - SNMP-SSH-TM-MIB (instead of SSHTM-MIB) - SNMP-TRANSPORT-SM-MIB (instead of SNMP-TSM-MIB) We also have to include the new verbose copyright boilerplate text in all MIB modules; this affects two of our documents. I don't think any of this is controversial. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Mon Apr 13 10:50:10 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8687F3A6A55 for ; Mon, 13 Apr 2009 10:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_20=-0.74, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eniEcZkPjnl for ; Mon, 13 Apr 2009 10:50:09 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id BAFC53A69E1 for ; Mon, 13 Apr 2009 10:50:09 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C65E639A0FC for ; Mon, 13 Apr 2009 10:51:20 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090409134521.GB26085@elstar.local> Date: Mon, 13 Apr 2009 10:51:20 -0700 In-Reply-To: <20090409134521.GB26085@elstar.local> (Juergen Schoenwaelder's message of "Thu, 9 Apr 2009 15:45:21 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsmib module names and mib copyright statements X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 17:50:10 -0000 >>>>> On Thu, 9 Apr 2009 15:45:21 +0200, Juergen Schoenwaelder said: JS> - SNMP-SSH-TM-MIB (instead of SSHTM-MIB) JS> - SNMP-TRANSPORT-SM-MIB (instead of SNMP-TSM-MIB) ... JS> I don't think any of this is controversial. Agreed it's a good idea, just to add a +1 -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From wjhns1@hardakers.net Mon Apr 13 11:02:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA89D3A6971 for ; Mon, 13 Apr 2009 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CD3mMPULmcsp for ; Mon, 13 Apr 2009 11:02:00 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id D88393A6968 for ; Mon, 13 Apr 2009 11:01:59 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 0751439A0FC for ; Mon, 13 Apr 2009 11:03:11 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Mon, 13 Apr 2009 11:03:10 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] reconstructed new charter text -- incorporates recent comments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 18:02:00 -0000 After coming back into email-range again and after re-reading the list from the last week I've pieced together the results of the recent discussion into a new set of charter text that better describes what I think everyone agrees to about the RADIUS work. Specifically, the text I wrote about it has been replaced by the latest of the text from David Nelson: ---- Begin proposed charter text ---- Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * Juergen Schoenwaelder * David Harrington Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define a DTLS-based transport that can offer support for environments that prefer certificate authentication and/or datagram-based transmissions. Certificate based authentication is desirable for many environments with a centralized authentication service. Datagram based transports may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A DTLS-based transport would offer a solution that addresses both of these situations. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop a DTLS-based Transport Subsystem. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify the DTLS transport for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the DTLS transport for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2009 Submit documentation on the DTLS transport for SNMP to IESG Jan 2009 Submit documentation for the centralized access control to IESG -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From ietfdbh@comcast.net Mon Apr 13 13:23:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB3F3A6870 for ; Mon, 13 Apr 2009 13:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrtXCKGHrU+h for ; Mon, 13 Apr 2009 13:23:38 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id ECF263A6CE1 for ; Mon, 13 Apr 2009 13:23:37 -0700 (PDT) Received: from OMTA11.westchester.pa.mail.comcast.net ([76.96.62.36]) by QMTA02.westchester.pa.mail.comcast.net with comcast id eyoE1b0040mv7h0528QYkP; Mon, 13 Apr 2009 20:24:32 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA11.westchester.pa.mail.comcast.net with comcast id f8Qo1b0180UQ6dC3X8Qodt; Mon, 13 Apr 2009 20:24:49 +0000 From: "David Harrington" To: "'Wes Hardaker'" , References: Date: Mon, 13 Apr 2009 16:24:47 -0400 Message-ID: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm8Yh3TlhRvPUWsTw6pPDTPaTjojQAE4UhA In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:23:39 -0000 Hu, The milestones are incorrect. Jan 2009 should either be Jan 2010, or maybe Dec 2009. The proposed charter proposes a new DTLS-based subsystem; this should be DTLS transport model. Should we also plan on a TLS-based transport model? dbh > -----Original Message----- > From: isms-bounces@ietf.org [mailto:isms-bounces@ietf.org] On > Behalf Of Wes Hardaker > Sent: Monday, April 13, 2009 2:03 PM > To: isms@ietf.org > Subject: [Isms] reconstructed new charter text -- > incorporates recentcomments > > > After coming back into email-range again and after re-reading the list > from the last week I've pieced together the results of the recent > discussion into a new set of charter text that better describes what I > think everyone agrees to about the RADIUS work. > Specifically, the text > I wrote about it has been replaced by the latest of the text > from David > Nelson: > > > ---- Begin proposed charter text ---- > > > Integrated Security Model for SNMP (isms) > > Last Modified: XXXX > > Additional information is available at tools.ietf.org/wg/isms > > Chair(s): > * Juergen Schoenwaelder > * David Harrington > > Security Area Director(s): > * Tim Polk > * Pasi Eronen > > Security Area Advisor: > * Pasi Eronen > > Mailing Lists: > > General Discussion: isms@ietf.org > To Subscribe: isms-request@ietf.org > In Body: in body: (un)subscribe > Archive: > http://www.ietf.org/mail-archive/working-groups/isms/current/m aillist.html > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be > tackled by the working group involved only these pieces. Additional > work on other transport models and other security extensions were to > wait until the initial transport architecture and defining documents > were completed. > > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. > However, > it still remains impossible to centrally authorize a given SNMP > transaction as on-device pre-existing authorization configuration is > still required. In order to leverage a centralized RADIUS service to > its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to the View-based > Access Control Model (VACM), to obtain authorization > information for an > authenticated principal from RADIUS. The authorization > information will > be limited to mapping the authenticated principal to existing access > control polices, defining session timeouts, and similar session > parameters. This mechanism will not provision the detailed access > control rules. > > Additionally, new work will be undertaken to define a DTLS-based > transport that can offer support for environments that prefer > certificate authentication and/or datagram-based transmissions. > Certificate based authentication is desirable for many > environments with > a centralized authentication service. Datagram based > transports may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A > DTLS-based transport > would offer a solution that addresses both of these situations. > > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop a > DTLS-based Transport Subsystem. > > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). > > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide > a binding > between a user and preconfigured VACM policies via > dynamic additions > to the securityToGroupname table. Additionally, specify a > time limit > for access decisions, and such a time limit should be used to > garbage collect expired dynamic securityToGroup mappings. > > - Specify the DTLS transport for SNMP. > > Goals and Milestones: > Jul 2009 Publish initial documentation on the DTLS > transport for SNMP > Jul 2009 Publish initial documentation for the > centralized access control > Jan 2009 Submit documentation on the DTLS transport > for SNMP to IESG > Jan 2009 Submit documentation for the centralized > access control to IESG > > > -- > Wes Hardaker > SPARTA National Security Sector > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > From wjhns1@hardakers.net Mon Apr 13 13:34:04 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C45BC3A6A06 for ; Mon, 13 Apr 2009 13:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.941 X-Spam-Level: X-Spam-Status: No, score=-1.941 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UiMEqujB5QAl for ; Mon, 13 Apr 2009 13:34:03 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id C2D3C3A69F3 for ; Mon, 13 Apr 2009 13:34:03 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id ECA2839A0F1; Mon, 13 Apr 2009 13:35:14 -0700 (PDT) From: Wes Hardaker To: "David Harrington" Organization: Sparta References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> Date: Mon, 13 Apr 2009 13:35:14 -0700 In-Reply-To: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> (David Harrington's message of "Mon, 13 Apr 2009 16:24:47 -0400") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: isms@ietf.org Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:34:04 -0000 >>>>> On Mon, 13 Apr 2009 16:24:47 -0400, "David Harrington" said: DH> The milestones are incorrect. Jan 2009 should either be Jan 2010, or DH> maybe Dec 2009. Whoops. Good catch. DH> The proposed charter proposes a new DTLS-based subsystem; this should DH> be DTLS transport model. Also a good catch. DH> Should we also plan on a TLS-based transport model? That is subject to the WG belief that such a transport would be beneficial. Personally, I don't see a problem with it and I think it would be easiest to roll such support into the current DTLS draft rather than write a second document (in part because the MIBs are likely to affect both equally). ---- Begin proposed charter text (take 3) ---- Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * Juergen Schoenwaelder * David Harrington Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define a DTLS-based transport that can offer support for environments that prefer certificate authentication and/or datagram-based transmissions. Certificate based authentication is desirable for many environments with a centralized authentication service. Datagram based transports may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A DTLS-based transport would offer a solution that addresses both of these situations. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop a DTLS-based Transport Model. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify the DTLS transport for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the DTLS transport for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the DTLS transport for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From j.schoenwaelder@jacobs-university.de Mon Apr 13 13:49:21 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC2943A6A86 for ; Mon, 13 Apr 2009 13:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkRvtrJgO7kH for ; Mon, 13 Apr 2009 13:49:21 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C8C083A67D8 for ; Mon, 13 Apr 2009 13:49:20 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A8F6C0032; Mon, 13 Apr 2009 22:50:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id iktV2prJKf3t; Mon, 13 Apr 2009 22:50:30 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D0256C001D; Mon, 13 Apr 2009 22:50:29 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 277D5A75D76; Mon, 13 Apr 2009 22:50:12 +0200 (CEST) Date: Mon, 13 Apr 2009 22:50:11 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090413205011.GA2358@elstar.local> Mail-Followup-To: David Harrington , 'Wes Hardaker' , "isms@ietf.org" References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 20:49:21 -0000 On Mon, Apr 13, 2009 at 10:24:47PM +0200, David Harrington wrote: > Should we also plan on a TLS-based transport model? Speaking as contributor... There once was a TLS proposal: http://tools.ietf.org/html/draft-marinov-isms-tlstm-00 This draft has not been updated for two years and I am sure it is not in sync with Wes' DTLS document. But speaking as a contributor, I prefer to get both TLS and DTLS done at the same time. Whether this should be a single document or two separate documents, I do not know yet since I do not yet fully understand how much is common here. Having DTLS and TLS in different documents has the advantage that the TMs can move on the standards-track independently at different speeds. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Mon Apr 13 14:44:20 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0BD13A680C for ; Mon, 13 Apr 2009 14:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.942 X-Spam-Level: X-Spam-Status: No, score=-1.942 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWKoOrdCMvpt for ; Mon, 13 Apr 2009 14:44:20 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 32C243A6800 for ; Mon, 13 Apr 2009 14:44:20 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 44E7239A0F1; Mon, 13 Apr 2009 14:45:31 -0700 (PDT) From: Wes Hardaker To: David Harrington Organization: Sparta References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> Date: Mon, 13 Apr 2009 14:45:31 -0700 In-Reply-To: <20090413205011.GA2358@elstar.local> (Juergen Schoenwaelder's message of "Mon, 13 Apr 2009 22:50:11 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2009 21:44:21 -0000 >>>>> On Mon, 13 Apr 2009 22:50:11 +0200, Juergen Schoenwaelder said: JS> Having DTLS and TLS in different documents has the advantage that JS> the TMs can move on the standards-track independently at different JS> speeds. I suspect that there will be some common dependencies too, though, as I mentioned in my other post. EG, the current DTLS document defines X.509 to securityName mapping infrastructure that would be needed by both solutions. The current DTLS document already has two domains for it: DTLS over UDP and DTLS over SCTP (which itself is subject to debate but I don't think necessarily impacts the charter discussion). The bigger question is whether we should be defining a TLS based transport. DTLS has the advantage of being UDP (or SCTP) based and was the primary reason I wanted it available for use since it performs better (IMHO) in badly behaving networks. However, others have wanted it for it's X.509 support (in fact, this aspect was discussed in Dublin). If people feel that TLS would be desired because it's TCP based support might be important for certain environments, then defining it now certainly seems wise. Feature wise, it doesn't bring a huge amount to the table beyond the existing features provided by SSH and DTLS. It combines a few of them, of course, and brings both TCP and X.509 support together. I'm happy either way. As I said, I don't think it's a huge amount of work to add it to the existing document. Having just described DTLS/SCTP within the document I'm quite familiar with the level of effort to add yet another TLS-based transport to the mix). -- Wes Hardaker SPARTA National Security Sector Cobham Analytic Solutions From ietfdbh@comcast.net Mon Apr 13 17:36:00 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B4413A6AD1 for ; Mon, 13 Apr 2009 17:36:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtrsklkefDYS for ; Mon, 13 Apr 2009 17:35:59 -0700 (PDT) Received: from QMTA02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by core3.amsl.com (Postfix) with ESMTP id 6A8E13A68F3 for ; Mon, 13 Apr 2009 17:35:45 -0700 (PDT) Received: from OMTA06.westchester.pa.mail.comcast.net ([76.96.62.51]) by QMTA02.westchester.pa.mail.comcast.net with comcast id f90H1b00716LCl052Ccfzk; Tue, 14 Apr 2009 00:36:39 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA06.westchester.pa.mail.comcast.net with comcast id fCcw1b00t0UQ6dC3SCcxx9; Tue, 14 Apr 2009 00:36:57 +0000 From: "David Harrington" To: "'Wes Hardaker'" References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com><20090413205011.GA2358@elstar.local> Date: Mon, 13 Apr 2009 20:36:55 -0400 Message-ID: <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm8gSx9Kzw0OfVfQemlIURsVnztrQAFfovw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 00:36:00 -0000 Hi, In syslog/dtls, Pasi requested that we simply point to the security features of syslog/tls because it is important to keep them consistent. I suspect the security aspects of snmp/tls and snmp/dtls would be mostly the same, especially the recommended configuration and mandatory support for certificate processing in the absence of a CA, etc. Security consideratons might differ slightly because tls and dtls have different approaches to reliability I think, but am not sure, that adding tls to the dtls document would be the simplest approach, possibly by defining the common certificate processing and then defining three transport models that use the general processing. I suspect there will be quite a few devices that have web servers in them, and would benefit from https for security. I think it also a good thing to have relatively consistent security configuration for syslog, netconf, and snmp interfaces. IANA is considering using snmps to name the snmp/sshtm interface. For consistency with https, do we want to request that they save snmps for an snmp/tls interface, and use something like snmpssh to name the interface? Upon approval of this document, IANA will make the following assignments in the registered port numbers registry located at http://www.iana.org/assignments/port-numbers Keyword Decimal Description References ------- ------- ----------- ---------- snmps tbd(x161)/tcp SNMP over SSH Transport Model [RFC-isms-secshell-15] snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model [RFC-isms-secshell-15] dbh > -----Original Message----- > From: Wes Hardaker [mailto:wjhns1@hardakers.net] > Sent: Monday, April 13, 2009 5:46 PM > To: David Harrington > Cc: 'Wes Hardaker'; isms@ietf.org > Subject: Re: reconstructed new charter text -- incorporates > recentcomments > > >>>>> On Mon, 13 Apr 2009 22:50:11 +0200, Juergen > Schoenwaelder said: > > JS> Having DTLS and TLS in different documents has the advantage that > JS> the TMs can move on the standards-track independently at different > JS> speeds. > > I suspect that there will be some common dependencies too, > though, as I > mentioned in my other post. EG, the current DTLS document > defines X.509 > to securityName mapping infrastructure that would be needed by both > solutions. > > The current DTLS document already has two domains for it: > DTLS over UDP > and DTLS over SCTP (which itself is subject to debate but I > don't think > necessarily impacts the charter discussion). > > The bigger question is whether we should be defining a TLS based > transport. DTLS has the advantage of being UDP (or SCTP) > based and was > the primary reason I wanted it available for use since it performs > better (IMHO) in badly behaving networks. However, others have wanted > it for it's X.509 support (in fact, this aspect was discussed in > Dublin). If people feel that TLS would be desired because it's TCP > based support might be important for certain environments, > then defining > it now certainly seems wise. Feature wise, it doesn't bring a huge > amount to the table beyond the existing features provided by SSH and > DTLS. It combines a few of them, of course, and brings both TCP and > X.509 support together. I'm happy either way. As I said, I > don't think > it's a huge amount of work to add it to the existing document. Having > just described DTLS/SCTP within the document I'm quite > familiar with the > level of effort to add yet another TLS-based transport to the mix). > > -- > Wes Hardaker > SPARTA National Security Sector > Cobham Analytic Solutions > From jhutz@cmu.edu Mon Apr 13 20:27:30 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B66183A68DF for ; Mon, 13 Apr 2009 20:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4x3ZnCS6Kly for ; Mon, 13 Apr 2009 20:27:29 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id A3FAF3A685D for ; Mon, 13 Apr 2009 20:27:29 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3E3SS4C026680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Apr 2009 23:28:29 -0400 (EDT) Date: Mon, 13 Apr 2009 23:28:28 -0400 From: Jeffrey Hutzelman To: David Harrington , "'Wes Hardaker'" Message-ID: <4D58BFECA4933CE3B13F6768@atlantis.pc.cs.cmu.edu> In-Reply-To: <200904140037.n3E0bHwm002760@mx02.srv.cs.cmu.edu> References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> <200904140037.n3E0bHwm002760@mx02.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] reconstructed new charter text -- incorporates recentcomments X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 03:27:30 -0000 --On Monday, April 13, 2009 08:36:55 PM -0400 David Harrington wrote: > I suspect there will be quite a few devices that have web servers in > them, and would benefit from https for security. I think it also a > good thing to have relatively consistent security configuration for > syslog, netconf, and snmp interfaces. Doesn't netconf use SSH? > IANA is considering using snmps to name the snmp/sshtm interface. For > consistency with https, do we want to request that they save snmps for > an snmp/tls interface, and use something like snmpssh to name the > interface? > > > Upon approval of this document, IANA will make the following > assignments in the registered port numbers registry located at > http://www.iana.org/assignments/port-numbers > > Keyword Decimal Description References > ------- ------- ----------- ---------- > snmps tbd(x161)/tcp SNMP over SSH Transport Model > [RFC-isms-secshell-15] > snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model > [RFC-isms-secshell-15] > IANA doesn't normally make up these names; we're supposed to have requested specific names. In fact, -secshell section 10 does mention the names "SSHTM" and "SSHTM-TRAP", but only parenthetically; thus it may have been unclear to IANA what we meant. The appropriate thing to do here is to respond and point out the names already mentioned in the document. This is part of why IANA reviews documents at last call -- to insure that IANA's understanding of the changes to be made matches that of the working group and document authors. -- Jeff From j.schoenwaelder@jacobs-university.de Tue Apr 14 01:19:18 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 261EC3A69A4 for ; Tue, 14 Apr 2009 01:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBt0q+5LfRJu for ; Tue, 14 Apr 2009 01:19:17 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 331C03A6A1C for ; Tue, 14 Apr 2009 01:19:17 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F8BDC0013; Tue, 14 Apr 2009 10:20:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PETU+RnUobbA; Tue, 14 Apr 2009 10:20:27 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F8CDC0032; Tue, 14 Apr 2009 10:20:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B3179A95363; Tue, 14 Apr 2009 10:20:09 +0200 (CEST) Date: Tue, 14 Apr 2009 10:20:09 +0200 From: Juergen Schoenwaelder To: David Harrington Message-ID: <20090414082009.GA1664@elstar.local> Mail-Followup-To: David Harrington , "isms@ietf.org" References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: [Isms] snmp over ssh iana allocation X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 08:19:18 -0000 On Tue, Apr 14, 2009 at 02:36:55AM +0200, David Harrington wrote: > IANA is considering using snmps to name the snmp/sshtm interface. For > consistency with https, do we want to request that they save snmps for > an snmp/tls interface, and use something like snmpssh to name the > interface? Yes, I agree that it might be a better choice to allocate snmpssh tbd(x161)/tcp SNMP over SSH Transport Model snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model instead of: > snmps tbd(x161)/tcp SNMP over SSH Transport Model > [RFC-isms-secshell-15] > snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model > [RFC-isms-secshell-15] If someone disagrees, please speak up now. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ietfdbh@comcast.net Tue Apr 14 03:50:31 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63C8C3A6DBD for ; Tue, 14 Apr 2009 03:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSC-B5fbA50Y for ; Tue, 14 Apr 2009 03:50:30 -0700 (PDT) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by core3.amsl.com (Postfix) with ESMTP id 043653A6D8B for ; Tue, 14 Apr 2009 03:50:29 -0700 (PDT) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id fMkf1b0010EZKEL55NrWpQ; Tue, 14 Apr 2009 10:51:30 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA01.westchester.pa.mail.comcast.net with comcast id fNrh1b0080UQ6dC3MNrhVS; Tue, 14 Apr 2009 10:51:42 +0000 From: "David Harrington" To: "'Juergen Schoenwaelder'" References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> <20090414082009.GA1664@elstar.local> Date: Tue, 14 Apr 2009 06:51:40 -0400 Message-ID: <052401c9bcee$fe5a5120$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm82d95zxPseronSkafCEfV7XKdxQAFLmgQ In-Reply-To: <20090414082009.GA1664@elstar.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] snmp over ssh iana allocation X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 10:50:31 -0000 Hi, I agree. dbh > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Tuesday, April 14, 2009 4:20 AM > To: David Harrington > Cc: isms@ietf.org > Subject: snmp over ssh iana allocation > > On Tue, Apr 14, 2009 at 02:36:55AM +0200, David Harrington wrote: > > > IANA is considering using snmps to name the snmp/sshtm > interface. For > > consistency with https, do we want to request that they > save snmps for > > an snmp/tls interface, and use something like snmpssh to name the > > interface? > > Yes, I agree that it might be a better choice to allocate > > snmpssh tbd(x161)/tcp SNMP over SSH Transport Model > snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH > Transport Model > > instead of: > > > snmps tbd(x161)/tcp SNMP over SSH Transport Model > > [RFC-isms-secshell-15] > > snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model > > [RFC-isms-secshell-15] > > If someone disagrees, please speak up now. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > From jhutz@cmu.edu Tue Apr 14 05:39:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1484F3A6DDA for ; Tue, 14 Apr 2009 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[AWL=0.648, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsdHf2nQQd3U for ; Tue, 14 Apr 2009 05:39:03 -0700 (PDT) Received: from jackfruit.srv.cs.cmu.edu (JACKFRUIT.SRV.CS.CMU.EDU [128.2.201.16]) by core3.amsl.com (Postfix) with ESMTP id 979693A6DA2 for ; Tue, 14 Apr 2009 05:39:03 -0700 (PDT) Received: from atlantis-home.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.184.185]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id n3ECe9QL003729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2009 08:40:09 -0400 (EDT) Date: Tue, 14 Apr 2009 08:40:09 -0400 From: Jeffrey Hutzelman To: Juergen Schoenwaelder , David Harrington Message-ID: In-Reply-To: <200904140820.n3E8KX0U002513@mx01.srv.cs.cmu.edu> References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> <200904140820.n3E8KX0U002513@mx01.srv.cs.cmu.edu> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.201.16 Cc: isms@ietf.org, jhutz@cmu.edu Subject: Re: [Isms] snmp over ssh iana allocation X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 12:39:05 -0000 --On Tuesday, April 14, 2009 10:20:09 AM +0200 Juergen Schoenwaelder wrote: > On Tue, Apr 14, 2009 at 02:36:55AM +0200, David Harrington wrote: > >> IANA is considering using snmps to name the snmp/sshtm interface. For >> consistency with https, do we want to request that they save snmps for >> an snmp/tls interface, and use something like snmpssh to name the >> interface? > > Yes, I agree that it might be a better choice to allocate > > snmpssh tbd(x161)/tcp SNMP over SSH Transport Model > snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model > > instead of: > >> snmps tbd(x161)/tcp SNMP over SSH Transport Model >> [RFC-isms-secshell-15] >> snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model >> [RFC-isms-secshell-15] > > If someone disagrees, please speak up now. I did reply. I don't feel particularly strongly about it, but I see no reason not to use the names actually mentioned in the SSHTM document, which are "sshtm" and "sshtm-trap". If we decide to use some other set of names, the document should be updated to reflect that. -- Jeff From wjhns1@hardakers.net Tue Apr 14 06:21:34 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CE03A6A6D for ; Tue, 14 Apr 2009 06:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.943 X-Spam-Level: X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+jpgw2iXdSE for ; Tue, 14 Apr 2009 06:21:33 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 7C4D53A68BA for ; Tue, 14 Apr 2009 06:21:33 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 2272B39A0F1; Tue, 14 Apr 2009 06:22:45 -0700 (PDT) From: Wes Hardaker To: David Harrington Organization: Sparta References: <04b301c9bc75$e43a95d0$0600a8c0@china.huawei.com> <20090413205011.GA2358@elstar.local> <04cf01c9bc99$1d461480$0600a8c0@china.huawei.com> <20090414082009.GA1664@elstar.local> Date: Tue, 14 Apr 2009 06:22:45 -0700 In-Reply-To: <20090414082009.GA1664@elstar.local> (Juergen Schoenwaelder's message of "Tue, 14 Apr 2009 10:20:09 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "isms@ietf.org" Subject: Re: [Isms] Ismssnmp over ssh iana allocation X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 13:21:34 -0000 >>>>> On Tue, 14 Apr 2009 10:20:09 +0200, Juergen Schoenwaelder said: JS> snmpssh tbd(x161)/tcp SNMP over SSH Transport Model JS> snmpssh-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model Agreed. -- Wes Hardaker Cobham Analytic Solutions From mankin@psg.com Wed Apr 15 23:56:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAFF3A68B3; Wed, 15 Apr 2009 23:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzQqFhMMcCqu; Wed, 15 Apr 2009 23:56:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 402D53A67B4; Wed, 15 Apr 2009 23:56:50 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=psg.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LuLXm-0009ul-6n; Thu, 16 Apr 2009 06:58:01 +0000 To: ietf@ietf.org, isms@ietf.org Date: Wed, 15 Apr 2009 23:57:54 -0700 Message-ID: <38114.1239865074@psg.com> From: Allison Mankin Cc: TSV Dir Subject: [Isms] Transport directorate review of Last Call: draft-ietf-isms-tmsm X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mankin@psg.com List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 06:56:51 -0000 Transport directorate review of Last Call: draft-ietf-isms-tmsm Transport Subsystem for the Simple Network Management Protocol (SNMP) I've reviewed this document as part of the transport area directorate's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors for their information and to allow them to address any issues raised. The authors should consider this review together with any other last-call comments they receive. Please always CC tsv-dir@ietf.org if you reply to or forward this review. Overall, this document gets a thumbs-up from me. And for extra measure I read over draft-ietf-isms-transport-security-model-12.txt to understqnd its context and found the two very well meshed. I found both of them a very strong base to the in-progress document draft-ietf-isms-secshell-15.txt. A top-level comment/question has to do with the draft's use of the TDomain/TAddress textual convention from RFC 2579, instead of RFC 3419. The revision notes call this out as mid-course choice and I'm sure the working group and the MIB experts have good reasons for it. But is a transport running on, say, TCP-IPv6 going to be appropriate with RFC 2579? In any event, it would be good since this is a transport-focused document if you could add a NOTE about the design choice of TDomain/TAddress. Here's what I'm reading in RFC 3419: Transport endpoints which carry SNMP traffic SHOULD continue to use the definitions from the SNMPv2-TM MIB module where applicable. They SHOULD use the transport domain values defined in this memo for SNMP transports not defined in the SNMPv2-TM MIB module, such as SNMP over UDP over IPv6. Programs that interpret transport domain values should in addition accept all the transport domain values defined in this memo in order to provide interoperability in cases where it is not possible or desirable to distinguish the protocols running over a transport endpoint. Section 2 Though I'm reviewing for the tsv-dir, I can't resist both complimenting and fussing a bit about the paragraph in Section 2 about the individual who considers three approaches to security and ends up hiring a company that can handle all his or her needs comprehensively: The individual therefore achieves the desired security, with no significant effort on his part other than identifying requirements and verifying the quality of service being provided. The discussion is very clear. But "with no significant effort...other than identifying requirements" is like the "small matter of programming." Section 3.2.1 At the mention of multiple transport mappings for SNMP, please give a reference. Section 3.2.1.3 A secure Transport Model will establish an authenticated and possibly encrypted tunnel between the Transport Models of two SNMP engines. After a transport layer tunnel is established, then SNMP messages can be sent through the tunnel from one SNMP engine to the other. Transport Models MAY support sending multiple SNMP messages through the same tunnel. Is the MAY sentence at the end of paragraph necessary? From the standpoint of a transport person, it's hard to envision that an implementor would establish security and tear it down per message, but this MAY is saying that's the default. Later you advise implementations against this. 3.3.1. No SNMP Sessions The transportDomain and transportAddress identify the transport connection to a remote network node. Elements of the transport address (such as the port number) might be used by an application to send a particular PDU type to a particular transport address. This paragraph describes a heuristic to get around the fact that "the transport subsystem does not have access to the pduType." What do pduTypes include? What's a useful example of this hint that makes this reversal worth including? Readability of the two paragraphs before: The Transport Subsystem may support transport sessions. However, the transport subsystem does not have access to the pduType, so cannot select a given transport session for particular types of traffic. Certain parameters of these ASIs might be used to guide the selection of an appropriate transport session to use for a given request by an application. To what does "these ASIs" refer? This hint isn't very clear either. Transport readers want to know... 3.3.4 If a secure transport session is closed between the time a request message is received, and the corresponding response message is sent, then the response message SHOULD be discarded, even if a new session has been established. The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. In other words, under USM, the late response MAY be accepted. This text says that under TSM the security model could decide to accept late responses. The cases are very different from each other and I think there should be a warning that this MAY could be complex to get right. TYPO: Commander Generator -> Command Generator 7.1 Coexistence, Security Parameters, and Access Control This section points out that enabling security models prior to transport-based security will have the result of bypassing the secure transport. Therefore, it recommends against trying coexistence and recommends that the secure transport model detect that the tmStateReference cache is not populated due to use of these other models and fail. However, the section also states that the previous User-Based Security Model differs from the transport-based security model in that it was designed not to depend on external network services. The draft talks about "provisioning" USM AuthPriv for use when TSM is too stressed to work: It is RECOMMENDED that operators provision authPriv USM to supplement any security model or transport model that has external dependencies, so that secure SNMP communications can continue when the external network service is not available. Please make this clearer. This isn't a coexistent USM, right? It's a failback that is enabled when access to dependencies is not possible or when there's other stress determined. 6. IANA Considerations For completeness and for some Security Models as yet unknown, you might want to add a registration for TCP to the SNMP Transport Domain: tcp snmpTCPDomain The reference would be this RFC once published. From Pasi.Eronen@nokia.com Thu Apr 16 02:07:25 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 983E93A6B59 for ; Thu, 16 Apr 2009 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5rpqY8r-E43 for ; Thu, 16 Apr 2009 02:07:24 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 4E3873A69D2 for ; Thu, 16 Apr 2009 02:07:24 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3G98MXa011155; Thu, 16 Apr 2009 04:08:36 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 12:08:29 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 12:08:28 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 12:08:23 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 11:08:23 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Thu, 16 Apr 2009 11:08:23 +0200 From: To: , Date: Thu, 16 Apr 2009 11:08:22 +0200 Thread-Topic: IETF Last Call summary for tmsm/tsm/secshell Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0Kw== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2009 09:08:23.0788 (UTC) FILETIME=[E5369AC0:01C9BE72] X-Nokia-AV: Clean Subject: [Isms] IETF Last Call summary for tmsm/tsm/secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 09:07:25 -0000 The IETF Last Call for tmsm/tsm/secshell ended yesterday (the radius draft is coming a bit later). According to my notes, we got the following comments: 1) Juergen commented MIB module names and copyright statements http://www.ietf.org/mail-archive/web/isms/current/msg03477.html The MIB module names could be handled with RFC Editor notes. I've entered the following ones (please yell if there's something wrong or if you strongly object): secshell: Replace all occurrences of "SSHTM-MIB" with "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7) tsm: Replace all occurrences of "SNMP-TSM-MIB" with "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7) The MIBs already have a copyright notice. The IESG and IETF Trust are currently discussing whether every MIB also needs to include the full BSD licensing terms, or just a pointer to the licensing terms (like MIBs so far have done). I would propose we let the RFC Editor fix this text once a decision has been reached (should happen soon -- the trustees are having a face-to-face meeting this week). 2) IANA reviews: https://datatracker.ietf.org/idtracker/draft-ietf-isms-tmsm/comment/93834/ https://datatracker.ietf.org/idtracker/draft-ietf-isms-transport-security-m= odel/comment/93958/ https://datatracker.ietf.org/idtracker/draft-ietf-isms-secshell/comment/938= 33/ There was some discussion on what the "keywords" for the TCP port numbers should be.=20 http://www.ietf.org/mail-archive/web/isms/current/msg03486.html http://www.ietf.org/mail-archive/web/isms/current/msg03487.html http://www.ietf.org/mail-archive/web/isms/current/msg03488.html http://www.ietf.org/mail-archive/web/isms/current/msg03489.html The conclusion seemed to be that "snmpssh"/"snmpssh-trap" are probably clearer than "snmps"/"snmps-trap" (proposed by IANA) or "sshtm"/"sshtm-trap" (not obvious it's related to snmp). I've entered the following RFC Editor note (please yell if there's something wrong or if you strongly object): Section 10: OLD: 1. two TCP registered port numbers in the http://www.iana.org/assignments/port-numbers registry which will be the default ports for SNMP over an SSH Transport Model (SSHTM) as defined in this document, and SNMP over an SSH Transport Model for notifications (SSHTM-TRAP) as defined in this document. It would be good if the assigned numbers were x161 and x162. NEW: 1. two TCP registered port numbers in the http://www.iana.org/assignments/port-numbers registry which will be the default ports for SNMP over an SSH Transport Model (snmpssh) as defined in this document, and SNMP over an SSH Transport Model for notifications (snmpssh-trap) as defined in this document. It would be good if the assigned numbers were x161 (snmpssh) and x162 (snmpssh-trap). 3) Vijay Gurbani's Gen-ART review for tmsm: http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html One nit about white space/indentation -- will get fixed by the RFC editor when they assign the RFC numbers. 4) Ben Campbell's Gen-ART review for tsm: http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html Couple of editorial comments, all extremely minor. I'd suggest=20 handling these during RFC Editor stage. 5) Allison Mankin's transport directorate review for tmsm: http://www.ietf.org/mail-archive/web/isms/current/msg03490.html At least a reply reply is needed, and possibly some small clarifications. It's possible these could be handled by RFC Editor notes. David, can you reply and propose text? I hope we can get the RFC Editor notes to address Allison's comments soon, so I've placed these on the agenda of next Thursday's IESG telechat (April 23). If we don't have text by Monday, I'll move them to the next telechat (May 7th). Best regards, Pasi From ietfdbh@comcast.net Thu Apr 16 08:28:17 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F35413A6915 for ; Thu, 16 Apr 2009 08:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teXm69Mfg1qF for ; Thu, 16 Apr 2009 08:28:15 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 6DD543A6DB2 for ; Thu, 16 Apr 2009 08:28:15 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id gCpz1b0011GhbT854FVVen; Thu, 16 Apr 2009 15:29:29 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id gFVU1b00Q0UQ6dC3TFVV6E; Thu, 16 Apr 2009 15:29:29 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 16 Apr 2009 11:29:27 -0400 Message-ID: <06ea01c9bea8$2178fc50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0KwAMLspQ In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 15:28:17 -0000 Hi Pasi, At ietf74, I mentioned some editorial changes that I think should be done, but never posted them during IETF Last Call. The biggest change I recall is the separation of the discussion of notification access control from the discussion of proxy (which does no access control). I think that is a bigger change than an RFC Editor note can handle. I think some of Allison's comments point out places where our text is not clear enough yet, and much of this has to do with the architectural constraints. I do not think these could be handled well by an RFC Editor note. I suggest the best approach is for me to make the following requested changes to the documents, keeping the changes as small as possible, and let the WG review the changes. An additional benefit of doing this ourselves is that I would have the updated sources for the documents. I haven't thoroughly reviewed all the changes needed for Allison's comments, but I think the whole thing should take no more than two days editing (and composing). I can also send direct responses to the reviewer comments as part of that process. Does that sound OK? dbh > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Thursday, April 16, 2009 5:08 AM > To: isms@ietf.org; ietfdbh@comcast.net > Subject: IETF Last Call summary for tmsm/tsm/secshell > > The IETF Last Call for tmsm/tsm/secshell ended yesterday (the radius > draft is coming a bit later). According to my notes, we got the > following comments: > > 1) Juergen commented MIB module names and copyright statements > http://www.ietf.org/mail-archive/web/isms/current/msg03477.html > > The MIB module names could be handled with RFC Editor notes. > I've entered the following ones (please yell if there's something > wrong or if you strongly object): > > secshell: Replace all occurrences of "SSHTM-MIB" with > "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7) > > tsm: Replace all occurrences of "SNMP-TSM-MIB" with > "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7) > > The MIBs already have a copyright notice. The IESG and IETF Trust are > currently discussing whether every MIB also needs to include the full > BSD licensing terms, or just a pointer to the licensing terms (like > MIBs so far have done). I would propose we let the RFC Editor fix this > text once a decision has been reached (should happen soon -- the > trustees are having a face-to-face meeting this week). > > 2) IANA reviews: > > https://datatracker.ietf.org/idtracker/draft-ietf-isms-tmsm/co mment/93834/ > https://datatracker.ietf.org/idtracker/draft-ietf-isms-transpo > rt-security-model/comment/93958/ > https://datatracker.ietf.org/idtracker/draft-ietf-isms-secshel l/comment/93833/ > > There was some discussion on what the "keywords" for the TCP port > numbers should be. > > http://www.ietf.org/mail-archive/web/isms/current/msg03486.html > http://www.ietf.org/mail-archive/web/isms/current/msg03487.html > http://www.ietf.org/mail-archive/web/isms/current/msg03488.html > http://www.ietf.org/mail-archive/web/isms/current/msg03489.html > > The conclusion seemed to be that "snmpssh"/"snmpssh-trap" are probably > clearer than "snmps"/"snmps-trap" (proposed by IANA) or > "sshtm"/"sshtm-trap" (not obvious it's related to snmp). I've entered > the following RFC Editor note (please yell if there's something wrong > or if you strongly object): > > Section 10: > OLD: > 1. two TCP registered port numbers in the > http://www.iana.org/assignments/port-numbers registry > which will > be the default ports for SNMP over an SSH Transport > Model (SSHTM) > as defined in this document, and SNMP over an SSH > Transport Model > for notifications (SSHTM-TRAP) as defined in this document. It > would be good if the assigned numbers were x161 and x162. > NEW: > 1. two TCP registered port numbers in the > http://www.iana.org/assignments/port-numbers registry > which will > be the default ports for SNMP over an SSH Transport > Model (snmpssh) > as defined in this document, and SNMP over an SSH > Transport Model > for notifications (snmpssh-trap) as defined in this > document. It > would be good if the assigned numbers were x161 > (snmpssh) and x162 > (snmpssh-trap). > > > 3) Vijay Gurbani's Gen-ART review for tmsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html > > One nit about white space/indentation -- will get fixed by > the RFC editor when they assign the RFC numbers. > > > 4) Ben Campbell's Gen-ART review for tsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html > > Couple of editorial comments, all extremely minor. I'd suggest > handling these during RFC Editor stage. > > > 5) Allison Mankin's transport directorate review for tmsm: > http://www.ietf.org/mail-archive/web/isms/current/msg03490.html > > At least a reply reply is needed, and possibly some small > clarifications. It's possible these could be handled by RFC Editor > notes. > > David, can you reply and propose text? > > > I hope we can get the RFC Editor notes to address Allison's comments > soon, so I've placed these on the agenda of next Thursday's IESG > telechat (April 23). If we don't have text by Monday, > I'll move them to the next telechat (May 7th). > > Best regards, > Pasi > > From Pasi.Eronen@nokia.com Thu Apr 16 10:47:22 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B51CD3A6818 for ; Thu, 16 Apr 2009 10:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vM6fSnX8ZpHu for ; Thu, 16 Apr 2009 10:47:21 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C46693A6AB8 for ; Thu, 16 Apr 2009 10:47:20 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3GHmPIS027833; Thu, 16 Apr 2009 20:48:25 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 20:48:27 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Apr 2009 20:48:22 +0300 Received: from nok-am1mhub-08.mgdnok.nokia.com (65.54.30.15) by NOK-am1MHUB-01.mgdnok.nokia.com (65.54.30.5) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 19:48:22 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-08.mgdnok.nokia.com ([65.54.30.15]) with mapi; Thu, 16 Apr 2009 19:48:22 +0200 From: To: , Date: Thu, 16 Apr 2009 19:48:19 +0200 Thread-Topic: IETF Last Call summary for tmsm/tsm/secshell Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0KwAMLspQAAXvO2A= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F235683D@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> <06ea01c9bea8$2178fc50$0600a8c0@china.huawei.com> In-Reply-To: <06ea01c9bea8$2178fc50$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 16 Apr 2009 17:48:22.0695 (UTC) FILETIME=[89360370:01C9BEBB] X-Nokia-AV: Clean Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 17:47:22 -0000 OK -- I've moved these to the May 7th IESG telechat (which means updated drafts are needed by end of April). =20 Best regards, Pasi > -----Original Message----- > From: ext David Harrington [mailto:ietfdbh@comcast.net] > Sent: 16 April, 2009 18:29 > To: Eronen Pasi (Nokia-NRC/Helsinki); isms@ietf.org > Subject: RE: IETF Last Call summary for tmsm/tsm/secshell >=20 > Hi Pasi, >=20 > At ietf74, I mentioned some editorial changes that I think should be > done, but never posted them during IETF Last Call. The biggest change > I recall is the separation of the discussion of notification access > control from the discussion of proxy (which does no access control). I > think that is a bigger change than an RFC Editor note can handle. >=20 > I think some of Allison's comments point out places where our text is > not clear enough yet, and much of this has to do with the > architectural constraints. I do not think these could be handled well > by an RFC Editor note. >=20 > I suggest the best approach is for me to make the following requested > changes to the documents, keeping the changes as small as possible, > and let the WG review the changes. An additional benefit of doing this > ourselves is that I would have the updated sources for the documents. >=20 > I haven't thoroughly reviewed all the changes needed for Allison's > comments, but I think the whole thing should take no more than two > days editing (and composing). I can also send direct responses to the > reviewer comments as part of that process. >=20 > Does that sound OK? >=20 > dbh >=20 > > -----Original Message----- > > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > > Sent: Thursday, April 16, 2009 5:08 AM > > To: isms@ietf.org; ietfdbh@comcast.net > > Subject: IETF Last Call summary for tmsm/tsm/secshell > > > > The IETF Last Call for tmsm/tsm/secshell ended yesterday (the radius > > draft is coming a bit later). According to my notes, we got the > > following comments: > > > > 1) Juergen commented MIB module names and copyright statements > > http://www.ietf.org/mail-archive/web/isms/current/msg03477.html > > > > The MIB module names could be handled with RFC Editor notes. > > I've entered the following ones (please yell if there's something > > wrong or if you strongly object): > > > > secshell: Replace all occurrences of "SSHTM-MIB" with > > "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7) > > > > tsm: Replace all occurrences of "SNMP-TSM-MIB" with > > "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7) > > > > The MIBs already have a copyright notice. The IESG and IETF Trust > are > > currently discussing whether every MIB also needs to include the > full > > BSD licensing terms, or just a pointer to the licensing terms (like > > MIBs so far have done). I would propose we let the RFC Editor fix > this > > text once a decision has been reached (should happen soon -- the > > trustees are having a face-to-face meeting this week). > > > > 2) IANA reviews: > > > > https://datatracker.ietf.org/idtracker/draft-ietf-isms-tmsm/co > mment/93834/ > > https://datatracker.ietf.org/idtracker/draft-ietf-isms-transpo > > rt-security-model/comment/93958/ > > https://datatracker.ietf.org/idtracker/draft-ietf-isms-secshel > l/comment/93833/ > > > > There was some discussion on what the "keywords" for the TCP port > > numbers should be. > > > > http://www.ietf.org/mail-archive/web/isms/current/msg03486.html > > http://www.ietf.org/mail-archive/web/isms/current/msg03487.html > > http://www.ietf.org/mail-archive/web/isms/current/msg03488.html > > http://www.ietf.org/mail-archive/web/isms/current/msg03489.html > > > > The conclusion seemed to be that "snmpssh"/"snmpssh-trap" are > probably > > clearer than "snmps"/"snmps-trap" (proposed by IANA) or > > "sshtm"/"sshtm-trap" (not obvious it's related to snmp). I've > entered > > the following RFC Editor note (please yell if there's something > wrong > > or if you strongly object): > > > > Section 10: > > OLD: > > 1. two TCP registered port numbers in the > > http://www.iana.org/assignments/port-numbers registry > > which will > > be the default ports for SNMP over an SSH Transport > > Model (SSHTM) > > as defined in this document, and SNMP over an SSH > > Transport Model > > for notifications (SSHTM-TRAP) as defined in this document. > It > > would be good if the assigned numbers were x161 and x162. > > NEW: > > 1. two TCP registered port numbers in the > > http://www.iana.org/assignments/port-numbers registry > > which will > > be the default ports for SNMP over an SSH Transport > > Model (snmpssh) > > as defined in this document, and SNMP over an SSH > > Transport Model > > for notifications (snmpssh-trap) as defined in this > > document. It > > would be good if the assigned numbers were x161 > > (snmpssh) and x162 > > (snmpssh-trap). > > > > > > 3) Vijay Gurbani's Gen-ART review for tmsm: > > http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html > > > > One nit about white space/indentation -- will get fixed by > > the RFC editor when they assign the RFC numbers. > > > > > > 4) Ben Campbell's Gen-ART review for tsm: > > http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html > > > > Couple of editorial comments, all extremely minor. I'd suggest > > handling these during RFC Editor stage. > > > > > > 5) Allison Mankin's transport directorate review for tmsm: > > http://www.ietf.org/mail-archive/web/isms/current/msg03490.html > > > > At least a reply reply is needed, and possibly some small > > clarifications. It's possible these could be handled by RFC Editor > > notes. > > > > David, can you reply and propose text? > > > > > > I hope we can get the RFC Editor notes to address Allison's comments > > soon, so I've placed these on the agenda of next Thursday's IESG > > telechat (April 23). If we don't have text by Monday, > > I'll move them to the next telechat (May 7th). > > > > Best regards, > > Pasi > > > > From j.schoenwaelder@jacobs-university.de Thu Apr 16 11:21:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A53F3A68B6 for ; Thu, 16 Apr 2009 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6BIf4ErT9Qf for ; Thu, 16 Apr 2009 11:21:35 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 184223A68B8 for ; Thu, 16 Apr 2009 11:20:58 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DAF3C006A; Thu, 16 Apr 2009 20:22:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id JVmnDNpwF0Nm; Thu, 16 Apr 2009 20:22:09 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC1F0C0008; Thu, 16 Apr 2009 20:22:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 79A78AA6FAA; Thu, 16 Apr 2009 20:21:50 +0200 (CEST) Date: Thu, 16 Apr 2009 20:21:50 +0200 From: Juergen Schoenwaelder To: "ietfdbh@comcast.net" Message-ID: <20090416182150.GA18876@elstar.local> Mail-Followup-To: "ietfdbh@comcast.net" , "Pasi.Eronen@nokia.com" , "isms@ietf.org" References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> <06ea01c9bea8$2178fc50$0600a8c0@china.huawei.com> <808FD6E27AD4884E94820BC333B2DB7727F235683D@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F235683D@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:21:36 -0000 On Thu, Apr 16, 2009 at 07:48:19PM +0200, Pasi.Eronen@nokia.com wrote: > OK -- I've moved these to the May 7th IESG telechat > (which means updated drafts are needed by end of April). Let me add that it would be very good to have updated drafts by the end of next week so we all have time to review 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 From ietfdbh@comcast.net Fri Apr 17 07:47:01 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1FE23A68FF for ; Fri, 17 Apr 2009 07:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.473 X-Spam-Level: X-Spam-Status: No, score=-2.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvQV5jfMXZeq for ; Fri, 17 Apr 2009 07:47:00 -0700 (PDT) Received: from QMTA07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by core3.amsl.com (Postfix) with ESMTP id 3CAD63A68AB for ; Fri, 17 Apr 2009 07:47:00 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA07.westchester.pa.mail.comcast.net with comcast id gbJB1b0070vyq2s57enhyt; Fri, 17 Apr 2009 14:47:41 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id geoE1b0010UQ6dC3ReoEU3; Fri, 17 Apr 2009 14:48:14 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> Date: Fri, 17 Apr 2009 10:48:13 -0400 Message-ID: <077d01c9bf6b$88d70a90$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0KwAZOJCA In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell #1 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 14:47:01 -0000 Hi, 1) In rev08, we changed all instances of SNMP-TRANSPORT-SM-MIB to SNMP-TSM-MIB to be consistent with the naming guidelines in RFC4181. See the change log. I propose to not make this change back and forth over and over. So, I guess this is a -1. ;-) I will add an RFC editor note to make sure the MIB copyright follows trust guidelines. The existing document contains the updated MIB copyright required by the Trust at time of publication (just prior to ietf74). 2) I have contacted IANA with our requested changes 3, 4, 5) will review comments, edit, and respond dbh > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Thursday, April 16, 2009 5:08 AM > To: isms@ietf.org; ietfdbh@comcast.net > Subject: IETF Last Call summary for tmsm/tsm/secshell > > The IETF Last Call for tmsm/tsm/secshell ended yesterday (the radius > draft is coming a bit later). According to my notes, we got the > following comments: > > 1) Juergen commented MIB module names and copyright statements > http://www.ietf.org/mail-archive/web/isms/current/msg03477.html > > The MIB module names could be handled with RFC Editor notes. > I've entered the following ones (please yell if there's something > wrong or if you strongly object): > > secshell: Replace all occurrences of "SSHTM-MIB" with > "SNMP-SSH-TM-MIB" (also in the MIB module in Section 7) > > tsm: Replace all occurrences of "SNMP-TSM-MIB" with > "SNMP-TRANSPORT-SM-MIB" (also in the MIB module in Section 7) > > The MIBs already have a copyright notice. The IESG and IETF Trust are > currently discussing whether every MIB also needs to include the full > BSD licensing terms, or just a pointer to the licensing terms (like > MIBs so far have done). I would propose we let the RFC Editor fix this > text once a decision has been reached (should happen soon -- the > trustees are having a face-to-face meeting this week). > > 2) IANA reviews: > > https://datatracker.ietf.org/idtracker/draft-ietf-isms-tmsm/co mment/93834/ > https://datatracker.ietf.org/idtracker/draft-ietf-isms-transpo > rt-security-model/comment/93958/ > https://datatracker.ietf.org/idtracker/draft-ietf-isms-secshel l/comment/93833/ > > There was some discussion on what the "keywords" for the TCP port > numbers should be. > > http://www.ietf.org/mail-archive/web/isms/current/msg03486.html > http://www.ietf.org/mail-archive/web/isms/current/msg03487.html > http://www.ietf.org/mail-archive/web/isms/current/msg03488.html > http://www.ietf.org/mail-archive/web/isms/current/msg03489.html > > The conclusion seemed to be that "snmpssh"/"snmpssh-trap" are probably > clearer than "snmps"/"snmps-trap" (proposed by IANA) or > "sshtm"/"sshtm-trap" (not obvious it's related to snmp). I've entered > the following RFC Editor note (please yell if there's something wrong > or if you strongly object): > > Section 10: > OLD: > 1. two TCP registered port numbers in the > http://www.iana.org/assignments/port-numbers registry > which will > be the default ports for SNMP over an SSH Transport > Model (SSHTM) > as defined in this document, and SNMP over an SSH > Transport Model > for notifications (SSHTM-TRAP) as defined in this document. It > would be good if the assigned numbers were x161 and x162. > NEW: > 1. two TCP registered port numbers in the > http://www.iana.org/assignments/port-numbers registry > which will > be the default ports for SNMP over an SSH Transport > Model (snmpssh) > as defined in this document, and SNMP over an SSH > Transport Model > for notifications (snmpssh-trap) as defined in this > document. It > would be good if the assigned numbers were x161 > (snmpssh) and x162 > (snmpssh-trap). > > > 3) Vijay Gurbani's Gen-ART review for tmsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html > > One nit about white space/indentation -- will get fixed by > the RFC editor when they assign the RFC numbers. > > > 4) Ben Campbell's Gen-ART review for tsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html > > Couple of editorial comments, all extremely minor. I'd suggest > handling these during RFC Editor stage. > > > 5) Allison Mankin's transport directorate review for tmsm: > http://www.ietf.org/mail-archive/web/isms/current/msg03490.html > > At least a reply reply is needed, and possibly some small > clarifications. It's possible these could be handled by RFC Editor > notes. > > David, can you reply and propose text? > > > I hope we can get the RFC Editor notes to address Allison's comments > soon, so I've placed these on the agenda of next Thursday's IESG > telechat (April 23). If we don't have text by Monday, > I'll move them to the next telechat (May 7th). > > Best regards, > Pasi > > From j.schoenwaelder@jacobs-university.de Mon Apr 20 00:38:44 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64C713A67F0 for ; Mon, 20 Apr 2009 00:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVU7Di1y5DKi for ; Mon, 20 Apr 2009 00:38:43 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 2CA523A6825 for ; Mon, 20 Apr 2009 00:38:43 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83809C001B for ; Mon, 20 Apr 2009 09:39:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9V3MrjaCb-yT for ; Mon, 20 Apr 2009 09:39:57 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 206EBC000F for ; Mon, 20 Apr 2009 09:39:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 16376AB511B; Mon, 20 Apr 2009 09:39:39 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Mon, 20 Apr 2009 09:39:38 +0200 Resent-Message-ID: <20090420073938.GB10099@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Mon, 20 Apr 2009 09:30:24 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBE3C000F for ; Mon, 20 Apr 2009 09:30:24 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 4705F52C for ; Mon, 20 Apr 2009 09:30:24 +0200 (CEST) Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id RNS5hge5xt4X for ; Mon, 20 Apr 2009 09:30:22 +0200 (CEST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas1b.jacobs-university.de (Postfix) with ESMTP for ; Mon, 20 Apr 2009 09:30:22 +0200 (CEST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 707C52089D; Mon, 20 Apr 2009 09:02:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4E368208C1; Mon, 20 Apr 2009 09:02:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:02:44 +0200 Received: from [159.107.24.247] ([159.107.24.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:02:43 +0200 From: "Miguel A. Garcia" To: "kaushik_narayan@yahoo.com" , "d.b.nelson@comcast.net" , =?iso-8859-1?Q?=22Sch=F6nw=E4lder=2C_J=FCrgen=22?= , Pasi Eronen Date: Mon, 20 Apr 2009 09:02:43 +0200 Thread-Topic: Gen-ART review of draft-ietf-isms-radius-usage-05.txt Thread-Index: AcnBid6DjQ8plMp5R6i2XtYKAV3Vrg== Message-ID: <49EC1E13.8040205@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Thunderbird 2.0.0.21 (Windows/20090302) x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ericsson.se DNSWLId 1790 x-originalarrivaltime: 20 Apr 2009 07:02:43.0867 (UTC) FILETIME=[00B8F6B0:01C9C186] x-brightmail-tracker: AAAAAA== x-auditid: c1b4fb3c-ab7ccbb00000238f-f8-49ec1e14f50f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team Subject: [Isms] Gen-ART review of draft-ietf-isms-radius-usage-05.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:38:44 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isms-radius-usage-05.txt Reviewer: Miguel Garcia Review Date: 2009-04-20 IETF LC End Date: 2009-04-21 Summary: This document is ready for publication as a standards track RFC. Major issues: none Minor issues: none Nits/editorial comments: - On Section 3, it would be nice to add a caption to each of the tables,=20 so that the text can refer to "Table 1" and "Table 2" rather than "the=20 following table". It also allows other documents to refer to these tables=20 in the future. - On Section 4, the note to the RFC Editor indicates that the whole=20 section should disappear upon publication. I don't think this is correct.=20 The section should remain upon publication with the only sentence being=20 the first line in the current text. - idnits indicates that the reference [RFC3415] is never used, thus, it=20 can be deleted. /Miguel --=20 Miguel A. Garcia +34-91-339-3608 Ericsson Spain From j.schoenwaelder@jacobs-university.de Mon Apr 20 00:38:51 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CCBF3A6912 for ; Mon, 20 Apr 2009 00:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqPGLEH8UdGG for ; Mon, 20 Apr 2009 00:38:51 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id C0F803A67F0 for ; Mon, 20 Apr 2009 00:38:50 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 20D15C0017 for ; Mon, 20 Apr 2009 09:40:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OV1s+6aZiZCj for ; Mon, 20 Apr 2009 09:40:06 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E6F10C000F for ; Mon, 20 Apr 2009 09:40:05 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 038EAAB5102; Mon, 20 Apr 2009 09:39:39 +0200 (CEST) Resent-From: j.schoenwaelder@jacobs-university.de Resent-Date: Mon, 20 Apr 2009 09:39:38 +0200 Resent-Message-ID: <20090420073938.GB10099@elstar.local> Resent-To: isms@ietf.org Received: from hermes.jacobs-university.de (212.201.44.23) by exchange.jacobs-university.de (10.70.0.123) with Microsoft SMTP Server id 8.1.358.0; Mon, 20 Apr 2009 09:30:24 +0200 Received: from atlas1.jacobs-university.de (atlas1a.jacobs-university.de [212.201.44.13]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4DBE3C000F for ; Mon, 20 Apr 2009 09:30:24 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by atlas1.jacobs-university.de (Postfix) with ESMTP id 4705F52C for ; Mon, 20 Apr 2009 09:30:24 +0200 (CEST) Received: from atlas1b.jacobs-university.de ([212.201.44.13]) by localhost (demetrius2.jacobs-university.de [212.201.44.47]) (amavisd-new, port 10030) with ESMTP id RNS5hge5xt4X for ; Mon, 20 Apr 2009 09:30:22 +0200 (CEST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas1b.jacobs-university.de (Postfix) with ESMTP for ; Mon, 20 Apr 2009 09:30:22 +0200 (CEST) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 707C52089D; Mon, 20 Apr 2009 09:02:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4E368208C1; Mon, 20 Apr 2009 09:02:44 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:02:44 +0200 Received: from [159.107.24.247] ([159.107.24.247]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Apr 2009 09:02:43 +0200 From: "Miguel A. Garcia" To: "kaushik_narayan@yahoo.com" , "d.b.nelson@comcast.net" , =?iso-8859-1?Q?=22Sch=F6nw=E4lder=2C_J=FCrgen=22?= , Pasi Eronen Date: Mon, 20 Apr 2009 09:02:43 +0200 Thread-Topic: Gen-ART review of draft-ietf-isms-radius-usage-05.txt Thread-Index: AcnBid6DjQ8plMp5R6i2XtYKAV3Vrg== Message-ID: <49EC1E13.8040205@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Exchange-Organization-AuthAs: Anonymous X-MS-Exchange-Organization-AuthSource: SHUBCAS02.jacobs.jacobs-university.de X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Thunderbird 2.0.0.21 (Windows/20090302) x-virus-scanned: amavisd-new at jacobs-university.de x-jacobsispwhitelisted: med ericsson.se DNSWLId 1790 x-originalarrivaltime: 20 Apr 2009 07:02:43.0867 (UTC) FILETIME=[00B8F6B0:01C9C186] x-brightmail-tracker: AAAAAA== x-auditid: c1b4fb3c-ab7ccbb00000238f-f8-49ec1e14f50f Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: General Area Review Team Subject: [Isms] Gen-ART review of draft-ietf-isms-radius-usage-05.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 07:38:51 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-isms-radius-usage-05.txt Reviewer: Miguel Garcia Review Date: 2009-04-20 IETF LC End Date: 2009-04-21 Summary: This document is ready for publication as a standards track RFC. Major issues: none Minor issues: none Nits/editorial comments: - On Section 3, it would be nice to add a caption to each of the tables,=20 so that the text can refer to "Table 1" and "Table 2" rather than "the=20 following table". It also allows other documents to refer to these tables=20 in the future. - On Section 4, the note to the RFC Editor indicates that the whole=20 section should disappear upon publication. I don't think this is correct.=20 The section should remain upon publication with the only sentence being=20 the first line in the current text. - idnits indicates that the reference [RFC3415] is never used, thus, it=20 can be deleted. /Miguel --=20 Miguel A. Garcia +34-91-339-3608 Ericsson Spain From dnelson@elbrysnetworks.com Mon Apr 20 15:24:56 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E606628C1B6 for ; Mon, 20 Apr 2009 15:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.862 X-Spam-Level: X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.737, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbiGKSLOZaXO for ; Mon, 20 Apr 2009 15:24:55 -0700 (PDT) Received: from gumby.elbrysnetworks.com (mail.elbrysnetworks.com [64.140.243.164]) by core3.amsl.com (Postfix) with SMTP id 645DD28C2CB for ; Mon, 20 Apr 2009 15:24:55 -0700 (PDT) Received: (qmail 15718 invoked from network); 20 Apr 2009 17:26:09 -0400 Received: from xpsuperdvd2.elbrysnetworks.com (HELO xpsuperdvd2) (172.22.18.93) by gumby.elbrysnetworks.com with SMTP; 20 Apr 2009 17:26:09 -0400 From: "David B. Nelson" To: References: <20090407145932.486C43A6C05@core3.amsl.com> Date: Mon, 20 Apr 2009 17:26:06 -0400 Organization: Elbrys Networks, Inc. Message-ID: 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.5579 In-Reply-To: <20090407145932.486C43A6C05@core3.amsl.com> Thread-Index: Acm3ke4gtTC+aJUIS6mVtxOlN+mwjwKauokw Cc: isms@ietf.org Subject: Re: [Isms] Last Call: draft-ietf-isms-radius-usage (Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 22:24:57 -0000 On March 9, 2009 Alan DeKok wrote... > Security Section: > > There are good reasons to provision USM access so supplement with > AAA-based access, however. > > > NIT: This doesn't appear to be a sentence. Yeah. Let's see what that was supposed to say... I think it's: There are good reasons to provision USM access to supplement AAA-based access, however. ISMS decided to handle this late WG Last Call comment as IETF Last Call input, so I'm re-posting the message now. From ietfdbh@comcast.net Tue Apr 21 15:39:38 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 822DD3A6EBD for ; Tue, 21 Apr 2009 15:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C4O-D-xkLlL9 for ; Tue, 21 Apr 2009 15:39:37 -0700 (PDT) Received: from QMTA04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 33E5B3A6EF1 for ; Tue, 21 Apr 2009 15:39:37 -0700 (PDT) Received: from OMTA07.westchester.pa.mail.comcast.net ([76.96.62.59]) by QMTA04.westchester.pa.mail.comcast.net with comcast id iF0o1b01H1GhbT854NgufE; Tue, 21 Apr 2009 22:40:54 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA07.westchester.pa.mail.comcast.net with comcast id iNgu1b0050UQ6dC3TNguE5; Tue, 21 Apr 2009 22:40:54 +0000 From: "David Harrington" To: References: <20090401142808.98F6B28C1BD@core3.amsl.com> Date: Tue, 21 Apr 2009 18:40:53 -0400 Message-ID: <022401c9c2d2$3a7b4e50$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acm6HLSvGRjX8W5bSTGs/Z1jKNeoMgEvk8cQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: isms@ietf.org Subject: Re: [Isms] [IANA #233488] Last Call: draft-ietf-isms-secshell (Secure Shell Transport Model for SNMP) to Proposed Standard X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 22:39:38 -0000 Hi Amanda, The WG discussed these assignments. They would prefer different keywords for Action 1: snmpssh rather than snmps snmpssh-trap rather than snmps-trap. I think Action 3 should use the following: [tbd] snmpSSHDomain SNMP over SSH Transport Model [RFC-isms-secshell-15] Thanks, David Harrington dbharrington@comcast.net ietfdbh@comcast.net dharrington@huawei.com > -----Original Message----- > From: Amanda Baber via RT [mailto:drafts-lastcall@icann.org] > Sent: Friday, April 10, 2009 3:43 PM > Cc: dharrington@huawei.com; jsalowey@cisco.com; > ietf@hardakers.net; isms-chairs@tools.ietf.org; iesg@ietf.org > Subject: [IANA #233488] Last Call: draft-ietf-isms-secshell > (Secure Shell Transport Model for SNMP) to Proposed Standard > > IESG: > > IANA has reviewed draft-ietf-isms-secshell-15.txt, which is > currently in Last Call, and has the following comments: > > [ Note: Actions in this document require the execution of the > actions in draft-ietf-isms-tmsm-16.txt ] > > Action 1: > > Upon approval of this document, IANA will make the following > assignments in the registered port numbers registry located at > http://www.iana.org/assignments/port-numbers > > Keyword Decimal Description References > ------- ------- ----------- ---------- > snmps tbd(x161)/tcp SNMP over SSH Transport Model > [RFC-isms-secshell-15] > snmps-trap tbd(x162)/tcp SNMP Notification over SSH Transport Model > [RFC-isms-secshell-15] > > > Action 2: > > Upon approval of this document, IANA will make the following > assignment in the "iso.org.dod.internet.mgmt.mib-2 (1.3.6.1.2.1)" > registry at > http://www.iana.org/assignments/smi-numbers > > Decimal Name Description References > ------- ---- ----------- ---------- > [tbd] sshtmMIB The Secure Shell Transport Model MIB > [RFC-isms-secshell-15] > > > Action 3: > > Upon approval of this document, IANA will make the following > assignment in the "iso.org.dod.internet.snmpv2.snmpDomains > (1.3.6.1.6.1)" registry at > http://www.iana.org/assignments/smi-numbers > > Decimal Name Description References > ------- -------------- ----------------- ---------- > [tbd] snmpSSHDomain SNMP SSH Domain Mib [RFC-isms-secshell-15] > > > Action 4: > > Upon approval of this document, IANA will make the following > assignment in the "SNMP Transport Domains" registry at > http://www.iana.org/assignments/snmp-number-spaces > > Prefix snmpDomains Reference > ------- ----------------------------- --------- > ssh snmpSSHDomain [RFC-isms-secshell-15] > > > Action 5: > > Upon approval of this document, IANA will make the following > assignment in the "Connection Protocol Subsystem Names" registry at > http://www.iana.org/assignments/ssh-parameters > > Subsystem Name Reference > ------------------------------ --------- > snmp [RFC-isms-secshell-15] > > > We understand the above to be the only IANA Actions for this document. > > > Thank you. > > Amanda Baber > (on behalf of IANA) > > > On Wed Apr 01 14:31:38 2009, noreply@ietf.org wrote: > > The IESG has received a request from the Integrated > Security Model for > > SNMP WG (isms) to consider the following document: > > > > - 'Secure Shell Transport Model for SNMP ' > > as a Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, > and solicits > > final comments on this action. Please send substantive comments to > > the > > ietf@ietf.org mailing lists by 2009-04-15. Exceptionally, > > comments may be sent to iesg@ietf.org instead. In either > case, please > > retain the beginning of the Subject line to allow automated sorting. > > > > The file can be obtained via > > http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-15.txt > > > > > > IESG discussion can be tracked via > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=vie w_id&dTag=13827&rfc_flag=0 > > > > The following IPR Declarations may be related to this I-D: > > > > > > > > From ietfdbh@comcast.net Wed Apr 22 21:36:39 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E17663A6D99 for ; Wed, 22 Apr 2009 21:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.483 X-Spam-Level: X-Spam-Status: No, score=-3.483 tagged_above=-999 required=5 tests=[AWL=1.116, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v57B-ENahJiS for ; Wed, 22 Apr 2009 21:36:38 -0700 (PDT) Received: from QMTA03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by core3.amsl.com (Postfix) with ESMTP id 74BCD3A6938 for ; Wed, 22 Apr 2009 21:36:38 -0700 (PDT) Received: from OMTA05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA03.westchester.pa.mail.comcast.net with comcast id isb01b0020vyq2s53sdDrr; Thu, 23 Apr 2009 04:37:13 +0000 Received: from Harrington73653 ([24.147.240.21]) by OMTA05.westchester.pa.mail.comcast.net with comcast id isdw1b0020UQ6dC3Rsdwiw; Thu, 23 Apr 2009 04:37:56 +0000 From: "David Harrington" To: , References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> Date: Thu, 23 Apr 2009 00:37:54 -0400 Message-ID: <003e01c9c3cd$4585fa10$0600a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0KwFG9QQg X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> Cc: ben@estacado.net, tsv-dir@ietf.org, gen-art@ietf.org, vkg@alcatel-lucent.com Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell #1, #3, #4, #5 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 04:36:40 -0000 Last Call: draft-ietf-isms-tmsm and draft-ietf-isms-transport-security-model Transport Subsystem for the Simple Network Management Protocol (SNMP) 1) Juergen commented MIB module names RFC4181 recommenda a naming convention where the module name, module identity, and prefixes are consistent: - The module name should be of the form XXX-MIB (or XXX-TC-MIB for a module with TCs only), where XXX is a unique prefix (usually all caps with hyphens for separators) that is not used by any existing module. For example, the module for managing optical interfaces [RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB. - The descriptor associated with the MODULE-IDENTITY invocation should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx is a mixed-case version of XXX starting with a lowercase letter and without any hyphens. For example, the OPT-IF-MIB uses the prefix optIf, and the descriptor associated with its MODULE-IDENTITY invocation is optIfMibModule. - Other descriptors within the MIB module should start with the same prefix xxx. OPT-IF-MIB uses the prefix optIf for all descriptors. I don't think we should change SNMP-TSM-MIB to SNMP-TRANSPORT-SM-MIB. I don't see significant benefit in this change. I do not object to changing SSHTM-MIB to SNMP-SSHTM-MIB or SNMPSSH-MIB. > 3) Vijay Gurbani's Gen-ART review for tmsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html > > One nit about white space/indentation -- will get fixed by > the RFC editor when they assign the RFC numbers. I believe this is related to the version of xml2rfc in use. It seems to vary after xml2rfc upgrades. When the RFC Editor does their final pass, it should be fine. > > > 4) Ben Campbell's Gen-ART review for tsm: > http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html > > Couple of editorial comments, all extremely minor. I'd suggest > handling these during RFC Editor stage. The "*" is part of the official name of the SNMPv2 variation. reference to USM provided. section 4.2 first two paragraphs ARE an ordered sequence - note that 3) follows a ways down in the procedures. pointer to smi-registry provided for mib-2 removed open issues and change log sections added pointer to secshell document for port assignment > > > 5) Allison Mankin's transport directorate review for tmsm: > http://www.ietf.org/mail-archive/web/isms/current/msg03490.html > A top-level comment/question has to do with the draft's use of the TDomain/TAddress textual convention from RFC 2579, instead of RFC 3419. NEW: This document uses TDomain textual conventions for the SNMP-internal MIB modules defined here for compatibility with the RFC3413 MIB modules and the RFC3411 Abstract Service Interfaces. OLD: with no significant effort...other than identifying requirements and verifying the quality of service being provided. NEW: The individual therefore achieves the desired security, with significantly less effort on his part except identifying requirements and verifying the quality of service being provided. reference for transport mappings added OLD: Transport Models MAY support sending multiple SNMP messages through the same tunnel. NEW: While the Community Security Models and the User-based Security Model establish a security association for each SNMP message, newer Transport Models MAY support sending multiple SNMP messages through the same tunnel to amortize the costs of establishing a security association. > This paragraph describes a heuristic to get around the fact that "the transport subsystem does not have access to the pduType." What do pduTypes include? What's a useful example of this hint that makes this reversal worth including? NEW: ... the transport subsystem does not have access to the pduType (i.e., the SNMP operation type) ... NEW: For example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB are used to configure notification originators with the destination port to which SNMPv2-Trap PDUs or Inform PDUs should be sent, but the transport subsystem never looks inside the PDU. OLD: The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. NEW: The SNMPv3 WG decided that this should be a SHOULD architecturally, and it is a security-model-specific decision whether to REQUIRE this. The architecture does not mandate this requirement to allow for future security models where this might make sense, but not requiring this could lead to added complexity and security vulnerabilities, so most security models SHOULD require this. Network stress discussion NEW: However, in times of network stress, a secure transport model may not work properly if its underlying security mechanisms (e.g., Network Time Protocol (NTP) or Authentication, Authorization, and Accounting (AAA) protocols or certificate authorities) are not reachable. The User-based Security Model was explicitly designed to not depend upon external network services, and provides its own security services. It is RECOMMENDED that operators provision authPriv USM as a fallback mechanism to supplement any security model or transport model that has external dependencies, so that secure SNMP communications can continue when the external network service is not available. snmpTCPDomain: I think such a domain should be registered when a model is defined to use it. > > At least a reply reply is needed, and possibly some small > clarifications. It's possible these could be handled by RFC Editor > notes. > > David, can you reply and propose text? > > > I hope we can get the RFC Editor notes to address Allison's comments > soon, so I've placed these on the agenda of next Thursday's IESG > telechat (April 23). If we don't have text by Monday, > I'll move them to the next telechat (May 7th). > > Best regards, > Pasi > > From Pasi.Eronen@nokia.com Mon Apr 27 00:06:54 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACD33A6873 for ; Mon, 27 Apr 2009 00:06:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.451 X-Spam-Level: X-Spam-Status: No, score=-6.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1W-R8LTCGPd for ; Mon, 27 Apr 2009 00:06:53 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B00B43A6F02 for ; Mon, 27 Apr 2009 00:06:53 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3R77xVE008686; Mon, 27 Apr 2009 02:08:14 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:08:09 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:08:04 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 27 Apr 2009 09:08:03 +0200 From: To: , Date: Mon, 27 Apr 2009 09:07:58 +0200 Thread-Topic: [Isms] AD review comments for draft-ietf-isms-radius-usage-05 Thread-Index: Acm3VlsPGOPvUjq6SuiGhqG4ZeescAAJft0gA+JjmsA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246CBBD@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F22151E9@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2009 07:08:04.0720 (UTC) FILETIME=[E8DB7F00:01C9C706] X-Nokia-AV: Clean Subject: Re: [Isms] AD review comments for draft-ietf-isms-radius-usage-05 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:06:54 -0000 Dave Nelson wrote: >=20 > Pasi Eronen writes... >=20 > > - Section 2.3 equates "secure transport" with "authPriv". > > While SSHTM requires encryption, can't some future secure > > transport model provide integrity/authentication only? >=20 > Possibly... >=20 > > Perhaps this could be rephrased as "...SNMP over a secure > > transport which provides both integrity and encryption > > (i.e. authPriv)". >=20 > OK. That makes sense. >=20 > > - I'd suggest removing NAS-IP-Address from the table in > > Section 3 (otherwise, we probably should add NAS-IPv6-Address > > and NAS-Identifier, too). >=20 > Hmmm... I'm trying to remember why that attribute was included. > Either suggestion may be OK, but let's think for a while as to > whether there is a use case for this information. The information is certainly needed (and including one of NAS-IP-Address/NAS-IPv6-Address/NAS-Identifier is required by the RADIUS specs)... but I'm not sure if we really need to include it in this table. > > - The table in Section 3 lists Management-Policy-Id, but this > > attribute is not mentioned anywhere else in the document. Perhaps > > the document should just say something like "[I-D.ietf-radext- > > management-authorization] defines Management-Policy-Id and > > Management-Privilege-Level attributes. How these are mapped > > into e.g. an SNMP Access Control Model is beyond the scope of > > this document" ? >=20 > We purged any [veiled] references to access control authorization > from this draft in the very last revision, and this item was missed. > We should probably remove the attribute from the table. Ok. > > - The table shows the User-Password attribute, but it's possible > > that some SNMP transport model could support other authentication > > mechanisms with RADIUS (like EAP or Digest). >=20 > Ahem. I realize there has been a recent change of Security AD > staff, but when this work was beginning we were *firmly* informed > that the applicability statement for EAP prohibited it from being > used for anything except network access authentication, and > certainly not for application authentication, e.g. for SNMP. There > was a bit of a fuss, but it soon subsided. Are you now telling us > this would be OK? Well... no, I'm not saying that. But we already have drafts about SNMP transport models that don't use passwords (although certificate-based authentication doesn't necessarily integrate with RADIUS). > If so, then we could consider adding it as possibility. >=20 > I suppose some *could* use Digest Authentication... >=20 > > Perhaps Section 3 should say something like "SSH integration with > > RADIUS traditionally uses passwords (with the User-Password > > attribute), but other secure transports could use other > > authentication mechanisms (such as EAP or HTTP Digest), and would > > include appropriate authentication attributes instead of > > User-Password" ? >=20 > Yes, that would make sense, assuming we are really allowed to use EAP. Perhaps "SSH integration with RADIUS traditionally uses passwords (with the User-Password attribute), but other secure transports could use other authentication mechanisms, and would include authentication attributes appropriate for that mechanism instead of User-Password"? Best regards, Pasi From Pasi.Eronen@nokia.com Mon Apr 27 00:32:29 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9FFF3A6962 for ; Mon, 27 Apr 2009 00:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBIbn+S0PrpB for ; Mon, 27 Apr 2009 00:32:29 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 94A703A6827 for ; Mon, 27 Apr 2009 00:32:28 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3R7Wokb028595 for ; Mon, 27 Apr 2009 10:33:42 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:33:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:33:34 +0300 Received: from nok-am1mhub-07.mgdnok.nokia.com (65.54.30.14) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 09:33:33 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-07.mgdnok.nokia.com ([65.54.30.14]) with mapi; Mon, 27 Apr 2009 09:33:34 +0200 From: To: Date: Mon, 27 Apr 2009 09:33:32 +0200 Thread-Topic: IETF Last Call summary for radius-usage Thread-Index: AcnHCnd9jqURXG1iS9eUjNFCunV9AA== Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246CC25@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2009 07:33:34.0676 (UTC) FILETIME=[78C84140:01C9C70A] X-Nokia-AV: Clean Subject: [Isms] IETF Last Call summary for radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:32:29 -0000 The IETF Last Call for radius-usage has ended. According to my=20 notes, we got the following comments: 1) My AD review comments: http://www.ietf.org/mail-archive/web/isms/current/msg03474.html http://www.ietf.org/mail-archive/web/isms/current/msg03475.html http://www.ietf.org/mail-archive/web/isms/current/msg03500.html It seems couple of semi-editorial edits are be needed (but nothing significant). 2) Miguel Garcia's Gen-ART review: http://www.ietf.org/mail-archive/web/isms/current/msg03496.html Very minor nits; could be handled now if we update the draft anyway, or later during RFC Editor processing. 3) IANA review (all OK, no IANA actions): https://datatracker.ietf.org/idtracker/draft-ietf-isms-radius-usage/comment= /94065/ David, could you either prepare set of RFC Editor notes, or submit=20 an updated draft soon? (If we can do this in couple of days, I could put this on the agenda of May 7th telechat together with the other ISMS documents.) Best regards, Pasi From Pasi.Eronen@nokia.com Mon Apr 27 00:35:27 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 268013A6955 for ; Mon, 27 Apr 2009 00:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.453 X-Spam-Level: X-Spam-Status: No, score=-7.453 tagged_above=-999 required=5 tests=[AWL=1.146, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH+wapjs2bTB for ; Mon, 27 Apr 2009 00:35:25 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6E3C33A6A31 for ; Mon, 27 Apr 2009 00:35:25 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n3R7aFKI004298; Mon, 27 Apr 2009 02:36:45 -0500 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:36:36 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Apr 2009 10:36:35 +0300 Received: from nok-am1mhub-06.mgdnok.nokia.com (65.54.30.10) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Mon, 27 Apr 2009 09:36:35 +0200 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-06.mgdnok.nokia.com ([65.54.30.10]) with mapi; Mon, 27 Apr 2009 09:36:35 +0200 From: To: , Date: Mon, 27 Apr 2009 09:36:34 +0200 Thread-Topic: IETF Last Call summary for tmsm/tsm/secshell #1, #3, #4, #5 Thread-Index: Acm+cuRpqhIFau9ZRv2M6xqPp+i0KwFG9QQgAN8HLBA= Message-ID: <808FD6E27AD4884E94820BC333B2DB7727F246CC30@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB7727F2356402@NOK-EUMSG-01.mgdnok.nokia.com> <003e01c9c3cd$4585fa10$0600a8c0@china.huawei.com> In-Reply-To: <003e01c9c3cd$4585fa10$0600a8c0@china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 27 Apr 2009 07:36:35.0797 (UTC) FILETIME=[E4BD2050:01C9C70A] X-Nokia-AV: Clean Subject: Re: [Isms] IETF Last Call summary for tmsm/tsm/secshell #1, #3, #4, #5 X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:35:27 -0000 Hi David, Everything here looks good to me. Can you submit an updated draft? Best regards, Pasi > -----Original Message----- > From: ext David Harrington [mailto:ietfdbh@comcast.net] > Sent: 23 April, 2009 07:38 > To: Eronen Pasi (Nokia-NRC/Helsinki); isms@ietf.org > Cc: 'Allison Mankin'; gen-art@ietf.org; ben@estacado.net; vkg@alcatel- > lucent.com; tsv-dir@ietf.org > Subject: RE: IETF Last Call summary for tmsm/tsm/secshell #1, #3, #4, > #5 >=20 > Last Call: draft-ietf-isms-tmsm and > draft-ietf-isms-transport-security-model > Transport Subsystem for the Simple Network Management Protocol (SNMP) >=20 > 1) Juergen commented MIB module names >=20 > RFC4181 recommenda a naming convention where the module name, module > identity, and prefixes are consistent: >=20 > - The module name should be of the form XXX-MIB (or XXX-TC-MIB for a > module with TCs only), where XXX is a unique prefix (usually all > caps with hyphens for separators) that is not used by any > existing > module. For example, the module for managing optical interfaces > [RFC3591] uses the prefix OPT-IF and has module name OPT-IF-MIB. >=20 > - The descriptor associated with the MODULE-IDENTITY invocation > should be of the form xxxMIB, xxxMib, or xxxMibModule, where xxx > is > a mixed-case version of XXX starting with a lowercase letter and > without any hyphens. For example, the OPT-IF-MIB uses the prefix > optIf, and the descriptor associated with its MODULE-IDENTITY > invocation is optIfMibModule. >=20 > - Other descriptors within the MIB module should start with the > same > prefix xxx. OPT-IF-MIB uses the prefix optIf for all > descriptors. >=20 > I don't think we should change SNMP-TSM-MIB to SNMP-TRANSPORT-SM-MIB. > I don't see significant benefit in this change. >=20 > I do not object to changing SSHTM-MIB to SNMP-SSHTM-MIB or > SNMPSSH-MIB. >=20 > > 3) Vijay Gurbani's Gen-ART review for tmsm: > > http://www.ietf.org/mail-archive/web/gen-art/current/msg03973.html > > > > One nit about white space/indentation -- will get fixed by > > the RFC editor when they assign the RFC numbers. >=20 > I believe this is related to the version of xml2rfc in use. It seems > to vary after xml2rfc upgrades. When the RFC Editor does their final > pass, it should be fine. >=20 > > > > > > 4) Ben Campbell's Gen-ART review for tsm: > > http://www.ietf.org/mail-archive/web/gen-art/current/msg03952.html > > > > Couple of editorial comments, all extremely minor. I'd suggest > > handling these during RFC Editor stage. >=20 > The "*" is part of the official name of the SNMPv2 variation. >=20 > reference to USM provided. >=20 > section 4.2 first two paragraphs ARE an ordered sequence - note that > 3) follows a ways down in the procedures. >=20 > pointer to smi-registry provided for mib-2 >=20 > removed open issues and change log sections >=20 > added pointer to secshell document for port assignment >=20 > > > > > > 5) Allison Mankin's transport directorate review for tmsm: > > http://www.ietf.org/mail-archive/web/isms/current/msg03490.html >=20 > > A top-level comment/question has to do with the draft's use of the > TDomain/TAddress textual convention from RFC 2579, instead of RFC > 3419. >=20 > NEW: > This document uses TDomain textual conventions for the SNMP-internal > MIB modules defined here for compatibility with the RFC3413 MIB > modules and the RFC3411 Abstract Service Interfaces. >=20 > OLD: > with no significant effort...other than identifying requirements and > verifying the quality of service being provided. > NEW: > The individual therefore achieves the desired security, with > significantly less effort on his part except identifying > requirements and verifying the quality of service being provided. >=20 > reference for transport mappings added >=20 > OLD: > Transport Models MAY support sending multiple SNMP messages through > the same tunnel. > NEW: > While the Community Security Models and the User-based > Security Model establish a security association for each SNMP message, > newer Transport Models MAY support sending multiple SNMP messages > through the same tunnel to amortize the costs of establishing a > security association. >=20 > > This paragraph describes a heuristic to get around the fact that > "the transport subsystem does not have access to the pduType." > What do pduTypes include? What's a useful example of this hint > that makes this reversal worth including? > NEW: > ... the transport subsystem does not have access to the pduType (i.e., > the SNMP operation type) ... > NEW: > For example, the SNMP-TARGET-MIB and SNMP-NOTIFICATION-MIB are used to > configure notification originators with the destination port to > which > SNMPv2-Trap PDUs or Inform PDUs should be sent, but the transport > subsystem never looks inside the PDU. >=20 > OLD: > The SNMPv3 WG decided that this should be a SHOULD architecturally, > and it is a security-model-specific decision whether to REQUIRE this. > NEW: > The SNMPv3 WG decided that this should be a SHOULD architecturally, > and it is a security-model-specific decision whether to REQUIRE this. > The architecture does not mandate this requirement to allow for future > security models where this might make sense, but not requiring this > could lead to added complexity and security vulnerabilities, so most > security models SHOULD require this. >=20 > Network stress discussion > NEW: > However, in times of network stress, a secure transport model may not > work > properly if its underlying security mechanisms (e.g., Network Time > Protocol (NTP) or Authentication, Authorization, and Accounting > (AAA) protocols or certificate authorities) are not reachable. The > User-based Security > Model was explicitly designed to not depend upon external network > services, and provides its own security services. It is RECOMMENDED > that operators provision authPriv USM as a fallback mechanism to > supplement > any security model or transport model that has external dependencies, > so that secure SNMP > communications can continue when the external network service is not > available. >=20 > snmpTCPDomain: I think such a domain should be registered when a model > is defined to use it. >=20 > > > > At least a reply reply is needed, and possibly some small > > clarifications. It's possible these could be handled by RFC Editor > > notes. > > > > David, can you reply and propose text? > > > > > > I hope we can get the RFC Editor notes to address Allison's comments > > soon, so I've placed these on the agenda of next Thursday's IESG > > telechat (April 23). If we don't have text by Monday, > > I'll move them to the next telechat (May 7th). > > > > Best regards, > > Pasi > > > > From j.schoenwaelder@jacobs-university.de Mon Apr 27 00:49:05 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65DC03A6853 for ; Mon, 27 Apr 2009 00:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EkxWZkrunLFD for ; Mon, 27 Apr 2009 00:49:04 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id E1FA23A67D2 for ; Mon, 27 Apr 2009 00:49:03 -0700 (PDT) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9CC53C0057; Mon, 27 Apr 2009 09:50:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ClTHMwcl4hca; Mon, 27 Apr 2009 09:50:23 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4022C0052; Mon, 27 Apr 2009 09:50:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DC51DAC012D; Mon, 27 Apr 2009 09:50:03 +0200 (CEST) Date: Mon, 27 Apr 2009 09:50:03 +0200 From: Juergen Schoenwaelder To: "Pasi.Eronen@nokia.com" Message-ID: <20090427075003.GD9485@elstar.local> Mail-Followup-To: "Pasi.Eronen@nokia.com" , "isms@ietf.org" References: <808FD6E27AD4884E94820BC333B2DB7727F246CC25@NOK-EUMSG-01.mgdnok.nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F246CC25@NOK-EUMSG-01.mgdnok.nokia.com> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: "isms@ietf.org" Subject: Re: [Isms] IETF Last Call summary for radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 07:49:05 -0000 On Mon, Apr 27, 2009 at 09:33:32AM +0200, Pasi.Eronen@nokia.com wrote: > David, could you either prepare set of RFC Editor notes, or submit > an updated draft soon? I would prefer to have an updated ID in place since this way we can all easily look at the changes using the wonderful diff tools we now have and there are less things to track later on. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From d.b.nelson@comcast.net Mon Apr 27 05:52:40 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BF3D3A6D61 for ; Mon, 27 Apr 2009 05:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lP6C01eK2QS for ; Mon, 27 Apr 2009 05:52:39 -0700 (PDT) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by core3.amsl.com (Postfix) with ESMTP id 5813A3A6C2A for ; Mon, 27 Apr 2009 05:52:39 -0700 (PDT) Received: from OMTA11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id kc5r1b0040mlR8UA8cu0Qx; Mon, 27 Apr 2009 12:54:00 +0000 Received: from NEWTON603 ([71.232.143.198]) by OMTA11.emeryville.ca.mail.comcast.net with comcast id kcty1b00L4H2mdz8Xctzsd; Mon, 27 Apr 2009 12:54:00 +0000 From: "Dave Nelson" To: , References: <808FD6E27AD4884E94820BC333B2DB7727F246CC25@NOK-EUMSG-01.mgdnok.nokia.com> Date: Mon, 27 Apr 2009 08:54:08 -0400 Message-ID: <5059F07C375C4CB290963E8DB22DB0F8@NEWTON603> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <808FD6E27AD4884E94820BC333B2DB7727F246CC25@NOK-EUMSG-01.mgdnok.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Thread-Index: AcnHCnd9jqURXG1iS9eUjNFCunV9AAALGluw Subject: Re: [Isms] IETF Last Call summary for radius-usage X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 12:52:40 -0000 > David, could you either prepare set of RFC Editor notes, or submit > an updated draft soon? Based on Juergen's preference, I'll submit a revised draft. > (If we can do this in couple of days, I could put this on the > agenda of May 7th telechat together with the other ISMS documents.) I should be able to work on that tonight... From root@core3.amsl.com Mon Apr 27 06:30:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DE2103A6F81; Mon, 27 Apr 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427133001.DE2103A6F81@core3.amsl.com> Date: Mon, 27 Apr 2009 06:30:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-transport-security-model-13.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Security Model for SNMP Author(s) : D. Harrington, W. Hardaker Filename : draft-ietf-isms-transport-security-model-13.txt Pages : 28 Date : 2009-04-27 This memo describes a Transport Security Model for the Simple Network Management Protocol. This memo also defines a portion of the Management Information Base (MIB) for monitoring and managing the Transport Security Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-transport-security-model-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-transport-security-model-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-27061913.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Apr 27 06:30:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ED0BD28C0D9; Mon, 27 Apr 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427133001.ED0BD28C0D9@core3.amsl.com> Date: Mon, 27 Apr 2009 06:30:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-tmsm-17.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Transport Subsystem for the Simple Network Management Protocol (SNMP) Author(s) : D. Harrington, J. Schoenwaelder Filename : draft-ietf-isms-tmsm-17.txt Pages : 36 Date : 2009-04-27 This document defines a Transport Subsystem, extending the Simple Network Management Protocol (SNMP) architecture defined in RFC 3411. This document defines a subsystem to contain Transport Models, comparable to other subsystems in the RFC3411 architecture. As work is being done to expand the transports to include secure transports such as SSH and TLS, using a subsystem will enable consistent design and modularity of such Transport Models. This document identifies and describes some key aspects that need to be considered for any Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-tmsm-17.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-tmsm-17.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-27061933.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Apr 27 06:30:02 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 088B928C11F; Mon, 27 Apr 2009 06:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427133002.088B928C11F@core3.amsl.com> Date: Mon, 27 Apr 2009 06:30:02 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-secshell-16.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Secure Shell Transport Model for SNMP Author(s) : D. Harrington, et al. Filename : draft-ietf-isms-secshell-16.txt Pages : 44 Date : 2009-04-27 This memo describes a Transport Model for the Simple Network Management Protocol, using the Secure Shell protocol (SSH). This memo also defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP based internets. In particular it defines objects for monitoring and managing the Secure Shell Transport Model for SNMP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-secshell-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-secshell-16.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-27061944.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Mon Apr 27 12:47:36 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7883A6A24 for ; Mon, 27 Apr 2009 12:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BajyXXlyRR-v for ; Mon, 27 Apr 2009 12:47:36 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 3E72628C19E for ; Mon, 27 Apr 2009 12:47:31 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89D20C06DB; Mon, 27 Apr 2009 21:48:51 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ia2zEN+GS2hm; Mon, 27 Apr 2009 21:48:49 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80DC3C06DA; Mon, 27 Apr 2009 21:48:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4346FAC1259; Mon, 27 Apr 2009 21:48:29 +0200 (CEST) Date: Mon, 27 Apr 2009 21:48:29 +0200 From: Juergen Schoenwaelder To: isms@ietf.org, Allison Mankin , Ben Campbell , "Vijay K. Gurbani" Message-ID: <20090427194829.GC10764@elstar.local> Mail-Followup-To: isms@ietf.org, Allison Mankin , Ben Campbell , "Vijay K. Gurbani" , Pasi Eronen MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Pasi Eronen Subject: [Isms] revised core isms documents posted - please check X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:47:37 -0000 Hi, a new set of the core ISMS documents has been posted: http://tools.ietf.org/html/draft-ietf-isms-tmsm-17 http://tools.ietf.org/html/draft-ietf-isms-transport-security-model-13 http://tools.ietf.org/html/draft-ietf-isms-secshell-16 These documents incorporate comments we received as part of the IETF last call process. Please check the changes and let us know as soon as possible if you think a comment has not been sufficiently addressed or errors have been introduced. These documents are currently scheduled for the IESG meeting on May 7th. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From root@core3.amsl.com Wed Apr 29 11:00:01 2009 Return-Path: X-Original-To: isms@ietf.org Delivered-To: isms@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id D2A6F3A71AA; Wed, 29 Apr 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090429180001.D2A6F3A71AA@core3.amsl.com> Date: Wed, 29 Apr 2009 11:00:01 -0700 (PDT) Cc: isms@ietf.org Subject: [Isms] I-D Action:draft-ietf-isms-radius-usage-06.txt X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 18:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Remote Authentication Dial-In User Service (RADIUS) Usage for Simple Network Management Protocol (SNMP) Transport Models Author(s) : K. Narayan, D. Nelson Filename : draft-ietf-isms-radius-usage-06.txt Pages : 14 Date : 2009-04-29 This memo describes the use of a Remote Authentication Dial-In User Service (RADIUS) authentication and authorization service with Simple Network Management Protocol (SNMP) secure Transport Models to authenticate users and authorize creation of secure transport sessions. While the recommendations of this memo are generally applicable to a broad class of SNMP Transport Models, the examples focus on the Secure Shell Transport Model. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-radius-usage-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-isms-radius-usage-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-29105706.I-D@ietf.org> --NextPart-- From j.schoenwaelder@jacobs-university.de Thu Apr 30 08:17:19 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 224D83A67D4 for ; Thu, 30 Apr 2009 08:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QAFajYjvmUXe for ; Thu, 30 Apr 2009 08:17:14 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8FB703A6D1E for ; Thu, 30 Apr 2009 08:17:14 -0700 (PDT) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 953B7C0146 for ; Thu, 30 Apr 2009 17:18:36 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RtvzzSBf3ZUE; Thu, 30 Apr 2009 17:18:35 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E8E23C013D; Thu, 30 Apr 2009 17:18:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D72E9AC4752; Thu, 30 Apr 2009 17:18:16 +0200 (CEST) Date: Thu, 30 Apr 2009 17:18:16 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20090430151816.GA14264@elstar.local> Mail-Followup-To: isms@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.19 (2009-01-05) Subject: [Isms] rechartering status X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:17:19 -0000 Hi, the WG wants to recharter and I think it is important now to make progress on this (one reason is the upcoming WG meeting request deadline for the Stockholm IETF). While there was some proposed charter text floating around, I am not sure what the final version was and who supports it and is willing to work on/review the documents (other than the authors/editors). Personally, I like to have an initial draft available for the RADIUS work on which the WG work can be based. It is not required to have such an ID, but I believe it helps to have such a starting point since it makes clear what the scope/details of the work to do actually are. In addition, it would be nice if people interested in the DTLS/TLS work could take some time to review Wes' ID and send feedback and questions to this list so that we get a feel of the amount of work left to be done on this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From wjhns1@hardakers.net Thu Apr 30 08:41:45 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB4983A6834 for ; Thu, 30 Apr 2009 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngxaooxgoa4K for ; Thu, 30 Apr 2009 08:41:45 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 071063A6D73 for ; Thu, 30 Apr 2009 08:41:31 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id 4106939A0F4 for ; Thu, 30 Apr 2009 08:42:54 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta References: <20090430151816.GA14264@elstar.local> Date: Thu, 30 Apr 2009 08:42:54 -0700 In-Reply-To: <20090430151816.GA14264@elstar.local> (Juergen Schoenwaelder's message of "Thu, 30 Apr 2009 17:18:16 +0200") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [Isms] Ismsrechartering status X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:41:46 -0000 >>>>> On Thu, 30 Apr 2009 17:18:16 +0200, Juergen Schoenwaelder said: JS> While there was some proposed charter text floating around, I am not JS> sure what the final version was I'll re-post it later. I think the last version was fairly well agreed upon by everyone involved. I think it's ready to go. JS> and who supports it and is willing to work on/review the documents JS> (other than the authors/editors). Calling for participants is certainly advisable, but there seemed to be enough people in the room at the WG meeting (if you read minutes, they were counted I believe) that both documents had a number of participants willing to read/review. The radius document was lacking people willing to edit, but I think they've stepped up since then so that's good to go as well (IMHO, of course). JS> In addition, it would be nice if people interested in the DTLS/TLS JS> work could take some time to review Wes' ID and send feedback and JS> questions to this list so that we get a feel of the amount of work JS> left to be done on this document. FYI, I've actually received multiple review comments and incorporated them either into previous versions or the current unreleased-version already. I was actually planning on publishing a new version soon, but was waiting to see what happened with the charter to see if I should publish it as a WG document or another personal copy. Let me know. -- Wes Hardaker Cobham Analytic Solutions From wjhns1@hardakers.net Thu Apr 30 13:32:26 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58393A6C37 for ; Thu, 30 Apr 2009 13:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsl7-nWFsX-F for ; Thu, 30 Apr 2009 13:32:25 -0700 (PDT) Received: from wes.hardakers.net (dcn236-43.dcn.davis.ca.us [168.150.236.43]) by core3.amsl.com (Postfix) with ESMTP id 91A233A67F7 for ; Thu, 30 Apr 2009 13:32:25 -0700 (PDT) Received: from localhost (wlap.dyn.hardakers.net [127.0.0.1]) by wes.hardakers.net (Postfix) with ESMTP id C342739A0F1 for ; Thu, 30 Apr 2009 13:33:46 -0700 (PDT) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 30 Apr 2009 13:33:46 -0700 Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) XEmacs/21.4.21 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 20:32:26 -0000 Enclosed is the last charter text (which received no comments after the last submission). The only outstanding question I can think of is whether there was agreement to include TLS into the DTLS draft or not. Everyone in the discussion seemed to be "on the fence" so I didn't include it in the text below, taking that as "not consensus at this time". If people wish TLS to be taken into account, now is the time to speak up. Integrated Security Model for SNMP (isms) Last Modified: XXXX Additional information is available at tools.ietf.org/wg/isms Chair(s): * Juergen Schoenwaelder Security Area Director(s): * Tim Polk * Pasi Eronen Security Area Advisor: * Pasi Eronen Mailing Lists: General Discussion: isms@ietf.org To Subscribe: isms-request@ietf.org In Body: in body: (un)subscribe Archive: http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html Description of Working Group: The Simple Network Management Protocol version 3 (SNMPv3) provides message security services through the security subsystem. Previously the ISMS Working Group defined a Transport Subsystem definition, a new Transport Security Model, and a Secure Shell Transport Model and a method for authenticating SNMPv3 users via the Remote Authentication Dial-In User Service (RADIUS). The initial body of work to be tackled by the working group involved only these pieces. Additional work on other transport models and other security extensions were to wait until the initial transport architecture and defining documents were completed. It is now possible to authenticate SNMPv3 messages via a RADIUS when those messages are sent over the newly defined SSH transport. However, it still remains impossible to centrally authorize a given SNMP transaction as on-device pre-existing authorization configuration is still required. In order to leverage a centralized RADIUS service to its full extent, the access control decision in the Access Control Subsystem needs to be based on authorization information received from RADIUS as well. The result will be an extension to the View-based Access Control Model (VACM), to obtain authorization information for an authenticated principal from RADIUS. The authorization information will be limited to mapping the authenticated principal to existing access control polices, defining session timeouts, and similar session parameters. This mechanism will not provision the detailed access control rules. Additionally, new work will be undertaken to define a DTLS-based transport that can offer support for environments that prefer certificate authentication and/or datagram-based transmissions. Certificate based authentication is desirable for many environments with a centralized authentication service. Datagram based transports may be desired for environments where TCP performance suffers because of network anomalies (e.g. high packet loss rates). A DTLS-based transport would offer a solution that addresses both of these situations. The current goal of the ISMS working group is two-fold: to develop a method for allowing for access control decisions to be based on information provide by an AAA provisioning service and to develop a DTLS-based Transport Model. The new work must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). The working group will cover the following work items: - Specify a mechanism to support centralization of SNMPv3 Access Control decisions by means of a RADIUS-provisioned username-to-groupname dynamic mapping, that would provide a binding between a user and preconfigured VACM policies via dynamic additions to the securityToGroupname table. Additionally, specify a time limit for access decisions, and such a time limit should be used to garbage collect expired dynamic securityToGroup mappings. - Specify the DTLS transport for SNMP. Goals and Milestones: Jul 2009 Publish initial documentation on the DTLS transport for SNMP Jul 2009 Publish initial documentation for the centralized access control Jan 2010 Submit documentation on the DTLS transport for SNMP to IESG Jan 2010 Submit documentation for the centralized access control to IESG -- Wes Hardaker Cobham Analytic Solutions From blueroofmusic@gmail.com Thu Apr 30 18:33:09 2009 Return-Path: X-Original-To: isms@core3.amsl.com Delivered-To: isms@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2426C3A69AE for ; Thu, 30 Apr 2009 18:33:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PU9jyWg0En9R for ; Thu, 30 Apr 2009 18:33:07 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 39B9A3A67E6 for ; Thu, 30 Apr 2009 18:33:07 -0700 (PDT) Received: by ewy24 with SMTP id 24so2250479ewy.37 for ; Thu, 30 Apr 2009 18:34:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pqRjNVYZzxeN59QpJ/gZbM/BaevOzXC3v4TaJ1mgvRc=; b=u4tOvdO4V5k7XJtTami7GKyhld2mA+9Eedw1J3e7HOauEtXU+2ksAdmoa3WRgk3rRa pUc9w+hb56m4OTRbNMUtBt4lWeip+jN1T/LhjGUV2axLsS5WzdRdK8OatW0VI/xQwpbo IMCLAP7zONhVbFZvWlAhukgVI2+4IVPWccokA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=T5asxkglDTkG9b/KeO0/HcCwvGy/+b0Z+/ObVPu703dSpk/eXMfhQaFHlZMk8IstUp cbF4o46IG71fTzhvipYP7vQNt9eWDDJ9FkhkJrRSb6mzVKY3PaldHQ3Oe+OzvD4650AI 8RnowRv74ext1uj2CfkdjgIaxh5Xe2GaqA38s= MIME-Version: 1.0 Received: by 10.210.43.11 with SMTP id q11mr2413518ebq.59.1241141669635; Thu, 30 Apr 2009 18:34:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 30 Apr 2009 21:34:29 -0400 Message-ID: From: Ira McDonald To: Wes Hardaker , Ira McDonald Content-Type: multipart/alternative; boundary=000e0ce0d19455a6720468cfd0fb Cc: isms@ietf.org Subject: Re: [Isms] Latest Proposed Charter Text X-BeenThere: isms@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 01:33:09 -0000 --000e0ce0d19455a6720468cfd0fb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I favor including TLS. I think the commonality of DTLS and TLS (by design) trumps keeping them separate topics (and I-Ds). For long sessions in healthy networks, TLS is better. For sticky times and quick fixes, DTLS has advantages. Cheers, - Ira Ira McDonald (Musician / Software Architect) Chair - Linux Foundation Open Printing WG Blue Roof Music/High North Inc email: blueroofmusic@gmail.com winter: 579 Park Place Saline, MI 48176 734-944-0094 summer: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Apr 30, 2009 at 4:33 PM, Wes Hardaker wrote: > > Enclosed is the last charter text (which received no comments after the > last submission). > > The only outstanding question I can think of is whether there was > agreement to include TLS into the DTLS draft or not. Everyone in the > discussion seemed to be "on the fence" so I didn't include it in the > text below, taking that as "not consensus at this time". If people wish > TLS to be taken into account, now is the time to speak up. > > > > Integrated Security Model for SNMP (isms) > > Last Modified: XXXX > > Additional information is available at tools.ietf.org/wg/isms > > Chair(s): > * Juergen Schoenwaelder > > Security Area Director(s): > * Tim Polk > * Pasi Eronen > > Security Area Advisor: > * Pasi Eronen > > Mailing Lists: > > General Discussion: isms@ietf.org > To Subscribe: isms-request@ietf.org > In Body: in body: (un)subscribe > Archive: > http://www.ietf.org/mail-archive/working-groups/isms/current/maillist.html > > Description of Working Group: > > The Simple Network Management Protocol version 3 (SNMPv3) provides > message security services through the security subsystem. Previously > the ISMS Working Group defined a Transport Subsystem definition, a new > Transport Security Model, and a Secure Shell Transport Model and a > method for authenticating SNMPv3 users via the Remote Authentication > Dial-In User Service (RADIUS). The initial body of work to be > tackled by the working group involved only these pieces. Additional > work on other transport models and other security extensions were to > wait until the initial transport architecture and defining documents > were completed. > > It is now possible to authenticate SNMPv3 messages via a RADIUS when > those messages are sent over the newly defined SSH transport. However, > it still remains impossible to centrally authorize a given SNMP > transaction as on-device pre-existing authorization configuration is > still required. In order to leverage a centralized RADIUS service to > its full extent, the access control decision in the Access Control > Subsystem needs to be based on authorization information received from > RADIUS as well. The result will be an extension to the View-based > Access Control Model (VACM), to obtain authorization information for an > authenticated principal from RADIUS. The authorization information will > be limited to mapping the authenticated principal to existing access > control polices, defining session timeouts, and similar session > parameters. This mechanism will not provision the detailed access > control rules. > > Additionally, new work will be undertaken to define a DTLS-based > transport that can offer support for environments that prefer > certificate authentication and/or datagram-based transmissions. > Certificate based authentication is desirable for many environments with > a centralized authentication service. Datagram based transports may be > desired for environments where TCP performance suffers because of > network anomalies (e.g. high packet loss rates). A DTLS-based transport > would offer a solution that addresses both of these situations. > > The current goal of the ISMS working group is two-fold: to develop a > method for allowing for access control decisions to be based on > information provide by an AAA provisioning service and to develop a > DTLS-based Transport Model. > > The new work must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). > > The working group will cover the following work items: > > - Specify a mechanism to support centralization of SNMPv3 Access > Control decisions by means of a RADIUS-provisioned > username-to-groupname dynamic mapping, that would provide a binding > between a user and preconfigured VACM policies via dynamic additions > to the securityToGroupname table. Additionally, specify a time limit > for access decisions, and such a time limit should be used to > garbage collect expired dynamic securityToGroup mappings. > > - Specify the DTLS transport for SNMP. > > Goals and Milestones: > Jul 2009 Publish initial documentation on the DTLS transport for > SNMP > Jul 2009 Publish initial documentation for the centralized access > control > Jan 2010 Submit documentation on the DTLS transport for SNMP to IESG > Jan 2010 Submit documentation for the centralized access control to > IESG > > -- > Wes Hardaker > Cobham Analytic Solutions > _______________________________________________ > Isms mailing list > Isms@ietf.org > https://www.ietf.org/mailman/listinfo/isms > --000e0ce0d19455a6720468cfd0fb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I favor including TLS.

I think the commonality of DTLS an= d TLS (by design)
trumps keeping them separate topics (and I-Ds).
For long sessions in healthy networks, TLS is better.

For sticky ti= mes and quick fixes, DTLS has advantages.

Cheers,
- Ira

Ira McDonald (Musician / Software= Architect)
Chair - Linux Foundation Open Printing WG
Blue Roof Music= /High North Inc
email: bluero= ofmusic@gmail.com
winter:
=A0579 Park Place =A0Saline, MI =A048176
=A0734-944-0094summer:
=A0PO Box 221 =A0Grand Marais, MI 49839
=A0906-494-2434

On Thu, Apr 30, 2009 at 4:33 PM, Wes Har= daker <wjhns1@= hardakers.net> wrote:

Enclosed is the last charter text (which received no comments after the
last submission).

The only outstanding question I can think of is whether there was
agreement to include TLS into the DTLS draft or not. =A0Everyone in the
discussion seemed to be "on the fence" so I didn't include it= in the
text below, taking that as "not consensus at this time". =A0If pe= ople wish
TLS to be taken into account, now is the time to speak up.



Integrated Security Model for SNMP (isms)

Last Modified: XXXX

Additional information is available at tools.ietf.org/wg/isms

Chair(s):
* Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>

Security Area Director(s):
* Tim Polk <tim.polk@nist.gov&g= t;
* Pasi Eronen <pasi.eronen@noki= a.com>

Security Area Advisor:
* Pasi Eronen <pasi.eronen@noki= a.com>

Mailing Lists:

General Discussion: isms@ietf.org
To Subscribe: isms-request@ietf.or= g
In Body: in body: (un)subscribe
Archive: http://www.ietf.org/mail-archive/wor= king-groups/isms/current/maillist.html

Description of Working Group:

The Simple Network Management Protocol version 3 (SNMPv3) provides
message security services through the security subsystem. =A0Previously
the ISMS Working Group defined a Transport Subsystem definition, a new
Transport Security Model, and a Secure Shell Transport Model and a
method for authenticating SNMPv3 users via the Remote Authentication
Dial-In User Service (RADIUS). =A0The initial body of work to be
tackled by the working group involved only these pieces. =A0 Additional
work on other transport models and other security extensions were to
wait until the initial transport architecture and defining documents
were completed.

It is now possible to authenticate SNMPv3 messages via a RADIUS when
those messages are sent over the newly defined SSH transport. =A0However, it still remains impossible to centrally authorize a given SNMP
transaction as on-device pre-existing authorization configuration is
still required. =A0In order to leverage a centralized RADIUS service to
its full extent, the access control decision in the Access Control
Subsystem needs to be based on authorization information received from
RADIUS as well. =A0The result will be an extension to the View-based
Access Control Model (VACM), to obtain authorization information for an
authenticated principal from RADIUS. =A0The authorization information will<= br> be limited to mapping the authenticated principal to existing access
control polices, defining session timeouts, and similar session
parameters. =A0This mechanism will not provision the detailed access
control rules.

Additionally, new work will be undertaken to define a DTLS-based
transport that can offer support for environments that prefer
certificate authentication and/or datagram-based transmissions.
Certificate based authentication is desirable for many environments with a centralized authentication service. =A0Datagram based transports may be desired for environments where TCP performance suffers because of
network anomalies (e.g. high packet loss rates). =A0A DTLS-based transport<= br> would offer a solution that addresses both of these situations.

The current goal of the ISMS working group is two-fold: to develop a
method for allowing for access control decisions to be based on
information provide by an AAA provisioning service and to develop a
DTLS-based Transport Model.

The new work must not modify any other aspects of SNMPv3 protocol as
defined in STD 62 (e.g., it must not create new PDU types).

The working group will cover the following work items:

=A0- Specify a mechanism to support centralization of SNMPv3 Access
=A0 =A0Control decisions by means of a RADIUS-provisioned
=A0 =A0username-to-groupname dynamic mapping, that would provide a binding=
=A0 =A0between a user and preconfigured VACM policies via dynamic addition= s
=A0 =A0to the securityToGroupname table. Additionally, specify a time limi= t
=A0 =A0for access decisions, and such a time limit should be used to
=A0 =A0garbage collect expired dynamic securityToGroup mappings.

=A0- Specify the DTLS transport for SNMP.

Goals and Milestones:
Jul 2009 =A0 =A0 =A0 =A0Publish initial documentation on the DTLS transport= for SNMP
Jul 2009 =A0 =A0 =A0 =A0Publish initial documentation for the centralized a= ccess control
Jan 2010 =A0 =A0 =A0 =A0Submit documentation on the DTLS transport for SNMP= to IESG
Jan 2010 =A0 =A0 =A0 =A0Submit documentation for the centralized access con= trol to IESG

--
Wes Hardaker
Cobham Analytic Solutions
_______________________________________________
Isms mailing list
Isms@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/isms

--000e0ce0d19455a6720468cfd0fb--