From isms-bounces@lists.ietf.org Mon Aug 01 05:50:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWwP-000724-77; Mon, 01 Aug 2005 05:50:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWXJ-0001cy-7x for isms@megatron.ietf.org; Mon, 01 Aug 2005 05:24:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08384 for ; Mon, 1 Aug 2005 05:24:39 -0400 (EDT) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzX3X-0006OV-MA for isms@ietf.org; Mon, 01 Aug 2005 05:58:01 -0400 Received: from pc6 (1Cust99.tnt110.lnd4.gbr.da.uu.net [62.188.174.99]) by astro.systems.pipex.net (Postfix) with SMTP id 142C9E000122; Mon, 1 Aug 2005 10:24:17 +0100 (BST) Message-ID: <004e01c59672$429004e0$0601a8c0@pc6> From: "Tom Petch" To: References: <20050727213207.GA3262@boskop.local><20050728065138.A5745D5EE@hermes.iu-bremen.de> <20050728075007.GA731@boskop.local> Subject: Re: [Isms] securityName Date: Mon, 1 Aug 2005 10:00:56 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ---- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: ; "'Dave Harrington'" Sent: Thursday, July 28, 2005 9:50 AM Subject: Re: [Isms] securityName > On Thu, Jul 28, 2005 at 02:51:28AM -0400, David B Harrington wrote: > > > -- requirements for a hack -- > I see these options: > > a) provide a mechanism to retrieve (at least parts of a) VACM configuration > from an AAA server (not in our charter) > > b) do a N:1 mapping from user identities into security names in the > ISMS security model (rather than doing a 1:1 mapping like USM) > > c) generally change the SNMP architecture providing new or extended > ASIs to actually make this mapping something between the security > model and the access control model (not in our charter) I am not sure that this is not in our charter. To quote TMSM "The RFC3411 ASIs would not need to be changed since the SNMPv3 WG expected that additional parameters could be passed for value-add features of specific implementations" Passing the group name in isAccessAllowed adds substantial value when it reduces the need to maintain AAA information in the 'agent'. OK, I exaggerate slightly but I think it hard to draw the line between adding references to a tmStateReference that contains session and master keys and adding a reference to a something that contains a securityName to vacmGroup mapping. In which case, option a) is wide open as well eg by allowing the 'manager' to retrieve the mapping and pass it over a secure pipe to the TMSM. Tom Petch > > There are now technical pros and cons for all these options and there > are process (charter) issues to consider. There was also the other > option (not sure it really counts as an option): > > d) provide a wildcard mapping extension to VACM which can be exploited > to map all security name with the same security level and security > model together into a vacm group (works only on simple setups where > you basically do not distinguish between different MIB views for > authenticated users - but perhaps this is a low hanging fruit that > covers most existing VACM configurations anyway) > > Any other options to consider which I forgot to list? > > /js > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 05:50:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWwY-000791-9Q; Mon, 01 Aug 2005 05:50:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzWj1-0003Jz-QC for isms@megatron.ietf.org; Mon, 01 Aug 2005 05:36:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10699 for ; Mon, 1 Aug 2005 05:36:45 -0400 (EDT) Received: from open-24-172.ietf63.ietf.org ([86.255.24.172] helo=dcn236-44.dcn.davis.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzXFH-0006vz-CS for isms@ietf.org; Mon, 01 Aug 2005 06:10:07 -0400 Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274) id F076111D515; Mon, 1 Aug 2005 02:36:34 -0700 (PDT) From: Wes Hardaker To: David B Harrington Subject: Re: [Isms] securityName Organization: Sparta References: <20050727213207.GA3262@boskop.local> <20050728065138.A5745D5EE@hermes.iu-bremen.de> <20050728075007.GA731@boskop.local> Date: Mon, 01 Aug 2005 02:36:30 -0700 In-Reply-To: <20050728075007.GA731@boskop.local> (Juergen Schoenwaelder's message of "Thu, 28 Jul 2005 09:50:07 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: isms@ietf.org, 'Dave Harrington' X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 28 Jul 2005 09:50:07 +0200, Juergen Schoenwaelder said: Juergen> d) provide a wildcard mapping extension to VACM which can be Juergen> exploited to map all security name with the same security Juergen> level and security model together into a vacm group (works Juergen> only on simple setups where you basically do not distinguish Juergen> between different MIB views for authenticated users - but Juergen> perhaps this is a low hanging fruit that covers most existing Juergen> VACM configurations anyway) FYI (I'm trying in vain to catch up on mail before the coming WG meeting; sorry for not responding to your previous note about this idea), David P and I talked extensively about this one day about a year ago or so. Over the phone, we actually decided it was possible to do what you've described above as an extension to the existing VACM tables without requiring modifications to it (a good thing; IMHO). However, we also talked about wildcarding many things, not just the security names. Security names to a single group mapping in a default case ("*" => "defaultAuthor") makes a lot of sense so that you can deploy generic access rules and having them apply to all unknown users. However, the other thing that we realized would be needed would be to say things like any user "Jack" coming in over any SM protocol should be mapped to "admin" or something like that. The reason for this style of wildcarding too is so you can deal with cases where we may have a lot of different future security models (eg, one for BEEP one for TLS/SASL using kerberos, one for ...). I believe that different mechanisms of authentication should result in their own security model numbers so you *can* distinguish differences between week and stronger transports in the VACM, but you then needed wildcarding of all of names, levels, and security model numbers so wouldn't make deployment more difficult when more fine grained decisions weren't needed. However, I do think it's critical that the resulting potential solutions from this WG for authentication and authorization not be bound together by requirement. Thus I see these three parts of the solution as independent and should be separate work items: 1) authentication (current major charter goal) 2) authorization configuration (referenced but not a direct goal) 3) the wildcard mapping to make configuration easier regardless of whether it's static or comes from #2 I think they *all* need to be solved, but I disagree that any of them need to be explicitly bound together. Any document that specifies a solution for #1 and allows for #2 but only when the solution for #1 is in use fails to meet the broader goal of making #2 possible in all cases. SMs and ACMs in SNMPv3 are not bound together today, and they shouldn't be in the future. There is no reason that an ACM configuration solution (over something centralized like AAA/radius or anything else like some other magic mapping) needs to be explicitly bound to a particular transport protocol. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 08:16:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZE0-0005js-7u; Mon, 01 Aug 2005 08:16:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzZDx-0005gv-Nj for isms@megatron.ietf.org; Mon, 01 Aug 2005 08:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04814 for ; Mon, 1 Aug 2005 08:16:50 -0400 (EDT) Received: from open-29-9.ietf63.ietf.org ([86.255.29.9] helo=dcn236-44.dcn.davis.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzZkD-00066i-S7 for isms@ietf.org; Mon, 01 Aug 2005 08:50:15 -0400 Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274) id 2606711D5FF; Mon, 1 Aug 2005 05:16:37 -0700 (PDT) From: Wes Hardaker To: Tom Petch Subject: Re: [Isms] securityName Organization: Sparta References: <20050727213207.GA3262@boskop.local> <20050728065138.A5745D5EE@hermes.iu-bremen.de> <20050728075007.GA731@boskop.local> <004e01c59672$429004e0$0601a8c0@pc6> Date: Mon, 01 Aug 2005 05:16:36 -0700 In-Reply-To: <004e01c59672$429004e0$0601a8c0@pc6> (Tom Petch's message of "Mon, 1 Aug 2005 10:00:56 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 1 Aug 2005 10:00:56 +0200, "Tom Petch" said: >> c) generally change the SNMP architecture providing new or extended >> ASIs to actually make this mapping something between the security >> model and the access control model (not in our charter) Tom> I am not sure that this is not in our charter. To quote TMSM Tom> "The RFC3411 ASIs would not need to be changed since the SNMPv3 Tom> WG expected that additional parameters could be passed for Tom> value-add features of specific implementations" The ASIs are described as examples and their arguments should not be treated as a function (thus they're not called APIs). When I (and others) suggested dropping the argument list from the ASIs before the v3 specs were published, the consensus was that they were useful even though they may not be perfect in the future and nobody in their right mind would treat them as APIs and would get what they had coming if they decided they were fixed in stone. I should go find the specific thread from the SNMPv3 archives, but I'll pass... -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 09:55:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzalC-0002tF-4I; Mon, 01 Aug 2005 09:55:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzal9-0002qX-0p for isms@megatron.ietf.org; Mon, 01 Aug 2005 09:55:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09718 for ; Mon, 1 Aug 2005 09:55:13 -0400 (EDT) Message-Id: <200508011355.JAA09718@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbHO-0001hU-W5 for isms@ietf.org; Mon, 01 Aug 2005 10:28:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080113550201300qfs96e>; Mon, 1 Aug 2005 13:55:03 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Tom Petch'" Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 09:54:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Thread-Index: AcWWkx69vYDoElmdSAOLx/7dUgmUMgACUNqA X-Spam-Score: 0.1 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Let me clarify the purpose of the ASIs: ASIs serve to differentiate the functional responsibilities/requirements of the subsystems, and identify the information that must pass between the subsystems (similar to data flow diagrams). As Wes points out, ASIs are not implementation constraints, and do not describe how implementations must modularize their code. However, ASIs **were** designed as constraints on future **model proposals**, to ensure interoperability between model proposals for one subsystem and model proposals for other subsystems. One concrete implication of this modular approach is that each subsystem has its own MIB module(s) that are independent of the MIB modules for other subsystems. The goal was to make MIB modules local to each subsystem rather than global in scope to prevent side-effects between subsystems. This was done deliberately because SNMPv2 had a horrendous problem with side-effects between the different types of functionality because the one MIB module for SNMPv2 was shared by all functional processing, and was constantly tweaked to meet different requirements, which caused unseen side-effects that violated other requirements. The SNMPv3 WG did recognize that in the future it may be desirable to add additional parameters to the ASIs, but it is important to standardize such additional parameters because it could create bindings between models that do not exist between subsystems, and such model-dependent bindings would defeat the purpose of the subsystem/ASI modularity. So, if we are going to add parameters to the ASIs, the parameters should be standardized, and co-existence with earlier models needs to be addressed. If the xxxxSecurityToGroupTable were moved to the SM subsystem from the AC subsystem, that we need to address how to reconcile this shift of responsibility from the existing AC models (VACM) to the existing SM models (USM and Community), how to move the MIB module from one subsystem to the other subsystem, and how to document the change to the architecture and the models given the IETF/RFC process. If the TMSM is going to pass transport information from the transport mapping to the SM subsystem, either through a cache or an ASI parameter, we need to standardize how this is done, how it affects existing models and MIB modules, and how to document these changes within the IETF. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker > Sent: Monday, August 01, 2005 8:17 AM > To: Tom Petch > Cc: isms@ietf.org > Subject: Re: [Isms] securityName > > >>>>> On Mon, 1 Aug 2005 10:00:56 +0200, "Tom Petch" > said: > > >> c) generally change the SNMP architecture providing new or extended > >> ASIs to actually make this mapping something between the security > >> model and the access control model (not in our charter) > > Tom> I am not sure that this is not in our charter. To quote TMSM > Tom> "The RFC3411 ASIs would not need to be changed since the SNMPv3 > Tom> WG expected that additional parameters could be passed for > Tom> value-add features of specific implementations" > > The ASIs are described as examples and their arguments should not be > treated as a function (thus they're not called APIs). When I (and > others) suggested dropping the argument list from the ASIs before the > v3 specs were published, the consensus was that they were useful even > though they may not be perfect in the future and nobody in their right > mind would treat them as APIs and would get what they had coming if > they decided they were fixed in stone. I should go find the specific > thread from the SNMPv3 archives, but I'll pass... > > -- > Wes Hardaker > Sparta, Inc. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 10:08:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaxY-0007Ih-KG; Mon, 01 Aug 2005 10:08:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzaxX-0007GY-Al for isms@megatron.ietf.org; Mon, 01 Aug 2005 10:08:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10931 for ; Mon, 1 Aug 2005 10:07:59 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbTm-0002JD-Fq for isms@ietf.org; Mon, 01 Aug 2005 10:41:23 -0400 Received: from wamui-bichon.atl.sa.earthlink.net ([209.86.224.26]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzaxI-0004Vb-00 for isms@ietf.org; Mon, 01 Aug 2005 10:07:48 -0400 Message-ID: <4177756.1122905268732.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Date: Mon, 1 Aug 2005 09:07:48 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] securityName Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: David B Harrington > Sent: Aug 1, 2005 8:54 AM > To: 'Wes Hardaker' , > 'Tom Petch' > Cc: isms@ietf.org > Subject: RE: [Isms] securityName ... > If the xxxxSecurityToGroupTable were moved to the SM subsystem from > the AC subsystem, that we need to address how to reconcile this shift > of responsibility from the existing AC models (VACM) to the existing > SM models (USM and Community), how to move the MIB module from one > subsystem to the other subsystem, and how to document the change to > the architecture and the models given the IETF/RFC process. ... Not-entirely rhetorical questions: (1) what does the architecture say about, for example, two different access control models making use of a commen table, if that table serves the needs of both models? (2) how do ASIs handle information updates that don't correspond to an SNMP pdu, but rather contain information coming from a non-SNMP source? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 10:18:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzb1m-0003o6-Lg; Mon, 01 Aug 2005 10:12:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzb1k-0003o1-II for isms@megatron.ietf.org; Mon, 01 Aug 2005 10:12:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11446 for ; Mon, 1 Aug 2005 10:12:22 -0400 (EDT) Message-Id: <200508011412.KAA11446@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbY1-0002Uv-Sw for isms@ietf.org; Mon, 01 Aug 2005 10:45:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050801141214012006be32e>; Mon, 1 Aug 2005 14:12:14 +0000 From: "David B Harrington" To: Date: Mon, 1 Aug 2005 10:12:09 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWWowDlmNdzFrL+RVCU4J5nz0b3hw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] presntations X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Will the presentations be available **in advance** via the mailing list or a web site from those who are using streaming audio to participate? Will there be a jabber scribe available to relay input from remote participants? Will there be presentations for the transport discussion? Who plans to lead that presentation/discussion? Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 10:18:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzb1e-0003nl-0k; Mon, 01 Aug 2005 10:12:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzb1c-0003nd-5F for isms@megatron.ietf.org; Mon, 01 Aug 2005 10:12:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11431 for ; Mon, 1 Aug 2005 10:12:14 -0400 (EDT) Message-Id: <200508011412.KAA11431@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzbXs-0002UY-Qx for isms@ietf.org; Mon, 01 Aug 2005 10:45:38 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080114120501100i17k6e>; Mon, 1 Aug 2005 14:12:05 +0000 From: "David B Harrington" To: Date: Mon, 1 Aug 2005 10:11:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWWovsTSfskSfOkR3mZZsJTYaiByA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Transport protocol discussion X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I have some concerns about trying to select "the" ISMS transport protocol; why are we trying to choose "the" transport rather than trying to choose a security application (e.g. TLS, SASL, SSH) that might incidentally be able to run over different transport protocols? Or is that what is meant by "selecting a transport protocol"? If we talk about selecting one transport protocol (i.e. UDP vs TCP), do we have new research with independently-verifiable statistics about the reliability and performance of these protocols as a transport for SNMP? If we don't have new info, I would consider discussing this for the umpteenth time to be a waste of face-to-face meeting time. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 11:58:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcgn-000389-Vv; Mon, 01 Aug 2005 11:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcgm-00037p-Jl for isms@megatron.ietf.org; Mon, 01 Aug 2005 11:58:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20122 for ; Mon, 1 Aug 2005 11:58:50 -0400 (EDT) Message-Id: <200508011558.LAA20122@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdD5-00081Q-EY for isms@ietf.org; Mon, 01 Aug 2005 12:32:15 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080115584101100i4vgge>; Mon, 1 Aug 2005 15:58:41 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Date: Mon, 1 Aug 2005 11:58:36 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <4177756.1122905268732.JavaMail.root@wamui-bichon.atl.sa.earthlink.net> Thread-Index: AcWWoo8fvhkdO4gXTCGIjoPbIjiApgAAba7w X-Spam-Score: 0.1 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] modularity X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Randy, Let me try to comment as co-chair of the concluded SNMPv3 WG: >From RFC3411 Design Decisions: - Architecture An architecture should be defined which identifies the conceptual boundaries between the documents. Subsystems should be defined which describe the abstract services provided by specific portions of an SNMP framework. Abstract service interfaces, as described by service primitives, define the abstract boundaries between documents, and the abstract services that are provided by the conceptual subsystems of an SNMP framework. - Self-contained Documents Elements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document, and as much as possible, should not be referenced in other documents. This allows pieces to be designed and documented as independent and self- contained parts, which is consistent with the general SNMP MIB module approach. As portions of SNMP change over time, the documents describing other portions of SNMP are not directly impacted. This modularity allows, for example, Security Models, authentication and privacy mechanisms, and message formats to be upgraded and supplemented as the need arises. The self-contained documents can move along the standards track on different time-lines. This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation. - Remote Configuration The Security and Access Control Subsystems add a whole new set of SNMP configuration parameters. The Security Subsystem also requires frequent changes of secrets at the various SNMP entities. To make this deployable in a large operational environment, these SNMP parameters must be remotely configurable. > > Not-entirely rhetorical questions: > > (1) what does the architecture say about, for example, two > different access control > models making use of a commen table, if that table serves the > needs of both models? "Elements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document, and as much as possible, should not be referenced in other documents. " It was the consensus of the SNMPv3 WG that even models of the same subsystem should not share MIB modules, unless the MIB model is defined as a standard part of its containing subsystem (e.g. SNMP-MPD-MIB) or a standard part of an overall architecture (e.g. SNMP-FRAMEWORK-MIB). By consensus of the SNMPv3 WG, the vacmSecurityToGroupTable is part of a specific model, and thus should not be referenced by other models. If they choose to use it, ISMS needs to decide whether an xxxxSecurityToGroupTable should be part of a specific model proposal, part of a subsystem, or part of an overall architecture. In my personal opinion, it will be relatively easy to define a table that is part of an independent AC model; it be will harder to officially modify the RFC3411 architecture to move responsibility for user-to-group mappings into the security subsystem, and hardest to retrofit moving the responsibility from the AC subsystem to the Security subsystem without officially modifying the architecture. Only the first option appears to be within the ISM charter, but any Transport-security approach will face the same problems. > > (2) how do ASIs handle information updates that don't > correspond to an SNMP > pdu, but rather contain information coming from a non-SNMP source? First let me respond to any assumption that ASIs are dependent on the PDU: >From RFC3412: "3.3. pduType A value of the pduType represents a specific type of protocol operation. The values of the pduType are specific to the version of the PDU contained in a message. Applications register to support particular pduTypes for particular contextEngineIDs. For incoming messages, pduType is provided to the Dispatcher by a version-specific Message Processing module. It is subsequently used to dispatch the PDU to the application which registered for the pduType for the contextEngineID of the associated scopedPDU." ASIs are designed as the interfaces between subsystems, and are typically independent of the PDU, since the PDU is specific to the message-processing-model and the application model. Second, SNMP generally provides a standardized interface to underlying non-SNMP instumentation. If a non-SNMP source modifies the underlying instrumentation, that may or may not show up in an SNMP standardized interface (a MIB module). By SNMPv3 WG consensus, it is expected that the SNMP parameters for the Security and AC subsystem models can be remotely configured. >From RFC3411 A.1.2: Each Security Model may allow multiple security protocols to be used concurrently within an implementation of the model. Each Security Model defines how to determine which protocol to use, given the securityLevel and the security parameters relevant to the message. Each Security Model, with its associated protocol(s) defines how the sending/receiving entities are identified, and how secrets are configured. So, RFC3411 doesn't state that the SNMP protocol must be used to do the configuration. Does that answer your Not-entirely rhetorical question #2? David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 12:19:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcuw-0006UG-QM; Mon, 01 Aug 2005 12:13:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcuu-0006OZ-IW for isms@megatron.ietf.org; Mon, 01 Aug 2005 12:13:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21295 for ; Mon, 1 Aug 2005 12:13:26 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzdRA-0000MK-L5 for isms@ietf.org; Mon, 01 Aug 2005 12:46:52 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 3D38D17067; Mon, 1 Aug 2005 09:12:58 -0700 (PDT) To: dbharrington@comcast.net Subject: Re: [Isms] Transport protocol discussion References: <200508011412.KAA11431@ietf.org> From: Eric Rescorla Date: Mon, 01 Aug 2005 09:12:58 -0700 In-Reply-To: <200508011412.KAA11431@ietf.org> (David B. Harrington's message of "Mon, 1 Aug 2005 10:11:59 -0400") Message-ID: <867jf5bppx.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org "David B Harrington" writes: > Hi, > > I have some concerns about trying to select "the" ISMS transport > protocol; why are we trying to choose "the" transport rather than > trying to choose a security application (e.g. TLS, SASL, SSH) that > might incidentally be able to run over different transport protocols? > Or is that what is meant by "selecting a transport protocol"? > > If we talk about selecting one transport protocol (i.e. UDP vs TCP), > do we have new research with independently-verifiable statistics about > the reliability and performance of these protocols as a transport for > SNMP? If we don't have new info, I would consider discussing this for > the umpteenth time to be a waste of face-to-face meeting time. My $.02: The important transport question is whether support for datagram mode is a requirement. If it is, that substantially constrains the solution set--and potentially requires some more design work :) -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 12:27:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd8X-0008VI-2f; Mon, 01 Aug 2005 12:27:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzd8R-0008PX-4T for isms@megatron.ietf.org; Mon, 01 Aug 2005 12:27:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22122 for ; Mon, 1 Aug 2005 12:27:24 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzdek-00010M-EF for isms@ietf.org; Mon, 01 Aug 2005 13:00:50 -0400 Received: from wamui-blood.atl.sa.earthlink.net ([209.86.224.28]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1Dzd8P-0001hi-00 for isms@ietf.org; Mon, 01 Aug 2005 12:27:25 -0400 Message-ID: <18185224.1122913645436.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Date: Mon, 1 Aug 2005 11:27:25 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Re: modularity X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: David B Harrington > Sent: Aug 1, 2005 10:58 AM > To: 'Randy Presuhn' , isms@ietf.org > Subject: modularity ... > > (1) what does the architecture say about, for example, two > > different access control > > models making use of a commen table, if that table serves the > > needs of both models? > > "Elements of procedure plus the MIB objects which are needed for > processing for a specific portion of an SNMP framework should > be defined in the same document, and as much as possible, > should not be referenced in other documents. " > > It was the consensus of the SNMPv3 WG that even models of the same > subsystem should not share MIB modules, unless the MIB model is > defined as a standard part of its containing subsystem (e.g. > SNMP-MPD-MIB) or a standard part of an overall architecture (e.g. > SNMP-FRAMEWORK-MIB). By consensus of the SNMPv3 WG, the > vacmSecurityToGroupTable is part of a specific model, and thus should > not be referenced by other models. That's not 100% clear. I think one could reasonably argue that the user/group mapping concept belongs to the access control subsystem, and is not necessarily limited to VACM. The dual nature of the USM and VACM documents (they describe both the subsystem and a specific model) doesn't help here, but we didn't want the document explosion that would have resulted if we had separated everything. However, I also think it's fair to say that a properly general-purpose user/group mapping designed for use by multiple access control models might look a little different from what we have today. For example, the 1:N might be M:N, there might be expiration dates on entries, etc. > If they choose to use it, ISMS needs to decide whether an > xxxxSecurityToGroupTable should be part of a specific model proposal, > part of a subsystem, or part of an overall architecture. Agreed, and I think there is a legitimate question whether ephemeral user/group mappings should be visible via SNMP at all. I think they should be, but the I think one could reasonably argue otherwise, as did the EUSM draft. > In my personal opinion, it will be relatively easy to define a table > that is part of an independent AC model; it be will harder to > officially modify the RFC3411 architecture to move responsibility for > user-to-group mappings into the security subsystem, and hardest to I think we're in agreement, though an implementation reality is that events in the security subsystem might trigger the (not-necessarily-SNMP) protocol exchanges that can eventually result in the arrival of user/group mapping updates. > retrofit moving the responsibility from the AC subsystem to the > Security subsystem without officially modifying the architecture. Only > the first option appears to be within the ISM charter, but any > Transport-security approach will face the same problems. I think one could also think about it as events in the security subsystem triggering events that update access control: --(snmp)--> security--(aaa)-->server--(aaa)-->accessControl That is: security model decides to send something to AAA; the response is internally routed to accessControl (after all, is it the subsystem or the engine that is talking to the AAA server?) > > (2) how do ASIs handle information updates that don't > > correspond to an SNMP > > pdu, but rather contain information coming from a non-SNMP source? > > First let me respond to any assumption that ASIs are dependent on the > PDU: ... > So, RFC3411 doesn't state that the SNMP protocol must be used to do > the configuration. > > Does that answer your Not-entirely rhetorical question #2? ... We're largely in agreement, I think, but I'd like to emphasize the timing and sequencing (or lack of sequencing) rather than conceptual parameters and syntax. The invocation of the ASIs corresponds to a chain of events triggered by the receipt of a PDU or the decision by an application to request transmission of a particular PDU. The ASIs don't address, for example, modification of configuration data through a CLI. I think one could look at dynamic creation / deletion of user/group mappings via an AAA-like protocol as being no different, from the SNMP engine's perspective, from those created / deleted via an ASI or netconf. >From this perspective, I think an EUSM-like approach to obtaining the user/group mappings as needed is not as much of an abomination as one might think. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 14:33:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzf61-0004tR-Gp; Mon, 01 Aug 2005 14:33:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzf60-0004rV-FH for isms@megatron.ietf.org; Mon, 01 Aug 2005 14:33:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29917 for ; Mon, 1 Aug 2005 14:33:01 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzfcI-0006vS-GG for isms@ietf.org; Mon, 01 Aug 2005 15:06:29 -0400 Received: from pc6 (1Cust20.tnt101.lnd4.gbr.da.uu.net [213.116.50.20]) by blaster.systems.pipex.net (Postfix) with SMTP id 2672EE0000FA; Mon, 1 Aug 2005 19:32:41 +0100 (BST) Message-ID: <007a01c596be$e01d5ae0$0601a8c0@pc6> From: "Tom Petch" To: "Randy Presuhn" , References: <18185224.1122913645436.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Subject: Re: [Isms] Re: modularity Date: Mon, 1 Aug 2005 19:30:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I find myself thinking that user to VacmGroup mapping does not belong in either SM or ACM and that that is the crux of the problem. Integration with existing security structure means, for me, that the authoritative engine for this mapping is elsewhere, in the organisation's security server, eg in RADIUS, so that placing it in either SM or ACM is or will be a problem for SM or ACM or both. Rather, SNMP should only be caching this information for as little time as it needs it, be that in 'manager', 'agent' or whereever, a bit like the state references in the ASIs.. As I have commented before, SNMPv3 sets out to do everything for itself, to be complete in itself, and that is no longer the market place we are in. The actual access rules within VACM are a different matter, because they are so SNMP specific so I do see them as properly part of an ACM MIB in the engine of the Command Responder.. Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Monday, August 01, 2005 6:27 PM Subject: [Isms] Re: modularity > Hi - > > > From: David B Harrington > > Sent: Aug 1, 2005 10:58 AM > > To: 'Randy Presuhn' , isms@ietf.org > > Subject: modularity > ... > > > (1) what does the architecture say about, for example, two > > > different access control > > > models making use of a commen table, if that table serves the > > > needs of both models? > > > > "Elements of procedure plus the MIB objects which are needed for > > processing for a specific portion of an SNMP framework should > > be defined in the same document, and as much as possible, > > should not be referenced in other documents. " > > > > It was the consensus of the SNMPv3 WG that even models of the same > > subsystem should not share MIB modules, unless the MIB model is > > defined as a standard part of its containing subsystem (e.g. > > SNMP-MPD-MIB) or a standard part of an overall architecture (e.g. > > SNMP-FRAMEWORK-MIB). By consensus of the SNMPv3 WG, the > > vacmSecurityToGroupTable is part of a specific model, and thus should > > not be referenced by other models. > > That's not 100% clear. I think one could reasonably argue that the user/group > mapping concept belongs to the access control subsystem, and is not necessarily > limited to VACM. The dual nature of the USM and VACM documents (they > describe both the subsystem and a specific model) doesn't help here, > but we didn't want the document explosion that would have resulted if we > had separated everything. > > However, I also think it's fair to say that a properly general-purpose user/group > mapping designed for use by multiple access control models might look a little > different from what we have today. For example, the 1:N might be M:N, there > might be expiration dates on entries, etc. > > > If they choose to use it, ISMS needs to decide whether an > > xxxxSecurityToGroupTable should be part of a specific model proposal, > > part of a subsystem, or part of an overall architecture. > > Agreed, and I think there is a legitimate question whether ephemeral > user/group mappings should be visible via SNMP at all. I think they should > be, but the I think one could reasonably argue otherwise, as did the EUSM > draft. > > > In my personal opinion, it will be relatively easy to define a table > > that is part of an independent AC model; it be will harder to > > officially modify the RFC3411 architecture to move responsibility for > > user-to-group mappings into the security subsystem, and hardest to > > I think we're in agreement, though an implementation reality is that > events in the security subsystem might trigger the (not-necessarily-SNMP) > protocol exchanges that can eventually result in the arrival of > user/group mapping updates. > > > retrofit moving the responsibility from the AC subsystem to the > > Security subsystem without officially modifying the architecture. Only > > the first option appears to be within the ISM charter, but any > > Transport-security approach will face the same problems. > > I think one could also think about it as events in the security subsystem > triggering events that update access control: > > --(snmp)--> security--(aaa)-->server--(aaa)-->accessControl > That is: security model decides to send something to AAA; the > response is internally routed to accessControl (after all, is it the > subsystem or the engine that is talking to the AAA server?) > > > > > (2) how do ASIs handle information updates that don't > > > correspond to an SNMP > > > pdu, but rather contain information coming from a non-SNMP source? > > > > First let me respond to any assumption that ASIs are dependent on the > > PDU: > ... > > So, RFC3411 doesn't state that the SNMP protocol must be used to do > > the configuration. > > > > Does that answer your Not-entirely rhetorical question #2? > ... > > We're largely in agreement, I think, but I'd like to emphasize the > timing and sequencing (or lack of sequencing) rather than conceptual > parameters and syntax. > > The invocation of the ASIs corresponds to a chain of events triggered > by the receipt of a PDU or the decision by an application to request > transmission of a particular PDU. The ASIs don't address, for example, > modification of configuration data through a CLI. I think one could look > at dynamic creation / deletion of user/group mappings via an AAA-like > protocol as being no different, from the SNMP engine's perspective, from > those created / deleted via an ASI or netconf. > > >From this perspective, I think an EUSM-like approach to obtaining the user/group > mappings as needed is not as much of an abomination as one might think. > > Randy > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 16:59:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhO6-0004o6-Ib; Mon, 01 Aug 2005 16:59:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhO3-0004lU-Jl for isms@megatron.ietf.org; Mon, 01 Aug 2005 16:59:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22837 for ; Mon, 1 Aug 2005 16:59:49 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzhuN-0001CY-7b for isms@ietf.org; Mon, 01 Aug 2005 17:33:17 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA22999; Mon, 1 Aug 2005 13:59:32 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71KxWs29457; Mon, 1 Aug 2005 13:59:32 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 13:59:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: modularity Date: Mon, 1 Aug 2005 13:59:28 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC432@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Re: modularity Thread-Index: AcWWyyeg4rkg/HpxRIK/mUTApyp1fQADtH3A From: "Fleischman, Eric" To: "Tom Petch" , "Randy Presuhn" , X-OriginalArrivalTime: 01 Aug 2005 20:59:29.0094 (UTC) FILETIME=[E8662660:01C596DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, I agree with you about VacmGroup mappings. My primary hope for ISMS is to leverage existing authentication systems for SNMP authentication and authorization. If those systems support "roles" then roles (including RBAC) is also supported. However, because these issues are determined by the authentication system, which is external to SNMP, and the specific authentication and authorization schema should be transparent to SNMP itself.=20 The issues that I am struggling with from these many recent postings are (1) "what are the SNMP interfaces to that external authentication system?" and=20 (2) "How much does ISMS leverage SNMPv3 USM and VACM? I.e., does it do 'security level' in the traditional way or has all security been 'outsourced' to another element?" Reading the various postings, it seems to me that the WG still doesn't have a common model in mind for these fundamental -- and core -- design issues. I am particularly alarmed that some still want to make minimal changes to SNMPv3 USM and VACM and others want to make major replacements to USM and VACM. Can we please reach consensus on that fundamental point, which, to me, are much more fundamental than whether we use SSH or TLS or DTLS? --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Monday, August 01, 2005 10:31 AM To: Randy Presuhn; isms@ietf.org Subject: Re: [Isms] Re: modularity I find myself thinking that user to VacmGroup mapping does not belong in either SM or ACM and that that is the crux of the problem. Integration with existing security structure means, for me, that the authoritative engine for this mapping is elsewhere, in the organisation's security server, eg in RADIUS, so that placing it in either SM or ACM is or will be a problem for SM or ACM or both. Rather, SNMP should only be caching this information for as little time as it needs it, be that in 'manager', 'agent' or whereever, a bit like the state references in the ASIs.. As I have commented before, SNMPv3 sets out to do everything for itself, to be complete in itself, and that is no longer the market place we are in. The actual access rules within VACM are a different matter, because they are so SNMP specific so I do see them as properly part of an ACM MIB in the engine of the Command Responder.. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 17:10:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhY7-0003jP-25; Mon, 01 Aug 2005 17:10:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzhY3-0003eE-L3 for isms@megatron.ietf.org; Mon, 01 Aug 2005 17:10:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23322 for ; Mon, 1 Aug 2005 17:10:08 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzi4L-0001cU-Nu for isms@ietf.org; Mon, 01 Aug 2005 17:43:37 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA05515; Mon, 1 Aug 2005 14:09:57 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71L9vv08310; Mon, 1 Aug 2005 16:09:57 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:09:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 14:09:55 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC433@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQ From: "Fleischman, Eric" To: "Tom Petch" , "Kaushik Narayan" X-OriginalArrivalTime: 01 Aug 2005 21:09:56.0016 (UTC) FILETIME=[5E12DB00:01C596DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, I agree with your point if our goal is to continue to leverage SNMPv3 USM and VACM. However, if we are "outsourcing" elements (or all of) the ISMS security to alternative technologies, such as many have proposed, then I disagree with you. I disagree with you because the order of Wes' list reflects ISP response to current SNMPv3 authentication realities.=20 As I've said many times, SNMPv3 authentication is totally unlike all other authentication systems in our deployment, and my personal goal for ISMS is for SNMP to directly leverage an existing authentication system within our deployment. To the extent that my employer represents the large end user, then I suggest that the preferable candidates are Kerberos, PKI, Radius, or some other server-based authentication system (including TACACS+). Local accounts just don't cut it because they don't scale.=20 --Eric -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Thursday, July 28, 2005 9:32 AM To: Kaushik Narayan Cc: isms@ietf.org Subject: Re: [Isms] securityName ----- Original Message ----- From: "Kaushik Narayan" To: Cc: Sent: Sunday, July 17, 2005 5:05 PM Subject: RE: [Isms] securityName > Hi David, > > Here is a list of external authentication mechanisms that are required > to be supported from the ISMS charter > > - Radius > - TACACS+ > - Kerberos > - LDAP > - Diameter > Well, no, that is not what I see or would ever want to see in the charter because I would regard it as impossible if it weren't that already. What I see the charter say is "The following security infrastructures will be considered by the working group as potential existing authentication infrastructures to make use of within the new security model. The solution will hopefully be able to be integrated with multiple of these user databases although it is expected that one will be mandatory. - Local accounts - SSH identities - Radius - TACACS+ - X.509 Certificates - Kerberos - LDAP - Diameter" So we have to support one, hopefully more than one, never all. And notice that the order of the list is that of the percentage currently using it as revealed in Wes' survey, so support for SSH counts for more than support for LDAP, by an order of magnitude. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 17:26:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzhnw-0006hK-C7; Mon, 01 Aug 2005 17:26:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzhnu-0006hF-Lh for isms@megatron.ietf.org; Mon, 01 Aug 2005 17:26:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23982 for ; Mon, 1 Aug 2005 17:26:31 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DziKD-0002Cy-QF for isms@ietf.org; Mon, 01 Aug 2005 18:00:00 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j71LQIui025705; Mon, 1 Aug 2005 21:26:18 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j71LPbeI022862; Mon, 1 Aug 2005 21:26:18 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080114261717189 ; Mon, 01 Aug 2005 14:26:17 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:26:17 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:26:16 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 17:26:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 17:22:39 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290192F3DC@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] securityName Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQAACfzIA= From: "Blumenthal, Uri" To: "Fleischman, Eric" , "Tom Petch" , "Kaushik Narayan" X-OriginalArrivalTime: 01 Aug 2005 21:26:15.0576 (UTC) FILETIME=[A5EFD980:01C596DF] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > As I've said many times, SNMPv3 authentication is totally unlike all > other authentication systems in our deployment No it is not.=20 At the moment it's much alike IPsec with manual keying (which coincidentally is employed by some applications and protocols). > and my personal goal for > ISMS is for SNMP to directly leverage an existing authentication system > within our deployment. You seem to be missing the fact that another important issue the WG is struggling with is mapping of whatever credentials Security System returns, to ACM rules to obtain access control decisions (without which authentication is not very useful). > To the extent that my employer represents the > large end user, then I suggest that the preferable candidates are > Kerberos, PKI, Radius, or some other server-based authentication system > (including TACACS+). Local accounts just don't cut it because they don't > scale.=20 And about 30% of the participants will tell you that local accounts is precisely what would allow them to perform zero-[extra]-touch deployment... -----Original Message----- From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 Sent: Thursday, July 28, 2005 9:32 AM To: Kaushik Narayan Cc: isms@ietf.org Subject: Re: [Isms] securityName ----- Original Message ----- From: "Kaushik Narayan" To: Cc: Sent: Sunday, July 17, 2005 5:05 PM Subject: RE: [Isms] securityName > Hi David, > > Here is a list of external authentication mechanisms that are required > to be supported from the ISMS charter > > - Radius > - TACACS+ > - Kerberos > - LDAP > - Diameter > Well, no, that is not what I see or would ever want to see in the charter because I would regard it as impossible if it weren't that already. What I see the charter say is "The following security infrastructures will be considered by the working group as potential existing authentication infrastructures to make use of within the new security model. The solution will hopefully be able to be integrated with multiple of these user databases although it is expected that one will be mandatory. - Local accounts - SSH identities - Radius - TACACS+ - X.509 Certificates - Kerberos - LDAP - Diameter" So we have to support one, hopefully more than one, never all. And notice that the order of the list is that of the percentage currently using it as revealed in Wes' survey, so support for SSH counts for more than support for LDAP, by an order of magnitude. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 17:44:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzi5G-0001jM-Sb; Mon, 01 Aug 2005 17:44:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzi5F-0001jH-AS for isms@megatron.ietf.org; Mon, 01 Aug 2005 17:44:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24800 for ; Mon, 1 Aug 2005 17:44:26 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzibY-0002uc-B9 for isms@ietf.org; Mon, 01 Aug 2005 18:17:55 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA12303; Mon, 1 Aug 2005 14:44:05 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71LiFs19177; Mon, 1 Aug 2005 14:44:15 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 14:44:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 14:44:14 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC435@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQAACfzIAAAFgEMA== From: "Fleischman, Eric" To: "Blumenthal, Uri" , "Tom Petch" , "Kaushik Narayan" X-OriginalArrivalTime: 01 Aug 2005 21:44:15.0109 (UTC) FILETIME=[29638350:01C596E2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >> and my personal goal for >> ISMS is for SNMP to directly leverage an existing authentication >>system within our deployment. >You seem to be missing the fact that another important=20 >issue the WG is struggling with is mapping of whatever=20 >credentials Security System returns, to ACM rules to=20 >obtain access control decisions (without which=20 >authentication is not very useful). Actually, I covered that point in the email message that I sent to the ISMS WG two minutes before the posting you have responded to. To re-iterate, what concerns me about these emails is that I believe the most foundational problem that the ISMS WG needs to resolve is "To what extent will we continue to leverage SNMPv3 USM and VACM?" Some postings presuppose that we won't change those interfaces. Others presuppose a whole-scale replacement. Until consensus is formed on this fundamental issue, I don't see how a long discussion of transport security is likely to be very fruitful. >> As I've said many times, SNMPv3 authentication is=20 >>totally unlike all other authentication systems in our deployment >No it is not.=20 >At the moment it's much alike IPsec with manual=20 >keying (which coincidentally is employed by some=20 >applications and protocols). I don't consider ad hoc "manual keying" to be an authentication system. Since you apparently do, then I understand why you disagree with my statement.=20 Regardless, my personal aspirations for the ISMS WG to enable SNMP leverage an existing, scalable enterprise authentication infrastructure alternative such as Kerberos, PKI, or Radius. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 17:45:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzi6Y-0002R5-AN; Mon, 01 Aug 2005 17:45:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzi6W-0002Qf-2h for isms@megatron.ietf.org; Mon, 01 Aug 2005 17:45:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24858 for ; Mon, 1 Aug 2005 17:45:45 -0400 (EDT) Message-Id: <200508012145.RAA24858@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzics-0002w3-Az for isms@ietf.org; Mon, 01 Aug 2005 18:19:14 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005080121453601400jdeeee>; Mon, 1 Aug 2005 21:45:36 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Tom Petch'" , "'Randy Presuhn'" , Subject: RE: [Isms] Re: modularity Date: Mon, 1 Aug 2005 17:45:30 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC432@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcWWyyeg4rkg/HpxRIK/mUTApyp1fQADtH3AAAF+LlA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, > Reading the various postings, it seems to me that the WG still doesn't > have a common model in mind for these fundamental -- and core > -- design > issues. I am particularly alarmed that some still want to make minimal > changes to SNMPv3 USM and VACM and others want to make major > replacements to USM and VACM. Can we please reach consensus on that > fundamental point The SNMPv3 WG did have consensus on a common model, and documented that consensus. To be consistent with the RFC3411 architecture, both USM and VACM should remain unchanged, and be able to coexist with supplementary security and access control models, such as those that outsource the security to other elements. The MIB module for USM should be used only by USM, and the MIB module for VACM should be used only by VACM, and any new secuirty model or new AC model should define its own MIB module, and only it should access that model-specific MIB module. Regarding scalability, the SNMPv3 WG reached consensus on the following design decision: " - Controlled Complexity It is recognized that producers of simple managed devices want to keep the resources used by SNMP to a minimum. At the same time, there is a need for more complex configurations which can spend more resources for SNMP and thus provide more functionality. The design tries to keep the competing requirements of these two environments in balance and allows the more complex environments to logically extend the simple environment." USM's local accounts represents the simple model, which is suitable for simple environments; interfacing to external security infrastructure for scalability is a requirement of a more complex environment, and can be achieved by designing a separate, supplementary security model, and a separate supplementary access control model. David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 17:52:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziCi-0007sm-OV; Mon, 01 Aug 2005 17:52:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziCh-0007sh-2Q for isms@megatron.ietf.org; Mon, 01 Aug 2005 17:52:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25168 for ; Mon, 1 Aug 2005 17:52:08 -0400 (EDT) Message-Id: <200508012152.RAA25168@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzij2-0003DN-F0 for isms@ietf.org; Mon, 01 Aug 2005 18:25:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080121513301100i1anie>; Mon, 1 Aug 2005 21:51:33 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Tom Petch'" , "'Kaushik Narayan'" Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 17:51:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC433@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQAAGYfbA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, > As I've said many times, SNMPv3 authentication is totally unlike all > other authentication systems in our deployment, and my > personal goal for > ISMS is for SNMP to directly leverage an existing > authentication system > within our deployment. Why don't you write up a security model proposal that directly leverages an existing authentication system within your deployment? The RFC3411 architecture was designed to explicitly permit such supplementary models. Why are you waiting for a standards body to develop something custom-fitted to your environment? If you want your solution to be an IETF standard, then after you design it, submit it for consideration as a standard. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 18:05:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziPC-0007ny-6u; Mon, 01 Aug 2005 18:05:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziPA-0007nT-7j for isms@megatron.ietf.org; Mon, 01 Aug 2005 18:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26580 for ; Mon, 1 Aug 2005 18:05:01 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzivW-0003kt-Ct for isms@ietf.org; Mon, 01 Aug 2005 18:38:30 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA05844; Mon, 1 Aug 2005 15:04:38 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71M4mv11749; Mon, 1 Aug 2005 17:04:48 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 15:04:43 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: modularity Date: Mon, 1 Aug 2005 15:04:42 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC436@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Re: modularity Thread-Index: AcWWyyeg4rkg/HpxRIK/mUTApyp1fQADtH3AAAF+LlAAAKn8UA== From: "Fleischman, Eric" To: , "Tom Petch" , "Randy Presuhn" , X-OriginalArrivalTime: 01 Aug 2005 22:04:43.0500 (UTC) FILETIME=[05911AC0:01C596E5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, I am grateful for your many postings, which I interpret as arguing for why SNMPv3 USM and VACM should be retained as unchanged as possible by ISMS. I respect your point of view since it represents possibly less work for the WG than the other alternatives, and I view this argument as clearly articulating a desirable goal in an achievable fashion.=20 I see two other alternatives, which I believe others have been arguing. The one I dislike is the possibility of changing both SNMPv3 and authentication infrastructures. To me, that alternative has no clean orientation and is the worst of all worlds. My own preference is to make SNMP leverage several existing authentication infrastructures (i.e., changing SNMP but keeping the authentication infrastructures unchanged) -- much like what Wes Hardaker and David Perkins proposed a year ago. However, what I dislike about my own preference is that the SNMP interface are very unclear/undefined (unless we adopt a specific proposal "as is", which I don't think that the WG is willing to do yet) and it could lead, in the worst case, to an entirely different system than SNMPv3 as we know it. This uncertainly troubles me greatly, which is why I am so appreciative of your postings. --Eric -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, August 01, 2005 2:46 PM To: Fleischman, Eric; 'Tom Petch'; 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] Re: modularity Hi Eric, The SNMPv3 WG did have consensus on a common model, and documented that consensus. To be consistent with the RFC3411 architecture, both USM and VACM should remain unchanged, and be able to coexist with supplementary security and access control models, such as those that outsource the security to other elements. The MIB module for USM should be used only by USM, and the MIB module for VACM should be used only by VACM, and any new secuirty model or new AC model should define its own MIB module, and only it should access that model-specific MIB module. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 18:08:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziSR-0001vp-Gw; Mon, 01 Aug 2005 18:08:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DziSN-0001ve-Sy for isms@megatron.ietf.org; Mon, 01 Aug 2005 18:08:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27069 for ; Mon, 1 Aug 2005 18:08:21 -0400 (EDT) Message-Id: <200508012208.SAA27069@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dziyi-0003rT-2m for isms@ietf.org; Mon, 01 Aug 2005 18:41:50 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005080122081101400jhvsge>; Mon, 1 Aug 2005 22:08:11 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Re: modularity Date: Mon, 1 Aug 2005 18:08:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <18185224.1122913645436.JavaMail.root@wamui-blood.atl.sa.earthlink.net> Thread-Index: AcWWtfyI1kLl6D7mQJerVSGuTGBIbQAHCk4A X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Randy, Comments (as a contributor, not SNMPv3 co-chair) inline. > > By consensus of the SNMPv3 WG, the > > vacmSecurityToGroupTable is part of a specific model, and > > thus should > > not be referenced by other models. > > That's not 100% clear. I think one could reasonably argue > that the user/group > mapping concept belongs to the access control subsystem, and > is not necessarily > limited to VACM. The dual nature of the USM and VACM documents (they > describe both the subsystem and a specific model) doesn't help here, > but we didn't want the document explosion that would have > resulted if we > had separated everything. Agreed that the dual nature of the documents makes it harder to see the separation. The following text was included in the documents to be 100% clear that the document (or document section) is model-specific: >From RFC3412 (SNMPv3-format message processing): "7. Elements of Procedure for v3MP This section describes the procedures followed by an SNMP engine when generating and processing SNMP messages according to the SNMPv3 Message Processing Model." >From RFC3414 (USM): " This document describes the User-based Security Model (USM) for Simple Network Management Protocol (SNMP) version 3 for use in the SNMP architecture. It defines the Elements of Procedure for providing SNMP message level security. This document also includes a Management Information Base (MIB) for remotely monitoring/managing the configuration parameters for this Security Model." >From RFC3415: "It is the purpose of this document to define a specific model of the Access Control Subsystem, designated the View-based Access Control Model." I don't think there's much ambiguity in these statements. > > However, I also think it's fair to say that a properly > general-purpose user/group > mapping designed for use by multiple access control models > might look a little > different from what we have today. For example, the 1:N > might be M:N, there > might be expiration dates on entries, etc. I agree one could be designed for subsystem usage and it would likely vary from VACM's, which was designed to meet model-specific requirements not general-usage requirements. > > > If they choose to use it, ISMS needs to decide whether an > > xxxxSecurityToGroupTable should be part of a specific model > proposal, > > part of a subsystem, or part of an overall architecture. > > Agreed, and I think there is a legitimate question whether ephemeral > user/group mappings should be visible via SNMP at all. I > think they should > be, but the I think one could reasonably argue otherwise, as > did the EUSM > draft. And I think the best approach to this different sets of requirements is to define specific access control models that choose to expose the information or not. That would seem a better approach than trying to redesign the architecture or the subsystem to meet a new set of needs, when the architecture is already designed to accommodate multiple models to address different needs. If we do decide to revamp the subsystem or the architecture to address what might now be considered oversights of the original subsystems/architecture, then we should be aware of the implications of the changes, and not overlook the original design decisions or their motivation. I don't believe the changes being suggested were oversights in the original design, but were deliberate choices to meet modularity goals, and to meet WG consensus requirements such as "the mandatory-to-implement models should have no dependencies on external protocols" and "to not require a user/group mapping". Let's not get hung up on the new requested features so much we forget the original design decisions. > > > In my personal opinion, it will be relatively easy to define a table > > that is part of an independent AC model; it be will harder to > > officially modify the RFC3411 architecture to move > responsibility for > > user-to-group mappings into the security subsystem, and hardest to > > I think we're in agreement, though an implementation reality is that > events in the security subsystem might trigger the > (not-necessarily-SNMP) > protocol exchanges that can eventually result in the arrival of > user/group mapping updates. If any specific AC model **depends** on a specific Security model to provide that trigger, then there are dependencies between the models, and that is a bad thing. Likewise, if a specific security model **depends** on the AC model to apply the triggered authorizations, that creates a dependency. But, if an AC model can take advantage of such behind-the-scenes configuration triggered by a security model that does this, but can also continue to function even if such a trigger is not provided by all security models, then one is not dependent on the other. If the SM provides the information but the AC models in the system (e.g. VACM) are free to ignore such information, then we are not faced with inter-model dependencies. Of course, having optional features in SMs and ACMs increases the complexity of the designs, and having two subsystems responsible/not responsible for getting/triggering the appropriate configuration increases the ambiguity in the architecture/subsystem responsibility separation. > > > retrofit moving the responsibility from the AC subsystem to the > > Security subsystem without officially modifying the > architecture. Only > > the first option appears to be within the ISM charter, but any > > Transport-security approach will face the same problems. > > I think one could also think about it as events in the > security subsystem > triggering events that update access control: > > --(snmp)--> security--(aaa)-->server--(aaa)-->accessControl > That is: security model decides to send something to AAA; the > response is internally routed to accessControl (after all, is it the > subsystem or the engine that is talking to the AAA server?) I don't think splitting hairs between the subsystem and the engine is helpful, and reminds me of the agent vs manager or "agent acting in a manager role" distinctions of the past. Let's focus on architecturally splitting the responsibility for different types of functionality, and then remain consistent about the responsibilities. If the SM triggers an AAA-event, does it know about the re-routing to the AC subsystem? Does the AC system know who triggered and rerouted the information? Are all SMs required to provide such functionality? Are all AC models required to utilize the mappings provided by the SMs? > > > > > (2) how do ASIs handle information updates that don't > > > correspond to an SNMP > > > pdu, but rather contain information coming from a non-SNMP source? > > > > First let me respond to any assumption that ASIs are > dependent on the > > PDU: > ... > > So, RFC3411 doesn't state that the SNMP protocol must be used to do > > the configuration. > > > > Does that answer your Not-entirely rhetorical question #2? > ... > > We're largely in agreement, I think, but I'd like to emphasize the > timing and sequencing (or lack of sequencing) rather than conceptual > parameters and syntax. > > The invocation of the ASIs corresponds to a chain of events triggered > by the receipt of a PDU or the decision by an application to request > transmission of a particular PDU. The ASIs don't address, > for example, > modification of configuration data through a CLI. I think > one could look > at dynamic creation / deletion of user/group mappings via an AAA-like > protocol as being no different, from the SNMP engine's > perspective, from > those created / deleted via an ASI or netconf. The underlying instrumentation can certainly be dynamically configured by means other than SNMP, and then have the configuration reflected in SNMP MIBs that can be used by the AC subsystem. As pointed out, netconf and CLI are commonly used to configure SNMP MIB modules. It certainly is common for SNMP events (incoming SETs or NOTIFICATIONS) to cause events to happen in the underlying instrumentation. I have concerns that the documentation not create dependencies between specific subsystems or between specific models, in a manner that contradicts the SNMPv3 WG consensus to require architectural modularity. I view this as similar to ISMS not being allowed to dictate to the EAP WG a new applicability statement, even though many of the original SNMPv3 WG members are present here as well. If we're going to change the architectural requirement for modularity, then we should (gasp) re-open and update the architecture standard. And let me be clear that I also have similar concerns about TMSM. > > >From this perspective, I think an EUSM-like approach to > obtaining the user/group > mappings as needed is not as much of an abomination as one > might think. I don't consider it an abomination. I have concerns that if a EUSM-style security model manipulates the entries in the vacmSecurityToGroupTable, that would violate the Design Decision that models should not reference the MIB modules of other models or other subsystems, because it creates unwanted dependencies between models. VACM depends on a configured vacmSecurityToGroupTable to function properly. If EUSM-style authorization modifies the underlying instrumentation, which then is reflected in the vacmSecurityToGroupTable (just as if netconf or the CLI had been used to configure the underlying instrumentation which is reflected in vacmSecurityToGroupTable), then there is no **dependency** on a specific configuration approach, and if the EUSM-style configuration does not cause a Security model to manipualte vacmSecurityToGroupTable, then no dependency is created by the SM and ACM. I am not opposed to changing the architecture if necessary, or extending the architecture with new ASI parameters or new caches, or even making some aspects implementation-dependent, but I am opposed to just ignoring the subsystem boundaries, which were defined by the SNMPv3 WG to avoid ending up with a monolithic architecture that suffered with hard-to-debug side-effects from every MIB object change or semantic tweak. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 18:31:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzioK-0006LK-Di; Mon, 01 Aug 2005 18:31:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzioJ-0006LF-5i for isms@megatron.ietf.org; Mon, 01 Aug 2005 18:31:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00297 for ; Mon, 1 Aug 2005 18:31:00 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzjKe-0004k2-J4 for isms@ietf.org; Mon, 01 Aug 2005 19:04:30 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA03328; Mon, 1 Aug 2005 15:30:49 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j71MUnv08199; Mon, 1 Aug 2005 17:30:49 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 15:30:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 15:30:46 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC437@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQAAGYfbAAAK97kA== From: "Fleischman, Eric" To: , "Tom Petch" , "Kaushik Narayan" X-OriginalArrivalTime: 01 Aug 2005 22:30:46.0484 (UTC) FILETIME=[A92D8940:01C596E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: David B Harrington [mailto:ietfdbh@comcast.net]=20 >Why are you waiting for a standards body to develop=20 >something custom-fitted to your environment? David, Our environment, other than its vast size, isn't very different than a great many other end users. Ever since the 1980s my employer has been actively encouraging standards-based approaches because those approaches have the best business cases by far (i.e., custom-fit just doesn't scale over time). This is why all of my postings have been arguing for ISMS to make SNMPv3 directly be able to use standard authentication infrastructures such as Kerberos, PKI, and Radius. These infrastructures are widely deployed and are universally deployed by all large end users that I know about. I discourage this WG leveraging Wes' authentication list because that was taken from ISPs, and ISPs are very different than us end users, who perhaps have orders of magnitude more SNMP products deployed than ISPs. The view from my knot-hole is that SNMPv3 currently has a unique security system that not only is needlessly expensive to deploy, but it is also extremely difficult to implement securely in vast deployments of multi-vendor equipment due to vendor product differences. I believe that this would be remedied by having SNMP conform to using one or more standard authentication technologies. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 01 23:30:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DznUI-00076N-IU; Mon, 01 Aug 2005 23:30:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DznUE-00076A-G6 for isms@megatron.ietf.org; Mon, 01 Aug 2005 23:30:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23246 for ; Mon, 1 Aug 2005 23:30:35 -0400 (EDT) Message-Id: <200508020330.XAA23246@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzo0c-0006y7-BU for isms@ietf.org; Tue, 02 Aug 2005 00:04:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080203302601300qc6dee>; Tue, 2 Aug 2005 03:30:26 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Tom Petch'" , "'Kaushik Narayan'" Subject: RE: [Isms] securityName Date: Mon, 1 Aug 2005 23:30:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <474EEBD229DF754FB83D256004D021080EC437@XCH-NW-6V1.nw.nos.boeing.com> Thread-Index: AcWTnuZaf94TTiXvQfayXjKcs8iQRwDPRAvQAAGYfbAAAK97kAALCqsg X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, Have you tried writing a proposal for a security model that utilizes Kerberos or PKI? The ISMS WG might be willing to accept it even if it is not from Wes's list. Otherwise, if it fits with the SNMPv3 architecture, even if it is not "the" ISMS protocol, you might get it published as experiemntal or informational, and once ISMS finishes, you can probably submit it to be considered for standards-track. The SNMPv3 architecture was designed to allow multiple security models, so it wouldn't be in conflict with the SNMPv3 strategy. Step up and write down your detailed proposal. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > Sent: Monday, August 01, 2005 6:31 PM > To: ietfdbh@comcast.net; Tom Petch; Kaushik Narayan > Cc: isms@ietf.org > Subject: RE: [Isms] securityName > > From: David B Harrington [mailto:ietfdbh@comcast.net] > >Why are you waiting for a standards body to develop > >something custom-fitted to your environment? > > David, > > Our environment, other than its vast size, isn't very different than a > great many other end users. Ever since the 1980s my employer has been > actively encouraging standards-based approaches because those > approaches > have the best business cases by far (i.e., custom-fit just > doesn't scale > over time). > > This is why all of my postings have been arguing for ISMS to > make SNMPv3 > directly be able to use standard authentication > infrastructures such as > Kerberos, PKI, and Radius. These infrastructures are widely > deployed and > are universally deployed by all large end users that I know about. I > discourage this WG leveraging Wes' authentication list > because that was > taken from ISPs, and ISPs are very different than us end users, who > perhaps have orders of magnitude more SNMP products deployed > than ISPs. > > The view from my knot-hole is that SNMPv3 currently has a unique > security system that not only is needlessly expensive to > deploy, but it > is also extremely difficult to implement securely in vast > deployments of > multi-vendor equipment due to vendor product differences. I > believe that > this would be remedied by having SNMP conform to using one or more > standard authentication technologies. > > --Eric > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 02:52:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzqdw-0001pi-BN; Tue, 02 Aug 2005 02:52:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzqdv-0001og-Fv for isms@megatron.ietf.org; Tue, 02 Aug 2005 02:52:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24327 for ; Tue, 2 Aug 2005 02:52:49 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzrAK-0006C3-Ce for isms@ietf.org; Tue, 02 Aug 2005 03:26:22 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 01 Aug 2005 23:52:37 -0700 X-IronPort-AV: i="3.95,161,1120460400"; d="scan'208"; a="202026965:sNHT26363920" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j726qaJL010252 for ; Mon, 1 Aug 2005 23:52:36 -0700 (PDT) Received: from [86.255.4.172] (ams-clip-vpn-dhcp4278.cisco.com [10.61.80.181]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j726o3vt027875 for ; Mon, 1 Aug 2005 23:50:04 -0700 Message-ID: <42EF1835.7070309@cisco.com> Date: Tue, 02 Aug 2005 08:52:37 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=81; t=1122965404; x=1123397604; c=nowsp; s=nebraska; h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:BTSM=20presentation| From:Eliot=20Lear=20| Date:Tue,=2002=20Aug=202005=2008=3A52=3A37=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=b3DDxAkvlbYTjEsYSCsztOU8brsye3h+jQwWcA4LdcSGYaJOgxjDdxnfrb2hg/PHsP4PW/cj rX2rCJuBdC1RWJin1KscRbuRatcIrm54qCJF/31L6DcCxQoZXIHym9KDtgZ0HLRiP1BmOqgjaty Ovs2pqw/5XtlCyrPJrmm7Ouc= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] BTSM presentation X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org PDF can be found at the following URL: http://www.ofcourseimright.com/~lear/btsm.pdf Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 03:47:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrVA-0005HH-Rg; Tue, 02 Aug 2005 03:47:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzrV9-0005DL-4u for isms@megatron.ietf.org; Tue, 02 Aug 2005 03:47:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27689 for ; Tue, 2 Aug 2005 03:47:48 -0400 (EDT) Received: from pop04.mail.atl.earthlink.net ([207.69.200.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzs1Z-0000QT-6K for isms@ietf.org; Tue, 02 Aug 2005 04:21:22 -0400 Received: from wamui-backed.atl.sa.earthlink.net ([209.86.224.25]) by pop04.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzrV6-0000hC-00 for isms@ietf.org; Tue, 02 Aug 2005 03:47:48 -0400 Message-ID: <19799944.1122968868517.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 02:47:48 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] Re: modularity Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: David B Harrington > Sent: Aug 1, 2005 5:08 PM > To: 'Randy Presuhn' , isms@ietf.org > Subject: RE: [Isms] Re: modularity ... ... > > Agreed, and I think there is a legitimate question whether ephemeral > > user/group mappings should be visible via SNMP at all. I > > think they should > > be, but the I think one could reasonably argue otherwise, as > > did the EUSM draft. > > And I think the best approach to this different sets of requirements > is to define specific access control models that choose to expose the > information or not. That would seem a better approach than trying to > redesign the architecture or the subsystem to meet a new set of needs, > when the architecture is already designed to accommodate multiple > models to address different needs. Though this sounds nice, I don't like where it leads: for each authentication mechanism we might end up defining yet another access control mechanism, which, if we stick with the MIB module structure you referred to a few messages ago, would result in the need to distribute identical access control configurations to multiple (for example) VACM-like MIBs that differ only in how their user/group mapping gets populated. That might be architecturally pure, but I think it would be an operational problem. > If we do decide to revamp the subsystem or the architecture to address ... I don't think doing so would be terribly productive. ... > > I think we're in agreement, though an implementation reality is that > > events in the security subsystem might trigger the > > (not-necessarily-SNMP) > > protocol exchanges that can eventually result in the arrival of > > user/group mapping updates. > > If any specific AC model **depends** on a specific Security model to > provide that trigger, then there are dependencies between the models, > and that is a bad thing. Likewise, if a specific security model > **depends** on the AC model to apply the triggered authorizations, > that creates a dependency. Agree. It should be able to work if the user/group mappings have been configured through SNMP. But from an operational perspective, we already assume that user/group mappings will have been configured before a request can be successfully processed. The EUSM approach can be thought of as just-in-time cache loading or just-in-time configuration, depending on whether or not you think these dynamic mappings should be visible to management. > But, if an AC model can take advantage of such behind-the-scenes > configuration triggered by a security model that does this, but can > also continue to function even if such a trigger is not provided by > all security models, then one is not dependent on the other. If the > SM provides the information but the AC models in the system (e.g. > VACM) are free to ignore such information, then we are not faced with > inter-model dependencies. We are in agreement here. > Of course, having optional features in SMs and ACMs increases the > complexity of the designs, and having two subsystems responsible/not > responsible for getting/triggering the appropriate configuration > increases the ambiguity in the architecture/subsystem responsibility > separation. Yup, but it's really just defining procedures that spell out automatic delivery of certain bits of information. The existing SNMP specifications just allow an incredibly large window for the delivery of these bits: any time before the request that needs the user/group mapping. ... > If the SM triggers an AAA-event, does it know about the re-routing to > the AC subsystem? Does the AC system know who triggered and rerouted > the information? I think there is no need for SM (security model) to know that the AAA event will be routed to the AC (access control) subsystem. I think there is no need for the AC system to know what caused the AAA information to arrive. There is, unfortunately, a need for the SM to know when the triggered AAA exchanges have finished. > Are all SMs required to provide such functionality? Are all AC models > required to utilize the mappings provided by the SMs? I think the answer to the first question is "no". Only SMs that talk to AAA infrastructure talk to AAA infrastructure. :-) I think the answer to the second question is that only AC models that employ the bits of information that are also provided in the updates made by AAA infrastucture could possibly utilize the mappings. So, for example, an access control model that did not have a group concept would have no need to do anything with the AAA update, though it *might* use the AAA update to ensure that the named user was recognized. ... > VACM depends on a configured vacmSecurityToGroupTable to function > properly. If EUSM-style authorization modifies the underlying > instrumentation, which then is reflected in the > vacmSecurityToGroupTable (just as if netconf or the CLI had been used > to configure the underlying instrumentation which is reflected in > vacmSecurityToGroupTable), then there is no **dependency** on a > specific configuration approach, and if the EUSM-style configuration > does not cause a Security model to manipualte > vacmSecurityToGroupTable, then no dependency is created by the SM and > ACM. ... I think we're in agreement here. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 04:06:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrnc-0005U9-L0; Tue, 02 Aug 2005 04:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzrna-0005TT-TC for isms@megatron.ietf.org; Tue, 02 Aug 2005 04:06:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28542 for ; Tue, 2 Aug 2005 04:06:52 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsK1-0001Ga-Fl for isms@ietf.org; Tue, 02 Aug 2005 04:40:26 -0400 Received: from pc6 (1Cust8.tnt107.lnd4.gbr.da.uu.net [213.116.62.8]) by galaxy.systems.pipex.net (Postfix) with SMTP id D0131E0001DB; Tue, 2 Aug 2005 09:06:19 +0100 (BST) Message-ID: <001b01c59730$89af0420$0601a8c0@pc6> From: "Tom Petch" To: "EKR" , References: <200508011412.KAA11431@ietf.org> <867jf5bppx.fsf@romeo.rtfm.com> Subject: Re: [Isms] Transport protocol discussion Date: Tue, 2 Aug 2005 09:05:02 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: Cc: Sent: Monday, August 01, 2005 6:12 PM Subject: Re: [Isms] Transport protocol discussion > "David B Harrington" writes: > > > Hi, > > > > I have some concerns about trying to select "the" ISMS transport > > protocol; why are we trying to choose "the" transport rather than > > trying to choose a security application (e.g. TLS, SASL, SSH) that > > might incidentally be able to run over different transport protocols? > > Or is that what is meant by "selecting a transport protocol"? > > > > If we talk about selecting one transport protocol (i.e. UDP vs TCP), > > do we have new research with independently-verifiable statistics about > > the reliability and performance of these protocols as a transport for > > SNMP? If we don't have new info, I would consider discussing this for > > the umpteenth time to be a waste of face-to-face meeting time. > > My $.02: > > The important transport question is whether support for datagram > mode is a requirement. If it is, that substantially constrains > the solution set--and potentially requires some more design work :) > > -Ekr > You've lost me here and I would like to understand. I see SNMP applications as datagram, message out message(s) back, not stream, not full duplex. If we have a full duplex stream transport, then a SNMP-like message exchange can be imposed on it, as the SNMP over TCP RFC demonstrates; needs work, but can be done. Tom PEtch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 04:37:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsGq-0007t6-0Y; Tue, 02 Aug 2005 04:37:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsGo-0007su-V7 for isms@megatron.ietf.org; Tue, 02 Aug 2005 04:37:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29837 for ; Tue, 2 Aug 2005 04:37:04 -0400 (EDT) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzsnF-0002XO-Hs for isms@ietf.org; Tue, 02 Aug 2005 05:10:39 -0400 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 632CB17058; Tue, 2 Aug 2005 01:36:49 -0700 (PDT) To: "Tom Petch" Subject: Re: [Isms] Transport protocol discussion References: <200508011412.KAA11431@ietf.org> <867jf5bppx.fsf@romeo.rtfm.com> <001b01c59730$89af0420$0601a8c0@pc6> From: Eric Rescorla Date: Tue, 02 Aug 2005 01:36:49 -0700 In-Reply-To: <001b01c59730$89af0420$0601a8c0@pc6> (Tom Petch's message of "Tue, 2 Aug 2005 09:05:02 +0200") Message-ID: <86zms0ag66.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org "Tom Petch" writes: >> My $.02: >> >> The important transport question is whether support for datagram >> mode is a requirement. If it is, that substantially constrains >> the solution set--and potentially requires some more design work :) >> >> -Ekr >> > > You've lost me here and I would like to understand. > > I see SNMP applications as datagram, message out message(s) back, not stream, > not full duplex. If we have a full duplex stream transport, then a SNMP-like > message exchange can be imposed on it, as the SNMP over TCP RFC demonstrates; > needs work, but can be done. Well, that's not datagram, that's record-oriented stream transport. The key difference being reliability and in-sequence delivery. One scenario where this is important is in real-time multimedia applications. If a packet gets lost, having it get retransmitted 500ms or 1s later doesn't do much good. What you *do* want is the next packet. But in reliable stream transport like TCP, packet n+1 can't be read until packet n is received. I'm not enough of an SNMP expert to say whether this is important in SNMP.... -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 04:54:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsXB-0003Rx-FZ; Tue, 02 Aug 2005 04:54:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzsX8-0003OY-Oc for isms@megatron.ietf.org; Tue, 02 Aug 2005 04:53:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00810 for ; Tue, 2 Aug 2005 04:53:56 -0400 (EDT) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzt3Z-0003I0-Ht for isms@ietf.org; Tue, 02 Aug 2005 05:27:30 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr001.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j728riKr019282 for ; Tue, 2 Aug 2005 08:53:44 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j728rikJ032326 for ; Tue, 2 Aug 2005 08:53:44 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080201534415388 for ; Tue, 02 Aug 2005 01:53:44 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 01:53:44 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 01:53:44 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 Aug 2005 04:53:43 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Transport protocol discussion Date: Tue, 2 Aug 2005 04:50:06 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C59290192F4F0@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Transport protocol discussion Thread-Index: AcWXPY1pmwn/9uxeQu+ahDCjjghozwAAPaqQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 02 Aug 2005 08:53:43.0259 (UTC) FILETIME=[AF78CAB0:01C5973F] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Well, that's not datagram, that's record-oriented stream transport. > The key difference being reliability and in-sequence delivery. > One scenario where this is important is in real-time multimedia > applications. If a packet gets lost, having it get retransmitted > 500ms or 1s later doesn't do much good. What you *do* want is > the next packet. But in reliable stream transport like TCP, > packet n+1 can't be read until packet n is received. > > I'm not enough of an SNMP expert to say whether this is important > in SNMP.... Normally, on a well-behaving network - this quality is not important to SNMP, and SNMP can live OK with reliable transport underneath it. When a network is in trouble - it is better not to depend on TCP reliability and ordering qualities. SNMP is supposed to work in both "good" and "troubled" networks. Thus IMHO it is important for SNMP not to depend on packet N arrival. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 05:23:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzszq-0006BC-VU; Tue, 02 Aug 2005 05:23:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzszp-00069e-HM for isms@megatron.ietf.org; Tue, 02 Aug 2005 05:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02119 for ; Tue, 2 Aug 2005 05:23:34 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztWH-0004YB-Qv for isms@ietf.org; Tue, 02 Aug 2005 05:57:10 -0400 Received: from pc6 (1Cust51.tnt106.lnd4.gbr.da.uu.net [213.116.60.51]) by galaxy.systems.pipex.net (Postfix) with SMTP id 9109AE0001BF; Tue, 2 Aug 2005 10:23:27 +0100 (BST) Message-ID: <01f801c5973b$4dd81a80$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC437@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] securityName Date: Tue, 2 Aug 2005 10:21:57 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: ; "Tom Petch" ; "Kaushik Narayan" Cc: Sent: Tuesday, August 02, 2005 12:30 AM Subject: RE: [Isms] securityName From: David B Harrington [mailto:ietfdbh@comcast.net] >Why are you waiting for a standards body to develop >something custom-fitted to your environment? David, Our environment, other than its vast size, isn't very different than a great many other end users. Ever since the 1980s my employer has been actively encouraging standards-based approaches because those approaches have the best business cases by far (i.e., custom-fit just doesn't scale over time). This is why all of my postings have been arguing for ISMS to make SNMPv3 directly be able to use standard authentication infrastructures such as Kerberos, PKI, and Radius. Eric Where you lose me is what you mean by PKI. The solutions we have spent most time on - SSH, TLS+/-SASL, DTLS - are or can be based on public keys, certificates (and Kerberos). So what more do you need to have a PKI solution? I have assumed that we are taking some form of PKI for granted in almost everything we do. Tom Petch (another with the concerns of large enterprises at heart) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 05:23:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzszr-0006Bs-B9; Tue, 02 Aug 2005 05:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzszp-00069v-M9 for isms@megatron.ietf.org; Tue, 02 Aug 2005 05:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02121 for ; Tue, 2 Aug 2005 05:23:35 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DztWG-0004YA-NR for isms@ietf.org; Tue, 02 Aug 2005 05:57:10 -0400 Received: from pc6 (1Cust51.tnt106.lnd4.gbr.da.uu.net [213.116.60.51]) by galaxy.systems.pipex.net (Postfix) with SMTP id 4965DE0000B8; Tue, 2 Aug 2005 10:23:23 +0100 (BST) Message-ID: <01f701c5973b$4cd32da0$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC435@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] securityName Date: Tue, 2 Aug 2005 10:21:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org A clarification, perhaps. Tom Petch ----- Original Message ----- From: "Fleischman, Eric" To: "Blumenthal, Uri" ; "Tom Petch" ; "Kaushik Narayan" Cc: Sent: Monday, August 01, 2005 11:44 PM Subject: RE: [Isms] securityName From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] >> and my personal goal for >> ISMS is for SNMP to directly leverage an existing authentication >>system within our deployment. >You seem to be missing the fact that another important >issue the WG is struggling with is mapping of whatever >credentials Security System returns, to ACM rules to >obtain access control decisions (without which >authentication is not very useful). Actually, I covered that point in the email message that I sent to the ISMS WG two minutes before the posting you have responded to. To re-iterate, what concerns me about these emails is that I believe the most foundational problem that the ISMS WG needs to resolve is "To what extent will we continue to leverage SNMPv3 USM and VACM?" Some postings presuppose that we won't change those interfaces. Others presuppose a whole-scale replacement. Until consensus is formed on this fundamental issue, I don't see how a long discussion of transport security is likely to be very fruitful. Eric, I don't see any proposal to change USM; borrow ideas from it perhaps to create a new xSM but USM must remain unaltered for those who are using it satisfactorily. PDUs with the appropriate value of securityModel will continue to get fed into it. VACM is in two parts, the admin (securityName to Group mapping MIB module) and the real thing, the rules defining what objects can have what done to them with what security by what groups. The latter is recognised as complex to administer (in the isms charter) but is out of scope for isms; again, I see no proposal to change that on this list. SNMPv3 Architecture defines generic models, of eg Message Processing, Access Control and Security and defines interfaces between these generic models in the form of ASIs. Where we got stuck six months ago and are still stuck is that a literal adherence to these ASIs renders our task difficult or impossible, depending on your subjective point of view, and this is the circle we continue to circumnavigate. The example of this that has attracted the most discussion is the securityName to Group mapping. My prejudice (which has some support) is that we must have the option to get this information from a security server and not require the administrators to have to do anything to maintain it in 'agents' to prevent a compromise of security. If you regard the generic Access Model AFI as sacrosanct, this presents a problem because this mapping is embedded in the Access Model and cannot be outsourced, regardless of whether the Access Model is VACM or anoACM. Juergen listed four options; for me, we have to do one, we cannot leave things as they stand. At the other end of the spectrum is a reading of the charter that says this is VACM, therefore we cannot change it; to me, that means winding up isms and starting xsms with a different charter. But it isn't the only example and I am slightly puzzled why the others seem not to get discussed. dbh has raised them several times; most are a consequence of moving integrity, authentication, encryption out of SNMP space and down into the depths of transport. The architecture did not allow for this either IMHO:-) so again we need new AFIs or caches or Architecture or ... (eg the xSM is the place where encryption is done- well, no it is done in SSH, not in SNMP space at all) Hope this helps you. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 05:34:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztAV-0003SD-8u; Tue, 02 Aug 2005 05:34:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DztAU-0003Ry-7F for isms@megatron.ietf.org; Tue, 02 Aug 2005 05:34:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02595 for ; Tue, 2 Aug 2005 05:34:35 -0400 (EDT) Received: from open-26-237.ietf63.ietf.org ([86.255.26.237] helo=dcn236-44.dcn.davis.ca.us) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dztgw-000502-Ge for isms@ietf.org; Tue, 02 Aug 2005 06:08:10 -0400 Received: by dcn236-44.dcn.davis.ca.us (Postfix, from userid 274) id F28C811D515; Tue, 2 Aug 2005 02:34:28 -0700 (PDT) From: Wes Hardaker To: EKR Subject: Re: [Isms] Transport protocol discussion Organization: Sparta References: <200508011412.KAA11431@ietf.org> <867jf5bppx.fsf@romeo.rtfm.com> Date: Tue, 02 Aug 2005 02:34:25 -0700 In-Reply-To: <867jf5bppx.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Mon, 01 Aug 2005 09:12:58 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 01 Aug 2005 09:12:58 -0700, Eric Rescorla said: Eric> My $.02: Eric> The important transport question is whether support for datagram Eric> mode is a requirement. If it is, that substantially constrains Eric> the solution set--and potentially requires some more design work Eric> :) [I'm not going to make the meeting later today due to a conflict, though I hope to listen from a different room... the end result is that I'll ramble on now instead ;-] I think it would be best, personally, to have a result with a choice. Unfortunately, that is looking less and less likely. The thing that concerns me the most is that we're trying to make a decision about the need for a datagram mode without any hard data (because none is available). We don't have any hard data papers anymore telling us how well modern TCP algorithms and network architectures have improved things. A lot of people like to state that the need for UDP is beyond us and that SNMP shouldn't need it anymore because TCP works just fine these days. But in actuality, I think the human-half of us is what is measuring that metric. I do have problems with TCP sessions all the time in broken networks (frequently wireless). But they're fixable by restarting the TCP session. The concrete example is that I've probably restarted ssh connections multiple times in this week alone because the TCP session properties had made my shell worthless from a responsiveness point of you. But it's easy to fix: I typed "exit" and relogged on. The delay was not huge for a human (5 seconds maybe), my shell history was restored through the use of a decent shell, and it happened at the right time (I noticed when things weren't responsive and made the decision myself). When using HTTP, I hit the stop button and then hit reload. Who, seriously, hasn't done that on a semi-regular basis because you the human know something is wrong and that will often fix the problem? My worry is that coding that human decision process about when to restart a broken TCP session because recovery will be faster by restarting than waiting for the TCP stack to fix the session will be impossible. I'm not at all convinced that TCP sessions are stable, based on my experience over the last few years. I do think they've gotten better, but I'm not willing to bet the management of my network on it. I'm not at all saying that UDP should be the only solution. I'm saying I don't know what the best choice is, but I'm fairly convinced that no one actually knows. I haven't seen any recent studies on the subject and I don't think we'd be doing the future service by forcing the selection of one or the other. I'd even be tempted to make 2 MUST transports, one UDP and one TCP because of this. But I can't believe I just said that, because now I'm about to get flamed. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 06:48:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuKN-0004CQ-4E; Tue, 02 Aug 2005 06:48:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuKL-00045s-2G for isms@megatron.ietf.org; Tue, 02 Aug 2005 06:48:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09112 for ; Tue, 2 Aug 2005 06:48:50 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzuqn-0000iC-5s for isms@ietf.org; Tue, 02 Aug 2005 07:22:26 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 730033A1620; Tue, 2 Aug 2005 12:48:23 +0200 (CEST) Date: Tue, 2 Aug 2005 12:48:23 +0200 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Transport protocol discussion Message-ID: <20050802104823.GB6323@open-31-253.ietf63.ietf.org> Mail-Followup-To: Wes Hardaker , EKR , dbharrington@comcast.net, isms@ietf.org References: <200508011412.KAA11431@ietf.org> <867jf5bppx.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 02:34:25AM -0700, Wes Hardaker wrote: [...] > My worry is that coding that human decision process about when to > restart a broken TCP session because recovery will be faster by > restarting than waiting for the TCP stack to fix the session will be > impossible. I'm not at all convinced that TCP sessions are stable, > based on my experience over the last few years. I do think they've > gotten better, but I'm not willing to bet the management of my network > on it. SNMP stacks usually come with a default retry/timeout strategy and they report some 'noResponse' error once you have had your retries. What happens next is either left to a human or some magic - I am not sure there is at the end that much difference in the magic here. [Yes, there are several technical differences I am ignoring here, but the point is that even with SNMPv1 you have to have some logic do deal with situations where your network is in trouble.] We simply have to give up the idea of a "one size fits all" security model. There are several trade offs to be made and operational requirements differ between environments. Personally, I see practical value in SNMP/SSH because it would enable me to transition to a secure version of SNMP with close to zero deployment costs. Eric Fleischman lives in a different environment and he surely likes to have SNMP/Kerberos because it allows him to transition to a secure version of SNMP with close to zero deployment costs. The question for me is whether we want to enable people to make such "close to zero deployment costs" transitions to secure SNMP or whether we continue to work on the "one size fits all" security approach, something we have been doing not too successful for more than a dozent years now. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 06:50:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuMF-0007yH-93; Tue, 02 Aug 2005 06:50:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzuMD-0007rH-8q for isms@megatron.ietf.org; Tue, 02 Aug 2005 06:50:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09192 for ; Tue, 2 Aug 2005 06:50:46 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzuse-0000lC-2n for isms@ietf.org; Tue, 02 Aug 2005 07:24:22 -0400 Received: from pc6 (1Cust83.tnt102.lnd4.gbr.da.uu.net [213.116.52.83]) by galaxy.systems.pipex.net (Postfix) with SMTP id 5ABA9E00025E; Tue, 2 Aug 2005 11:50:22 +0100 (BST) Message-ID: <027601c59747$73468200$0601a8c0@pc6> From: "Tom Petch" To: "EKR" , "Sam Hartman" References: <200507151618.MAA22560@ietf.org> <010101c59423$8a17a9e0$0601a8c0@pc6> <86oe8kb70n.fsf@romeo.rtfm.com> Subject: Re: [Isms] Comments on the BTSMS proposal Date: Tue, 2 Aug 2005 11:48:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 2.9 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Yes but ... Tom Petch ----- Original Message ----- From: "Eric Rescorla" To: "Sam Hartman" Cc: "Tom Petch" ; Sent: Saturday, July 30, 2005 6:20 PM Subject: Re: [Isms] Comments on the BTSMS proposal > Sam Hartman writes: > > >>>>>> "Tom" == Tom Petch writes: > > > > Tom> What the SNMPv3 architecture exposes is the level of security > > Tom> on the wire as (RFC3411 3.4.3. p.29) securityLevel - without > > Tom> authentication and without privacy (noAuthNoPriv) - with > > Tom> authentication but without privacy (authNoPriv) - with > > Tom> authentication and with privacy (authPriv) > > > > These seem like reasonable things for the encapsulation layer to > > communicate to the rest of SNMP. > > Trouble is, as dbh has pointed out, there is no provision for this in the architecture i.e. these securityLevel are requirements that the application passes to the dispatcher to the message processing subsystem to the security model which makes them happen on the wire and embeds flags to that effect in the ASN.1 which are then extracted by the recipient engine. When security is outside SNMP, at the transport layer, then somewhere in the SNMP engine needs to tell TMSM or transport what is wanted, which then says yes or no; and the level on the wire may exceed what is requested (eg authPriv v authNoPriv) which, IMHO, needs recording in the packet (where?) and needs passing up the stack of the recipient (how?). None of this is in the architecture or ASIs. And recall that the PDU is ASN.1 so the transport layer cannot readily set or reset flags in it, even in the space set aside for security parms ie we are in a sense modifying the SNMPv3 PDU format by moving the securityParms outside the ASN.1 SEQUENCE. Even the idea of a securityModel in a sense has to be modified in that by the time the securityModel is decoded from the ASN.1 by the recipient SNMP engine, it is too late; the security has already been done in the transport layer. > > > > I anticipate no problem with doing this for Ssh, Beep, SASL, TLS or > > DTLS. > > Agreed. > > Though it's worth noting that as far as I know all of these establish > a single connection-level set of security parameters. This contrasts > with the current USM, which lets you set per-message parameters. > > -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 07:20:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzuox-0003cB-4E; Tue, 02 Aug 2005 07:20:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzuov-0003by-CU for isms@megatron.ietf.org; Tue, 02 Aug 2005 07:20:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11859 for ; Tue, 2 Aug 2005 07:20:26 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzvLO-0002Qh-Iy for isms@ietf.org; Tue, 02 Aug 2005 07:54:02 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id E63443A16C8; Tue, 2 Aug 2005 13:20:18 +0200 (CEST) Date: Tue, 2 Aug 2005 13:20:18 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] Comments on the BTSMS proposal Message-ID: <20050802112018.GA6617@open-31-253.ietf63.ietf.org> Mail-Followup-To: Tom Petch , EKR , Sam Hartman , isms@ietf.org References: <200507151618.MAA22560@ietf.org> <86oe8kb70n.fsf@romeo.rtfm.com> <027601c59747$73468200$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <027601c59747$73468200$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 11:48:19AM +0200, Tom Petch wrote: > When security is outside SNMP, at the transport layer, then > somewhere in the SNMP engine needs to tell TMSM or transport what is > wanted, which then says yes or no; and the level on the wire may > exceed what is requested (eg authPriv v authNoPriv) which, IMHO, > needs recording in the packet (where?) and needs passing up the > stack of the recipient (how?). The TMSM document discusses this in some detail. I fail to see why you think it is necessary to touch the flags in the SNMP packet. Can you please elaborate? > None of this is in the architecture or ASIs. And recall that the > PDU is ASN.1 so the transport layer cannot readily set or reset > flags in it, even in the space set aside for security parms ie we > are in a sense modifying the SNMPv3 PDU format by moving the > securityParms outside the ASN.1 SEQUENCE. The TMSM document currently proposes to pass this information between the pieces of the split security model via a cache referred to by a cache reference. Again, I like to understand why you think it is necessary to change the SNMPv3 PDU format. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 07:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzv7i-0006RG-AN; Tue, 02 Aug 2005 07:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzv7g-0006NQ-78 for isms@megatron.ietf.org; Tue, 02 Aug 2005 07:39:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12781 for ; Tue, 2 Aug 2005 07:39:50 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzve8-0003Pa-Po for isms@ietf.org; Tue, 02 Aug 2005 08:13:26 -0400 Received: from wired-5-117.ietf63.ietf.org (wired-5-117.ietf63.ietf.org [86.255.5.117]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9CB981BAC4D for ; Tue, 2 Aug 2005 13:39:41 +0200 (CEST) Date: Tue, 02 Aug 2005 13:39:38 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: <4E356399148A5740A52ECCB5@wired-5-117.ietf63.ietf.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] agenda and presentations of today's session X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Eliot already posted a URL of his slides. Please find the agenda and all slides at Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 07:51:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvIX-0006ep-Rs; Tue, 02 Aug 2005 07:51:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvIX-0006eQ-DJ for isms@megatron.ietf.org; Tue, 02 Aug 2005 07:51:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13202 for ; Tue, 2 Aug 2005 07:51:03 -0400 (EDT) Message-Id: <200508021151.HAA13202@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzvoz-0003n8-LY for isms@ietf.org; Tue, 02 Aug 2005 08:24:39 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005080211505301400jd0die>; Tue, 2 Aug 2005 11:50:53 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Re: modularity Date: Tue, 2 Aug 2005 07:50:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <19799944.1122968868517.JavaMail.root@wamui-backed.atl.sa.earthlink.net> Thread-Index: AcWXNqFKHSncxPg8Rr+e+Jx8QvHHUAAG+1lQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > > And I think the best approach to this different sets of requirements > > is to define specific access control models that choose to > expose the > > information or not. That would seem a better approach than trying to > > redesign the architecture or the subsystem to meet a new > set of needs, > > when the architecture is already designed to accommodate multiple > > models to address different needs. > > Though this sounds nice, I don't like where it leads: for > each authentication > mechanism we might end up defining yet another access control > mechanism, This is exactly what I'm trying to avoid. There should be NO dependencies between specific security model and sepecific AC models. If you're designing an AC model to match each security model, you're not building per the RFC3411 architecture. > > If any specific AC model **depends** on a specific Security model to > > provide that trigger, then there are dependencies between > the models, > > and that is a bad thing. Likewise, if a specific security model > > **depends** on the AC model to apply the triggered authorizations, > > that creates a dependency. > > Agree. It should be able to work if the user/group mappings have been > configured through SNMP. But from an operational > perspective, we already > assume that user/group mappings will have been configured > before a request > can be successfully processed. The EUSM approach can be thought of as > just-in-time cache loading or just-in-time configuration, > depending on whether > or not you think these dynamic mappings should be visible to > management. And I am in agreement with the just-in-time dynamic mappings, as long as there are no dependencies between specific models. If the mappings you want to make visible are the raw RADIUS data, then you need to develop a RADIUS-specific MIB module to show them and if that depends on a RADIUS-specific security model, you've got dependencies. I suggested a generic user-to-group mapping MIB module, that is dynamically-configured behind-the-scenes from RADIUS and/or TACACS and/or .... and then an AC model can use the securityName ASI parameter for lookup purposes. I think this is just what you're arguing for, and I have no problem with this as long as we avoid any dependencies between specific models. So it would not be a requirement that all security models must support triggers to cause the population of this MIB module, and it would not be a requirement that all AC models utilize this MIB module. The specific security model does not depend on a specific AC model to provide access control, and a specific AC model does not depend on a specific security model to trigger the population. I could live with that. > I think there is no need for SM (security model) to know that > the AAA event will be routed to > the AC (access control) subsystem. I think there is no need > for the AC system to know what > caused the AAA information to arrive. There is, > unfortunately, a need for > the SM to know when the triggered AAA exchanges have finished. Why does the SM need to know this? > ... > > I think we're in agreement here. > Agreed David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 08:02:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvTg-0001si-H9; Tue, 02 Aug 2005 08:02:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvTf-0001sd-Py for isms@megatron.ietf.org; Tue, 02 Aug 2005 08:02:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13599 for ; Tue, 2 Aug 2005 08:02:34 -0400 (EDT) Message-Id: <200508021202.IAA13599@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzw08-0004C4-KP for isms@ietf.org; Tue, 02 Aug 2005 08:36:09 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080212022501100hv04pe>; Tue, 2 Aug 2005 12:02:25 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , Subject: RE: [Isms] Transport protocol discussion Date: Tue, 2 Aug 2005 08:02:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <3DEC199BD7489643817ECA151F7C59290192F4F0@pysmsx401.amr.corp.intel.com> Thread-Index: AcWXPY1pmwn/9uxeQu+ahDCjjghozwAAPaqQAAaUWCA= X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > > SNMP is supposed to work in both "good" and "troubled" networks. Thus > IMHO it is important for SNMP not to depend on packet N arrival. > And I agree that this is an important consideration when a network is broken, and for situations where you are trying to detect a broken network, but probably 98% of SNMP usage occurs on non-broken networks, where depending on packet N arrival is not a problem. Having UDP transport available for heartbeat polling (polling for sysuptime to make sure you get an answer), and to tweak a few variables in a configuration is best done using UDP. To retrieve routing tables and other large masses of SNMP data would be better done over a streaming protocol like TCP. This could have implications for future MIB module development, in that it would be good to identify the use cases for the MIB module; if it is expected that certain tables will get large, the MIB module should describe that it is expected to be run over a TCP connection, not a UDP connection, but the "lastChanged" timestamp for the table can be polled effectively using UDP. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 08:03:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvU4-00021o-Te; Tue, 02 Aug 2005 08:03:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzvU3-00021g-9G for isms@megatron.ietf.org; Tue, 02 Aug 2005 08:02:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13634 for ; Tue, 2 Aug 2005 08:02:57 -0400 (EDT) Received: from pop06.mail.atl.earthlink.net ([207.69.200.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzw0V-0004D6-GN for isms@ietf.org; Tue, 02 Aug 2005 08:36:32 -0400 Received: from wamui-billy.atl.sa.earthlink.net ([209.86.224.27]) by pop06.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzvTw-0002Ty-00 for isms@ietf.org; Tue, 02 Aug 2005 08:02:52 -0400 Message-ID: <6461899.1122984172231.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 07:02:52 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] Re: modularity Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: David B Harrington > Sent: Aug 2, 2005 6:50 AM > To: 'Randy Presuhn' , isms@ietf.org > Subject: RE: [Isms] Re: modularity ... > >There is, > > unfortunately, a need for > > the SM to know when the triggered AAA exchanges have finished. > > Why does the SM need to know this? ... Not strictly the SM per se, but one wouldn't want to hand the PDU to the application for processing before any necessary user/group mapping updates have happened. Otherwise there's a processing race condition. (If the user/group mapping arrives in the same PDU as the authentication-related stuff, and if the implementation-specific internal API that hands this information to the access control stuff is synchronous, there's no problem. If, for example, the mapping were to arrive later, then there could be a problem if there is no mechanism internal to the implentations to serialize things.) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 10:08:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxRO-0001ek-6Q; Tue, 02 Aug 2005 10:08:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzxRL-0001YT-TP for isms@megatron.ietf.org; Tue, 02 Aug 2005 10:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21150 for ; Tue, 2 Aug 2005 10:08:17 -0400 (EDT) Message-Id: <200508021408.KAA21150@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzxxn-0001EF-Nq for isms@ietf.org; Tue, 02 Aug 2005 10:41:54 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080214080701300qht3le>; Tue, 2 Aug 2005 14:08:07 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Re: modularity Date: Tue, 2 Aug 2005 10:08:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6461899.1122984172231.JavaMail.root@wamui-billy.atl.sa.earthlink.net> Thread-Index: AcWXWotP1FTAtP1KRXqQ+AuVof3mgwAEMtNw X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org So the ACM needs to know whether the data has finished being updated for that user. Assuming something akin to rowstatus (for potentially multiple rows, however) indexed by the securityname, the ACM can determine that an update is in progress and can wait for completiton or (after suitable time, aborts). dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, August 02, 2005 8:03 AM > To: isms@ietf.org > Subject: RE: [Isms] Re: modularity > > Hi - > > > From: David B Harrington > > Sent: Aug 2, 2005 6:50 AM > > To: 'Randy Presuhn' , isms@ietf.org > > Subject: RE: [Isms] Re: modularity > ... > > >There is, > > > unfortunately, a need for > > > the SM to know when the triggered AAA exchanges have finished. > > > > Why does the SM need to know this? > ... > > Not strictly the SM per se, but one wouldn't want to hand the > PDU to the > application for processing before any necessary user/group > mapping updates > have happened. Otherwise there's a processing race > condition. (If the user/group > mapping arrives in the same PDU as the authentication-related > stuff, and if > the implementation-specific internal API that hands this > information to the > access control stuff is synchronous, there's no problem. If, > for example, > the mapping were to arrive later, then there could be a > problem if there is > no mechanism internal to the implentations to serialize things.) > > Randy > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 11:33:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzylz-0000jF-GS; Tue, 02 Aug 2005 11:33:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzyly-0000j7-OK for isms@megatron.ietf.org; Tue, 02 Aug 2005 11:33:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29221 for ; Tue, 2 Aug 2005 11:33:40 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzIR-0005mU-SA for isms@ietf.org; Tue, 02 Aug 2005 12:07:18 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 5EE3A3A1A33; Tue, 2 Aug 2005 17:33:25 +0200 (CEST) Date: Tue, 2 Aug 2005 17:33:25 +0200 From: Juergen Schoenwaelder To: isms@ietf.org Message-ID: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> Mail-Followup-To: isms@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: Subject: [Isms] charter proposal X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. Attached is a charter proposal for rechartering the ISMS WG based on the discussions during today's WG meeting. Lets bash it here on the list to converge it into a usable charter that helps us in getting the work we agreed on today done. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="isms.txt" Integrated Security Model for SNMP (isms) ========================================= Chair(s): N.N. N.N. Security Area Director(s) Steven Bellovin Russell Housley Security Area Advisor: Steven Bellovin ; Tue, 2 Aug 2005 12:07:55 -0400 (EDT) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzpd-0007YS-IF for isms@ietf.org; Tue, 02 Aug 2005 12:41:35 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA15428; Tue, 2 Aug 2005 11:07:37 -0500 (CDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j72G7av00342; Tue, 2 Aug 2005 11:07:36 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 2 Aug 2005 09:07:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Tue, 2 Aug 2005 09:07:14 -0700 Message-ID: <474EEBD229DF754FB83D256004D021080EC443@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName Thread-Index: AcWXQ9jlNhv6EvSJQlaAxZ8dV1pDKwANhyqw From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 02 Aug 2005 16:07:32.0934 (UTC) FILETIME=[4A5DFE60:01C5977C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >Eric > >Where you lose me is what you mean by PKI. =20 >The solutions we have spent most time on - SSH,=20 >TLS+/-SASL, DTLS - are or can be based on public=20 >keys, certificates (and Kerberos). So what more=20 >do you need to have a PKI solution? I have=20 >assumed that we are taking some form of PKI for=20 >granted in almost everything we do. > >Tom Petch Tom, I am in harmony with using SSH, TLS+/-SASL, or DTLS. I very much appreciate the authentication system flexibility avaialable from these approaches. (Yes, PKI =3D=3D Certificates.)=20 However, I am not clear how we are planning on adding additional privacy and authentication mechanisms and still leave SNMPv3 USM and VACM untouched. Where are the interfaces between the two systems (the old and new) being drawn? --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:20:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzLx-00017g-BX; Tue, 02 Aug 2005 12:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzLv-000159-RK for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:10:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02254 for ; Tue, 2 Aug 2005 12:10:48 -0400 (EDT) Message-Id: <200508021610.MAA02254@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzzsQ-0007fq-GA for isms@ietf.org; Tue, 02 Aug 2005 12:44:27 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050802161028012006g3v0e>; Tue, 2 Aug 2005 16:10:29 +0000 From: "David B Harrington" To: , Subject: RE: [Isms] charter proposal Date: Tue, 2 Aug 2005 12:10:21 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> Thread-Index: AcWXd7tYtm1qLSXzQ8iOaD2Ts0kapwAAYM1A X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I think the ADs need to be updated. Suggested modifications: "SSH is a widely deployed access protocol preferred by many operators to manage network devices. In order to leverage the authentication information already accessible on such devices, the ISMS working group will define a new SNMP security model which utilizes the SSH protocol to provide message security services for SNMP. Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. Devices utilizing SSH often support the integration of user authentication with AAA systems via protocols such as RADIUS, which provide authorization information in the same message exchange session. The TMSM document will describe how authorization information accessible through a TMSM authentication mechanism might be cached or otherwise captured so that it can later be made available to the AC subsystem, but it is out of scope to define how the AC system gets such information. If the SSH security model provides a tie-in to a AAA system, it will be acceptable to identify how the information can be cached within the constraints of the TMSM model. The solution must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411. Any architectural extensions required to achieve the goals stated above should be defined in the TMSM document in such a way that additional transport mapping security models may be defined in the future." [I am concerned about having the RADIUS tie-in in this charter, but the TMSM is basically extending the architecture of SNMPv3, and if the security model will "trigger the AAA infrastrcuture for authorization information", it really needs to be discussed within the context of the TMSM document.] David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, August 02, 2005 11:33 AM > To: isms@ietf.org > Subject: [Isms] charter proposal > > Hi. > > Attached is a charter proposal for rechartering the ISMS WG based on > the discussions during today's WG meeting. Lets bash it here on the > list to converge it into a usable charter that helps us in getting the > work we agreed on today done. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:20:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzRQ-0002Qs-1E; Tue, 02 Aug 2005 12:16:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzRO-0002QE-DM for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:16:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02730 for ; Tue, 2 Aug 2005 12:16:25 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dzzxr-0007yp-Jg for isms@ietf.org; Tue, 02 Aug 2005 12:50:04 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzzRI-00034T-00 for isms@ietf.org; Tue, 02 Aug 2005 12:16:24 -0400 Message-ID: <6998709.1122999384454.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 11:16:24 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] charter proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - Though I agree that distribution of VACM (or other access control model) rules should be out of scope, I think the discussion of the last few days gives us good reason to want to not preclude permitting the solution to address the user/group question. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:22:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzX4-0008CG-JI; Tue, 02 Aug 2005 12:22:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzX2-0008C6-29 for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:22:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03072 for ; Tue, 2 Aug 2005 12:22:15 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E003W-0008FP-HT for isms@ietf.org; Tue, 02 Aug 2005 12:55:54 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1DzzWv-0004Z6-00 for isms@ietf.org; Tue, 02 Aug 2005 12:22:13 -0400 Message-ID: <13936017.1122999733132.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 11:22:12 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] securityName Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Fleischman, Eric" > Sent: Aug 2, 2005 11:07 AM > To: Tom Petch > Cc: isms@ietf.org > Subject: RE: [Isms] securityName ... > However, I am not clear how we are planning on adding additional privacy > and authentication mechanisms and still leave SNMPv3 USM and VACM > untouched. Where are the interfaces between the two systems (the old and > new) being drawn? ... That is a key point of the SNMPv3 architecture: new interfaces between the old and new mechanisms should not be needed. They should plug in using the *conceptual* interface provided by the ASIs, which are really just a way of modularizing the specification, not necessarily an implementation. The addition of a new authentication mechanism should not require any changes whatsoever to VACM. The introduction of a new privacy mechanism should not require any changes whatsoever to VACM. If it does, something is very broken. Randy Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:33:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzhh-0006n1-Jp; Tue, 02 Aug 2005 12:33:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzhg-0006km-J7 for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:33:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03657 for ; Tue, 2 Aug 2005 12:33:17 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00E9-0000Go-Dw for isms@ietf.org; Tue, 02 Aug 2005 13:06:56 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j72GX1Lb013066; Tue, 2 Aug 2005 09:33:01 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j72GWu0J002922; Tue, 2 Aug 2005 09:32:56 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j72GWteB002917; Tue, 2 Aug 2005 09:32:55 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 2 Aug 2005 09:32:55 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: RE: [Isms] charter proposal In-Reply-To: <200508021610.MAA02254@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, I support the below, since it will allow for the following.... On the managed system, there can be created rules for where to "resolve" authentication and authorization. For example, a managed system may suport both local and "remote" (via Radius) resolution. A simple rule may be based on ordering of the authen/author resolvers, such as "set authentication admin resolvers (local, r1)" This rule would try to authenticate a user first locally, and then "remotely" at Radius server r1. Other rules could be supported based on, for example, a pattern match of the the name, the source IP address, or whether is was from a serial port. Likewise, the managed system could support rules for where to get authorization info, which could "override" VACM info (such as group name), or extend it (such as allowed hours of use). PS Such rules already exist in commercial products for administrative access. On Tue, 2 Aug 2005, David B Harrington wrote: > Hi, > > I think the ADs need to be updated. > > Suggested modifications: > > "SSH is a widely deployed access protocol preferred by many operators > to manage network devices. In order to leverage the authentication > information already accessible on such devices, the ISMS working group > will define a new SNMP security model which utilizes the SSH protocol > to provide message security services for SNMP. > > Work on new access control models or centralized administration of > View-based Access Control Model (VACM) rules and mappings is outside > the scope of the working group. Devices utilizing SSH often support > the integration of user authentication with AAA systems via protocols > such as RADIUS, which provide authorization information in the same > message exchange session. The TMSM document will describe how > authorization information accessible through a TMSM authentication > mechanism might be cached or otherwise captured so that it can later > be made available to the AC subsystem, but it is out of scope to > define how the AC system gets such information. If the SSH security > model provides a tie-in to a AAA system, it will be acceptable to > identify how the information can be cached within the constraints of > the TMSM model. > > The solution must not modify any other aspects of SNMPv3 protocol as > defined in STD 62 (e.g., it must not create new PDU types). It should > also be compliant with the security model architectural block of > SNMPv3, as outlined in RFC 3411. Any architectural extensions required > to achieve the goals stated above should be defined in the TMSM > document in such a way > that additional transport mapping security models may be defined in > the future." > > > [I am concerned about having the RADIUS tie-in in this charter, but > the TMSM is basically extending the architecture of SNMPv3, and if the > security model will "trigger the AAA infrastrcuture for authorization > information", it really needs to be discussed within the context of > the TMSM document.] > > David Harrington > dbharrington@comcast.net > > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, August 02, 2005 11:33 AM > > To: isms@ietf.org > > Subject: [Isms] charter proposal > > > > Hi. > > > > Attached is a charter proposal for rechartering the ISMS WG based on > > the discussions during today's WG meeting. Lets bash it here on the > > list to converge it into a usable charter that helps us in getting > the > > work we agreed on today done. > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:36:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzkT-0008Ng-Cv; Tue, 02 Aug 2005 12:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzzkQ-0008J5-KT for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:36:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03799 for ; Tue, 2 Aug 2005 12:36:07 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Gt-0000Ns-KA for isms@ietf.org; Tue, 02 Aug 2005 13:09:47 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 0A9BA3A1BC9; Tue, 2 Aug 2005 18:35:51 +0200 (CEST) Date: Tue, 2 Aug 2005 18:35:51 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] charter proposal Message-ID: <20050802163551.GA7399@open-31-253.ietf63.ietf.org> Mail-Followup-To: David B Harrington , isms@ietf.org References: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> <20050802161036.ADAD4393B0@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802161036.ADAD4393B0@hermes.iu-bremen.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 12:10:21PM -0400, David B Harrington wrote: > [I am concerned about having the RADIUS tie-in in this charter, but > the TMSM is basically extending the architecture of SNMPv3, and if the > security model will "trigger the AAA infrastrcuture for authorization > information", it really needs to be discussed within the context of > the TMSM document.] There is a reason why my text mentioned Radius as a source for user authentication and not authorization... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:41:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzpx-0003uR-Ey; Tue, 02 Aug 2005 12:41:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzzpv-0003uJ-Lf for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:41:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03989 for ; Tue, 2 Aug 2005 12:41:48 -0400 (EDT) Message-Id: <200508021641.MAA03989@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00MQ-0000b3-GF for isms@ietf.org; Tue, 02 Aug 2005 13:15:27 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080216413801300qdujne>; Tue, 2 Aug 2005 16:41:38 +0000 From: "David B Harrington" To: Date: Tue, 2 Aug 2005 12:41:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWXgQlKi/SDUM8gR62Y0VwXGkoyQQ== X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Separation of authn and authz when using RADIUS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I have a question. I don't have a through understanding of RADIUS and my terminology might be slightly wrong, but I'd like to see if my understanding of the abstract flow of messages is accurate. Please keep this thread only about my question so we can retire this thread once my question is answered. In RADIUS, a client sends an Access-Request to a RADIUS server; as part of that process, the client establishes a security association between the client and server (the server validates the client). The client identifies the user for whom access is requested, and provides to the server the authentication credentials provided by the user (in various ways depending on the chosen authentication mechanism), and may also provide such factors as port. If found acceptable, the server returns an "Access-Accept" which might include the type of service, packet filter IDs, etc. Does RADIUS support the ability of the client to go back to the RADIUS server later to ask for additional service acceptance, or are all service attributes, filter IDs, etc. returned in the "Access-Accept" message? i.e. can RADIUS handle the user-authentication as one step (ending with the Access-Accept" nad then go back for authorization information (e.g. filterIDs)? Applied to an SSH model, if the SSH authentication creates a RADIUS session, is there a RADIUS session identifier that could be made available to the AC subsystem, which can subsequently query (or trigger the query of) the RADIUS server for authorization information (say an SNMP filterID used to name a VACM group) for the appropriate principal using the same RADIUS session? My thinking is that, given the securityModel and securityName via the ASI, a RADIUS ACM might be able to ask the co-resident RADIUS client to query for the groups/policies to apply to the user and populate the model's securityToGroupTable. If that is possible, we shouldn't need to include the AAA connection in the charter. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 12:54:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E002M-00032Y-8U; Tue, 02 Aug 2005 12:54:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E002K-0002z2-B1 for isms@megatron.ietf.org; Tue, 02 Aug 2005 12:54:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04893 for ; Tue, 2 Aug 2005 12:54:36 -0400 (EDT) Message-Id: <200508021654.MAA04893@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00Yp-0001Fs-5w for isms@ietf.org; Tue, 02 Aug 2005 13:28:16 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050802165421012006dqgte>; Tue, 2 Aug 2005 16:54:21 +0000 From: "David B Harrington" To: Subject: RE: [Isms] charter proposal Date: Tue, 2 Aug 2005 12:54:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050802163551.GA7399@open-31-253.ietf63.ietf.org> Thread-Index: AcWXgEBIXjhIUsXiS0a4caKCMGLwkAAAVRHg X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Hmmmm. I am of the impression that, as a source for authentication, the use of AAA is an implementation-dependent detail of the SSH authentication; whether SSH authentication relies on RADIUS or AAA or local users to authenticate the transport connection and the user should be transparent to the SNMP engine, shouldn't it? If so, then it doesn't belong in the charter at all. Where we run into the problem is if a TMSM also needs to somehow capture the authorization information returned by AAA so the AC subsystem can use it later. If we want that feature, and we seem to have a lot of people suggesting it is an important feature to support, then we need to address how to standardize that feature so future TMSM security models handle it in a compatible way. Are my assumptions incorrect? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, August 02, 2005 12:36 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] charter proposal > > On Tue, Aug 02, 2005 at 12:10:21PM -0400, David B Harrington wrote: > > > [I am concerned about having the RADIUS tie-in in this charter, but > > the TMSM is basically extending the architecture of SNMPv3, > and if the > > security model will "trigger the AAA infrastrcuture for > authorization > > information", it really needs to be discussed within the context of > > the TMSM document.] > > There is a reason why my text mentioned Radius as a source for user > authentication and not authorization... > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:01:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0096-0000zi-7G; Tue, 02 Aug 2005 13:01:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0094-0000yL-Ha for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:01:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05559 for ; Tue, 2 Aug 2005 13:01:34 -0400 (EDT) Received: from pop05.mail.atl.earthlink.net ([207.69.200.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00fZ-0001ch-IG for isms@ietf.org; Tue, 02 Aug 2005 13:35:14 -0400 Received: from wamui-valley.atl.sa.earthlink.net ([209.86.224.52]) by pop05.mail.atl.earthlink.net with esmtp (Exim 3.36 #10) id 1E008z-0007Jt-00 for isms@ietf.org; Tue, 02 Aug 2005 13:01:33 -0400 Message-ID: <18808224.1123002093748.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Date: Tue, 2 Aug 2005 12:01:33 -0500 (GMT-05:00) From: Randy Presuhn To: isms@ietf.org Subject: RE: [Isms] charter proposal Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Randy Presuhn List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: David B Harrington > Sent: Aug 2, 2005 11:54 AM > To: j.schoenwaelder@iu-bremen.de > Cc: isms@ietf.org > Subject: RE: [Isms] charter proposal ... > Hmmmm. I am of the impression that, as a source for authentication, > the use of AAA is an implementation-dependent detail of the SSH > authentication; whether SSH authentication relies on RADIUS or AAA or > local users to authenticate the transport connection and the user > should be transparent to the SNMP engine, shouldn't it? If so, then it > doesn't belong in the charter at all. ... But, ironically, the set of AAA solutions supported by implementations will be a key factor in whether this suceeds as an *integration* effort, rather than just another security protocol effort. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:06:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00DT-0006o2-99; Tue, 02 Aug 2005 13:06:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00DR-0006m4-KT for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:06:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06023 for ; Tue, 2 Aug 2005 13:06:06 -0400 (EDT) Message-Id: <200508021706.NAA06023@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00jw-0001us-N9 for isms@ietf.org; Tue, 02 Aug 2005 13:39:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080217055401300qg88qe>; Tue, 2 Aug 2005 17:05:54 +0000 From: "David B Harrington" To: Date: Tue, 2 Aug 2005 13:05:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWXhGzqOCjq2pvdS7WAHSM35WxChA== X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Charter proposal X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, As Uri pointed out today, we have not determined whether our approach going forward should establish a "session" to amortize the security overhead across multiple SNMP messages. Is that something we should be planning on when writing the SSH proposal and updating the TMSM document? (yeah, I know we haven't agreed on the charter yet, but should we be addressing this issue in the proposals being prepared?) Is anybody willing to contribute some text about how the session concept will fit within a TMSM environment, and how that fits within the SNMPv3 architecture so a session-based security model can coexist with non-session security models, such as USM? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:06:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Dz-0007c0-0q; Tue, 02 Aug 2005 13:06:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Dx-0007YL-1V for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:06:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06056 for ; Tue, 2 Aug 2005 13:06:37 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00kT-0001w7-29 for isms@ietf.org; Tue, 02 Aug 2005 13:40:17 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 625C13A1C51; Tue, 2 Aug 2005 19:06:25 +0200 (CEST) Date: Tue, 2 Aug 2005 19:06:25 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] charter proposal Message-ID: <20050802170625.GA7466@open-31-253.ietf63.ietf.org> Mail-Followup-To: David B Harrington , isms@ietf.org References: <20050802163551.GA7399@open-31-253.ietf63.ietf.org> <20050802165929.8918539A18@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802165929.8918539A18@hermes.iu-bremen.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 12:54:06PM -0400, David B Harrington wrote: > Hmmmm. I am of the impression that, as a source for authentication, > the use of AAA is an implementation-dependent detail of the SSH > authentication; whether SSH authentication relies on RADIUS or AAA or > local users to authenticate the transport connection and the user > should be transparent to the SNMP engine, shouldn't it? If so, then it > doesn't belong in the charter at all. I agree that this is fully transparent to the SNMP engine. On the motivational side of the charter, I thought it might be worth to mention this since not everybody might be aware that SSH authentication decisions can easily be outsourced to AAA servers, something that was requested in the past by operators. > Where we run into the problem is if a TMSM also needs to somehow > capture the authorization information returned by AAA so the AC > subsystem can use it later. If we want that feature, and we seem to > have a lot of people suggesting it is an important feature to support, > then we need to address how to standardize that feature so future TMSM > security models handle it in a compatible way. I simply did not put this in the charter since I do not yet understand the dimension of this problem. I need to learn more how AAA servers provide this authorization information and how it looks like. Perhaps someone here can educate me or point to the relevant specs to read. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:08:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Fs-0002Mp-IZ; Tue, 02 Aug 2005 13:08:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Fr-0002Mh-Nd for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:08:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06156 for ; Tue, 2 Aug 2005 13:08:36 -0400 (EDT) Message-Id: <200508021708.NAA06156@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00mL-0001zI-Q4 for isms@ietf.org; Tue, 02 Aug 2005 13:42:16 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080217081801100akd09e>; Tue, 2 Aug 2005 17:08:18 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] charter proposal Date: Tue, 2 Aug 2005 13:08:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <18808224.1123002093748.JavaMail.root@wamui-valley.atl.sa.earthlink.net> Thread-Index: AcWXg+PmdgCscIZxQ/6FEmNa+b6oiAAAJ9kw X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org As they said in the 70s, "Right on, brother." dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, August 02, 2005 1:02 PM > To: isms@ietf.org > Subject: RE: [Isms] charter proposal > > Hi - > > > From: David B Harrington > > Sent: Aug 2, 2005 11:54 AM > > To: j.schoenwaelder@iu-bremen.de > > Cc: isms@ietf.org > > Subject: RE: [Isms] charter proposal > ... > > Hmmmm. I am of the impression that, as a source for authentication, > > the use of AAA is an implementation-dependent detail of the SSH > > authentication; whether SSH authentication relies on RADIUS > or AAA or > > local users to authenticate the transport connection and the user > > should be transparent to the SNMP engine, shouldn't it? If > so, then it > > doesn't belong in the charter at all. > ... > > But, ironically, the set of AAA solutions supported by implementations > will be a key factor in whether this suceeds as an > *integration* effort, > rather than just another security protocol effort. > > Randy > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:21:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00S9-0000LD-Gr; Tue, 02 Aug 2005 13:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00S8-0000Jf-Dx for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06692 for ; Tue, 2 Aug 2005 13:21:16 -0400 (EDT) Message-Id: <200508021721.NAA06692@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E00ye-0002Vh-H0 for isms@ietf.org; Tue, 02 Aug 2005 13:54:56 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080217211001100ama4re>; Tue, 2 Aug 2005 17:21:10 +0000 From: "David B Harrington" To: Subject: RE: [Isms] charter proposal Date: Tue, 2 Aug 2005 13:21:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050802170625.GA7466@open-31-253.ietf63.ietf.org> Thread-Index: AcWXhITVK200CmI2TI22wNlbsIVppQAAFoLQ X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, >From my limited experince looking at the problem, If we start to discuss HOW the SSH will support AAA, then we will need to discuss 1) which AAA protocol? 2) which AAA attributes contain the authorization information 2a) should we use filterID, which is supposed to be for packet filtering, not policy management 2b) should we define a new standard attribute for this purpose, since the only attributes available don't provide the granularity we need? 2c) should vendors develop their own VSAs to provide this granularity? 3) will we standardize the naming mechanisms for ACM policies? 4) will we support user-to-group mappings or user-to-policy mappings (i.e. non-group policies)? And so on.... I'd like to avoid the whole discussion of how to connect SNMP authorization to AAA authorization for now, and simply focus on how to connect SSH user-auth to SNMP user-auth. However, if the WG REALLY wants to trigger/capture AAA-authorization via the security model, we'll need to open that whole can of worms, because it will require changes to the architecture or an agreement of how to do it outside the architecture (wink, wink). David Harrington dbharrington@comcast.net > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Tuesday, August 02, 2005 1:06 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: Re: [Isms] charter proposal > > On Tue, Aug 02, 2005 at 12:54:06PM -0400, David B Harrington wrote: > > > Hmmmm. I am of the impression that, as a source for authentication, > > the use of AAA is an implementation-dependent detail of the SSH > > authentication; whether SSH authentication relies on RADIUS > or AAA or > > local users to authenticate the transport connection and the user > > should be transparent to the SNMP engine, shouldn't it? If > so, then it > > doesn't belong in the charter at all. > > I agree that this is fully transparent to the SNMP engine. On the > motivational side of the charter, I thought it might be worth to > mention this since not everybody might be aware that SSH > authentication decisions can easily be outsourced to AAA servers, > something that was requested in the past by operators. > > > Where we run into the problem is if a TMSM also needs to somehow > > capture the authorization information returned by AAA so the AC > > subsystem can use it later. If we want that feature, and we seem to > > have a lot of people suggesting it is an important feature > to support, > > then we need to address how to standardize that feature so > future TMSM > > security models handle it in a compatible way. > > I simply did not put this in the charter since I do not yet understand > the dimension of this problem. I need to learn more how AAA servers > provide this authorization information and how it looks like. Perhaps > someone here can educate me or point to the relevant specs to read. > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:27:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Xp-0006O4-PN; Tue, 02 Aug 2005 13:27:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00Xn-0006Nw-Oa for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:27:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06991 for ; Tue, 2 Aug 2005 13:27:08 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E014H-0002kW-BW for isms@ietf.org; Tue, 02 Aug 2005 14:00:48 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Aug 2005 10:26:59 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j72HQsIt003732; Tue, 2 Aug 2005 10:26:54 -0700 (PDT) Message-Id: <6.2.0.14.0.20050802101937.040f1d48@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 02 Aug 2005 10:26:58 -0700 To: dbharrington@comcast.net From: Kaushik Narayan Subject: Re: [Isms] Separation of authn and authz when using RADIUS In-Reply-To: <200508021641.MAA03989@ietf.org> References: <200508021641.MAA03989@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I think it is safe to assume that for purposes of administrative access, protocols such as RADIUS and TACACS+ should be treated as being stateless. i.e. Although you could perform authentication and authorization as part of separate requests, the NAS would need to pass principal name in the authorization request. We should not expect the AAA server to manage a user session and map a session ID to a principal. p.s. - Note that I specifically mentioned administrative access, since some RADIUS server implementations do track user session state but that is largely for network access use cases such as accounting/billing, COA etc. regards, kaushik! At 09:41 AM 8/2/2005, David B Harrington wrote: >I have a question. I don't have a through understanding of RADIUS and >my terminology might be slightly wrong, but I'd like to see if my >understanding of the abstract flow of messages is accurate. Please >keep this thread only about my question so we can retire this thread >once my question is answered. > >In RADIUS, a client sends an Access-Request to a RADIUS server; as >part of that process, the client establishes a security association >between the client and server (the server validates the client). The >client identifies the user for whom access is requested, and provides >to the server the authentication credentials provided by the user (in >various ways depending on the chosen authentication mechanism), and >may also provide such factors as port. If found acceptable, the server >returns an "Access-Accept" which might include the type of service, >packet filter IDs, etc. > >Does RADIUS support the ability of the client to go back to the RADIUS >server later to ask for additional service acceptance, or are all >service attributes, filter IDs, etc. returned in the "Access-Accept" >message? i.e. can RADIUS handle the user-authentication as one step >(ending with the Access-Accept" nad then go back for authorization >information (e.g. filterIDs)? > >Applied to an SSH model, if the SSH authentication creates a RADIUS >session, is there a RADIUS session identifier that could be made >available to the AC subsystem, which can subsequently query (or >trigger the query of) the RADIUS server for authorization information >(say an SNMP filterID used to name a VACM group) for the appropriate >principal using the same RADIUS session? > >My thinking is that, given the securityModel and securityName via the >ASI, a RADIUS ACM might be able to ask the co-resident RADIUS client >to query for the groups/policies to apply to the user and populate the >model's securityToGroupTable. If that is possible, we shouldn't need >to include the AAA connection in the charter. > >David Harrington >dbharrington@comcast.net > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 13:52:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00w5-00063Q-Nt; Tue, 02 Aug 2005 13:52:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E00w4-00063F-46 for isms@megatron.ietf.org; Tue, 02 Aug 2005 13:52:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08226 for ; Tue, 2 Aug 2005 13:52:14 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E01Sa-0003lj-RQ for isms@ietf.org; Tue, 02 Aug 2005 14:25:53 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 02 Aug 2005 10:52:06 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j72Hq5JM003241; Tue, 2 Aug 2005 10:52:05 -0700 (PDT) Message-Id: <6.2.0.14.0.20050802102835.0360c218@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 02 Aug 2005 10:52:03 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] charter proposal In-Reply-To: <200508021721.NAA06692@ietf.org> References: <20050802170625.GA7466@open-31-253.ietf63.ietf.org> <200508021721.NAA06692@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I am not sure we need elaborate AAA work in order to allow for linkages between ISMS authentication and SNMPv3 VACM. Ideally the RADIUS work for this should happen in RADEXT and I believe Dave Nelson and Greg Weber already have an ID that would be relevant. http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt regards, kaushik! At 10:21 AM 8/2/2005, David B Harrington wrote: >Hi Juergen, > > >From my limited experince looking at the problem, > >If we start to discuss HOW the SSH will support AAA, then we will need >to discuss >1) which AAA protocol? >2) which AAA attributes contain the authorization information >2a) should we use filterID, which is supposed to be for packet >filtering, not policy management >2b) should we define a new standard attribute for this purpose, since >the only attributes available don't provide the granularity we need? >2c) should vendors develop their own VSAs to provide this granularity? >3) will we standardize the naming mechanisms for ACM policies? >4) will we support user-to-group mappings or user-to-policy mappings >(i.e. non-group policies)? > >And so on.... > >I'd like to avoid the whole discussion of how to connect SNMP >authorization to AAA authorization for now, and simply focus on how to >connect SSH user-auth to SNMP user-auth. > >However, if the WG REALLY wants to trigger/capture AAA-authorization >via the security model, we'll need to open that whole can of worms, >because it will require changes to the architecture or an agreement of >how to do it outside the architecture (wink, wink). > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > > Sent: Tuesday, August 02, 2005 1:06 PM > > To: David B Harrington > > Cc: isms@ietf.org > > Subject: Re: [Isms] charter proposal > > > > On Tue, Aug 02, 2005 at 12:54:06PM -0400, David B Harrington wrote: > > > > > Hmmmm. I am of the impression that, as a source for >authentication, > > > the use of AAA is an implementation-dependent detail of the SSH > > > authentication; whether SSH authentication relies on RADIUS > > or AAA or > > > local users to authenticate the transport connection and the user > > > should be transparent to the SNMP engine, shouldn't it? If > > so, then it > > > doesn't belong in the charter at all. > > > > I agree that this is fully transparent to the SNMP engine. On the > > motivational side of the charter, I thought it might be worth to > > mention this since not everybody might be aware that SSH > > authentication decisions can easily be outsourced to AAA servers, > > something that was requested in the past by operators. > > > > > Where we run into the problem is if a TMSM also needs to somehow > > > capture the authorization information returned by AAA so the AC > > > subsystem can use it later. If we want that feature, and we seem >to > > > have a lot of people suggesting it is an important feature > > to support, > > > then we need to address how to standardize that feature so > > future TMSM > > > security models handle it in a compatible way. > > > > I simply did not put this in the charter since I do not yet >understand > > the dimension of this problem. I need to learn more how AAA servers > > provide this authorization information and how it looks like. >Perhaps > > someone here can educate me or point to the relevant specs to read. > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 14:40:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E01gs-0007xa-EA; Tue, 02 Aug 2005 14:40:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E01gq-0007xQ-Pi for isms@megatron.ietf.org; Tue, 02 Aug 2005 14:40:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10265 for ; Tue, 2 Aug 2005 14:40:34 -0400 (EDT) Message-Id: <200508021840.OAA10265@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E02DL-0005Ud-So for isms@ietf.org; Tue, 02 Aug 2005 15:14:14 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080218402201300dt33ne>; Tue, 2 Aug 2005 18:40:23 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" , Subject: RE: [Isms] Separation of authn and authz when using RADIUS Date: Tue, 2 Aug 2005 14:40:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <6.2.0.14.0.20050802101937.040f1d48@email.cisco.com> Thread-Index: AcWXh5Nxiv7YidHLR76wfWLJ+s7+gAACgEDg X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Thanks, I suspected that was the answer. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Kaushik Narayan > Sent: Tuesday, August 02, 2005 1:27 PM > To: dbharrington@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] Separation of authn and authz when using RADIUS > > Hi David, > > I think it is safe to assume that for purposes of administrative > access, protocols such as RADIUS and TACACS+ should be > treated as being stateless. i.e. Although you could perform > authentication and authorization as part of separate requests, > the NAS would need to pass principal name in the authorization > request. We should not expect the AAA server to manage a user > session and map a session ID to a principal. > > p.s. - Note that I specifically mentioned administrative access, since > some RADIUS server implementations do track user session state > but that is largely for network access use cases such as > accounting/billing, > COA etc. > > regards, > kaushik! > > > At 09:41 AM 8/2/2005, David B Harrington wrote: > > >I have a question. I don't have a through understanding of RADIUS and > >my terminology might be slightly wrong, but I'd like to see if my > >understanding of the abstract flow of messages is accurate. Please > >keep this thread only about my question so we can retire this thread > >once my question is answered. > > > >In RADIUS, a client sends an Access-Request to a RADIUS server; as > >part of that process, the client establishes a security association > >between the client and server (the server validates the client). The > >client identifies the user for whom access is requested, and provides > >to the server the authentication credentials provided by the user (in > >various ways depending on the chosen authentication mechanism), and > >may also provide such factors as port. If found acceptable, > the server > >returns an "Access-Accept" which might include the type of service, > >packet filter IDs, etc. > > > >Does RADIUS support the ability of the client to go back to > the RADIUS > >server later to ask for additional service acceptance, or are all > >service attributes, filter IDs, etc. returned in the "Access-Accept" > >message? i.e. can RADIUS handle the user-authentication as one step > >(ending with the Access-Accept" nad then go back for authorization > >information (e.g. filterIDs)? > > > >Applied to an SSH model, if the SSH authentication creates a RADIUS > >session, is there a RADIUS session identifier that could be made > >available to the AC subsystem, which can subsequently query (or > >trigger the query of) the RADIUS server for authorization information > >(say an SNMP filterID used to name a VACM group) for the appropriate > >principal using the same RADIUS session? > > > >My thinking is that, given the securityModel and securityName via the > >ASI, a RADIUS ACM might be able to ask the co-resident RADIUS client > >to query for the groups/policies to apply to the user and > populate the > >model's securityToGroupTable. If that is possible, we shouldn't need > >to include the AAA connection in the charter. > > > >David Harrington > >dbharrington@comcast.net > > > > > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 15:36:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02Z0-00013P-Kx; Tue, 02 Aug 2005 15:36:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02Yz-00013K-9P for isms@megatron.ietf.org; Tue, 02 Aug 2005 15:36:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13870 for ; Tue, 2 Aug 2005 15:36:31 -0400 (EDT) Received: from tui75-2-82-229-178-125.fbx.proxad.net ([82.229.178.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E035U-0007ql-Vw for isms@ietf.org; Tue, 02 Aug 2005 16:10:11 -0400 Received: by boskop.local (Postfix, from userid 501) id 3C0F53A1D57; Tue, 2 Aug 2005 21:36:18 +0200 (CEST) Date: Tue, 2 Aug 2005 21:36:17 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] charter proposal Message-ID: <20050802193617.GB7546@boskop.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <20050802170625.GA7466@open-31-253.ietf63.ietf.org> <20050802172112.5E1AE39A40@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050802172112.5E1AE39A40@hermes.iu-bremen.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 01:21:02PM -0400, David B Harrington wrote: > From my limited experince looking at the problem, > > If we start to discuss HOW the SSH will support AAA, then we will need > to discuss > 1) which AAA protocol? > 2) which AAA attributes contain the authorization information > 2a) should we use filterID, which is supposed to be for packet > filtering, not policy management > 2b) should we define a new standard attribute for this purpose, since > the only attributes available don't provide the granularity we need? > 2c) should vendors develop their own VSAs to provide this granularity? > 3) will we standardize the naming mechanisms for ACM policies? > 4) will we support user-to-group mappings or user-to-policy mappings > (i.e. non-group policies)? > > And so on.... If all these questions do not have a well established clear answer, then I guess I misunderstood those who said that user->group mapping is something we have to do via AAA because it is widely used elsewhere. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 16:01:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02we-0008QA-3F; Tue, 02 Aug 2005 16:01:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E02wc-0008NJ-P7 for isms@megatron.ietf.org; Tue, 02 Aug 2005 16:00:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14805 for ; Tue, 2 Aug 2005 16:00:56 -0400 (EDT) Received: from tui75-2-82-229-178-125.fbx.proxad.net ([82.229.178.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E03TA-0000JR-Ke for isms@ietf.org; Tue, 02 Aug 2005 16:34:36 -0400 Received: by boskop.local (Postfix, from userid 501) id 34C253A1DA8; Tue, 2 Aug 2005 22:00:43 +0200 (CEST) Date: Tue, 2 Aug 2005 22:00:42 +0200 From: Juergen Schoenwaelder To: Kaushik Narayan Subject: Re: [Isms] charter proposal Message-ID: <20050802200042.GC7546@boskop.local> Mail-Followup-To: Kaushik Narayan , ietfdbh@comcast.net, isms@ietf.org References: <20050802170625.GA7466@open-31-253.ietf63.ietf.org> <200508021721.NAA06692@ietf.org> <6.2.0.14.0.20050802102835.0360c218@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.0.14.0.20050802102835.0360c218@email.cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 02, 2005 at 10:52:03AM -0700, Kaushik Narayan wrote: > I am not sure we need elaborate AAA work in order to allow for > linkages between ISMS authentication and SNMPv3 VACM. > Ideally the RADIUS work for this should happen in RADEXT > and I believe Dave Nelson and Greg Weber already have an > ID that would be relevant. > > http://www.ietf.org/internet-drafts/draft-nelson-radius-management-authorization-01.txt This is indeed interesting and highly relevant work. I do, however, believe that (if we go down this road) we need to specify when exactly such authorization information is retrieved, how long it is valid and how such an external source of authorization information fits into the RFC 3411 model. I am also not sure the implementation specific textual formats described in the ID cited above which convey authorization information are particularily useful for interoperability, but that might be a less important detail at this point in time. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 02 17:22:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04DH-0002aH-18; Tue, 02 Aug 2005 17:22:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E04DF-0002YQ-5y for isms@megatron.ietf.org; Tue, 02 Aug 2005 17:22:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17954 for ; Tue, 2 Aug 2005 17:22:10 -0400 (EDT) Message-Id: <200508022122.RAA17954@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E04jk-0003Es-Ho for isms@ietf.org; Tue, 02 Aug 2005 17:55:51 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080221215901300dnrg5e>; Tue, 2 Aug 2005 21:22:00 +0000 From: "David B Harrington" To: Subject: RE: [Isms] charter proposal Date: Tue, 2 Aug 2005 17:21:52 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050802193617.GB7546@boskop.local> Thread-Index: AcWXmXUU6/9SSUYDQVKDOMLyzeKOOgAC7wkQ X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > If all these questions do not have a well established clear answer, > then I guess I misunderstood those who said that user->group mapping > is something we have to do via AAA because it is widely used > elsewhere. Dave Nelson and I and the engineers at Enterasys started discussing well over a year ago the need for vendor-specific management attributes to provide granular user-to-policy mappings, and comparable attributes are currently being discussed in RADEXT. We started our discussions because there did not appear to be a set of RADIUS (or other AAA protocol) attributes that could be used to provide such a mapping for network management purposes at the desired level of granularity for VACM groups or other network management access control "named" policies. The only existing standard management attributes seem to be the remote management Service-Types defined in RFC 2865 [RFC2865]. The available services provide access to the interactive, ASCII-text, Command Line Interface (CLI) of the managed entity, but do not do any user-to-group mapping that I can see. The only other option I've seen is the Congdon approach (RFC3580) for having RADIUS identify user-to-VLAN mappings (the RADIUS server typically indicates the desired VLAN by including tunnel attributes within the Access-Accept), and then policy filters (i.e. the user is allowed to use the SNMP protocol) can be applied to traffic on that VLAN. I don't see how this could be effectively utilized for user-to-VACM Group mappings. I would be interested in hearing from vendors and operators and the people arguing for this user-to-group-mapping feature just HOW they currently use AAA to provide user-to-group mappings for network management access control. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 02:28:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0CjR-0000oZ-1S; Wed, 03 Aug 2005 02:28:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0CjO-0000l3-LJ for isms@megatron.ietf.org; Wed, 03 Aug 2005 02:27:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11849 for ; Wed, 3 Aug 2005 02:27:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0DG0-000686-Mq for isms@ietf.org; Wed, 03 Aug 2005 03:01:42 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Aug 2005 23:27:48 -0700 X-IronPort-AV: i="3.95,162,1120460400"; d="scan'208"; a="652604026:sNHT32078994" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j736Rgul001451; Tue, 2 Aug 2005 23:27:42 -0700 (PDT) Received: from [86.255.28.180] (rtp-vpn1-16.cisco.com [10.82.224.16]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j736P7gw005259; Tue, 2 Aug 2005 23:25:08 -0700 Message-ID: <42F063E1.1040303@cisco.com> Date: Wed, 03 Aug 2005 08:27:45 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] charter proposal References: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> In-Reply-To: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1039; t=1123050310; x=1123482510; c=nowsp; s=nebraska; h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20charter=20proposal| From:Eliot=20Lear=20| Date:Wed,=2003=20Aug=202005=2008=3A27=3A45=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=JosrBFcUIC2ibUDB++VuvrqB+rFGKyDsy/YDQSNhuLWw6H95+upytv9SPaxHVdfAUa9B75YB aXTcInusyYBE0ln1pyn1+7ukH+NjpFZeFU2uieB+oXTiyJueLoXj68S/Rdtculq6b0I2dTS9kpa 5OxX2GPVt7mwJXSaDZXs9Yuw= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, I have major problems with the way things went yesterday. The group decided to reject out of hand SNMP/BEEP without any comparable SSH draft. I think this is both unreasonable and unwise, especially given the time frame the ADs are pushing. What I know: - There was general agreement in the room that "call home" functionality was a good thing to have. - There was general preference for a single mechanism between NETCONF and SSH. - Of the humm that occurred favoring SSH, the operators and at least those I know to be interested vendors indicated a preference for BEEP. - NETCONF/SSH specifically excluded "call home" functionality. - There is no specification for SNMP/SSH. In our haste to create a solution that integrates with other security solutions we are producing something that won't integrate with other network management solutions. Now you could say that perhaps the NETCONF/SSH specification should have "call home" added to it. The reason Margaret didn't include it was that she felt if you wanted that sort of thing, use BEEP. That was her logic. It's not unreasonable. I have no problem working through the issues that separate BEEP and SSH. But to have prematurely made the decision is, I assert again, unwise. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 03:08:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DMR-0000Ov-5i; Wed, 03 Aug 2005 03:08:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0DMP-0000Li-7H for isms@megatron.ietf.org; Wed, 03 Aug 2005 03:08:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19850 for ; Wed, 3 Aug 2005 03:08:16 -0400 (EDT) Received: from tui75-2-82-229-178-125.fbx.proxad.net ([82.229.178.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Dt1-0007r5-Ih for isms@ietf.org; Wed, 03 Aug 2005 03:42:01 -0400 Received: by boskop.local (Postfix, from userid 501) id 9DF8D3A2112; Wed, 3 Aug 2005 09:07:59 +0200 (CEST) Date: Wed, 3 Aug 2005 09:07:59 +0200 From: Juergen Schoenwaelder To: Eliot Lear Subject: Re: [Isms] charter proposal Message-ID: <20050803070759.GA7943@boskop.local> Mail-Followup-To: Eliot Lear , isms@ietf.org, "Wijnen, Bert (Bert)" , Sam Hartman , Andy Bierman , Margaret Wasserman References: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> <42F063E1.1040303@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42F063E1.1040303@cisco.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 03, 2005 at 08:27:45AM +0200, Eliot Lear wrote: > Hi Juergen, > > I have major problems with the way things went yesterday. > > The group decided to reject out of hand SNMP/BEEP without any comparable > SSH draft. I think this is both unreasonable and unwise, especially > given the time frame the ADs are pushing. The TMSM document was written with ssh in mind. This is mentioned in the ID. I am happy to leave it to the chairs and the ADs to gauge the level of discussion of SSH as a transport on the ISM WG mailing list and to compare that to BEEP. > What I know: > > - There was general agreement in the room that "call home" > functionality was a good thing to have. Can't remember whether this is accurate. I do remember jabber log statements that call home might be doable with ssh as well - I can't judge that at the moment. I do however realize that SNMP right now does not have call home - so you are proposing to add a feature to SNMP which does not yet exist in that form. > - There was general preference for a single mechanism between NETCONF > and SSH. Not sure I understand the semantics of this sentence... > - Of the humm that occurred favoring SSH, the operators and at least > those I know to be interested vendors indicated a preference for > BEEP. I heard Simon saying that he uses SSH for management, actually using passwords authentication (even though he seemed to prefer in principle to use public key SSH authentication). Simon, correct me if I am wrong. I heard Ruediger saying that he doubts that someone types in SNMP messages into SSH (which I can easily agree with) and that he does not really care what the security protocol on the wire looks like as long as it integrates. Ruediger, correct me if I am wrong. > - NETCONF/SSH specifically excluded "call home" functionality. Not sure this is accurate. I think NETCONF decided to make a straight forward ssh mapping mandatory. Other mappings can be used as well but are not mandatory. > - There is no specification for SNMP/SSH. See explanation above. > In our haste to create a solution that integrates with other security > solutions we are producing something that won't integrate with other > network management solutions. Which ones? I doubt that SNMP based solutions have a call home feature right now. > Now you could say that perhaps the NETCONF/SSH specification should have > "call home" added to it. The reason Margaret didn't include it was that > she felt if you wanted that sort of thing, use BEEP. That was her > logic. It's not unreasonable. I prefer to let Margaret speak for herself since there are different interpretations possible for a statement of the sort "if you wanted that sort of thing, use BEEP". > I have no problem working through the issues that separate BEEP and SSH. > But to have prematurely made the decision is, I assert again, unwise. Maybe it is, maybe not. With netconf, we took the approach that SSH is mandatory and to let the market sort out the rest. In isms, it was somehow determined yesterday that doing this same approach wastes resources. If you think this decision is wrong, you should I think primarily contact the chairs and the ADs - I am clearly not the one to determine concensus. (So I am kind of wondering why this message was directed to me and not to the chairs - perhaps too many Juergens around here.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 04:20:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ETq-0007Xm-NE; Wed, 03 Aug 2005 04:20:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ETo-0007XJ-Nr for isms@megatron.ietf.org; Wed, 03 Aug 2005 04:20:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24287 for ; Wed, 3 Aug 2005 04:19:59 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0F0R-0002un-0Y for isms@ietf.org; Wed, 03 Aug 2005 04:53:45 -0400 Received: from pc6 (1Cust209.tnt106.lnd4.gbr.da.uu.net [213.116.60.209]) by galaxy.systems.pipex.net (Postfix) with SMTP id BA985E0002F8; Wed, 3 Aug 2005 09:19:30 +0100 (BST) Message-ID: <000a01c597fb$89a7fb00$0601a8c0@pc6> From: "Tom Petch" To: "Fleischman, Eric" References: <474EEBD229DF754FB83D256004D021080EC443@XCH-NW-6V1.nw.nos.boeing.com> Subject: Re: [Isms] securityName Date: Wed, 3 Aug 2005 09:17:40 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org ----- Original Message ----- From: "Fleischman, Eric" To: "Tom Petch" Cc: Sent: Tuesday, August 02, 2005 6:07 PM Subject: RE: [Isms] securityName Tom, I am in harmony with using SSH, TLS+/-SASL, or DTLS. I very much appreciate the authentication system flexibility avaialable from these approaches. (Yes, PKI == Certificates.) However, I am not clear how we are planning on adding additional privacy and authentication mechanisms and still leave SNMPv3 USM and VACM untouched. Where are the interfaces between the two systems (the old and new) being drawn? --Eric Eric The intent of the architecture is that the message processing subsystem decodes the ASN.1, finds a securityModel value and calls one of many coexisting xSM, of which USM is currently the only one; so no problem in principle in adding anoSM (or anoACM) with a different value. Every xSM should be passed the same parameters and return the same values, as per the ASI in the SNMPv3 Architecture. Trouble is, when security is done at transport level (SSH, TLS), the security is best done before ever the PDU gets to the message processing subsystem so its calls, eg to get the PDU decrypted, are somewhat meaningless. So for me, the architecture does not allow for transport level security and so needs flexing or changing; I don't see this as a problem, others do. Likewise, the transport level knows what authentication has taken place, who the 'principal' is; no way to pass this on - the security model is expected to produce it out of a hat from the msgSecurityParameters for the message processing subsystem whereas, with transport level security, the security parameters are no longer in the SNMP PDU but part of the SSH/TLS header. The architecture is fine when every thing is done in a self-contained manner within the engine as with USM and VACM. For me, it starts to fail whenever anything is done elsewhere, when some other system is the primary source of information (authentication, user to Group mapping etc) and SNMP is the slave or cache of it. This is not clear cut, I think we have wiggle room, but I see this as one significant unresolved issue. The TMSM I-D does cover much of this. How to move forward? Get a charter that clearly allows us limited change in the Architecture that allows security and authorization to be performed outside the engine seems best to me (I have now ducked behind a multi-layered, over-engineered firewall but will reemerge to make the same point in due course.:-) Randy's reply takes a different perspective. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 04:43:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eqq-0006S0-SI; Wed, 03 Aug 2005 04:43:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Eqo-0006Rm-Lo for isms@megatron.ietf.org; Wed, 03 Aug 2005 04:43:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25409 for ; Wed, 3 Aug 2005 04:43:44 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0FNS-0003xv-26 for isms@ietf.org; Wed, 03 Aug 2005 05:17:31 -0400 Received: from pc6 (1Cust124.tnt27.lnd4.gbr.da.uu.net [62.188.154.124]) by galaxy.systems.pipex.net (Postfix) with SMTP id 1DB8AE00032D; Wed, 3 Aug 2005 09:43:30 +0100 (BST) Message-ID: <00c801c597fe$e52ac540$0601a8c0@pc6> From: "Tom Petch" To: , "Eliot Lear" References: <20050802153325.GA6968@open-31-253.ietf63.ietf.org><42F063E1.1040303@cisco.com> <20050803070759.GA7943@boskop.local> Subject: Re: [Isms] charter proposal Date: Wed, 3 Aug 2005 09:41:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Eliot Lear" Cc: "Margaret Wasserman" ; "Andy Bierman" ; "Sam Hartman" ; Sent: Wednesday, August 03, 2005 9:07 AM Subject: Re: [Isms] charter proposal > On Wed, Aug 03, 2005 at 08:27:45AM +0200, Eliot Lear wrote: > > Hi Juergen, > > > > I have major problems with the way things went yesterday. > > > > The group decided to reject out of hand SNMP/BEEP without any comparable > > SSH draft. I think this is both unreasonable and unwise, especially > > given the time frame the ADs are pushing. > > The TMSM document was written with ssh in mind. This is mentioned in > the ID. I am happy to leave it to the chairs and the ADs to gauge the > level of discussion of SSH as a transport on the ISM WG mailing list > and to compare that to BEEP. > Eliot I did (and posted to the list) a section for the TMSM I-D which replaced TLS by SSH. There was very little change, mostly the choice to use subsystems and connections. Sam commented I did not go far enough - true, but I went as far as TMSM with TLS. The unresolved issue for me was what to authenticate, whether we have one SSH authenticated pipe between engines (ssh-userauth) with principal authentication done separately or whether there was one SSH authenticated pipe per set of security credentials, be that host, application or user (whatever level the organisation authenticates at). For me, most of the issues are transport level security ones, independent of actual protocol. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 05:59:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G26-0002eN-Hk; Wed, 03 Aug 2005 05:59:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0G24-0002eC-72 for isms@megatron.ietf.org; Wed, 03 Aug 2005 05:59:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01168 for ; Wed, 3 Aug 2005 05:59:25 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0GYi-0007Sb-72 for isms@ietf.org; Wed, 03 Aug 2005 06:33:13 -0400 Received: from pc6 (1Cust24.tnt28.lnd4.gbr.da.uu.net [62.188.156.24]) by galaxy.systems.pipex.net (Postfix) with SMTP id 6B5CAE0000BB; Wed, 3 Aug 2005 10:59:12 +0100 (BST) Message-ID: <01ee01c59809$782efc80$0601a8c0@pc6> From: "Tom Petch" To: References: <200507151618.MAA22560@ietf.org> <86oe8kb70n.fsf@romeo.rtfm.com> <027601c59747$73468200$0601a8c0@pc6> <20050802112018.GA6617@open-31-253.ietf63.ietf.org> Subject: Re: [Isms] Comments on the BTSMS proposal Date: Wed, 3 Aug 2005 10:57:31 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "Tom Petch" Cc: "EKR" ; "Sam Hartman" ; Sent: Tuesday, August 02, 2005 1:20 PM Subject: Re: [Isms] Comments on the BTSMS proposal > On Tue, Aug 02, 2005 at 11:48:19AM +0200, Tom Petch wrote: > > > When security is outside SNMP, at the transport layer, then > > somewhere in the SNMP engine needs to tell TMSM or transport what is > > wanted, which then says yes or no; and the level on the wire may > > exceed what is requested (eg authPriv v authNoPriv) which, IMHO, > > needs recording in the packet (where?) and needs passing up the > > stack of the recipient (how?). > > The TMSM document discusses this in some detail. I fail to see why you > think it is necessary to touch the flags in the SNMP packet. Can you > please elaborate? > The auth priv flags in the SNMP PDU reflect the request of the application and I do not see these as being changed by SSH (not wanted, not feasible). The reality on the wire may be different; I think that that should be passed to the SNMP engine but that that cannot be done in the SNMP PDU. I see this as at best a fudge of the architecture, perhaps even a change. We no longer have in the PDU information we should have. > > None of this is in the architecture or ASIs. And recall that the > > PDU is ASN.1 so the transport layer cannot readily set or reset > > flags in it, even in the space set aside for security parms ie we > > are in a sense modifying the SNMPv3 PDU format by moving the > > securityParms outside the ASN.1 SEQUENCE. > > The TMSM document currently proposes to pass this information between > the pieces of the split security model via a cache referred to by a > cache reference. Again, I like to understand why you think it is > necessary to change the SNMPv3 PDU format. > > /js > Same argument. The security model is expected to derive a securityName from the msgSecurityParameters in the PDU. When security is done at transport level, this information never makes it into the SNMP PDU. There are security parameters but they are outside the remit of the SNMP engine and architecture. Same conclusion. I accept that this is a judgment call and you see it differently. I was interested to be reminded by dbh of the SNMP 'WG consensus requirements such as "the mandatory-to-implement models should have no dependencies on external protocols" '. We are now introducing a greater dependence on external protocols - SSH et al - albeit for non-mandatory models and for me, that puts the architecture under strain. dbh also says 'If the TMSM is going to pass transport information from the transport mapping to the SM subsystem, either through a cache or an ASI parameter, we need to standardize how this is done, how it affects existing models and MIB modules, and how to document these changes within the IETF.' Again, a matter of judgment, but I see this as close to suggesting a small change to the architecture as defined in RFC3411 caused by a dependency on external protocols. Tom Petch > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 06:45:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GkV-00022S-Bi; Wed, 03 Aug 2005 06:45:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0GkT-00022N-Nv for isms@megatron.ietf.org; Wed, 03 Aug 2005 06:45:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03927 for ; Wed, 3 Aug 2005 06:45:19 -0400 (EDT) Message-Id: <200508031045.GAA03927@ietf.org> Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HH7-00018A-Bu for isms@ietf.org; Wed, 03 Aug 2005 07:19:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005080310451001200pd8e6e>; Wed, 3 Aug 2005 10:45:10 +0000 From: "David B Harrington" To: "'Eliot Lear'" Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 06:45:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <42F063E1.1040303@cisco.com> Thread-Index: AcWX9Of/uzfYShwYRq+2H1/xwQgspQAGZXNQ X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: 'Margaret Wasserman' , 'Andy Bierman' , 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot, I share your concern with the way things went, although not for quite the same reasons. I think it makes much more sense to encourage multiple proposals to be submitted so we can do a real comparison; that was the approach used in netconf and many other WGs, but apparently that's not an acceptable approach for this WG. I think this would be a better approach than eliminating all but one possible solution and choosing only one which we don't even know is feasible, knowing that netconf found it hard to support some expected requirements, and choosing that one without even identifying the requirements that need to be met by proposed isms solutions. An alternative approach is to identify the requirmeents and then do a protocol analysis, but I've seen that in multiple WGs and doing this seems to cause WGs to lose momentum badly, and to give really skewed results. We should be trying to accommodate operators' preferences for which protocols to support. Wes's survey showed SSH as a popular choice with (ISP) operators; I don't see BEEP in the list (maybe it wasn't a choice in the survey). I think the group chose to reject BEEP, or at least sideline BEEP for now, primarily because we are supposed to be leveraging widely-deployed infrastructure, and BEEP to my knowledge is not widely deployed; it is mentioned in a wide range of IETF WGs, which shows a strong marketing push by the supporters of BEEP like yourself, but I don't see a comparable deployment of BEEP in the real world. I think this is very similar to the analysis done in the Netconf WG. I think it would be foolish for the WG to choose BEEP because the ADs are pushing a tight timeframe, just as I think it is foolish to choose SSH because of a tight AD timeframe. But if that's what it takes to stay in business, then I guess we must. That said, I personally think that if you believe BEEP to be a better solution than SSH, you should continue to develop the BEEP draft while our team develops the SSH proposal, then we can do a real comparison. I have serious concerns about the decisions made by Netconf to not address notifications and other issues with their SSH solution, and it may well be that SSH may not be a feasible approach to meet SNMP needs, but until we have an SSH proposal it's hard to tell. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Eliot Lear > Sent: Wednesday, August 03, 2005 2:28 AM > To: j.schoenwaelder@iu-bremen.de > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > Subject: Re: [Isms] charter proposal > > Hi Juergen, > > I have major problems with the way things went yesterday. > > The group decided to reject out of hand SNMP/BEEP without any > comparable > SSH draft. I think this is both unreasonable and unwise, especially > given the time frame the ADs are pushing. > > What I know: > > - There was general agreement in the room that "call home" > functionality was a good thing to have. > > - There was general preference for a single mechanism between NETCONF > and SSH. > > - Of the humm that occurred favoring SSH, the operators and at least > those I know to be interested vendors indicated a preference for > BEEP. > > - NETCONF/SSH specifically excluded "call home" functionality. > > - There is no specification for SNMP/SSH. > > In our haste to create a solution that integrates with other security > solutions we are producing something that won't integrate with other > network management solutions. > > Now you could say that perhaps the NETCONF/SSH specification > should have > "call home" added to it. The reason Margaret didn't include > it was that > she felt if you wanted that sort of thing, use BEEP. That was her > logic. It's not unreasonable. > > I have no problem working through the issues that separate > BEEP and SSH. > But to have prematurely made the decision is, I assert again, unwise. > > Eliot > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 06:54:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gt2-0004UZ-FU; Wed, 03 Aug 2005 06:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Gt0-0004UF-5m for isms@megatron.ietf.org; Wed, 03 Aug 2005 06:54:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04443 for ; Wed, 3 Aug 2005 06:54:07 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0HPe-0001WS-Vj for isms@ietf.org; Wed, 03 Aug 2005 07:27:56 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j73Aruo5000604 for ; Wed, 3 Aug 2005 03:53:56 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j73Arpxi003221 for ; Wed, 3 Aug 2005 03:53:51 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j73ArpDf003218 for ; Wed, 3 Aug 2005 03:53:51 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 3 Aug 2005 03:53:50 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Subject: Re: [Isms] Comments on the BTSMS proposal (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, oops, forgot to copy the list. Regards, /david t. perkins ---------- Forwarded message ---------- Date: Wed, 3 Aug 2005 03:38:41 -0700 (PDT) From: David T. Perkins To: Tom Petch Subject: Re: [Isms] Comments on the BTSMS proposal HI, On the question about what to put in the security param field (and security type) when using encapsulated security - I suggest either: 1) nothing - a zero length string (and the security model (SM) session ID would be determined by the "SSH session"; or 2) a session ID pair - the security model (SM) processing code would take the session ID pair and verify that the "SSH session" matches. I assume that there is a "table" (conceptual) of SM sessions. Each entry is identified by a session ID pair. Other info in the entry would include: 1) "encapsulation transport" info (for example, the info for the "SSH session") 2) the security level provided by the encapsulating transport (the values would be authNoPriv and authPriv, but maybe also noAuthNoPriv) 3) the SM identity and the security name of the session initiator 4) possibly, the SM identity and security name of the session listner 5) possibly, the VACM group name 6) possibly, other values for "overrides" and other session related attributes. When an "encapsulation transport" session is created, entries would be added to the table. And when a session is terminated, then entries are removed from the table. I believe that the above approach works for and SSH "encapsulation transport" session, and will also work for other session based SMs. And I believe that it resolves the issue about how the values from SNMP messages for flags to security level is determined, and how to use the values in the security params field. On Wed, 3 Aug 2005, Tom Petch wrote: > > Tom Petch > > ----- Original Message ----- > From: "Juergen Schoenwaelder" > To: "Tom Petch" > Cc: "EKR" ; "Sam Hartman" ; > Sent: Tuesday, August 02, 2005 1:20 PM > Subject: Re: [Isms] Comments on the BTSMS proposal > > > > On Tue, Aug 02, 2005 at 11:48:19AM +0200, Tom Petch wrote: > > > > > When security is outside SNMP, at the transport layer, then > > > somewhere in the SNMP engine needs to tell TMSM or transport what is > > > wanted, which then says yes or no; and the level on the wire may > > > exceed what is requested (eg authPriv v authNoPriv) which, IMHO, > > > needs recording in the packet (where?) and needs passing up the > > > stack of the recipient (how?). > > > > The TMSM document discusses this in some detail. I fail to see why you > > think it is necessary to touch the flags in the SNMP packet. Can you > > please elaborate? > > > The auth priv flags in the SNMP PDU reflect the request of the application and I > do not see these as being changed by SSH (not wanted, not feasible). The > reality on the wire may be different; I think that that should be passed to the > SNMP engine but that that cannot be done in the SNMP PDU. I see this as at best > a fudge of the architecture, perhaps even a change. We no longer have in the > PDU information we should have. > > > > None of this is in the architecture or ASIs. And recall that the > > > PDU is ASN.1 so the transport layer cannot readily set or reset > > > flags in it, even in the space set aside for security parms ie we > > > are in a sense modifying the SNMPv3 PDU format by moving the > > > securityParms outside the ASN.1 SEQUENCE. > > > > The TMSM document currently proposes to pass this information between > > the pieces of the split security model via a cache referred to by a > > cache reference. Again, I like to understand why you think it is > > necessary to change the SNMPv3 PDU format. > > > > /js > > > Same argument. The security model is expected to derive a securityName from the > msgSecurityParameters in the PDU. When security is done at transport level, > this information never makes it into the SNMP PDU. There are security > parameters but they are outside the remit of the SNMP engine and architecture. > Same conclusion. > > I accept that this is a judgment call and you see it differently. I was > interested to be reminded by dbh of the SNMP 'WG consensus requirements such as > "the mandatory-to-implement models should have no dependencies on external > protocols" '. We are now introducing a greater dependence on external > protocols - SSH et al - albeit for non-mandatory models and for me, that puts > the architecture under strain. > > dbh also says > 'If the TMSM is going to pass transport information from the transport > mapping to the SM subsystem, either through a cache or an ASI > parameter, we need to standardize how this is done, how it affects > existing models and MIB modules, and how to document these changes > within the IETF.' > > Again, a matter of judgment, but I see this as close to suggesting a small > change to the architecture as defined in RFC3411 caused by a dependency on > external protocols. > > > Tom Petch Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 07:20:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HIL-00038o-Lt; Wed, 03 Aug 2005 07:20:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0HIJ-00037R-A4 for isms@megatron.ietf.org; Wed, 03 Aug 2005 07:20:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05840 for ; Wed, 3 Aug 2005 07:20:16 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0How-0002fF-Uu for isms@ietf.org; Wed, 03 Aug 2005 07:54:05 -0400 Received: from pc6 (1Cust109.tnt105.lnd4.gbr.da.uu.net [213.116.58.109]) by galaxy.systems.pipex.net (Postfix) with SMTP id C7EAEE00012B; Wed, 3 Aug 2005 12:19:54 +0100 (BST) Message-ID: <02d501c59814$bc830c40$0601a8c0@pc6> From: "Tom Petch" To: , "David B Harrington" References: <20050802170625.GA7466@open-31-253.ietf63.ietf.org><20050802172112.5E1AE39A40@hermes.iu-bremen.de> <20050802193617.GB7546@boskop.local> Subject: Re: [Isms] charter proposal user-group mapping Date: Wed, 3 Aug 2005 11:37:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Schoenwaelder" To: "David B Harrington" Cc: Sent: Tuesday, August 02, 2005 9:36 PM Subject: Re: [Isms] charter proposal > On Tue, Aug 02, 2005 at 01:21:02PM -0400, David B Harrington wrote: > > > From my limited experince looking at the problem, > > > > If we start to discuss HOW the SSH will support AAA, then we will need > > to discuss > > 1) which AAA protocol? > > 2) which AAA attributes contain the authorization information > > 2a) should we use filterID, which is supposed to be for packet > > filtering, not policy management > > 2b) should we define a new standard attribute for this purpose, since > > the only attributes available don't provide the granularity we need? > > 2c) should vendors develop their own VSAs to provide this granularity? > > 3) will we standardize the naming mechanisms for ACM policies? > > 4) will we support user-to-group mappings or user-to-policy mappings > > (i.e. non-group policies)? > > > > And so on.... > > If all these questions do not have a well established clear answer, > then I guess I misunderstood those who said that user->group mapping > is something we have to do via AAA because it is widely used > elsewhere. > > /js I have said that the user-group mapping needs removing from the 'agent' as a task the administrators have to perform in order to maintain security, else I believe isms will not meet its objectives. In one, rather large, marketplace, I see this model (framework? architecture?) done in a proprietary manner, using Windows Active Directory (which uses Kerberos, but I don't know in what way). So an end user logs onto a server running an SNMP Command Generator, is authenticated and as part of that, the security server specifies authorisations, access permissions, rights etc which are mostly defined by being a member of a group. The Command Generator now has everything the Command Responder needs to know and so passes it, end user identity plus group membership, to the Command Responder in a secure manner (ssh transport, security parameters, authenticated, with integrity) which uses it to access the access control rules. Obviously this does not yet exist for SNMPv3 but there are parallels for other aspects of network management. Again, I have no brief for those who would implement such code but if we provide the protocol, I believe it is a simple step forward. Likewise, my knowledge of standards-based systems leads me to believe that this could be done with them (although not necessarily with all of them). I do believe that retrieving the group membership at the time the SNMPv3 principal is authenticated is the key function and that everything else needs to stem from it. As dbh's query elicited, these servers are stateless. I also believe that the Command Generator is the place to do it because of the (small) numbers of them, the power of these platforms, the rich range of services that already exist on them. Doing it from an entry level router does not seem so attractive. Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 08:29:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0INj-0007Ti-HM; Wed, 03 Aug 2005 08:29:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0INi-0007TX-4R for isms@megatron.ietf.org; Wed, 03 Aug 2005 08:29:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10988 for ; Wed, 3 Aug 2005 08:29:57 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0IuN-0006Eq-Nc for isms@ietf.org; Wed, 03 Aug 2005 09:03:45 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 5EE493A2CFE; Wed, 3 Aug 2005 14:29:43 +0200 (CEST) Date: Wed, 3 Aug 2005 14:29:43 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] Comments on the BTSMS proposal Message-ID: <20050803122943.GC10206@open-31-253.ietf63.ietf.org> Mail-Followup-To: Tom Petch , isms@ietf.org References: <200507151618.MAA22560@ietf.org> <86oe8kb70n.fsf@romeo.rtfm.com> <027601c59747$73468200$0601a8c0@pc6> <20050802112018.GA6617@open-31-253.ietf63.ietf.org> <01ee01c59809$782efc80$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01c59809$782efc80$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 03, 2005 at 10:57:31AM +0200, Tom Petch wrote: > > The TMSM document discusses this in some detail. I fail to see why you > > think it is necessary to touch the flags in the SNMP packet. Can you > > please elaborate? > > > The auth priv flags in the SNMP PDU reflect the request of the > application and I do not see these as being changed by SSH (not > wanted, not feasible). The reality on the wire may be different; I > think that that should be passed to the SNMP engine but that that > cannot be done in the SNMP PDU. I see this as at best a fudge of > the architecture, perhaps even a change. We no longer have in the > PDU information we should have. I don't think the security parameters of the session must be exchanged over the network and hence I don't thing they have to be in the PDU. > > The TMSM document currently proposes to pass this information between > > the pieces of the split security model via a cache referred to by a > > cache reference. Again, I like to understand why you think it is > > necessary to change the SNMPv3 PDU format. > > Same argument. The security model is expected to derive a > securityName from the msgSecurityParameters in the PDU. When > security is done at transport level, this information never makes it > into the SNMP PDU. There are security parameters but they are > outside the remit of the SNMP engine and architecture. Same > conclusion. Please point to the RFC from which you derive this requirement for all security models. > I accept that this is a judgment call and you see it differently. I > was interested to be reminded by dbh of the SNMP 'WG consensus > requirements such as "the mandatory-to-implement models should have > no dependencies on external protocols" '. We are now introducing a > greater dependence on external protocols - SSH et al - albeit for > non-mandatory models and for me, that puts the architecture under > strain. > > dbh also says > 'If the TMSM is going to pass transport information from the transport > mapping to the SM subsystem, either through a cache or an ASI > parameter, we need to standardize how this is done, how it affects > existing models and MIB modules, and how to document these changes > within the IETF.' > > Again, a matter of judgment, but I see this as close to suggesting a small > change to the architecture as defined in RFC3411 caused by a dependency on > external protocols. I guess you have seen my recharter proposal and it in particular allows for updates that describe how security state information is passed around. I am actually not sure what your problem really is. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 08:41:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0IYo-0002Sq-PK; Wed, 03 Aug 2005 08:41:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0IYm-0002SL-5Z for isms@megatron.ietf.org; Wed, 03 Aug 2005 08:41:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11590 for ; Wed, 3 Aug 2005 08:41:23 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0J5S-0006fv-T6 for isms@ietf.org; Wed, 03 Aug 2005 09:15:11 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 41D0B3A2D41; Wed, 3 Aug 2005 14:41:14 +0200 (CEST) Date: Wed, 3 Aug 2005 14:41:14 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] charter proposal user-group mapping Message-ID: <20050803124114.GD10206@open-31-253.ietf63.ietf.org> Mail-Followup-To: Tom Petch , David B Harrington , isms@ietf.org References: <20050802193617.GB7546@boskop.local> <02d501c59814$bc830c40$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d501c59814$bc830c40$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 03, 2005 at 11:37:04AM +0200, Tom Petch wrote: > So an end user logs onto a server running an SNMP Command Generator, > is authenticated and as part of that, the security server specifies > authorisations, access permissions, rights etc which are mostly > defined by being a member of a group. The Command Generator now has > everything the Command Responder needs to know and so passes it, end > user identity plus group membership, to the Command Responder in a > secure manner (ssh transport, security parameters, authenticated, > with integrity) which uses it to access the access control rules. Why should the device (command responder) trust the user that he does not claim a false group membership? I believe the user to group membership has to be provided by a trusted third party or it would have to be at least signed by a trusted third party and the device would have to be able to check the signature. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 08:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ic3-0005tc-Dk; Wed, 03 Aug 2005 08:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ibz-0005rg-2c for isms@megatron.ietf.org; Wed, 03 Aug 2005 08:44:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11916 for ; Wed, 3 Aug 2005 08:44:41 -0400 (EDT) Message-Id: <200508031244.IAA11916@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0J8f-0006ri-Mr for isms@ietf.org; Wed, 03 Aug 2005 09:18:30 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005080312443301300dqjr7e>; Wed, 3 Aug 2005 12:44:33 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] Comments on the BTSMS proposal Date: Wed, 3 Aug 2005 08:44:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <01ee01c59809$782efc80$0601a8c0@pc6> Thread-Index: AcWYEmFZzG9llyx0RaaLrBej4dcqXwABl4zA X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, You're making assumptions about what is required in SNMPv3 processing, and I don't agree with some of your assumptions. > > > When security is outside SNMP, at the transport layer, then > > > somewhere in the SNMP engine needs to tell TMSM or > transport what is > > > wanted, which then says yes or no; and the level on the wire may > > > exceed what is requested (eg authPriv v authNoPriv) which, IMHO, > > > needs recording in the packet (where?) and needs passing up the > > > stack of the recipient (how?). Why does this need to be included in the PDU? When I send an SNMP message (or a FTP packet, or ...) over an IPSec network, should the PDU be modified to show what securitylevel IPSec used? There are two reasons msgflags are passed in SNMPv3 messages. The first reason is to ensure that the information is handled by the recipient with the same concern for data sensitivity. I don't see any problem with providing stronger security than requested. What happens if I use SNMPv3 noAuthNoPriv over a VPN that does authentication and encryption? Do we need to change the msgFlags in the SNMP message? What happens if we use USM AuthPriv and the message passes over a nonsecure network and a VPN that does authentication and encryption? The minimum security is still AuthPriv, regardless of the maximum level of security applied in transit, or the lack of security applied in transit. "The authFlag and privFlag portions of the msgFlags field are set by the sender to indicate the securityLevel that was applied to the message before it was sent on the wire. " If you want to argue for a literal interpretation of the requirements, then the sender who relies on a transport layer to provide auth and priv should set the message flags to noAuthNoPriv, since that's what was applied to the message before it was sent on the wire (i.e. sent to the lower layer in the communications stack). Obviously, the engine requests a securityLevel from the underlying transport and ensures that the transport protocol agrees to meet its minimum criteria before sending it on the wire. All the engine can do is assert that (at least) this level of security has been applied. The second reason msgFlags is included in the message is an artifact of USM security - msgFlags alerts the recipient's USM model about which lookups they need to do in the USM MIB to get the shared keys for authentication and encryption. SSH, TLS, SAL all have different mechanisms for determining how to get shared keys or other credentials; they don't need this passed in the SNMP message. > Same argument. The security model is expected to derive a > securityName from the > msgSecurityParameters in the PDU. The USM security model does it this way, but this is not an architectural requirement. >From RFC3411: The transformation of model-dependent security IDs into securityNames and vice versa is the responsibility of the relevant Security Model. >From RFC3412: 6.6. msgSecurityParameters The msgSecurityParameters field of the SNMPv3 Message is used for communication between the Security Model modules in the sending and receiving SNMP engines. The data in the msgSecurityParameters field is used exclusively by the Security Model, and the contents and format of the data is defined by the Security Model. This OCTET STRING is not interpreted by the v3MP, but is passed to the local implementation of the Security Model indicated by the msgSecurityModel field in the message. > I was > interested to be reminded by dbh of the SNMP 'WG consensus > requirements such as > "the mandatory-to-implement models should have no > dependencies on external > protocols" '. Yes, because one purpose of SNMP is to troubleshoot broken networks, and the mandatory-to-implement protocol needs to work (if possible) even when the network is broken; having a dependency on an external authentication server increases the likelihood that SNMP will not function when the network is broken. While desirable, (I believe) this is not a requirement for supplemental security models, since USM can provide the troubleshooting capability. Some have argued that USM should not be replaced by a new security model; if that occurs, the replacement security model would be faced with this requirement. > We are now introducing a greater dependence on external > protocols - SSH et al - albeit for non-mandatory models and > for me, that puts > the architecture under strain. It in no way puts the architecture under strain. It has long been considered a desirable thing to tie into existing security infrastructure, and the architecture was designed to allow different security models to be developed that could utilize various approaches to security. If you can locate the old SNMPv2 archives, you can see the debates about how to leverage IPSec to secure SNMP. This was definitely recognized as a potential approach to security. I will agree we didn't do a very good at providing a layered architecture so we could utilize lower layers for security easily, but the use of external security definitely was considered. Note that the SNMPv3 architecture reached standards track before most of the transport layer security protocols (and SecSH hasn't gotten there yet); it's hard to plan the architectural fit with external protocols still in development. > > dbh also says > 'If the TMSM is going to pass transport information from the transport > mapping to the SM subsystem, either through a cache or an ASI > parameter, we need to standardize how this is done, how it affects > existing models and MIB modules, and how to document these changes > within the IETF.' > > Again, a matter of judgment, but I see this as close to > suggesting a small > change to the architecture as defined in RFC3411 caused by a > dependency on > external protocols. I don't see this as close to suggesting a small change in the architecture as defined in RFC3411; I see this as definitely suggesting a small change to the architecture as defined in RFC3411, but in a way that is consistent with the precedents of the architecture defined in RFC3411. This change is required because the RFC3411 ASIs were knowingly made inadequate to support transport security. There was a political battle in the SNMPv2/v3 WGs over whether SNMPv2/v3 should support the use of source address as an authentication mechanism. Despite its popularity with operators, and the strong insistence of one of the "major players", given the ease of address spoofing, the WGs decided to not pass the transport info into the security subsystem, and to not allow the transport mapping to provide authentication, to encourage operators to use the stronger authenticatino mechanisms supported by USM and other expected security models. This political decision has come back to haunt us. > > > Tom Petch > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, 28725 > Bremen, Germany > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 09:05:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ivk-00072p-3l; Wed, 03 Aug 2005 09:05:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ivd-00070Q-4L for isms@megatron.ietf.org; Wed, 03 Aug 2005 09:05:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13318 for ; Wed, 3 Aug 2005 09:04:59 -0400 (EDT) Received: from open-31-253.ietf63.ietf.org ([86.255.31.253]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JSK-0007rK-1V for isms@ietf.org; Wed, 03 Aug 2005 09:38:48 -0400 Received: by open-31-253.ietf63.ietf.org (Postfix, from userid 501) id 6B87D3A2DBD; Wed, 3 Aug 2005 15:04:51 +0200 (CEST) Date: Wed, 3 Aug 2005 15:04:51 +0200 From: Juergen Schoenwaelder To: "David T. Perkins" Subject: Re: [Isms] Comments on the BTSMS proposal (fwd) Message-ID: <20050803130451.GA10476@open-31-253.ietf63.ietf.org> Mail-Followup-To: "David T. Perkins" , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 03, 2005 at 03:53:50AM -0700, David T. Perkins wrote: > On the question about what to put in the security param > field (and security type) when using encapsulated security - > I suggest either: > 1) nothing - a zero length string (and the security model (SM) > session ID would be determined by the "SSH session"; or > 2) a session ID pair - the security model (SM) processing code > would take the session ID pair and verify that the > "SSH session" matches. In option 2) requires that the secure transport makes such session identifiers available - not sure every potential secure transport protocol will give you such identifiers. If you want to pass the session identifier from the local session endpoint up to the security model, then using a state reference seems to be much simpler. > I assume that there is a "table" (conceptual) of SM sessions. > Each entry is identified by a session ID pair. Other info > in the entry would include: > 1) "encapsulation transport" info (for example, the info > for the "SSH session") > 2) the security level provided by the encapsulating transport > (the values would be authNoPriv and authPriv, but maybe > also noAuthNoPriv) > 3) the SM identity and the security name of the session > initiator > 4) possibly, the SM identity and security name of the > session listner > 5) possibly, the VACM group name > 6) possibly, other values for "overrides" and other session > related attributes. > > When an "encapsulation transport" session is created, entries > would be added to the table. And when a session is terminated, > then entries are removed from the table. This table would basically export the tmStateReference cache described in - which may be useful just for debugging purposes alone. However, I am rather strictly against a solution which requires to populate something in such a table to make things work. > I believe that the above approach works for and SSH "encapsulation > transport" session, and will also work for other session > based SMs. And I believe that it resolves the issue about > how the values from SNMP messages for flags to security level > is determined, and how to use the values in the security params > field. Yes. I also think that should figure out how sessions are initated, identified and used in generic terms. RFC 3430 has some text on this and I am not saying this approach is the right one or best one. But I think it would be nice if session oriented protocols could share some of this. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 09:22:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JCg-00080K-Ve; Wed, 03 Aug 2005 09:22:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0JCf-00080A-LP for isms@megatron.ietf.org; Wed, 03 Aug 2005 09:22:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15081 for ; Wed, 3 Aug 2005 09:22:36 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0JjM-0000Y5-B5 for isms@ietf.org; Wed, 03 Aug 2005 09:56:25 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2005 06:22:28 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j73DMNul017435; Wed, 3 Aug 2005 06:22:23 -0700 (PDT) Received: from [86.255.4.172] (ams-clip-vpn-dhcp270.cisco.com [10.61.65.14]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j73DJl6N008115; Wed, 3 Aug 2005 06:19:48 -0700 Message-ID: <42F0C512.3030908@cisco.com> Date: Wed, 03 Aug 2005 15:22:26 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: j.schoenwaelder@iu-bremen.de Subject: Re: [Isms] charter proposal References: <20050802153325.GA6968@open-31-253.ietf63.ietf.org> <42F063E1.1040303@cisco.com> <20050803070759.GA7943@boskop.local> In-Reply-To: <20050803070759.GA7943@boskop.local> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=4652; t=1123075190; x=1123507390; c=nowsp; s=nebraska; h=Subject:From:Sender:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20charter=20proposal| From:Eliot=20Lear=20| Date:Wed,=2003=20Aug=202005=2015=3A22=3A26=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=VyoORclDkPuEJe3YJ+yCssluvF9IWmtTP0MN6wugSnxZaCvcjmqq16sPTvHGd1n+Dfa9xRry JNK5fBBhizdkac77qfCF43Z1IWqzDWSmgfavw6Xsg7DaLiQdxiV/ndVRY0fDl9NDGq5L4tjbM1s jg96awKuQ0e5SHp1hxD7YgJQ= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, First let me say that I did not mean to direct the message at you. As I recall you played very little part in discussions at the actual meeting - not that there's anything wrong with that. My concern is that we have reached a perverse result without proper consideration of the ramifications (not that you caused such a result). Your message containing the proposed updated charter required me to respond as I find the charter wholly unacceptable (to the point that if it goes forward under the current conditions I will appeal). I recognize, however, that you are accurately reflecting the sense of the room. > The TMSM document was written with ssh in mind. This is mentioned in > the ID. I am happy to leave it to the chairs and the ADs to gauge the > level of discussion of SSH as a transport on the ISM WG mailing list > and to compare that to BEEP. Conveniently it works for both. And I generally think that the TMSM is good as far as it goes, and I agree with you that we should separate it out from protocol, adopt it as a WG doc, and get it done. As to the below: > Can't remember whether this is accurate. I do remember jabber log > statements that call home might be doable with ssh as well - I can't > judge that at the moment. I do however realize that SNMP right now > does not have call home - so you are proposing to add a feature to > SNMP which does not yet exist in that form. Yes, I am and it's important. The world is very different from the way it was when v3 was developed. Unless people find it necessary to do so I will not regurgitate the full logic behind this. > > >> - There was general preference for a single mechanism between NETCONF >> and SSH. > > > Not sure I understand the semantics of this sentence... In other words, better we end up with one protocol rather than two and in principle I agree with that notion. > I heard Simon saying that he uses SSH for management, actually using > passwords authentication (even though he seemed to prefer in principle > to use public key SSH authentication). Simon, correct me if I am wrong. Yes, he is sitting next to me (not on the list). This is what he said. However, he went on to vote for BEEP. > > I heard Ruediger saying that he doubts that someone types in SNMP > messages into SSH (which I can easily agree with) and that he does not > really care what the security protocol on the wire looks like as long > as it integrates. Ruediger, correct me if I am wrong. > > >> - NETCONF/SSH specifically excluded "call home" functionality. > > > Not sure this is accurate. I think NETCONF decided to make a straight > forward ssh mapping mandatory. Other mappings can be used as well but > are not mandatory. Well, the "straight ssh forward mapping" does not support call home. To quote draft-ietf-netconf-ssh-04.txt: > When NETCONF is run over SSH using the mapping defined in > this document, the client is always the manager, and the server is > always the agent. >>In our haste to create a solution that integrates with other security >>solutions we are producing something that won't integrate with other >>network management solutions. > > > Which ones? I doubt that SNMP based solutions have a call home feature > right now. No, I'm referring to {SNMP/NETCONF}/{SSH/BEEP}. Let's be clear: there is no call home function in the NETCONF/SSH mapping. Even if you do such a thing for SNMP/SSH, one must use two different call home mechanisms. This is how things are lining up and it's the wrong way to go. >>Now you could say that perhaps the NETCONF/SSH specification should have >>"call home" added to it. The reason Margaret didn't include it was that >>she felt if you wanted that sort of thing, use BEEP. That was her >>logic. It's not unreasonable. > > > I prefer to let Margaret speak for herself since there are different > interpretations possible for a statement of the sort "if you wanted > that sort of thing, use BEEP". While I agree it's always best if she speaks for herself, I don't believe I am misrepresenting her opinion. As you can see she followed through with it in the draft. > > >>I have no problem working through the issues that separate BEEP and SSH. >>But to have prematurely made the decision is, I assert again, unwise. > > > Maybe it is, maybe not. With netconf, we took the approach that SSH is > mandatory and to let the market sort out the rest. In isms, it was > somehow determined yesterday that doing this same approach wastes > resources. Yes, it's the "somehow" that eludes me. The decision as I repeatedly said yesterday is premature. > > If you think this decision is wrong, you should I think primarily > contact the chairs and the ADs - I am clearly not the one to determine > concensus. (So I am kind of wondering why this message was directed to > me and not to the chairs - perhaps too many Juergens around here.) Again, I apologize if this sounded like a complaint against you. It was not meant as such (far from it). I'm saying that the working group is going down a perilous path for many many reasons. It is not just the chairs and the ADs that need to hear this. It is the working group as it is the working group that needs to change course. Also, all decisions at IETF are confirmed by the mailing list. I am saying that this is one we ought not confirm. Instead, we should continue with draft development and compare approaches, particularly in light of the broader context, and then make a decision. The ADs have made it clear that they want us to finish, and have suggested that perhaps an interim meeting might help. I repeat my offer to the group: if the group would like to hold an interim meeting, I would be happy to host it at the end of September in Switzerland. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 10:22:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K91-0008NN-3r; Wed, 03 Aug 2005 10:22:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0K8z-0008IP-Fq for isms@megatron.ietf.org; Wed, 03 Aug 2005 10:22:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21225 for ; Wed, 3 Aug 2005 10:22:51 -0400 (EDT) Message-Id: <200508031422.KAA21225@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kff-0003oA-TL for isms@ietf.org; Wed, 03 Aug 2005 10:56:41 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080314224001100agj5te>; Wed, 3 Aug 2005 14:22:42 +0000 From: "David B Harrington" To: "'Tom Petch'" , Subject: RE: [Isms] charter proposal user-group mapping Date: Wed, 3 Aug 2005 10:22:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <02d501c59814$bc830c40$0601a8c0@pc6> Thread-Index: AcWYHUdxJhpdJE9jT/u/V1Q9j9yzVgAFAsJg X-Spam-Score: 0.1 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, > So an end user logs onto a server running an SNMP Command > Generator, is > authenticated and as part of that, the security server > specifies authorisations, > access permissions, rights etc which are mostly defined by > being a member of a > group. The Command Generator now has everything the Command > Responder needs to > know and so passes it, end user identity plus group > membership, to the Command > Responder in a secure manner (ssh transport, security > parameters, authenticated, > with > integrity) which uses it to access the access control rules. > > Obviously this does not yet exist for SNMPv3 but there are > parallels for other > aspects of network management. Again, I have no brief for > those who would > implement such code but if we provide the protocol, I believe > it is a simple > step forward. We have provided the protocol - it is called SNMPv3, and we provided a standards-based set of MIBs to hold such configuration information. Making the security remotely configurable was a definite design decision of the SNMPv3 WG. It certainly would be possible for a network management application (a Command Generator) to authenticate itself to the managed entity using USM (user=HPOV) and then, assuming it had appropriate rights via VACM, populate the USM tables and the VACM user-to-group mappings for the person who has authenticated themselve to the application (using OS security mechanisms). Then the application can perform all SNMP operations as the individual requesting the operation. All of this is imminently doable already, using industry standard mechanisms (SNMPv3/MIBs) already resident on the networking devices of most major equipment vendors, and readily available in many toolkits with host management capabilities. The application models exist in an application subsystem and new applications can be developed. Do you want to develop a security model or new command generator application that performs this type of forwarded security configuration? Do you think the application should pass the OS-authentication username/credentials to the managed entity? I think this would be a bad practice security-wise. Passing OS credentials to a managed device could be a mess configuration-wise because host-side authentication is typically not vendor-neutral, and would be difficult to support for all variations of LDAP server, ActiveDirectory, etc. Do you think the application should pass some type of vendor-neutral authentication credentials into the managed system? Do you think the protocol to pass on the information should be secure? If so, why not use SNMPv3 to do so? That's why we provided a standards-based protocol and data schema for this purpose. > > Likewise, my knowledge of standards-based systems leads me to > believe that this > could be done with them (although not necessarily with all of them). standards are great, everybody should own one? Why not use a vendor-neutral standard, such as SNMPv3? > > I do believe that retrieving the group membership at the time > the SNMPv3 > principal is authenticated is the key function and that > everything else needs to > stem from it. I question the need to do this. If HPOV is an authenticated entity with manageent rights on a remote device, and a user authenticates to HPOV, why not simply let HPOV request the SNMP operations for the user? That would minimize the amount of remote configuration needed. Why go through the whole process of configuring the user credentials into the managed device and then sending messages using the authentication information of that principal? Why not just act as a trusted proxy for that principal (which you would be doing in either case)? Oh, because we want to track who made what changes to which managed objects? I've heard this for years and have never seen it actually done. How does one do this? I am aware of no standard mechanism that provides the promised logging or auditing of SNMP operations. Certainly HPOV could track which requests it performed for which authenticated users, and that would make it a non-requirement for the managed station to maintain such auditing info. So do we really gain anything by having a Command Generator populate user info or user-to-group mappings at the time of authentication? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 10:27:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KD3-0001pg-N7; Wed, 03 Aug 2005 10:27:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KD1-0001pA-B0 for isms@megatron.ietf.org; Wed, 03 Aug 2005 10:27:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21571 for ; Wed, 3 Aug 2005 10:27:01 -0400 (EDT) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kjg-00041h-S7 for isms@ietf.org; Wed, 03 Aug 2005 11:00:51 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j73EPfsS029974; Wed, 3 Aug 2005 09:25:42 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Aug 2005 16:25:41 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507B5C2D3@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 16:25:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org w.r.t. > Also, all decisions at IETF are confirmed by the mailing list. I am > saying that this is one we ought not confirm. Instead, we should > continue with draft development and compare approaches, > particularly in > light of the broader context, and then make a decision. > > The ADs have made it clear that they want us to finish, and have > suggested that perhaps an interim meeting might help. First, in this case I am not an AD for the WG. I am SNMP (or OPS area) advisor to the WG. So I do not play AD role here. Second, I did indeed make that suggestion, and stated that such would be acceptable to me, but that I rather prefer a decision now. I do not recall that Sam in fact agreed with the suggestion. I'd expect he wants to see more discussion on the list w.r.t. confirming the decision that seemed obvious in the f2f WG session. Sam can speak up if I am mis-representing him. Let me add (for repeated clarity): The only reason I even though of this is because some were asking for another delay to Vancouver (i.e extend yet one more IETF meeting as we have had so many before). An interim would give some extra time (max september in my view) to better discuss the choice between the shortlist (ssh and beep). But it at the same time REQUIRES commitement from all WG members to do a lot os serious work within the next 5-7 weeks and to invest not only time but also travel to an interim. In other words a lot of extra work in order to get a little bit of extra time. Again, it was a suggestion that I can live with, but which is up to the AD (Sam) to approve. Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 10:39:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KOz-00010f-9E; Wed, 03 Aug 2005 10:39:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0KOx-00010Z-3W for isms@megatron.ietf.org; Wed, 03 Aug 2005 10:39:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22708 for ; Wed, 3 Aug 2005 10:39:21 -0400 (EDT) Message-Id: <200508031439.KAA22708@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Kvd-0004ab-Of for isms@ietf.org; Wed, 03 Aug 2005 11:13:10 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080314391201100aetise>; Wed, 3 Aug 2005 14:39:12 +0000 From: "David B Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Eliot Lear'" , Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 10:38:54 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507B5C2D3@nl0006exch001u.nl.lucent.com> Thread-Index: AcWYN37sKuFscMYlSQC4VkcI6ZAQYgAALFAA X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: 'Margaret Wasserman' , 'Andy Bierman' , 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Bert, > An interim would give some extra > time (max september in my view) to better discuss the choice between > the shortlist (ssh and beep). But it at the same time REQUIRES > commitement from all WG members to do a lot os serious work within > the next 5-7 weeks and to invest not only time but also travel > to an interim. I don't mind that you are trying to force people to do a lot of serious work within the next 5-7 weeks; I am concerned that you are trying to force a commitment to travel; that will make it hard for some to participate fully, including many of those who have publicly committed to doing the hard work for the next 5-7 weeks. Most of the (promised) editors of the SSH proposal will not be able to travel, and telecommuting to an interim just doesn't permit the same level of participation. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 12:03:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Lia-00074a-Vd; Wed, 03 Aug 2005 12:03:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0LiZ-000735-DZ for isms@megatron.ietf.org; Wed, 03 Aug 2005 12:03:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27490 for ; Wed, 3 Aug 2005 12:03:41 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0MFF-00083d-Lh for isms@ietf.org; Wed, 03 Aug 2005 12:37:32 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j73G2jHn023450; Wed, 3 Aug 2005 09:02:45 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Aug 2005 09:04:10 -0700 Message-ID: From: "McDonald, Ira" To: "'Wijnen, Bert (Bert)'" , Eliot Lear , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 09:04:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: Margaret Wasserman , Andy Bierman , Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, With much respect to all people involved, I note that nearly a year has passed since this working group rushed into work. And the divisions and disagreements are, if anything, worse. If people with strongly held opinions on specific directions would sit down and write REALLY complete proposals, maybe this effort would progress. As a working group, it feels a lot like the many years SNMPv2 debacle. And of course, NOTHING was decided in Paris. This is a chartered IETF working group. Rough concensus on the mailing list is the ONLY place that decisions get made. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Wijnen, Bert (Bert) > Sent: Wednesday, August 03, 2005 10:26 AM > To: Eliot Lear; j.schoenwaelder@iu-bremen.de > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > Subject: RE: [Isms] charter proposal > > > w.r.t. > > Also, all decisions at IETF are confirmed by the mailing list. I am > > saying that this is one we ought not confirm. Instead, we should > > continue with draft development and compare approaches, > > particularly in > > light of the broader context, and then make a decision. > > > > The ADs have made it clear that they want us to finish, and have > > suggested that perhaps an interim meeting might help. > > First, in this case I am not an AD for the WG. I am SNMP (or OPS area) > advisor to the WG. So I do not play AD role here. > > Second, I did indeed make that suggestion, and stated that such > would be acceptable to me, but that I rather prefer a decision now. > > I do not recall that Sam in fact agreed with the suggestion. > I'd expect > he wants to see more discussion on the list w.r.t. confirming the > decision that seemed obvious in the f2f WG session. Sam can > speak up if I am mis-representing him. > > Let me add (for repeated clarity): > The only reason I even though of this is because some were asking > for another delay to Vancouver (i.e extend yet one more IETF meeting > as we have had so many before). An interim would give some extra > time (max september in my view) to better discuss the choice between > the shortlist (ssh and beep). But it at the same time REQUIRES > commitement from all WG members to do a lot os serious work within > the next 5-7 weeks and to invest not only time but also travel > to an interim. In other words a lot of extra work in order to get > a little bit of extra time. > > Again, it was a suggestion that I can live with, but which is up to > the AD (Sam) to approve. > > Bert > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 12:26:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M4D-0001lx-9C; Wed, 03 Aug 2005 12:26:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0M4C-0001kc-CC for isms@megatron.ietf.org; Wed, 03 Aug 2005 12:26:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28766 for ; Wed, 3 Aug 2005 12:26:01 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Mat-0000X4-Ol for isms@ietf.org; Wed, 03 Aug 2005 12:59:53 -0400 Received: from wired-5-117.ietf63.ietf.org (open-25-41.ietf63.ietf.org [86.255.25.41]) by kyoto.netlab.nec.de (Postfix) with ESMTP id EC19E1BAC4D; Wed, 3 Aug 2005 18:25:52 +0200 (CEST) Date: Wed, 03 Aug 2005 18:25:50 +0200 From: Juergen Quittek To: isms@ietf.org, housley@vigilsec.com, hartmans-ietf@mit.edu Message-ID: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] ISMS session summary and draft minutes X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Below please find a summary of our session yesterday. Please find the detailed draft minutes at . Many thanks to Martin for taking the minutes! We had a long discussion and probably not every statement was captured correctly in the minutes. Please check them. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de =================================== IETF-63 ISMS Session Summary Tuesday August 2, 14:00 h - 16:00 h =================================== In April the WG achieved (very rough) consensus on using an encapsulated keying architecture (as used by the TLSM proposal). At this meeting the WG progressed the decision on a transport protocol to be used by ISMS. Candidate protocols were TLS+SASL, SSH, DTLS, and BEEP. Among the proposals, DTLS is the only one based on UDP. Since DTLS is not yet commonly deployed and not extensively tested, it was eliminated from the discussion after the WG agreed that UDP transport is not necessarily required for the ISMS solution. For all of the remaining three protocols there was support in the WG. Among them, SSH had clearly the strongest support, mainly, because SSH is already widely deployed and used in network management and thus could best achieve the goal of integrating the ISMS solution into existing security infrastructures. Within the session there was a consensus on choosing only one protocol as work item and there was rough consensus that this protocol would be SSH. The consensus still needs to be confirmed on the mailing list. Decisions made: - ISMS will work on one transport protocol only - Use SSH as transport protocol Action items: - confirm WG consensus on decisions on the mailing list (August) - draft new charter, discuss on mailing list (August) - start work on SSH-based solution _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 13:46:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0NK5-0004gs-CO; Wed, 03 Aug 2005 13:46:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0NK3-0004eB-KF for isms@megatron.ietf.org; Wed, 03 Aug 2005 13:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03235 for ; Wed, 3 Aug 2005 13:46:28 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Nqk-00040l-MY for isms@ietf.org; Wed, 03 Aug 2005 14:20:21 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA01170; Wed, 3 Aug 2005 10:46:00 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j73HkBv29390; Wed, 3 Aug 2005 12:46:11 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 3 Aug 2005 10:46:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] securityName Date: Wed, 3 Aug 2005 10:45:22 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBC87A@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] securityName Thread-Index: AcWYBBYxWuQlqsYpQbCg56Z8c5R8IAARsY8w From: "Fleischman, Eric" To: "Tom Petch" X-OriginalArrivalTime: 03 Aug 2005 17:46:06.0671 (UTC) FILETIME=[39A465F0:01C59853] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, I concur with your analysis. However, additional issues are whether the application level, which is SNMPv3 USM/VACM in this case, uses the same authentication credentials as the transport layer security (e.g., TLS, SSH, DTLS) or not. My own belief is that security can be enhanced if transport-layer authentication, which is used to create transaction privacy via TLS, SSH, or DTLS, is distinct from application layer authentication. This permits a virtual two-factor authentication-like system by having the transport layer leverage "what you have" credentials or Radius lookups or whatever and the application layer use "what you know" passwords, or their symmetric key constructs such as what SNMPv3 currently enables. This means that it is theoretically possible to "bolt on" a standard (modern) transport layer security addition to SNMPv3, and fully benefit from its transport privacy provisions, and still maintain the historic SNMPv3 authentication system untouched, except perhaps for its privacy provisions (unless we want redundancies there). Of course, we still would have the historic SNMPv3 symmetic key distribution problem about which I've complained repeatedly, but my complaints would be addressed if a secure standards track key distribution system would be defined for SNMPv3. After all, SNMPv3 currently supports AES today, if only we could securely distribute those keys. Alternatively, we could integrate the transport layer authentication with the application layer authentication. My reading of the mail list is that the latter is what the WG is presuming, but if we go that way then we really need to define how USM/VACM can handle novel-to-USM concepts such as asymmetric keys. The latter are the issues that I have been worrying about. --Eric From: Tom Petch [mailto:nwnetworks@dial.pipex.com]=20 >Every xSM should be passed the same parameters=20 >and return the same values, as per the ASI in the=20 >SNMPv3 Architecture. Trouble is, when security=20 >is done at transport level (SSH, TLS), the security=20 >is best done before ever the PDU gets to the message=20 >processing subsystem so its calls, eg to get the PDU=20 >decrypted, are somewhat meaningless. So for me,=20 >the architecture does not allow for transport level=20 >security and so needs flexing or changing; I don't=20 >see this as a problem, others do. Likewise, the=20 >transport level knows what authentication has taken=20 >place, who the 'principal' is; no way to pass this=20 >on - the security model is expected to produce it out=20 >of a hat from the msgSecurityParameters for the message=20 >processing subsystem whereas, with transport level=20 >security, the security parameters are no longer in the=20 >SNMP PDU but part of the SSH/TLS header. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 14:09:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nft-0005LQ-Ts; Wed, 03 Aug 2005 14:09:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nfs-0005LE-Cj for isms@megatron.ietf.org; Wed, 03 Aug 2005 14:09:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04108 for ; Wed, 3 Aug 2005 14:09:03 -0400 (EDT) Message-Id: <200508031809.OAA04108@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0OCa-0004q1-KU for isms@ietf.org; Wed, 03 Aug 2005 14:42:54 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080318085001100ai71te>; Wed, 3 Aug 2005 18:08:50 +0000 From: "David B Harrington" To: "'McDonald, Ira'" Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 14:08:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYRP9mPNb0PuEFTue7LZwd0m6IWwADTBqQ In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Ira, I totally disagree with your analysis. I think we have accomplished a lot. Not as much as I would have liked, but a lot nonetheless. We have written multiple proposals, reviewed those proposals, convened an official review team and published a fairly detailed analysis of the proposals, discussed the ramifications of the architectural differences of the proposals, eliminated some proposals, chosen a general direction for focus (use of encapulating protocols to carry SNMP messages), cleaned up the initial proposal, identified and discussed many technical issues relative to the TMSM approach, had a BEEP/TMSM proposal written and reviewed, and started work on an SSH/TMSM proposal - and we have seven editors willing to commit to working against a short deadline. I see lots of agreement on direction, and even though some industry segments wish we had selected different directions, rough consensus on the chosen direction. I wish some of the other WGs I've been in had made this kind of progress. As far as this being comparable to SNMPv2 years, no way! During those years we suffered through tremendous ego battles as responsibility for designing solutions shifted from the "big four" players to the whole SNMP community; abandoned a Proposed Standard when we realized the design was completely non-viable for application vendors; we suffered the segmentation of the community into two major "camps"; and we suffered through an imposed shutdown of the WG and ALL network management development work, not because the WG couldn't reach consensus or finish documents but to avoid the constant acrimonious flame wars between the camps. We are seeing none of the ego battles or flame wars in this WG, and given the progress we have manifested, I think it unlikely this WG will be shutdown soon. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > Sent: Wednesday, August 03, 2005 12:04 PM > To: 'Wijnen, Bert (Bert)'; Eliot Lear; j.schoenwaelder@iu-bremen.de > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > Subject: RE: [Isms] charter proposal > > Hi, > > With much respect to all people involved, I note that nearly > a year has passed since this working group rushed into work. > And the divisions and disagreements are, if anything, worse. > > If people with strongly held opinions on specific directions > would sit down and write REALLY complete proposals, maybe this > effort would progress. > > As a working group, it feels a lot like the many years SNMPv2 > debacle. > > And of course, NOTHING was decided in Paris. This is a chartered > IETF working group. Rough concensus on the mailing list is the > ONLY place that decisions get made. > > Cheers, > - Ira > > Ira McDonald (Musician / Software Architect) > Blue Roof Music / High North Inc > PO Box 221 Grand Marais, MI 49839 > phone: +1-906-494-2434 > email: imcdonald@sharplabs.com > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Wednesday, August 03, 2005 10:26 AM > > To: Eliot Lear; j.schoenwaelder@iu-bremen.de > > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > > Subject: RE: [Isms] charter proposal > > > > > > w.r.t. > > > Also, all decisions at IETF are confirmed by the mailing > list. I am > > > saying that this is one we ought not confirm. Instead, we should > > > continue with draft development and compare approaches, > > > particularly in > > > light of the broader context, and then make a decision. > > > > > > The ADs have made it clear that they want us to finish, and have > > > suggested that perhaps an interim meeting might help. > > > > First, in this case I am not an AD for the WG. I am SNMP > (or OPS area) > > advisor to the WG. So I do not play AD role here. > > > > Second, I did indeed make that suggestion, and stated that such > > would be acceptable to me, but that I rather prefer a decision now. > > > > I do not recall that Sam in fact agreed with the suggestion. > > I'd expect > > he wants to see more discussion on the list w.r.t. confirming the > > decision that seemed obvious in the f2f WG session. Sam can > > speak up if I am mis-representing him. > > > > Let me add (for repeated clarity): > > The only reason I even though of this is because some were asking > > for another delay to Vancouver (i.e extend yet one more IETF meeting > > as we have had so many before). An interim would give some extra > > time (max september in my view) to better discuss the choice between > > the shortlist (ssh and beep). But it at the same time REQUIRES > > commitement from all WG members to do a lot os serious work within > > the next 5-7 weeks and to invest not only time but also travel > > to an interim. In other words a lot of extra work in order to get > > a little bit of extra time. > > > > Again, it was a suggestion that I can live with, but which is up to > > the AD (Sam) to approve. > > > > Bert > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 14:26:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nwq-0004VZ-JN; Wed, 03 Aug 2005 14:26:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Nwm-0004Pm-Ti for isms@megatron.ietf.org; Wed, 03 Aug 2005 14:26:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05176 for ; Wed, 3 Aug 2005 14:26:31 -0400 (EDT) Message-Id: <200508031826.OAA05176@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0OTV-0005az-Ee for isms@ietf.org; Wed, 03 Aug 2005 15:00:22 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005080318262001100afc85e>; Wed, 3 Aug 2005 18:26:20 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" Subject: RE: [Isms] securityName Date: Wed, 3 Aug 2005 14:26:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYBBYxWuQlqsYpQbCg56Z8c5R8IAARsY8wAAL5NpA= In-Reply-To: <474EEBD229DF754FB83D256004D02108BBC87A@XCH-NW-6V1.nw.nos.boeing.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, > My own belief is that security can be enhanced if transport-layer > authentication, which is used to create transaction privacy via TLS, > SSH, or DTLS, is distinct from application layer authentication. This > permits a virtual two-factor authentication-like system by having the > transport layer leverage "what you have" credentials or Radius lookups > or whatever and the application layer use "what you know" > passwords, or > their symmetric key constructs such as what SNMPv3 currently enables. I hear you asking for enhancements but not working to develop them. Your desired solution is only waiting for some author to write it, Eric. I hereby formally invite you to do so. > > This means that it is theoretically possible to "bolt on" a standard > (modern) transport layer security addition to SNMPv3, and > fully benefit > from its transport privacy provisions, and still maintain the historic > SNMPv3 authentication system untouched, except perhaps for its privacy > provisions (unless we want redundancies there). You can do that now; you don't need ISMS to achieve that. > Of course, we still > would have the historic SNMPv3 symmetic key distribution problem about > which I've complained repeatedly, but my complaints would be addressed > if a secure standards track key distribution system would be > defined for > SNMPv3. After all, SNMPv3 currently supports AES today, if > only we could > securely distribute those keys. That desired solution is only waiting for some author to write it, Eric. I hereby formally invite you to do so. > > Alternatively, we could integrate the transport layer authentication > with the application layer authentication. That's what some us believe is the solution to pursue and we've stepped up to write the documents to make it happen. > My reading of the mail list > is that the latter is what the WG is presuming, but if we go that way > then we really need to define how USM/VACM can handle novel-to-USM > concepts such as asymmetric keys. The latter are the issues > that I have > been worrying about. > > --Eric > David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 15:30:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ox9-0002vg-A9; Wed, 03 Aug 2005 15:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Ox7-0002vb-W9 for isms@megatron.ietf.org; Wed, 03 Aug 2005 15:30:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09018 for ; Wed, 3 Aug 2005 15:30:56 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0PTo-00083j-TQ for isms@ietf.org; Wed, 03 Aug 2005 16:04:48 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2005 12:30:43 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j73JUfJM017915; Wed, 3 Aug 2005 12:30:41 -0700 (PDT) Message-Id: <6.2.0.14.0.20050803120037.04235f18@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 03 Aug 2005 12:30:41 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] charter proposal In-Reply-To: <200508022122.RAA17954@ietf.org> References: <20050802193617.GB7546@boskop.local> <200508022122.RAA17954@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I would be interested in hearing from vendors and operators and the >people arguing for this user-to-group-mapping feature just HOW they >currently use AAA to provide user-to-group mappings for network >management access control. Cisco IOS currently has the following mechanisms for access control for the CLI commands. Cisco IOS supports 16 privilege levels (0-15) that can be setup on a RADIUS (TACACS+) server and will be sent to the device using a Cisco RADIUS VSA (shell:priv-lvl) http://www.cisco.com/warp/public/480/PRIV.html More recently we have augmented the privilege level model to support more flexible RBAC like support with CLI views (a.k.a roles) and we have a Cisco RADIUS VSA (shell:cli-view-name) used to communicate the view name of the user to the device. CLI views (similar to SNMPv3 VACM views) must be defined locally on the device. http://www.cisco.com/en/US/products/ps6350/products_configuration_guide_chapter09186a0080455b96.html#wp1073986 In addition to this, TACACS+ also supports per command authorization, i.e. a TACACS+ authorization request/response will be used to authorize each command being received by the device. http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fsecur_c/fsecsp/scftplus.htm#1001102 Hope this helps, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 16:39:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Q1q-0002IL-He; Wed, 03 Aug 2005 16:39:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Q1m-0002Ay-SN for isms@megatron.ietf.org; Wed, 03 Aug 2005 16:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18529 for ; Wed, 3 Aug 2005 16:39:48 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0QYV-0004MX-5V for isms@ietf.org; Wed, 03 Aug 2005 17:13:41 -0400 Received: from pc6 (1Cust7.tnt27.lnd4.gbr.da.uu.net [62.188.154.7]) by galaxy.systems.pipex.net (Postfix) with SMTP id 32C93E00024F; Wed, 3 Aug 2005 21:39:30 +0100 (BST) Message-ID: <054101c59862$e90baa80$0601a8c0@pc6> From: "Tom Petch" To: References: <20050803124435.1DDD0E00009C@dragons.systems.pipex.net> Subject: Re: [Isms] Comments on the BTSMS proposal Date: Wed, 3 Aug 2005 21:37:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Thank you for your comments; I am glad we are in the same ballpark about small changes to the RFC3411 Architecture. I think recognition of this is rather important. The only minor point I would like to add to is about including the actual security level in the information passed to the engine. I have no problem with the requested security level being handled as it is. I cannot currently produce a compelling reason why we need the actual security level when we are using SSH security at the transport layer but have a nagging feeling we will, perhaps for security audits, logs, exploitation by the engine itself (eg it knows it has priv and so can afford to send information it otherwise would not),.... so I would rather see it passed betwen transport and engine if it reasonably can, rather than find out later it is needed and we don't have it. If those on this list with a security background say that knowing the actual security level used (authentication, encryption, integrity - not the particular algorithm) in a data transfer is not needed for security purposes, I would feel reassured (ie would shut up about it). eg if a security breach is detected, does it matter that we do not know at the application level whether the message was encrypted or not? Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" ; Cc: Sent: Wednesday, August 03, 2005 2:44 PM Subject: RE: [Isms] Comments on the BTSMS proposal > Hi Tom, > > You're making assumptions about what is required in SNMPv3 processing, > and I don't agree with some of your assumptions. > > > > > When security is outside SNMP, at the transport layer, then > > > > somewhere in the SNMP engine needs to tell TMSM or > > transport what is > > > > wanted, which then says yes or no; and the level on the wire may > > > > exceed what is requested (eg authPriv v authNoPriv) which, IMHO, > > > > needs recording in the packet (where?) and needs passing up the > > > > stack of the recipient (how?). > > Why does this need to be included in the PDU? When I send an SNMP > message (or a FTP packet, or ...) over an IPSec network, should the > PDU be modified to show what securitylevel IPSec used? > > There are two reasons msgflags are passed in SNMPv3 messages. > > The first reason is to ensure that the information is handled by the > recipient with the same concern for data sensitivity. I don't see any > problem with providing stronger security than requested. What happens > if I use SNMPv3 noAuthNoPriv over a VPN that does authentication and > encryption? Do we need to change the msgFlags in the SNMP message? > What happens if we use USM AuthPriv and the message passes over a > nonsecure network and a VPN that does authentication and encryption? > The minimum security is still AuthPriv, regardless of the maximum > level of security applied in transit, or the lack of security applied > in transit. > > "The authFlag and privFlag portions of the msgFlags field are set by > the sender to indicate the securityLevel that was applied to the > message before it was sent on the wire. " > > If you want to argue for a literal interpretation of the requirements, > then the sender who relies on a transport layer to provide auth and > priv should set the message flags to noAuthNoPriv, since that's what > was applied to the message before it was sent on the wire (i.e. sent > to the lower layer in the communications stack). > > Obviously, the engine requests a securityLevel from the underlying > transport and ensures that the transport protocol agrees to meet its > minimum criteria before sending it on the wire. All the engine can do > is assert that (at least) this level of security has been applied. > > The second reason msgFlags is included in the message is an artifact > of USM security - msgFlags alerts the recipient's USM model about > which lookups they need to do in the USM MIB to get the shared keys > for authentication and encryption. SSH, TLS, SAL all have different > mechanisms for determining how to get shared keys or other > credentials; they don't need this passed in the SNMP message. > > > Same argument. The security model is expected to derive a > > securityName from the > > msgSecurityParameters in the PDU. > > The USM security model does it this way, but this is not an > architectural requirement. > > From RFC3411: > The transformation of model-dependent security IDs into > securityNames > and vice versa is the responsibility of the relevant Security > Model. > > From RFC3412: > 6.6. msgSecurityParameters > > The msgSecurityParameters field of the SNMPv3 Message is used for > communication between the Security Model modules in the sending and > receiving SNMP engines. The data in the msgSecurityParameters > field > is used exclusively by the Security Model, and the contents and > format of the data is defined by the Security Model. This OCTET > STRING is not interpreted by the v3MP, but is passed to the local > implementation of the Security Model indicated by the > msgSecurityModel field in the message. > > > > I was > > interested to be reminded by dbh of the SNMP 'WG consensus > > requirements such as > > "the mandatory-to-implement models should have no > > dependencies on external > > protocols" '. > > Yes, because one purpose of SNMP is to troubleshoot broken networks, > and the mandatory-to-implement protocol needs to work (if possible) > even when the network is broken; having a dependency on an external > authentication server increases the likelihood that SNMP will not > function when the network is broken. > > While desirable, (I believe) this is not a requirement for > supplemental security models, since USM can provide the > troubleshooting capability. Some have argued that USM should not be > replaced by a new security model; if that occurs, the replacement > security model would be faced with this requirement. > > > We are now introducing a greater dependence on external > > protocols - SSH et al - albeit for non-mandatory models and > > for me, that puts > > the architecture under strain. > > It in no way puts the architecture under strain. It has long been > considered a desirable thing to tie into existing security > infrastructure, and the architecture was designed to allow different > security models to be developed that could utilize various approaches > to security. If you can locate the old SNMPv2 archives, you can see > the debates about how to leverage IPSec to secure SNMP. This was > definitely recognized as a potential approach to security. > > I will agree we didn't do a very good at providing a layered > architecture so we could utilize lower layers for security easily, but > the use of external security definitely was considered. Note that the > SNMPv3 architecture reached standards track before most of the > transport layer security protocols (and SecSH hasn't gotten there > yet); it's hard to plan the architectural fit with external protocols > still in development. > > > > > dbh also says > > 'If the TMSM is going to pass transport information from the > transport > > mapping to the SM subsystem, either through a cache or an ASI > > parameter, we need to standardize how this is done, how it affects > > existing models and MIB modules, and how to document these changes > > within the IETF.' > > > > Again, a matter of judgment, but I see this as close to > > suggesting a small > > change to the architecture as defined in RFC3411 caused by a > > dependency on > > external protocols. > > I don't see this as close to suggesting a small change in the > architecture as defined in RFC3411; I see this as definitely > suggesting a small change to the architecture as defined in RFC3411, > but in a way that is consistent with the precedents of the > architecture defined in RFC3411. > > This change is required because the RFC3411 ASIs were knowingly made > inadequate to support transport security. There was a political > battle in the SNMPv2/v3 WGs over whether SNMPv2/v3 should support the > use of source address as an authentication mechanism. Despite its > popularity with operators, and the strong insistence of one of the > "major players", given the ease of address spoofing, the WGs decided > to not pass the transport info into the security subsystem, and to not > allow the transport mapping to provide authentication, to encourage > operators to use the stronger authenticatino mechanisms supported by > USM and other expected security models. This political decision has > come back to haunt us. > > > > > > > Tom Petch > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 17:19:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Qe2-00077W-GT; Wed, 03 Aug 2005 17:19:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0Qe0-00076k-L6 for isms@megatron.ietf.org; Wed, 03 Aug 2005 17:19:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20002 for ; Wed, 3 Aug 2005 17:19:18 -0400 (EDT) Received: from tui75-2-82-229-178-125.fbx.proxad.net ([82.229.178.125] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0RAk-0005g0-Iq for isms@ietf.org; Wed, 03 Aug 2005 17:53:11 -0400 Received: by boskop.local (Postfix, from userid 501) id 52A283A5222; Wed, 3 Aug 2005 23:18:58 +0200 (CEST) Date: Wed, 3 Aug 2005 23:18:58 +0200 From: Juergen Schoenwaelder To: Tom Petch Subject: Re: [Isms] Comments on the BTSMS proposal Message-ID: <20050803211858.GA851@boskop.local> Mail-Followup-To: Tom Petch , isms@ietf.org References: <20050803124435.1DDD0E00009C@dragons.systems.pipex.net> <054101c59862$e90baa80$0601a8c0@pc6> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <054101c59862$e90baa80$0601a8c0@pc6> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 03, 2005 at 09:37:28PM +0200, Tom Petch wrote: > The only minor point I would like to add to is about including the > actual security level in the information passed to the engine. I > have no problem with the requested security level being handled as > it is. I cannot currently produce a compelling reason why we need > the actual security level when we are using SSH security at the > transport layer but have a nagging feeling we will, perhaps for > security audits, logs, exploitation by the engine itself (eg it > knows it has priv and so can afford to send information it otherwise > would not),.... so I would rather see it passed betwen transport and > engine if it reasonably can, rather than find out later it is needed > and we don't have it. If you read the TLSM draft, you will see that this information is supposed to be passed via a cache reference between the transport layer security portion and the SNMP layer security portion. Dave Perkins suggested to support a MIB module which allows you to retrieve information about the session details, which might be useful (if alone for debugging purposes). > If those on this list with a security background say that knowing > the actual security level used (authentication, encryption, > integrity - not the particular algorithm) in a data transfer is not > needed for security purposes, I would feel reassured (ie would shut > up about it). eg if a security breach is detected, does it matter > that we do not know at the application level whether the message was > encrypted or not? As said above, the TLSM draft passes this information up to the security model portion of the SSH security model where a check can be made whether the actual security level matches the required security level. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 03 17:48:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0R5r-0001BM-T0; Wed, 03 Aug 2005 17:48:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0R5p-000168-G4 for isms@megatron.ietf.org; Wed, 03 Aug 2005 17:48:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20912 for ; Wed, 3 Aug 2005 17:48:03 -0400 (EDT) Message-Id: <200508032148.RAA20912@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0RcZ-0006cW-Nd for isms@ietf.org; Wed, 03 Aug 2005 18:21:57 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005080321475401400d8l57e>; Wed, 3 Aug 2005 21:47:54 +0000 From: "David B Harrington" To: "'Tom Petch'" Subject: RE: [Isms] Comments on the BTSMS proposal Date: Wed, 3 Aug 2005 17:47:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWYa3TkVnCWXcpASWWT64/JgI9HIgACUcOA In-Reply-To: <054101c59862$e90baa80$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, Be aware that I believe the msgFlags should incicate a minimum level of security that the sending engine has applied (or arranged). I would consider it a real problem if the transport did not provide at least the amount of security specified in msgFlags. dbh > -----Original Message----- > From: Tom Petch [mailto:nwnetworks@dial.pipex.com] > Sent: Wednesday, August 03, 2005 3:37 PM > To: ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: Re: [Isms] Comments on the BTSMS proposal > > David > > Thank you for your comments; I am glad we are in the same > ballpark about small > changes to the RFC3411 Architecture. I think recognition of > this is rather > important. > > The only minor point I would like to add to is about > including the actual > security level in the information passed to the engine. I > have no problem with > the requested security level being handled as it is. I > cannot currently produce > a compelling reason why we need the actual security level > when we are using SSH > security at the transport layer but have a nagging feeling we > will, perhaps for > security audits, logs, exploitation by the engine itself (eg > it knows it has > priv and so can afford to send information it otherwise would > not),.... so I > would rather see it passed betwen transport and engine if it > reasonably can, > rather than find out later it is needed and we don't have it. > > If those on this list with a security background say that > knowing the actual > security level used (authentication, encryption, integrity - > not the particular > algorithm) in a data transfer is not needed for security > purposes, I would feel > reassured (ie would shut up about it). eg if a security > breach is detected, does > it matter that we do not know at the application level > whether the message was > encrypted or not? > > Tom Petch > > ----- Original Message ----- > From: "David B Harrington" > To: "'Tom Petch'" ; > > Cc: > Sent: Wednesday, August 03, 2005 2:44 PM > Subject: RE: [Isms] Comments on the BTSMS proposal > > > > Hi Tom, > > > > You're making assumptions about what is required in SNMPv3 > processing, > > and I don't agree with some of your assumptions. > > > > > > > When security is outside SNMP, at the transport layer, then > > > > > somewhere in the SNMP engine needs to tell TMSM or > > > transport what is > > > > > wanted, which then says yes or no; and the level on > the wire may > > > > > exceed what is requested (eg authPriv v authNoPriv) > which, IMHO, > > > > > needs recording in the packet (where?) and needs > passing up the > > > > > stack of the recipient (how?). > > > > Why does this need to be included in the PDU? When I send an SNMP > > message (or a FTP packet, or ...) over an IPSec network, should the > > PDU be modified to show what securitylevel IPSec used? > > > > There are two reasons msgflags are passed in SNMPv3 messages. > > > > The first reason is to ensure that the information is handled by the > > recipient with the same concern for data sensitivity. I > don't see any > > problem with providing stronger security than requested. > What happens > > if I use SNMPv3 noAuthNoPriv over a VPN that does authentication and > > encryption? Do we need to change the msgFlags in the SNMP message? > > What happens if we use USM AuthPriv and the message passes over a > > nonsecure network and a VPN that does authentication and encryption? > > The minimum security is still AuthPriv, regardless of the maximum > > level of security applied in transit, or the lack of > security applied > > in transit. > > > > "The authFlag and privFlag portions of the msgFlags field are set by > > the sender to indicate the securityLevel that was applied to the > > message before it was sent on the wire. " > > > > If you want to argue for a literal interpretation of the > requirements, > > then the sender who relies on a transport layer to provide auth and > > priv should set the message flags to noAuthNoPriv, since that's what > > was applied to the message before it was sent on the wire (i.e. sent > > to the lower layer in the communications stack). > > > > Obviously, the engine requests a securityLevel from the underlying > > transport and ensures that the transport protocol agrees to meet its > > minimum criteria before sending it on the wire. All the > engine can do > > is assert that (at least) this level of security has been applied. > > > > The second reason msgFlags is included in the message is an artifact > > of USM security - msgFlags alerts the recipient's USM model about > > which lookups they need to do in the USM MIB to get the shared keys > > for authentication and encryption. SSH, TLS, SAL all have different > > mechanisms for determining how to get shared keys or other > > credentials; they don't need this passed in the SNMP message. > > > > > Same argument. The security model is expected to derive a > > > securityName from the > > > msgSecurityParameters in the PDU. > > > > The USM security model does it this way, but this is not an > > architectural requirement. > > > > From RFC3411: > > The transformation of model-dependent security IDs into > > securityNames > > and vice versa is the responsibility of the relevant Security > > Model. > > > > From RFC3412: > > 6.6. msgSecurityParameters > > > > The msgSecurityParameters field of the SNMPv3 Message is used for > > communication between the Security Model modules in the > sending and > > receiving SNMP engines. The data in the msgSecurityParameters > > field > > is used exclusively by the Security Model, and the contents and > > format of the data is defined by the Security Model. This OCTET > > STRING is not interpreted by the v3MP, but is passed to the local > > implementation of the Security Model indicated by the > > msgSecurityModel field in the message. > > > > > > > I was > > > interested to be reminded by dbh of the SNMP 'WG consensus > > > requirements such as > > > "the mandatory-to-implement models should have no > > > dependencies on external > > > protocols" '. > > > > Yes, because one purpose of SNMP is to troubleshoot broken networks, > > and the mandatory-to-implement protocol needs to work (if possible) > > even when the network is broken; having a dependency on an external > > authentication server increases the likelihood that SNMP will not > > function when the network is broken. > > > > While desirable, (I believe) this is not a requirement for > > supplemental security models, since USM can provide the > > troubleshooting capability. Some have argued that USM should not be > > replaced by a new security model; if that occurs, the replacement > > security model would be faced with this requirement. > > > > > We are now introducing a greater dependence on external > > > protocols - SSH et al - albeit for non-mandatory models and > > > for me, that puts > > > the architecture under strain. > > > > It in no way puts the architecture under strain. It has long been > > considered a desirable thing to tie into existing security > > infrastructure, and the architecture was designed to allow different > > security models to be developed that could utilize various > approaches > > to security. If you can locate the old SNMPv2 archives, you can see > > the debates about how to leverage IPSec to secure SNMP. This was > > definitely recognized as a potential approach to security. > > > > I will agree we didn't do a very good at providing a layered > > architecture so we could utilize lower layers for security > easily, but > > the use of external security definitely was considered. > Note that the > > SNMPv3 architecture reached standards track before most of the > > transport layer security protocols (and SecSH hasn't gotten there > > yet); it's hard to plan the architectural fit with external > protocols > > still in development. > > > > > > > > dbh also says > > > 'If the TMSM is going to pass transport information from the > > transport > > > mapping to the SM subsystem, either through a cache or an ASI > > > parameter, we need to standardize how this is done, how it affects > > > existing models and MIB modules, and how to document these changes > > > within the IETF.' > > > > > > Again, a matter of judgment, but I see this as close to > > > suggesting a small > > > change to the architecture as defined in RFC3411 caused by a > > > dependency on > > > external protocols. > > > > I don't see this as close to suggesting a small change in the > > architecture as defined in RFC3411; I see this as definitely > > suggesting a small change to the architecture as defined in RFC3411, > > but in a way that is consistent with the precedents of the > > architecture defined in RFC3411. > > > > This change is required because the RFC3411 ASIs were knowingly made > > inadequate to support transport security. There was a political > > battle in the SNMPv2/v3 WGs over whether SNMPv2/v3 should > support the > > use of source address as an authentication mechanism. Despite its > > popularity with operators, and the strong insistence of one of the > > "major players", given the ease of address spoofing, the WGs decided > > to not pass the transport info into the security subsystem, > and to not > > allow the transport mapping to provide authentication, to encourage > > operators to use the stronger authenticatino mechanisms supported by > > USM and other expected security models. This political decision has > > come back to haunt us. > > > > > > > > > > > Tom Petch > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 04 00:32:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0XPQ-00051c-IV; Thu, 04 Aug 2005 00:32:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0XPO-00051X-Id for isms@megatron.ietf.org; Thu, 04 Aug 2005 00:32:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07567 for ; Thu, 4 Aug 2005 00:32:39 -0400 (EDT) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0Xw8-0003Wh-AN for isms@ietf.org; Thu, 04 Aug 2005 01:06:37 -0400 Received: from admsrvnt02.enet.sharplabs.com (admsrvnt02.enet.sharplabs.com [172.29.225.253]) by sharplabs.com (8.13.1/8.13.1) with ESMTP id j744W5WE022425; Wed, 3 Aug 2005 21:32:05 -0700 (PDT) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Wed, 3 Aug 2005 21:33:32 -0700 Message-ID: From: "McDonald, Ira" To: "'ietfdbh@comcast.net'" , "McDonald, Ira" Subject: RE: [Isms] charter proposal Date: Wed, 3 Aug 2005 21:33:24 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="ISO-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I stand corrected. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Wednesday, August 03, 2005 2:09 PM > To: 'McDonald, Ira' > Cc: isms@ietf.org > Subject: RE: [Isms] charter proposal > > > Hi Ira, > > I totally disagree with your analysis. > > I think we have accomplished a lot. Not as much as I would have liked, > but a lot nonetheless. We have written multiple proposals, reviewed > those proposals, convened an official review team and published a > fairly detailed analysis of the proposals, discussed the ramifications > of the architectural differences of the proposals, eliminated some > proposals, chosen a general direction for focus (use of encapulating > protocols to carry SNMP messages), cleaned up the initial proposal, > identified and discussed many technical issues relative to the TMSM > approach, had a BEEP/TMSM proposal written and reviewed, and started > work on an SSH/TMSM proposal - and we have seven editors willing to > commit to working against a short deadline. I see lots of agreement on > direction, and even though some industry segments wish we had selected > different directions, rough consensus on the chosen direction. I wish > some of the other WGs I've been in had made this kind of progress. > > As far as this being comparable to SNMPv2 years, no way! During those > years we suffered through tremendous ego battles as responsibility for > designing solutions shifted from the "big four" players to the whole > SNMP community; abandoned a Proposed Standard when we realized the > design was completely non-viable for application vendors; we suffered > the segmentation of the community into two major "camps"; and we > suffered through an imposed shutdown of the WG and ALL network > management development work, not because the WG couldn't reach > consensus or finish documents but to avoid the constant acrimonious > flame wars between the camps. We are seeing none of the ego battles or > flame wars in this WG, and given the progress we have manifested, I > think it unlikely this WG will be shutdown soon. > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of McDonald, Ira > > Sent: Wednesday, August 03, 2005 12:04 PM > > To: 'Wijnen, Bert (Bert)'; Eliot Lear; j.schoenwaelder@iu-bremen.de > > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > > Subject: RE: [Isms] charter proposal > > > > Hi, > > > > With much respect to all people involved, I note that nearly > > a year has passed since this working group rushed into work. > > And the divisions and disagreements are, if anything, worse. > > > > If people with strongly held opinions on specific directions > > would sit down and write REALLY complete proposals, maybe this > > effort would progress. > > > > As a working group, it feels a lot like the many years SNMPv2 > > debacle. > > > > And of course, NOTHING was decided in Paris. This is a chartered > > IETF working group. Rough concensus on the mailing list is the > > ONLY place that decisions get made. > > > > Cheers, > > - Ira > > > > Ira McDonald (Musician / Software Architect) > > Blue Roof Music / High North Inc > > PO Box 221 Grand Marais, MI 49839 > > phone: +1-906-494-2434 > > email: imcdonald@sharplabs.com > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org]On > > > Behalf Of Wijnen, Bert (Bert) > > > Sent: Wednesday, August 03, 2005 10:26 AM > > > To: Eliot Lear; j.schoenwaelder@iu-bremen.de > > > Cc: Margaret Wasserman; Andy Bierman; Sam Hartman; isms@ietf.org > > > Subject: RE: [Isms] charter proposal > > > > > > > > > w.r.t. > > > > Also, all decisions at IETF are confirmed by the mailing > > list. I am > > > > saying that this is one we ought not confirm. Instead, we > should > > > > continue with draft development and compare approaches, > > > > particularly in > > > > light of the broader context, and then make a decision. > > > > > > > > The ADs have made it clear that they want us to finish, and have > > > > suggested that perhaps an interim meeting might help. > > > > > > First, in this case I am not an AD for the WG. I am SNMP > > (or OPS area) > > > advisor to the WG. So I do not play AD role here. > > > > > > Second, I did indeed make that suggestion, and stated that such > > > would be acceptable to me, but that I rather prefer a decision > now. > > > > > > I do not recall that Sam in fact agreed with the suggestion. > > > I'd expect > > > he wants to see more discussion on the list w.r.t. confirming the > > > decision that seemed obvious in the f2f WG session. Sam can > > > speak up if I am mis-representing him. > > > > > > Let me add (for repeated clarity): > > > The only reason I even though of this is because some were asking > > > for another delay to Vancouver (i.e extend yet one more IETF > meeting > > > as we have had so many before). An interim would give some extra > > > time (max september in my view) to better discuss the choice > between > > > the shortlist (ssh and beep). But it at the same time REQUIRES > > > commitement from all WG members to do a lot os serious work within > > > the next 5-7 weeks and to invest not only time but also travel > > > to an interim. In other words a lot of extra work in order to get > > > a little bit of extra time. > > > > > > Again, it was a suggestion that I can live with, but which is up > to > > > the AD (Sam) to approve. > > > > > > Bert > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 04 09:32:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fpN-0002ZS-9c; Thu, 04 Aug 2005 09:32:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0fpM-0002ZN-B9 for isms@megatron.ietf.org; Thu, 04 Aug 2005 09:32:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09816 for ; Thu, 4 Aug 2005 09:32:02 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0gMA-0002im-Hq for isms@ietf.org; Thu, 04 Aug 2005 10:06:04 -0400 Received: from open-25-41.ietf63.ietf.org (open-25-41.ietf63.ietf.org [86.255.25.41]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C5D8B1BAC4D for ; Thu, 4 Aug 2005 15:31:42 +0200 (CEST) Date: Thu, 04 Aug 2005 15:31:39 +0200 From: Juergen Quittek To: isms@ietf.org Subject: Re: [Isms] ISMS session summary and draft minutes Message-ID: In-Reply-To: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> References: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Juergen Schoenwaelder sent a lot of comments on the draft of the session minutes (Thanks a lot Juergen!). Please find an updated version at Please continue checking them and send your comments. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 8/3/2005 6:25 PM +0200 Juergen Quittek wrote: > Dear all, > > Below please find a summary of our session yesterday. > > Please find the detailed draft minutes at > . > Many thanks to Martin for taking the minutes! > > We had a long discussion and probably not every statement was captured > correctly in the minutes. Please check them. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > > =================================== > IETF-63 ISMS Session Summary > Tuesday August 2, 14:00 h - 16:00 h > =================================== > > In April the WG achieved (very rough) consensus on using an > encapsulated keying architecture (as used by the TLSM proposal). > At this meeting the WG progressed the decision on a transport > protocol to be used by ISMS. Candidate protocols were TLS+SASL, > SSH, DTLS, and BEEP. > > Among the proposals, DTLS is the only one based on UDP. Since > DTLS is not yet commonly deployed and not extensively tested, > it was eliminated from the discussion after the WG agreed that > UDP transport is not necessarily required for the ISMS solution. > For all of the remaining three protocols there was support in > the WG. Among them, SSH had clearly the strongest support, > mainly, because SSH is already widely deployed and used in network > management and thus could best achieve the goal of integrating the > ISMS solution into existing security infrastructures. Within the > session there was a consensus on choosing only one protocol as work > item and there was rough consensus that this protocol would be SSH. > The consensus still needs to be confirmed on the mailing list. > > Decisions made: > - ISMS will work on one transport protocol only > - Use SSH as transport protocol > > Action items: > - confirm WG consensus on decisions on the mailing list (August) > - draft new charter, discuss on mailing list (August) > - start work on SSH-based solution > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 04 14:19:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kJY-0000P1-05; Thu, 04 Aug 2005 14:19:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kJW-0000Ow-Gi for isms@megatron.ietf.org; Thu, 04 Aug 2005 14:19:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27871 for ; Thu, 4 Aug 2005 14:19:29 -0400 (EDT) Message-Id: <200508041819.OAA27871@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0kqS-0003GX-M5 for isms@ietf.org; Thu, 04 Aug 2005 14:53:32 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <2005080418192001200pjghte>; Thu, 4 Aug 2005 18:19:20 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] ISMS session summary and draft minutes Date: Thu, 4 Aug 2005 14:19:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWY+S9uvf2719OkRHaYC4EU94igOgAJ2ZTw In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, The work done by Juergen and I on the "TLSM" proposal really is about the architectural extension required to make a transport-mapping security model (TMSM) viable. To differentiate a TLS security model from a transport mapping approach, I prefer to have us all use the term TMSM rather than TLSM, so we can keep TLSM to refer to a TLS-specific security model. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Thursday, August 04, 2005 9:32 AM > To: isms@ietf.org > Subject: Re: [Isms] ISMS session summary and draft minutes > > Dear all, > > Juergen Schoenwaelder sent a lot of comments on the > draft of the session minutes (Thanks a lot Juergen!). > Please find an updated version at > > > Please continue checking them and send your comments. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > --On 8/3/2005 6:25 PM +0200 Juergen Quittek wrote: > > > Dear all, > > > > Below please find a summary of our session yesterday. > > > > Please find the detailed draft minutes at > > . > > Many thanks to Martin for taking the minutes! > > > > We had a long discussion and probably not every statement > was captured > > correctly in the minutes. Please check them. > > > > Thanks, > > > > Juergen > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > > > > =================================== > > IETF-63 ISMS Session Summary > > Tuesday August 2, 14:00 h - 16:00 h > > =================================== > > > > In April the WG achieved (very rough) consensus on using an > > encapsulated keying architecture (as used by the TLSM proposal). > > At this meeting the WG progressed the decision on a transport > > protocol to be used by ISMS. Candidate protocols were TLS+SASL, > > SSH, DTLS, and BEEP. > > > > Among the proposals, DTLS is the only one based on UDP. Since > > DTLS is not yet commonly deployed and not extensively tested, > > it was eliminated from the discussion after the WG agreed that > > UDP transport is not necessarily required for the ISMS solution. > > For all of the remaining three protocols there was support in > > the WG. Among them, SSH had clearly the strongest support, > > mainly, because SSH is already widely deployed and used in network > > management and thus could best achieve the goal of integrating the > > ISMS solution into existing security infrastructures. Within the > > session there was a consensus on choosing only one protocol as work > > item and there was rough consensus that this protocol would be SSH. > > The consensus still needs to be confirmed on the mailing list. > > > > Decisions made: > > - ISMS will work on one transport protocol only > > - Use SSH as transport protocol > > > > Action items: > > - confirm WG consensus on decisions on the mailing list (August) > > - draft new charter, discuss on mailing list (August) > > - start work on SSH-based solution > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 04 14:56:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0ksu-0007uk-5j; Thu, 04 Aug 2005 14:56:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0kst-0007uf-5Q for isms@megatron.ietf.org; Thu, 04 Aug 2005 14:56:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29407 for ; Thu, 4 Aug 2005 14:56:01 -0400 (EDT) Message-Id: <200508041856.OAA29407@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E0lPo-00045Q-42 for isms@ietf.org; Thu, 04 Aug 2005 15:30:05 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005080418555101400d64q2e>; Thu, 4 Aug 2005 18:55:51 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] ISMS session summary and draft minutes Date: Thu, 4 Aug 2005 14:55:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWY+S9uvf2719OkRHaYC4EU94igOgAKQRew In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I'll try to improve the [DH] ... Lines, but I see that most o fmy comments are not in the jabber log online. Don't know why. (DH) We need UDP for certain purposes, but non UDP for other purposes (DH) ... Should be (DH) We need UDP for certain purposes, but non UDP can be used for other purposes. We need UDP to troubleshoot broken networks, but TCP would be good for downloading large tables when the network is running fine. ---- (ER) SSH is back on the list (DH) ... (EL) If Dave's point is that we can use what we have, it is fine. I think this discussion has not been captured well, and it's hard to determine the context of my comments. I beleive this was probably a discussion about Netconf finding SSH limited for things like notiifcations, and my point would have been that the SNMPv3 architectuire provides for multiple co-existing security models, so notifications could always be sent using a different security model, such as USM, than the request-response traffic, so it wouldn't necessarily need to be in an SSH security model (although it would be desirable). [of course, since I was typing this into jabber in real-time, my comment would have been somewhat shorter... --- (DH) Pick a deadline! Should be [DH} let's get a proposal started. I'm willing to work on fleshing out the SSH portion of TMSM IFFFF somebody with knowledge of SSH helps craft the text. Who is willing to be the security-side co-editor for an SSH document? [DH] Add one item to the charter: do an SSH proposal and pick a deadline. [DH] I am willing to try to get a draft written by the end of August if co-editors are available. --- Because jabber comments were not being relayed to the meeting, the meeting never heard comments from the group of people who volunteered to edit the SSH draft, including the comments that an interim was a no-go for most of the volunteer editors. --- Many of the jabber comments never got relayed, and when they did they were often not not very accuratekly relayed, and, since the note-taker had to relay them, they were not included in the meeting notes. That the jabber scribe was the same as the note-taker, and the same as the relayer made this largely impossib;e. The isms jabber log at ietf.xmpp.org contains more details on what was being discussed over jabber. The notes should probably reflect some of those comments. I didn't bother making more comments because I knew they wouldn't get relayed. The log looks to be missing the first half hour or so of the meeting. I logged in for the complete meeting, but the log is missing most of the early part of the meeting. Support for jabber participants really should be improved in the future for ISMS; the chairs really need to be more mindful of this, as Sam pointed out on a number of occasions. The problems were similar last time in ISMS. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Thursday, August 04, 2005 9:32 AM > To: isms@ietf.org > Subject: Re: [Isms] ISMS session summary and draft minutes > > Dear all, > > Juergen Schoenwaelder sent a lot of comments on the > draft of the session minutes (Thanks a lot Juergen!). > Please find an updated version at > > > Please continue checking them and send your comments. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > --On 8/3/2005 6:25 PM +0200 Juergen Quittek wrote: > > > Dear all, > > > > Below please find a summary of our session yesterday. > > > > Please find the detailed draft minutes at > > . > > Many thanks to Martin for taking the minutes! > > > > We had a long discussion and probably not every statement > was captured > > correctly in the minutes. Please check them. > > > > Thanks, > > > > Juergen > > -- > > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > > > > > =================================== > > IETF-63 ISMS Session Summary > > Tuesday August 2, 14:00 h - 16:00 h > > =================================== > > > > In April the WG achieved (very rough) consensus on using an > > encapsulated keying architecture (as used by the TLSM proposal). > > At this meeting the WG progressed the decision on a transport > > protocol to be used by ISMS. Candidate protocols were TLS+SASL, > > SSH, DTLS, and BEEP. > > > > Among the proposals, DTLS is the only one based on UDP. Since > > DTLS is not yet commonly deployed and not extensively tested, > > it was eliminated from the discussion after the WG agreed that > > UDP transport is not necessarily required for the ISMS solution. > > For all of the remaining three protocols there was support in > > the WG. Among them, SSH had clearly the strongest support, > > mainly, because SSH is already widely deployed and used in network > > management and thus could best achieve the goal of integrating the > > ISMS solution into existing security infrastructures. Within the > > session there was a consensus on choosing only one protocol as work > > item and there was rough consensus that this protocol would be SSH. > > The consensus still needs to be confirmed on the mailing list. > > > > Decisions made: > > - ISMS will work on one transport protocol only > > - Use SSH as transport protocol > > > > Action items: > > - confirm WG consensus on decisions on the mailing list (August) > > - draft new charter, discuss on mailing list (August) > > - start work on SSH-based solution > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 08:01:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26Jb-0006DM-QJ; Mon, 08 Aug 2005 08:01:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26Ja-0006CX-9N for isms@megatron.ietf.org; Mon, 08 Aug 2005 08:01:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15825 for ; Mon, 8 Aug 2005 08:01:08 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E26rE-0005am-4u for isms@ietf.org; Mon, 08 Aug 2005 08:35:59 -0400 Received: from pc6 (1Cust18.tnt6.lnd4.gbr.da.uu.net [62.188.135.18]) by ranger.systems.pipex.net (Postfix) with SMTP id 9E4E6E0001C6; Mon, 8 Aug 2005 13:00:48 +0100 (BST) Message-ID: <01ba01c59c08$42dedb60$0601a8c0@pc6> From: "Tom Petch" To: References: <200508021654.MAA04893@ietf.org> Subject: Re: [Isms] charter proposal Date: Mon, 8 Aug 2005 12:58:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "David B Harrington" To: Cc: Sent: Tuesday, August 02, 2005 6:54 PM Subject: RE: [Isms] charter proposal > Hi, > > Hmmmm. I am of the impression that, as a source for authentication, > the use of AAA is an implementation-dependent detail of the SSH > authentication; whether SSH authentication relies on RADIUS or AAA or > local users to authenticate the transport connection and the user > should be transparent to the SNMP engine, shouldn't it? If so, then it > doesn't belong in the charter at all. > I agree; we should specify the SSH options that are appropriate but no more than that. Thus the authentication of the Command Generator will (most likely) be done by ssh-userauth, which REQUIREs user (identified by UTF8 string) public key, and allows user password (with transport level encryption) and host (dns name, IPaddress) public key. No mention of any AAA infrastrucutre there nor should there be. We might want to comment on the use of host authentication versus user authentication and its interaction with the concept of SNMP principal but I would not want to see any more than that. > Where we run into the problem is if a TMSM also needs to somehow > capture the authorization information returned by AAA so the AC > subsystem can use it later. If we want that feature, and we seem to > have a lot of people suggesting it is an important feature to support, > then we need to address how to standardize that feature so future TMSM > security models handle it in a compatible way. > We could require any transport security model to pass than information securely in the initial exchange, which I believe ssh can do. > Are my assumptions incorrect? > > David Harrington > dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 09:14:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27So-00085n-Kw; Mon, 08 Aug 2005 09:14:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27Sn-000838-6p for isms@megatron.ietf.org; Mon, 08 Aug 2005 09:14:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19670 for ; Mon, 8 Aug 2005 09:14:43 -0400 (EDT) Message-Id: <200508081314.JAA19670@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E280S-0007cf-Bf for isms@ietf.org; Mon, 08 Aug 2005 09:49:35 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050808131432011001deu7e>; Mon, 8 Aug 2005 13:14:32 +0000 From: "David B Harrington" To: "'Tom Petch'" Subject: RE: [Isms] charter proposal Date: Mon, 8 Aug 2005 09:14:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWcENGcVu5e4hWzTM2/BFiMz9z1bQACWDaw In-Reply-To: <01ba01c59c08$42dedb60$0601a8c0@pc6> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, > I agree; we should specify the SSH options that are > appropriate but no more than > that. Thus the authentication of the Command Generator will In writing an SSH proposal, it is my intention to authenticate the user, not the Command Generator. Authenticating only the command generator entails a tremendous loss of granularity in identifying the princiapl, and I do not consider that change of granularity to be in high demand by the SNMP community, nor do I think there is consensus of this WG that such a change should be made. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 09:25:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27dT-00036l-Ti; Mon, 08 Aug 2005 09:25:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E27dS-00036d-BY for isms@megatron.ietf.org; Mon, 08 Aug 2005 09:25:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20203 for ; Mon, 8 Aug 2005 09:25:44 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E28B2-0007vX-5E for isms@ietf.org; Mon, 08 Aug 2005 10:00:36 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j78DPWZC020144 for ; Mon, 8 Aug 2005 09:25:32 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 08 Aug 2005 09:25:32 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 08 Aug 2005 09:25:32 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 09:25:31 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Mon, 8 Aug 2005 09:25:30 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324AC@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWcEW8cAduJx0jERGmhG55EiF3uuAACuRkg From: "Nelson, David" To: "Tom Petch" , X-OriginalArrivalTime: 08 Aug 2005 13:25:31.0898 (UTC) FILETIME=[A6A81DA0:01C59C1C] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:71.2071 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tpm Petch writes... > No mention of any AAA infrastrucutre there nor should there be. But isn't re-use of existing AAA infrastructure (be it local, host-based or remote, server-based) a basic requirement of ISMS? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 12:26:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ASh-00060j-0T; Mon, 08 Aug 2005 12:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ASe-00060U-Gw for isms@megatron.ietf.org; Mon, 08 Aug 2005 12:26:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00974 for ; Mon, 8 Aug 2005 12:26:45 -0400 (EDT) Message-Id: <200508081626.MAA00974@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2B0N-0004cG-4Z for isms@ietf.org; Mon, 08 Aug 2005 13:01:40 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050808162636011001d2qie>; Mon, 8 Aug 2005 16:26:36 +0000 From: "David B Harrington" To: "'Nelson, David'" , "'Tom Petch'" Subject: RE: [Isms] charter proposal Date: Mon, 8 Aug 2005 12:26:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWcEW8cAduJx0jERGmhG55EiF3uuAACuRkgAAZVcdA= In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324AC@MAANDMBX2.ets.enterasys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, SSH provides an authentication of the user via some sort of authetication mechanism. SNMP does not care what the underlying mechanism is that SSH uses, only that it trusts SSH to do the job effectively. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Monday, August 08, 2005 9:26 AM > To: Tom Petch; ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: RE: [Isms] charter proposal > > Tpm Petch writes... > > > No mention of any AAA infrastrucutre there nor should there be. > > But isn't re-use of existing AAA infrastructure (be it local, > host-based > or remote, server-based) a basic requirement of ISMS? > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 12:59:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ayl-0008Ha-0o; Mon, 08 Aug 2005 12:59:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Ayi-0008Gv-Rf for isms@megatron.ietf.org; Mon, 08 Aug 2005 12:59:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02727 for ; Mon, 8 Aug 2005 12:59:53 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2BWR-0005ZI-Qm for isms@ietf.org; Mon, 08 Aug 2005 13:34:49 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA23366 for ; Mon, 8 Aug 2005 13:02:24 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma023345; Mon, 8 Aug 05 13:02:02 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 08 Aug 2005 12:59:30 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 08 Aug 2005 12:59:30 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 8 Aug 2005 12:59:30 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Mon, 8 Aug 2005 12:59:29 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324B1@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWcEW8cAduJx0jERGmhG55EiF3uuAACuRkgAAZVcdAAAPtVAA== From: "Nelson, David" To: , "Tom Petch" X-OriginalArrivalTime: 08 Aug 2005 16:59:30.0554 (UTC) FILETIME=[8B178DA0:01C59C3A] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > SSH provides an authentication of the user via some sort of > authetication mechanism. > SNMP does not care what the underlying mechanism is that SSH uses, > only that it trusts SSH to do the job effectively. That sounds like a protocol design discussion. I thought we were having WG charter discussion. If SSH already provides authentication that meets the *current* charter requirements, i.e. authentication that leverages both local and remote AAA of the sorts that operators have deployed, then it is probably sufficient to worry about designing an interface between SNMP and SSH. My comment is intended to signify that the "if" at the beginning of the previous sentence represents a mandatory pre-requisite. Phrasing this differently, SNMP may not care what the underlying mechanism is, but the operators using SNMP are very likely to care.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 15:38:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DS0-00009I-J1; Mon, 08 Aug 2005 15:38:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2DRz-00009D-KF for isms@megatron.ietf.org; Mon, 08 Aug 2005 15:38:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13048 for ; Mon, 8 Aug 2005 15:38:17 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2Dzj-0001o3-OG for isms@ietf.org; Mon, 08 Aug 2005 16:13:13 -0400 Received: from pc6 (1Cust125.tnt13.lnd4.gbr.da.uu.net [62.188.142.125]) by ranger.systems.pipex.net (Postfix) with SMTP id 8B9C0E00022B; Mon, 8 Aug 2005 20:38:06 +0100 (BST) Message-ID: <018301c59c48$261f6fe0$0601a8c0@pc6> From: "Tom Petch" To: References: <20050808131434.82971E000087@robin.systems.pipex.net> Subject: Re: [Isms] charter proposal Date: Mon, 8 Aug 2005 20:36:15 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Apologies for the sloppiness of my wording; what I was trying to convey was more like Thus the authentication of the principal which invokes the Command Generator in an SNMPv3 engine which is using SSH as a secure transport will (most likely) be done by secsh-userauth, for which user (identified by UTF8 string) authentication by public key is REQUIRED and authentication by user password (with transport level encryption) and or by host (dns name, IPaddress) public key is OPTIONAL. but I expect I have not covered all the bases:-) Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'Tom Petch'" Cc: Sent: Monday, August 08, 2005 3:14 PM Subject: RE: [Isms] charter proposal > > > I agree; we should specify the SSH options that are > > appropriate but no more than > > that. Thus the authentication of the Command Generator will > > In writing an SSH proposal, it is my intention to authenticate the > user, not the Command Generator. Authenticating only the command > generator entails a tremendous loss of granularity in identifying the > princiapl, and I do not consider that change of granularity to be in > high demand by the SNMP community, nor do I think there is consensus > of this WG that such a change should be made. > > David Harrington > dbharrington@comcast.net > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 08 16:43:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ETX-0000WG-HF; Mon, 08 Aug 2005 16:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ETW-0000W8-2U for isms@megatron.ietf.org; Mon, 08 Aug 2005 16:43:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23724 for ; Mon, 8 Aug 2005 16:43:55 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E2F1G-0006FD-Nh for isms@ietf.org; Mon, 08 Aug 2005 17:18:52 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j78KhlsN016366 for ; Mon, 8 Aug 2005 20:43:47 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j78KhlsS013645 for ; Mon, 8 Aug 2005 20:43:47 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005080813434720899 for ; Mon, 08 Aug 2005 13:43:47 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 13:43:47 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 13:43:46 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 16:43:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Mon, 8 Aug 2005 16:39:36 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C5929019F3E1B@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWcEW8cAduJx0jERGmhG55EiF3uuAACuRkgAAZVcdAAAPtVAAAGoh9g From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 08 Aug 2005 20:43:45.0888 (UTC) FILETIME=[DF189600:01C59C59] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org [free translation] - Why are you looking at the ground under this street-lamp? - Searching for my wallet. - Did you lose it here? - No, over there in the darkness. - Then why are you looking for it here? - Because here is light. The purpose of this WG was to address SNMPv3 deployability (or lack of) by providing an easy way to integrate it with an existing security infrastructure. What must be addressed (in the descending order of priority): 1. What existing infrastructure(s) to integrate SNMP with/into.=20 2. What credentials that already-deployed infrastructure uses, how it names principals and how it authenticates them. 2a. What authentication should the new security model use (may or may not be the same as in 2)? 3. How to map principals between the new security model, the interfaced-infrastructure, and the rest of SNMPv3. 4. What security mechanisms to use for SNMP traffic protection (and whether to re-use USM for that). 4a. Required capabilities of those mechanisms, such as taking/providing to SNMP identity of the principal and traffic protection parameters. I personally find the decision to use SSH rather irrelevant. The WG must find satisfactory answers to the first three questions first. E.g. somebody wants to integrate with Kerberos. How will SSH help him? Somebody else needs RADIUS. How are his problems (configuring user database, supplying credentials, etc) solved with SSH? Yet another person wants PKI...=20 So don't tell me what protocol you'll be using - tell me how you'll provision (and maintain the database of) identities and credentials. And tell me how you'll map those identities onto something usable in Access Control. That's all that matters, the rest is mostly BS (and you probably know it). P.S. Any combination of mechanisms/infrastructures can work - the only difference is how expensive it will be to implement/deploy/operate. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 10 21:05:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E31Vc-0007sG-AZ; Wed, 10 Aug 2005 21:05:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E31VZ-0007ro-Vi for isms@megatron.ietf.org; Wed, 10 Aug 2005 21:05:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15411 for ; Wed, 10 Aug 2005 21:05:19 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E323n-0003Af-1u for isms@ietf.org; Wed, 10 Aug 2005 21:40:43 -0400 Received: from h-64-105-136-21.snvacaid.dynamic.covad.net ([64.105.136.21] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E31VU-0004T3-00 for isms@ietf.org; Wed, 10 Aug 2005 21:05:16 -0400 Message-ID: <002c01c59e10$e8c33620$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3DEC199BD7489643817ECA151F7C5929019F3E1B@pysmsx401.amr.corp.intel.com> Subject: Re: [Isms] charter proposal Date: Wed, 10 Aug 2005 18:06:30 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - I whole-heartedly concur with Uri's comment. Randy ----- Original Message ----- From: "Blumenthal, Uri" To: Sent: Monday, August 08, 2005 1:39 PM Subject: RE: [Isms] charter proposal [free translation] - Why are you looking at the ground under this street-lamp? - Searching for my wallet. - Did you lose it here? - No, over there in the darkness. - Then why are you looking for it here? - Because here is light. The purpose of this WG was to address SNMPv3 deployability (or lack of) by providing an easy way to integrate it with an existing security infrastructure. What must be addressed (in the descending order of priority): 1. What existing infrastructure(s) to integrate SNMP with/into. 2. What credentials that already-deployed infrastructure uses, how it names principals and how it authenticates them. 2a. What authentication should the new security model use (may or may not be the same as in 2)? 3. How to map principals between the new security model, the interfaced-infrastructure, and the rest of SNMPv3. 4. What security mechanisms to use for SNMP traffic protection (and whether to re-use USM for that). 4a. Required capabilities of those mechanisms, such as taking/providing to SNMP identity of the principal and traffic protection parameters. I personally find the decision to use SSH rather irrelevant. The WG must find satisfactory answers to the first three questions first. E.g. somebody wants to integrate with Kerberos. How will SSH help him? Somebody else needs RADIUS. How are his problems (configuring user database, supplying credentials, etc) solved with SSH? Yet another person wants PKI... So don't tell me what protocol you'll be using - tell me how you'll provision (and maintain the database of) identities and credentials. And tell me how you'll map those identities onto something usable in Access Control. That's all that matters, the rest is mostly BS (and you probably know it). P.S. Any combination of mechanisms/infrastructures can work - the only difference is how expensive it will be to implement/deploy/operate. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 06:35:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AOr-0004Ro-8I; Thu, 11 Aug 2005 06:35:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AOq-0004Oc-19 for isms@megatron.ietf.org; Thu, 11 Aug 2005 06:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22209 for ; Thu, 11 Aug 2005 06:34:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Ax6-0000LF-Hp for isms@ietf.org; Thu, 11 Aug 2005 07:10:26 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2005 03:34:49 -0700 X-IronPort-AV: i="3.96,99,1122879600"; d="scan'208"; a="654204221:sNHT28972908" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7BAYkoo004485; Thu, 11 Aug 2005 03:34:46 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4475.cisco.com [10.61.81.122]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7BAVcQK007951; Thu, 11 Aug 2005 03:31:39 -0700 Message-ID: <42FB29C4.8070007@cisco.com> Date: Thu, 11 Aug 2005 12:34:44 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Presuhn Subject: Re: [Isms] charter proposal References: <3DEC199BD7489643817ECA151F7C5929019F3E1B@pysmsx401.amr.corp.intel.com> <002c01c59e10$e8c33620$7f1afea9@oemcomputer> In-Reply-To: <002c01c59e10$e8c33620$7f1afea9@oemcomputer> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=126; t=1123756299; x=1124188499; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20charter=20proposal| From:Eliot=20Lear=20| Date:Thu,=2011=20Aug=202005=2012=3A34=3A44=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=EQhkI1cCA6+KWsaA9a1sk2J+LUfT/toRaZKUOKepV+JZj6PEslFH9S9gIpOjd3JwHt/Se8IF FMwSNN58uJ40PYtcPOSCSFN4fNjbxOP2ad5e7Y7VlbnoaS2TJw8zI0UtZbTju3M8PLbKnn0TNoA zw9bRfL25xSpZJnflUiWlzSk= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Randy, Could you and Uri please comment on what is necessary to improve Juergen's doc, which seems to me to cover a lot of ground that URI refers to? Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 08:37:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CJD-0006cx-Nu; Thu, 11 Aug 2005 08:37:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3CJC-0006cq-6v for isms@megatron.ietf.org; Thu, 11 Aug 2005 08:37:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27650 for ; Thu, 11 Aug 2005 08:37:16 -0400 (EDT) Received: from sky.bmc.com ([198.207.223.240] helo=babbler.bmc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3CrS-0003Qh-6p for isms@ietf.org; Thu, 11 Aug 2005 09:12:45 -0400 Received: from hou-ec-02.adprod.bmc.com (hou-ec-02.adprod.bmc.com [172.17.1.111]) by babbler.bmc.com (Postfix) with ESMTP id 953F71303C6; Thu, 11 Aug 2005 07:36:55 -0500 (CDT) Received: from hou-ex-02.adprod.bmc.com ([172.17.1.224]) by hou-ec-02.adprod.bmc.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 07:36:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 07:36:55 -0500 Message-ID: Thread-Topic: [Isms] charter proposal Thread-Index: AcWeEQiP48xL7zdoQrijy8pq5mHVGwAXxBfw From: "Golovinsky, Eugene" To: "Randy Presuhn" , X-OriginalArrivalTime: 11 Aug 2005 12:36:55.0593 (UTC) FILETIME=[5BA48990:01C59E71] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org My 2 cents of support to that notion. The fundamental problem with SNMPv3 is not security, but "deployability" and usability. Very few people in reality are using v3, although a lot of devices provide support for it. There is no really turn key operation and IT departments can not afford anymore army of admin staff doing manual configuration labor. SSH is hardly a solution to this issue. As long as we do not provide meaningful integration with already deployed infrastructure and easy initial deployment/configuration SNMPv3 will remain extremely secure :-), simply because nothing is going to be exposed through it :-) Over last 4 years I've been watching our customers becoming less and less curious about SNMPv3, to the point that almost nobody is asking about it anymore. What does it tell you? Is security really an issue?=20 --Gene =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, August 10, 2005 8:07 PM To: isms@ietf.org Subject: Re: [Isms] charter proposal Hi - I whole-heartedly concur with Uri's comment. Randy ----- Original Message -----=20 From: "Blumenthal, Uri" To: Sent: Monday, August 08, 2005 1:39 PM Subject: RE: [Isms] charter proposal [free translation] - Why are you looking at the ground under this street-lamp? - Searching for my wallet. - Did you lose it here? - No, over there in the darkness. - Then why are you looking for it here? - Because here is light. The purpose of this WG was to address SNMPv3 deployability (or lack of) by providing an easy way to integrate it with an existing security infrastructure. What must be addressed (in the descending order of priority): 1. What existing infrastructure(s) to integrate SNMP with/into. 2. What credentials that already-deployed infrastructure uses, how it names principals and how it authenticates them. 2a. What authentication should the new security model use (may or may not be the same as in 2)? 3. How to map principals between the new security model, the interfaced-infrastructure, and the rest of SNMPv3. 4. What security mechanisms to use for SNMP traffic protection (and whether to re-use USM for that). 4a. Required capabilities of those mechanisms, such as taking/providing to SNMP identity of the principal and traffic protection parameters. I personally find the decision to use SSH rather irrelevant. The WG must find satisfactory answers to the first three questions first. E.g. somebody wants to integrate with Kerberos. How will SSH help him? Somebody else needs RADIUS. How are his problems (configuring user database, supplying credentials, etc) solved with SSH? Yet another person wants PKI... So don't tell me what protocol you'll be using - tell me how you'll provision (and maintain the database of) identities and credentials. And tell me how you'll map those identities onto something usable in Access Control. That's all that matters, the rest is mostly BS (and you probably know it). P.S. Any combination of mechanisms/infrastructures can work - the only difference is how expensive it will be to implement/deploy/operate. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 11:49:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3FJZ-00014F-Aw; Thu, 11 Aug 2005 11:49:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3FJY-000149-1Y for isms@megatron.ietf.org; Thu, 11 Aug 2005 11:49:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10478 for ; Thu, 11 Aug 2005 11:49:49 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Frr-0000Ge-QM for isms@ietf.org; Thu, 11 Aug 2005 12:25:21 -0400 Received: from h-68-165-6-176.snvacaid.dynamic.covad.net ([68.165.6.176] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3FJK-0000nI-00 for isms@ietf.org; Thu, 11 Aug 2005 11:49:38 -0400 Message-ID: <003001c59e8c$72cbdc20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <3DEC199BD7489643817ECA151F7C5929019F3E1B@pysmsx401.amr.corp.intel.com> <002c01c59e10$e8c33620$7f1afea9@oemcomputer> <42FB29C4.8070007@cisco.com> Subject: Re: [Isms] charter proposal Date: Thu, 11 Aug 2005 08:50:12 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Eliot Lear" > To: "Randy Presuhn" > Cc: > Sent: Thursday, August 11, 2005 3:34 AM > Subject: Re: [Isms] charter proposal > > Randy, > > Could you and Uri please comment on what is necessary to improve > Juergen's doc, which seems to me to cover a lot of ground that URI > refers to? > > Eliot I can't speak for Uri, but I think the heart of the matter is that there doesn't seem to be a "mandatory to implement" integration with any of the other infrastructures mentioned in the draft (e.g., Kerberos or Radius), or the WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). The references to any sort of AAA are very generic, (probably by design, knowing the authors) but we need to nail down just what this stuff talks to in order to know how to answer the fundamental question: Does this proposal provide sufficient integration with existing infrastuctures to satisfy the operational needs that triggered formation of this WG? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 15:59:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JCj-0006sV-O4; Thu, 11 Aug 2005 15:59:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JCi-0006sQ-F3 for isms@megatron.ietf.org; Thu, 11 Aug 2005 15:59:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24497 for ; Thu, 11 Aug 2005 15:59:02 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Jl5-0007I1-0u for isms@ietf.org; Thu, 11 Aug 2005 16:34:36 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 680C2E0049; Thu, 11 Aug 2005 15:58:57 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Thu, 11 Aug 2005 15:58:57 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Limited@ietf.org, time@mit.edu, to@mit.edu, charter@mit.edu Subject: [Isms] Limited time to charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, folks. I'd like to draw your attention to our remaining milestone: Aug 05 Working group will recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time August is fast passing us by and we don't have much time. I'd like to recommend to the chairs that they consider tools available for increasing the speed of our discussion. In particular it may be appropriate to set up conference calls, IM sessions or other more realtime communications channels to work through issues. I know there had been some discussion of an interim meeting. So far, I don't see that an interim meeting is all that likely to resolve the types of concerns currently being discussed and so I am reluctant to approve such a meeting. I will however consider proposals for such a meeting particularly if people can explain what we could accomplish with an interim that we are not accomplishing on the list. I will probably not be able to attend the meeting myself because of limited travel funding but could participate by phone. Keep in mind that interim meetings must be approved 30 days in advance and that both Bert and I believe dragging things out past September is unacceptable. While I remain optimistic that we can come to consensus, I must now entertain the very real possibility that we will fail to come to consensus. Please consider this message the formal consultation required prior to termination of a working group under section 4 of RFC 2418. At this time it is my opinion that absent an interim meeting we must choose a technical direction by the close of August. If that does not happen this working group will close. I will consider changes in this time table but currently do not see circumstances under which I'm likely to agree to such a change. Sam Hartman IETF Security Area Director _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 16:00:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JEC-0007YK-IO; Thu, 11 Aug 2005 16:00:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JEA-0007YF-S9 for isms@megatron.ietf.org; Thu, 11 Aug 2005 16:00:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24577 for ; Thu, 11 Aug 2005 16:00:33 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3JmY-0007KU-EW for isms@ietf.org; Thu, 11 Aug 2005 16:36:06 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BD348E0049; Thu, 11 Aug 2005 16:00:28 -0400 (EDT) To: isms@ietf.org From: Sam Hartman Date: Thu, 11 Aug 2005 15:58:57 -0400 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) Content-Type: text/plain; charset=us-ascii MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: charter@mit.edu Subject: [Isms] Limited time to charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, folks. I'd like to draw your attention to our remaining milestone: Aug 05 Working group will recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time August is fast passing us by and we don't have much time. I'd like to recommend to the chairs that they consider tools available for increasing the speed of our discussion. In particular it may be appropriate to set up conference calls, IM sessions or other more realtime communications channels to work through issues. I know there had been some discussion of an interim meeting. So far, I don't see that an interim meeting is all that likely to resolve the types of concerns currently being discussed and so I am reluctant to approve such a meeting. I will however consider proposals for such a meeting particularly if people can explain what we could accomplish with an interim that we are not accomplishing on the list. I will probably not be able to attend the meeting myself because of limited travel funding but could participate by phone. Keep in mind that interim meetings must be approved 30 days in advance and that both Bert and I believe dragging things out past September is unacceptable. While I remain optimistic that we can come to consensus, I must now entertain the very real possibility that we will fail to come to consensus. Please consider this message the formal consultation required prior to termination of a working group under section 4 of RFC 2418. At this time it is my opinion that absent an interim meeting we must choose a technical direction by the close of August. If that does not happen this working group will close. I will consider changes in this time table but currently do not see circumstances under which I'm likely to agree to such a change. Sam Hartman IETF Security Area Director _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 16:14:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JQ7-0002A5-CS; Thu, 11 Aug 2005 16:12:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3JQ5-00029z-KU for isms@megatron.ietf.org; Thu, 11 Aug 2005 16:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25071 for ; Thu, 11 Aug 2005 16:12:51 -0400 (EDT) Message-Id: <200508112012.QAA25071@ietf.org> Received: from rwcrmhc11.comcast.net ([216.148.227.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3JyR-0007bs-KS for isms@ietf.org; Thu, 11 Aug 2005 16:48:25 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005081120123301300ofpu2e>; Thu, 11 Aug 2005 20:12:34 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 16:12:27 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <003001c59e8c$72cbdc20$7f1afea9@oemcomputer> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWejKMqvhM6aGzoQi2nv+/NvJDAHwAHZ5vA X-Spam-Score: 0.1 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I think the issues under discussion may actually be missing the point somewhat, or hitting the nail on the head, depending on how you look at it. Having worked for Enterasys first in the management application side, and then in the equipment side, I see a fundamental problem. Gene mentioned that SNMPv3 is supported in a bunch of devices, and I agree with that. While equipment vendors have provided varying degrees of support, most of the major equipment vendors do support SNMPv3 messaging and the MIB modules to support SNMPv3. The place where SNMPv3 really isn't supported is in the management applications. I believe this is the result of two major impacts of SNMPv3 on management applications. First, while networking equipment has long supported remote monitoring and some configuration via SNMP, management applications have **never** allowed remote monitoring and configuration via SNMP. SNMPv3 added a MIB to management applications; in SNMPv1, the MIB only existed in the managed equipment. It is a very foreign concept to allow some other entity to modify the operating environment, especially the security parameters, of the application from the network side of things. And I don't see applications vendors jumping up and saying, "oh, please let me open that can of worms for my programs!" Second, SNMP defines a user-interface via MIB modules for equipment, but the user-interface for management applications is very different. To add real support for the concepts of SNMPv3 could require lots of changes to code and internal APIs to pass the necessary parameters from the user interfaces for client implementations, to access the server functionality, through the program logic, and into the database interface to remote management protocols and, ultimately, the SNMP stack. In addition, if access control is applied at the managed device, then the applications should also honor the access controls, so a MIB module accessible to "lear" but not "dbh" on a remote device isn't exposed to "dbh" through the management application's database. Adding support for SNMPv3 concepts and applying SNMPv3 access control is a huge cost for application vendors. So the problem isn't just about leveraging the AAA support already supported in the equipment; it's about providing an authentication and authorization solution that will be utilized by application vendors, reflected in application user interfaces, and applied to user views into application databases (as mirrors of the managed equipment databases). So maybe we should be having serious discussions about application frameworks like .NET and J2EE, and their security infrastructures, and how we can leverage their security infrastructures for securing both the client applications and the n-tier server functionality of network management. By n-tier functinoality, I am thinking of application databases, the proxy layer that converts from business logic requests to SMI varbinds, the communication layer between the srver and the remote SNMP engine, and the associated remote MIBs that connect from the SNMP protocol to the underlying instrumentation. Web services has already been dealing with this type of archoitectural breakdown. I'm not suggesting using http and web services, but leveraging the security infrastructure that correlates user authentication at the client application to the database access routines, and to remote procedure calls into remote databases. I think that discussing SSH vs RADIUS vs PKI vs local accounts is thinking too much about the protocols, and not enough about the high-level problem of leveraging security infrastructure in complete network management **systems**. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, August 11, 2005 11:50 AM > To: isms@ietf.org > Subject: Re: [Isms] charter proposal > > Hi - > > > From: "Eliot Lear" > > To: "Randy Presuhn" > > Cc: > > Sent: Thursday, August 11, 2005 3:34 AM > > Subject: Re: [Isms] charter proposal > > > > Randy, > > > > Could you and Uri please comment on what is necessary to improve > > Juergen's doc, which seems to me to cover a lot of ground that URI > > refers to? > > > > Eliot > > I can't speak for Uri, but I think the heart of the matter is > that there doesn't > seem to be a "mandatory to implement" integration with any of > the other > infrastructures mentioned in the draft (e.g., Kerberos or > Radius), or the > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > The references to any sort of AAA are very generic, (probably > by design, > knowing the authors) but we need to nail down just what this stuff > talks to in order to know how to answer the fundamental question: > Does this proposal provide sufficient integration with > existing infrastuctures > to satisfy the operational needs that triggered formation of this WG? > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 16:39:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Jq7-0007C9-La; Thu, 11 Aug 2005 16:39:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Jq4-0007C4-6B for isms@megatron.ietf.org; Thu, 11 Aug 2005 16:39:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26491 for ; Thu, 11 Aug 2005 16:39:42 -0400 (EDT) Received: from sky.bmc.com ([198.207.223.240] helo=babbler.bmc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3KOQ-0008Dd-Os for isms@ietf.org; Thu, 11 Aug 2005 17:15:16 -0400 Received: from svl-ec-01.adprod.bmc.com (svl-ec-01.adprod.bmc.com [172.20.5.28]) by babbler.bmc.com (Postfix) with ESMTP id 6DF8F130367; Thu, 11 Aug 2005 15:39:31 -0500 (CDT) Received: from hou-ex-02.adprod.bmc.com ([172.17.1.224]) by svl-ec-01.adprod.bmc.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 11 Aug 2005 13:39:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 15:39:26 -0500 Message-ID: Thread-Topic: [Isms] charter proposal Thread-Index: AcWejKMqvhM6aGzoQi2nv+/NvJDAHwAHZ5vAAAKL53A= From: "Golovinsky, Eugene" To: , "Randy Presuhn" , X-OriginalArrivalTime: 11 Aug 2005 20:39:28.0632 (UTC) FILETIME=[C4FFAF80:01C59EB4] X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org YES!!!!!!! Sorry, I could not contain myself:-) I absolutely agree with this clarification. Discussion about transports are not solving the real problem, but rather trying to address symptoms. Thanks, David! --Gene =20 =20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, August 11, 2005 3:12 PM To: 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] charter proposal Hi, I think the issues under discussion may actually be missing the point somewhat, or hitting the nail on the head, depending on how you look at it.=20 Having worked for Enterasys first in the management application side, and then in the equipment side, I see a fundamental problem.=20 Gene mentioned that SNMPv3 is supported in a bunch of devices, and I agree with that. While equipment vendors have provided varying degrees of support, most of the major equipment vendors do support SNMPv3 messaging and the MIB modules to support SNMPv3. The place where SNMPv3 really isn't supported is in the management applications. I believe this is the result of two major impacts of SNMPv3 on management applications.=20 First, while networking equipment has long supported remote monitoring and some configuration via SNMP, management applications have **never** allowed remote monitoring and configuration via SNMP. SNMPv3 added a MIB to management applications; in SNMPv1, the MIB only existed in the managed equipment. It is a very foreign concept to allow some other entity to modify the operating environment, especially the security parameters, of the application from the network side of things. And I don't see applications vendors jumping up and saying, "oh, please let me open that can of worms for my programs!" Second, SNMP defines a user-interface via MIB modules for equipment, but the user-interface for management applications is very different. To add real support for the concepts of SNMPv3 could require lots of changes to code and internal APIs to pass the necessary parameters from the user interfaces for client implementations, to access the server functionality, through the program logic, and into the database interface to remote management protocols and, ultimately, the SNMP stack. In addition, if access control is applied at the managed device, then the applications should also honor the access controls, so a MIB module accessible to "lear" but not "dbh" on a remote device isn't exposed to "dbh" through the management application's database. Adding support for SNMPv3 concepts and applying SNMPv3 access control is a huge cost for application vendors. So the problem isn't just about leveraging the AAA support already supported in the equipment; it's about providing an authentication and authorization solution that will be utilized by application vendors, reflected in application user interfaces, and applied to user views into application databases (as mirrors of the managed equipment databases). So maybe we should be having serious discussions about application frameworks like .NET and J2EE, and their security infrastructures, and how we can leverage their security infrastructures for securing both the client applications and the n-tier server functionality of network management. By n-tier functinoality, I am thinking of application databases, the proxy layer that converts from business logic requests to SMI varbinds, the communication layer between the srver and the remote SNMP engine, and the associated remote MIBs that connect from the SNMP protocol to the underlying instrumentation. Web services has already been dealing with this type of archoitectural breakdown. I'm not suggesting using http and web services, but leveraging the security infrastructure that correlates user authentication at the client application to the database access routines, and to remote procedure calls into remote databases. I think that discussing SSH vs RADIUS vs PKI vs local accounts is thinking too much about the protocols, and not enough about the high-level problem of leveraging security infrastructure in complete network management **systems**. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Thursday, August 11, 2005 11:50 AM > To: isms@ietf.org > Subject: Re: [Isms] charter proposal >=20 > Hi - >=20 > > From: "Eliot Lear" > > To: "Randy Presuhn" > > Cc: > > Sent: Thursday, August 11, 2005 3:34 AM > > Subject: Re: [Isms] charter proposal > > > > Randy, > > > > Could you and Uri please comment on what is necessary to improve > > Juergen's doc, which seems to me to cover a lot of ground that URI > > refers to? > > > > Eliot >=20 > I can't speak for Uri, but I think the heart of the matter is=20 > that there doesn't > seem to be a "mandatory to implement" integration with any of=20 > the other > infrastructures mentioned in the draft (e.g., Kerberos or=20 > Radius), or the > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > The references to any sort of AAA are very generic, (probably=20 > by design, > knowing the authors) but we need to nail down just what this stuff > talks to in order to know how to answer the fundamental question: > Does this proposal provide sufficient integration with=20 > existing infrastuctures > to satisfy the operational needs that triggered formation of this WG? >=20 > Randy >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 17:33:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3KgF-0001Pf-3u; Thu, 11 Aug 2005 17:33:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3KgD-0001Pa-OV for isms@megatron.ietf.org; Thu, 11 Aug 2005 17:33:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28544 for ; Thu, 11 Aug 2005 17:33:31 -0400 (EDT) Message-Id: <200508112133.RAA28544@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3LEX-00011i-MY for isms@ietf.org; Thu, 11 Aug 2005 18:09:06 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005081121331901300olef9e>; Thu, 11 Aug 2005 21:33:21 +0000 From: "David B Harrington" To: "'Sam Hartman'" , Subject: RE: [Isms] Limited time to charter Date: Thu, 11 Aug 2005 17:33:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWerzSqoXpNl9zEQxSfZK5iFr60HAAAcymw X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: 7bit Cc: Limited@ietf.org, time@mit.edu, to@mit.edu, charter@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, As stated in another message, I think that discussing SSH vs RADIUS vs PKI vs local accounts is thinking too much about the protocols, and not enough about the high-level problem of leveraging security infrastructure in complete network management **systems**. However, to solve the integration issue, we really need to understand how to step-wise integrate from one portion to the next until we have a solution that ties in the security infratsructure all the way from the application framnewokrs down to SNMP-specific mappings to securityModel, securityName, and securityLevel. I believe that getting the mappings between SNMP and SSH (or any other next-hop protocol) provides one link in the many steps that need to be resolved. Then we need to discuss how SSH will link to AAA and/or local accounts, and then how the AAA protocols will integrate with the applications. I am working on exploring how to establish the SNMP-to-SSH glue. I encourage oythers to work on how to define the glue between SSH and, say, RADIUS or whatever your favorite security infrastructure is. In that way we will make progress. If the members of the WG spend their time having theoretical discussions, and nobody is willing to actually write anything down, and do the thorough research necessary to provide the glues between pieces, then we're just spewing hot air and never delivering product. If that's what the members of this WG (and other O&M WGs) want to spend their doing, I suggest the question they should be mulling over is which other standards-development-organization will define the next generation of network management protocols, because it surely won't be the IETF. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Thursday, August 11, 2005 3:59 PM > To: isms@ietf.org > Cc: Limited@ietf.org; time@mit.edu; to@mit.edu; charter@mit.edu > Subject: [Isms] Limited time to charter > > > Hi, folks. > > I'd like to draw your attention to our remaining milestone: > > Aug 05 Working group will recharter to include publication goals > or shutdown if no consensus on a technical direction is > reached by > this time > > > August is fast passing us by and we don't have much time. > > I'd like to recommend to the chairs that they consider tools available > for increasing the speed of our discussion. In particular it may be > appropriate to set up conference calls, IM sessions or other more > realtime communications channels to work through issues. > > > I know there had been some discussion of an interim meeting. So far, > I don't see that an interim meeting is all that likely to resolve the > types of concerns currently being discussed and so I am reluctant to > approve such a meeting. I will however consider proposals for such a > meeting particularly if people can explain what we could accomplish > with an interim that we are not accomplishing on the list. I will > probably not be able to attend the meeting myself because of limited > travel funding but could participate by phone. > > > Keep in mind that interim meetings must be approved 30 days in advance > and that both Bert and I believe dragging things out past September is > unacceptable. > > While I remain optimistic that we can come to consensus, I must now > entertain the very real possibility that we will fail to come to > consensus. Please consider this message the formal consultation > required prior to termination of a working group under section 4 of > RFC 2418. At this time it is my opinion that absent an > interim meeting > we must choose a technical direction by the close of August. If that > does not happen this working group will close. I will consider > changes in this time table but currently do not see circumstances > under which I'm likely to agree to such a change. > > > Sam Hartman > IETF Security Area Director > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 17:56:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3L2N-0006OG-UG; Thu, 11 Aug 2005 17:56:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3L2K-0006ML-Vj for isms@megatron.ietf.org; Thu, 11 Aug 2005 17:56:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00267 for ; Thu, 11 Aug 2005 17:56:26 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Lah-0001qG-Vg for isms@ietf.org; Thu, 11 Aug 2005 18:32:01 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 44F6FE0049; Thu, 11 Aug 2005 17:56:17 -0400 (EDT) To: Subject: Re: [Isms] Limited time to charter References: <200508112133.j7BLXLn0029582@fort-point-station.mit.edu> From: Sam Hartman Date: Thu, 11 Aug 2005 17:56:17 -0400 In-Reply-To: <200508112133.j7BLXLn0029582@fort-point-station.mit.edu> (David B. Harrington's message of "Thu, 11 Aug 2005 17:33:13 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Limited@ietf.org, time@mit.edu, isms@ietf.org, charter@mit.edu, to@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> However, to solve the integration issue, we really need to David> understand how to step-wise integrate from one portion to David> the next until we have a solution that ties in the security David> infratsructure all the way from the application framnewokrs David> down to SNMP-specific mappings to securityModel, David> securityName, and securityLevel. David> I believe that getting the mappings between SNMP and SSH David> (or any other next-hop protocol) provides one link in the David> many steps that need to be resolved. Then we need to David> discuss how SSH will link to AAA and/or local accounts, and David> then how the AAA protocols will integrate with the David> applications. If you can convince the rest of the working group that this is the technical direction they need to follow and can write a charter that reflects this technical direction, that sounds like it would meet the August deadline. For a variety of reasons I think that such a charter probably would need to have specifics about which protocol you ar encapsulating. Without that I would be somewhat concerned that we're not going to get focus. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 18:16:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LHO-0001zR-6t; Thu, 11 Aug 2005 18:12:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LHL-0001z9-4F for isms@megatron.ietf.org; Thu, 11 Aug 2005 18:11:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01648 for ; Thu, 11 Aug 2005 18:11:56 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Lpf-0002Gj-4A for isms@ietf.org; Thu, 11 Aug 2005 18:47:31 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 11 Aug 2005 15:11:45 -0700 X-IronPort-AV: i="3.96,101,1122879600"; d="scan'208"; a="654439655:sNHT31660964" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7BMBb0K004812; Thu, 11 Aug 2005 15:11:38 -0700 (PDT) Message-Id: <6.2.0.14.0.20050811144239.03cedd00@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 11 Aug 2005 15:11:41 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] charter proposal In-Reply-To: <200508112012.QAA25071@ietf.org> References: <003001c59e8c$72cbdc20$7f1afea9@oemcomputer> <200508112012.QAA25071@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Sorry for my ignorance but I am not sure how the discussion of management of NMS applications via SNMP is relevant to ISMS. SNMP is not used for application management since there are already standards that provide richer and more tighter integration with applications. This includes Java standards such as JMX and CIM and WSDM. I agree that we need to provide support for common authentication systems between the SNMP/NetConf/CLI and NMS apps but I am not sure how that is related to the NMS apps being managed via SNMP. SNMP is important for what is used, i.e. Inventory, Performance and Fault monitoring of networks and it is important to have common identity and authentication mechanisms across the management domain, this includes the protocols used manage devices and user access to the NMS. To achieve that goal, the discussion of protocols such as RADIUS and TACACS+ is very essential in ISMS since these protocol servers work as proxies to enable unification of identity and authentication stores. Most AAA servers support integration into a variety of back-end identity and authentication systems thereby allowing organizations to use a single identity and credentials across a variety of domains such as applications access including network management apps, network access and device access. We have been fairly successful with using AAA servers as a proxy to Active Directory, LDAP servers, Token Servers and NIS+ That's the reason our initial focus with EUSM was to make sure that we enable SNMP authentication to integrate with a RADIUS server. regards, kaushik! At 01:12 PM 8/11/2005, David B Harrington wrote: >Hi, > >I think the issues under discussion may actually be missing the point >somewhat, or hitting the nail on the head, depending on how you look >at it. > >Having worked for Enterasys first in the management application side, >and then in the equipment side, I see a fundamental problem. > >Gene mentioned that SNMPv3 is supported in a bunch of devices, and I >agree with that. While equipment vendors have provided varying degrees >of support, most of the major equipment vendors do support SNMPv3 >messaging and the MIB modules to support SNMPv3. > >The place where SNMPv3 really isn't supported is in the management >applications. I believe this is the result of two major impacts of >SNMPv3 on management applications. > >First, while networking equipment has long supported remote monitoring >and some configuration via SNMP, management applications have >**never** allowed remote monitoring and configuration via SNMP. SNMPv3 >added a MIB to management applications; in SNMPv1, the MIB only >existed in the managed equipment. It is a very foreign concept to >allow some other entity to modify the operating environment, >especially the security parameters, of the application from the >network side of things. And I don't see applications vendors jumping >up and saying, "oh, please let me open that can of worms for my >programs!" > >Second, SNMP defines a user-interface via MIB modules for equipment, >but the user-interface for management applications is very different. >To add real support for the concepts of SNMPv3 could require lots of >changes to code and internal APIs to pass the necessary parameters >from the user interfaces for client implementations, to access the >server functionality, through the program logic, and into the database >interface to remote management protocols and, ultimately, the SNMP >stack. In addition, if access control is applied at the managed >device, then the applications should also honor the access controls, >so a MIB module accessible to "lear" but not "dbh" on a remote device >isn't exposed to "dbh" through the management application's database. >Adding support for SNMPv3 concepts and applying SNMPv3 access control >is a huge cost for application vendors. > >So the problem isn't just about leveraging the AAA support already >supported in the equipment; it's about providing an authentication and >authorization solution that will be utilized by application vendors, >reflected in application user interfaces, and applied to user views >into application databases (as mirrors of the managed equipment >databases). > >So maybe we should be having serious discussions about application >frameworks like .NET and J2EE, and their security infrastructures, and >how we can leverage their security infrastructures for securing both >the client applications and the n-tier server functionality of >network management. By n-tier functinoality, I am thinking of >application databases, the proxy layer that converts from business >logic requests to SMI varbinds, the communication layer between the >srver and the remote SNMP engine, and the associated remote MIBs that >connect from the SNMP protocol to the underlying instrumentation. Web >services has already been dealing with this type of archoitectural >breakdown. > >I'm not suggesting using http and web services, but leveraging the >security infrastructure that correlates user authentication at the >client application to the database access routines, and to remote >procedure calls into remote databases. > >I think that discussing SSH vs RADIUS vs PKI vs local accounts is >thinking too much about the protocols, and not enough about the >high-level problem of leveraging security infrastructure in complete >network management **systems**. > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > Sent: Thursday, August 11, 2005 11:50 AM > > To: isms@ietf.org > > Subject: Re: [Isms] charter proposal > > > > Hi - > > > > > From: "Eliot Lear" > > > To: "Randy Presuhn" > > > Cc: > > > Sent: Thursday, August 11, 2005 3:34 AM > > > Subject: Re: [Isms] charter proposal > > > > > > Randy, > > > > > > Could you and Uri please comment on what is necessary to improve > > > Juergen's doc, which seems to me to cover a lot of ground that URI > > > refers to? > > > > > > Eliot > > > > I can't speak for Uri, but I think the heart of the matter is > > that there doesn't > > seem to be a "mandatory to implement" integration with any of > > the other > > infrastructures mentioned in the draft (e.g., Kerberos or > > Radius), or the > > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > > The references to any sort of AAA are very generic, (probably > > by design, > > knowing the authors) but we need to nail down just what this stuff > > talks to in order to know how to answer the fundamental question: > > Does this proposal provide sufficient integration with > > existing infrastuctures > > to satisfy the operational needs that triggered formation of this >WG? > > > > Randy > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 18:18:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LNz-0004N1-8Q; Thu, 11 Aug 2005 18:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3LNx-0004Mr-No for isms@megatron.ietf.org; Thu, 11 Aug 2005 18:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02466 for ; Thu, 11 Aug 2005 18:18:47 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3LwL-0002VW-B4 for isms@ietf.org; Thu, 11 Aug 2005 18:54:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7BMIZ12016977; Thu, 11 Aug 2005 17:18:36 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 12 Aug 2005 00:18:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507C4AD5D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, "'Sam Hartman'" , isms@ietf.org Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 00:18:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Limited@ietf.org, time@mit.edu, to@mit.edu, charter@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org [Sam, do you want us to keep teh CC: line to all those lists at mit.edu?] Dbh and others, W.r.t. > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of David B Harrington > Sent: Thursday, August 11, 2005 23:33 > To: 'Sam Hartman'; isms@ietf.org > Cc: Limited@ietf.org; time@mit.edu; to@mit.edu; charter@mit.edu > Subject: RE: [Isms] Limited time to charter > > > Hi, > > As stated in another message, I think that discussing SSH vs RADIUS vs > PKI vs local accounts is thinking too much about the protocols, and > not enough about the high-level problem of leveraging security > infrastructure in complete network management **systems**. > I would like to point out that in the grand scheme of things, many operators and enterprises use SNMP only in the Element to Element Management Layer (ELM) and use totally different technologies to communicate between ELM and NML and upt to SML and up to BML (Network Management Layer, Service Management Layer and Business Management Layer), i.e. the TMN piramid. They use terms like southbound (from EML to EM) where they use SNMP and northbound (from EML to NML and up) where they often use Corba etc etc. I do not believe that we have the correct participants to try and address the security infrastructure for that complete NM system picture. YMMV. Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 18:44:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Lml-0001SI-ST; Thu, 11 Aug 2005 18:44:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Lmj-0001SD-Qh for isms@megatron.ietf.org; Thu, 11 Aug 2005 18:44:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03986 for ; Thu, 11 Aug 2005 18:44:22 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3ML7-00037E-DS for isms@ietf.org; Thu, 11 Aug 2005 19:19:58 -0400 Received: from h-68-165-6-176.snvacaid.dynamic.covad.net ([68.165.6.176] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3Lmd-0002jb-00 for isms@ietf.org; Thu, 11 Aug 2005 18:44:19 -0400 Message-ID: <002c01c59ec6$6199a6a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <003001c59e8c$72cbdc20$7f1afea9@oemcomputer> <200508112012.QAA25071@ietf.org> <6.2.0.14.0.20050811144239.03cedd00@email.cisco.com> Subject: Re: [Isms] charter proposal Date: Thu, 11 Aug 2005 15:44:36 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Kaushik Narayan" > To: > Cc: "'Randy Presuhn'" ; > Sent: Thursday, August 11, 2005 3:11 PM > Subject: RE: [Isms] charter proposal ... > Sorry for my ignorance but I am not sure how the discussion of > management of NMS applications via SNMP is relevant to ISMS. ... When an NMS uses SNMPv3 to communicate with some managed system, it does so on behalf of a user. For the SNMP engines at both ends of this interaction, it was intended that the users and their keys would managed through the USM MIB, though the specifications don't preclude that information arriving there via some mechanism other than SNMPv3. Some NMS developers had a really hard time grasping that some of the parameters of *their* application might be managed, just like those of anything else. ... > To achieve that goal, the discussion of protocols such as RADIUS and TACACS+ > is very essential in ISMS since these protocol servers work as proxies > to enable unification of identity and authentication stores. Most > AAA servers support integration into a variety of back-end identity > and authentication systems thereby allowing organizations to use a > single identity and credentials across a variety of domains such as > applications access including network management apps, network > access and device access. We have been fairly successful with > using AAA servers as a proxy to Active Directory, LDAP servers, > Token Servers and NIS+ ... I think we're agreeing. Specify how it's supposed to work with some small N that will cover most of the operator requirements, and make one mandatory to implement. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 19:18:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MJS-0008JV-3W; Thu, 11 Aug 2005 19:18:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MJQ-0008JL-UM for isms@megatron.ietf.org; Thu, 11 Aug 2005 19:18:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05686 for ; Thu, 11 Aug 2005 19:18:09 -0400 (EDT) Message-Id: <200508112318.TAA05686@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Mrp-0003yj-Ru for isms@ietf.org; Thu, 11 Aug 2005 19:53:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005081123180201300oergne>; Thu, 11 Aug 2005 23:18:02 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 19:17:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <6.2.0.14.0.20050811144239.03cedd00@email.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWewajuZxZ3PmsuTnqym74EbTOD3gABiF1g X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Kaushik, USM expects shared key management to be done via SNMPv3, and application vendors don't allow their applications to be managed via SNMP. So while you can try to synchronize the keys across multiple managed devices using SNMP, you cannot synchronize the keys used by the applications using SNMP. Changing to a different security model, you might be able to synchronize the keys across multiple managed devices using RADIUS, or TACACS+, or Kerberos, or PKI, but can you manage the keys used by the NMS applications? I'm working on writing a proposal to provide the glue between SNMP and SSH, because SSH is used for accessing the CLI on many vendors' network-equipment products, but I'm not sure how many SNMP management application vendors support using SSH to talk to the CLI, and how many applications use the SSH user/key infrastructure to authenicate the users of the applications. So while we might enable updating user/keys across multiple devices, how many NMS applications will support such an approach? I would like to see a concrete proposal of how NMS applications should be updated to support a common authentication infrastructure like SSH or RADIUS, and the implications of utilizing such a proposal within an NMS application like HPOV. So far, the discussion seems to be mostly about engine-to-AAA issues, not application-impact considerations. If the SNMP stack needs to provide CHAP credentials to authenticate the user, the application is going to need to prompt the user for his credentials, and track the sessions and so on. How will this impact the application? Do most NMS applications currently support going to a AAA server to authenticate its users now? Which ones do this? How do they do it? If your applications do this now, can you document how this is done so we can standardize the approach, and encourage other NMS applications to use the same approach? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Thursday, August 11, 2005 6:12 PM > To: ietfdbh@comcast.net > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: RE: [Isms] charter proposal > > Hi David, > > Sorry for my ignorance but I am not sure how the discussion of > management of NMS applications via SNMP is relevant to ISMS. > SNMP is not used for application management since there are > already standards that provide richer and more tighter integration > with applications. This includes Java standards such as JMX and > CIM and WSDM. I agree that we need to provide support for > common authentication systems between the SNMP/NetConf/CLI > and NMS apps but I am not sure how that is related to the NMS > apps being managed via SNMP. > > SNMP is important for what is used, i.e. Inventory, Performance > and Fault monitoring of networks and it is important to have common > identity and authentication mechanisms across the management > domain, this includes the protocols used manage devices and user > access to the NMS. > > To achieve that goal, the discussion of protocols such as > RADIUS and TACACS+ > is very essential in ISMS since these protocol servers work as proxies > to enable unification of identity and authentication stores. Most > AAA servers support integration into a variety of back-end identity > and authentication systems thereby allowing organizations to use a > single identity and credentials across a variety of domains such as > applications access including network management apps, network > access and device access. We have been fairly successful with > using AAA servers as a proxy to Active Directory, LDAP servers, > Token Servers and NIS+ > > That's the reason our initial focus with EUSM was to make sure that we > enable SNMP authentication to integrate with a RADIUS server. > > regards, > kaushik! > > At 01:12 PM 8/11/2005, David B Harrington wrote: > >Hi, > > > >I think the issues under discussion may actually be missing the point > >somewhat, or hitting the nail on the head, depending on how you look > >at it. > > > >Having worked for Enterasys first in the management application side, > >and then in the equipment side, I see a fundamental problem. > > > >Gene mentioned that SNMPv3 is supported in a bunch of devices, and I > >agree with that. While equipment vendors have provided > varying degrees > >of support, most of the major equipment vendors do support SNMPv3 > >messaging and the MIB modules to support SNMPv3. > > > >The place where SNMPv3 really isn't supported is in the management > >applications. I believe this is the result of two major impacts of > >SNMPv3 on management applications. > > > >First, while networking equipment has long supported remote > monitoring > >and some configuration via SNMP, management applications have > >**never** allowed remote monitoring and configuration via > SNMP. SNMPv3 > >added a MIB to management applications; in SNMPv1, the MIB only > >existed in the managed equipment. It is a very foreign concept to > >allow some other entity to modify the operating environment, > >especially the security parameters, of the application from the > >network side of things. And I don't see applications vendors jumping > >up and saying, "oh, please let me open that can of worms for my > >programs!" > > > >Second, SNMP defines a user-interface via MIB modules for equipment, > >but the user-interface for management applications is very different. > >To add real support for the concepts of SNMPv3 could require lots of > >changes to code and internal APIs to pass the necessary parameters > >from the user interfaces for client implementations, to access the > >server functionality, through the program logic, and into > the database > >interface to remote management protocols and, ultimately, the SNMP > >stack. In addition, if access control is applied at the managed > >device, then the applications should also honor the access controls, > >so a MIB module accessible to "lear" but not "dbh" on a remote device > >isn't exposed to "dbh" through the management application's database. > >Adding support for SNMPv3 concepts and applying SNMPv3 access control > >is a huge cost for application vendors. > > > >So the problem isn't just about leveraging the AAA support already > >supported in the equipment; it's about providing an > authentication and > >authorization solution that will be utilized by application vendors, > >reflected in application user interfaces, and applied to user views > >into application databases (as mirrors of the managed equipment > >databases). > > > >So maybe we should be having serious discussions about application > >frameworks like .NET and J2EE, and their security > infrastructures, and > >how we can leverage their security infrastructures for securing both > >the client applications and the n-tier server functionality of > >network management. By n-tier functinoality, I am thinking of > >application databases, the proxy layer that converts from business > >logic requests to SMI varbinds, the communication layer between the > >srver and the remote SNMP engine, and the associated remote MIBs that > >connect from the SNMP protocol to the underlying instrumentation. Web > >services has already been dealing with this type of archoitectural > >breakdown. > > > >I'm not suggesting using http and web services, but leveraging the > >security infrastructure that correlates user authentication at the > >client application to the database access routines, and to remote > >procedure calls into remote databases. > > > >I think that discussing SSH vs RADIUS vs PKI vs local accounts is > >thinking too much about the protocols, and not enough about the > >high-level problem of leveraging security infrastructure in complete > >network management **systems**. > > > >David Harrington > >dbharrington@comcast.net > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > Sent: Thursday, August 11, 2005 11:50 AM > > > To: isms@ietf.org > > > Subject: Re: [Isms] charter proposal > > > > > > Hi - > > > > > > > From: "Eliot Lear" > > > > To: "Randy Presuhn" > > > > Cc: > > > > Sent: Thursday, August 11, 2005 3:34 AM > > > > Subject: Re: [Isms] charter proposal > > > > > > > > Randy, > > > > > > > > Could you and Uri please comment on what is necessary to improve > > > > Juergen's doc, which seems to me to cover a lot of > ground that URI > > > > refers to? > > > > > > > > Eliot > > > > > > I can't speak for Uri, but I think the heart of the matter is > > > that there doesn't > > > seem to be a "mandatory to implement" integration with any of > > > the other > > > infrastructures mentioned in the draft (e.g., Kerberos or > > > Radius), or the > > > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > > > The references to any sort of AAA are very generic, (probably > > > by design, > > > knowing the authors) but we need to nail down just what this stuff > > > talks to in order to know how to answer the fundamental question: > > > Does this proposal provide sufficient integration with > > > existing infrastuctures > > > to satisfy the operational needs that triggered formation of this > >WG? > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 19:31:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MWL-0002s4-Vb; Thu, 11 Aug 2005 19:31:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MWJ-0002rz-IM for isms@megatron.ietf.org; Thu, 11 Aug 2005 19:31:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06287 for ; Thu, 11 Aug 2005 19:31:28 -0400 (EDT) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3N4i-0004Sd-3M for isms@ietf.org; Thu, 11 Aug 2005 20:07:04 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7BNVF2X032089; Thu, 11 Aug 2005 23:31:15 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7BNVEYn023661; Thu, 11 Aug 2005 23:31:15 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005081116311502144 ; Thu, 11 Aug 2005 16:31:15 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 16:31:07 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 16:31:06 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 19:31:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 19:26:48 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901A5EB50@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWewajuZxZ3PmsuTnqym74EbTOD3gABiF1gAADML0A= From: "Blumenthal, Uri" To: , "Kaushik Narayan" X-OriginalArrivalTime: 11 Aug 2005 23:31:05.0522 (UTC) FILETIME=[BE6C6920:01C59ECC] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm surprised to see SSH or TLS called "infrastructure".=20 A. In case of SSH the infrastructure is local accounts. All the access control is performed by the host OS. B. In case of TLS the infrastructure is a mix of PKI for servers and either server-maintained password database, or AD/Kerberos for users/clients. So one needs glue not between SNMP and SSH - but between SNMP and local accounts (accessible via SSH). I don't believe this WG can even attempt to solve the problem of applications, though I acknowledge its (problem's) importance. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Thursday, August 11, 2005 7:18 PM To: 'Kaushik Narayan' Cc: isms@ietf.org Subject: RE: [Isms] charter proposal Hi Kaushik, USM expects shared key management to be done via SNMPv3, and application vendors don't allow their applications to be managed via SNMP. So while you can try to synchronize the keys across multiple managed devices using SNMP, you cannot synchronize the keys used by the applications using SNMP. Changing to a different security model, you might be able to synchronize the keys across multiple managed devices using RADIUS, or TACACS+, or Kerberos, or PKI, but can you manage the keys used by the NMS applications?=20 I'm working on writing a proposal to provide the glue between SNMP and SSH, because SSH is used for accessing the CLI on many vendors' network-equipment products, but I'm not sure how many SNMP management application vendors support using SSH to talk to the CLI, and how many applications use the SSH user/key infrastructure to authenicate the users of the applications. So while we might enable updating user/keys across multiple devices, how many NMS applications will support such an approach? I would like to see a concrete proposal of how NMS applications should be updated to support a common authentication infrastructure like SSH or RADIUS, and the implications of utilizing such a proposal within an NMS application like HPOV. So far, the discussion seems to be mostly about engine-to-AAA issues, not application-impact considerations. If the SNMP stack needs to provide CHAP credentials to authenticate the user, the application is going to need to prompt the user for his credentials, and track the sessions and so on. How will this impact the application?=20 Do most NMS applications currently support going to a AAA server to authenticate its users now? Which ones do this? How do they do it? If your applications do this now, can you document how this is done so we can standardize the approach, and encourage other NMS applications to use the same approach? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 > Sent: Thursday, August 11, 2005 6:12 PM > To: ietfdbh@comcast.net > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: RE: [Isms] charter proposal >=20 > Hi David, >=20 > Sorry for my ignorance but I am not sure how the discussion of > management of NMS applications via SNMP is relevant to ISMS. > SNMP is not used for application management since there are > already standards that provide richer and more tighter integration > with applications. This includes Java standards such as JMX and > CIM and WSDM. I agree that we need to provide support for > common authentication systems between the SNMP/NetConf/CLI > and NMS apps but I am not sure how that is related to the NMS > apps being managed via SNMP. >=20 > SNMP is important for what is used, i.e. Inventory, Performance > and Fault monitoring of networks and it is important to have common > identity and authentication mechanisms across the management > domain, this includes the protocols used manage devices and user > access to the NMS. >=20 > To achieve that goal, the discussion of protocols such as=20 > RADIUS and TACACS+ > is very essential in ISMS since these protocol servers work as proxies > to enable unification of identity and authentication stores. Most > AAA servers support integration into a variety of back-end identity > and authentication systems thereby allowing organizations to use a > single identity and credentials across a variety of domains such as > applications access including network management apps, network > access and device access. We have been fairly successful with > using AAA servers as a proxy to Active Directory, LDAP servers, > Token Servers and NIS+ >=20 > That's the reason our initial focus with EUSM was to make sure that we > enable SNMP authentication to integrate with a RADIUS server. >=20 > regards, > kaushik! >=20 > At 01:12 PM 8/11/2005, David B Harrington wrote: > >Hi, > > > >I think the issues under discussion may actually be missing the point > >somewhat, or hitting the nail on the head, depending on how you look > >at it. > > > >Having worked for Enterasys first in the management application side, > >and then in the equipment side, I see a fundamental problem. > > > >Gene mentioned that SNMPv3 is supported in a bunch of devices, and I > >agree with that. While equipment vendors have provided=20 > varying degrees > >of support, most of the major equipment vendors do support SNMPv3 > >messaging and the MIB modules to support SNMPv3. > > > >The place where SNMPv3 really isn't supported is in the management > >applications. I believe this is the result of two major impacts of > >SNMPv3 on management applications. > > > >First, while networking equipment has long supported remote=20 > monitoring > >and some configuration via SNMP, management applications have > >**never** allowed remote monitoring and configuration via=20 > SNMP. SNMPv3 > >added a MIB to management applications; in SNMPv1, the MIB only > >existed in the managed equipment. It is a very foreign concept to > >allow some other entity to modify the operating environment, > >especially the security parameters, of the application from the > >network side of things. And I don't see applications vendors jumping > >up and saying, "oh, please let me open that can of worms for my > >programs!" > > > >Second, SNMP defines a user-interface via MIB modules for equipment, > >but the user-interface for management applications is very different. > >To add real support for the concepts of SNMPv3 could require lots of > >changes to code and internal APIs to pass the necessary parameters > >from the user interfaces for client implementations, to access the > >server functionality, through the program logic, and into=20 > the database > >interface to remote management protocols and, ultimately, the SNMP > >stack. In addition, if access control is applied at the managed > >device, then the applications should also honor the access controls, > >so a MIB module accessible to "lear" but not "dbh" on a remote device > >isn't exposed to "dbh" through the management application's database. > >Adding support for SNMPv3 concepts and applying SNMPv3 access control > >is a huge cost for application vendors. > > > >So the problem isn't just about leveraging the AAA support already > >supported in the equipment; it's about providing an=20 > authentication and > >authorization solution that will be utilized by application vendors, > >reflected in application user interfaces, and applied to user views > >into application databases (as mirrors of the managed equipment > >databases). > > > >So maybe we should be having serious discussions about application > >frameworks like .NET and J2EE, and their security=20 > infrastructures, and > >how we can leverage their security infrastructures for securing both > >the client applications and the n-tier server functionality of > >network management. By n-tier functinoality, I am thinking of > >application databases, the proxy layer that converts from business > >logic requests to SMI varbinds, the communication layer between the > >srver and the remote SNMP engine, and the associated remote MIBs that > >connect from the SNMP protocol to the underlying instrumentation. Web > >services has already been dealing with this type of archoitectural > >breakdown. > > > >I'm not suggesting using http and web services, but leveraging the > >security infrastructure that correlates user authentication at the > >client application to the database access routines, and to remote > >procedure calls into remote databases. > > > >I think that discussing SSH vs RADIUS vs PKI vs local accounts is > >thinking too much about the protocols, and not enough about the > >high-level problem of leveraging security infrastructure in complete > >network management **systems**. > > > >David Harrington > >dbharrington@comcast.net > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > Sent: Thursday, August 11, 2005 11:50 AM > > > To: isms@ietf.org > > > Subject: Re: [Isms] charter proposal > > > > > > Hi - > > > > > > > From: "Eliot Lear" > > > > To: "Randy Presuhn" > > > > Cc: > > > > Sent: Thursday, August 11, 2005 3:34 AM > > > > Subject: Re: [Isms] charter proposal > > > > > > > > Randy, > > > > > > > > Could you and Uri please comment on what is necessary to improve > > > > Juergen's doc, which seems to me to cover a lot of=20 > ground that URI > > > > refers to? > > > > > > > > Eliot > > > > > > I can't speak for Uri, but I think the heart of the matter is > > > that there doesn't > > > seem to be a "mandatory to implement" integration with any of > > > the other > > > infrastructures mentioned in the draft (e.g., Kerberos or > > > Radius), or the > > > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > > > The references to any sort of AAA are very generic, (probably > > > by design, > > > knowing the authors) but we need to nail down just what this stuff > > > talks to in order to know how to answer the fundamental question: > > > Does this proposal provide sufficient integration with > > > existing infrastuctures > > > to satisfy the operational needs that triggered formation of this > >WG? > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 19:35:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MZi-0003T4-SJ; Thu, 11 Aug 2005 19:35:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MZg-0003Qc-JV for isms@megatron.ietf.org; Thu, 11 Aug 2005 19:35:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06394 for ; Thu, 11 Aug 2005 19:34:57 -0400 (EDT) Message-Id: <200508112334.TAA06394@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3N84-0004Zf-Hi for isms@ietf.org; Thu, 11 Aug 2005 20:10:33 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005081123344401300ohvime>; Thu, 11 Aug 2005 23:34:45 +0000 From: "David B Harrington" To: "'Sam Hartman'" Subject: RE: [Isms] Limited time to charter Date: Thu, 11 Aug 2005 19:34:38 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWev4SRvqsllbW2SKukQax00ptcoQAC4YsQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: Limited@ietf.org, time@mit.edu, isms@ietf.org, charter@mit.edu, to@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, So do we have any volunteers to work on documenting how SSH authenticates its users using RADIUS or Kerberos, and makes the model (e.g. RADIUS), user (user-auth), and level (authentication and encryption services) accessible in a standard manner within SSH, or in an SSH-API for protocols using SSH services? Given these mappings between SSH and RADIUS, and a way to access these mappings, a TMSM model based on SSH can translate that into securityModel, securityName, and securityLevel for SNMP usage. I'm working on the SNMP-to-SSH interface, and have done initial passes at SNMP-to-TLS, and SNMP-to-DTLS, and SNMP-to-SASL, but we need more. Do we have volunteers to write an SSH-to-RADIUS document? Or SSH-to-TACACS+, or SSH-to-Kerberos or SSH-to-PKI? Since these are reputedly used for accessing the CLI subsystem, there must be people who understand how to provide such mappings. Or maybe we need an SSH-to-CLI-to-RADIUS, and SSH-to-CLI-to-XXXX mapping, and so on. Who's willing to commit to doing some writing? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Thursday, August 11, 2005 5:56 PM > To: ietfdbh@comcast.net > Cc: isms@ietf.org; Limited@ietf.org; time@mit.edu; > to@mit.edu; charter@mit.edu > Subject: Re: [Isms] Limited time to charter > > >>>>> "David" == David B Harrington writes: > > David> However, to solve the integration issue, we really need to > David> understand how to step-wise integrate from one portion to > David> the next until we have a solution that ties in the security > David> infratsructure all the way from the application framnewokrs > David> down to SNMP-specific mappings to securityModel, > David> securityName, and securityLevel. > > David> I believe that getting the mappings between SNMP and SSH > David> (or any other next-hop protocol) provides one link in the > David> many steps that need to be resolved. Then we need to > David> discuss how SSH will link to AAA and/or local accounts, and > David> then how the AAA protocols will integrate with the > David> applications. > > > > If you can convince the rest of the working group that this is the > technical direction they need to follow and can write a charter that > reflects this technical direction, that sounds like it would meet the > August deadline. > > > For a variety of reasons I think that such a charter probably would > need to have specifics about which protocol you ar encapsulating. > Without that I would be somewhat concerned that we're not going to get > focus. > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 19:38:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Mcj-0003sV-8O; Thu, 11 Aug 2005 19:38:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Mch-0003sQ-BN for isms@megatron.ietf.org; Thu, 11 Aug 2005 19:38:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06518 for ; Thu, 11 Aug 2005 19:38:04 -0400 (EDT) Message-Id: <200508112338.TAA06518@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3NB6-0004gb-QR for isms@ietf.org; Thu, 11 Aug 2005 20:13:41 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc11) with SMTP id <2005081123375701300og4kae>; Thu, 11 Aug 2005 23:37:57 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , "'Kaushik Narayan'" Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 19:37:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <3DEC199BD7489643817ECA151F7C592901A5EB50@pysmsx401.amr.corp.intel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWewajuZxZ3PmsuTnqym74EbTOD3gABiF1gAADML0AAAJwEkA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] > > So one needs glue not between SNMP and SSH - but between > SNMP and local accounts (accessible via SSH). So are you volunteering to document how this mapping could be achieved? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 19:58:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Mwt-00083W-7F; Thu, 11 Aug 2005 19:58:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Mws-00083Q-1d for isms@megatron.ietf.org; Thu, 11 Aug 2005 19:58:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07410 for ; Thu, 11 Aug 2005 19:58:56 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3NVH-0005b9-5N for isms@ietf.org; Thu, 11 Aug 2005 20:34:31 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Aug 2005 16:58:49 -0700 X-IronPort-AV: i="3.96,101,1122879600"; d="scan'208"; a="204333153:sNHT35616992" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7BNwj2j019756; Thu, 11 Aug 2005 16:58:46 -0700 (PDT) Message-Id: <6.2.0.14.0.20050811162216.03d4d550@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 11 Aug 2005 16:43:04 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] charter proposal In-Reply-To: <40qjma$34dgr9@sj-inbound-e.cisco.com> References: <6.2.0.14.0.20050811144239.03cedd00@email.cisco.com> <40qjma$34dgr9@sj-inbound-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 24d000849df6f171c5ec1cca2ea21b82 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Dave, Please find my reply inline. At 04:17 PM 8/11/2005, David B Harrington wrote: >Hi Kaushik, > >USM expects shared key management to be done via SNMPv3, and >application vendors don't allow their applications to be managed via >SNMP. So while you can try to synchronize the keys across multiple >managed devices using SNMP, you cannot synchronize the keys used by >the applications using SNMP. I am not sure about what you mean by "keys used by applications". I am assuming you are referring to keys used to protect communication channels used by the applications such from a web browser/client or between application servers in a distributed model. Well most of these keys tend to be ephemeral and have no co-relation to the principal accessing the application. The prevalent model is to tunnel application protocols such as HTTP, IIOP and JMS over TLS. The TLS channel is authenticated via the server cert and clients are authenticated via username/password. This is similar to what would happen if you login to bank account online. (there are very few applications that support client side certs except in cases where clients are a system entity such as an OSS system). In terms of integrated security it is important that the same username/password is used south bound from the NMS applications going to the device as used in gaining access to the NMS itself. >Changing to a different security model, you might be able to >synchronize the keys across multiple managed devices using RADIUS, or >TACACS+, or Kerberos, or PKI, but can you manage the keys used by the >NMS applications? Again I think the key management is a bit of a red herring unless we are talking about different "keys" here. >I'm working on writing a proposal to provide the glue between SNMP and >SSH, because SSH is used for accessing the CLI on many vendors' >network-equipment products, but I'm not sure how many SNMP management >application vendors support using SSH to talk to the CLI, and how many >applications use the SSH user/key infrastructure to authenicate the >users of the applications. So while we might enable updating user/keys >across multiple devices, how many NMS applications will support such >an approach? Our NMS applications do use SSH to access CLI on our devices and all our authentication is user based. So by pointing both the device and the NMS to the same AAA server, we can essentially use the same username/password provided during NMS login going down from the NMS to the device. There are however exceptions since that might not be desired in some cases, there might be a need to use a pre-configured system account to communicate with devices. >I would like to see a concrete proposal of how NMS applications should >be updated to support a common authentication infrastructure like SSH >or RADIUS, and the implications of utilizing such a proposal within an >NMS application like HPOV. > >So far, the discussion seems to be mostly about engine-to-AAA issues, >not application-impact considerations. If the SNMP stack needs to >provide CHAP credentials to authenticate the user, the application is >going to need to prompt the user for his credentials, and track the >sessions and so on. How will this impact the application? > >Do most NMS applications currently support going to a AAA server to >authenticate its users now? Which ones do this? How do they do it? If >your applications do this now, can you document how this is done so we >can standardize the approach, and encourage other NMS applications to >use the same approach? Most of our NMS applications support the use of AAA for login to the NMS and there is very commonly used by a lot of our customers. The NMS behaves like a standard RADIUS or T+ client. regards, kaushik! >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: Kaushik Narayan [mailto:kaushik@cisco.com] > > Sent: Thursday, August 11, 2005 6:12 PM > > To: ietfdbh@comcast.net > > Cc: 'Randy Presuhn'; isms@ietf.org > > Subject: RE: [Isms] charter proposal > > > > Hi David, > > > > Sorry for my ignorance but I am not sure how the discussion of > > management of NMS applications via SNMP is relevant to ISMS. > > SNMP is not used for application management since there are > > already standards that provide richer and more tighter integration > > with applications. This includes Java standards such as JMX and > > CIM and WSDM. I agree that we need to provide support for > > common authentication systems between the SNMP/NetConf/CLI > > and NMS apps but I am not sure how that is related to the NMS > > apps being managed via SNMP. > > > > SNMP is important for what is used, i.e. Inventory, Performance > > and Fault monitoring of networks and it is important to have common > > identity and authentication mechanisms across the management > > domain, this includes the protocols used manage devices and user > > access to the NMS. > > > > To achieve that goal, the discussion of protocols such as > > RADIUS and TACACS+ > > is very essential in ISMS since these protocol servers work as >proxies > > to enable unification of identity and authentication stores. Most > > AAA servers support integration into a variety of back-end identity > > and authentication systems thereby allowing organizations to use a > > single identity and credentials across a variety of domains such as > > applications access including network management apps, network > > access and device access. We have been fairly successful with > > using AAA servers as a proxy to Active Directory, LDAP servers, > > Token Servers and NIS+ > > > > That's the reason our initial focus with EUSM was to make sure that >we > > enable SNMP authentication to integrate with a RADIUS server. > > > > regards, > > kaushik! > > > > At 01:12 PM 8/11/2005, David B Harrington wrote: > > >Hi, > > > > > >I think the issues under discussion may actually be missing the >point > > >somewhat, or hitting the nail on the head, depending on how you >look > > >at it. > > > > > >Having worked for Enterasys first in the management application >side, > > >and then in the equipment side, I see a fundamental problem. > > > > > >Gene mentioned that SNMPv3 is supported in a bunch of devices, and >I > > >agree with that. While equipment vendors have provided > > varying degrees > > >of support, most of the major equipment vendors do support SNMPv3 > > >messaging and the MIB modules to support SNMPv3. > > > > > >The place where SNMPv3 really isn't supported is in the management > > >applications. I believe this is the result of two major impacts of > > >SNMPv3 on management applications. > > > > > >First, while networking equipment has long supported remote > > monitoring > > >and some configuration via SNMP, management applications have > > >**never** allowed remote monitoring and configuration via > > SNMP. SNMPv3 > > >added a MIB to management applications; in SNMPv1, the MIB only > > >existed in the managed equipment. It is a very foreign concept to > > >allow some other entity to modify the operating environment, > > >especially the security parameters, of the application from the > > >network side of things. And I don't see applications vendors >jumping > > >up and saying, "oh, please let me open that can of worms for my > > >programs!" > > > > > >Second, SNMP defines a user-interface via MIB modules for >equipment, > > >but the user-interface for management applications is very >different. > > >To add real support for the concepts of SNMPv3 could require lots >of > > >changes to code and internal APIs to pass the necessary parameters > > >from the user interfaces for client implementations, to access the > > >server functionality, through the program logic, and into > > the database > > >interface to remote management protocols and, ultimately, the SNMP > > >stack. In addition, if access control is applied at the managed > > >device, then the applications should also honor the access >controls, > > >so a MIB module accessible to "lear" but not "dbh" on a remote >device > > >isn't exposed to "dbh" through the management application's >database. > > >Adding support for SNMPv3 concepts and applying SNMPv3 access >control > > >is a huge cost for application vendors. > > > > > >So the problem isn't just about leveraging the AAA support already > > >supported in the equipment; it's about providing an > > authentication and > > >authorization solution that will be utilized by application >vendors, > > >reflected in application user interfaces, and applied to user views > > >into application databases (as mirrors of the managed equipment > > >databases). > > > > > >So maybe we should be having serious discussions about application > > >frameworks like .NET and J2EE, and their security > > infrastructures, and > > >how we can leverage their security infrastructures for securing >both > > >the client applications and the n-tier server functionality of > > >network management. By n-tier functinoality, I am thinking of > > >application databases, the proxy layer that converts from business > > >logic requests to SMI varbinds, the communication layer between the > > >srver and the remote SNMP engine, and the associated remote MIBs >that > > >connect from the SNMP protocol to the underlying instrumentation. >Web > > >services has already been dealing with this type of archoitectural > > >breakdown. > > > > > >I'm not suggesting using http and web services, but leveraging the > > >security infrastructure that correlates user authentication at the > > >client application to the database access routines, and to remote > > >procedure calls into remote databases. > > > > > >I think that discussing SSH vs RADIUS vs PKI vs local accounts is > > >thinking too much about the protocols, and not enough about the > > >high-level problem of leveraging security infrastructure in >complete > > >network management **systems**. > > > > > >David Harrington > > >dbharrington@comcast.net > > > > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > Sent: Thursday, August 11, 2005 11:50 AM > > > > To: isms@ietf.org > > > > Subject: Re: [Isms] charter proposal > > > > > > > > Hi - > > > > > > > > > From: "Eliot Lear" > > > > > To: "Randy Presuhn" > > > > > Cc: > > > > > Sent: Thursday, August 11, 2005 3:34 AM > > > > > Subject: Re: [Isms] charter proposal > > > > > > > > > > Randy, > > > > > > > > > > Could you and Uri please comment on what is necessary to >improve > > > > > Juergen's doc, which seems to me to cover a lot of > > ground that URI > > > > > refers to? > > > > > > > > > > Eliot > > > > > > > > I can't speak for Uri, but I think the heart of the matter is > > > > that there doesn't > > > > seem to be a "mandatory to implement" integration with any of > > > > the other > > > > infrastructures mentioned in the draft (e.g., Kerberos or > > > > Radius), or the > > > > WG charter (e.g. TACACS+, X.509 Certificates, LDAP, Diameter). > > > > The references to any sort of AAA are very generic, (probably > > > > by design, > > > > knowing the authors) but we need to nail down just what this >stuff > > > > talks to in order to know how to answer the fundamental >question: > > > > Does this proposal provide sufficient integration with > > > > existing infrastuctures > > > > to satisfy the operational needs that triggered formation of >this > > >WG? > > > > > > > > Randy > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > > >_______________________________________________ > > >Isms mailing list > > >Isms@lists.ietf.org > > >https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 20:00:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MyP-0008Bt-Hs; Thu, 11 Aug 2005 20:00:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3MyO-0008Bl-CN for isms@megatron.ietf.org; Thu, 11 Aug 2005 20:00:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07450 for ; Thu, 11 Aug 2005 20:00:31 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3NWm-0005cK-Nj for isms@ietf.org; Thu, 11 Aug 2005 20:36:06 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7C00L8l011016; Fri, 12 Aug 2005 00:00:21 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7C00JYj010281; Fri, 12 Aug 2005 00:00:21 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005081117002114476 ; Thu, 11 Aug 2005 17:00:21 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 17:00:21 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 17:00:20 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 Aug 2005 20:00:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Thu, 11 Aug 2005 19:56:01 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901A5EB68@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWewajuZxZ3PmsuTnqym74EbTOD3gABiF1gAADML0AAAJwEkAAArZ2g From: "Blumenthal, Uri" To: , "Kaushik Narayan" X-OriginalArrivalTime: 12 Aug 2005 00:00:18.0167 (UTC) FILETIME=[D314D070:01C59ED0] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Naw, I'm outta here.=20 -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Thursday, August 11, 2005 7:38 PM To: Blumenthal, Uri; 'Kaushik Narayan' Cc: isms@ietf.org Subject: RE: [Isms] charter proposal > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >=20 > So one needs glue not between SNMP and SSH - but between > SNMP and local accounts (accessible via SSH). So are you volunteering to document how this mapping could be achieved? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 20:28:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NPi-0005mD-LO; Thu, 11 Aug 2005 20:28:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3NPg-0005m8-IQ for isms@megatron.ietf.org; Thu, 11 Aug 2005 20:28:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08555 for ; Thu, 11 Aug 2005 20:28:42 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3Ny4-0006U5-SO for isms@ietf.org; Thu, 11 Aug 2005 21:04:18 -0400 Received: from h-68-165-6-176.snvacaid.dynamic.covad.net ([68.165.6.176] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3NPV-0004VL-00 for isms@ietf.org; Thu, 11 Aug 2005 20:28:33 -0400 Message-ID: <000401c59ed4$ee2fe9e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <6.2.0.14.0.20050811144239.03cedd00@email.cisco.com> <40qjma$34dgr9@sj-inbound-e.cisco.com> <6.2.0.14.0.20050811162216.03d4d550@email.cisco.com> Subject: Re: [Isms] charter proposal Date: Thu, 11 Aug 2005 17:29:39 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Kaushik Narayan" > To: > Cc: "'Randy Presuhn'" ; > Sent: Thursday, August 11, 2005 4:43 PM > Subject: RE: [Isms] charter proposal ... > At 04:17 PM 8/11/2005, David B Harrington wrote: > >Hi Kaushik, > > > >USM expects shared key management to be done via SNMPv3, and > >application vendors don't allow their applications to be managed via > >SNMP. So while you can try to synchronize the keys across multiple > >managed devices using SNMP, you cannot synchronize the keys used by > >the applications using SNMP. > > > I am not sure about what you mean by "keys used by applications". I The USM authentication and privacy keys. > am assuming you are referring to keys used to protect communication > channels used by the applications such from a web browser/client or between > application servers in a distributed model. Well most of these keys tend ... No. The keys used for SNMPv3. > In terms of integrated security it is important that the same username/password > is used south bound from the NMS applications going to the device as > used in gaining access to the NMS itself. USM tries to avoid that through key localization. Otherwise, compromise of a single managed device would compromize all other devices accessible by that user. > >Changing to a different security model, you might be able to > >synchronize the keys across multiple managed devices using RADIUS, or > >TACACS+, or Kerberos, or PKI, but can you manage the keys used by the > >NMS applications? > > > Again I think the key management is a bit of a red herring unless we are > talking about different "keys" here. ... I fail to see how key management is a "red herring" when it is one of the key complaints about the deployability of SNMPv3. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 11 21:28:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3OLr-0001jw-Kf; Thu, 11 Aug 2005 21:28:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3OLq-0001iI-2C for isms@megatron.ietf.org; Thu, 11 Aug 2005 21:28:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11143 for ; Thu, 11 Aug 2005 21:28:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3OuG-00083H-C1 for isms@ietf.org; Thu, 11 Aug 2005 22:04:24 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 11 Aug 2005 18:28:41 -0700 X-IronPort-AV: i="3.96,101,1122879600"; d="scan'208"; a="331519684:sNHT30892184" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7C1SWQN003309; Thu, 11 Aug 2005 18:28:33 -0700 (PDT) Message-Id: <6.2.0.14.0.20050811181642.03fbe7f8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 11 Aug 2005 18:28:37 -0700 To: randy_presuhn@mindspring.com From: Kaushik Narayan Subject: Re: Fwd: Re: [Isms] charter proposal In-Reply-To: <20050812011623.89466.qmail@web31013.mail.mud.yahoo.com> References: <20050812011623.89466.qmail@web31013.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Randy, I am sorry I was completely confused about what we were discussing. I understand USM, key localization and why we need key management in SNMPv3. From David's message, it seemed that David was referring to "keys used by applications" which I understood to be a set of keys that applications use for their own protection and have nothing to do with SNMPv3. That's reason I wasn't sure about need to synchronize keys on the agent to keys "used" by the application. In case David was referring to how we could get multiple NMS applications to share keys that use to talk SNMP agents, that really is an application implementation and in most cases we should be able to share the keys in case there is a common SNMP transport infrastructure shared by these applications. In large part most NMS applications including HPOV have the capability to refer to a shared local credential store. regards, kaushik! >Hi - > > > From: "Kaushik Narayan" > > To: > > Cc: "'Randy Presuhn'" ; > > Sent: Thursday, August 11, 2005 4:43 PM > > Subject: RE: [Isms] charter proposal >... > > At 04:17 PM 8/11/2005, David B Harrington wrote: > > >Hi Kaushik, > > > > > >USM expects shared key management to be done via SNMPv3, and > > >application vendors don't allow their applications to be managed via > > >SNMP. So while you can try to synchronize the keys across multiple > > >managed devices using SNMP, you cannot synchronize the keys used by > > >the applications using SNMP. > > > > > > I am not sure about what you mean by "keys used by applications". I > >The USM authentication and privacy keys. > > > am assuming you are referring to keys used to protect communication > > channels used by the applications such from a web browser/client or between > > application servers in a distributed model. Well most of these keys tend >... > >No. The keys used for SNMPv3. > > > In terms of integrated security it is important that the same > username/password > > is used south bound from the NMS applications going to the device as > > used in gaining access to the NMS itself. > >USM tries to avoid that through key localization. Otherwise, compromise of >a single managed device would compromize all other devices accessible >by that user. > > > >Changing to a different security model, you might be able to > > >synchronize the keys across multiple managed devices using RADIUS, or > > >TACACS+, or Kerberos, or PKI, but can you manage the keys used by the > > >NMS applications? > > > > > > Again I think the key management is a bit of a red herring unless we are > > talking about different "keys" here. >... > >I fail to see how key management is a "red herring" when it is one of the >key complaints about the deployability of SNMPv3. > >Randy > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 11:39:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bdA-0003yi-5Y; Fri, 12 Aug 2005 11:39:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bd8-0003yd-M0 for isms@megatron.ietf.org; Fri, 12 Aug 2005 11:39:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01698 for ; Fri, 12 Aug 2005 11:39:31 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cBe-0005AP-BB for isms@ietf.org; Fri, 12 Aug 2005 12:15:16 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E3E55E0049; Fri, 12 Aug 2005 11:39:19 -0400 (EDT) To: Subject: Re: [Isms] Limited time to charter References: <200508112334.j7BNYkk0020021@fort-point-station.mit.edu> From: Sam Hartman Date: Fri, 12 Aug 2005 11:39:19 -0400 In-Reply-To: <200508112334.j7BNYkk0020021@fort-point-station.mit.edu> (David B. Harrington's message of "Thu, 11 Aug 2005 19:34:38 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Limited@ietf.org, time@mit.edu, isms@ietf.org, charter@mit.edu, to@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org This is very much an individual opinion. The only thing close to this I would say as an AD is to make sure your architecture is not over specified to the point where it makes implementation difficult. For example I would say that requiring implementation of specific APIs would be actively harmful. But the rest of this message is just my personal thoughts. >>>>> "David" == David B Harrington writes: David> Hi, So do we have any volunteers to work on documenting how David> SSH authenticates its users using RADIUS or Kerberos, and David> makes the model (e.g. RADIUS), user (user-auth), and level David> (authentication and encryption services) accessible in a David> standard manner within SSH, or in an SSH-API for protocols David> using SSH services? I'm not entirely sure that's necessary. Traditionally outside of a few limited areas the IETF has not discussed implementation details like how one subsystem (such as the ssh radius plugin) makes information available to another subsystem (the snmp ssh subsystem). There are a few exceptions to this and I'll note that SNMP is traditionally one of these exceptions. If you can find someone to do this work and if they manage to do so in a way that does not limit what ssh implementations you can use or overly constrain implementation then that will be a good result. However in order to succeed at a standardization level, you don't quite need that. I think all you need is documents describing bits on the wire and an applicability statement (in the strict sense of section 3.2 of RFC 2026) describing required to implement behavior. In particular, I think the minimum set of documens you would need is: * Mapping describing how ssh is used between the two snmp engines * Mapping describing what radius attributes are used to populate securityname and other SNMP parameters * Document describing the ssh security model; probably this can be folded in as part of the first document. This document allows for the securityname to be mapped and points to the radius document as an example of how one does it in a radius environment. Discusses mapping to level; if ssh is used as it traditionally is used, everything maps to authpriv. Otherwise specify level in terms of the over the wire ssh behavior. * An applicability statement that sets up reasonable mandatory to implement methods. You'll probably want to require radius support although of course that is a WG decision. In particular I don't think you need a document describing how ssh authenticates via radius, although as I discuss I do think you will need documentation of how authorization information is obtained from radius. Note that's what I think you will need to succeed at a standards level. Your implementers may need more guidance to actually implement the standards. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 11:52:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bpU-0008EM-Fu; Fri, 12 Aug 2005 11:52:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3bpT-0008EC-3t for isms@megatron.ietf.org; Fri, 12 Aug 2005 11:52:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02273 for ; Fri, 12 Aug 2005 11:52:16 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3cNg-0005Wk-3F for isms@ietf.org; Fri, 12 Aug 2005 12:28:01 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7CFpuZC001616 for ; Fri, 12 Aug 2005 11:51:56 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Aug 2005 11:51:56 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Aug 2005 11:51:56 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 11:51:56 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 11:51:55 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324DD@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Limited time to charter Thread-Index: AcWfVDv4snUuZNP6TDiYRfl/A/CXQwAARVNw From: "Nelson, David" To: X-OriginalArrivalTime: 12 Aug 2005 15:51:56.0218 (UTC) FILETIME=[C42BF9A0:01C59F55] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:71.9075 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > In particular, I think the minimum set of documents you would need is: >=20 > * Mapping describing how ssh is used between the two snmp engines >=20 > * Mapping describing what radius attributes are used to populate > securityname and other SNMP parameters >=20 > * Document describing the ssh security model; probably this can be > folded in as part of the first document. This document allows for > the securityname to be mapped and points to the radius document as > an example of how one does it in a radius environment. Discusses > mapping to level; if ssh is used as it traditionally is used, > everything maps to authpriv. Otherwise specify level in terms of > the over the wire ssh behavior. >=20 > * An applicability statement that sets up reasonable mandatory to > implement methods. You'll probably want to require radius support > although of course that is a WG decision. That sounds like the correct list of documents, to me. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 12:56:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cpe-0001X9-8f; Fri, 12 Aug 2005 12:56:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3cpc-0001X4-Q6 for isms@megatron.ietf.org; Fri, 12 Aug 2005 12:56:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05681 for ; Fri, 12 Aug 2005 12:56:29 -0400 (EDT) Message-Id: <200508121656.MAA05681@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dOB-0007Nm-4T for isms@ietf.org; Fri, 12 Aug 2005 13:32:15 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <20050812165621014009r68ge>; Fri, 12 Aug 2005 16:56:22 +0000 From: "David B Harrington" To: "'Sam Hartman'" Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 12:56:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWfVAf8j5qfn7GCSbqRzY/5Jig7kgABb9KA X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Content-Transfer-Encoding: 7bit Cc: Limited@ietf.org, time@mit.edu, isms@ietf.org, charter@mit.edu, to@mit.edu X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Comments inline. > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Friday, August 12, 2005 11:39 AM > To: ietfdbh@comcast.net > Cc: isms@ietf.org; Limited@ietf.org; time@mit.edu; > to@mit.edu; charter@mit.edu > Subject: Re: [Isms] Limited time to charter > > > This is very much an individual opinion. The only thing close to this > I would say as an AD is to make sure your architecture is not over > specified to the point where it makes implementation difficult. For > example I would say that requiring implementation of specific APIs > would be actively harmful. I agree. I'm not looking for APIs; I'm, looking for the source of the data that needs to be mapped to the SNMP concepts securityModel, securityName, and securityLevel. > But the rest of this message is just my > personal thoughts. > > > >>>>> "David" == David B Harrington writes: > > David> Hi, So do we have any volunteers to work on documenting how > David> SSH authenticates its users using RADIUS or Kerberos, and > David> makes the model (e.g. RADIUS), user (user-auth), and level > David> (authentication and encryption services) accessible in a > David> standard manner within SSH, or in an SSH-API for protocols > David> using SSH services? > I'm not entirely sure that's necessary. Traditionally outside of a > few limited areas the IETF has not discussed implementation details > like how one subsystem (such as the ssh radius plugin) makes > information available to another subsystem (the snmp ssh subsystem). > There are a few exceptions to this and I'll note that SNMP is > traditionally one of these exceptions. > > > If you can find someone to do this work and if they manage to do so in > a way that does not limit what ssh implementations you can use or > overly constrain implementation then that will be a good result. > > However in order to succeed at a standardization level, you don't > quite need that. I think all you need is documents describing bits on > the wire and an applicability statement (in the strict sense of > section 3.2 of RFC 2026) describing required to implement behavior. > > In particular, I think the minimum set of documens you would need is: > > * Mapping describing how ssh is used between the two snmp engines Juergen S. and I have been working on the assumption that the TMSM document, or something similar, will describe how any transport-mapping can be used to work between engines, possibly including such issues as session management. > > * Mapping describing what radius attributes are used to > populate securityname and other SNMP parameters Is the RADIUS user authentication different from the SSH user authentication? It appears to me that in the SNMP-to-SSH mapping, securityName can be obtained from the user name contained in the SSH_MSG_USERAUTH_REQUEST message. This works for publickey, password, and host-based approaches. I don't see any mention of RADIUS in the "SSH Authentication Protocol" draft. If RADIUS is used to provide the SSH authentication, how do we get the username from RADIUS to pass via the SSH_MSG_USERAUTH_REQUEST into the SNMP engine? Or do we go directly to RADIUS to get the username, and if so does that also work for other backend authentication metyhods, such as publickey, password, and host-based or would every authentication method require its own user-mapping technique? Is there a document already in existence that describes how to use RADIUS for SSH user authentication? > > * Document describing the ssh security model; probably this can be > folded in as part of the first document. This document allows for > the securityname to be mapped and points to the radius document as > an example of how one does it in a radius environment. Discusses > mapping to level; if ssh is used as it traditionally is used, > everything maps to authpriv. Otherwise specify level in terms of > the over the wire ssh behavior. As I envision it, the securityName must be extracted somehow form the messages passed by the underlying protocol, such as from the SSH_MSG_USERAUTH_REQUEST. Extracting an SSH username will be different than extracting a TLS username, and different than extracting a SASL username, and so on, so I envision a different document for each, unless the work to be done for each is really minimal enough to fit into an appendix of the TMSM document. As you state, securityLevel may simply always be authpriv, but since SSH authentication can utilize different methods, do we need to *check* whether auth and priv are provided by the selected method? If so, how do we do this? In a programming world where support for dynamic link libraries or other dynamic add-ons, how do we know whether an add-on does or does not provide auth and priv? Is there something in the SSH standard that requires all add-ons to assert the securitylevel provided? The securityModel will probably be just a single one for the SSH security model, but we may need different securityModel identifiers depending on whether we use publickey or password or host-based or some other method of authentication, if that can affect how access control might be applied. If we do need this, then we need to know how to determine which authentication method was used and how to report that to the SNMP engine. > > * An applicability statement that sets up reasonable mandatory to > implement methods. You'll probably want to require radius > support although of course that is a WG decision. Agreed. > > > In particular I don't think you need a document describing how ssh > authenticates via radius, although as I discuss I do think you will > need documentation of how authorization information is obtained from > radius. Do you consider it within the current charter scope to discuss how authorization information is retrieved from RADIUS? Should we be trying to address this issue as well as the authentication issue in the new charter? > > > Note that's what I think you will need to succeed at a standards > level. Your implementers may need more guidance to actually implement > the standards. > > --Sam > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 13:27:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dJq-0001oj-Bc; Fri, 12 Aug 2005 13:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dJo-0001oW-GI for isms@megatron.ietf.org; Fri, 12 Aug 2005 13:27:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06995 for ; Fri, 12 Aug 2005 13:27:40 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3dsN-0008EM-1H for isms@ietf.org; Fri, 12 Aug 2005 14:03:27 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 96B03E0049; Fri, 12 Aug 2005 13:27:31 -0400 (EDT) To: References: <200508121656.j7CGuNG1009476@pacific-carrier-annex.mit.edu> From: Sam Hartman Date: Fri, 12 Aug 2005 13:27:31 -0400 In-Reply-To: <200508121656.j7CGuNG1009476@pacific-carrier-annex.mit.edu> (David B. Harrington's message of "Fri, 12 Aug 2005 12:56:14 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: isms@ietf.org Subject: [Isms] RADIUS ssh and ISMS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: >> * Mapping describing how ssh is used between the two snmp >> engines David> Juergen S. and I have been working on the assumption that David> the TMSM document, or something similar, will describe how David> any transport-mapping can be used to work between engines, David> possibly including such issues as session management. Agreed. >> * Mapping describing what radius attributes are used to >> populate securityname and other SNMP parameters David> Is the RADIUS user authentication different from the SSH David> user authentication? I don't know how to answer this. In general, if radius is being used by an ssh implementation, here is how it works. The ssh implementation will use password auth (or keyboard interactive) over the wire between the client and server. The server will turn this into a radius authentication request. The server may later get radius authorization information to for example confirm that the session is allowed at the current time. David> It appears to me that in the SNMP-to-SSH mapping, David> securityName can be obtained from the user name contained David> in the SSH_MSG_USERAUTH_REQUEST message. This works for David> publickey, password, and host-based approaches. People have argued on this list that that's not very deployable. In particular they believe you need to populate VACM entries for every ssh user who might use the system. Instead there has been some discussion of having the security model map the model-specific authentication name (the name in the userauth_request message for ssh) into some SNMP security name. The idea is that whatever central database is providing your authentication information might also want to provide securityname mapping. Then you would only need to consider VACM entries for the range (instead of domain) of that mapping. If you believe this is valuable you could create RADIUS attributes to store this information. If you just want to use the name from the userauth_request message as your securityname then you need say nothing about RADIUS, Kerberos or really any particular authentication method. David> I don't see any mention of RADIUS in the "SSH David> Authentication Protocol" draft. If RADIUS is used to David> provide the SSH authentication, how do we get the username David> from RADIUS to pass via the SSH_MSG_USERAUTH_REQUEST into David> the SNMP engine? Or do we go directly to RADIUS to get the David> username, and if so does that also work for other backend David> authentication metyhods, such as publickey, password, and David> host-based or would every authentication method require its David> own user-mapping technique? Is there a document already in David> existence that describes how to use RADIUS for SSH user David> authentication? Every backend would require its own mapping technique. Note that backends don't map well to ssh userauth mechanisms. For example the Kerberos backend can be used with password, keyboard interactive, gssapi-with-mic and gssapi-keyex user authentication methods. The RADIUS backend can be used with password and keyboard interactive. You could use LDAP with password, keyboard interactive, and publickey. >> * Document describing the ssh security model; probably this >> can be folded in as part of the first document. This document >> allows for the securityname to be mapped and points to the >> radius document as an example of how one does it in a radius >> environment. Discusses mapping to level; if ssh is used as it >> traditionally is used, everything maps to authpriv. Otherwise >> specify level in terms of the over the wire ssh behavior. David> As I envision it, the securityName must be extracted David> somehow form the messages passed by the underlying David> protocol, such as from the David> SSH_MSG_USERAUTH_REQUEST. Extracting an SSH username will David> be different than extracting a TLS username, and different David> than extracting a SASL username, and so on, so I envision a David> different document for each, unless the work to be done for David> each is really minimal enough to fit into an appendix of David> the TMSM document. I was hoping the working group would not define all these encapsulations unless there is actually a need to do so. David> As you state, securityLevel may simply always be authpriv, David> but since SSH authentication can utilize different methods, David> do we need to *check* whether auth and priv are provided by David> the selected method? If so, how do we do this? So, the SNMP level seems to refer more to per-packet protection than to properties of the authentication method. It is true that for per-packet protection you need certain minimum properties from the authentication method. Any authentication method that meets the requirements of the ssh architecture will give you these properties (mutual authentication and binding of keys seem to be all that is required). Then the only question for level is whether the channel is using confidentiality and whether the channel is using integrity. While ssh does support turning off confidentiality and integrity, it is strongly recommended that you never do so. Turning off confidentiality would violate the security assumptions of authentication methods like password. I would recommend simply requiring that ISMS uses of ssh keep confidentiality and integrity on and then define the level to be authpriv. Many ssh implementations don't even support turning off confidentiality or integrity even though it is allowed by the spec. David> The securityModel will probably be just a single one for David> the SSH security model, but we may need different David> securityModel identifiers depending on whether we use David> publickey or password or host-based or some other method of David> authentication, if that can affect how access control might David> be applied. If we do need this, then we need to know how to David> determine which authentication method was used and how to David> report that to the SNMP engine. I recommend a single security model. If you do something else, you make it harder for people to use new authentication methods with SNMP. That is undesirable. >> In particular I don't think you need a document describing how >> ssh authenticates via radius, although as I discuss I do think >> you will need documentation of how authorization information is >> obtained from radius. David> Do you consider it within the current charter scope to David> discuss how authorization information is retrieved from David> RADIUS? Should we be trying to address this issue as well David> as the authentication issue in the new charter? I believe that model-specific security name mapping is within scope. I believe that VACM population and other authorization information is out of scope. I'll certainly listen to arguments that expand the scope, although given our problems reaching consensus so far they would need to be very good. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 13:49:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3deS-0007fk-Ie; Fri, 12 Aug 2005 13:49:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3deQ-0007fc-DO for isms@megatron.ietf.org; Fri, 12 Aug 2005 13:49:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07872 for ; Fri, 12 Aug 2005 13:49:00 -0400 (EDT) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eCy-0000KC-4T for isms@ietf.org; Fri, 12 Aug 2005 14:24:45 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-siberian.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3deL-0007EJ-00 for isms@ietf.org; Fri, 12 Aug 2005 13:48:57 -0400 Message-ID: <001201c59f66$4c5beaa0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200508121656.j7CGuNG1009476@pacific-carrier-annex.mit.edu> Subject: Re: [Isms] RADIUS ssh and ISMS Date: Fri, 12 Aug 2005 10:50:15 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Sam Hartman" > To: > Cc: > Sent: Friday, August 12, 2005 10:27 AM > Subject: [Isms] RADIUS ssh and ISMS ... > I believe that model-specific security name mapping is within scope. > I believe that VACM population and other authorization information is > out of scope. I'll certainly listen to arguments that expand the > scope, although given our problems reaching consensus so far they > would need to be very good. ... Do you consider the user->group mapping to be out of scope, because it is associated with authorization? I strongly agree that delivery of the other information found in VACM should be out of scope, but I believe it would be a mistake to not address the user->group mapping. If the user->group mapping is not addressed, the isms solution would not be appreciably better than USM, from the perspective of when management systems would need to push security configuration information into the SNMP engines scattered about an administrative domain. Specifically, the only work "saved" would be for key updates. For user addition, removal, and re-categorization, there'd by no improvement. That doesn't sound like much of a win. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 13:50:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dfj-0007vU-UH; Fri, 12 Aug 2005 13:50:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dfi-0007uh-2w for isms@megatron.ietf.org; Fri, 12 Aug 2005 13:50:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07908 for ; Fri, 12 Aug 2005 13:50:20 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eEG-0000LW-4R for isms@ietf.org; Fri, 12 Aug 2005 14:26:05 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 12 Aug 2005 10:50:12 -0700 Received: from kaushik-w2k03.cisco.com (sjc-vpn5-582.cisco.com [10.21.90.70]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7CHo82j010607; Fri, 12 Aug 2005 10:50:09 -0700 (PDT) Message-Id: <6.2.0.14.0.20050812102702.03e3ffb8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 12 Aug 2005 10:50:08 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] Limited time to charter In-Reply-To: <200508121656.MAA05681@ietf.org> References: <200508121656.MAA05681@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Please find my reply inline > > > > * Mapping describing what radius attributes are used to > > populate securityname and other SNMP parameters > >Is the RADIUS user authentication different from the SSH user >authentication? > >It appears to me that in the SNMP-to-SSH mapping, securityName can be >obtained from the user name contained in the SSH_MSG_USERAUTH_REQUEST >message. This works for publickey, password, and host-based >approaches. > >I don't see any mention of RADIUS in the "SSH Authentication Protocol" >draft. If RADIUS is used to provide the SSH authentication, how do we >get the username from RADIUS to pass via the SSH_MSG_USERAUTH_REQUEST >into the SNMP engine? Or do we go directly to RADIUS to get the >username, and if so does that also work for other backend >authentication metyhods, such as publickey, password, and host-based >or would every authentication method require its own user-mapping >technique? Is there a document already in existence that describes how >to use RADIUS for SSH user authentication? > Most SSH implementations support user/password based authentication with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2. This is pretty standard RADIUS client behavior. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 14:16:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3e00-0004ai-Ek; Fri, 12 Aug 2005 14:11:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3dzy-0004XP-8O for isms@megatron.ietf.org; Fri, 12 Aug 2005 14:11:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08669 for ; Fri, 12 Aug 2005 14:11:16 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eYQ-0000q9-4I for isms@ietf.org; Fri, 12 Aug 2005 14:47:01 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7CIB8ZC005665 for ; Fri, 12 Aug 2005 14:11:08 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Aug 2005 14:11:08 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Aug 2005 14:11:08 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 14:11:08 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RADIUS ssh and ISMS Date: Fri, 12 Aug 2005 14:11:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E0@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RADIUS ssh and ISMS Thread-Index: AcWfY2ZhZ39OqAvER1qaLt/4p19nswABDKHw From: "Nelson, David" To: X-OriginalArrivalTime: 12 Aug 2005 18:11:08.0000 (UTC) FILETIME=[3638C600:01C59F69] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:99.8514 P:95.9108 R:95.9108 S: 7.3762 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > People have argued on this list that that's not very deployable. In > particular they believe you need to populate VACM entries for every > ssh user who might use the system. Instead there has been some > discussion of having the security model map the model-specific > authentication name (the name in the userauth_request message for ssh) > into some SNMP security name. The idea is that whatever central > database is providing your authentication information might also want > to provide securityname mapping. Then you would only need to consider > VACM entries for the range (instead of domain) of that mapping. >=20 > If you believe this is valuable you could create RADIUS attributes to > store this information. Greg Weber and I have previously created such a document. Reference http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-02.txt (note: -02 submitted just today). One RADIUS attribute described in this document that relates to the current thread is called Management-Policy-Id, and it is intended to aid in the mapping of an authenticated user identity (e.g. RADIUS User-Name) onto various access control mechanisms, of local scope to the managed entity. This could map to securityName as Sam has suggested, or it could map to a securityGroup, as Randy Presuhn suggested in another recent posting. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 14:16:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3e29-0004zW-Ma; Fri, 12 Aug 2005 14:13:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3e27-0004zL-GH for isms@megatron.ietf.org; Fri, 12 Aug 2005 14:13:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08738 for ; Fri, 12 Aug 2005 14:13:29 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3eaf-0000th-MP for isms@ietf.org; Fri, 12 Aug 2005 14:49:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D8ECBE0049; Fri, 12 Aug 2005 14:13:23 -0400 (EDT) To: "Randy Presuhn" Subject: Re: [Isms] RADIUS ssh and ISMS References: <200508121656.j7CGuNG1009476@pacific-carrier-annex.mit.edu> <001201c59f66$4c5beaa0$7f1afea9@oemcomputer> From: Sam Hartman Date: Fri, 12 Aug 2005 14:13:23 -0400 In-Reply-To: <001201c59f66$4c5beaa0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Fri, 12 Aug 2005 10:50:15 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Randy" == Randy Presuhn writes: Randy> Hi - >> From: "Sam Hartman" To: >> Cc: Sent: Friday, August >> 12, 2005 10:27 AM Subject: [Isms] RADIUS ssh and ISMS Randy> ... >> I believe that model-specific security name mapping is within >> scope. I believe that VACM population and other authorization >> information is out of scope. I'll certainly listen to >> arguments that expand the scope, although given our problems >> reaching consensus so far they would need to be very good. Randy> ... Randy> Do you consider the user->group mapping to be out of scope, Randy> because it is associated with authorization? Randy> I strongly agree that delivery of the other information Randy> found in VACM should be out of scope, but I believe it Randy> would be a mistake to not address the user->group mapping. Randy> If the user->group mapping is not addressed, the isms Randy> solution would not be appreciably better than USM, from the Randy> perspective of when management systems would need to push Randy> security configuration information into the SNMP engines Randy> scattered about an administrative domain. Specifically, Randy> the only work "saved" would be for key updates. For user Randy> addition, removal, and re-categorization, there'd by no Randy> improvement. That doesn't sound like much of a win. I actually think that allowing to remap securityname gives you most of the flexibility you need. You could create role accounts at the VACM level, add those to VACM groups, and then map encapsulated authentication to those role accounts. That said, group mapping may not be much more difficult than name mapping. I'm not sure whether it is in scope, but if the working group believes group mapping is required or can easily be done, I don't have a problem doing it. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 14:48:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eZu-0001DF-GD; Fri, 12 Aug 2005 14:48:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eZt-0001Cx-JL for isms@megatron.ietf.org; Fri, 12 Aug 2005 14:48:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10848 for ; Fri, 12 Aug 2005 14:48:23 -0400 (EDT) Message-Id: <200508121848.OAA10848@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3f8T-0001ys-0f for isms@ietf.org; Fri, 12 Aug 2005 15:24:09 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005081218481501400gan4pe>; Fri, 12 Aug 2005 18:48:15 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 14:48:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <6.2.0.14.0.20050812102702.03e3ffb8@email.cisco.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWfZkj907VW+tSoTrSgDETGn2bPxwAA7LYg X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Is there a document already in existence that describes how to use RADIUS for SSH user authentication? Or do we need to write one to document how to get the securityName information from RADIUS into SNMP? Do we need to go read the username from the SSH_MSG_USERAUTH_REQUEST to populate securityname? Do pretty-standard clients mirror the User-Name Attribute from the RADIUS Access-Request in the SSH_MSG_USERAUTH_REQUEST? Or do we need to go directly read the User-Name Attribute from the RADIUS Access-Request packet, because pretty-standard clients do not always mirror this? OR do we need to go directly read the User-Name Attribute from the RADIUS Access-Accept packet, since this MAY be different than the User-Name Attribute in the RADIUS Access-Request packet? According to RFC2865, we SHOULD use this if we were doing subsequent accounting request packets. Could we use this capability to provide a user-to-group mapping? Or do various accounting/business models differ too much from an SNMP access control model to make reuse of this field problematic? - The format of the username MAY be one of several forms: text Consisting only of UTF-8 encoded 10646 [7] characters. network access identifier A Network Access Identifier as described in RFC 2486 [8]. distinguished name A name in ASN.1 form used in Public Key authentication systems. Do we need to document the acceptable choices for use with SNMP? Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be useful for a command-line SNMP application, but what about something like HPOV where there isn't necessarily a human sitting at the management application when a scheduled poll occurs? Do we need to store the credentials at the management application to handle scheduled non-human polling, and do we then need to worry about key distribution to various applications (not to mention the possibility of somebody finding the credentials in the application datastore)? Are there pretty standard client approaches for this, for, say, scheduling CLI script retrieval of device configurations? How are these issues dealt with? Are these solutions documented somewhere? David Harrington dbharrington@comcast.net > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Friday, August 12, 2005 1:50 PM > To: ietfdbh@comcast.net > Cc: 'Sam Hartman'; isms@ietf.org > Subject: RE: [Isms] Limited time to charter > > Hi David, > > Please find my reply inline > > > > > > > > > > * Mapping describing what radius attributes are used to > > > populate securityname and other SNMP parameters > > > >Is the RADIUS user authentication different from the SSH user > >authentication? > > > >It appears to me that in the SNMP-to-SSH mapping, securityName can be > >obtained from the user name contained in the SSH_MSG_USERAUTH_REQUEST > >message. This works for publickey, password, and host-based > >approaches. > > > >I don't see any mention of RADIUS in the "SSH Authentication > Protocol" > >draft. If RADIUS is used to provide the SSH authentication, how do we > >get the username from RADIUS to pass via the SSH_MSG_USERAUTH_REQUEST > >into the SNMP engine? Or do we go directly to RADIUS to get the > >username, and if so does that also work for other backend > >authentication metyhods, such as publickey, password, and host-based > >or would every authentication method require its own user-mapping > >technique? Is there a document already in existence that > describes how > >to use RADIUS for SSH user authentication? > > > > > > Most SSH implementations support user/password based authentication > with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2. > This is pretty > standard RADIUS client behavior. > > regards, > kaushik! > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 14:53:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eeO-0002YN-Vo; Fri, 12 Aug 2005 14:53:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3eeM-0002WE-P2 for isms@megatron.ietf.org; Fri, 12 Aug 2005 14:53:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11086 for ; Fri, 12 Aug 2005 14:53:00 -0400 (EDT) Message-Id: <200508121853.OAA11086@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fCv-00027U-Bm for isms@ietf.org; Fri, 12 Aug 2005 15:28:46 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <20050812185251014009rlage>; Fri, 12 Aug 2005 18:52:52 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] RADIUS ssh and ISMS Date: Fri, 12 Aug 2005 14:52:47 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-reply-to: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E0@MAANDMBX2.ets.enterasys.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWfY2ZhZ39OqAvER1qaLt/4p19nswABDKHwAAHCEbA= X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Keep in mind that securityName is used not only when receiving a message, but also when generating outgoing messages to map to the security identity to be used in the sent message. So I'd be careful about overloading the purpose of securityName. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Friday, August 12, 2005 2:11 PM > To: isms@ietf.org > Subject: RE: [Isms] RADIUS ssh and ISMS > > Sam Hartman writes... > > > People have argued on this list that that's not very deployable. In > > particular they believe you need to populate VACM entries for every > > ssh user who might use the system. Instead there has been some > > discussion of having the security model map the model-specific > > authentication name (the name in the userauth_request > message for ssh) > > into some SNMP security name. The idea is that whatever central > > database is providing your authentication information might > also want > > to provide securityname mapping. Then you would only need > to consider > > VACM entries for the range (instead of domain) of that mapping. > > > > If you believe this is valuable you could create RADIUS > attributes to > > store this information. > > Greg Weber and I have previously created such a document. Reference > http://www.ietf.org/internet-drafts/draft-nelson-radius-manage > ment-autho > rization-02.txt (note: -02 submitted just today). One RADIUS > attribute > described in this document that relates to the current thread > is called > Management-Policy-Id, and it is intended to aid in the mapping of an > authenticated user identity (e.g. RADIUS User-Name) onto > various access > control mechanisms, of local scope to the managed entity. This could > map to securityName as Sam has suggested, or it could map to a > securityGroup, as Randy Presuhn suggested in another recent posting. > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 15:08:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3etB-0007p8-5z; Fri, 12 Aug 2005 15:08:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3etA-0007oz-3Z for isms@megatron.ietf.org; Fri, 12 Aug 2005 15:08:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12576 for ; Fri, 12 Aug 2005 15:08:17 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fRj-0002fm-SP for isms@ietf.org; Fri, 12 Aug 2005 15:44:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D678AE0049; Fri, 12 Aug 2005 15:08:09 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] RADIUS ssh and ISMS References: <200508121853.OAA11086@ietf.org> From: Sam Hartman Date: Fri, 12 Aug 2005 15:08:08 -0400 In-Reply-To: <200508121853.OAA11086@ietf.org> (David B. Harrington's message of "Fri, 12 Aug 2005 14:52:47 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Keep in mind that securityName is used not only when David> receiving a message, but also when generating outgoing David> messages to map to the security identity to be used in the David> sent message. So I'd be careful about overloading the David> purpose of securityName. Fine. My goal was simply to try and show how you might document and charter some of the proposals made so far, not trying to advocate any particular proposal. I remembered the securityname mapping proposal, but did not remember the group mapping proposal in enough detail. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 15:13:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ey6-0000MY-Qr; Fri, 12 Aug 2005 15:13:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ey4-0000MQ-Aj for isms@megatron.ietf.org; Fri, 12 Aug 2005 15:13:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13031 for ; Fri, 12 Aug 2005 15:13:22 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fWJ-0002m8-0S for isms@ietf.org; Fri, 12 Aug 2005 15:49:08 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7CJD0ZC007457 for ; Fri, 12 Aug 2005 15:13:00 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Aug 2005 15:13:01 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Aug 2005 15:13:01 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 15:13:01 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 15:13:00 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E1@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Limited time to charter Thread-Index: AcWfZkj907VW+tSoTrSgDETGn2bPxwAA7LYgAAF7UjA= From: "Nelson, David" To: X-OriginalArrivalTime: 12 Aug 2005 19:13:01.0500 (UTC) FILETIME=[DBA3E7C0:01C59F71] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:94.5022 P:95.9108 R:95.9108 S:57.8033 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David B Harrington writes... > Could we use this capability to provide a user-to-group mapping? Or do > various accounting/business models differ too much from an SNMP access > control model to make reuse of this field problematic? RADIUS allows a modified User-Name attribute to appear in an Access-Accept message, so that the identity used in subsequent accounting requests can be tailored in certain application environments. Note that this can cause problems with the "source routing" properties of an NAI contained in User-Name, when used in RADIUS Proxy environments, so a new RADIUS attribute is being standardized in the RADEXT WG, called Chargeable-User-Identity, that may supplant the practice of sending a modified User-Name in an Access-Accept.=20 > Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be > useful for a command-line SNMP application, but what about something > like HPOV where there isn't necessarily a human sitting at the > management application when a scheduled poll occurs? Any of these RADIUS authentication methods can [ultimately] use "static" usernames and passwords. If a management station is acting autonomously, it can inherit the credentials of a human entity, or it can be issued its own credentials as an application entity. > Do we need to store the credentials at the management application to > handle scheduled non-human polling, ... For PAP, CHAP and MSCHAPv2, the answer is yes. > ... and do we then need to worry about > key distribution to various applications=20 There will be a requirement to provision the applications with the authentication credentials. The encryption keys for the sessions (e.g. SSH) would not need to be statically provisioned (at least I do not believe so). > ... (not to mention the > possibility of somebody finding the credentials in the application > datastore)? That is a risk, of course. I think it is a risk whenever a non-human entity is being authenticated, unless the credentials are somehow encapsulated in tamper resistant hardware implementations. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 15:14:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ez4-0000ev-G1; Fri, 12 Aug 2005 15:14:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3ez3-0000en-2g for isms@megatron.ietf.org; Fri, 12 Aug 2005 15:14:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13158 for ; Fri, 12 Aug 2005 15:14:22 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3fXb-0002oq-Re for isms@ietf.org; Fri, 12 Aug 2005 15:50:09 -0400 Received: from h-64-105-34-177.snvacaid.dynamic.covad.net ([64.105.34.177] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E3eyw-0001q1-00 for isms@ietf.org; Fri, 12 Aug 2005 15:14:18 -0400 Message-ID: <001c01c59f72$38a2ab00$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200508121848.OAA10848@ietf.org> Subject: Re: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 12:15:36 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: "'Kaushik Narayan'" > Cc: "'Sam Hartman'" ; > Sent: Friday, August 12, 2005 11:48 AM > Subject: RE: [Isms] Limited time to charter ... Lots of questions deleted ... > The format of the username MAY be one of several forms: > > text Consisting only of UTF-8 encoded 10646 [7] characters. > > network access identifier > A Network Access Identifier as described in RFC 2486 > [8]. > > distinguished name > A name in ASN.1 form used in Public Key authentication > systems. > > Do we need to document the acceptable choices for use with SNMP? I believe the answer to this is YES, and that that's one reason why we'd be doing an applicability statement. > Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be > useful for a command-line SNMP application, but what about something > like HPOV where there isn't necessarily a human sitting at the > management application when a scheduled poll occurs? The operators are said to like scripts. What do they do? That should answer the question, and provide yet another reason for doing an applicability statement. There are far too many possible mechanisms; we need to trim the list down to the ones that we can make work and that will give us the best coverage of the infrastucture currently in use for management. > Do we need to store the credentials at the management application to > handle scheduled non-human polling, and do we then need to worry about > key distribution to various applications (not to mention the > possibility of somebody finding the credentials in the application > datastore)? Are there pretty standard client approaches for this, for, > say, scheduling CLI script retrieval of device configurations? How are > these issues dealt with? Are these solutions documented somewhere? ... I suspect it will look rather like the "local configuration datastore" :-) More seriously, it may be time to think about delegation. (But not in this WG!!!!) We started to look at it in disman, but the general sentiment of many WG members was that it made their heads hurt to go beyond the trivial forms we used in the disman MIBs. (This was *long* ago.) Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 16:41:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3gKu-0001O1-SU; Fri, 12 Aug 2005 16:41:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3gKr-0001N8-LP for isms@megatron.ietf.org; Fri, 12 Aug 2005 16:41:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00450 for ; Fri, 12 Aug 2005 16:40:58 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3gtQ-0001Fc-C6 for isms@ietf.org; Fri, 12 Aug 2005 17:16:45 -0400 Received: from pc6 (1Cust57.tnt27.lnd4.gbr.da.uu.net [62.188.154.57]) by galaxy.systems.pipex.net (Postfix) with SMTP id B42CEE000186; Fri, 12 Aug 2005 21:40:41 +0100 (BST) Message-ID: <04c801c59f75$8ac6c6c0$0601a8c0@pc6> From: "Tom Petch" To: , "Sam Hartman" References: Subject: Re: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 21:38:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org To quote from the Paris draft minutes (JQ) How is the current state of the WG. Hand waving on three approaches: TLS+SASL: 5 raised hands (including jabber) SSH: big majority in room BBEP: 7 raised hands (including jabber) >From this, I was expecting that the WG chairs would make a call on this list for support for the view in the meeting, so that at least some possible paths forward were eliminated. Tom Petch ----- Original Message ----- From: "Sam Hartman" To: Cc: ; ; ; Sent: Thursday, August 11, 2005 9:58 PM Subject: [Isms] Limited time to charter > > Hi, folks. > > I'd like to draw your attention to our remaining milestone: > > Aug 05 Working group will recharter to include publication goals > or shutdown if no consensus on a technical direction is reached by > this time > > August is fast passing us by and we don't have much time. > > I'd like to recommend to the chairs that they consider tools available > for increasing the speed of our discussion. In particular it may be > appropriate to set up conference calls, IM sessions or other more > realtime communications channels to work through issues. > > I know there had been some discussion of an interim meeting. So far, > I don't see that an interim meeting is all that likely to resolve the > types of concerns currently being discussed and so I am reluctant to > approve such a meeting. I will however consider proposals for such a > meeting particularly if people can explain what we could accomplish > with an interim that we are not accomplishing on the list. I will > probably not be able to attend the meeting myself because of limited > travel funding but could participate by phone. > > Keep in mind that interim meetings must be approved 30 days in advance > and that both Bert and I believe dragging things out past September is > unacceptable. > > While I remain optimistic that we can come to consensus, I must now > entertain the very real possibility that we will fail to come to > consensus. Please consider this message the formal consultation > required prior to termination of a working group under section 4 of > RFC 2418. At this time it is my opinion that absent an interim meeting > we must choose a technical direction by the close of August. If that > does not happen this working group will close. I will consider > changes in this time table but currently do not see circumstances > under which I'm likely to agree to such a change. > > > Sam Hartman > IETF Security Area Director > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 16:41:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3gKv-0001OQ-60; Fri, 12 Aug 2005 16:41:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3gKt-0001N9-47 for isms@megatron.ietf.org; Fri, 12 Aug 2005 16:41:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00453 for ; Fri, 12 Aug 2005 16:40:58 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3gtR-0001Fd-9X for isms@ietf.org; Fri, 12 Aug 2005 17:16:46 -0400 Received: from pc6 (1Cust57.tnt27.lnd4.gbr.da.uu.net [62.188.154.57]) by galaxy.systems.pipex.net (Postfix) with SMTP id CCB46E0001F0; Fri, 12 Aug 2005 21:40:45 +0100 (BST) Message-ID: <04c901c59f75$8bf4e680$0601a8c0@pc6> From: "Tom Petch" To: "Blumenthal, Uri" References: <3DEC199BD7489643817ECA151F7C592901A5EB50@pysmsx401.amr.corp.intel.com> Subject: Re: [Isms] charter proposal Date: Fri, 12 Aug 2005 21:38:42 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Blumenthal, Uri" To: ; "Kaushik Narayan" Cc: Sent: Friday, August 12, 2005 1:26 AM Subject: RE: [Isms] charter proposal I'm surprised to see SSH or TLS called "infrastructure". A. In case of SSH the infrastructure is local accounts. A clarification, if you will. Are you saying that user-authentication (ie client) is performed by passwords over a encrypted channel (as opposed to publickey or hostbased, the other two options listed in draft-ietf-secsh-userauth-27.txt). Tom Petch _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 17:28:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3h5B-0001Mz-Pq; Fri, 12 Aug 2005 17:28:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3h59-0001Mq-IZ for isms@megatron.ietf.org; Fri, 12 Aug 2005 17:28:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04142 for ; Fri, 12 Aug 2005 17:28:48 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3hdk-0002rp-9S for isms@ietf.org; Fri, 12 Aug 2005 18:04:36 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Aug 2005 14:28:42 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="331806532:sNHT32049308" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7CLSXQN022496; Fri, 12 Aug 2005 14:28:33 -0700 (PDT) Message-Id: <6.2.0.14.0.20050812142110.03e96f60@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 12 Aug 2005 14:28:38 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] Limited time to charter In-Reply-To: <40qjma$34lle0@sj-inbound-e.cisco.com> References: <6.2.0.14.0.20050812102702.03e3ffb8@email.cisco.com> <40qjma$34lle0@sj-inbound-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Cc: 'Sam Hartman' , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Support for RADIUS authentication for SSH is implementation specific. Most SSH implementations on Unix including OpenSSH support RADIUS/TACACS+ authentication via a Pluggable Authentication Module (PAM). http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Pluggable_Authentication_Module__PAM_.html PAM implementations are available for Linux and Solaris and there are a variety of supported PAM modules including RADIUS, TACACS+, Kerberos etc. http://www.kernel.org/pub/linux/libs/pam/modules.html I believe most SSH implementations on vendor equipment would be similar, i.e the SSH does not actually integrate with RADIUS, TACACS+ but that is done via an authentication module. regards, kaushik! At 11:48 AM 8/12/2005, David B Harrington wrote: >Is there a document already in existence that describes how >to use RADIUS for SSH user authentication? > >Or do we need to write one to document how to get the securityName >information from RADIUS into SNMP? > >Do we need to go read the username from the SSH_MSG_USERAUTH_REQUEST >to populate securityname? Do pretty-standard clients mirror the >User-Name Attribute from the RADIUS Access-Request in the >SSH_MSG_USERAUTH_REQUEST? > >Or do we need to go directly read the User-Name Attribute from the >RADIUS Access-Request packet, because pretty-standard clients do not >always mirror this? > >OR do we need to go directly read the User-Name Attribute from the >RADIUS Access-Accept packet, since this MAY be different than the >User-Name Attribute in the RADIUS Access-Request packet? According to >RFC2865, we SHOULD use this if we were doing subsequent accounting >request packets. > >Could we use this capability to provide a user-to-group mapping? Or do >various accounting/business models differ too much from an SNMP access >control model to make reuse of this field problematic? >- > >The format of the username MAY be one of several forms: > > text Consisting only of UTF-8 encoded 10646 [7] characters. > > network access identifier > A Network Access Identifier as described in RFC 2486 > [8]. > > distinguished name > A name in ASN.1 form used in Public Key authentication > systems. > >Do we need to document the acceptable choices for use with SNMP? > >Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be >useful for a command-line SNMP application, but what about something >like HPOV where there isn't necessarily a human sitting at the >management application when a scheduled poll occurs? > >Do we need to store the credentials at the management application to >handle scheduled non-human polling, and do we then need to worry about >key distribution to various applications (not to mention the >possibility of somebody finding the credentials in the application >datastore)? Are there pretty standard client approaches for this, for, >say, scheduling CLI script retrieval of device configurations? How are >these issues dealt with? Are these solutions documented somewhere? > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: Kaushik Narayan [mailto:kaushik@cisco.com] > > Sent: Friday, August 12, 2005 1:50 PM > > To: ietfdbh@comcast.net > > Cc: 'Sam Hartman'; isms@ietf.org > > Subject: RE: [Isms] Limited time to charter > > > > Hi David, > > > > Please find my reply inline > > > > > > > > > > > > > > > > * Mapping describing what radius attributes are used to > > > > populate securityname and other SNMP parameters > > > > > >Is the RADIUS user authentication different from the SSH user > > >authentication? > > > > > >It appears to me that in the SNMP-to-SSH mapping, securityName can >be > > >obtained from the user name contained in the >SSH_MSG_USERAUTH_REQUEST > > >message. This works for publickey, password, and host-based > > >approaches. > > > > > >I don't see any mention of RADIUS in the "SSH Authentication > > Protocol" > > >draft. If RADIUS is used to provide the SSH authentication, how do >we > > >get the username from RADIUS to pass via the >SSH_MSG_USERAUTH_REQUEST > > >into the SNMP engine? Or do we go directly to RADIUS to get the > > >username, and if so does that also work for other backend > > >authentication metyhods, such as publickey, password, and >host-based > > >or would every authentication method require its own user-mapping > > >technique? Is there a document already in existence that > > describes how > > >to use RADIUS for SSH user authentication? > > > > > > > > > > > Most SSH implementations support user/password based authentication > > with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2. > > This is pretty > > standard RADIUS client behavior. > > > > regards, > > kaushik! > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 17:38:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hEO-00041S-CH; Fri, 12 Aug 2005 17:38:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hEM-00041N-Lp for isms@megatron.ietf.org; Fri, 12 Aug 2005 17:38:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04466 for ; Fri, 12 Aug 2005 17:38:19 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3hmc-00033j-G5 for isms@ietf.org; Fri, 12 Aug 2005 18:14:07 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7CLbwZC012923 for ; Fri, 12 Aug 2005 17:37:58 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Aug 2005 17:37:59 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Aug 2005 17:37:59 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 17:37:59 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 17:37:58 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Limited time to charter Thread-Index: AcWfhS7BzWPPUH9dRqKDRVWH+HfAQQAAEBuQ From: "Nelson, David" To: X-OriginalArrivalTime: 12 Aug 2005 21:37:59.0375 (UTC) FILETIME=[1BFA4DF0:01C59F86] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:56.8584 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... > Most SSH implementations on Unix including OpenSSH support RADIUS/TACACS+ > authentication via a Pluggable Authentication Module (PAM). My cursory research this afternoon has led me to this same conclusion. One further question, however, is whether the PAM API would support provisioning of the user identity to access control mapping parameter (whether it be securityName or securityGroup). In other words, does PAM support Authorization in addition to Authentication? The last time I investigated PAM, it did not. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 17:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hKA-0005tn-OE; Fri, 12 Aug 2005 17:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hK8-0005ti-If for isms@megatron.ietf.org; Fri, 12 Aug 2005 17:44:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04683 for ; Fri, 12 Aug 2005 17:44:17 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3hsj-0003Dr-CF for isms@ietf.org; Fri, 12 Aug 2005 18:20:05 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2005 14:44:11 -0700 X-IronPort-AV: i="3.96,103,1122879600"; d="scan'208"; a="204569401:sNHT36023776" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7CLi82i022507; Fri, 12 Aug 2005 14:44:08 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 14:48:52 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905B61335@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] Limited time to charter Thread-Index: AcWfZkj907VW+tSoTrSgDETGn2bPxwAA7LYgAAa55GA= From: "Salowey, Joe" To: , "Narayan, Kaushik" X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: quoted-printable Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net]=20 > Sent: Friday, August 12, 2005 11:48 AM > To: Narayan, Kaushik > Cc: 'Sam Hartman'; isms@ietf.org > Subject: RE: [Isms] Limited time to charter >=20 >=20 > Is there a document already in existence that describes how=20 > to use RADIUS for SSH user authentication?=20 >=20 [Joe] No and its not clear that you would want one. SSH supports a number of authentication methods. The easiest to integrate with RADIUS is the username/password method which sends a clear text password. This can be used in RADIUS PAP, CHAP or MS-CHAP authentication. This mode of operation may have undesirable security properties since the password is available in cleartext to the SSH intermediaries. Other SSH user authentication methods do not have RADIUS support at this point, but it not clear that you would really want to support these in RADIUS (support could potentially be added by a GSS-API to EAP bridge mechanism, but that is probably beyond the scope of this group).=20 > Or do we need to write one to document how to get the=20 > securityName information from RADIUS into SNMP?=20 > [Joe] This would probably be a good idea. The definition of which attribute to use would be necessary. Perhaps the username attribute could be used in the access accept. =20 =20 > Do we need to go read the username from the=20 > SSH_MSG_USERAUTH_REQUEST to populate securityname? Do=20 > pretty-standard clients mirror the User-Name Attribute from=20 > the RADIUS Access-Request in the SSH_MSG_USERAUTH_REQUEST? >=20 > Or do we need to go directly read the User-Name Attribute=20 > from the RADIUS Access-Request packet, because=20 > pretty-standard clients do not always mirror this?=20 >=20 > OR do we need to go directly read the User-Name Attribute=20 > from the RADIUS Access-Accept packet, since this MAY be=20 > different than the User-Name Attribute in the RADIUS=20 > Access-Request packet? According to RFC2865, we SHOULD use=20 > this if we were doing subsequent accounting request packets.=20 >=20 [Joe] I would think it would be best to use the user name (or some other attribute) in the access-accept since this has actually been validated by the RADIUS server.=20 > Could we use this capability to provide a user-to-group=20 > mapping? Or do various accounting/business models differ too=20 > much from an SNMP access control model to make reuse of this=20 > field problematic? [Joe] It would seem that the use of SNMP is a separate matter. There are business and accounting models which require certain protection of the actual username so addition attributes have been proposed for carrying identity for charging users. Right now I don't think this would interact with SNMP uses.=20 >=20 > The format of the username MAY be one of several forms: >=20 > text Consisting only of UTF-8 encoded 10646 [7] characters. >=20 > network access identifier > A Network Access Identifier as described in RFC 2486 > [8]. >=20 > distinguished name > A name in ASN.1 form used in Public Key authentication > systems. >=20 > Do we need to document the acceptable choices for use with SNMP? >=20 [Joe} Some guidance on naming is necessary.=20 > Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP=20 > would be useful for a command-line SNMP application, but what=20 > about something like HPOV where there isn't necessarily a=20 > human sitting at the management application when a scheduled=20 > poll occurs?=20 >=20 [Joe] Note that these are only supported in RADIUS and not in SSH. So they are not really usable except as a back end mechanism that takes a cleartext password as input from the client.=20 > Do we need to store the credentials at the management=20 > application to handle scheduled non-human polling, and do we=20 > then need to worry about key distribution to various=20 > applications (not to mention the possibility of somebody=20 > finding the credentials in the application datastore)? Are=20 > there pretty standard client approaches for this, for, say,=20 > scheduling CLI script retrieval of device configurations? How=20 > are these issues dealt with? Are these solutions documented somewhere? >=20 > David Harrington > dbharrington@comcast.net >=20 > > -----Original Message----- > > From: Kaushik Narayan [mailto:kaushik@cisco.com] > > Sent: Friday, August 12, 2005 1:50 PM > > To: ietfdbh@comcast.net > > Cc: 'Sam Hartman'; isms@ietf.org > > Subject: RE: [Isms] Limited time to charter > >=20 > > Hi David, > >=20 > > Please find my reply inline > >=20 > > > >=20 > >=20 > > > > > > > > * Mapping describing what radius attributes are used to=20 > populate=20 > > > > securityname and other SNMP parameters > > > > > >Is the RADIUS user authentication different from the SSH user=20 > > >authentication? > > > > > >It appears to me that in the SNMP-to-SSH mapping, securityName can > be > > >obtained from the user name contained in the > SSH_MSG_USERAUTH_REQUEST > > >message. This works for publickey, password, and host-based=20 > > >approaches. > > > > > >I don't see any mention of RADIUS in the "SSH Authentication > > Protocol" > > >draft. If RADIUS is used to provide the SSH authentication, how do > we > > >get the username from RADIUS to pass via the > SSH_MSG_USERAUTH_REQUEST > > >into the SNMP engine? Or do we go directly to RADIUS to get the=20 > > >username, and if so does that also work for other backend=20 > > >authentication metyhods, such as publickey, password, and > host-based > > >or would every authentication method require its own user-mapping=20 > > >technique? Is there a document already in existence that > > describes how > > >to use RADIUS for SSH user authentication? > > > > >=20 > >=20 > >=20 > > Most SSH implementations support user/password based authentication=20 > > with a RADIUS server and support RADIUS PAP/CHAP/MSCHAPv2. > > This is pretty > > standard RADIUS client behavior. > >=20 > > regards, > > kaushik! > >=20 > >=20 > >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 17:46:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hLo-0006De-DU; Fri, 12 Aug 2005 17:46:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hLn-0006DZ-E2 for isms@megatron.ietf.org; Fri, 12 Aug 2005 17:46:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04764 for ; Fri, 12 Aug 2005 17:46:00 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3huN-0003HU-HU for isms@ietf.org; Fri, 12 Aug 2005 18:21:48 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 12 Aug 2005 14:45:53 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7CLjjZ2025599; Fri, 12 Aug 2005 14:45:51 -0700 (PDT) Message-Id: <6.2.0.14.0.20050812144449.03e85780@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 12 Aug 2005 14:45:44 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] Limited time to charter In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I am not aware of the PAM API supporting passing of module specific parameters. At 02:37 PM 8/12/2005, Nelson, David wrote: >Kaushik Narayan writes... > > > Most SSH implementations on Unix including OpenSSH support >RADIUS/TACACS+ > > authentication via a Pluggable Authentication Module (PAM). > >My cursory research this afternoon has led me to this same conclusion. >One further question, however, is whether the PAM API would support >provisioning of the user identity to access control mapping parameter >(whether it be securityName or securityGroup). In other words, does PAM >support Authorization in addition to Authentication? The last time I >investigated PAM, it did not. > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 12 17:52:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hS0-0007um-7M; Fri, 12 Aug 2005 17:52:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3hRy-0007ue-KL for isms@megatron.ietf.org; Fri, 12 Aug 2005 17:52:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05026 for ; Fri, 12 Aug 2005 17:52:23 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E3i0Y-0003QU-QF for isms@ietf.org; Fri, 12 Aug 2005 18:28:12 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA23947 for ; Fri, 12 Aug 2005 17:54:56 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma023936; Fri, 12 Aug 05 17:54:08 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 12 Aug 2005 17:51:36 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 12 Aug 2005 17:51:36 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Aug 2005 17:51:36 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Limited time to charter Date: Fri, 12 Aug 2005 17:51:35 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E5@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Limited time to charter Thread-Index: AcWfhzufXl9jZ3xhSZiDVdn+2ETLwgAADzTg From: "Nelson, David" To: X-OriginalArrivalTime: 12 Aug 2005 21:51:36.0625 (UTC) FILETIME=[0318C210:01C59F88] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:62.5509 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Kaushik Narayan writes... > I am not aware of the PAM API supporting passing of > module specific parameters. So I thought. This isn't a show-stopper, of course. It just means that some API enhancements would be required in the PAM module for {RADIUS, TACACS+, etc}. This would not affect any on-the-wire protocol. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 14 10:26:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JRr-0000XW-CT; Sun, 14 Aug 2005 10:26:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4JRp-0000XO-9g for isms@megatron.ietf.org; Sun, 14 Aug 2005 10:26:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28738 for ; Sun, 14 Aug 2005 10:26:46 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4K0j-0006HH-SJ for isms@ietf.org; Sun, 14 Aug 2005 11:02:56 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 14 Aug 2005 07:26:40 -0700 X-IronPort-AV: i="3.96,105,1122879600"; d="scan'208"; a="204733105:sNHT28972900" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7EEQZ2i024562 for ; Sun, 14 Aug 2005 07:26:36 -0700 (PDT) Received: from [212.254.247.4] (ams-clip-vpn-dhcp4340.cisco.com [10.61.80.243]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7EENG4U001428 for ; Sun, 14 Aug 2005 07:23:17 -0700 Message-ID: <42FF549A.1070605@cisco.com> Date: Sun, 14 Aug 2005 16:26:34 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=402; t=1124029397; x=1124461597; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:request=20for=20confirmation=20(or=20lack=20thereof)=20of=20the=20decisi ons=20made=0A=20at=20IETF63| From:Eliot=20Lear=20| Date:Sun,=2014=20Aug=202005=2016=3A26=3A34=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=JyCmhjYA2ZDSc4W9usbkk1lcy9zocLB7RuyMxJU5NMt4P3pnKxV3uTa7Rqb/suid/mwbtOHY 3lbsOGy7pxgnbb4zBjKB1Q6PldKQFtq1rRZgSH1RhTehnsIwhQQA9FVqSz83B3YP7Cu10/H0OwZ 2E4uPXWSUCIYLsJq9Dl9KEBA= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I would request that the chairs call for consensus on the points discussed at IETF 63. As I recall there were four major decisions: - discarding of UDP options - advancing of Juergen's architecture draft separately - creating an SSH draft - moving forward solely on the basis of that draft Perhaps others might disagree with my recollection. I'll not argue for or against in this message, but plan to do so on each of these questions as they are called (hopefully separately). Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 06:40:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOb-0003Ct-9r; Mon, 15 Aug 2005 06:40:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOZ-0003CN-V1 for isms@megatron.ietf.org; Mon, 15 Aug 2005 06:40:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25185 for ; Mon, 15 Aug 2005 06:40:41 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4cxh-0003NX-31 for isms@ietf.org; Mon, 15 Aug 2005 07:17:01 -0400 Received: from [192.168.1.116] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 3F0E81BACA3 for ; Mon, 15 Aug 2005 12:40:34 +0200 (CEST) Date: Mon, 15 Aug 2005 02:00:23 +0200 From: Juergen Quittek To: isms@ietf.org Subject: Re: [Isms] ISMS session summary and draft minutes Message-ID: In-Reply-To: References: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, There is another update of the minutes of our meeting with changes suggested by David Harrington and Bert Wijnen. Please find it at Thanks, Juergen --On 8/4/2005 3:31 PM +0200 Juergen Quittek wrote: > Dear all, > > Juergen Schoenwaelder sent a lot of comments on the > draft of the session minutes (Thanks a lot Juergen!). > Please find an updated version at > > > Please continue checking them and send your comments. > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de > > > --On 8/3/2005 6:25 PM +0200 Juergen Quittek wrote: > >> Dear all, >> >> Below please find a summary of our session yesterday. >> >> Please find the detailed draft minutes at >> . >> Many thanks to Martin for taking the minutes! >> >> We had a long discussion and probably not every statement was captured >> correctly in the minutes. Please check them. >> >> Thanks, >> >> Juergen >> -- >> Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 >> NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 >> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de >> >> >> =================================== >> IETF-63 ISMS Session Summary >> Tuesday August 2, 14:00 h - 16:00 h >> =================================== >> >> In April the WG achieved (very rough) consensus on using an >> encapsulated keying architecture (as used by the TLSM proposal). >> At this meeting the WG progressed the decision on a transport >> protocol to be used by ISMS. Candidate protocols were TLS+SASL, >> SSH, DTLS, and BEEP. >> >> Among the proposals, DTLS is the only one based on UDP. Since >> DTLS is not yet commonly deployed and not extensively tested, >> it was eliminated from the discussion after the WG agreed that >> UDP transport is not necessarily required for the ISMS solution. >> For all of the remaining three protocols there was support in >> the WG. Among them, SSH had clearly the strongest support, >> mainly, because SSH is already widely deployed and used in network >> management and thus could best achieve the goal of integrating the >> ISMS solution into existing security infrastructures. Within the >> session there was a consensus on choosing only one protocol as work >> item and there was rough consensus that this protocol would be SSH. >> The consensus still needs to be confirmed on the mailing list. >> >> Decisions made: >> - ISMS will work on one transport protocol only >> - Use SSH as transport protocol >> >> Action items: >> - confirm WG consensus on decisions on the mailing list (August) >> - draft new charter, discuss on mailing list (August) >> - start work on SSH-based solution >> >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 06:40:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOe-0003ER-Gb; Mon, 15 Aug 2005 06:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOb-0003DG-EC for isms@megatron.ietf.org; Mon, 15 Aug 2005 06:40:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25191 for ; Mon, 15 Aug 2005 06:40:42 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4cxi-0003Nk-FY for isms@ietf.org; Mon, 15 Aug 2005 07:17:02 -0400 Received: from [192.168.1.116] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 713471BACA4; Mon, 15 Aug 2005 12:40:35 +0200 (CEST) Date: Mon, 15 Aug 2005 02:34:07 +0200 From: Juergen Quittek To: Eliot Lear , isms@ietf.org Subject: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 Message-ID: In-Reply-To: <42FF549A.1070605@cisco.com> References: <42FF549A.1070605@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, Thanks for the request. As stated at the saag session, I think that the following decisions made the ISMS session need approval from the mailing list: 1. The ISMS WG will work on one transport protocol only 2. ISMS will use SSH as transport protocol These issues are not exactly the ones from your list, but they are targeting at the same direction and reflect the discussion at the Paris session. For 1. I am not aware of contrary opinions. I see consensus on 1. Anyone who disagrees, please speak up soon. For 2. there was a clear preference at the session. However, there were statements challenging this decision on the list, mainly from people in favor of BEEP. At the session there were also also people favoring TLS+SASL, but so far they did not express severe concerns on the mailing list about choosing SSH instead. Concerns were raised at the meeting that none of the alternatives (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an Internet draft (for BEEP we have the most detailed description) for making the decision. However, we need to make progress and arguments have been exchanged extensively. Therefore I ask particularly people who did not participate in the Paris session to express their concerns about ISMS using SSH as transport protocol. Thanks, Juergen --On 8/14/2005 4:26 PM +0200 Eliot Lear wrote: > Hi, > > I would request that the chairs call for consensus on the points > discussed at IETF 63. As I recall there were four major decisions: > > - discarding of UDP options > > - advancing of Juergen's architecture draft separately > > - creating an SSH draft > > - moving forward solely on the basis of that draft > > Perhaps others might disagree with my recollection. I'll not argue for > or against in this message, but plan to do so on each of these questions > as they are called (hopefully separately). > > Eliot > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 06:40:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOe-0003Eq-Lm; Mon, 15 Aug 2005 06:40:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cOc-0003EL-Mf for isms@megatron.ietf.org; Mon, 15 Aug 2005 06:40:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25210 for ; Mon, 15 Aug 2005 06:40:44 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4cxj-0003Nn-U0 for isms@ietf.org; Mon, 15 Aug 2005 07:17:04 -0400 Received: from [192.168.1.116] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A60CC1BAC9E; Mon, 15 Aug 2005 12:40:36 +0200 (CEST) Date: Mon, 15 Aug 2005 02:46:22 +0200 From: Juergen Quittek To: Tom Petch , isms@ietf.org, Sam Hartman Subject: Re: [Isms] Limited time to charter Message-ID: <7243FE27E9A10643A4E624BF@753F3B888A9969457862729D> In-Reply-To: <04c801c59f75$8ac6c6c0$0601a8c0@pc6> References: <04c801c59f75$8ac6c6c0$0601a8c0@pc6> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.6 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, I fully agree. I already stated at the SAAG meeting that we need approval from the list for this decision. Juergen --On 8/12/2005 9:38 PM +0200 Tom Petch wrote: > To quote from the Paris draft minutes > > (JQ) How is the current state of the WG. Hand waving on three approaches: > TLS+SASL: 5 raised hands (including jabber) > SSH: big majority in room > BBEP: 7 raised hands (including jabber) > >> From this, I was expecting that the WG chairs would make a call on this list for > support for the view in the meeting, so that at least some possible paths > forward > were eliminated. > > Tom Petch > > ----- Original Message ----- > From: "Sam Hartman" > To: > Cc: ; ; ; > Sent: Thursday, August 11, 2005 9:58 PM > Subject: [Isms] Limited time to charter > > >> >> Hi, folks. >> >> I'd like to draw your attention to our remaining milestone: >> >> Aug 05 Working group will recharter to include publication goals >> or shutdown if no consensus on a technical direction is reached by >> this time >> >> August is fast passing us by and we don't have much time. >> >> I'd like to recommend to the chairs that they consider tools available >> for increasing the speed of our discussion. In particular it may be >> appropriate to set up conference calls, IM sessions or other more >> realtime communications channels to work through issues. >> >> I know there had been some discussion of an interim meeting. So far, >> I don't see that an interim meeting is all that likely to resolve the >> types of concerns currently being discussed and so I am reluctant to >> approve such a meeting. I will however consider proposals for such a >> meeting particularly if people can explain what we could accomplish >> with an interim that we are not accomplishing on the list. I will >> probably not be able to attend the meeting myself because of limited >> travel funding but could participate by phone. >> >> Keep in mind that interim meetings must be approved 30 days in advance >> and that both Bert and I believe dragging things out past September is >> unacceptable. >> >> While I remain optimistic that we can come to consensus, I must now >> entertain the very real possibility that we will fail to come to >> consensus. Please consider this message the formal consultation >> required prior to termination of a working group under section 4 of >> RFC 2418. At this time it is my opinion that absent an interim meeting >> we must choose a technical direction by the close of August. If that >> does not happen this working group will close. I will consider >> changes in this time table but currently do not see circumstances >> under which I'm likely to agree to such a change. >> >> >> Sam Hartman >> IETF Security Area Director >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 06:57:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ceh-0005Oj-Gy; Mon, 15 Aug 2005 06:57:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4cef-0005Oe-Sz for isms@megatron.ietf.org; Mon, 15 Aug 2005 06:57:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25748 for ; Mon, 15 Aug 2005 06:57:19 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4dDl-0003hp-8g for isms@ietf.org; Mon, 15 Aug 2005 07:33:39 -0400 Received: from [192.168.1.116] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5B8E81BAC4D for ; Mon, 15 Aug 2005 12:57:10 +0200 (CEST) Date: Mon, 15 Aug 2005 12:57:04 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: <8DDEE4A4E051906C85215ABC@[192.168.1.116]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] ISMS charter discussion X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, In order to make progress concerning the charter, I suggest we agree on an outline in form of bullet items first and discuss elaborated text after we have consensus on the bullets. Below please find a summary of the recent charter discussion. Please note that the discussion assumes that the WG will achieve consensus on using SSH for transport. Items with questions marks were discussed without a clear result so far. Comments are highly appreciated, particularly if they constructively suggest concrete text modifications, such as replace bullet item A by bullet item B or replace text "..." by text ",,,". Thanks, Juergen ----------------------- ISMS WG charter outline ----------------------- Background - USM has limited deployment - no standard for integrating key and user management into deployed authentication infrastructures - SSH is widely deployed - SSH integration into AAA, e.g., Redius, is available WG goals - define a new SNMP security model that utilzes the SSH protocol to provide message security services for SNMP - compliancy with SNMPv3, no modification of SNMPv3 - work on new access control models and VACM mappings out of scope - open to further transport mappings, such as BEEP, TLS, ... ? mentions session concept ? ? mention user->group mapping via AAA ? ? authenticate user or command generator ? Work Items: - specify how transport mapping security models (TMSMs) fit into the SNMPv3 architecture - specify RADIUS attributes used to populate securityname and other SNMP parameters - define how to use SSH between the two snmp engines - specify the SSH security model for SNMP Documents - A document that specifies how transport mapping security models (TMSMs) fit into the SNMPv3 architecture and which defines the requirements for transport mapping security models. - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) - A document specifying the SSH security model for SNMP. This specification must comply with the TMSM requirements. - An Applicability statement that sets up reasonable mandatory to implement methods. ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it with the SSH transport model (or move RFC 3430 to historic) ? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 09:15:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4eoM-0006HJ-Gu; Mon, 15 Aug 2005 09:15:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4eoK-0006HE-CJ for isms@megatron.ietf.org; Mon, 15 Aug 2005 09:15:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02170 for ; Mon, 15 Aug 2005 09:15:27 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fNS-0006sr-4K for isms@ietf.org; Mon, 15 Aug 2005 09:51:47 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2005 06:15:17 -0700 X-IronPort-AV: i="3.96,107,1122879600"; d="scan'208"; a="654750016:sNHT30308092" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FDF9QM010232; Mon, 15 Aug 2005 06:15:10 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4137.cisco.com [10.61.80.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7FDBpIp005950; Mon, 15 Aug 2005 06:11:52 -0700 Message-ID: <43009562.2000009@cisco.com> Date: Mon, 15 Aug 2005 15:15:14 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: [Isms] ISMS session summary and draft minutes References: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=398; t=1124111513; x=1124543713; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20ISMS=20session=20summary=20and=20draft=20minutes| From:Eliot=20Lear=20| Date:Mon,=2015=20Aug=202005=2015=3A15=3A14=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=WDrNsLLsn24dUfPm6SnSPhmW8OkVHysJOcJYyJxPZq+lamL6kKkg9CkDI7/CAYq9iV4lBDZX WVZ9IBqOjsVW4e6oFLDXjz7mNkoCSP7U/3dfrYHW0oLYcy/sY+8ZHP9vpg9HyI+kqmJjJAvHZ9D pkn/eeXlgCLoMTPI/ikiSyTI= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, In the minutes, Sam Hartman is reported to have said the following: > (SH) Speaking as an AD, requiring to come one solution focusing the > effort. My recollection is that these were not Sam's words. My further recollection is that Sam said something closer to his "strong personal preference [for one solution]", but that he did NOT require the working group to come to consensus on one solution. Sam, am I correct or do the minutes correctly reflect what you said? Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 09:27:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4f0K-00083l-A1; Mon, 15 Aug 2005 09:27:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4f0I-00083d-Va for isms@megatron.ietf.org; Mon, 15 Aug 2005 09:27:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02612 for ; Mon, 15 Aug 2005 09:27:49 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4fZQ-00078j-PZ for isms@ietf.org; Mon, 15 Aug 2005 10:04:10 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2005 06:27:41 -0700 X-IronPort-AV: i="3.96,107,1122879600"; d="scan'208"; a="654751346:sNHT31486972" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7FDRcQM014424; Mon, 15 Aug 2005 06:27:38 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4137.cisco.com [10.61.80.40]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7FDOF58006025; Mon, 15 Aug 2005 06:24:16 -0700 Message-ID: <43009847.1060300@cisco.com> Date: Mon, 15 Aug 2005 15:27:35 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 References: <42FF549A.1070605@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1825; t=1124112256; x=1124544456; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20Call=20for=20consensus, =20was=3A=20[Isms]=20request=20for=20conf irmation=20(or=0A=20lack=20thereof)=20of=20the=20decisions=20made=20at=20IE TF63| From:Eliot=20Lear=20| Date:Mon,=2015=20Aug=202005=2015=3A27=3A35=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=aZGzNIQuBMgaZie7xvMkzMC8y8OAbT3/ebJrI2/svpd+Z6n37bmMLS6qd6JKIRQJeRUUY00O V1OkOheQk+aAHgTJum8bd2xdb/MV9+RaK31iE2EDkHu0C4soOrS3ijZAc5BSjEk3I6Y+vTO1qSN 5t8RKeplQGKn31aHVuC0Kfic= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen: Juergen Quittek wrote: > Eliot, > > Thanks for the request. > > As stated at the saag session, I think that the following decisions > made the ISMS session need approval from the mailing list: > > 1. The ISMS WG will work on one transport protocol only > > 2. ISMS will use SSH as transport protocol > > These issues are not exactly the ones from your list, but they > are targeting at the same direction and reflect the discussion > at the Paris session. > > For 1. I am not aware of contrary opinions. I see consensus on 1. > Anyone who disagrees, please speak up soon. I do. First, your use of the term "transport protocol" here is confusing. We agreed on several actions, one of which was dropping UDP, which is a transport (L4) protocol. I am neutral on whether we drop UDP at this time. If someone wants to work on it, I don't particularly mind, so long as they come to the table with a concrete proposal I can evaluate. In addition, I object to the idea that we are anywhere near prepared to eliminate ANY alternative given that today we have barely one (if one). We are also not in a position to compare "best" proposals. It is premature to eliminate ANY EK solution. > For 2. there was a clear preference at the session. However, > there were statements challenging this decision on the list, > mainly from people in favor of BEEP. At the session there > were also also people favoring TLS+SASL, but so far they did > not express severe concerns on the mailing list about choosing > SSH instead. > > Concerns were raised at the meeting that none of the alternatives > (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an > Internet draft (for BEEP we have the most detailed description) > for making the decision. In addition to these concerns, I also raised the concern that if this group chooses SSH where NETCONF has chosen BEEP for p2p/call home, we end up moving AWAY from our goal of integration of security management. > > However, we need to make progress and arguments have been exchanged > extensively. Juergen, the progress we need to make is on the drafts and not on deciding prematurely which one is best. So I ask that the group refute [1] and encourage further development on all drafts. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 10:43:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gB2-0001hX-VO; Mon, 15 Aug 2005 10:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gB0-0001hN-Iv for isms@megatron.ietf.org; Mon, 15 Aug 2005 10:42:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07006 for ; Mon, 15 Aug 2005 10:42:56 -0400 (EDT) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gk9-0000OU-Ax for isms@ietf.org; Mon, 15 Aug 2005 11:19:17 -0400 Received: from pc6 (1Cust114.tnt103.lnd4.gbr.da.uu.net [213.116.54.114]) by blaster.systems.pipex.net (Postfix) with SMTP id 16469E000083; Mon, 15 Aug 2005 15:42:40 +0100 (BST) Message-ID: <03a501c5a19f$035807e0$0601a8c0@pc6> From: "Tom Petch" To: "Randy Presuhn" , References: <200508121848.OAA10848@ietf.org> <001c01c59f72$38a2ab00$7f1afea9@oemcomputer> Subject: Re: [Isms] Limited time to charter Date: Mon, 15 Aug 2005 15:40:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Trimmed even more Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Friday, August 12, 2005 9:15 PM Subject: Re: [Isms] Limited time to charter > > From: "David B Harrington" > > To: "'Kaushik Narayan'" > > Cc: "'Sam Hartman'" ; > > Sent: Friday, August 12, 2005 11:48 AM > > Subject: RE: [Isms] Limited time to charter > ... > > Lots of questions deleted > ... > > The format of the username MAY be one of several forms: > > > > text Consisting only of UTF-8 encoded 10646 [7] characters. > > > > network access identifier > > A Network Access Identifier as described in RFC 2486 > > [8]. > > > > distinguished name > > A name in ASN.1 form used in Public Key authentication > > systems. > > > > Do we need to document the acceptable choices for use with SNMP? > > I believe the answer to this is YES, and that that's one reason why we'd be > doing an applicability statement. > > > Do we want to support PAP and CHAP and MSCHAPv2? I see CHAP would be > > useful for a command-line SNMP application, but what about something > > like HPOV where there isn't necessarily a human sitting at the > > management application when a scheduled poll occurs? > > The operators are said to like scripts. What do they do? That should > answer the question, and provide yet another reason for doing an applicability > statement. There are far too many possible mechanisms; we need to trim the > list down to the ones that we can make work and that will give us the best > coverage of the infrastucture currently in use for management. > I agree that we need an applicability statement, once we have an I-D specifying how to integrate SNMPv3 and our chosen Encapsulation Keying protocol. But .... we are slotting into a pre-existing environment where we seem to have little direct knowledge of which mechanisms are in use. I keep looking at the commonest current system, namely local accounts, and not knowing just what it means. Plain text passwords manually configured and sent in clear? I hope not (but know some enterprises that do just that). Plain text passwords fed into a system that generates one time session keys? .... I don't know and given the limited participation of operators in this list do not believe we can reliably find out. So I think our applicability statement needs to be catholic, spelling out the risks of the many different possibilities, rather than prescribing a limited selection of mechanisms as being the only ones and, in so doing, choosing ones that are not in widespread use. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 10:49:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gHj-0002Uz-UR; Mon, 15 Aug 2005 10:49:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4gHi-0002Uu-PC for isms@megatron.ietf.org; Mon, 15 Aug 2005 10:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07289 for ; Mon, 15 Aug 2005 10:49:50 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4gqo-0000YS-OK for isms@ietf.org; Mon, 15 Aug 2005 11:26:12 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id KAA22875 for ; Mon, 15 Aug 2005 10:52:18 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma022782; Mon, 15 Aug 05 10:51:47 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 15 Aug 2005 10:49:12 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 15 Aug 2005 10:49:12 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 15 Aug 2005 10:49:12 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS charter discussion Date: Mon, 15 Aug 2005 10:49:11 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS charter discussion Thread-Index: AcWhiDnPsHHfewIfRIWGGBLLnPTZqgAHrQ8Q From: "Nelson, David" To: X-OriginalArrivalTime: 15 Aug 2005 14:49:12.0437 (UTC) FILETIME=[8005D250:01C5A1A8] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:93.7606 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Quittek writes... Specific suggestions in-line, below (DBN). > ----------------------- > ISMS WG charter outline > ----------------------- >=20 > Background > - USM has limited deployment > - no standard for integrating key and user management into > deployed authentication infrastructures > - SSH is widely deployed > - SSH integration into AAA, e.g., Redius, is available DBN: - SSH integration into AAA, e.g., RADIUS, is available >=20 > WG goals > - define a new SNMP security model that utilzes the SSH protocol > to provide message security services for SNMP > - compliancy with SNMPv3, no modification of SNMPv3 DBN: - compliance with SNMPv3 architecture > - work on new access control models and VACM mappings out of scope DBN: - work on new access control models and VACM mappings out of scope (except for mapping via securityName or security Group, see below) > - open to further transport mappings, such as BEEP, TLS, ... > ? mentions session concept ? DBN: The concept of session is important, and could be easily supported via SSH. I think we need to mention it. > ? mention user->group mapping via AAA ? DBN: - define a standard method for mapping from AAA-provisioned authorization parameter(s) to SNMP securityName and securityGroup > ? authenticate user or command generator ? DBN: Are we talking about device authentication here? That is to say, non-human entity authentication? >=20 > Work Items: > - specify how transport mapping security models (TMSMs) > fit into the SNMPv3 architecture > - specify RADIUS attributes used to populate > securityName and other SNMP parameters DBN: I would specifically mention securityGroup here. > - define how to use SSH between the two snmp engines > - specify the SSH security model for SNMP >=20 > Documents > - A document that specifies how transport mapping security models > (TMSMs) fit into the SNMPv3 architecture and which defines the > requirements for transport mapping security models. > - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) > - A document specifying the SSH security model for SNMP. > This specification must comply with the TMSM requirements. > - An Applicability statement that sets up reasonable mandatory to > implement methods. > ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it > with the SSH transport model (or move RFC 3430 to historic) ? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 12:08:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hWF-000304-6W; Mon, 15 Aug 2005 12:08:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hWC-0002zx-Ut for isms@megatron.ietf.org; Mon, 15 Aug 2005 12:08:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10545 for ; Mon, 15 Aug 2005 12:08:54 -0400 (EDT) Received: from hosting.revelstone.com ([66.36.242.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4i5M-0002GW-8m for isms@ietf.org; Mon, 15 Aug 2005 12:45:17 -0400 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.50) id 1E4hVu-0002iu-SS for isms@ietf.org; Mon, 15 Aug 2005 12:08:38 -0400 Date: Mon, 15 Aug 2005 12:06:26 -0400 From: Robert Story To: isms@ietf.org Message-ID: <20050815120626.20a1f57b@aud> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.4.14; powerpc-yellowdog-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] ssh draft in progress? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org There were lots of volunteers at the Paris meeting to work on a ssh draft for further analysis. I was just wondering if they had gotten together and work was actually progressing. We are rapidly approaching our deadline... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 12:20:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hhk-0006RO-LX; Mon, 15 Aug 2005 12:20:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4hhj-0006RC-5o for isms@megatron.ietf.org; Mon, 15 Aug 2005 12:20:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11529 for ; Mon, 15 Aug 2005 12:20:48 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4iGs-0002kY-1y for isms@ietf.org; Mon, 15 Aug 2005 12:57:11 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9F52AE0049; Mon, 15 Aug 2005 12:20:04 -0400 (EDT) To: Kaushik Narayan References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.enterasys.com> <6.2.0.14.0.20050812144449.03e85780@email.cisco.com> From: Sam Hartman Date: Mon, 15 Aug 2005 12:20:04 -0400 In-Reply-To: <6.2.0.14.0.20050812144449.03e85780@email.cisco.com> (Kaushik Narayan's message of "Fri, 12 Aug 2005 14:45:44 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: isms@ietf.org Subject: [Isms] PAM and RADIUS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Kaushik" == Kaushik Narayan writes: Kaushik> I am not aware of the PAM API supporting passing of Kaushik> module specific parameters. pam_set_item, pam_get_item could be used for this. But you would need support from your module. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 13:09:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iSS-00066P-Nn; Mon, 15 Aug 2005 13:09:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4iSR-00066K-Ng for isms@megatron.ietf.org; Mon, 15 Aug 2005 13:09:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14556 for ; Mon, 15 Aug 2005 13:09:05 -0400 (EDT) Message-Id: <200508151709.NAA14556@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4j1Z-0004B4-GE for isms@ietf.org; Mon, 15 Aug 2005 13:45:28 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050815170854011000ot13e>; Mon, 15 Aug 2005 17:08:54 +0000 From: "David B Harrington" To: "'Robert Story'" , Subject: RE: [Isms] ssh draft in progress? Date: Mon, 15 Aug 2005 13:08:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050815120626.20a1f57b@aud> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWhtB85UxrnwmuWQXWGNv3R1LrfQwABIr7w X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Robert, Most volunteers did not want to have to worry about formatting the document and so on, so I have taken on the role of being primary editor. I have written an initial draft, filled in much of the boilerplate information and the introduction. I asked the SSH-knowledgeable volunteers to review RFC3411 and the TMSM document so we will all understand the SNMP requirements, and JuergenS and I have been studying the SSH documents and RADIUS documents so we can understand the capabilities/messages of these security protocols. I have organized the document sections indicating what needs to be discussed, using the USM Security Model RFC as a guideline, filled in much of the discussions about threats and security capabilities of the model, and identified which elements of procedure we will need to write for the model. I have, as best I could, started identifying the sources for the tmStateReference values. Obviously, I have also been trying to drive discussion of the "available integrations" of SSH and RADIUS so we could determine the best approach to extarcting values for securityname and other parameters from the SSH and RADIUS standards and implementation-assumptions. Many of the sections needed for the USM document are unnecessary because the topics are already discussed in the TMSM document (the best place since the issues would apply to all TMSM models). I have been expanding the TMSM document, and JuergenS has done a review of the current TMSM sources, made some adjustments there, and begun to set up a source control system so we can all contribute. I sent out the initial SSH Security Model draft to the other editors for review on Friday. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story > Sent: Monday, August 15, 2005 12:06 PM > To: isms@ietf.org > Subject: [Isms] ssh draft in progress? > > There were lots of volunteers at the Paris meeting to work on > a ssh draft for > further analysis. I was just wondering if they had gotten > together and work > was actually progressing. We are rapidly approaching our deadline... > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 13:19:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4icj-0007w2-HC; Mon, 15 Aug 2005 13:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4ici-0007vJ-Mj for isms@megatron.ietf.org; Mon, 15 Aug 2005 13:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15293 for ; Mon, 15 Aug 2005 13:19:42 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4jBt-0004X5-Et for isms@ietf.org; Mon, 15 Aug 2005 13:56:05 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B003A1BAC4D; Mon, 15 Aug 2005 19:19:32 +0200 (CEST) Date: Mon, 15 Aug 2005 19:18:56 +0200 From: Juergen Quittek To: Eliot Lear Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 Message-ID: In-Reply-To: <43009847.1060300@cisco.com> References: <42FF549A.1070605@cisco.com> <43009847.1060300@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, Thanks for your comments. Please see replies inline. --On 8/15/2005 3:27 PM +0200 Eliot Lear wrote: > Juergen: > > Juergen Quittek wrote: >> Eliot, >> >> Thanks for the request. >> >> As stated at the saag session, I think that the following decisions >> made the ISMS session need approval from the mailing list: >> >> 1. The ISMS WG will work on one transport protocol only >> >> 2. ISMS will use SSH as transport protocol >> >> These issues are not exactly the ones from your list, but they >> are targeting at the same direction and reflect the discussion >> at the Paris session. >> >> For 1. I am not aware of contrary opinions. I see consensus on 1. >> Anyone who disagrees, please speak up soon. > > I do. First, your use of the term "transport protocol" here is > confusing. Please suggest a better term. > We agreed on several actions, one of which was dropping UDP, > which is a transport (L4) protocol. I am neutral on whether we drop UDP > at this time. If someone wants to work on it, I don't particularly > mind, so long as they come to the table with a concrete proposal I can > evaluate. I think going for just one solution was unchallenged by WG members and I do not see this decision highly dependent on whether or not UDP was already eliminated or not. Do you really think that we should go for more than one solution? > In addition, I object to the idea that we are anywhere near prepared to > eliminate ANY alternative given that today we have barely one (if one). > We are also not in a position to compare "best" proposals. It is > premature to eliminate ANY EK solution. You say we cannot decide now. The ADs had good reasons for giving us a short-lived initial charter. According to the current (extended) one we can either agree or terminate. There is the chance of following Bert's recommendation to and extend the charter again until an interim meeting. This could create a better foundation for our decision, but the progress we can make until then is limited. I am sure that we could apply the same argument (the foundation for the decision is too weak) again at the interim meeting. Therefore I clearly prefer to make the decision now on an admittedly not 100% solid foundation. >> For 2. there was a clear preference at the session. However, >> there were statements challenging this decision on the list, >> mainly from people in favor of BEEP. At the session there >> were also also people favoring TLS+SASL, but so far they did >> not express severe concerns on the mailing list about choosing >> SSH instead. >> >> Concerns were raised at the meeting that none of the alternatives >> (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an >> Internet draft (for BEEP we have the most detailed description) >> for making the decision. > > In addition to these concerns, I also raised the concern that if this > group chooses SSH where NETCONF has chosen BEEP for p2p/call home, we > end up moving AWAY from our goal of integration of security management. > >> >> However, we need to make progress and arguments have been exchanged >> extensively. > > Juergen, the progress we need to make is on the drafts and not on > deciding prematurely which one is best. So I ask that the group refute > [1] and encourage further development on all drafts. The progress we need to make as WG is described by our charter saying | Aug 05=A0 Working group will recharter to include publication goals | or shutdown if no consensus on a technical direction is | reached by this time. Thanks, Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 13:52:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4j8L-0004Tj-Dz; Mon, 15 Aug 2005 13:52:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4j8J-0004Te-PB for isms@megatron.ietf.org; Mon, 15 Aug 2005 13:52:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16713 for ; Mon, 15 Aug 2005 13:52:22 -0400 (EDT) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4jhS-0005LW-Iu for isms@ietf.org; Mon, 15 Aug 2005 14:28:45 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA10023; Mon, 15 Aug 2005 10:51:57 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7FHqAs17991; Mon, 15 Aug 2005 10:52:10 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 15 Aug 2005 10:52:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] charter proposal Date: Mon, 15 Aug 2005 10:52:09 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBC88E@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] charter proposal Thread-Index: AcWeEQiP48xL7zdoQrijy8pq5mHVGwAXxBfwANQwTyA= From: "Fleischman, Eric" To: "Golovinsky, Eugene" , "Randy Presuhn" , X-OriginalArrivalTime: 15 Aug 2005 17:52:10.0040 (UTC) FILETIME=[0F2F1B80:01C5A1C2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Gene, I suspect that your customers may have concluded that the security gain of deploying SNMPv3 was not justifiable due to the increases in deployabilty expenses. However, there are likely to be a large number of differing reasons underlying that common conclusion. Perhaps some customers felt that their existing perimeter defenses made SNMP security redundant? Perhaps some felt that SNMPv3 security was much less secure than could be fiscally justified by the pricetag of deploying it? Certainly, that is the motivation underlying the deployments with which I am associated. Regardless, tying ISMS security to existing authentication infrastructures SHOULD (if done correctly) drastically change that cost equation by making the infrastructure cost of deploying SNMP security be significantly lessened. Thus, if ISMS does its job correctly, there should be a significantly lessened pricetag to deploying SNMP securely. --Eric -----Original Message----- From: Golovinsky, Eugene [mailto:Eugene_Golovinsky@bmc.com]=20 Sent: Thursday, August 11, 2005 5:37 AM To: Randy Presuhn; isms@ietf.org Subject: RE: [Isms] charter proposal My 2 cents of support to that notion. The fundamental problem with SNMPv3 is not security, but "deployability" and usability. Very few people in reality are using v3, although a lot of devices provide support for it. There is no really turn key operation and IT departments can not afford anymore army of admin staff doing manual configuration labor. SSH is hardly a solution to this issue. As long as we do not provide meaningful integration with already deployed infrastructure and easy initial deployment/configuration SNMPv3 will remain extremely secure :-), simply because nothing is going to be exposed through it :-) Over last 4 years I've been watching our customers becoming less and less curious about SNMPv3, to the point that almost nobody is asking about it anymore. What does it tell you? Is security really an issue?=20 --Gene =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 14:18:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jXE-00082M-JR; Mon, 15 Aug 2005 14:18:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4jXC-00082E-E0 for isms@megatron.ietf.org; Mon, 15 Aug 2005 14:18:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17645 for ; Mon, 15 Aug 2005 14:18:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4k6M-0005uQ-T7 for isms@ietf.org; Mon, 15 Aug 2005 14:54:28 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 14C24E0049; Mon, 15 Aug 2005 14:17:19 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] ISMS session summary and draft minutes References: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> <43009562.2000009@cisco.com> From: Sam Hartman Date: Mon, 15 Aug 2005 14:17:19 -0400 In-Reply-To: <43009562.2000009@cisco.com> (Eliot Lear's message of "Mon, 15 Aug 2005 15:15:14 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Juergen, In the minutes, Sam Hartman is reported to have Eliot> said the following: >> (SH) Speaking as an AD, requiring to come one solution focusing >> the effort. Eliot> My recollection is that these were not Sam's words. My Eliot> further recollection is that Sam said something closer to Eliot> his "strong personal preference [for one solution]", but Eliot> that he did NOT require the working group to come to Eliot> consensus on one solution. Eliot> Sam, am I correct or do the minutes correctly reflect what Eliot> you said? The minutes definitely do not reflect what I said; thanks for drawing this to my attention. As an AD, I think there needs to be one mandatory to implement solution. There can be other solutions, but that should be because there is a market demand for the other solutions or because the other solutions work in different environments. However if we have multiple solutions it needs to be because we believe multiple solutions are needed not because we are unable to make a decision between solutions. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 14:39:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4js4-0002B5-ED; Mon, 15 Aug 2005 14:39:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4js2-000282-Cx for isms@megatron.ietf.org; Mon, 15 Aug 2005 14:39:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18698 for ; Mon, 15 Aug 2005 14:39:36 -0400 (EDT) Message-Id: <200508151839.OAA18698@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4kRD-0006Oq-PW for isms@ietf.org; Mon, 15 Aug 2005 15:16:00 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050815183926012005ltmme>; Mon, 15 Aug 2005 18:39:26 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Eliot Lear'" Subject: RE: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of thedecisions made at IETF63 Date: Mon, 15 Aug 2005 14:39:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWhvY02RKG1RhLwQaGi3ojZb4WPdgACGl1w X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > > In addition, I object to the idea that we are anywhere near > prepared to > > eliminate ANY alternative given that today we have barely > one (if one). > > We are also not in a position to compare "best" proposals. It is > > premature to eliminate ANY EK solution. > > You say we cannot decide now. The ADs had good reasons for giving > us a short-lived initial charter. According to the current (extended) > one we can either agree or terminate. There is the chance of > following > Bert's recommendation to and extend the charter again until an interim > meeting. This could create a better foundation for our decision, but > the progress we can make until then is limited. I am sure that we > could apply the same argument (the foundation for the decision is too > weak) again at the interim meeting. Therefore I clearly prefer to > make the decision now on an admittedly not 100% solid foundation. I agree that it is simply too early to eliminate any options. But at the same time we need to agree on a WG direction to which we will commit our limited resources. My issue is largely with the wording. >From the Mirrriam-Webster dictionary: Eliminate "to cast out or get rid of : REMOVE, ERADICATE b : to set aside as unimportant : IGNORE" Focus "a center of activity, attraction, or attention b : a point of concentration" I believe the WG consensus is to FOCUS on one solution at this time, to determine whether it is a viable solution or not. SSH with a RADIUS backend appears to be the consensus of the WG as a solution to FOCUS our efforts on in the near future. This consensus appears to be based on the wide deployment of these protocols, the willingness of editors to produce written proposals, and to a lesser degree the compatibility with the Netconf decision to select SSH as their primary (application-transport) protocol. I do not believe we should eliminate/eradicate/remove/ignore the BEEP proposal, but it should be an area of secondary focus. We should not assign any working group resources to work on this proposal, but we should not discourage willing editors from producing such concrete proposals, and should not ban discussion of the secondary-focus concrete proposals from the mailing list of this WG because the difference between SSH and alternative proposals could prove to highlight some differences between the proposed solutions, as was the case in the Netconf WG. To put this into product-development terms, we should first assign engineers to work on releasing an SSH/RADIUS feature because that appears to have the greatest demand from customers, and, after we release the SSH/RADIUS solution, if customer demand proves sufficient to justify developing BEEP support as well, we could do so in a later release. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 15:34:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kij-0008Ik-Vn; Mon, 15 Aug 2005 15:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4kih-0008IU-Nv for isms@megatron.ietf.org; Mon, 15 Aug 2005 15:34:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22247 for ; Mon, 15 Aug 2005 15:34:02 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4lHs-0007jj-ON for isms@ietf.org; Mon, 15 Aug 2005 16:10:26 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id E41551BAC4D; Mon, 15 Aug 2005 21:33:50 +0200 (CEST) Date: Mon, 15 Aug 2005 21:33:49 +0200 From: Juergen Quittek To: Sam Hartman , Eliot Lear Subject: Re: [Isms] ISMS session summary and draft minutes Message-ID: <42591E2E3AA69824BC4F7E87@[192.168.0.112]> In-Reply-To: References: <9422A79CC398B1A9B9F745EA@open-25-41.ietf63.ietf.org> <43009562.2000009@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot and Sam, Thanks for the corrections. I will update the minutes accordingly. Juergen --On 8/15/2005 2:17 PM -0400 Sam Hartman wrote: > As an AD, I think there needs to be one mandatory to implement > solution. There can be other solutions, but that should be because > there is a market demand for the other solutions or because the other > solutions work in different environments. However if we have multiple > solutions it needs to be because we believe multiple solutions are > needed not because we are unable to make a decision between solutions. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 15 16:29:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4laS-0003y4-0a; Mon, 15 Aug 2005 16:29:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4laQ-0003xu-VR for isms@megatron.ietf.org; Mon, 15 Aug 2005 16:29:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03061 for ; Mon, 15 Aug 2005 16:29:33 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4m9c-0003SW-Gh for isms@ietf.org; Mon, 15 Aug 2005 17:05:57 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id EBF26E0049; Mon, 15 Aug 2005 16:28:54 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of thedecisions made at IETF63 References: <200508151839.OAA18698@ietf.org> From: Sam Hartman Date: Mon, 15 Aug 2005 16:28:54 -0400 In-Reply-To: <200508151839.OAA18698@ietf.org> (David B. Harrington's message of "Mon, 15 Aug 2005 14:39:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org As an AD, I would be uncomfortable with a charter that did not pick some direction to focus on. There are a lot of reasons for this. One is that we've been spending a lot of energy on this decision and it would concern me if we cannot at least decide on a direction after having spent this long thinking about it. Also, as David points out, we do have limited resources and I need to make sure that we commit to a task that I believe we can accomplish. So, I do think it is important that we focus on some mandatory to implement solution in our charter. I also think it is important that we identify such a solution at the time of chartering, although I am open to arguments why this is not the case. However I do understand David and Eliot's concerns. I would support a charter that focused on one direction but allowed for parallel development of alternatives. If we found that at some future time that the primary focus did not meet our needs we could recharter to change our focus. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 01:46:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4uHG-0008Ao-In; Tue, 16 Aug 2005 01:46:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4uHC-0008Ag-Fd for isms@megatron.ietf.org; Tue, 16 Aug 2005 01:46:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08344 for ; Tue, 16 Aug 2005 01:46:17 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E4uqT-00072O-Sn for isms@ietf.org; Tue, 16 Aug 2005 02:22:46 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 15 Aug 2005 22:46:07 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7G5k42i001905; Mon, 15 Aug 2005 22:46:04 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp132.cisco.com [10.61.64.132]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7G5gcET014617; Mon, 15 Aug 2005 22:42:39 -0700 Message-ID: <43017D9B.8040201@cisco.com> Date: Tue, 16 Aug 2005 07:46:03 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Juergen Quittek Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 References: <42FF549A.1070605@cisco.com> <43009847.1060300@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2546; t=1124170960; x=1124603160; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20Call=20for=20consensus, =20was=3A=20[Isms]=20request=20for=20conf irmation=20(or=0A=20lack=20thereof)=20of=20the=20decisions=20made=20at=20IE TF63| From:Eliot=20Lear=20| Date:Tue,=2016=20Aug=202005=2007=3A46=3A03=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=m9G8MjgNkhg3bxj89xtMC0MF4S2kJ7E/BMbetzw/ha4FrutQHBR4fTIgQKQ74O0uZKxsv+qX dqp3NxlRIjfbUbjJKvEXt6muHk5Q7yXu8UuGdhnkTpu0624QlZkbTfW/796wF+/orNhcUPDDMWl exHj45P99s3pmQz18GFDN0qE= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, Juergen Quittek wrote: > Please suggest a better term. I think simply distinguishing between UDP and TCP (which as you recall was one of the columns on the board at one point) and then the specific substrates (TLS, SSH, TLS/BEEP) would be sufficient. N.B., I think there was only one sketch of a proposal in the UDP column. > >> We agreed on several actions, one of which was dropping UDP, >> which is a transport (L4) protocol. I am neutral on whether we drop UDP >> at this time. If someone wants to work on it, I don't particularly >> mind, so long as they come to the table with a concrete proposal I can >> evaluate. > > > I think going for just one solution was unchallenged by WG members > and I do not see this decision highly dependent on whether or not > UDP was already eliminated or not. > Do you really think that we should go for more than one solution? Here I believe there was some confusion in the room (and I may have been one of the people confused). In the end, I would prefer one solution, as that is best for interoperability, as I believe one of the ADs mentioned in another contentious area. But we are not at the end, and this is the source of the confusion. Right now we are at a point where there is only one proposal on the table that we seem to have eliminated. Before we even consider knocking the number of proposals down to one, we should probably start with MORE than one. This has all the benefits I've previously mentioned to you. >> In addition, I object to the idea that we are anywhere near prepared to >> eliminate ANY alternative given that today we have barely one (if one). >> We are also not in a position to compare "best" proposals. It is >> premature to eliminate ANY EK solution. > > > You say we cannot decide now. The ADs had good reasons for giving > us a short-lived initial charter. Let's be careful not to conflate the need for a the charter revision with a choice of protocol. I believe the ADs should assist us in developing a viable charter that gets us to a point where we can decide amongst the choices. > > Therefore I clearly prefer to > make the decision now on an admittedly not 100% solid foundation. Think about this statement. This is the fundamental problem I have. We can and should do better than this. I've clearly stated a right hand / left hand problem with NETCONF and this group involving choice of substrates. I know that Bert stated his concern about which protocol is mandatory. I think both are problems that need to be addressed. As I said in the working group, we can do anything with either protocol. It's only a matter of bits. But if we do one thing where NETCONF did another, we're not doing a very good job of resource management either in the IETF or back in our companies, for that matter! > > The progress we need to make as WG is described by our charter saying > > | Aug 05 Working group will recharter to include publication goals > | or shutdown if no consensus on a technical direction is > | reached by this time. A viable consensus is to proceed to develop several choices from which we will choose one or more to be standardized. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 10:38:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52aE-0001jg-R0; Tue, 16 Aug 2005 10:38:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E52aC-0001jb-Nb for isms@megatron.ietf.org; Tue, 16 Aug 2005 10:38:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15481 for ; Tue, 16 Aug 2005 10:38:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E539W-0002w8-EB for isms@ietf.org; Tue, 16 Aug 2005 11:14:59 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7GEcFSb011437 for ; Tue, 16 Aug 2005 09:38:15 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Aug 2005 16:38:14 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D31FFD@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: isms@ietf.org Date: Tue, 16 Aug 2005 16:38:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [Isms] BEEP as a transport for X X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I saw some side conversations and polled for additional info. I got the following information on BEEP which I think will be good to know for this WG. Specifically, because (as far I have always understood the WG charter) the WG is trying to find a solution to allow SNMPv3 to be much better intergrated with (existing) operational security infrastructure. Bert -------------- fowarding with permission >From Andy Newton: >> >> The problem we faced in the CRISP working group is that BEEP >> was just too much for the simple request/response protocol >> we have developed. >> While there are new libraries now from both IBM and Apple >> which I have not had the chance to use, it seemed that most >> of the libraries we found were incomplete, out-and-out >> vaporware, or incredibly frustrating to understand from >> the API perspective. >> >> Now, if the question is "which is easier to implement, >> BEEP or SSH?" I'll bet that BEEP is the answer. >> But there are some pretty rock-solid implementations of >> SSH out there that surpass anything I have seen with BEEP. >> >> I like BEEP. I think it is a cool design. But the simple >> fact is that if your implementers want something easy to >> build or something easy to re-use, BEEP is not that (yet). >> >> -andy >> >From LEslie Daigle: >>>>> Subject: Arch....? Re: Notifications in LEMONADE >>>>> >>>>> So, BEEP is an interesting beast. >>>>> >>>>> *Architecturally*, it is the right direction. But, it is falling >>>>> down in reality because a) Marshall's attention moved on, and >>>>> b) the implementations are unwieldy. That is, if you don't >>>>> need all of the features of BEEP, finding your way into >>>>> the spottily-implemented and worse-documented libraries >>>>> is *ugly*. >>>>> >>>>> This, by the way, is why CRISP developed a non-BEEP tranport >>>>> for IRIS after the original BEEP one. And there have been >>>>> more implementations by key stakeholders *because* of that >>>>> change. >>>>> >>>>> Sigh. Sometimes the architecturally right thing gets undermined >>>>> by practical realities. >>>>> >>>>> Leslie. >>>>> _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 14:16:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55z3-0008LX-Pa; Tue, 16 Aug 2005 14:16:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E55z1-0008Kp-IM for isms@megatron.ietf.org; Tue, 16 Aug 2005 14:16:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26648 for ; Tue, 16 Aug 2005 14:16:17 -0400 (EDT) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56YP-0000Gl-Cj for isms@ietf.org; Tue, 16 Aug 2005 14:52:53 -0400 Received: from pc6 (1Cust58.tnt103.lnd4.gbr.da.uu.net [213.116.54.58]) by ranger.systems.pipex.net (Postfix) with SMTP id 48082E0001F0; Tue, 16 Aug 2005 19:15:55 +0100 (BST) Message-ID: <014101c5a285$f834ff20$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" , References: <42FF549A.1070605@cisco.com> Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of thedecisions made at IETF63 Date: Tue, 16 Aug 2005 19:09:29 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen (and your co-chair:-), I struggle with the way you do this. You ask for those who disagree with 1. The ISMS WG will work on one transport protocol only to speak up so the list will contain only or mostly contrary views. How then do you judge rough consensus on this if those in favour have not spoken? (I am in favour) Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: "Eliot Lear" ; Sent: Monday, August 15, 2005 2:34 AM Subject: Call for consensus,was: [Isms] request for confirmation (or lack thereof) of thedecisions made at IETF63 > Eliot, > > Thanks for the request. > > As stated at the saag session, I think that the following decisions > made the ISMS session need approval from the mailing list: > > 1. The ISMS WG will work on one transport protocol only > > 2. ISMS will use SSH as transport protocol > > These issues are not exactly the ones from your list, but they > are targeting at the same direction and reflect the discussion > at the Paris session. > > For 1. I am not aware of contrary opinions. I see consensus on 1. > Anyone who disagrees, please speak up soon. > > For 2. there was a clear preference at the session. However, > there were statements challenging this decision on the list, > mainly from people in favor of BEEP. At the session there > were also also people favoring TLS+SASL, but so far they did > not express severe concerns on the mailing list about choosing > SSH instead. > > Concerns were raised at the meeting that none of the alternatives > (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an > Internet draft (for BEEP we have the most detailed description) > for making the decision. > > However, we need to make progress and arguments have been exchanged > extensively. Therefore I ask particularly people who did not > participate in the Paris session to express their concerns about > ISMS using SSH as transport protocol. > > Thanks, > > Juergen > > --On 8/14/2005 4:26 PM +0200 Eliot Lear wrote: > > > Hi, > > > > I would request that the chairs call for consensus on the points > > discussed at IETF 63. As I recall there were four major decisions: > > > > - discarding of UDP options > > > > - advancing of Juergen's architecture draft separately > > > > - creating an SSH draft > > > > - moving forward solely on the basis of that draft > > > > Perhaps others might disagree with my recollection. I'll not argue for > > or against in this message, but plan to do so on each of these questions > > as they are called (hopefully separately). > > > > Eliot > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 14:32:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56EQ-00037X-Nd; Tue, 16 Aug 2005 14:32:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56EP-00037S-HI for isms@megatron.ietf.org; Tue, 16 Aug 2005 14:32:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27377 for ; Tue, 16 Aug 2005 14:32:11 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E56nS-0000ej-Ju for isms@ietf.org; Tue, 16 Aug 2005 15:08:47 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7GIVjZC005626 for ; Tue, 16 Aug 2005 14:31:45 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 16 Aug 2005 14:31:46 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 16 Aug 2005 14:31:46 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Aug 2005 14:31:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Aug 2005 14:31:45 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> Thread-Topic: Call for consensus Thread-Index: AcWijt8bmdTPbX4dQiSgXhbO9C4JIAAAMc2Q From: "Nelson, David" To: X-OriginalArrivalTime: 16 Aug 2005 18:31:46.0367 (UTC) FILETIME=[C1FF94F0:01C5A290] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:86.4395 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] RE: Call for consensus X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch writes... > I struggle with the way you do this. You ask for those who disagree > with 1. The ISMS WG will work on one transport protocol only > to speak up so the list will contain only or mostly contrary views. =20 > How then do you judge rough consensus on this if those in favour have=20 > not spoken? Asking for dissent is one valid method of sensing rough consensus. If only a few object, then it is very likely to be rough consensus in favor. OTOH, if you believe that the majority is undecided, has no strong opinion, or primarily consists of "lurkers" on the list, then a poll of the "yeas" and "nays" may be required. > (I am in favour) FWIW, so am I. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 16:08:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57jo-0005Hg-Ge; Tue, 16 Aug 2005 16:08:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E57jn-0005HS-Mo for isms@megatron.ietf.org; Tue, 16 Aug 2005 16:08:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05755 for ; Tue, 16 Aug 2005 16:08:41 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58JB-0004Bz-DX for isms@ietf.org; Tue, 16 Aug 2005 16:45:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2005 13:08:32 -0700 X-IronPort-AV: i="3.96,113,1122879600"; d="scan'208"; a="332791643:sNHT36544164" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7GK8OQM025062; Tue, 16 Aug 2005 13:08:25 -0700 (PDT) Received: from [212.254.247.5] (ams-clip-vpn-dhcp4459.cisco.com [10.61.81.106]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7GK52LF022610; Tue, 16 Aug 2005 13:05:02 -0700 Message-ID: <430247BC.9030601@cisco.com> Date: Tue, 16 Aug 2005 22:08:28 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=391; t=1124222703; x=1124654903; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Tue,=2016=20Aug=202005=2022=3A08=3A28=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=TGSzDzGt8xzQ2yQqo5XgCeuduWoCIKVdkLLu0UXVR0/iudjFIm/Q/gF46JcouOhVB6yrJsA7 0dQwb2b9ejSfwFihHri9AgLUcoLvBnrhOn2RkleCs9Wde3es2gO84aOVu6YwkSXX9zmYJ56+rij ANnsY0aqSkNNrMmLLSkz+lAc= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org For those who are in favor, it seems only fair that you answer the following questions: - why is it reasonable for ISMS diverge from the method that NETCONF has specified for "call home" functionality? - what should be done to resolve the differences? - If you claim NETCONF should change, explain how that should be accomplished. For demographic purposes, could you identify yourself as a vendor (and one that will code) or an operator (one that will use the code)? Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 16:27:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E582B-0000WH-9c; Tue, 16 Aug 2005 16:27:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E582A-0000UU-0I for isms@megatron.ietf.org; Tue, 16 Aug 2005 16:27:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10941 for ; Tue, 16 Aug 2005 16:27:39 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E58bY-0006D5-8c for isms@ietf.org; Tue, 16 Aug 2005 17:04:17 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7GKRFoF004163; Tue, 16 Aug 2005 15:27:16 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 16 Aug 2005 22:27:15 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3208E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear , "Nelson, David" Subject: RE: [Isms] RE: Call for consensus Date: Tue, 16 Aug 2005 22:27:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, can you point out where people should look in the Netconf Documents for the descritpion of the "call home" function? That may help them (and me). Bert > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Eliot Lear > Sent: Tuesday, August 16, 2005 22:08 > To: Nelson, David > Cc: isms@ietf.org > Subject: Re: [Isms] RE: Call for consensus > > > For those who are in favor, it seems only fair that you answer the > following questions: > > - why is it reasonable for ISMS diverge from the method that > NETCONF has specified for "call home" functionality? > > - what should be done to resolve the differences? > > - If you claim NETCONF should change, explain how that should be > accomplished. > > For demographic purposes, could you identify yourself as a vendor (and > one that will code) or an operator (one that will use the code)? > > Eliot > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 18:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59gg-0001Y0-4W; Tue, 16 Aug 2005 18:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59ge-0001Xr-Dw for isms@megatron.ietf.org; Tue, 16 Aug 2005 18:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16122 for ; Tue, 16 Aug 2005 18:13:33 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AG3-0000NF-EB for isms@ietf.org; Tue, 16 Aug 2005 18:50:12 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 6B27C1BAC4D; Wed, 17 Aug 2005 00:13:23 +0200 (CEST) Date: Wed, 17 Aug 2005 00:13:22 +0200 From: Juergen Quittek To: Tom Petch , isms@ietf.org Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of thedecisions made at IETF63 Message-ID: In-Reply-To: <014101c5a285$f834ff20$0601a8c0@pc6> References: <014101c5a285$f834ff20$0601a8c0@pc6> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom, --On 8/16/2005 7:09 PM +0200 Tom Petch wrote: > Juergen (and your co-chair:-), > > I struggle with the way you do this. You ask for those who disagree with > 1. The ISMS WG will work on one transport protocol only > to speak up so the list will contain only or mostly contrary views. How then do > you judge > rough consensus on this if those in favour have not spoken? We had a lot of people at the session who were in favor. The intention of the call for consensus is finding out if there is a significant number of people who disagree, but could not join us at the meeting or who changed their minds after the session Also people should speak up who discovered new problems with this way, that have not been considered yet. Thanks, Juergen > (I am in favour) > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: "Eliot Lear" ; > Sent: Monday, August 15, 2005 2:34 AM > Subject: Call for consensus,was: [Isms] request for confirmation (or lack > thereof) of thedecisions made at IETF63 > > >> Eliot, >> >> Thanks for the request. >> >> As stated at the saag session, I think that the following decisions >> made the ISMS session need approval from the mailing list: >> >> 1. The ISMS WG will work on one transport protocol only >> >> 2. ISMS will use SSH as transport protocol >> >> These issues are not exactly the ones from your list, but they >> are targeting at the same direction and reflect the discussion >> at the Paris session. >> >> For 1. I am not aware of contrary opinions. I see consensus on 1. >> Anyone who disagrees, please speak up soon. >> >> For 2. there was a clear preference at the session. However, >> there were statements challenging this decision on the list, >> mainly from people in favor of BEEP. At the session there >> were also also people favoring TLS+SASL, but so far they did >> not express severe concerns on the mailing list about choosing >> SSH instead. >> >> Concerns were raised at the meeting that none of the alternatives >> (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an >> Internet draft (for BEEP we have the most detailed description) >> for making the decision. >> >> However, we need to make progress and arguments have been exchanged >> extensively. Therefore I ask particularly people who did not >> participate in the Paris session to express their concerns about >> ISMS using SSH as transport protocol. >> >> Thanks, >> >> Juergen >> >> --On 8/14/2005 4:26 PM +0200 Eliot Lear wrote: >> >> > Hi, >> > >> > I would request that the chairs call for consensus on the points >> > discussed at IETF 63. As I recall there were four major decisions: >> > >> > - discarding of UDP options >> > >> > - advancing of Juergen's architecture draft separately >> > >> > - creating an SSH draft >> > >> > - moving forward solely on the basis of that draft >> > >> > Perhaps others might disagree with my recollection. I'll not argue for >> > or against in this message, but plan to do so on each of these questions >> > as they are called (hopefully separately). >> > >> > Eliot >> > >> > _______________________________________________ >> > Isms mailing list >> > Isms@lists.ietf.org >> > https://www1.ietf.org/mailman/listinfo/isms >> > >> >> >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 16 18:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59mo-0002sh-Q2; Tue, 16 Aug 2005 18:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E59mm-0002sX-M4 for isms@megatron.ietf.org; Tue, 16 Aug 2005 18:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16734 for ; Tue, 16 Aug 2005 18:19:53 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5AMB-0000W6-TT for isms@ietf.org; Tue, 16 Aug 2005 18:56:33 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 446491BAC4D; Wed, 17 Aug 2005 00:19:46 +0200 (CEST) Date: Wed, 17 Aug 2005 00:19:45 +0200 From: Juergen Quittek To: "Nelson, David" , isms@ietf.org Subject: Re: [Isms] RE: Call for consensus Message-ID: <49BB62318B412B62F842C9B0@[192.168.0.112]> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Nelson, --On 8/16/2005 8:31 PM +0200 Nelson, David wrote: > Tom Petch writes... > >> I struggle with the way you do this. You ask for those who disagree >> with 1. The ISMS WG will work on one transport protocol only >> to speak up so the list will contain only or mostly contrary views. >> How then do you judge rough consensus on this if those in favour have >> not spoken? > > Asking for dissent is one valid method of sensing rough consensus. If > only a few object, then it is very likely to be rough consensus in > favor. > > OTOH, if you believe that the majority is undecided, has no strong > opinion, or primarily consists of "lurkers" on the list, then a poll of > the "yeas" and "nays" may be required. The session showed a clear majority agreeing. I do not see why we should ask all of them to send a message to the list. Thanks, Juergen >> (I am in favour) > > FWIW, so am I. > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 02:38:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HYl-0002UT-Vw; Wed, 17 Aug 2005 02:37:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5HYk-0002UO-TQ for isms@megatron.ietf.org; Wed, 17 Aug 2005 02:37:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09197 for ; Wed, 17 Aug 2005 02:37:57 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5I8E-0004A3-Hi for isms@ietf.org; Wed, 17 Aug 2005 03:14:39 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 16 Aug 2005 23:10:36 -0700 X-IronPort-AV: i="3.96,115,1122879600"; d="scan'208"; a="655137893:sNHT31661636" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7H6AXoo003892; Tue, 16 Aug 2005 23:10:34 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp212.cisco.com [10.61.64.212]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7H674R2026845; Tue, 16 Aug 2005 23:07:04 -0700 Message-ID: <4302D4D8.9060409@cisco.com> Date: Wed, 17 Aug 2005 08:10:32 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] RE: Call for consensus References: <7D5D48D2CAA3D84C813F5B154F43B15507D3208E@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D3208E@nl0006exch001u.nl.lucent.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=611; t=1124258825; x=1124691025; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Wed,=2017=20Aug=202005=2008=3A10=3A32=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=RZ/XaqoNgbtjSRowpLi8fjSPEkL/ukJHbMnyHOVcLNsSIlNy0vdkDf9HeHEToAYFSA0lfECD 0D+o5yvPBFgRFmaMPe+c8cmBNEqqBSU+wVhrJ5+67ekBIOgK1r1zky8gV64s0NLt/sOTMS1uLZZ 7QEjnQ+60d947qynHoGkt1Sc= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wijnen, Bert (Bert) wrote: > Eliot, can you point out where people should look in > the Netconf Documents for the descritpion of the > "call home" function? The functionality is (admittedly obliquely) described in the BEEP draft (draft-ietf-netconf-beep-0?.txt) as well in the base BEEP specification, which is RFC 3080. The term "call home" is not used. Rather "peer to peer" is made use of. To be brief, the way this is accomplished in BEEP is via advertised profiles. If a profile is advertised it can be used. Another simple way to think about it is through the SMTP "TURN/ETRN" commands. Yes, it goes that far back in our history - even before NATs and firewalls, oddly enough. Just part of the robustness principle back then. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 03:21:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IF2-0004F7-II; Wed, 17 Aug 2005 03:21:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IF0-0004De-Hb for isms@megatron.ietf.org; Wed, 17 Aug 2005 03:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11820 for ; Wed, 17 Aug 2005 03:21:37 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5IoV-0005Zf-F2 for isms@ietf.org; Wed, 17 Aug 2005 03:58:19 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 582311BAC4D; Wed, 17 Aug 2005 09:21:28 +0200 (CEST) Date: Wed, 17 Aug 2005 09:21:28 +0200 From: Juergen Quittek To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] ISMS charter discussion Message-ID: <2F5F4C4AAB408A5A6996BC2E@[192.168.0.112]> In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, Thanks for the comments. --On 8/15/2005 4:49 PM +0200 Nelson, David wrote: > Juergen Quittek writes... > > Specific suggestions in-line, below (DBN). > >> ----------------------- >> ISMS WG charter outline >> ----------------------- >> >> Background >> - USM has limited deployment >> - no standard for integrating key and user management into >> deployed authentication infrastructures >> - SSH is widely deployed >> - SSH integration into AAA, e.g., Redius, is available > > DBN: - SSH integration into AAA, e.g., RADIUS, is available Fixed. >> >> WG goals >> - define a new SNMP security model that utilzes the SSH protocol >> to provide message security services for SNMP >> - compliancy with SNMPv3, no modification of SNMPv3 > > DBN: - compliance with SNMPv3 architecture Fixed. >> - work on new access control models and VACM mappings out of scope > > DBN: - work on new access control models and VACM mappings out of scope > (except for mapping via securityName or security Group, see > below) Fine. >> - open to further transport mappings, such as BEEP, TLS, ... >> ? mentions session concept ? > > DBN: The concept of session is important, and could be easily supported > via SSH. I think we need to mention it. What about: - following a session-based approach ? >> ? mention user->group mapping via AAA ? > > DBN: - define a standard method for mapping from AAA-provisioned > authorization parameter(s) to SNMP securityName and securityGroup fine. >> ? authenticate user or command generator ? > > DBN: Are we talking about device authentication here? That is > to say, non-human entity authentication? > >> >> Work Items: >> - specify how transport mapping security models (TMSMs) >> fit into the SNMPv3 architecture >> - specify RADIUS attributes used to populate >> securityName and other SNMP parameters > > DBN: I would specifically mention securityGroup here. Would we then still need to say "and other SNMP parameters"? Thanks, Juergen >> - define how to use SSH between the two snmp engines >> - specify the SSH security model for SNMP >> >> Documents >> - A document that specifies how transport mapping security models >> (TMSMs) fit into the SNMPv3 architecture and which defines the >> requirements for transport mapping security models. >> - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) >> - A document specifying the SSH security model for SNMP. >> This specification must comply with the TMSM requirements. >> - An Applicability statement that sets up reasonable mandatory to >> implement methods. >> ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it >> with the SSH transport model (or move RFC 3430 to historic) ? > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 05:38:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KNn-0005N1-Tz; Wed, 17 Aug 2005 05:38:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KNm-0005Mt-2I for isms@megatron.ietf.org; Wed, 17 Aug 2005 05:38:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17555 for ; Wed, 17 Aug 2005 05:38:47 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5KxG-00016C-U5 for isms@ietf.org; Wed, 17 Aug 2005 06:15:32 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2EAFA1BAC4D; Wed, 17 Aug 2005 11:38:37 +0200 (CEST) Date: Wed, 17 Aug 2005 11:38:37 +0200 From: Juergen Quittek To: "Nelson, David" , isms@ietf.org Subject: RE: [Isms] ISMS charter discussion Message-ID: In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Here is an update based on David's comments: ----------------------- ISMS WG charter outline ----------------------- Background - USM has limited deployment - no standard for integrating key and user management into deployed authentication infrastructures - SSH is widely deployed - SSH integration into AAA, e.g., RADIUS, is available WG goals - define a new SNMP security model that utilzes the SSH protocol to provide message security services for SNMP - compliancy with SNMPv3 architecture, no modification of SNMPv3 - work on new access control models and VACM mappings out of scope (except for mapping via securityName or security Group) - open to further transport mappings, such as BEEP, TLS, ... - following a session-based approach - define a standard method for mapping from AAA-provisioned authorization parameter(s) to SNMP securityName and securityGroup Work Items: - specify how transport mapping security models (TMSMs) fit into the SNMPv3 architecture - specify RADIUS attributes used to populate securityname and other SNMP parameters - define how to use SSH between the two snmp engines - specify the SSH security model for SNMP Documents - A document that specifies how transport mapping security models (TMSMs) fit into the SNMPv3 architecture and which defines the requirements for transport mapping security models. - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) - A document specifying the SSH security model for SNMP. This specification must comply with the TMSM requirements. - An Applicability statement that sets up reasonable mandatory to implement methods. ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it with the SSH transport model (or move RFC 3430 to historic) ? --On 8/15/2005 4:49 PM +0200 Nelson, David wrote: > Juergen Quittek writes... > > Specific suggestions in-line, below (DBN). > >> ----------------------- >> ISMS WG charter outline >> ----------------------- >> >> Background >> - USM has limited deployment >> - no standard for integrating key and user management into >> deployed authentication infrastructures >> - SSH is widely deployed >> - SSH integration into AAA, e.g., Redius, is available > > DBN: - SSH integration into AAA, e.g., RADIUS, is available > >> >> WG goals >> - define a new SNMP security model that utilzes the SSH protocol >> to provide message security services for SNMP >> - compliancy with SNMPv3, no modification of SNMPv3 > > DBN: - compliance with SNMPv3 architecture > >> - work on new access control models and VACM mappings out of scope > > DBN: - work on new access control models and VACM mappings out of scope > (except for mapping via securityName or security Group, see > below) > >> - open to further transport mappings, such as BEEP, TLS, ... >> ? mentions session concept ? > > DBN: The concept of session is important, and could be easily supported > via SSH. I think we need to mention it. > >> ? mention user->group mapping via AAA ? > > DBN: - define a standard method for mapping from AAA-provisioned > authorization parameter(s) to SNMP securityName and securityGroup > > >> ? authenticate user or command generator ? > > DBN: Are we talking about device authentication here? That is > to say, non-human entity authentication? > >> >> Work Items: >> - specify how transport mapping security models (TMSMs) >> fit into the SNMPv3 architecture >> - specify RADIUS attributes used to populate >> securityName and other SNMP parameters > > DBN: I would specifically mention securityGroup here. > >> - define how to use SSH between the two snmp engines >> - specify the SSH security model for SNMP >> >> Documents >> - A document that specifies how transport mapping security models >> (TMSMs) fit into the SNMPv3 architecture and which defines the >> requirements for transport mapping security models. >> - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) >> - A document specifying the SSH security model for SNMP. >> This specification must comply with the TMSM requirements. >> - An Applicability statement that sets up reasonable mandatory to >> implement methods. >> ? A Revision RFC 3430 (SNMP over TCP) to ensure it is aligned it >> with the SSH transport model (or move RFC 3430 to historic) ? > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 05:43:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KSJ-0006Tn-Km; Wed, 17 Aug 2005 05:43:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5KSH-0006Tf-VT for isms@megatron.ietf.org; Wed, 17 Aug 2005 05:43:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18048 for ; Wed, 17 Aug 2005 05:43:27 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5L1j-0001Ie-FH for isms@ietf.org; Wed, 17 Aug 2005 06:20:12 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7H9h9bF022530; Wed, 17 Aug 2005 04:43:10 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 17 Aug 2005 11:43:09 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D321E4@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear Subject: RE: [Isms] RE: Call for consensus Date: Wed, 17 Aug 2005 11:42:58 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org All nice Eliot. But I like you to be a bit more specific. Pls write a short paragraph or two that explains exactly what you mean with "call home". I think it is a term that means something in your mind, and possibly something else in my (or other peoples) mind(s). So having a good definition, so we all know what we're talking about is (I think) a good thing. Then, I'd like to know where/how you think current SNMPv3 provides it. That makes it much easier for me to map the concept onto things I know. Then I'd like you to uncover some more of the "obliqueness" of where how it is done in NetConf (over BEEP). You seem to claim (implicit) that NetConf "consciously decided to have a call-home" functionality, but I am not so sure they did. In any event, if they have it via the NetConf over BEEP mechanism, then they cannot assume it will be present, because only NetConf over SSH is mandatory to implement. Sorry to bother you and get you to this (extra) work. But I prefer that we are all clear on this topic which seems to be such an important topic to you. Bert > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Wednesday, August 17, 2005 08:11 > To: Wijnen, Bert (Bert) > Cc: Nelson, David; isms@ietf.org > Subject: Re: [Isms] RE: Call for consensus > > > > > Wijnen, Bert (Bert) wrote: > > Eliot, can you point out where people should look in > > the Netconf Documents for the descritpion of the > > "call home" function? > > The functionality is (admittedly obliquely) described in the > BEEP draft > (draft-ietf-netconf-beep-0?.txt) as well in the base BEEP > specification, > which is RFC 3080. The term "call home" is not used. Rather "peer to > peer" is made use of. > > To be brief, the way this is accomplished in BEEP is via advertised > profiles. If a profile is advertised it can be used. > > Another simple way to think about it is through the SMTP "TURN/ETRN" > commands. Yes, it goes that far back in our history - even > before NATs > and firewalls, oddly enough. Just part of the robustness > principle back > then. > > Eliot > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 08:16:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5MpE-0005NI-Io; Wed, 17 Aug 2005 08:15:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5MpC-0005Lv-Pf for isms@megatron.ietf.org; Wed, 17 Aug 2005 08:15:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24802 for ; Wed, 17 Aug 2005 08:15:15 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5NOg-0005VS-2P for isms@ietf.org; Wed, 17 Aug 2005 08:52:00 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 479437; Wed, 17 Aug 2005 08:08:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <430247BC.9030601@cisco.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> Date: Wed, 17 Aug 2005 08:14:51 -0400 To: Eliot Lear , "Nelson, David" From: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot and ISMS folks, I've been trying to come up-to-speed on what is happening in this group, so I thought I'd jump in here. Please let me know if I am misunderstanding something or hashing over something that has been well-hashed in the past... At 10:08 PM +0200 8/16/05, Eliot Lear wrote: >For those who are in favor, it seems only fair that you answer the >following questions: > > - why is it reasonable for ISMS diverge from the method that > NETCONF has specified for "call home" functionality? I understand that there is a benefit (code re-use and unified security configuration) to using a shared "transport protocol" (to use that term loosely), such as SSH for both SNMP (through ISMS) and NETCONF. But, I am not sure that it is important that SNMP and NETCONF use SSH in exactly the same way, because they don't have exactly the same properties. I'm not really sure what you mean when you discuss "call home" functionality WRT SNMP... SNMP has a well established paradigm where the manager sends SNMP query PDUs to the agent, perhaps polling for information as necessary, and the agent sends response PDUs only in response to queries. If a managed device needs to send information to a manager asynchronously, this is done via notification PDUs or traps that are sent from a notification sender to a notification receiver. In other words, SNMP is not a symmetric peer-to-peer protocol. If you are talking about the situation where a new device comes on-line and, essentially, requests to be configured, monitored or managed via SNMP, I would _think_ that the best way to accomplish that within the SNMP paradigm would be for the new device to send a notification to a notification receiver running on the same system as the SNMP manager, and for the manager to start sending SNMP queries (for monitoring, provisioning, etc.) to the new device as a result of that notification. If that is the type of exchange that you are trying to support, I think that the simplest way to support that would be to have two different types of SSH subsystem for SNMP, an "SNMP-agent" subsystem that is invoked on the agent by the manager, and an "SNMP-notification-receiver" subsystem that is invoked on the notification receiver by the notification sender. The new device would establish an SSH session with a notification receiver to send the notification, and the manager would then establish an SSH session with the agent to send queries and receive responses. I don't understand why this would require any special "call home" functionality, and I don't seen any reason why this would be difficult from an SSH perspective. Or are you suggesting that this would all need to happen using a single SSH connection? If so, I could see how that might be problematic, as I don't know that it is possible for a single SSH connection to be used first to invoke a subsystem on one end of the connection and later to invoke a subsystem on the other end -- I'd have to ask more SSH-knowledgable folks if that is even possible. I also have trouble picturing how that would be consistent with the SNMP architecture and paradigms, since the manager/agent and notification sender/receiver are independent architectural entities... Either way that you try to handle this, I think that there are a number of other complexities with this model, such as: How would the new device get information about what notification receiver/manager to contact? And, how would the new device get it's initial SNMP security configuration? Could you explain what you are trying to do here? Are there cases where the simpler scenario I've described above (new device sends notification, manager starts sending queries as a result of the notification) wouldn't work in situations where the more complex single-connection "call home" model would? Perhaps if a NAT is involved? >For demographic purposes, could you identify yourself as a vendor (and >one that will code) or an operator (one that will use the code)? I am a vendor of devices that are monitored via SNMP and that may be configured (at some point in the future) using NETCONF. Margaret _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 10:18:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Oke-0002Tt-QT; Wed, 17 Aug 2005 10:18:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Okd-0002To-Aa for isms@megatron.ietf.org; Wed, 17 Aug 2005 10:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03519 for ; Wed, 17 Aug 2005 10:18:41 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PK8-0000tS-Dj for isms@ietf.org; Wed, 17 Aug 2005 10:55:28 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E0150E0049; Wed, 17 Aug 2005 10:17:55 -0400 (EDT) To: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> From: Sam Hartman Date: Wed, 17 Aug 2005 10:17:55 -0400 In-Reply-To: (Margaret Wasserman's message of "Wed, 17 Aug 2005 08:14:51 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Or are you suggesting that this would all need to happen Margaret> using a single SSH connection? If so, I could see how Margaret> that might be problematic, as I don't know that it is Margaret> possible for a single SSH connection to be used first to Margaret> invoke a subsystem on one end of the connection and Margaret> later to invoke a subsystem on the other end -- I'd have Margaret> to ask more SSH-knowledgable folks if that is even Margaret> possible. I also have trouble picturing how that would Margaret> be consistent with the SNMP architecture and paradigms, Margaret> since the manager/agent and notification sender/receiver Margaret> are independent architectural entities... It cannot. However you could set things up so that no matter which side invokes the snmp subsystem, packets are allowed to flow in both directions. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 10:22:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5OoN-0003th-Hb; Wed, 17 Aug 2005 10:22:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5OoM-0003tc-Cq for isms@megatron.ietf.org; Wed, 17 Aug 2005 10:22:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03946 for ; Wed, 17 Aug 2005 10:22:32 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5PNt-000113-U6 for isms@ietf.org; Wed, 17 Aug 2005 10:59:19 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 9F3CBE0049; Wed, 17 Aug 2005 10:21:50 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> From: Sam Hartman Date: Wed, 17 Aug 2005 10:21:50 -0400 In-Reply-To: <430247BC.9030601@cisco.com> (Eliot Lear's message of "Tue, 16 Aug 2005 22:08:28 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> For those who are in favor, it seems only fair that you Eliot> answer the following questions: Eliot> - why is it reasonable for ISMS diverge from the method Eliot> that NETCONF has specified for "call home" functionality? Our charter does not require us to align with netconf. You can try and convince people this is a desirable goal and to the extent you are successful they will consider it in evaluating solutions. However so far I have not seen anything in the charter that requires us to align with netconf nor have I seen a consensus declared that this is a strong requirement for evaluating solutions. Similarly, I don't see a requirement in our charter for call home functionality. Again, you can argue for such a requirement but so far I have not seen a consensus that the group agrees there is such a requirement. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 11:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PoO-0004Ly-Sr; Wed, 17 Aug 2005 11:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PoM-0004Lq-TC for isms@megatron.ietf.org; Wed, 17 Aug 2005 11:26:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07290 for ; Wed, 17 Aug 2005 11:26:36 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5QNu-0002qA-8O for isms@ietf.org; Wed, 17 Aug 2005 12:03:24 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 479746; Wed, 17 Aug 2005 11:19:33 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> Date: Wed, 17 Aug 2005 11:26:18 -0400 To: Sam Hartman From: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, At 10:17 AM -0400 8/17/05, Sam Hartman wrote: >It cannot. However you could set things up so that no matter which >side invokes the snmp subsystem, packets are allowed to flow in both >directions. SNMP communication is bi-directional, but it is not symmetrical, and I'm not sure that we can or should change that under the auspices of defining a new, better integrated security mechanism for SNMP. As far as I can tell, the "call home" features is concerned with which side(s) can take the _initiative_ to establish an SNMP communication session. I'd argue that having an SNMP agent (AKA the architectural element that response to queries) _decide_ (based on configuration, or whatever) that it wants to be managed (monitored, configured, etc.) by a particular manager (AKA an architectural element that sends queries) and then having that agent establish a connection to that manager for the purpose of being managed is a pretty big departure from the current SNMP model. Today, the manager is active, and the agent is completely reactive. If an a device needs to send information asynchronously to a management system, that is done by the notification sender on the device sending a notify or a trap. It is my hope that ISMS will produce something that can be retro-fitted into existing SNMP implementations by changing the underlying transport layer and perhaps adding a few hooks into the existing SNMP agent for access control. If that isn't the goal, and we're willing to revisit basic properties of SNMP, perhaps we should get rid of that pesky ASN.1 BER encoding while we are at it! :-) (<== Note for the humour impaired: this is a joke. Please do not respond as if it were a serious suggestion.) Margaret _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 11:35:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Pwb-0006fb-92; Wed, 17 Aug 2005 11:35:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5PwZ-0006dg-Mr for isms@megatron.ietf.org; Wed, 17 Aug 2005 11:35:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07674 for ; Wed, 17 Aug 2005 11:35:05 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5QW5-00035s-JG for isms@ietf.org; Wed, 17 Aug 2005 12:11:53 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 51060E0049; Wed, 17 Aug 2005 11:34:21 -0400 (EDT) To: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> From: Sam Hartman Date: Wed, 17 Aug 2005 11:34:21 -0400 In-Reply-To: (Margaret Wasserman's message of "Wed, 17 Aug 2005 11:26:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Margaret" == Margaret Wasserman writes: Margaret> Hi Sam, Margaret> At 10:17 AM -0400 8/17/05, Sam Hartman wrote: >> It cannot. However you could set things up so that no matter >> which side invokes the snmp subsystem, packets are allowed to >> flow in both directions. Margaret> SNMP communication is bi-directional, but it is not Margaret> symmetrical, and I'm not sure that we can or should Margaret> change that under the auspices of defining a new, better Margaret> integrated security mechanism for SNMP. Is it asymmetric at the level that we're talking about though--at the PDU transport level? I do think the simplest level to do call home is to make the channel bidirectional. I do agree with you though that it is unclear what call home would mean in an SNMP context and that we should convince ourselves that we want call home and know what it means before specifying it. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 12:16:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QYa-0007Ek-Fz; Wed, 17 Aug 2005 12:14:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5QYZ-0007E9-Bq for isms@megatron.ietf.org; Wed, 17 Aug 2005 12:14:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09510 for ; Wed, 17 Aug 2005 12:14:20 -0400 (EDT) Message-Id: <200508171614.MAA09510@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5R85-0004B3-Ed for isms@ietf.org; Wed, 17 Aug 2005 12:51:08 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050817161409011000ritce>; Wed, 17 Aug 2005 16:14:09 +0000 From: "David B Harrington" To: "'Margaret Wasserman'" , Subject: RE: [Isms] RE: Call for consensus Date: Wed, 17 Aug 2005 12:14:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWjQWkEtoYD+0aGRw6LpBytdXVZBAAAyL6A X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Architecturally, a "call home" functionality would likely impact multiple subsystems within the RFC3411 architecture - the transport mapping (implied subsystem), the security subsystem, and the application subsystem (RFC3413). I agree with Sam that we should understand how we want to utilize this functionality in SNMP before spending resources to developing it. So far, I haven't seen a strong case that we need this, only an argument that BEEP supports this, so we should want it to justify adopting BEEP. If the goal is to address NAT/firewall issues, that seems to me to be an issue to be resolved at the transport layer, or within NAT/firewall standards rather than within SNMP. SNMP already has its own solution for this problem - the proxy application defined in RFC3413 allows an SNMPv3 proxy entity to be co-resident with NAT/firewall functionality and can establish two SSH trusted tunnels, one to the entity outside the firewall, and one to the entity inside the firewall (or in the public vs private addressing space). RFC2962 has a discussion of application-level gateways and proxies and special considerations related to SNMP. If we choose to address issues of NAT, that should certainly be included in the discussion. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Wednesday, August 17, 2005 11:34 AM > To: Margaret Wasserman > Cc: isms@ietf.org > Subject: Re: [Isms] RE: Call for consensus > > >>>>> "Margaret" == Margaret Wasserman > writes: > > Margaret> Hi Sam, > > Margaret> At 10:17 AM -0400 8/17/05, Sam Hartman wrote: > >> It cannot. However you could set things up so that no matter > >> which side invokes the snmp subsystem, packets are allowed to > >> flow in both directions. > > Margaret> SNMP communication is bi-directional, but it is not > Margaret> symmetrical, and I'm not sure that we can or should > Margaret> change that under the auspices of defining a new, better > Margaret> integrated security mechanism for SNMP. > > Is it asymmetric at the level that we're talking about though--at the > PDU transport level? > > I do think the simplest level to do call home is to make the channel > bidirectional. I do agree with you though that it is unclear what > call home would mean in an SNMP context and that we should convince > ourselves that we want call home and know what it means before > specifying it. > > --Sam > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 13:31:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Rl0-0005HO-KH; Wed, 17 Aug 2005 13:31:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Rky-0005HJ-QX for isms@megatron.ietf.org; Wed, 17 Aug 2005 13:31:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13564 for ; Wed, 17 Aug 2005 13:31:13 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5SKX-0006LM-0K for isms@ietf.org; Wed, 17 Aug 2005 14:08:03 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7HHV3pZ004879 for ; Wed, 17 Aug 2005 17:31:03 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7HHUHF6001681 for ; Wed, 17 Aug 2005 17:31:03 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005081710310127342 for ; Wed, 17 Aug 2005 10:31:01 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:30:59 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 10:30:59 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 13:30:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Call for consensus Date: Wed, 17 Aug 2005 13:26:37 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901AA79E1@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] RE: Call for consensus Thread-Index: AcWjQWaeSndVIqPuTmyHgTfD8JkxFQACm5mw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 17 Aug 2005 17:30:57.0894 (UTC) FILETIME=[6DC08860:01C5A351] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 >> It cannot. However you could set things up so that no matter >> which side invokes the snmp subsystem, packets are allowed to >> flow in both directions. Margaret> SNMP communication is bi-directional, but it is not Margaret> symmetrical, and I'm not sure that we can or should Margaret> change that under the auspices of defining a new, better Margaret> integrated security mechanism for SNMP. > Is it asymmetric at the level that we're talking about > though--at the PDU transport level? > > I do think the simplest level to do call home is to make the channel > bidirectional.=20 The channel is bidirectional no matter what - in the sense that both ends occasionally send something over it. But the only true symmetry is in the session/channel establishment cost - which is evenly shared between the two peers. Asymmetric here (as Margaret pointed out) means - who must know what about who (such as but not limited to locations and identities of potential managers).=20 If asymmetricity of the higher layers didn't impact PDU transport - this WG could be concluded with two one-statement RFCs: (1) "just use SSH", and (2) "just use TLS". Devil is in the details, such as who to establish a channel to, when, how, with what parameters, etc. Managers are at much better position to answer those questions. Currently SNMP agents (as Margaret pointed out) just sit there and wait for incoming requests. If and when one comes - send a message back if ncessary. Vey simple. Note that Web-based management doesn't change this basic assumption - it simply replaces SNMP server with httpd. Introducing Notifications ("confirmed traps") was a divergence from this puerille line of thinking. Now the agent must figure out who to send notification to, and more important - what to do if it appears that notification hasn't reached its destination. But the main SNMP concept wasn't altered: agent in its routine functioning stays small and dumb. Perhaps we do want to change all this? And as we're at it - perhaps we do want to get rid of ASN.1? It's only half-joke. > I do agree with you though that it is unclear what > call home would mean in an SNMP context and that we should > convince ourselves that we want call home and know what it > means before specifying it. Can't agree more. Am not convinced that "call home" is needed and/or can solve any of SNMP problems. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 15:13:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TLg-0007H5-Fl; Wed, 17 Aug 2005 15:13:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5TLf-0007Gv-HQ for isms@megatron.ietf.org; Wed, 17 Aug 2005 15:13:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18607 for ; Wed, 17 Aug 2005 15:13:13 -0400 (EDT) Received: from pop-altamira.atl.sa.earthlink.net ([207.69.195.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5TvF-0000Sn-Q6 for isms@ietf.org; Wed, 17 Aug 2005 15:50:03 -0400 Received: from h-64-105-136-26.snvacaid.dynamic.covad.net ([64.105.136.26] helo=oemcomputer) by pop-altamira.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5TLN-0000zw-00 for isms@ietf.org; Wed, 17 Aug 2005 15:12:57 -0400 Message-ID: <005a01c5a35f$e26f6920$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com><430247BC.9030601@cisco.com> Subject: Re: [Isms] RE: Call for consensus Date: Wed, 17 Aug 2005 12:14:25 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Margaret Wasserman" > To: "Sam Hartman" > Cc: > Sent: Wednesday, August 17, 2005 8:26 AM > Subject: Re: [Isms] RE: Call for consensus ... > At 10:17 AM -0400 8/17/05, Sam Hartman wrote: > >It cannot. However you could set things up so that no matter which > >side invokes the snmp subsystem, packets are allowed to flow in both > >directions. > > SNMP communication is bi-directional, but it is not symmetrical, and > I'm not sure that we can or should change that under the auspices of > defining a new, better integrated security mechanism for SNMP. > > As far as I can tell, the "call home" features is concerned with > which side(s) can take the _initiative_ to establish an SNMP > communication session. ... Let's take a concrete example: A managed device comes up, has persistant entries in RFC 3413's SNMP-TARGET-MIB, SNMP-NOTIFICATION-MIB, and appropriate VACM entries. Something happens that results in notifications needing to be sent. How do they get delivered, if our transport mechanism requires a session of some kind to be in place? Obviously the "agent" needs to be able to establish the session, rather than waiting for some management system to get around to contacting it, particularly since there's no guarantee that the configured notification targets will *ever* call the device themselves. Sure one can get into arguing about whether fancier things may or may not be needed, but this is rather rock-bottom functionality that I think is hard to argue with. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 19:18:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XB1-0005rG-Qe; Wed, 17 Aug 2005 19:18:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XB0-0005r1-5j for isms@megatron.ietf.org; Wed, 17 Aug 2005 19:18:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11082 for ; Wed, 17 Aug 2005 19:18:26 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5Xkb-0001qc-DC for isms@ietf.org; Wed, 17 Aug 2005 19:55:19 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7HNIEYx027512 for ; Wed, 17 Aug 2005 18:18:15 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Aug 2005 01:18:14 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D323FC@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: isms@ietf.org Date: Thu, 18 Aug 2005 01:18:05 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Subject: [Isms] bidirectional session, call-home, authoritative SNMP Engine X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org W.r.t. SNMP and having two methods of operation (if I may say so) - The normal polling from an NMS like end to a Managed device (agent like end). - The sending of (confirmed) notifications When we agreed on (converged from SNMPv2u and SNMPv2* into) SNMPv3, we also agreed that for the first method of operation, the agent (or managed device) is the "authoritative" engine w.r.t. snmpEngineID and snmpEngineboots and snmpEngineTime. For the second mode of Operations, we decided that the other end (the manager) is the "authoritative" engine for those 3 objects. So we (probably, but I do not know enough details of all the security mechanisms/transports etc being considered) must take those two modes of operation into account. It is the sending of (confirmed) notifications which makes it hard for an agent to go and send a "here I am and I want to be managed" to some SNMP manager (NMS). In any event, even with current SNMPv3 and USM, the agent MUST be configured (manually as far as I know) to install some initial security configuration and to ensure it can communicate with an SNMP manager (for either mode of operation). Hope this helps in the discussion. Bert p.s. Still waiting for Eliot to give a definition of "call home" and to show what it maps to on current SNMPv3 (if it does at all) and if possible to also show me the details of its obliqueness in NetCOnf over Beep. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 19:31:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XNo-0000ko-MV; Wed, 17 Aug 2005 19:31:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5XNl-0000ka-HR for isms@megatron.ietf.org; Wed, 17 Aug 2005 19:31:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11924 for ; Wed, 17 Aug 2005 19:31:38 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5XxM-0002GS-2L for isms@ietf.org; Wed, 17 Aug 2005 20:08:31 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2005 16:31:29 -0700 X-IronPort-AV: i="3.96,119,1122879600"; d="scan'208"; a="333196775:sNHT42012402" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7HNVRQN024262; Wed, 17 Aug 2005 16:31:27 -0700 (PDT) Message-Id: <6.2.0.14.0.20050817162734.0407e970@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 17 Aug 2005 16:31:19 -0700 To: Sam Hartman From: Kaushik Narayan In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.enterasys.com> <6.2.0.14.0.20050812144449.03e85780@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org Subject: [Isms] Re: PAM and RADIUS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Thanks Sam. This should work although we still need to figure out how the module specific attributes (groupName) are passed to the SNMP engine by the SSH layer. At 09:20 AM 8/15/2005, Sam Hartman wrote: > >>>>> "Kaushik" == Kaushik Narayan writes: > > Kaushik> I am not aware of the PAM API supporting passing of > Kaushik> module specific parameters. >pam_set_item, pam_get_item could be used for this. But you would need >support from your module. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 17 22:53:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aWl-0007Qd-S6; Wed, 17 Aug 2005 22:53:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5aWk-0007P2-Im for isms@megatron.ietf.org; Wed, 17 Aug 2005 22:53:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21250 for ; Wed, 17 Aug 2005 22:53:08 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5b6P-0007kH-0h for isms@ietf.org; Wed, 17 Aug 2005 23:30:02 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5516CE0049; Wed, 17 Aug 2005 22:52:24 -0400 (EDT) To: Kaushik Narayan Subject: Re: [Isms] Re: PAM and RADIUS References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E4@MAANDMBX2.ets.enterasys.com> <6.2.0.14.0.20050812144449.03e85780@email.cisco.com> <6.2.0.14.0.20050817162734.0407e970@email.cisco.com> From: Sam Hartman Date: Wed, 17 Aug 2005 22:52:24 -0400 In-Reply-To: <6.2.0.14.0.20050817162734.0407e970@email.cisco.com> (Kaushik Narayan's message of "Wed, 17 Aug 2005 16:31:19 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Kaushik" == Kaushik Narayan writes: Kaushik> Thanks Sam. Kaushik> This should work although we still need to figure out how Kaushik> the module specific attributes (groupName) are passed to Kaushik> the SNMP engine by the SSH layer. I think that's out of scope for IETF work. I do agree that vendors need to discuss that as they consider how to implement and don't think using this list would be a bad place to have that discussion. I also believe that if implementers come back and tell us that they cannot solve the problem we need to consider that our protocol probably does not meet their needs. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 00:30:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5c2s-0001YH-01; Thu, 18 Aug 2005 00:30:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5c2q-0001Wl-9v for isms@megatron.ietf.org; Thu, 18 Aug 2005 00:30:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25749 for ; Thu, 18 Aug 2005 00:30:21 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ccV-00028f-Dn for isms@ietf.org; Thu, 18 Aug 2005 01:07:16 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j7I4UAo5015038; Wed, 17 Aug 2005 21:30:10 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j7I4U5Fk008723; Wed, 17 Aug 2005 21:30:05 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j7I4U43H008716; Wed, 17 Aug 2005 21:30:05 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 17 Aug 2005 21:30:04 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Sam Hartman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org Subject: [Isms] Security question for SNMP notifications X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, The model that SNMPv3/USM uses for delivering notifications (with are traps and informs), is that the notification delivery system as defined in RFC 3413 is configured for identities at transport address targets. There may be multiple identities at each transport address, and if so, a notification may be sent to each one. On the notification receiver side, each SNMPv3/USM message is verified with the credentials of the identity specified in the notification SNMP message. When a session approach is used, if a session is created by a notification originator (the client) to a notification receiver (the server) and mutul authentication is to be done, then which identifies should be used by the client and manager. For me, the "natural" identities are the managed system for the client, and a user for the server. However, to do this, then on session creation, the client must tell the server what ID to use, since the server can support many identities. (Or at least, that is the model today, and it "lines up" with the identities used when the session is created by a "command generator". So, from a "security purity" standpoint, what options are there? I can see: 1) yes, it is Ok for the client to tell the server the identity that the server should use. 2) no, this is not OK. There can be only one identity used per transport address 3) some other approach Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 01:39:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5d7w-0005xV-PX; Thu, 18 Aug 2005 01:39:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5d7t-0005xL-UJ for isms@megatron.ietf.org; Thu, 18 Aug 2005 01:39:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28476 for ; Thu, 18 Aug 2005 01:39:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5dhY-0003s2-HC for isms@ietf.org; Thu, 18 Aug 2005 02:16:35 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 17 Aug 2005 22:39:30 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7I5dR0J019003; Wed, 17 Aug 2005 22:39:27 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4164.cisco.com [10.61.80.67]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7I5ZsuX007249; Wed, 17 Aug 2005 22:35:54 -0700 Message-ID: <43041F0F.8010303@cisco.com> Date: Thu, 18 Aug 2005 07:39:27 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] RE: Call for consensus References: <7D5D48D2CAA3D84C813F5B154F43B15507D321E4@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D321E4@nl0006exch001u.nl.lucent.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2680; t=1124343355; x=1124775555; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Thu,=2018=20Aug=202005=2007=3A39=3A27=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=HKQiMAmDFUXCjfifGjF/egNwp5Zmg+LrztBllqoQK2exIAXugYC5SDRBSZJ5kigR5ebu2K4f R9Z1LV+E2Z8HrEFRVYRb+nSwKiUwjJuOnk/waSQ24TpeXLhrS1FWpKgJJGprMimiQklJZq3bFzk 5DVI+kglFJMhoh52ZwIpyPIk= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Andy Bierman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Good morning, Bert. I'm sorry for the delayed response- out sick yesterday. Please see below. > Pls write a short paragraph or two that explains exactly > what you mean with "call home". I think it is a term > that means something in your mind, and possibly something > else in my (or other peoples) mind(s). So having a good > definition, so we all know what we're talking about is > (I think) a good thing. "Call home" is the act of the managed element initiating the transport connection to the manager for the purpose of being managed in some way. An example of a "call home" function would be any of the various update mechanisms in your Microsoft Windows / Apple / SuSE Linux software update services. This function is used explicitly for several reasons. First, many elements are unavailable through firewalls or NATs largely because the firewall does not support transport of other than specific UDP functions such as DNS and/or NTP and/or certain gaming applications. Second, there is an inherent security benefit for devices that do not have to (TCP/SCTP) LISTEN or otherwise accept random UDP requests as SNMP does since the lower levels filter out communications that the device didn't establish. The level of benefit is of course tied to whether or not TLS is run atop the connection or IPSEC is run below it, but from a configuration perspective the latter isn't all that easy. > > Then, I'd like to know where/how you think current SNMPv3 > provides it. That makes it much easier for me to map > the concept onto things I know. The current SNMP does not provide this function. Were we to add it the identities mapped must be explictly mentioned in the draft. TCP offers us important opportunity, however, that would not have come up had UDP remained the transport of choice in ISMS. > > Then I'd like you to uncover some more of the "obliqueness" > of where how it is done in NetConf (over BEEP). You seem to > claim (implicit) that NetConf "consciously decided to have > a call-home" functionality, but I am not so sure they did. As you can read from the BEEP draft either side may initiate the connection. We didn't use the term "call home", that's all. The design-team had a discussion on this point and Margaret claimed that since the function was available to BEEP it needn't be present in all mappings. While I didn't think much of the answer at the time (I prefered all mappings to offer all functions), since I could do what I wanted to do in BEEP I was happy enough. I've CC'd Margaret and Andy as they can check my memory and notes (much of this occurred on the phone). > In any event, if they have it via the NetConf over BEEP > mechanism, then they cannot assume it will be present, > because only NetConf over SSH is mandatory to implement. When we offer the same service we should use the same method to accomplish the task. As I've written, I'm not wedded to BEEP but I do think we need this capability in either and we should implement it in the same way. At the very least it has the potential to simplify administration while the other method has more than the potential to complicate it. You're also re-using the same code paths which is good for security, not to mention efficiency. Does this answer your questions sufficiently? Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 02:31:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5dvy-0007s6-4w; Thu, 18 Aug 2005 02:31:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5dvw-0007rx-Hp for isms@megatron.ietf.org; Thu, 18 Aug 2005 02:31:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14046 for ; Thu, 18 Aug 2005 02:31:23 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5eVb-0005AT-P7 for isms@ietf.org; Thu, 18 Aug 2005 03:08:18 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 17 Aug 2005 23:31:13 -0700 X-IronPort-AV: i="3.96,120,1122879600"; d="scan'208"; a="333281226:sNHT32871180" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7I6VAoo007204; Wed, 17 Aug 2005 23:31:10 -0700 (PDT) Received: from [212.254.247.3] (ams-clip-vpn-dhcp4334.cisco.com [10.61.80.237]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7I6RaS0007538; Wed, 17 Aug 2005 23:27:36 -0700 Message-ID: <43042B28.1010701@cisco.com> Date: Thu, 18 Aug 2005 08:31:04 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1141; t=1124346458; x=1124778658; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Thu,=2018=20Aug=202005=2008=3A31=3A04=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=MrpfDj0JNEJ4oU6i8VUyQo6gJnrJAJK98bqlZ3CbY6DaLLoGQ2XfDfzCVh1Ub2qwJBLTqTwo L1v+q6SdfTlkEY/Zv1cDZhvLqA2Lc3Uxn030fvoyoPEDKrJ1Wpf5JwG0sRghjsr/K+q120oDQDv b+oofu8mUMfdrPfhqbKlPhKE= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Margaret, Margaret Wasserman wrote: > As far as I can tell, the "call home" features is concerned with which > side(s) can take the _initiative_ to establish an SNMP communication > session. Precisely, but see my earlier email. > > I'd argue that having an SNMP agent (AKA the architectural element that > response to queries) _decide_ (based on configuration, or whatever) that > it wants to be managed (monitored, configured, etc.) by a particular > manager (AKA an architectural element that sends queries) and then > having that agent establish a connection to that manager for the purpose > of being managed is a pretty big departure from the current SNMP model. Then today's model fails a large component of the market - those elements that must be managed through non-aware firewalls and NATs. It's a reflection of the changing reality that we should acknowledge. > Today, the manager is active, and the agent is completely reactive. If > an a device needs to send information asynchronously to a management > system, that is done by the notification sender on the device sending a > notify or a trap. Actually, today for a given group of elements there is NO standard management because communication is impossible. Again, nobody proposes that call-home be the primary form contact method. There are all those OTHER devices that work just as you describe ;-) Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 02:49:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5eDF-0002rc-Jc; Thu, 18 Aug 2005 02:49:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5eDD-0002rU-T6 for isms@megatron.ietf.org; Thu, 18 Aug 2005 02:49:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14758 for ; Thu, 18 Aug 2005 02:49:14 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5emt-0005Z7-8r for isms@ietf.org; Thu, 18 Aug 2005 03:26:09 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 17 Aug 2005 23:49:05 -0700 X-IronPort-AV: i="3.96,120,1122879600"; d="scan'208"; a="205818844:sNHT32068184" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7I6mv2i003451; Wed, 17 Aug 2005 23:49:02 -0700 (PDT) Received: from [212.254.247.3] (rtp-vpn2-365.cisco.com [10.82.241.109]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7I6ihtL007629; Wed, 17 Aug 2005 23:44:44 -0700 Message-ID: <43042F22.9050802@cisco.com> Date: Thu, 18 Aug 2005 08:48:02 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietfdbh@comcast.net Subject: Re: [Isms] RE: Call for consensus References: <200508171614.MAA09510@ietf.org> In-Reply-To: <200508171614.MAA09510@ietf.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2831; t=1124347495; x=1124779695; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Thu,=2018=20Aug=202005=2008=3A48=3A02=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=nAskRMtH1TeUgUbTNLHMqRLDMhAR7xtqQfyb1gXYU3aAS5Zp1qBE1mawCMK6XUWqlZjqNs+h TDpHKDASwW5AinTvX06fYiRRk9zVCAm56laSHZ0xDQNtpfH3j8iPDmhCD0ka6QIXsZuazMVnveB 0ybwRLWpYt2tWKm4ryhWs8K4= Authentication-Results: imail.cisco.com; header.from=lear@cisco.com; dkim=neutral X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave, Margaret, all, There is NO substantial difference between using SSH to connect in one direction versus using SSH to connect in the other. The ONLY difference is in the form of authentication available, as I understand it, and even THAT is subject to change, thanks to modularity. We must solve every problem that has been raised regarding mapping regardless of which way the connection starts. This includes notifications. Eliot David B Harrington wrote: > Hi, > > Architecturally, a "call home" functionality would likely impact > multiple subsystems within the RFC3411 architecture - the transport > mapping (implied subsystem), the security subsystem, and the > application subsystem (RFC3413). > > I agree with Sam that we should understand how we want to utilize this > functionality in SNMP before spending resources to developing it. So > far, I haven't seen a strong case that we need this, only an argument > that BEEP supports this, so we should want it to justify adopting > BEEP. > > If the goal is to address NAT/firewall issues, that seems to me to be > an issue to be resolved at the transport layer, or within NAT/firewall > standards rather than within SNMP. SNMP already has its own solution > for this problem - the proxy application defined in RFC3413 allows an > SNMPv3 proxy entity to be co-resident with NAT/firewall functionality > and can establish two SSH trusted tunnels, one to the entity outside > the firewall, and one to the entity inside the firewall (or in the > public vs private addressing space). > > RFC2962 has a discussion of application-level gateways and proxies and > special considerations related to SNMP. If we choose to address issues > of NAT, that should certainly be included in the discussion. > > David Harrington > dbharrington@comcast.net > > >>-----Original Message----- >>From: isms-bounces@lists.ietf.org >>[mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman >>Sent: Wednesday, August 17, 2005 11:34 AM >>To: Margaret Wasserman >>Cc: isms@ietf.org >>Subject: Re: [Isms] RE: Call for consensus >> >> >>>>>>>"Margaret" == Margaret Wasserman >> >> writes: >> >> Margaret> Hi Sam, >> >> Margaret> At 10:17 AM -0400 8/17/05, Sam Hartman wrote: >> >> It cannot. However you could set things up so that no matter >> >> which side invokes the snmp subsystem, packets are allowed to >> >> flow in both directions. >> >> Margaret> SNMP communication is bi-directional, but it is not >> Margaret> symmetrical, and I'm not sure that we can or should >> Margaret> change that under the auspices of defining a new, > > better > >> Margaret> integrated security mechanism for SNMP. >> >>Is it asymmetric at the level that we're talking about though--at > > the > >>PDU transport level? >> >>I do think the simplest level to do call home is to make the channel >>bidirectional. I do agree with you though that it is unclear what >>call home would mean in an SNMP context and that we should convince >>ourselves that we want call home and know what it means before >>specifying it. >> >>--Sam >> >> >>_______________________________________________ >>Isms mailing list >>Isms@lists.ietf.org >>https://www1.ietf.org/mailman/listinfo/isms >> > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 06:15:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hQr-0004jE-7m; Thu, 18 Aug 2005 06:15:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hQp-0004j2-QJ for isms@megatron.ietf.org; Thu, 18 Aug 2005 06:15:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24194 for ; Thu, 18 Aug 2005 06:15:29 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5i0Z-0003I8-0o for isms@ietf.org; Thu, 18 Aug 2005 06:52:27 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7IAEJTM006506; Thu, 18 Aug 2005 05:14:20 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Aug 2005 12:14:18 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 12:14:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: isms@ietf.org, Andy Bierman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Thanks Eliot. Your explanantions are very useful (at least to me). So based on what you say, then I see: - Call-Home is a new function that we do not have in current SNMPv3. - Call-Home is not a specific issue w.r.t. the WG charter, which is (in my view) to develop a securityModel that provides better integration with existing operational security infrastructure. - Call-Home is also not available (in the mandatory to implement) NetConf over SSH. So it cannot be assumed to be available in that environment. - You may have uncovered/presented a feature that operators may need or want, but I do not think that that feature falls in this WG's charter, the more since you explain that it is not well enough defined/available in NetConf (mandatory parts) and also not in current SNMPv3. - So if such a feature is indeed needed/wanted, then it seems something that may need separate attention. Possibly in a separate WG, possibly as individual submission, Possibly in Netconf as a follow on work item, and maybe later (or at lower priority) in ISMS. But I claim it is not the primary task of this WG to focus on it. Just my individual opinion. Bert p.s. Hope you feel much better today! > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Thursday, August 18, 2005 07:39 > To: Wijnen, Bert (Bert) > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > Subject: Re: [Isms] RE: Call for consensus > > > Good morning, Bert. > > I'm sorry for the delayed response- out sick yesterday. > Please see below. > > > Pls write a short paragraph or two that explains exactly > > what you mean with "call home". I think it is a term > > that means something in your mind, and possibly something > > else in my (or other peoples) mind(s). So having a good > > definition, so we all know what we're talking about is > > (I think) a good thing. > > "Call home" is the act of the managed element initiating the transport > connection to the manager for the purpose of being managed in > some way. > An example of a "call home" function would be any of the > various update > mechanisms in your Microsoft Windows / Apple / SuSE Linux software > update services. > > This function is used explicitly for several reasons. First, many > elements are unavailable through firewalls or NATs largely because the > firewall does not support transport of other than specific > UDP functions > such as DNS and/or NTP and/or certain gaming applications. > > Second, there is an inherent security benefit for devices that do not > have to (TCP/SCTP) LISTEN or otherwise accept random UDP requests as > SNMP does since the lower levels filter out communications that the > device didn't establish. The level of benefit is of course tied to > whether or not TLS is run atop the connection or IPSEC is run > below it, > but from a configuration perspective the latter isn't all that easy. > > > > > Then, I'd like to know where/how you think current SNMPv3 > > provides it. That makes it much easier for me to map > > the concept onto things I know. > > The current SNMP does not provide this function. Were we to > add it the > identities mapped must be explictly mentioned in the draft. > TCP offers > us important opportunity, however, that would not have come up had UDP > remained the transport of choice in ISMS. > > > > > Then I'd like you to uncover some more of the "obliqueness" > > of where how it is done in NetConf (over BEEP). You seem to > > claim (implicit) that NetConf "consciously decided to have > > a call-home" functionality, but I am not so sure they did. > > As you can read from the BEEP draft either side may initiate the > connection. We didn't use the term "call home", that's all. The > design-team had a discussion on this point and Margaret claimed that > since the function was available to BEEP it needn't be present in all > mappings. While I didn't think much of the answer at the time (I > prefered all mappings to offer all functions), since I could do what I > wanted to do in BEEP I was happy enough. I've CC'd Margaret > and Andy as > they can check my memory and notes (much of this occurred on > the phone). > > > In any event, if they have it via the NetConf over BEEP > > mechanism, then they cannot assume it will be present, > > because only NetConf over SSH is mandatory to implement. > > When we offer the same service we should use the same method to > accomplish the task. As I've written, I'm not wedded to BEEP but I do > think we need this capability in either and we should implement it in > the same way. At the very least it has the potential to simplify > administration while the other method has more than the potential to > complicate it. You're also re-using the same code paths which is good > for security, not to mention efficiency. > > Does this answer your questions sufficiently? > > Eliot > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 07:26:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iXg-0004X0-Hv; Thu, 18 Aug 2005 07:26:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iXe-0004Wo-TY for isms@megatron.ietf.org; Thu, 18 Aug 2005 07:26:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27305 for ; Thu, 18 Aug 2005 07:26:38 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5j7M-0005Lz-GG for isms@ietf.org; Thu, 18 Aug 2005 08:03:35 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2005 04:26:26 -0700 X-IronPort-AV: i="3.96,120,1122879600"; d="scan'208"; a="333343383:sNHT34024364" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7IBQNoo028069; Thu, 18 Aug 2005 04:26:23 -0700 (PDT) Received: from [212.254.247.3] (rtp-vpn3-7.cisco.com [10.82.216.7]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7IBMm4S009302; Thu, 18 Aug 2005 04:22:49 -0700 Message-ID: <43047060.6050806@cisco.com> Date: Thu, 18 Aug 2005 13:26:24 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" , isms@ietf.org, Margaret Wasserman , Andy Bierman Subject: Re: [Isms] RE: Call for consensus and a proposal References: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=2952; t=1124364171; x=1124796371; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus=20and=20a=20proposal| From:Eliot=20Lear=20| Date:Thu,=2018=20Aug=202005=2013=3A26=3A24=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=XGKjS70EmpqCoCc6wMa6Y8vcmqgkDelvGIboah7r6wYu7/l7D6ZBmiEvnXUhuJ2HRskfUVsq uqeqJwLGVam5JxhoZxGDlq44vjCBttZy3rntwcH8HfwjGxtSjwR4v7UKA/9XRkNmJYmulYy64/Z Bqy94vUZ7nUg28QGkS9pvQHI= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Bert, Forgive me but I'm frustrated. I won't just complain, however. I have a proposal (I've been chewing on it for a bit). See below. How could call home functionality possibly have ended up in the charter? Nobody knew we would come close to using a TCP-based approach until March when an WG-shaking event occurred. Every approach submitted and envisioned prior to that was a new security model using the existing UDP transport. But we are here now, and we are positioned to either take advantage of or miss a huge opportunity or create a mess. Anyone who thinks that firewalls or NATs routinely implement the proxy function of RFC 3413 hasn't taken a good look at the market lately. Let's at least make the best of the position we find ourselves and take corrective action. I hate to say it, but take a look at Windows. Most of the time management connections are issued by clients. Really this is no different. Let me refresh your and Dave's memory on the matter of NETCONF. The initial authors of the base spec ALWAYS envisioned a call home function. We got it for free with BEEP, which was part of the core specification until the working group forced us to separate out protocol mappings. We even had it in an early draft of the SSH specification, but cut it out [too much channel cruft as you may recall]. What's more, I claim it's easier than ever to do now. In the netconf ssh draft, what I propose is that we add some text around the following idea: - when the manager contacts the agent, it will request the "netconf" SSH service. - when the agent contacts the manager, it will request the "netconf-turn" service (or "netconf-callhome" if you prefer - I would like to reuse the SMTP term since they invented the concept, so far as I can recall). - Add text in security considerations about how to handle identity for the call home approach. I claim it's No Big Deal. It just says that the client process for callhome should probably tie to an appropriately authorized user for the function being managed. This mechanism has the added benefit of not requiring pre-existing implementations to change their code. The reason I want it in round one of netconf is that I would if I could nuke all other transport options including BEEP. Options are a necessary evil. Transport options are an UNnecessary evil. Rinse and repeat. The same process can be applied to SNMP. There is no difference. Presto. Yes, it took me a few days to come up with this in a simple way. And yes, there are a few issues surrounding the mapping for traps, but I claim we can solve those as well to peoples' satisfaction. What do people think? The result is a single mandatory transport for both NETCONF AND BEEP. Similar call home functionality for both. This is NOT Eliot's "would be nice" for a protocol. It's really important for our customers. We've always envisioned having call home functionality in our products. In fact we've had proprietary solutions for years (which is how we know it's important to our customers). The other option - and they're already talking about it - is SNMP over SIP. I kid you not. Sort of makes me think of running IP over a DHCP option, but heck anything's possible. In summary, please let's be elegant. Let's kill two birds with one stone. Let's make it easier on all of our customers in the future. And let's codify something that everyone else has been doing for years. My connectivity will be sketchy for the next few days, but will continue as best I can (although I don't want to beat a dead horse). Eliot ps: yes, I've offered to put this into real draft words for Dave. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 08:21:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jP5-0002cd-J5; Thu, 18 Aug 2005 08:21:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jP3-0002cX-I4 for isms@megatron.ietf.org; Thu, 18 Aug 2005 08:21:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00609 for ; Thu, 18 Aug 2005 08:21:48 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5jym-00075e-N8 for isms@ietf.org; Thu, 18 Aug 2005 08:58:46 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7ICLY3t023432; Thu, 18 Aug 2005 07:21:35 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Aug 2005 14:21:34 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32605@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear , isms@ietf.org, Margaret Wasserman , Andy Bierman Subject: RE: [Isms] RE: Call for consensus and a proposal Date: Thu, 18 Aug 2005 14:21:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, whatever proposal you have for NetConf should go to that WG and not to this list (or so I think). That WG will/can deal with your comment/proposal. Bert > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Thursday, August 18, 2005 13:26 > To: Wijnen, Bert (Bert); isms@ietf.org; Margaret Wasserman; > Andy Bierman > Subject: Re: [Isms] RE: Call for consensus and a proposal > > > Bert, > > Forgive me but I'm frustrated. I won't just complain, > however. I have > a proposal (I've been chewing on it for a bit). See below. > > How could call home functionality possibly have ended up in > the charter? > Nobody knew we would come close to using a TCP-based approach until > March when an WG-shaking event occurred. Every approach submitted and > envisioned prior to that was a new security model using the > existing UDP > transport. > > But we are here now, and we are positioned to either take advantage of > or miss a huge opportunity or create a mess. Anyone who thinks that > firewalls or NATs routinely implement the proxy function of RFC 3413 > hasn't taken a good look at the market lately. Let's at > least make the > best of the position we find ourselves and take corrective action. I > hate to say it, but take a look at Windows. Most of the time > management > connections are issued by clients. Really this is no different. > > Let me refresh your and Dave's memory on the matter of NETCONF. The > initial authors of the base spec ALWAYS envisioned a call > home function. > We got it for free with BEEP, which was part of the core > specification > until the working group forced us to separate out protocol > mappings. We > even had it in an early draft of the SSH specification, but cut it out > [too much channel cruft as you may recall]. What's more, I claim it's > easier than ever to do now. > > In the netconf ssh draft, what I propose is that we add some > text around > the following idea: > > - when the manager contacts the agent, it will request the "netconf" > SSH service. > - when the agent contacts the manager, it will request the > "netconf-turn" service (or "netconf-callhome" if you prefer - I > would like to reuse the SMTP term since they invented the concept, > so far as I can recall). > - Add text in security considerations about how to handle identity > for the call home approach. I claim it's No Big Deal. It just > says that the client process for callhome should probably tie to > an appropriately authorized user for the function being managed. > > This mechanism has the added benefit of not requiring pre-existing > implementations to change their code. The reason I want it > in round one > of netconf is that I would if I could nuke all other transport options > including BEEP. Options are a necessary evil. Transport > options are an > UNnecessary evil. > > Rinse and repeat. The same process can be applied to SNMP. > There is no > difference. Presto. Yes, it took me a few days to come up > with this in > a simple way. And yes, there are a few issues surrounding the mapping > for traps, but I claim we can solve those as well to peoples' > satisfaction. What do people think? > > The result is a single mandatory transport for both NETCONF AND BEEP. > Similar call home functionality for both. > > This is NOT Eliot's "would be nice" for a protocol. It's really > important for our customers. We've always envisioned having call home > functionality in our products. In fact we've had proprietary > solutions > for years (which is how we know it's important to our customers). The > other option - and they're already talking about it - is SNMP > over SIP. > I kid you not. Sort of makes me think of running IP over a DHCP > option, but heck anything's possible. > > In summary, please let's be elegant. Let's kill two birds with one > stone. Let's make it easier on all of our customers in the > future. And > let's codify something that everyone else has been doing for years. > > My connectivity will be sketchy for the next few days, but > will continue > as best I can (although I don't want to beat a dead horse). > > Eliot > ps: yes, I've offered to put this into real draft words for Dave. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 09:49:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5klW-0006JK-JA; Thu, 18 Aug 2005 09:49:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5klV-0006JB-49 for isms@megatron.ietf.org; Thu, 18 Aug 2005 09:49:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05036 for ; Thu, 18 Aug 2005 09:49:03 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lLF-00016x-Vt for isms@ietf.org; Thu, 18 Aug 2005 10:26:02 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 18 Aug 2005 06:48:56 -0700 X-IronPort-AV: i="3.96,120,1122879600"; d="scan'208"; a="333398037:sNHT32172104" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7IDmp0J014668; Thu, 18 Aug 2005 06:48:51 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id GAA02567; Thu, 18 Aug 2005 06:48:53 -0700 (PDT) From: Keith McCloghrie Message-Id: <200508181348.GAA02567@cisco.com> Subject: Re: [Isms] RE: Call for consensus To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Thu, 18 Aug 2005 06:48:53 -0700 (PDT) In-Reply-To: from "Wijnen, Bert (Bert)" at Aug 18, 2005 12:14:13 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Andy Bierman X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Bert, After a (cold) reboot, an agent will typically send a coldStart notification. If that notification is to be sent via a TCP-based transport mapping, then the agent has to setup the TCP connection. The notion of "trap-based polling" has been part of SNMP since the beginning, wherein an agent sends a notification to a manager and the manager decides to send requests to the agent based on the information contained in the notification. What Eliot describes is equivalent to a "trap-based polling" scenario for a notification such as coldStart. Keith. > Thanks Eliot. Your explanantions are very useful > (at least to me). > > So based on what you say, then I see: > - Call-Home is a new function that we do not have > in current SNMPv3. > - Call-Home is not a specific issue w.r.t. the > WG charter, which is (in my view) to develop > a securityModel that provides better integration > with existing operational security infrastructure. > - Call-Home is also not available (in the mandatory > to implement) NetConf over SSH. So it cannot be > assumed to be available in that environment. > - You may have uncovered/presented a feature that > operators may need or want, but I do not think > that that feature falls in this WG's charter, the > more since you explain that it is not well enough > defined/available in NetConf (mandatory parts) and > also not in current SNMPv3. > - So if such a feature is indeed needed/wanted, then > it seems something that may need separate attention. > Possibly in a separate WG, possibly as individual > submission, Possibly in Netconf as a follow on > work item, and maybe later (or at lower priority) > in ISMS. But I claim it is not the primary task of > this WG to focus on it. > > Just my individual opinion. > Bert > p.s. Hope you feel much better today! > > > -----Original Message----- > > From: Eliot Lear [mailto:lear@cisco.com] > > Sent: Thursday, August 18, 2005 07:39 > > To: Wijnen, Bert (Bert) > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > Subject: Re: [Isms] RE: Call for consensus > > > > > > Good morning, Bert. > > > > I'm sorry for the delayed response- out sick yesterday. > > Please see below. > > > > > Pls write a short paragraph or two that explains exactly > > > what you mean with "call home". I think it is a term > > > that means something in your mind, and possibly something > > > else in my (or other peoples) mind(s). So having a good > > > definition, so we all know what we're talking about is > > > (I think) a good thing. > > > > "Call home" is the act of the managed element initiating the transport > > connection to the manager for the purpose of being managed in > > some way. > > An example of a "call home" function would be any of the > > various update > > mechanisms in your Microsoft Windows / Apple / SuSE Linux software > > update services. > > > > This function is used explicitly for several reasons. First, many > > elements are unavailable through firewalls or NATs largely because the > > firewall does not support transport of other than specific > > UDP functions > > such as DNS and/or NTP and/or certain gaming applications. > > > > Second, there is an inherent security benefit for devices that do not > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP requests as > > SNMP does since the lower levels filter out communications that the > > device didn't establish. The level of benefit is of course tied to > > whether or not TLS is run atop the connection or IPSEC is run > > below it, > > but from a configuration perspective the latter isn't all that easy. > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > provides it. That makes it much easier for me to map > > > the concept onto things I know. > > > > The current SNMP does not provide this function. Were we to > > add it the > > identities mapped must be explictly mentioned in the draft. > > TCP offers > > us important opportunity, however, that would not have come up had UDP > > remained the transport of choice in ISMS. > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > of where how it is done in NetConf (over BEEP). You seem to > > > claim (implicit) that NetConf "consciously decided to have > > > a call-home" functionality, but I am not so sure they did. > > > > As you can read from the BEEP draft either side may initiate the > > connection. We didn't use the term "call home", that's all. The > > design-team had a discussion on this point and Margaret claimed that > > since the function was available to BEEP it needn't be present in all > > mappings. While I didn't think much of the answer at the time (I > > prefered all mappings to offer all functions), since I could do what I > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > and Andy as > > they can check my memory and notes (much of this occurred on > > the phone). > > > > > In any event, if they have it via the NetConf over BEEP > > > mechanism, then they cannot assume it will be present, > > > because only NetConf over SSH is mandatory to implement. > > > > When we offer the same service we should use the same method to > > accomplish the task. As I've written, I'm not wedded to BEEP but I do > > think we need this capability in either and we should implement it in > > the same way. At the very least it has the potential to simplify > > administration while the other method has more than the potential to > > complicate it. You're also re-using the same code paths which is good > > for security, not to mention efficiency. > > > > Does this answer your questions sufficiently? > > > > Eliot > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 10:09:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5l5c-0003ta-M9; Thu, 18 Aug 2005 10:09:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5l5a-0003tS-TN for isms@megatron.ietf.org; Thu, 18 Aug 2005 10:09:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06853 for ; Thu, 18 Aug 2005 10:09:49 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5lfL-0001rf-W1 for isms@ietf.org; Thu, 18 Aug 2005 10:46:48 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7IE8cYU012692; Thu, 18 Aug 2005 09:08:39 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 18 Aug 2005 16:08:38 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3269E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Keith McCloghrie Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 16:08:32 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c Cc: isms@ietf.org, abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Thanks for your input Keith. For the example you cite, I wonder - SNMPv3 over UDP stays as a mandatory transport I would think (We say so in the SNMP specs) - The coldStart to me seems not sensitive from a security point of view (or so I think, others may think different), so I do not see why it could not be sent unauthenticated (i.e. noAuthNoPriv) via a TRAPv2 on UDP. - And then after that, the manager can setup a connection to the agent, no? I am not saying that a call-home (as I now better understand what it means) is not a usefull feature, I am saying that it seems to add extra requirements or an extra problem that this WG was not intended to solve. And we have (had at least) trouble enough to focus on the things we ARE supposed to work on. Bert > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Thursday, August 18, 2005 15:49 > To: bwijnen@lucent.com > Cc: lear@cisco.com; isms@ietf.org; abierman@cisco.com > Subject: Re: [Isms] RE: Call for consensus > > > Bert, > > After a (cold) reboot, an agent will typically send a coldStart > notification. If that notification is to be sent via a TCP-based > transport mapping, then the agent has to setup the TCP connection. > The notion of "trap-based polling" has been part of SNMP since the > beginning, wherein an agent sends a notification to a manager and the > manager decides to send requests to the agent based on the information > contained in the notification. What Eliot describes is > equivalent to a > "trap-based polling" scenario for a notification such as coldStart. > > Keith. > > > > Thanks Eliot. Your explanantions are very useful > > (at least to me). > > > > So based on what you say, then I see: > > - Call-Home is a new function that we do not have > > in current SNMPv3. > > - Call-Home is not a specific issue w.r.t. the > > WG charter, which is (in my view) to develop > > a securityModel that provides better integration > > with existing operational security infrastructure. > > - Call-Home is also not available (in the mandatory > > to implement) NetConf over SSH. So it cannot be > > assumed to be available in that environment. > > - You may have uncovered/presented a feature that > > operators may need or want, but I do not think > > that that feature falls in this WG's charter, the > > more since you explain that it is not well enough > > defined/available in NetConf (mandatory parts) and > > also not in current SNMPv3. > > - So if such a feature is indeed needed/wanted, then > > it seems something that may need separate attention. > > Possibly in a separate WG, possibly as individual > > submission, Possibly in Netconf as a follow on > > work item, and maybe later (or at lower priority) > > in ISMS. But I claim it is not the primary task of > > this WG to focus on it. > > > > Just my individual opinion. > > Bert > > p.s. Hope you feel much better today! > > > > > -----Original Message----- > > > From: Eliot Lear [mailto:lear@cisco.com] > > > Sent: Thursday, August 18, 2005 07:39 > > > To: Wijnen, Bert (Bert) > > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > Good morning, Bert. > > > > > > I'm sorry for the delayed response- out sick yesterday. > > > Please see below. > > > > > > > Pls write a short paragraph or two that explains exactly > > > > what you mean with "call home". I think it is a term > > > > that means something in your mind, and possibly something > > > > else in my (or other peoples) mind(s). So having a good > > > > definition, so we all know what we're talking about is > > > > (I think) a good thing. > > > > > > "Call home" is the act of the managed element initiating > the transport > > > connection to the manager for the purpose of being managed in > > > some way. > > > An example of a "call home" function would be any of the > > > various update > > > mechanisms in your Microsoft Windows / Apple / SuSE Linux software > > > update services. > > > > > > This function is used explicitly for several reasons. First, many > > > elements are unavailable through firewalls or NATs > largely because the > > > firewall does not support transport of other than specific > > > UDP functions > > > such as DNS and/or NTP and/or certain gaming applications. > > > > > > Second, there is an inherent security benefit for devices > that do not > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP > requests as > > > SNMP does since the lower levels filter out > communications that the > > > device didn't establish. The level of benefit is of > course tied to > > > whether or not TLS is run atop the connection or IPSEC is run > > > below it, > > > but from a configuration perspective the latter isn't all > that easy. > > > > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > > provides it. That makes it much easier for me to map > > > > the concept onto things I know. > > > > > > The current SNMP does not provide this function. Were we to > > > add it the > > > identities mapped must be explictly mentioned in the draft. > > > TCP offers > > > us important opportunity, however, that would not have > come up had UDP > > > remained the transport of choice in ISMS. > > > > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > > of where how it is done in NetConf (over BEEP). You seem to > > > > claim (implicit) that NetConf "consciously decided to have > > > > a call-home" functionality, but I am not so sure they did. > > > > > > As you can read from the BEEP draft either side may initiate the > > > connection. We didn't use the term "call home", that's all. The > > > design-team had a discussion on this point and Margaret > claimed that > > > since the function was available to BEEP it needn't be > present in all > > > mappings. While I didn't think much of the answer at the time (I > > > prefered all mappings to offer all functions), since I > could do what I > > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > > and Andy as > > > they can check my memory and notes (much of this occurred on > > > the phone). > > > > > > > In any event, if they have it via the NetConf over BEEP > > > > mechanism, then they cannot assume it will be present, > > > > because only NetConf over SSH is mandatory to implement. > > > > > > When we offer the same service we should use the same method to > > > accomplish the task. As I've written, I'm not wedded to > BEEP but I do > > > think we need this capability in either and we should > implement it in > > > the same way. At the very least it has the potential to simplify > > > administration while the other method has more than the > potential to > > > complicate it. You're also re-using the same code paths > which is good > > > for security, not to mention efficiency. > > > > > > Does this answer your questions sufficiently? > > > > > > Eliot > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 11:06:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lyq-0002ze-MS; Thu, 18 Aug 2005 11:06:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5lym-0002zW-Vx for isms@megatron.ietf.org; Thu, 18 Aug 2005 11:06:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11469 for ; Thu, 18 Aug 2005 11:06:50 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5mYX-0003oI-QW for isms@ietf.org; Thu, 18 Aug 2005 11:43:51 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2005 08:06:43 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7IF6b0J024973; Thu, 18 Aug 2005 08:06:37 -0700 (PDT) Received: from [212.254.247.5] (rtp-vpn3-480.cisco.com [10.82.217.226]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7IF35ko011017; Thu, 18 Aug 2005 08:03:05 -0700 Message-ID: <4304A3FF.1080709@cisco.com> Date: Thu, 18 Aug 2005 17:06:39 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] RE: Call for consensus and a proposal References: <7D5D48D2CAA3D84C813F5B154F43B15507D32605@nl0006exch001u.nl.lucent.com> In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D32605@nl0006exch001u.nl.lucent.com> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=204; t=1124377387; x=1124809587; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus=20and=20a=20proposal| From:Eliot=20Lear=20| Date:Thu,=2018=20Aug=202005=2017=3A06=3A39=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=rK+4M+8kw3NEwfdpR/63Zt9/bLPqhbuFY5iVaOYWpNKfS9AwrNl1FnBa9Z9Ref9wTCrlzHFr Getb/QBdNgSKoNEKaefJjuND/VNBmIil1SKkvIS888X/ppeEElw2k4TO5QlDKZA1qhuGQJn72PZ +NgphwKWgxzv5qwL4cOdZYHw= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: Andy Bierman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wijnen, Bert (Bert) wrote: > Eliot, whatever proposal you have for NetConf should go to > that WG and not to this list (or so I think). That WG > will/can deal with your comment/proposal. Bert, just to be clear, the proposal is for BOTH groups. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 11:22:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mEE-0007RC-I0; Thu, 18 Aug 2005 11:22:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mEC-0007R7-DH for isms@megatron.ietf.org; Thu, 18 Aug 2005 11:22:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12326 for ; Thu, 18 Aug 2005 11:22:46 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5mnx-0004IM-Sa for isms@ietf.org; Thu, 18 Aug 2005 11:59:46 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 18 Aug 2005 08:22:39 -0700 Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7IFMaoo026398; Thu, 18 Aug 2005 08:22:37 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA09069; Thu, 18 Aug 2005 08:22:36 -0700 (PDT) From: Keith McCloghrie Message-Id: <200508181522.IAA09069@cisco.com> Subject: Re: [Isms] RE: Call for consensus To: bwijnen@lucent.com ("Wijnen, Bert (Bert)") Date: Thu, 18 Aug 2005 08:22:36 -0700 (PDT) In-Reply-To: from "Wijnen, Bert (Bert)" at Aug 18, 2005 04:08:32 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Cc: abierman@cisco.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Bert, > For the example you cite, I wonder > - SNMPv3 over UDP stays as a mandatory transport I would think > (We say so in the SNMP specs) > - The coldStart to me seems not sensitive from a security point > of view (or so I think, others may think different), > so I do not see why it could not be sent unauthenticated > (i.e. noAuthNoPriv) via a TRAPv2 on UDP. > - And then after that, the manager can setup a connection to the > agent, no? I gave coldStart as an example, but the issue is not specific to coldStart -- the same situation could occur for many different types of notification. If a TCP-based transport mapping has the limitation that coldStart and many other types can not be sent securely unless a manager already has a connection open to the agent, then I would suggest the WG should change its mind and reinstate UDP-based transports. > I am not saying that a call-home (as I now better understand what > it means) is not a usefull feature, I am saying that it seems > to add extra requirements or an extra problem that this WG was > not intended to solve. And we have (had at least) trouble enough > to focus on the things we ARE supposed to work on. I disagree that it is "extra". I suggest that the WG is only now coming to grips with the issues inherent in using a secure TCP-based transport mapping for the capabilities which have been part of SNMP since RFC 1157. Keith. > Bert > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Thursday, August 18, 2005 15:49 > > To: bwijnen@lucent.com > > Cc: lear@cisco.com; isms@ietf.org; abierman@cisco.com > > Subject: Re: [Isms] RE: Call for consensus > > > > > > Bert, > > > > After a (cold) reboot, an agent will typically send a coldStart > > notification. If that notification is to be sent via a TCP-based > > transport mapping, then the agent has to setup the TCP connection. > > The notion of "trap-based polling" has been part of SNMP since the > > beginning, wherein an agent sends a notification to a manager and the > > manager decides to send requests to the agent based on the information > > contained in the notification. What Eliot describes is > > equivalent to a > > "trap-based polling" scenario for a notification such as coldStart. > > > > Keith. > > > > > > > Thanks Eliot. Your explanantions are very useful > > > (at least to me). > > > > > > So based on what you say, then I see: > > > - Call-Home is a new function that we do not have > > > in current SNMPv3. > > > - Call-Home is not a specific issue w.r.t. the > > > WG charter, which is (in my view) to develop > > > a securityModel that provides better integration > > > with existing operational security infrastructure. > > > - Call-Home is also not available (in the mandatory > > > to implement) NetConf over SSH. So it cannot be > > > assumed to be available in that environment. > > > - You may have uncovered/presented a feature that > > > operators may need or want, but I do not think > > > that that feature falls in this WG's charter, the > > > more since you explain that it is not well enough > > > defined/available in NetConf (mandatory parts) and > > > also not in current SNMPv3. > > > - So if such a feature is indeed needed/wanted, then > > > it seems something that may need separate attention. > > > Possibly in a separate WG, possibly as individual > > > submission, Possibly in Netconf as a follow on > > > work item, and maybe later (or at lower priority) > > > in ISMS. But I claim it is not the primary task of > > > this WG to focus on it. > > > > > > Just my individual opinion. > > > Bert > > > p.s. Hope you feel much better today! > > > > > > > -----Original Message----- > > > > From: Eliot Lear [mailto:lear@cisco.com] > > > > Sent: Thursday, August 18, 2005 07:39 > > > > To: Wijnen, Bert (Bert) > > > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > > > > Good morning, Bert. > > > > > > > > I'm sorry for the delayed response- out sick yesterday. > > > > Please see below. > > > > > > > > > Pls write a short paragraph or two that explains exactly > > > > > what you mean with "call home". I think it is a term > > > > > that means something in your mind, and possibly something > > > > > else in my (or other peoples) mind(s). So having a good > > > > > definition, so we all know what we're talking about is > > > > > (I think) a good thing. > > > > > > > > "Call home" is the act of the managed element initiating > > the transport > > > > connection to the manager for the purpose of being managed in > > > > some way. > > > > An example of a "call home" function would be any of the > > > > various update > > > > mechanisms in your Microsoft Windows / Apple / SuSE Linux software > > > > update services. > > > > > > > > This function is used explicitly for several reasons. First, many > > > > elements are unavailable through firewalls or NATs > > largely because the > > > > firewall does not support transport of other than specific > > > > UDP functions > > > > such as DNS and/or NTP and/or certain gaming applications. > > > > > > > > Second, there is an inherent security benefit for devices > > that do not > > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP > > requests as > > > > SNMP does since the lower levels filter out > > communications that the > > > > device didn't establish. The level of benefit is of > > course tied to > > > > whether or not TLS is run atop the connection or IPSEC is run > > > > below it, > > > > but from a configuration perspective the latter isn't all > > that easy. > > > > > > > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > > > provides it. That makes it much easier for me to map > > > > > the concept onto things I know. > > > > > > > > The current SNMP does not provide this function. Were we to > > > > add it the > > > > identities mapped must be explictly mentioned in the draft. > > > > TCP offers > > > > us important opportunity, however, that would not have > > come up had UDP > > > > remained the transport of choice in ISMS. > > > > > > > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > > > of where how it is done in NetConf (over BEEP). You seem to > > > > > claim (implicit) that NetConf "consciously decided to have > > > > > a call-home" functionality, but I am not so sure they did. > > > > > > > > As you can read from the BEEP draft either side may initiate the > > > > connection. We didn't use the term "call home", that's all. The > > > > design-team had a discussion on this point and Margaret > > claimed that > > > > since the function was available to BEEP it needn't be > > present in all > > > > mappings. While I didn't think much of the answer at the time (I > > > > prefered all mappings to offer all functions), since I > > could do what I > > > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > > > and Andy as > > > > they can check my memory and notes (much of this occurred on > > > > the phone). > > > > > > > > > In any event, if they have it via the NetConf over BEEP > > > > > mechanism, then they cannot assume it will be present, > > > > > because only NetConf over SSH is mandatory to implement. > > > > > > > > When we offer the same service we should use the same method to > > > > accomplish the task. As I've written, I'm not wedded to > > BEEP but I do > > > > think we need this capability in either and we should > > implement it in > > > > the same way. At the very least it has the potential to simplify > > > > administration while the other method has more than the > > potential to > > > > complicate it. You're also re-using the same code paths > > which is good > > > > for security, not to mention efficiency. > > > > > > > > Does this answer your questions sufficiently? > > > > > > > > Eliot > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 11:46:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mbA-0005Tg-PT; Thu, 18 Aug 2005 11:46:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5mb9-0005Tb-Os for isms@megatron.ietf.org; Thu, 18 Aug 2005 11:46:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13346 for ; Thu, 18 Aug 2005 11:46:29 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nAq-0004vH-Lp for isms@ietf.org; Thu, 18 Aug 2005 12:23:30 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7IFkKZC016814 for ; Thu, 18 Aug 2005 11:46:20 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Thu, 18 Aug 2005 11:46:20 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Thu, 18 Aug 2005 11:46:20 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Aug 2005 11:46:20 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 11:46:19 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F7@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Call for consensus Thread-Index: AcWkCMHMsLj16Eh4SFOikwbwOJs85wAApcDg From: "Nelson, David" To: "Keith McCloghrie" , "Wijnen, Bert \(Bert\)" X-OriginalArrivalTime: 18 Aug 2005 15:46:20.0289 (UTC) FILETIME=[FA6BC710:01C5A40B] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:98.0684 P:95.9108 R:95.9108 S:75.9960 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Keith McCloghrie writes... > If a TCP-based transport mapping has the > limitation that coldStart and many other types can not be sent > securely unless a manager already has a connection open to the > agent, then I would suggest the WG should change its mind and > reinstate UDP-based transports. Is the issue solely the initiation of a TCP connection (session), or is the requirement to establish a security association equally at issue? For example, if we were to use DTLS would notifications be easy to implement, while they would be hard(er) using TLS? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 11:48:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5md5-0005nB-6e; Thu, 18 Aug 2005 11:48:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5md3-0005n6-HS for isms@megatron.ietf.org; Thu, 18 Aug 2005 11:48:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13438 for ; Thu, 18 Aug 2005 11:48:27 -0400 (EDT) Message-Id: <200508181548.LAA13438@ietf.org> Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nCp-0004zM-GG for isms@ietf.org; Thu, 18 Aug 2005 12:25:27 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050818154819012005ndj5e>; Thu, 18 Aug 2005 15:48:19 +0000 From: "David B Harrington" To: "'Keith McCloghrie'" , "'\"Wijnen, Bert \(Bert\)\"'" Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 11:48:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <200508181522.IAA09069@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWkCL5XF9MzyNIXTUmVOo0SRcbKHwAAmFhw X-Spam-Score: 0.1 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I have always thought that for certain purposes, we need to retain USM. This may be one of those purposes. Assuming a model where the notification sender needs to request an NMS to "call-home", the N-S will need to be configured with the address of the NMS. Configuring a shared secret, especially if the target is a fixed application rather than a user, would not seem to be a major problem. The TCP security resolves the multiple, dynamic user problem (which I think is still going to be highly limited since only IT personnel are likely to have SNMP rights anyway. So USM is not an onerous approach to solving this problem. That said, Elliot and I have already talked about him contributing some text for the SSH document, possibly including a discussion of call-home functionality. So I'll add the call-home text to the SSH document, in the section on notifications or in an appendix, have it reviewed by the other editors for wordsmithing, and publish it to the WG for consideration and discussion with the rest of the SSH solution. Is that a fair approach for everybody? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Keith McCloghrie > Sent: Thursday, August 18, 2005 11:23 AM > To: "Wijnen, Bert (Bert)" > Cc: abierman@cisco.com; isms@ietf.org > Subject: Re: [Isms] RE: Call for consensus > > Bert, > > > For the example you cite, I wonder > > - SNMPv3 over UDP stays as a mandatory transport I would think > > (We say so in the SNMP specs) > > - The coldStart to me seems not sensitive from a security point > > of view (or so I think, others may think different), > > so I do not see why it could not be sent unauthenticated > > (i.e. noAuthNoPriv) via a TRAPv2 on UDP. > > - And then after that, the manager can setup a connection to the > > agent, no? > > I gave coldStart as an example, but the issue is not specific to > coldStart -- the same situation could occur for many different > types of notification. If a TCP-based transport mapping has the > limitation that coldStart and many other types can not be sent > securely unless a manager already has a connection open to the > agent, then I would suggest the WG should change its mind and > reinstate UDP-based transports. > > > I am not saying that a call-home (as I now better understand what > > it means) is not a usefull feature, I am saying that it seems > > to add extra requirements or an extra problem that this WG was > > not intended to solve. And we have (had at least) trouble enough > > to focus on the things we ARE supposed to work on. > > I disagree that it is "extra". I suggest that the WG is only now > coming to grips with the issues inherent in using a secure TCP-based > transport mapping for the capabilities which have been part of SNMP > since RFC 1157. > > Keith. > > > > Bert > > > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Thursday, August 18, 2005 15:49 > > > To: bwijnen@lucent.com > > > Cc: lear@cisco.com; isms@ietf.org; abierman@cisco.com > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > Bert, > > > > > > After a (cold) reboot, an agent will typically send a coldStart > > > notification. If that notification is to be sent via a TCP-based > > > transport mapping, then the agent has to setup the TCP connection. > > > The notion of "trap-based polling" has been part of SNMP since the > > > beginning, wherein an agent sends a notification to a > manager and the > > > manager decides to send requests to the agent based on > the information > > > contained in the notification. What Eliot describes is > > > equivalent to a > > > "trap-based polling" scenario for a notification such as > coldStart. > > > > > > Keith. > > > > > > > > > > Thanks Eliot. Your explanantions are very useful > > > > (at least to me). > > > > > > > > So based on what you say, then I see: > > > > - Call-Home is a new function that we do not have > > > > in current SNMPv3. > > > > - Call-Home is not a specific issue w.r.t. the > > > > WG charter, which is (in my view) to develop > > > > a securityModel that provides better integration > > > > with existing operational security infrastructure. > > > > - Call-Home is also not available (in the mandatory > > > > to implement) NetConf over SSH. So it cannot be > > > > assumed to be available in that environment. > > > > - You may have uncovered/presented a feature that > > > > operators may need or want, but I do not think > > > > that that feature falls in this WG's charter, the > > > > more since you explain that it is not well enough > > > > defined/available in NetConf (mandatory parts) and > > > > also not in current SNMPv3. > > > > - So if such a feature is indeed needed/wanted, then > > > > it seems something that may need separate attention. > > > > Possibly in a separate WG, possibly as individual > > > > submission, Possibly in Netconf as a follow on > > > > work item, and maybe later (or at lower priority) > > > > in ISMS. But I claim it is not the primary task of > > > > this WG to focus on it. > > > > > > > > Just my individual opinion. > > > > Bert > > > > p.s. Hope you feel much better today! > > > > > > > > > -----Original Message----- > > > > > From: Eliot Lear [mailto:lear@cisco.com] > > > > > Sent: Thursday, August 18, 2005 07:39 > > > > > To: Wijnen, Bert (Bert) > > > > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > > > > > > > Good morning, Bert. > > > > > > > > > > I'm sorry for the delayed response- out sick yesterday. > > > > > Please see below. > > > > > > > > > > > Pls write a short paragraph or two that explains exactly > > > > > > what you mean with "call home". I think it is a term > > > > > > that means something in your mind, and possibly something > > > > > > else in my (or other peoples) mind(s). So having a good > > > > > > definition, so we all know what we're talking about is > > > > > > (I think) a good thing. > > > > > > > > > > "Call home" is the act of the managed element initiating > > > the transport > > > > > connection to the manager for the purpose of being managed in > > > > > some way. > > > > > An example of a "call home" function would be any of the > > > > > various update > > > > > mechanisms in your Microsoft Windows / Apple / SuSE > Linux software > > > > > update services. > > > > > > > > > > This function is used explicitly for several reasons. > First, many > > > > > elements are unavailable through firewalls or NATs > > > largely because the > > > > > firewall does not support transport of other than specific > > > > > UDP functions > > > > > such as DNS and/or NTP and/or certain gaming applications. > > > > > > > > > > Second, there is an inherent security benefit for devices > > > that do not > > > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP > > > requests as > > > > > SNMP does since the lower levels filter out > > > communications that the > > > > > device didn't establish. The level of benefit is of > > > course tied to > > > > > whether or not TLS is run atop the connection or IPSEC is run > > > > > below it, > > > > > but from a configuration perspective the latter isn't all > > > that easy. > > > > > > > > > > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > > > > provides it. That makes it much easier for me to map > > > > > > the concept onto things I know. > > > > > > > > > > The current SNMP does not provide this function. Were we to > > > > > add it the > > > > > identities mapped must be explictly mentioned in the draft. > > > > > TCP offers > > > > > us important opportunity, however, that would not have > > > come up had UDP > > > > > remained the transport of choice in ISMS. > > > > > > > > > > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > > > > of where how it is done in NetConf (over BEEP). You seem to > > > > > > claim (implicit) that NetConf "consciously decided to have > > > > > > a call-home" functionality, but I am not so sure they did. > > > > > > > > > > As you can read from the BEEP draft either side may > initiate the > > > > > connection. We didn't use the term "call home", > that's all. The > > > > > design-team had a discussion on this point and Margaret > > > claimed that > > > > > since the function was available to BEEP it needn't be > > > present in all > > > > > mappings. While I didn't think much of the answer at > the time (I > > > > > prefered all mappings to offer all functions), since I > > > could do what I > > > > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > > > > and Andy as > > > > > they can check my memory and notes (much of this occurred on > > > > > the phone). > > > > > > > > > > > In any event, if they have it via the NetConf over BEEP > > > > > > mechanism, then they cannot assume it will be present, > > > > > > because only NetConf over SSH is mandatory to implement. > > > > > > > > > > When we offer the same service we should use the same > method to > > > > > accomplish the task. As I've written, I'm not wedded to > > > BEEP but I do > > > > > think we need this capability in either and we should > > > implement it in > > > > > the same way. At the very least it has the potential > to simplify > > > > > administration while the other method has more than the > > > potential to > > > > > complicate it. You're also re-using the same code paths > > > which is good > > > > > for security, not to mention efficiency. > > > > > > > > > > Does this answer your questions sufficiently? > > > > > > > > > > Eliot > > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 12:04:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ms5-0001RT-Ts; Thu, 18 Aug 2005 12:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5ms5-0001RN-CV for isms@megatron.ietf.org; Thu, 18 Aug 2005 12:04:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14330 for ; Thu, 18 Aug 2005 12:03:58 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5nRp-0005S5-Kp for isms@ietf.org; Thu, 18 Aug 2005 12:41:00 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j7IG3no5032652; Thu, 18 Aug 2005 09:03:49 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j7IG3hHD005504; Thu, 18 Aug 2005 09:03:43 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j7IG3gSP005497; Thu, 18 Aug 2005 09:03:43 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 18 Aug 2005 09:03:42 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: lear@cisco.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: isms@ietf.org Subject: [Isms] What identity X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, On the Call home functionality, don't you have the same issue as described below? That is, if you want to set up a session, what identity is to be used by the client and server, and is it possible for the client to "hint" to the server the identity to use? Regards, /david t. perkins ---------- Forwarded message ---------- Date: Wed, 17 Aug 2005 21:30:04 -0700 (PDT) From: David T. Perkins To: Sam Hartman Cc: isms@ietf.org Subject: [Isms] Security question for SNMP notifications HI, The model that SNMPv3/USM uses for delivering notifications (with are traps and informs), is that the notification delivery system as defined in RFC 3413 is configured for identities at transport address targets. There may be multiple identities at each transport address, and if so, a notification may be sent to each one. On the notification receiver side, each SNMPv3/USM message is verified with the credentials of the identity specified in the notification SNMP message. When a session approach is used, if a session is created by a notification originator (the client) to a notification receiver (the server) and mutul authentication is to be done, then which identifies should be used by the client and manager. For me, the "natural" identities are the managed system for the client, and a user for the server. However, to do this, then on session creation, the client must tell the server what ID to use, since the server can support many identities. (Or at least, that is the model today, and it "lines up" with the identities used when the session is created by a "command generator". So, from a "security purity" standpoint, what options are there? I can see: 1) yes, it is Ok for the client to tell the server the identity that the server should use. 2) no, this is not OK. There can be only one identity used per transport address 3) some other approach Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 14:21:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5p0v-0007az-Qr; Thu, 18 Aug 2005 14:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5p0t-0007ah-VX for isms@megatron.ietf.org; Thu, 18 Aug 2005 14:21:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21693 for ; Thu, 18 Aug 2005 14:21:14 -0400 (EDT) Received: from pop-knobcone.atl.sa.earthlink.net ([207.69.195.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pag-0001ED-4b for isms@ietf.org; Thu, 18 Aug 2005 14:58:15 -0400 Received: from h-64-105-34-173.snvacaid.dynamic.covad.net ([64.105.34.173] helo=oemcomputer) by pop-knobcone.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5p0n-0004dM-00 for isms@ietf.org; Thu, 18 Aug 2005 14:21:09 -0400 Message-ID: <009801c5a421$cf92af20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F7@MAANDMBX2.ets.enterasys.com> Subject: Re: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 11:22:35 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Nelson, David" > To: "Keith McCloghrie" ; "Wijnen, Bert (Bert)" > Cc: ; > Sent: Thursday, August 18, 2005 8:46 AM > Subject: RE: [Isms] RE: Call for consensus > > Keith McCloghrie writes... > > > If a TCP-based transport mapping has the > > limitation that coldStart and many other types can not be sent > > securely unless a manager already has a connection open to the > > agent, then I would suggest the WG should change its mind and > > reinstate UDP-based transports. > > Is the issue solely the initiation of a TCP connection (session), or is > the requirement to establish a security association equally at issue? > For example, if we were to use DTLS would notifications be easy to > implement, while they would be hard(er) using TLS? ... Let's look to the details in order to understand the larger picture. For outgoing notifications, there are existing MIB modules defining the information that would be needed in order to know whom to call and what credentials to use, and the decision that a notification should be sent establishes that it's time to make the call. (Though not when to close the connection due to, for example, lack of activity.) For setting up a connection "in order to be managed", we do not *currently* have any MIB modules that tell the engine whom to call, and nothing that would tell it when to call, or how persistant to be in trying to make the connection. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 14:44:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pMt-0004Yh-W7; Thu, 18 Aug 2005 14:43:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pMs-0004Yc-MJ for isms@megatron.ietf.org; Thu, 18 Aug 2005 14:43:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22817 for ; Thu, 18 Aug 2005 14:43:57 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5pwf-0001pQ-66 for isms@ietf.org; Thu, 18 Aug 2005 15:20:58 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 490767; Thu, 18 Aug 2005 13:47:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <43042B28.1010701@cisco.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> <43042B28.1010701@cisco.com> Date: Thu, 18 Aug 2005 14:43:42 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot, At 8:31 AM +0200 8/18/05, Eliot Lear wrote: >Then today's model fails a large component of the market - those >elements that must be managed through non-aware firewalls and NATs. >It's a reflection of the changing reality that we should acknowledge. I think that this is a question of scope... I thought it was the purpose of this WG to specify an integrated security model for SNMP as it exists today. Today, an SNMP agent does not have a concept of initiating communication to a manager in order to be managed by that manager. You seem to be suggesting a fairly substantial extension to the SNMP model, and I personally don't see that as in-scope for this (security area) effort. It is possible, if we decide that notifications should be secured using ISMS as well as queries/responses (has that been determined?), that devices (acting as notification senders) may end-up initiating SSH sessions to notification receivers. I would personally find it more intuitive and more consistent with the SNMP model if the notification subsystem was distinct from the query/response subsystem, rather than considering a model where a device might send a notification to a manger that would then turn around and use that same SSH connection to issue queries to the device. Perhaps you think otherwise, though? Margaret _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 15:22:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pyT-0004vD-Ut; Thu, 18 Aug 2005 15:22:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5pyT-0004v8-6J for isms@megatron.ietf.org; Thu, 18 Aug 2005 15:22:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25516 for ; Thu, 18 Aug 2005 15:22:47 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.230] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5qYG-0002p4-7Z for isms@ietf.org; Thu, 18 Aug 2005 15:59:49 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B2F43E0049; Thu, 18 Aug 2005 15:21:59 -0400 (EDT) To: "David T. Perkins" References: From: Sam Hartman Date: Thu, 18 Aug 2005 15:21:59 -0400 In-Reply-To: (David T. Perkins's message of "Wed, 17 Aug 2005 21:30:04 -0700 (PDT)") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: isms@ietf.org Subject: [Isms] Re: Security question for SNMP notifications X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I'm sort of uncomfortable with this question. The identities used depend on the authentication mechanisms in use. For example ssh public keys have names nothing like Kerberos principals. Some credential types distinguish users and servers; some do not. The general answer to your question is that yes, from a security standpoint it is reasonable for a client to tell a server what identity the client wishes the server to use. However not all security mechanisms work that way. In particular, ssh' existing key exchange mechanisms do not work that way, nor do all SASL mechanisms. Also, ssh is more complicated because of how userauth works. A user does not actually present user credentials to an ssh server. Instead a user presents credentials (which may be user credentials depending on the authentication mechanism) along with a username. The ssh server authenticates the party on the other end of the transport against these credentials and then makes an authorization decision about whether those credentials are allowed to request service as the given user. So, in a given ssh session, regardless of whether the authentication method typically distinguishes user and server credentials, there is always a user name that the client has chosen (and been authorized) to act as. In summary, for ssh, the following identities are involved: * identity associated with key exchange credential used to authenticate server to client. Typically this is a credential type and type-specific identity. Examples include ssh DSA public keys, ssh RSA public keys, GSSAPI names. * An identity that the client requested service as; this is a text user name, a NAI, or some more obscure possibilities typically not used in practice. * Zero or more sets of userauth method-specific identities corresponding to credentials used in requesting service as the given username. Examples include ssh RSA public keys, SSH DSA public keys, GSSAPI names. Passwords and challenge response interactions also fall into this category although it is not clear they have associated identities so much as raw associated credentials. In terms of configuration, here is what seems natural from an ssh standpoint: * Configure user name to request service as and credentials to present for command generators. * Configure transport target and as an implementation matter either use existing ssh mechanisms for confirming that the transport target is mutually authenticated (known hosts file, Kerberos) or store authentication method specific credentials that are expected to be used. You will get much greater interoperability in the cases where you can use the ssh mechanisms but that will not work for some environments. * Configure authorization based on username for command responders; leave what credentials are allowed to request service as that user to ssh. * Configure username to request service as when sending notifications and credentials to present for notification senders. * Configure transport target for notification senders; authentication handled the same as command generators. * Notification receivers need to authorize and route/handle notifications based on the username service is requested as. Downsides of this approach: * The command generator and notification sender don't really know what credential or low level identity is used for mutual authentication. * There is an asymmetry in the authentication. * Command generators and notification senders may not actually know what access rights they have on the remote system, particularly if SecurityGroup mapping happens. LDAP and IMAP provide solutions to this by defining a new operation that lets you know what identity you end up having and what rights you have. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 16:06:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qes-0001OH-St; Thu, 18 Aug 2005 16:06:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qer-0001Nw-89 for isms@megatron.ietf.org; Thu, 18 Aug 2005 16:06:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00592 for ; Thu, 18 Aug 2005 16:06:35 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.230] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rEf-0005A1-NU for isms@ietf.org; Thu, 18 Aug 2005 16:43:37 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 4B458E0049; Thu, 18 Aug 2005 16:05:49 -0400 (EDT) To: "Wijnen, Bert (Bert)" Subject: Re: [Isms] RE: Call for consensus References: <7D5D48D2CAA3D84C813F5B154F43B15507D3269E@nl0006exch001u.nl.lucent.com> From: Sam Hartman Date: Thu, 18 Aug 2005 16:05:49 -0400 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D3269E@nl0006exch001u.nl.lucent.com> (Bert Wijnen's message of "Thu, 18 Aug 2005 16:08:32 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: abierman@cisco.com, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Wijnen," == Wijnen, Bert (Bert) writes: Wijnen,> Thanks for your input Keith. For the example you cite, I Wijnen,> wonder - SNMPv3 over UDP stays as a mandatory transport I Wijnen,> would think (We say so in the SNMP specs) - The coldStart Wijnen,> to me seems not sensitive from a security point of view Wijnen,> (or so I think, others may think different), so I do not Wijnen,> see why it could not be sent unauthenticated Wijnen,> (i.e. noAuthNoPriv) via a TRAPv2 on UDP. - You probably want notifications to be integrity protected, for example so you know that the box has actually rebooted. Similarly you want the delivery confirmation to be integrity protected. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 16:44:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rFn-0004Xp-Fn; Thu, 18 Aug 2005 16:44:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rFl-0004Xk-EI for isms@megatron.ietf.org; Thu, 18 Aug 2005 16:44:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02505 for ; Thu, 18 Aug 2005 16:44:43 -0400 (EDT) Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.230] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rpY-0006Ex-4X for isms@ietf.org; Thu, 18 Aug 2005 17:21:46 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id DC394E0049; Thu, 18 Aug 2005 16:43:50 -0400 (EDT) To: isms@ietf.org, lear@cisco.com References: <7D5D48D2CAA3D84C813F5B154F43B15507D321E4@nl0006exch001u.nl.lucent.com> <43041F0F.8010303@cisco.com> From: Sam Hartman Date: Thu, 18 Aug 2005 16:43:50 -0400 In-Reply-To: <43041F0F.8010303@cisco.com> (Eliot Lear's message of "Thu, 18 Aug 2005 07:39:27 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: housley@vigilsec.com Subject: [Isms] AD Comment: Call Home Out of Scope X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: >> Pls write a short paragraph or two that explains exactly what >> you mean with "call home". I think it is a term that means >> something in your mind, and possibly something else in my (or >> other peoples) mind(s). So having a good definition, so we all >> know what we're talking about is (I think) a good thing. Eliot> "Call home" is the act of the managed element initiating Eliot> the transport connection to the manager for the purpose of Eliot> being managed in some way. An example of a "call home" Eliot> function would be any of the various update mechanisms in Eliot> your Microsoft Windows / Apple / SuSE Linux software update Eliot> services. >> Then, I'd like to know where/how you think current SNMPv3 >> provides it. That makes it much easier for me to map the >> concept onto things I know. Eliot> The current SNMP does not provide this function. Hi, Eliot. Based on this discussion I'm going to have to rule call home functionality out of scope for ISMS. Please understand that I am not expressing any opinion on its desirability as an SNMP feature. I'm making a process decision in the interest of making forward progress within this working group. I would also like to suggest a path to you in order to pursue adding call home functionality to the scope of this working group without disrupting the process. I'd like to draw your attention to our charter: A solution must not modify the other aspects of SNMPv3 protocol as defined in STD 62 (EG, it must not create new PDU types). It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411. And if at all possible, it should also not change any other protocols either. It seems clear to me that adding a new architectural element such as call home falls outside that charter. In particular, I believe the following is out of scope: * Using call home support as an evaluation criteria for ISMS proposals. * Including call home in the ISMS charter presented to the IESG * Blocking consensus on issues in ISMS for issues that are exclusively about call home. * Blocking forward progress on documents until call home issues are resolved. I want to make it clear that I am not making any decisions regarding some related issues: * Whether we understand the ssh proposal well enough to have a consensus on it. * Whether we need a proposal in addition to a primary focus. * Identity mapping for notifications. * Whether notification and other traffic can be carried over the same session. Also, I encourage you to work with the authors of the ssh draft to investigate how to perform call home in the ssh draft. You can feel free to ask for my technical input if you feel it would be useful; I'll try to give it on a time available basis. You should also continue your investigation of call home in the beep proposal. So, if I'm ruling this out of scope, how do you get it in scope? I think you need to convince the IETF community--the same folks that placed the restriction on us that we not modify SNMP. I think you need to do so in a way that does not disrupt our forward progress if you fail to convince them. Here's how I think you should go about it. When the charter is sent to me for IESG review, ask me to send it out for external review (IETF wide) rather than just approving it; I will honor such a request. You will need a proposal ready to present to the community when the charter comes out for review. The proposal should include proposed modifications to the charter to make call home in scope. In addition you probably want to answer the following concerns: * People believe that architectural changes to SNMP should happen in the management not security area. Either convince them that this is OK in the security area, propose moving the working group, or propose splitting the work appropriately. * Address the concerns about the lack of MIBs and other facilities for managing call home. Have a proposal ready for what is involved in doing the work. * Understand concerns Bert is likely to raise and respond to them. I believe that this will create a balance between your desire to have your proposal heard and our desire to make forward progress without blocking on your proposal. I'm happy to answer any questions the chairs have in implementing these decisions. I'm also happy to answer any questions you have. Finally, if I've overlooked something and have not managed to provide you with a fair opportunity for your proposal to be heard and considered please let me know what I have missed. Sam Hartman Security Area Director _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 16:51:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rM6-0006CA-8u; Thu, 18 Aug 2005 16:51:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rM0-0006C2-H7 for isms@megatron.ietf.org; Thu, 18 Aug 2005 16:51:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02771 for ; Thu, 18 Aug 2005 16:51:10 -0400 (EDT) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5rvn-0006OU-4Q for isms@ietf.org; Thu, 18 Aug 2005 17:28:13 -0400 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.253.24.21]) by fmsfmr006.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7IKowr9024538; Thu, 18 Aug 2005 20:50:58 GMT Received: from fmsmsxvs042.fm.intel.com (fmsmsxvs042.fm.intel.com [132.233.42.128]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7IKoh2v015151; Thu, 18 Aug 2005 20:50:58 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005081813505812327 ; Thu, 18 Aug 2005 13:50:58 -0700 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 13:50:58 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 13:50:57 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 16:50:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 16:46:34 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901AE1188@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] RE: Call for consensus Thread-Index: AcWkMIY5R8tT0yrqS56W+/vEku/xJQABCixw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 18 Aug 2005 20:50:57.0013 (UTC) FILETIME=[88328A50:01C5A436] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: quoted-printable Cc: abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wijnen,> Thanks for your input Keith. For the example you cite, I Wijnen,> wonder - SNMPv3 over UDP stays as a mandatory transport I Wijnen,> would think (We say so in the SNMP specs) - The coldStart Wijnen,> to me seems not sensitive from a security point of view Wijnen,> (or so I think, others may think different), so I do not Wijnen,> see why it could not be sent unauthenticated Wijnen,> (i.e. noAuthNoPriv) via a TRAPv2 on UDP. -=20 > You probably want notifications to be integrity protected, for example > so you know that the box has actually rebooted.=20 (Speaking of traps and not notifications - as notification is a different beast. Reboot event usually generates a trap, not a notification.) Not necessarily! =20 Recall, that SNMP uses "Trap-guided Polling" approach. Received trap basically means "something probably has happened on that device, so I better go look now, rather than when my schedule suggests to check on it." Trap information merely guides as to what to look first. It would be better if traps could be trusted (i.e. integrity- and source-identity-protected), but the cost of establishing that security association may well outweight the cost of just polling when you get the trap - especially since after receiving the trap you'd probably need to poll anyway (regardless of whether you trusted the trap or not). It's not like having secure traps saves you from the need to go and poll the device. > Similarly you want > the delivery confirmation to be integrity protected. Yes, IF I'm sending a secure notification - I'd like the confirmation to be secure too. But as it was said before - support of notifications effectively turns agent into a manager wrt. the burden of figuring who to talk to and establishing the connection/session/whatever. SNMPv3/USM allowed to take it easy by using static configuration. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 18:18:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sii-00056J-WD; Thu, 18 Aug 2005 18:18:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5sig-00056E-W6 for isms@megatron.ietf.org; Thu, 18 Aug 2005 18:18:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07678 for ; Thu, 18 Aug 2005 18:18:39 -0400 (EDT) Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.ca.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tIV-0000Lz-Mt for isms@ietf.org; Thu, 18 Aug 2005 18:55:44 -0400 Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id j7IMGWZ05910; Thu, 18 Aug 2005 18:16:32 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 18:17:34 -0400 Message-ID: <085091CB2CA14E4B8B163FFC37C84E9D05CCD78A@zcarhxm0.corp.nortel.com> Thread-Topic: [Isms] RE: Call for consensus Thread-Index: AcWj/nlcpxdb/2tUS8WqovSPdOm/HQAQ2PJg From: "Glenn Waters" To: "Wijnen, Bert \(Bert\)" , "Keith McCloghrie" X-Spam-Score: 0.0 (/) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Now I am confused. We started the ISMS group in part because people were not implementing/deploying SNMPv3 due to the complexity of the security administration. Now I see the suggestion that a notification (coldStart in the example below) would go over UDP which implies that the existing SNMPv3 security model must be implemented/deployed. If we consider the existing security model to be fine enough for notifications then why even bother with ISMS? Regards, /gww=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Wijnen, Bert (Bert) > Sent: Thursday, August 18, 2005 10:09 > To: Keith McCloghrie > Cc: isms@ietf.org; abierman@cisco.com > Subject: RE: [Isms] RE: Call for consensus >=20 > Thanks for your input Keith. >=20 > For the example you cite, I wonder > - SNMPv3 over UDP stays as a mandatory transport I would think > (We say so in the SNMP specs) > - The coldStart to me seems not sensitive from a security point > of view (or so I think, others may think different), > so I do not see why it could not be sent unauthenticated > (i.e. noAuthNoPriv) via a TRAPv2 on UDP. > - And then after that, the manager can setup a connection to the > agent, no? >=20 > I am not saying that a call-home (as I now better understand what > it means) is not a usefull feature, I am saying that it seems > to add extra requirements or an extra problem that this WG was > not intended to solve. And we have (had at least) trouble enough > to focus on the things we ARE supposed to work on. >=20 > Bert >=20 > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Thursday, August 18, 2005 15:49 > > To: bwijnen@lucent.com > > Cc: lear@cisco.com; isms@ietf.org; abierman@cisco.com > > Subject: Re: [Isms] RE: Call for consensus > > > > > > Bert, > > > > After a (cold) reboot, an agent will typically send a coldStart > > notification. If that notification is to be sent via a TCP-based > > transport mapping, then the agent has to setup the TCP connection. > > The notion of "trap-based polling" has been part of SNMP since the > > beginning, wherein an agent sends a notification to a manager and the > > manager decides to send requests to the agent based on the information > > contained in the notification. What Eliot describes is > > equivalent to a > > "trap-based polling" scenario for a notification such as coldStart. > > > > Keith. > > > > > > > Thanks Eliot. Your explanantions are very useful > > > (at least to me). > > > > > > So based on what you say, then I see: > > > - Call-Home is a new function that we do not have > > > in current SNMPv3. > > > - Call-Home is not a specific issue w.r.t. the > > > WG charter, which is (in my view) to develop > > > a securityModel that provides better integration > > > with existing operational security infrastructure. > > > - Call-Home is also not available (in the mandatory > > > to implement) NetConf over SSH. So it cannot be > > > assumed to be available in that environment. > > > - You may have uncovered/presented a feature that > > > operators may need or want, but I do not think > > > that that feature falls in this WG's charter, the > > > more since you explain that it is not well enough > > > defined/available in NetConf (mandatory parts) and > > > also not in current SNMPv3. > > > - So if such a feature is indeed needed/wanted, then > > > it seems something that may need separate attention. > > > Possibly in a separate WG, possibly as individual > > > submission, Possibly in Netconf as a follow on > > > work item, and maybe later (or at lower priority) > > > in ISMS. But I claim it is not the primary task of > > > this WG to focus on it. > > > > > > Just my individual opinion. > > > Bert > > > p.s. Hope you feel much better today! > > > > > > > -----Original Message----- > > > > From: Eliot Lear [mailto:lear@cisco.com] > > > > Sent: Thursday, August 18, 2005 07:39 > > > > To: Wijnen, Bert (Bert) > > > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > > > > Good morning, Bert. > > > > > > > > I'm sorry for the delayed response- out sick yesterday. > > > > Please see below. > > > > > > > > > Pls write a short paragraph or two that explains exactly > > > > > what you mean with "call home". I think it is a term > > > > > that means something in your mind, and possibly something > > > > > else in my (or other peoples) mind(s). So having a good > > > > > definition, so we all know what we're talking about is > > > > > (I think) a good thing. > > > > > > > > "Call home" is the act of the managed element initiating > > the transport > > > > connection to the manager for the purpose of being managed in > > > > some way. > > > > An example of a "call home" function would be any of the > > > > various update > > > > mechanisms in your Microsoft Windows / Apple / SuSE Linux software > > > > update services. > > > > > > > > This function is used explicitly for several reasons. First, many > > > > elements are unavailable through firewalls or NATs > > largely because the > > > > firewall does not support transport of other than specific > > > > UDP functions > > > > such as DNS and/or NTP and/or certain gaming applications. > > > > > > > > Second, there is an inherent security benefit for devices > > that do not > > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP > > requests as > > > > SNMP does since the lower levels filter out > > communications that the > > > > device didn't establish. The level of benefit is of > > course tied to > > > > whether or not TLS is run atop the connection or IPSEC is run > > > > below it, > > > > but from a configuration perspective the latter isn't all > > that easy. > > > > > > > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > > > provides it. That makes it much easier for me to map > > > > > the concept onto things I know. > > > > > > > > The current SNMP does not provide this function. Were we to > > > > add it the > > > > identities mapped must be explictly mentioned in the draft. > > > > TCP offers > > > > us important opportunity, however, that would not have > > come up had UDP > > > > remained the transport of choice in ISMS. > > > > > > > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > > > of where how it is done in NetConf (over BEEP). You seem to > > > > > claim (implicit) that NetConf "consciously decided to have > > > > > a call-home" functionality, but I am not so sure they did. > > > > > > > > As you can read from the BEEP draft either side may initiate the > > > > connection. We didn't use the term "call home", that's all. The > > > > design-team had a discussion on this point and Margaret > > claimed that > > > > since the function was available to BEEP it needn't be > > present in all > > > > mappings. While I didn't think much of the answer at the time (I > > > > prefered all mappings to offer all functions), since I > > could do what I > > > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > > > and Andy as > > > > they can check my memory and notes (much of this occurred on > > > > the phone). > > > > > > > > > In any event, if they have it via the NetConf over BEEP > > > > > mechanism, then they cannot assume it will be present, > > > > > because only NetConf over SSH is mandatory to implement. > > > > > > > > When we offer the same service we should use the same method to > > > > accomplish the task. As I've written, I'm not wedded to > > BEEP but I do > > > > think we need this capability in either and we should > > implement it in > > > > the same way. At the very least it has the potential to simplify > > > > administration while the other method has more than the > > potential to > > > > complicate it. You're also re-using the same code paths > > which is good > > > > for security, not to mention efficiency. > > > > > > > > Does this answer your questions sufficiently? > > > > > > > > Eliot > > > > > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 18:50:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tDE-00050h-9L; Thu, 18 Aug 2005 18:50:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tD1-0004wl-8r for isms@megatron.ietf.org; Thu, 18 Aug 2005 18:50:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09468 for ; Thu, 18 Aug 2005 18:49:59 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5tmp-0001DB-Li for isms@ietf.org; Thu, 18 Aug 2005 19:27:04 -0400 Received: from h-64-105-34-173.snvacaid.dynamic.covad.net ([64.105.34.173] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5tCv-0000fY-00 for isms@ietf.org; Thu, 18 Aug 2005 18:49:57 -0400 Message-ID: <003901c5a447$5ebb65a0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> <43047060.6050806@cisco.com> Subject: Re: [Isms] RE: Call for consensus and a proposal Date: Thu, 18 Aug 2005 15:51:28 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Eliot Lear" > To: "Wijnen, Bert (Bert)" ; ; "Margaret Wasserman" ; "Andy Bierman" > Sent: Thursday, August 18, 2005 4:26 AM > Subject: Re: [Isms] RE: Call for consensus and a proposal ... > Nobody knew we would come close to using a TCP-based approach until > March when an WG-shaking event occurred. Every approach submitted and > envisioned prior to that was a new security model using the existing UDP > transport. ... Not so. The TLSM proposal the evaluation team looked at in http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt explicitly provided for TLS/TCP as a transport. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 19:09:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tW6-0005gd-Ri; Thu, 18 Aug 2005 19:09:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tW5-0005gY-BQ for isms@megatron.ietf.org; Thu, 18 Aug 2005 19:09:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13276 for ; Thu, 18 Aug 2005 19:09:42 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5u5v-0002kH-6d for isms@ietf.org; Thu, 18 Aug 2005 19:46:47 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7IN8TTp016513; Thu, 18 Aug 2005 18:08:33 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 01:08:28 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32766@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Glenn Waters , Keith McCloghrie Subject: RE: [Isms] RE: Call for consensus Date: Fri, 19 Aug 2005 01:08:28 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Cc: isms@ietf.org, abierman@cisco.com X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org A simple noAuthNoPriv trap for a coldstart (or similar initial call home) only needs the default config parameters as described in RFC3411-3415. It does not require extensive SNMP configuration or config of SNMP security parameters. Those will be needed when you start to do serious SNMP work. Or so is my view. Bert > -----Original Message----- > From: Glenn Waters [mailto:gww@nortel.com] > Sent: Friday, August 19, 2005 00:18 > To: Wijnen, Bert (Bert); Keith McCloghrie > Cc: isms@ietf.org; abierman@cisco.com > Subject: RE: [Isms] RE: Call for consensus > > > Now I am confused. > > We started the ISMS group in part because people were not > implementing/deploying SNMPv3 due to the complexity of the security > administration. Now I see the suggestion that a notification > (coldStart > in the example below) would go over UDP which implies that > the existing > SNMPv3 security model must be implemented/deployed. If we consider the > existing security model to be fine enough for notifications then why > even bother with ISMS? > > Regards, /gww > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] > On > > Behalf Of Wijnen, Bert (Bert) > > Sent: Thursday, August 18, 2005 10:09 > > To: Keith McCloghrie > > Cc: isms@ietf.org; abierman@cisco.com > > Subject: RE: [Isms] RE: Call for consensus > > > > Thanks for your input Keith. > > > > For the example you cite, I wonder > > - SNMPv3 over UDP stays as a mandatory transport I would think > > (We say so in the SNMP specs) > > - The coldStart to me seems not sensitive from a security point > > of view (or so I think, others may think different), > > so I do not see why it could not be sent unauthenticated > > (i.e. noAuthNoPriv) via a TRAPv2 on UDP. > > - And then after that, the manager can setup a connection to the > > agent, no? > > > > I am not saying that a call-home (as I now better understand what > > it means) is not a usefull feature, I am saying that it seems > > to add extra requirements or an extra problem that this WG was > > not intended to solve. And we have (had at least) trouble enough > > to focus on the things we ARE supposed to work on. > > > > Bert > > > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Thursday, August 18, 2005 15:49 > > > To: bwijnen@lucent.com > > > Cc: lear@cisco.com; isms@ietf.org; abierman@cisco.com > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > Bert, > > > > > > After a (cold) reboot, an agent will typically send a coldStart > > > notification. If that notification is to be sent via a TCP-based > > > transport mapping, then the agent has to setup the TCP connection. > > > The notion of "trap-based polling" has been part of SNMP since the > > > beginning, wherein an agent sends a notification to a manager and > the > > > manager decides to send requests to the agent based on the > information > > > contained in the notification. What Eliot describes is > > > equivalent to a > > > "trap-based polling" scenario for a notification such as > coldStart. > > > > > > Keith. > > > > > > > > > > Thanks Eliot. Your explanantions are very useful > > > > (at least to me). > > > > > > > > So based on what you say, then I see: > > > > - Call-Home is a new function that we do not have > > > > in current SNMPv3. > > > > - Call-Home is not a specific issue w.r.t. the > > > > WG charter, which is (in my view) to develop > > > > a securityModel that provides better integration > > > > with existing operational security infrastructure. > > > > - Call-Home is also not available (in the mandatory > > > > to implement) NetConf over SSH. So it cannot be > > > > assumed to be available in that environment. > > > > - You may have uncovered/presented a feature that > > > > operators may need or want, but I do not think > > > > that that feature falls in this WG's charter, the > > > > more since you explain that it is not well enough > > > > defined/available in NetConf (mandatory parts) and > > > > also not in current SNMPv3. > > > > - So if such a feature is indeed needed/wanted, then > > > > it seems something that may need separate attention. > > > > Possibly in a separate WG, possibly as individual > > > > submission, Possibly in Netconf as a follow on > > > > work item, and maybe later (or at lower priority) > > > > in ISMS. But I claim it is not the primary task of > > > > this WG to focus on it. > > > > > > > > Just my individual opinion. > > > > Bert > > > > p.s. Hope you feel much better today! > > > > > > > > > -----Original Message----- > > > > > From: Eliot Lear [mailto:lear@cisco.com] > > > > > Sent: Thursday, August 18, 2005 07:39 > > > > > To: Wijnen, Bert (Bert) > > > > > Cc: isms@ietf.org; Margaret Wasserman; Andy Bierman > > > > > Subject: Re: [Isms] RE: Call for consensus > > > > > > > > > > > > > > > Good morning, Bert. > > > > > > > > > > I'm sorry for the delayed response- out sick yesterday. > > > > > Please see below. > > > > > > > > > > > Pls write a short paragraph or two that explains exactly > > > > > > what you mean with "call home". I think it is a term > > > > > > that means something in your mind, and possibly something > > > > > > else in my (or other peoples) mind(s). So having a good > > > > > > definition, so we all know what we're talking about is > > > > > > (I think) a good thing. > > > > > > > > > > "Call home" is the act of the managed element initiating > > > the transport > > > > > connection to the manager for the purpose of being managed in > > > > > some way. > > > > > An example of a "call home" function would be any of the > > > > > various update > > > > > mechanisms in your Microsoft Windows / Apple / SuSE Linux > software > > > > > update services. > > > > > > > > > > This function is used explicitly for several reasons. First, > many > > > > > elements are unavailable through firewalls or NATs > > > largely because the > > > > > firewall does not support transport of other than specific > > > > > UDP functions > > > > > such as DNS and/or NTP and/or certain gaming applications. > > > > > > > > > > Second, there is an inherent security benefit for devices > > > that do not > > > > > have to (TCP/SCTP) LISTEN or otherwise accept random UDP > > > requests as > > > > > SNMP does since the lower levels filter out > > > communications that the > > > > > device didn't establish. The level of benefit is of > > > course tied to > > > > > whether or not TLS is run atop the connection or IPSEC is run > > > > > below it, > > > > > but from a configuration perspective the latter isn't all > > > that easy. > > > > > > > > > > > > > > > > > Then, I'd like to know where/how you think current SNMPv3 > > > > > > provides it. That makes it much easier for me to map > > > > > > the concept onto things I know. > > > > > > > > > > The current SNMP does not provide this function. Were we to > > > > > add it the > > > > > identities mapped must be explictly mentioned in the draft. > > > > > TCP offers > > > > > us important opportunity, however, that would not have > > > come up had UDP > > > > > remained the transport of choice in ISMS. > > > > > > > > > > > > > > > > > Then I'd like you to uncover some more of the "obliqueness" > > > > > > of where how it is done in NetConf (over BEEP). You seem to > > > > > > claim (implicit) that NetConf "consciously decided to have > > > > > > a call-home" functionality, but I am not so sure they did. > > > > > > > > > > As you can read from the BEEP draft either side may > initiate the > > > > > connection. We didn't use the term "call home", that's all. > The > > > > > design-team had a discussion on this point and Margaret > > > claimed that > > > > > since the function was available to BEEP it needn't be > > > present in all > > > > > mappings. While I didn't think much of the answer at the time > (I > > > > > prefered all mappings to offer all functions), since I > > > could do what I > > > > > wanted to do in BEEP I was happy enough. I've CC'd Margaret > > > > > and Andy as > > > > > they can check my memory and notes (much of this occurred on > > > > > the phone). > > > > > > > > > > > In any event, if they have it via the NetConf over BEEP > > > > > > mechanism, then they cannot assume it will be present, > > > > > > because only NetConf over SSH is mandatory to implement. > > > > > > > > > > When we offer the same service we should use the same > method to > > > > > accomplish the task. As I've written, I'm not wedded to > > > BEEP but I do > > > > > think we need this capability in either and we should > > > implement it in > > > > > the same way. At the very least it has the potential to > simplify > > > > > administration while the other method has more than the > > > potential to > > > > > complicate it. You're also re-using the same code paths > > > which is good > > > > > for security, not to mention efficiency. > > > > > > > > > > Does this answer your questions sufficiently? > > > > > > > > > > Eliot > > > > > > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 19:34:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tu6-0007lp-5R; Thu, 18 Aug 2005 19:34:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5tu5-0007lh-8f for isms@megatron.ietf.org; Thu, 18 Aug 2005 19:34:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16584 for ; Thu, 18 Aug 2005 19:34:28 -0400 (EDT) Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5uTt-0004DR-FQ for isms@ietf.org; Thu, 18 Aug 2005 20:11:33 -0400 Received: from h-64-105-34-173.snvacaid.dynamic.covad.net ([64.105.34.173] helo=oemcomputer) by pop-satin.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E5ttt-0002LD-00 for isms@ietf.org; Thu, 18 Aug 2005 19:34:22 -0400 Message-ID: <008501c5a44d$92d38560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <7D5D48D2CAA3D84C813F5B154F43B15507D32766@nl0006exch001u.nl.lucent.com> Subject: Re: [Isms] RE: Call for consensus Date: Thu, 18 Aug 2005 16:35:52 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "Wijnen, Bert (Bert)" > To: "Glenn Waters" ; "Keith McCloghrie" > Cc: ; > Sent: Thursday, August 18, 2005 4:08 PM > Subject: RE: [Isms] RE: Call for consensus > > A simple noAuthNoPriv trap for a coldstart (or similar > initial call home) only needs the default config > parameters as described in RFC3411-3415. It does not > require extensive SNMP configuration or config > of SNMP security parameters. Those will be needed > when you start to do serious SNMP work. > > Or so is my view. ... In order for that notification to be delivered, *something* will have had to have created the following non-default entries: 1) an entry in snmpTargetAddrTable, indexed by snmpTargetAddrName, consisting of snmpTargetAddrTDomain, snmpTargetAddrTAddress, snmpTargetAddrTimeout, snmpTargetAddrRetryCount (these last two items have usable DEFVALs), snmpTargetAddrTagList, snmpTargetAddrParams, snmpTargetAddrStorageType (this item also has a usable DEFVAL) and snmpTargetAddrRowStatus 2) an entry in snmpTargetParamsTable (to be indexed by snmpTargetAddrParams), consisting of snmpTargetParamsMPModel, snmpTargetParamsSecurityModel, snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel, snmpTargetParamsStorageType (this last one having a usable DEFVAL), and snmpTargetParamsRowStatus 3) an entry in snmpNotifyTable (indexed by snmpNotifyName) consisting of snmpNotifyTag, snmpNotifyType, snmpNotifyStorageType (has a usable DEFVAL) and snmpNotifyRowStatus 4) an entry in snmpNotifyFilterProfileTable (indexed by snmpTargetParamsName) consisting of snmpNotifyFilterProfileName, snmpNotifyFilterProfileStorType (has a usable DEFVAL) and snmpNotifyFilterProfileRowStatus 5) an entry in snmpNotifyFilterTable (indexed by snmpNotifyFilterProfileName and snmpNotifyFilterSubtree) consisting of snmpNotifyFilterMask, snmpNotifyFilterType, snmpNotifyFilterStorageType (these three have potential usable DEFVALs), and snmpNotifyFilterRowStatus Appendix A of RFC 3413 gives a worked-out example. Whether this is "extensive" configuration or not is left to the reader. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 18 19:42:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5u1g-0001ZF-Jg; Thu, 18 Aug 2005 19:42:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5u1f-0001ZA-9j for isms@megatron.ietf.org; Thu, 18 Aug 2005 19:42:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16916 for ; Thu, 18 Aug 2005 19:42:20 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5ubT-0004QI-BO for isms@ietf.org; Thu, 18 Aug 2005 20:19:25 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7INg8fu018154; Thu, 18 Aug 2005 18:42:09 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 01:42:08 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3276B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Randy Presuhn , isms@ietf.org Subject: RE: [Isms] RE: Call for consensus Date: Fri, 19 Aug 2005 01:42:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org And I think we explicitly did putthose examples in the RFC so that people could (reasonably easy) configure those. I guess I am biased, having done various implementations and so it may seem more "reasonably easy" to me than to others. I also think if you look at the text of the parameters in Appendix A in RFC3413, that it does not look as awfull as it looks in the unformatted text provided by Randy below. Bert > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Randy Presuhn > Sent: Friday, August 19, 2005 01:36 > To: isms@ietf.org > Subject: Re: [Isms] RE: Call for consensus > > > Hi - > > > From: "Wijnen, Bert (Bert)" > > To: "Glenn Waters" ; "Keith McCloghrie" > > > Cc: ; > > Sent: Thursday, August 18, 2005 4:08 PM > > Subject: RE: [Isms] RE: Call for consensus > > > > A simple noAuthNoPriv trap for a coldstart (or similar > > initial call home) only needs the default config > > parameters as described in RFC3411-3415. It does not > > require extensive SNMP configuration or config > > of SNMP security parameters. Those will be needed > > when you start to do serious SNMP work. > > > > Or so is my view. > ... > > In order for that notification to be delivered, *something* > will have had to have created the following non-default entries: > > 1) an entry in snmpTargetAddrTable, indexed by > snmpTargetAddrName, consisting of > snmpTargetAddrTDomain, snmpTargetAddrTAddress, > snmpTargetAddrTimeout, > snmpTargetAddrRetryCount (these last two items have usable > DEFVALs), > snmpTargetAddrTagList, snmpTargetAddrParams, > snmpTargetAddrStorageType > (this item also has a usable DEFVAL) and snmpTargetAddrRowStatus > > 2) an entry in snmpTargetParamsTable (to be indexed by > snmpTargetAddrParams), > consisting of snmpTargetParamsMPModel, > snmpTargetParamsSecurityModel, > snmpTargetParamsSecurityName, snmpTargetParamsSecurityLevel, > snmpTargetParamsStorageType (this last one having a usable > DEFVAL), and > snmpTargetParamsRowStatus > > 3) an entry in snmpNotifyTable (indexed by snmpNotifyName) > consisting of snmpNotifyTag, snmpNotifyType, snmpNotifyStorageType > (has a usable DEFVAL) and snmpNotifyRowStatus > > 4) an entry in snmpNotifyFilterProfileTable (indexed by > snmpTargetParamsName) > consisting of snmpNotifyFilterProfileName, > snmpNotifyFilterProfileStorType > (has a usable DEFVAL) and snmpNotifyFilterProfileRowStatus > > 5) an entry in snmpNotifyFilterTable (indexed by > snmpNotifyFilterProfileName > and snmpNotifyFilterSubtree) consisting of snmpNotifyFilterMask, > snmpNotifyFilterType, snmpNotifyFilterStorageType (these > three have potential > usable DEFVALs), and snmpNotifyFilterRowStatus > > Appendix A of RFC 3413 gives a worked-out example. > Whether this is "extensive" configuration or not is left to > the reader. > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 04:08:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61vh-0005Xd-8V; Fri, 19 Aug 2005 04:08:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61vg-0005Wy-9m for isms@megatron.ietf.org; Fri, 19 Aug 2005 04:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19518 for ; Fri, 19 Aug 2005 04:08:42 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E62VZ-0000Z1-4Y for isms@ietf.org; Fri, 19 Aug 2005 04:45:51 -0400 Received: from [192.168.0.112] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 60F751BAC4D for ; Fri, 19 Aug 2005 10:08:32 +0200 (CEST) Date: Fri, 19 Aug 2005 10:08:34 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] WG status X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, We still have two tasks to complete by the and of August: - achieving consensus on two direction decisions 1. The ISMS WG will work on one transport protocol only 2. ISMS will use SSH as transport protocol - achieving rough consensus on our new charter Ken and I sense consensus on decision 1. Concerning decision 2 we had a discussion on using BEEP instead of SSH or in addition to it. The most often stated argument in favor of BEEP was better support for a feature that named "call home". Since this is not a function SNMP currently supports, Ken and I fully agree with Sam that this cannot be a key argument for our discussion. Extending SNMP by features not related to security is out of the scope of ISMS (and of the security area). For getting closer to consensus I would like to know which other arguments against SSH or for BEEP (or other alternatives) should be considered. Thanks, Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 04:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E625W-0008N7-Dc; Fri, 19 Aug 2005 04:18:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E625U-0008N1-BM for isms@megatron.ietf.org; Fri, 19 Aug 2005 04:18:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19885 for ; Fri, 19 Aug 2005 04:18:50 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E62fP-0000ov-2l for isms@ietf.org; Fri, 19 Aug 2005 04:55:59 -0400 Received: from [192.168.0.112] (bro67-3-82-231-136-16.fbx.proxad.net [82.231.136.16]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A56411BAC4D for ; Fri, 19 Aug 2005 10:18:42 +0200 (CEST) Date: Fri, 19 Aug 2005 10:18:44 +0200 From: Juergen Quittek To: isms@ietf.org Subject: RE: [Isms] ISMS charter discussion Message-ID: <2B9BF5FAB4C5547D819BAE81@[192.168.1.111]> In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Please have a look at the outline of our new charter. You will find the current outline below. Particularly, I would like you to express your opinion about - explicitly mentioning securityName and securityGroup - having a revision RFC 3430 as one of our work items Ken and I will turn the outline into a text version and post it on Monday. Then we will have next week for discussing wordings. Thanks, Juergen ----------------------- ISMS WG charter outline ----------------------- Background - USM has limited deployment - no standard for integrating key and user management into deployed authentication infrastructures - SSH is widely deployed - SSH integration into AAA, e.g., RADIUS, is available WG goals - define a new SNMP security model that utilzes the SSH protocol to provide message security services for SNMP - compliancy with SNMPv3 architecture, no modification of SNMPv3 - work on new access control models and VACM mappings out of scope (except for mapping via securityName or securityGroup) - open to further transport mappings, such as BEEP, TLS, ... - following a session-based approach - define a standard method for mapping from AAA-provisioned authorization parameter(s) to SNMP securityName and securityGroup Work Items: - specify how transport mapping security models (TMSMs) fit into the SNMPv3 architecture - specify RADIUS attributes used to populate securityname and other SNMP parameters - define how to use SSH between the two snmp engines - specify the SSH security model for SNMP Documents - A document that specifies how transport mapping security models (TMSMs) fit into the SNMPv3 architecture and which defines the requirements for transport mapping security models. - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) - A document specifying the SSH security model for SNMP. This specification must comply with the TMSM requirements. - An Applicability statement that sets up reasonable mandatory to implement methods. ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it with the SSH transport model (or move RFC 3430 to historic) ? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 05:14:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62xT-00059R-Vd; Fri, 19 Aug 2005 05:14:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62xT-000591-1N for isms@megatron.ietf.org; Fri, 19 Aug 2005 05:14:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21701 for ; Fri, 19 Aug 2005 05:14:36 -0400 (EDT) Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E63XN-0002FL-AY for isms@ietf.org; Fri, 19 Aug 2005 05:51:46 -0400 Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7J9EQl0023275 for ; Fri, 19 Aug 2005 11:14:26 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id j7J9EOkH015113 for ; Fri, 19 Aug 2005 11:14:26 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 19 Aug 2005 11:14:15 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Aug 2005 11:14:15 +0200 Message-ID: Thread-Topic: radius usage Thread-Index: AcWklwyDBdy9A/diTlGo4zqL7FeyCgABuHmA From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 19 Aug 2005 09:14:15.0493 (UTC) FILETIME=[5EF68750:01C5A49E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: Subject: [Isms] radius usage X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org hi all=20 i was wondering about the purpose of the radius interaction.=20 what is the purpose of the radius interaction? =20 a) key transport b) authorization in case of (b): what is the authorization decision that is made by the radius server? =20 what input by the radius client is needed in order for the radius server to make a decision? if a decision is made is it binary (accept/reject)? =20 ciao hannes _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 06:59:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64am-0004ze-ME; Fri, 19 Aug 2005 06:59:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E64ak-0004zZ-V1 for isms@megatron.ietf.org; Fri, 19 Aug 2005 06:59:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26054 for ; Fri, 19 Aug 2005 06:59:15 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E65Ag-0005FC-U3 for isms@ietf.org; Fri, 19 Aug 2005 07:36:27 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7JAx3c8021415; Fri, 19 Aug 2005 05:59:04 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 12:59:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32865@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Juergen Quittek , isms@ietf.org Subject: RE: [Isms] ISMS charter discussion Date: Fri, 19 Aug 2005 12:59:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Juergen Quittek > Sent: Friday, August 19, 2005 10:19 > To: isms@ietf.org > Subject: RE: [Isms] ISMS charter discussion > > > Dear all, > > Please have a look at the outline of our new charter. > You will find the current outline below. > > Particularly, I would like you to express your opinion about > > - explicitly mentioning securityName and securityGroup We do have a concept of "securityName" in SNMPv3. So mentioning that is fine. We do not have the concept of "securityGroup" in SNMPv3 (I did not recal we have one, but a "grep securityGroup RFC341*" also does not find a hit. I guess what you mean is that you want to be able to map the SSH credentials (not sure I use the right term here) into a groupName (this term is used in SNMP documents). In SNMP we control access based on the groupName or the "who" (among otehr things). See RFC3415 page 8. In the case of USM we use the securityModel (USM) and the userName in the msgSecurityParameters (securityModel-specific parameters inside a SNMPv3 Message) which gets mapped (1-1) into the security-model-independent securityName. The securityModel and securityName are used to map to a groupName, which is then one of the keys to find out if access can be granted. If the securityModel is gonna be (for example) SSM (SSH-based Security Model), then we have the securityModel. We then need to decide how we map the SSH identity (correct term) into a securityName. Once we have those two, I think it is a matter of populating an entry (entries) in the vacmSecurityToGroupTable and bingo, we're all set. So for me, it seems we can explicitly mention securityName but for me it seems that the securityModel and securityName should map (via vacmSecurityToGroupTable) into a groupName. Or have I missed some discussion as to why this would be done in a different way (which then in my view is not compliant with the SNMPv3 architecture, or at least it is not yet obvious to me how it would be compliant). > - having a revision RFC 3430 as one of our work items > RFC3430 is experimental. I'd say that once we have completed our initial work, we could then see if we have time/energy to update 3430 or just declare it HISTORIC. I would not worry too much about it at this point in time. More below > Ken and I will turn the outline into a text version and post > it on Monday. Then we will have next week for discussing wordings. > > Thanks, > > Juergen > > ----------------------- > ISMS WG charter outline > ----------------------- > > Background > - USM has limited deployment > - no standard for integrating key and user management into > deployed authentication infrastructures > - SSH is widely deployed > - SSH integration into AAA, e.g., RADIUS, is available > > WG goals > - define a new SNMP security model that utilzes the SSH protocol > to provide message security services for SNMP > - compliancy with SNMPv3 architecture, no modification of SNMPv3 > - work on new access control models and VACM mappings out of scope > (except for mapping via securityName or securityGroup) I would move this to the end of this list (i.e. list the things that are in-scope first). May I suggest rewording into - work on new access control models and new VACM mappings out of scope (except for mapping from SSH identity into securityName, which together with the new securityModel will map into the VACM groupName) > - open to further transport mappings, such as BEEP, TLS, ... I would move this to position it as the last item of in-scope work items I am also not sure about the wording. It makes the WG charter pretty much open ended and so it can bite us back since it opens us up for all sorts of ideas to come to our WG. We were going to try and come to a focused WG charter that we can finish in a reasonable amount of time. Once we finish it we can entertain the idea of "close WG or recharter" and so the at that time we'd be "open to consider to charter additional transport mappings". If the WG decides now that they want to add (at lower priority in my view) an additional (optional) mapping onto BEEP, then I could live with that, but let us not list several (and certainly not "...." that makes it far too open ended). > - following a session-based approach > - define a standard method for mapping from AAA-provisioned > authorization parameter(s) to SNMP securityName and securityGroup > > Work Items: > - specify how transport mapping security models (TMSMs) > fit into the SNMPv3 architecture > - specify RADIUS attributes used to populate > securityname and other SNMP parameters > - define how to use SSH between the two snmp engines > - specify the SSH security model for SNMP > > Documents > - A document that specifies how transport mapping security models > (TMSMs) fit into the SNMPv3 architecture and which defines the > requirements for transport mapping security models. > - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) As far as I know, the RADEXT WG has an overloaded plate already. I have seen at least one RADEXT WG chair participate in these discussions, so maybe he can estimate how much room/energy that WG has to work on this. So I would rather keep it in ISMS and instead change "(in RADEXT WG?)" into "(in consultancy with RADEXT WG)" or some such. > - A document specifying the SSH security model for SNMP. > This specification must comply with the TMSM requirements. > - An Applicability statement that sets up reasonable mandatory to > implement methods. > ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it > with the SSH transport model (or move RFC 3430 to historic) ? > See my comment on 3430 above Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 09:06:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66Zt-00085g-Jq; Fri, 19 Aug 2005 09:06:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66Zr-00085K-W5 for isms@megatron.ietf.org; Fri, 19 Aug 2005 09:06:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01744 for ; Fri, 19 Aug 2005 09:06:29 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E679o-0000F9-8f for isms@ietf.org; Fri, 19 Aug 2005 09:43:41 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 19 Aug 2005 06:06:21 -0700 X-IronPort-AV: i="3.96,124,1122879600"; d="scan'208"; a="333806195:sNHT35237940" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7JD6F0J029096; Fri, 19 Aug 2005 06:06:15 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4321.cisco.com [10.61.80.224]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7JD2c75021022; Fri, 19 Aug 2005 06:02:38 -0700 Message-ID: <4305D945.50103@cisco.com> Date: Fri, 19 Aug 2005 15:06:13 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Hartman References: <7D5D48D2CAA3D84C813F5B154F43B15507D321E4@nl0006exch001u.nl.lucent.com> <43041F0F.8010303@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1891; t=1124456561; x=1124888761; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20AD=20Comment=3A=20Call=20Home=20Out=20of=20Scope| From:Eliot=20Lear=20| Date:Fri,=2019=20Aug=202005=2015=3A06=3A13=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=hq994kG7GPkReTAgeDdV17hQPqNaczxCfDhUODFfAcAFosN1Od1cF/l39dLysV2fUKW/5OTt idUR36t3+fBbQbMYyFh5jYazfewIMokWzkcbtFHB5aMOKwRV/x4vHou8JwNtgdwKLtuKWnITzhg cMtXUbkEA6vKvqkBtxo4s9rs= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org, Andy Bierman , housley@vigilsec.com, simon@switch.ch, netconf@ietf.org Subject: [Isms] Re: AD Comment: Call Home Out of Scope X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Understand, Sam, that what I care about are the following factors: - providing a mechanism that is useful to the operations community - properly making use of existing standardized components - minimizing the number of redundant components I look at this from a systems perspective. One protocol is but a piece of that system. If in the end it looks as though you, the WG, or the IESG is ignoring these principles (as it appears now), I will appeal as is appropriate. As to your below: > I'd like to draw your attention to our charter: > > A solution must not modify the other aspects of SNMPv3 protocol as > defined in STD 62 (EG, it must not create new PDU types). It should > also be compliant with the security model architectural block of > SNMPv3, as outlined in RFC 3411. And if at all possible, it should > also not change any other protocols either. > > It seems clear to me that adding a new architectural element such as > call home falls outside that charter. I would ask that you please explain to me how you came to this conclusion. Further, I ask that you explain what work would have to be done for "call home" functionality that would NOT have to be done otherwise such that it is out of scope. Finally, I ask that you reconsider one aspect of your decision: > * Blocking forward progress on documents until call home issues are > resolved. I suggest to you that since the working group is not chartered at this time to write protocol documents (you prohibited that at IETF 62), such a restriction is not reasonable until a new charter is approved. If you agree to drop this restriction, I will in turn agree to (a) not appeal your decision, (b) continue to work with Dave Harrington on the draft he is developing, and (c) following the process you've laid down until the new charter is approved. If at the time of documents' last call to both the working group and the IETF we have not resolved these matters, I will raise my concerns again, as I currently believe we are building a car with two different wheel sizes. This includes draft-ietf-netconf-ssh-0[45].txt, which I now believe to be incompatable with the current direction of the ISMS working group. It can and should be corrected. Again, I stress that I will work with Dave and the NETCONF folks as well to correct the matter. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 09:28:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66uv-0004qg-Mq; Fri, 19 Aug 2005 09:28:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66us-0004q1-Bt for isms@megatron.ietf.org; Fri, 19 Aug 2005 09:28:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02635 for ; Fri, 19 Aug 2005 09:28:12 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E67Uo-0000qq-VV for isms@ietf.org; Fri, 19 Aug 2005 10:05:24 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2005 06:28:04 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7JDRx0J010105; Fri, 19 Aug 2005 06:27:59 -0700 (PDT) Received: from [212.254.247.6] (ams-clip-vpn-dhcp4321.cisco.com [10.61.80.224]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7JDONjO021134; Fri, 19 Aug 2005 06:24:24 -0700 Message-ID: <4305DE5F.5030204@cisco.com> Date: Fri, 19 Aug 2005 15:27:59 +0200 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> <43042B28.1010701@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1161; t=1124457865; x=1124890065; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20RE=3A=20Call=20for=20consensus| From:Eliot=20Lear=20| Date:Fri,=2019=20Aug=202005=2015=3A27=3A59=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=lIr1kBsIZ0CxIghH/slYqsbsEYdGWglYaRraTzYlooBqpirI/ADnztTTWL/3H/+BSbtnyEMw +PutmzwDZoIrlxvhOKdrwooqK+h0C++OR2BTHkAfG+Y2VFRyFkNWvpcbVT8HUXrJw46fG0WPuWS CY1R69OvmkZvJx/W/GHzP3PI= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Margaret, Let me defer a response to you on the matter of scope. However... > It is possible, if we decide that notifications should be secured using > ISMS as well as queries/responses (has that been determined?), that > devices (acting as notification senders) may end-up initiating SSH > sessions to notification receivers. We have demonstrable proof in the form of FTP that having one connection in one direction and another connection in another is a serious mistake, thanks again to firewalls and NATs. We have them, let's please not stick our heads in the sand (again). Let connection directionality flow in a single direction - the one that works (whatever that might be). > > I would personally find it more intuitive and more consistent with the > SNMP model if the notification subsystem was distinct from the > query/response subsystem, rather than considering a model where a device > might send a notification to a manger that would then turn around and > use that same SSH connection to issue queries to the device. Perhaps > you think otherwise, though? I'm somewhat open to a number of possibilities here: - multiple connections within the SSH transport connection - multiple SSH connections - a hybrid where one opportunistically is able to use an existing SSH transport I think more highly of the 3rd, could settle for the 2nd, and would not cry if we ended up with the first. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 10:03:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67T3-0004kH-QY; Fri, 19 Aug 2005 10:03:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E67T1-0004k4-Oh for isms@megatron.ietf.org; Fri, 19 Aug 2005 10:03:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04078 for ; Fri, 19 Aug 2005 10:03:29 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E682y-0001mm-Eg for isms@ietf.org; Fri, 19 Aug 2005 10:40:41 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7JE2EF6017501; Fri, 19 Aug 2005 09:02:14 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 16:02:13 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D32911@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Eliot Lear Date: Fri, 19 Aug 2005 16:01:43 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: isms@ietf.org Subject: [Isms] Firwalls and NATs X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, I am picking on some text from your posting: > We have demonstrable proof in the form of FTP that having one > connection in one direction and another connection in another > is a serious mistake, thanks again to firewalls and NATs. > We have them, let's please not stick our heads in the sand > (again). Let connection directionality flow in a single > direction - the one that works (whatever that might be). > I would like you to explain to me how this applies (or is inscope) for ISMS. It may be just me... so bear with me please. I explicitly also invite operators to chime in if I have it wrong or right. That would be very good input. I rather hear them speak up for themselves as opposed to vendors "channeling their customer requirements". - I believe that many networks and network devices are being managed from the inside. I.e. there is no need to go and pass through a firewall or NAT in order to manage the network device or network service. - Specifically large operators have been pushing on us (boeing, us governement, ... ) that we need to blend in with existing NM infrastructure (I believe that SSH and use of RADIUS was also explicitly mentioned) - Some operators (ISPs) possibly manage things like ADSL or cable modems at their curtomer sites. But even then, I think they manage it from the inside side of the NAT or firewall, and they do not go and manage systems inside the customer premises. So, I am not saying that the issue does not exist at all, but I do wonder (and I do not know, so that is why I am asking) if the oeprators who are interested to work with us to get this integration of security infrastructure for SNMP, if those operators indeed need to manage all sorts of devices and services outside (i.e. beyond a firewall or NAT). If that number is only a very small percentage, then maybe we should focus on the majority of situations first and do the remaining small piece later (in a 2nd step) if at all. Just thinking aloud and asking questions, Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 10:38:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E680a-0005ru-QQ; Fri, 19 Aug 2005 10:38:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E680Y-0005r3-Td for isms@megatron.ietf.org; Fri, 19 Aug 2005 10:38:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06982 for ; Fri, 19 Aug 2005 10:38:08 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E68aQ-0002pT-9g for isms@ietf.org; Fri, 19 Aug 2005 11:15:21 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7JEc1ZC015628 for ; Fri, 19 Aug 2005 10:38:01 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 19 Aug 2005 10:38:00 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 19 Aug 2005 10:38:00 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Aug 2005 10:38:00 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] radius usage Date: Fri, 19 Aug 2005 10:37:59 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324FF@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] radius usage Thread-Index: AcWklwyDBdy9A/diTlGo4zqL7FeyCgABuHmAAAruv7A= From: "Nelson, David" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 19 Aug 2005 14:38:00.0476 (UTC) FILETIME=[9927B5C0:01C5A4CB] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:90.6865 M:99.5542 P:95.9108 R:95.9108 S:34.0325 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hannes Tschofenig writes... > what is the purpose of the radius interaction? > a) key transport > b) authorization (1) authentication (2) authorization Using the SSH transport, SSH provides the key agreement mechanism, so that transport via RADIUS is not required. > in case of (b): what is the authorization decision that is made by the > radius server? RADIUS servers provide authorization in two ways. If the Access-Request message contains suitable "hint" attributes, e.g. that the requested access is for ISMS, the RADIUS server may compare those attributes against a profile of allowed services (or a group of profiles) for a given user account to determine whether an Access-Accept or Access-Reject will be returned. Additionally, based on group membership properties of the user account (and possibly the access profiles) the RADIUS server may return a customized set of service provisioning attributes. For example, it could specify that the service to be provisioned is SNMPv3 access via ISMS. It could additionally return attributes to map into securityName or groupName. See the I-D, http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-02.txt for examples of these types of attributes. > what input by the radius client is needed in order for the radius server > to make a decision? The minimum required is the User-Name attribute and suitable credentials, such as User-Password. Adding "hint" attributes in the Access-Request that describe the requested service would be of benefit. > if a decision is made is it binary (accept/reject)? The decision is binary, but the accept decision may contain specific service provisioning attributes. Generally speaking, if a RADIUS client cannot provide the specific service provisioned in the Access-Accept, it is expected to treat it as an Access-Reject. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 10:56:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68IQ-00022k-01; Fri, 19 Aug 2005 10:56:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5np2-0004xy-38 for isms@megatron.ietf.org; Thu, 18 Aug 2005 13:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17919 for ; Thu, 18 Aug 2005 13:04:53 -0400 (EDT) Received: from mail.networksolutionsemail.com ([205.178.146.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5oOl-0007Sh-Ry for isms@ietf.org; Thu, 18 Aug 2005 13:41:55 -0400 Received: (qmail 6766 invoked by uid 78); 18 Aug 2005 16:19:16 -0000 Received: from unknown (HELO ?192.168.0.10?) (24.24.133.237) by mail7.netsol.inquent.com with SMTP; 18 Aug 2005 16:19:16 -0000 Message-ID: <4304B503.1060308@andybierman.com> Date: Thu, 18 Aug 2005 09:19:15 -0700 From: Andy Bierman User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Isms] RE: Call for consensus and a proposal References: <7D5D48D2CAA3D84C813F5B154F43B15507D32583@nl0006exch001u.nl.lucent.com> <43047060.6050806@cisco.com> In-Reply-To: <43047060.6050806@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Aug 2005 10:56:36 -0400 Cc: isms@ietf.org, netconf X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot, I cc:ed the NETCONF WG because you are proposing changes to NETCONF over SSH to the ISMS WG. In theory, I agree with your goal of a single transport for both NETCONF and ISMS, and I like your proposal. If it had been on the table at the interim meeting where this was all worked out, I think it would have been selected the one and only NETCONF transport. However, the NETCONF WG took a long time to decide on 3 different transports. I don't really know how useful NETCONF over SOAP is going to be, but I bet a few people would complain if we told them (at the last minute) that NETCONF over BEEP is being removed. (It's not!) Any new NETCONF features need to be done as proprietary extensions first, shown to be useful in real operator environments, and then gain wide acceptance from the WG. I would support new NETCONF work today that met this criteria. Andy >Bert, > >Forgive me but I'm frustrated. I won't just complain, however. I have >a proposal (I've been chewing on it for a bit). See below. > >How could call home functionality possibly have ended up in the charter? > Nobody knew we would come close to using a TCP-based approach until >March when an WG-shaking event occurred. Every approach submitted and >envisioned prior to that was a new security model using the existing UDP >transport. > >But we are here now, and we are positioned to either take advantage of >or miss a huge opportunity or create a mess. Anyone who thinks that >firewalls or NATs routinely implement the proxy function of RFC 3413 >hasn't taken a good look at the market lately. Let's at least make the >best of the position we find ourselves and take corrective action. I >hate to say it, but take a look at Windows. Most of the time management >connections are issued by clients. Really this is no different. > >Let me refresh your and Dave's memory on the matter of NETCONF. The >initial authors of the base spec ALWAYS envisioned a call home function. > We got it for free with BEEP, which was part of the core specification >until the working group forced us to separate out protocol mappings. We >even had it in an early draft of the SSH specification, but cut it out >[too much channel cruft as you may recall]. What's more, I claim it's >easier than ever to do now. > >In the netconf ssh draft, what I propose is that we add some text around >the following idea: > > - when the manager contacts the agent, it will request the "netconf" > SSH service. > - when the agent contacts the manager, it will request the > "netconf-turn" service (or "netconf-callhome" if you prefer - I > would like to reuse the SMTP term since they invented the concept, > so far as I can recall). > - Add text in security considerations about how to handle identity > for the call home approach. I claim it's No Big Deal. It just > says that the client process for callhome should probably tie to > an appropriately authorized user for the function being managed. > >This mechanism has the added benefit of not requiring pre-existing >implementations to change their code. The reason I want it in round one >of netconf is that I would if I could nuke all other transport options >including BEEP. Options are a necessary evil. Transport options are an >UNnecessary evil. > >Rinse and repeat. The same process can be applied to SNMP. There is no >difference. Presto. Yes, it took me a few days to come up with this in >a simple way. And yes, there are a few issues surrounding the mapping >for traps, but I claim we can solve those as well to peoples' >satisfaction. What do people think? > >The result is a single mandatory transport for both NETCONF AND BEEP. >Similar call home functionality for both. > >This is NOT Eliot's "would be nice" for a protocol. It's really >important for our customers. We've always envisioned having call home >functionality in our products. In fact we've had proprietary solutions >for years (which is how we know it's important to our customers). The >other option - and they're already talking about it - is SNMP over SIP. > I kid you not. Sort of makes me think of running IP over a DHCP >option, but heck anything's possible. > >In summary, please let's be elegant. Let's kill two birds with one >stone. Let's make it easier on all of our customers in the future. And >let's codify something that everyone else has been doing for years. > >My connectivity will be sketchy for the next few days, but will continue >as best I can (although I don't want to beat a dead horse). > >Eliot >ps: yes, I've offered to put this into real draft words for Dave. > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 10:59:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68LB-0002NF-Q8; Fri, 19 Aug 2005 10:59:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68LB-0002Mp-7l for isms@megatron.ietf.org; Fri, 19 Aug 2005 10:59:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08126 for ; Fri, 19 Aug 2005 10:59:26 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E68v8-0003Vi-Kx for isms@ietf.org; Fri, 19 Aug 2005 11:36:39 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA11756 for ; Fri, 19 Aug 2005 11:02:04 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma011586; Fri, 19 Aug 05 11:01:11 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 19 Aug 2005 10:58:32 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Fri, 19 Aug 2005 10:58:32 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Aug 2005 10:58:32 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS charter discussion Date: Fri, 19 Aug 2005 10:58:31 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032500@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS charter discussion Thread-Index: AcWkrTU/SwT6VU5CT7efkkYDaC5bfgAHmybg From: "Nelson, David" To: "Wijnen, Bert \(Bert\)" , "Juergen Quittek" , X-OriginalArrivalTime: 19 Aug 2005 14:58:32.0257 (UTC) FILETIME=[775A9310:01C5A4CE] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:87.1726 M:98.0684 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Bert Wijnen writes... > We do not have the concept of "securityGroup" in SNMPv3 ... So I've clearly picked up an incorrect term from another thread in on this list. > In SNMP we control access based on the groupName or the "who" > (among other things). See RFC3415 page 8. I believe I should have said groupName. The intent was to re-use an existing mechanism. > In the case of USM we use the securityModel (USM) and the > userName in the msgSecurityParameters (securityModel-specific > parameters inside a SNMPv3 Message) which gets mapped (1-1) > into the security-model-independent securityName. > The securityModel and securityName are used to map to a > groupName, which is then one of the keys to find out > if access can be granted. I am suggesting, however, that we allow the AAA-provisioned authorization attributes to map into groupName. That may require a modification to the API between the access control module and the security module. It would certainly not affect the SNMP over-the-wire protocol definition. > If the securityModel is gonna be (for example) > SSM (SSH-based Security Model), then we have the securityModel. > We then need to decide how we map the SSH identity (correct term) > into a securityName. Once we have those two, I think it is > a matter of populating an entry (entries) in the > vacmSecurityToGroupTable and bingo, we're all set. I agree that operators will continue to populate the VACM table as they do (or do not) today. Today the mapping from securityName to groupName is stored in the local non-volatile storage of the managed entity. I think that constitutes an impediment to deployment and a scalability issue that ISMS needs to address. It seems to me that are three choices: (a) In practice, the securityName will be limited to a small number of values that describe roles within and organization structure (e.g. help-desk, network-admin), and not individual identities (e.g. dnelson). Then, securityName can that be a simple 1:1 mapping into groupName (perhaps the equality mapping). (b) The mapping between securityName and groupName remains to be provisioned as it is done today. (c) We allow the AAA server to provision the groupName, centralizing the mapping of securityName to groupName in the AAA server, along with other access rights information. I think that (a) is simple, but has the potential disadvantage of losing the individual identity of the user (or command generator). It may be interesting to keep that for auditing purposes, e.g. syslog. I think that (b) perpetuates an impediment to deployment. I think that (c) is almost a simple as (a) and is the best choice. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 11:26:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68ln-0001g3-56; Fri, 19 Aug 2005 11:26:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68lm-0001fv-Bj for isms@megatron.ietf.org; Fri, 19 Aug 2005 11:26:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09564 for ; Fri, 19 Aug 2005 11:26:55 -0400 (EDT) Received: from [204.9.221.21] (helo=thingmagic.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E69Lh-0004Rb-Vn for isms@ietf.org; Fri, 19 Aug 2005 12:04:09 -0400 Received: from [66.30.121.250] (account margaret HELO [192.168.2.2]) by thingmagic.com (CommuniGate Pro SMTP 4.1.8) with ESMTP-TLS id 491766; Fri, 19 Aug 2005 10:30:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4305DE5F.5030204@cisco.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324F0@MAANDMBX2.ets.enterasys.com> <430247BC.9030601@cisco.com> <43042B28.1010701@cisco.com> <4305DE5F.5030204@cisco.com> Date: Fri, 19 Aug 2005 11:26:27 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: [Isms] RE: Call for consensus Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eliot, At 3:27 PM +0200 8/19/05, Eliot Lear wrote: >Let me defer a response to you on the matter of scope. However... I'm not sure that you can really defer the question of scope, because that is the whole point: What is the purpose (scope) of this particular WG effort? There are SNMP "customers" who are using SNMP today (and therefore, by definition, can initiate communication from their management stations to their devices) who have not migrated from SNMPv1/v2 to SNMPv3, because of the cost/complexity (real or perceived) of deploying SNMPv3 security. That is the problem that I think we are trying to solve in this working group, by integrating SNMP security with existing, widely deployed security infrastructure, such as RADIUS. You have spoken about another, separate problem: That devices behind NATs can't always be addressed or reached from the outside, making SNMP (as it exists today) a poor solution to manage those devices. FWIW, I agree with you that this problem exists, but it is certainly not specific to SNMP. Furthermore, fixing this problem using the concept that you have described would require major changes to the SNMP operational model, and I don't think that this particular (Security area) WG is (or should be) chartered to do that work. If you believe that your "call home" concept is a viable solution to the SNMP-through-a-NAT problem, and if you can point to a large set of "customers" who are likely to adopt SNMP if this problem is solved, then I think that you should write a draft and work with Bert to get an SNMP "call home" effort started in the OPS area. I might even poke my head in from time-to-time... Margaret _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 12:39:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69uN-00039A-1H; Fri, 19 Aug 2005 12:39:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E69uL-000395-Vx for isms@megatron.ietf.org; Fri, 19 Aug 2005 12:39:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14120 for ; Fri, 19 Aug 2005 12:39:50 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6AUL-0006jB-6i for isms@ietf.org; Fri, 19 Aug 2005 13:17:05 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7JGdadn013405; Fri, 19 Aug 2005 11:39:37 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 19 Aug 2005 18:39:36 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507D3295D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Nelson, David" , isms@ietf.org Subject: securityName/groupName [was RE: [Isms] ISMS charter discussion] Date: Fri, 19 Aug 2005 18:39:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Inline > -----Original Message----- > From: Nelson, David [mailto:dnelson@enterasys.com] > Sent: Friday, August 19, 2005 16:59 > To: Wijnen, Bert (Bert); Juergen Quittek; isms@ietf.org > Subject: RE: [Isms] ISMS charter discussion > > > Bert Wijnen writes... > > > We do not have the concept of "securityGroup" in SNMPv3 ... > > So I've clearly picked up an incorrect term from another thread in on > this list. > That is OK David. I just wanted to be sure we are not talking about some new form of groupName but about the groupName as currently known in VACM. > > In SNMP we control access based on the groupName or the "who" > > (among other things). See RFC3415 page 8. > > I believe I should have said groupName. The intent was to re-use an > existing mechanism. > OK, good to hear. > > In the case of USM we use the securityModel (USM) and the > > userName in the msgSecurityParameters (securityModel-specific > > parameters inside a SNMPv3 Message) which gets mapped (1-1) > > into the security-model-independent securityName. > > The securityModel and securityName are used to map to a > > groupName, which is then one of the keys to find out > > if access can be granted. > > I am suggesting, however, that we allow the AAA-provisioned > authorization attributes to map into groupName. That may require a > modification to the API between the access control module and the > security module. It would certainly not affect the SNMP over-the-wire > protocol definition. > I am not sure yet I understand what you want to do. If you look at the figure on page 24 of RFC3411, then you can see that we do not have an API (or ASI as we call it because it is only meant to be a logical interface between modular pieces of our technical specifications and not intended to mandate an implementation API) between the security module and the acces control module. Instead, the applications (like the CommandResponder and the NotificationOriginator) call the the access control module with arguments they have received via internal mechanimsms (securityName, Groupname, viewName etc, see RFC3415 for details). So my question is how do we populate the existing MIB tables like the VACM table to prepare for access. And then when a SNMP message comes in, what information can we extract out of that messages (either the SNMPv3 message itself, in any (SSH or Radius specific) securityParamters that can easily map onto the internal data structire (concepts) of securityModel, secuirtyLevel, securityName? Or maybe when the message comes in (over SHH), we can populate some of those internal things (securityModel, securityLevel and securityName) so that fruther down all works fine. It could be that when we get the session setup call and we check with RADIUS, that at that point we populate some of the internal MIB tables with (temporary maybe) securityName and mapping into a group) and then decide that the session must use some specific (temporary) userName (in the security Paramters of the SNMPv3 message) that maps to the proper securityName that was instantiated in the VACM tables for this session. Anyway, we have lots of work to do there I think > > If the securityModel is gonna be (for example) > > SSM (SSH-based Security Model), then we have the securityModel. > > We then need to decide how we map the SSH identity (correct term) > > into a securityName. Once we have those two, I think it is > > a matter of populating an entry (entries) in the > > vacmSecurityToGroupTable and bingo, we're all set. > > I agree that operators will continue to populate the VACM table as they > do (or do not) today. Today the mapping from securityName to groupName > is stored in the local non-volatile storage of the managed entity. I > think that constitutes an impediment to deployment and a scalability > issue that ISMS needs to address. > > It seems to me that are three choices: > > (a) In practice, the securityName will be limited to a small number of > values that describe roles within and organization structure (e.g. > help-desk, network-admin), and not individual identities (e.g. dnelson). > Then, securityName can that be a simple 1:1 mapping into groupName > (perhaps the equality mapping). > I have sort of preached in the past that I would popolate the MIB at the managed device with (basically unknow) users and secrets. They would be know on the managed device and on the NMS station. They would (in my view) represent roles as you describe). At the NMS, a user/person logs in (e.g. dnelson) and based on the credentials he gives he can then act in a particular role. It would make it so much easier if dnelsen leaves the company and you need to remove his access rights. You only need to do it on the NMS(es) instead of having to do it on (hundreds of) thousands of devices. Same for when a new operator comes and joins the team. One could imagine a few "crisis or emergency" users that have been defined and that are under strict control. Such users would be used in firefighting mode, when the NMS cannot help or is unavailable or has no connectivity to the device or so. Such special users would eb used rarely (I hope) and would need to change after they ahve been used. Oh well... sory for my side-stepping and all that. But the idea is not bad in my view. > (b) The mapping between securityName and groupName remains to be > provisioned as it is done today. > > (c) We allow the AAA server to provision the groupName, centralizing the > mapping of securityName to groupName in the AAA server, along with other > access rights information. > > I think that (a) is simple, but has the potential disadvantage of losing > the individual identity of the user (or command generator). It may be > interesting to keep that for auditing purposes, e.g. syslog. > Well, see my rant above. the auditing issue could be handled on the NMS, but I can see that that might not be sufficient. > I think that (b) perpetuates an impediment to deployment. > probably > I think that (c) is almost a simple as (a) and is the best choice. > As long as we can define a way to do that without having to touch many many places inside an SNMP implementation. I think at the bginning of my response above, I may have started to think about how we could do that. The way I describe it there I think tries to leave VACM alone and instead allow (at session setup) to populate some entries and maybe assign a dynamic userName or some such (that maps into a temporrary/dynamic securityName). That way, the code changes could be localized to where we must add/insert the new securityModel anyway. Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 19 13:27:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AeU-0002Qw-UL; Fri, 19 Aug 2005 13:27:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AeT-0002Qj-SH for isms@megatron.ietf.org; Fri, 19 Aug 2005 13:27:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18156 for ; Fri, 19 Aug 2005 13:27:30 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BEO-0000Lr-Ix for isms@ietf.org; Fri, 19 Aug 2005 14:04:45 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2005 10:27:19 -0700 X-IronPort-AV: i="3.96,126,1122879600"; d="scan'208,217"; a="206272686:sNHT50010888" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7JHR9Z2018282; Fri, 19 Aug 2005 10:27:10 -0700 (PDT) Message-Id: <6.2.0.14.0.20050819102257.06979d30@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 19 Aug 2005 10:27:15 -0700 To: "Wijnen, Bert (Bert)" From: Kaushik Narayan Subject: Re: securityName/groupName [was RE: [Isms] ISMS charter discussion] In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507D3295D@nl0006exch001u.nl .lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507D3295D@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 054490fec19f6a94c68e63428d06db69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0382299929==" Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org --===============0382299929== Content-Type: multipart/alternative; boundary="=====================_241553655==.ALT" --=====================_241553655==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Bert, Here's how we had proposed in the EUSM draft This specification would require a minor modification to the SNMPv3 VACM processing as defined in [RFC3415]. The current VACM specification has the vacmSecurityToGroupTable, this table maps a combination of securityModel and securityName into a groupName which is used to define an access control policy for a group of principals. The EUSM model will have not a Local Configuration Database and securityNames, hence there would be no entries in the vacmSecurityToGroupTable for the EUSM model. The new security model MUST retrieve the groupName for the user on successful authentication and the authoritative SNMP engine MUST not look up the vacmSecurityToGroupTable to retrieve the groupName for a given security Name. In case of RADIUS authentication, the groupName MUST be returned by the RADIUS server. It is possible for the RADIUS Server to return a groupName that has not been defined on the authoritative SNMP engine; in such cases, the vacmAccessTable would not have an entry for this group. The authoritative SNMP engine MUST return with a noAccessEntry error for the request. All other aspects of the SNMPv3 VACM would be applicable to this specification. Although the vacmSecurityToGroupTable would be empty for EUSM users, it would not effect other VACM tables that depend on the groupName. The vacmAccessTable has the groupName as of the indexes but the groupName is not dependent on instances in vacmSecurityToGroupTable, quoting the statement in [RFC3415], "Entries in the vacmAccessTable can use an instance value for object vacmGroupName even if no entry in table vacmAccessSecurityToGroupTable has a corresponding value for object vacmGroupName." I think this text is relevant to any new security model we define. regards, kaushik! At 09:39 AM 8/19/2005, Wijnen, Bert (Bert) wrote: >Inline > > > -----Original Message----- > > From: Nelson, David [mailto:dnelson@enterasys.com] > > Sent: Friday, August 19, 2005 16:59 > > To: Wijnen, Bert (Bert); Juergen Quittek; isms@ietf.org > > Subject: RE: [Isms] ISMS charter discussion > > > > > > Bert Wijnen writes... > > > > > We do not have the concept of "securityGroup" in SNMPv3 ... > > > > So I've clearly picked up an incorrect term from another thread in on > > this list. > > >That is OK David. >I just wanted to be sure we are not talking about some new form >of groupName but about the groupName as currently known in VACM. > > > > In SNMP we control access based on the groupName or the "who" > > > (among other things). See RFC3415 page 8. > > > > I believe I should have said groupName. The intent was to re-use an > > existing mechanism. > > >OK, good to hear. > > > > In the case of USM we use the securityModel (USM) and the > > > userName in the msgSecurityParameters (securityModel-specific > > > parameters inside a SNMPv3 Message) which gets mapped (1-1) > > > into the security-model-independent securityName. > > > The securityModel and securityName are used to map to a > > > groupName, which is then one of the keys to find out > > > if access can be granted. > > > > I am suggesting, however, that we allow the AAA-provisioned > > authorization attributes to map into groupName. That may require a > > modification to the API between the access control module and the > > security module. It would certainly not affect the SNMP over-the-wire > > protocol definition. > > > >I am not sure yet I understand what you want to do. >If you look at the figure on page 24 of RFC3411, then you can >see that we do not have an API (or ASI as we call it because >it is only meant to be a logical interface between modular >pieces of our technical specifications and not intended to >mandate an implementation API) between the security module and >the acces control module. Instead, the applications (like >the CommandResponder and the NotificationOriginator) call the >the access control module with arguments they have received >via internal mechanimsms (securityName, Groupname, viewName >etc, see RFC3415 for details). > >So my question is how do we populate the existing MIB tables >like the VACM table to prepare for access. And then when a >SNMP message comes in, what information can we extract out >of that messages (either the SNMPv3 message itself, in any >(SSH or Radius specific) securityParamters that can easily >map onto the internal data structire (concepts) of >securityModel, secuirtyLevel, securityName? Or maybe when >the message comes in (over SHH), we can populate some >of those internal things (securityModel, securityLevel and >securityName) so that fruther down all works fine. > >It could be that when we get the session setup call and >we check with RADIUS, that at that point we populate some >of the internal MIB tables with (temporary maybe) securityName >and mapping into a group) and then decide that the session >must use some specific (temporary) userName (in the security >Paramters of the SNMPv3 message) that maps to the proper >securityName that was instantiated in the VACM tables for >this session. Anyway, we have lots of work to do there I >think > > > > If the securityModel is gonna be (for example) > > > SSM (SSH-based Security Model), then we have the securityModel. > > > We then need to decide how we map the SSH identity (correct term) > > > into a securityName. Once we have those two, I think it is > > > a matter of populating an entry (entries) in the > > > vacmSecurityToGroupTable and bingo, we're all set. > > > > I agree that operators will continue to populate the VACM table as they > > do (or do not) today. Today the mapping from securityName to groupName > > is stored in the local non-volatile storage of the managed entity. I > > think that constitutes an impediment to deployment and a scalability > > issue that ISMS needs to address. > > > > It seems to me that are three choices: > > > > (a) In practice, the securityName will be limited to a small number of > > values that describe roles within and organization structure (e.g. > > help-desk, network-admin), and not individual identities (e.g. dnelson). > > Then, securityName can that be a simple 1:1 mapping into groupName > > (perhaps the equality mapping). > > > >I have sort of preached in the past that I would popolate the MIB >at the managed device with (basically unknow) users and secrets. >They would be know on the managed device and on the NMS station. >They would (in my view) represent roles as you describe). > >At the NMS, a user/person logs in (e.g. dnelson) and based on >the credentials he gives he can then act in a particular role. >It would make it so much easier if dnelsen leaves the company and >you need to remove his access rights. You only need to do it on >the NMS(es) instead of having to do it on (hundreds of) thousands >of devices. Same for when a new operator comes and joins the team. > >One could imagine a few "crisis or emergency" users that have been defined >and that are under strict control. Such users would be used in firefighting >mode, when the NMS cannot help or is unavailable or has no connectivity to >the device or so. Such special users would eb used rarely (I hope) and >would need to change after they ahve been used. > >Oh well... sory for my side-stepping and all that. >But the idea is not bad in my view. > > > (b) The mapping between securityName and groupName remains to be > > provisioned as it is done today. > > > > (c) We allow the AAA server to provision the groupName, centralizing the > > mapping of securityName to groupName in the AAA server, along with other > > access rights information. > > > > I think that (a) is simple, but has the potential disadvantage of losing > > the individual identity of the user (or command generator). It may be > > interesting to keep that for auditing purposes, e.g. syslog. > > > >Well, see my rant above. the auditing issue could be handled >on the NMS, but I can see that that might not be sufficient. > > > I think that (b) perpetuates an impediment to deployment. > > >probably > > > I think that (c) is almost a simple as (a) and is the best choice. > > >As long as we can define a way to do that without having to >touch many many places inside an SNMP implementation. >I think at the bginning of my response above, I may have started >to think about how we could do that. The way I describe it there >I think tries to leave VACM alone and instead allow >(at session setup) to populate some entries and maybe assign a dynamic >userName or some such (that maps into a temporrary/dynamic securityName). >That way, the code changes could be localized to where we must add/insert >the new securityModel anyway. > >Bert > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms --=====================_241553655==.ALT Content-Type: text/html; charset="us-ascii" Hi Bert,


Here's how we had proposed in the EUSM draft


   This specification would require a minor modification
to the SNMPv3 
   VACM processing as defined in [RFC3415]. The current VACM 
   specification has the vacmSecurityToGroupTable, this table
maps a 
   combination of securityModel and securityName into a
groupName which 
   is used to define an access control policy for a group of
principals.
   The EUSM model will have not a Local Configuration Database
and 
   securityNames, hence there would be no entries in the 
   vacmSecurityToGroupTable for the EUSM model. 
   
   The new security model MUST retrieve the groupName for 
   the user on successful authentication and the authoritative
SNMP 
   engine MUST not look up the vacmSecurityToGroupTable to
retrieve 
   the groupName for a given security Name. In case of RADIUS 
   authentication, the groupName MUST be returned by the RADIUS 
   server.  It is possible for the RADIUS Server to return
a 
   groupName that has not been defined on the authoritative
SNMP 
   engine; in such cases, the vacmAccessTable would not have an
entry 
   for this group. The authoritative SNMP engine MUST return
with a 
   noAccessEntry error for the request.
   All other aspects of the SNMPv3 VACM would be applicable to
this 
   specification. Although the vacmSecurityToGroupTable would
be empty 
   for EUSM users, it would not effect other VACM tables that
depend on 
   the groupName. The vacmAccessTable has the groupName as of
the 
   indexes but the groupName is not dependent on instances in 
   vacmSecurityToGroupTable, quoting the statement in
[RFC3415], 
   "Entries in the vacmAccessTable can use an instance
value for object 
   vacmGroupName even if no entry in table 
   vacmAccessSecurityToGroupTable has a corresponding value for
object 
   vacmGroupName."
I think this text is relevant to any new security model we define.

regards,
  kaushik!



At 09:39 AM 8/19/2005, Wijnen, Bert (Bert) wrote:
Inline

> -----Original Message-----
> From: Nelson, David [ mailto:dnelson@enterasys.com]
> Sent: Friday, August 19, 2005 16:59
> To: Wijnen, Bert (Bert); Juergen Quittek; isms@ietf.org
> Subject: RE: [Isms] ISMS charter discussion
>
>
> Bert Wijnen writes...
>
> > We do not have the concept of "securityGroup" in SNMPv3 ...
>
> So I've clearly picked up an incorrect term from another thread in on
> this list.
>
That is OK David.
I just wanted to be sure we are not talking about some new form
of groupName but about the groupName as currently known in VACM.

> > In SNMP we control access based on the groupName or the "who"
> > (among other things). See RFC3415 page 8.
>
> I believe I should have said groupName.  The intent was to re-use an
> existing mechanism.
>
OK, good to hear.

> > In the case of USM we use the securityModel (USM) and the
> > userName in the msgSecurityParameters (securityModel-specific
> > parameters inside a SNMPv3 Message) which gets mapped (1-1)
> > into the security-model-independent securityName.
> > The securityModel and securityName are used to map to a
> > groupName, which is then one of the keys to find out
> > if access can be granted.
>
> I am suggesting, however, that we allow the AAA-provisioned
> authorization attributes to map into groupName.  That may require a
> modification to the API between the access control module and the
> security module.  It would certainly not affect the SNMP over-the-wire
> protocol definition.
>

I am not sure yet I understand what you want to do.
If you look at the figure on page 24 of RFC3411, then you can
see that we do not have an API (or ASI as we call it because
it is only meant to be a logical interface between modular
pieces of our technical specifications and not intended to
mandate an implementation API) between the security module and
the acces control module. Instead, the applications (like
the CommandResponder and the NotificationOriginator) call the
the access control module with arguments they have received
via internal mechanimsms (securityName, Groupname, viewName
etc, see RFC3415 for details).

So my question is how do we populate the existing MIB tables
like the VACM table to prepare for access. And then when a
SNMP message comes in, what information can we extract out
of that messages (either the SNMPv3 message itself, in any
(SSH or Radius specific) securityParamters that can easily
map onto the internal data structire (concepts) of
securityModel, secuirtyLevel, securityName? Or maybe when
the message comes in (over SHH),  we can populate some
of those internal things (securityModel, securityLevel and
securityName) so that fruther down all works fine.

It could be that when we get the session setup call and
we check with RADIUS, that at that point we populate some
of the internal MIB tables with (temporary maybe) securityName
and mapping into a group) and then decide that the session
must use some specific (temporary) userName (in the security
Paramters of the SNMPv3 message) that maps to the proper
securityName that was instantiated in the VACM tables for
this session. Anyway, we have lots of work to do there I
think

> > If the securityModel is gonna be (for example)
> > SSM (SSH-based Security Model), then we have the securityModel.
> > We then need to decide how we map the SSH identity (correct term)
> > into a securityName. Once we have those two, I think it is
> > a matter of populating an entry (entries) in the
> > vacmSecurityToGroupTable and bingo, we're all set.
>
> I agree that operators will continue to populate the VACM table as they
> do (or do not) today.  Today the mapping from securityName to groupName
> is stored in the local non-volatile storage of the managed entity.  I
> think that constitutes an impediment to deployment and a scalability
> issue that ISMS needs to address.
>
> It seems to me that are three choices:
>
> (a) In practice, the securityName will be limited to a small number of
> values that describe roles within and organization structure (e.g.
> help-desk, network-admin), and not individual identities (e.g. dnelson).
> Then, securityName can that be a simple 1:1 mapping into groupName
> (perhaps the equality mapping).
>

I have sort of preached in the past that I would popolate the MIB
at the managed device with (basically unknow) users and secrets.
They would be know on the managed device and on the NMS station.
They would (in my view) represent roles as you describe).

At the NMS, a user/person logs in (e.g. dnelson) and based on
the credentials he gives he can then act in a particular role.
It would make it so much easier if dnelsen leaves the company and
you need to remove his access rights. You only need to do it on
the NMS(es) instead of having to do it on (hundreds of) thousands
of devices. Same for when a new operator comes and joins the team.

One could imagine a few "crisis or emergency" users that have been defined
and that are under strict control. Such users would be used in firefighting
mode, when the NMS cannot help or is unavailable or has no connectivity to
the device or so. Such special users would eb used rarely (I hope) and
would need to change after they ahve been used.

Oh well... sory for my side-stepping and all that.
But the idea is not bad in my view.

> (b) The mapping between securityName and groupName remains to be
> provisioned as it is done today.
>
> (c) We allow the AAA server to provision the groupName, centralizing the
> mapping of securityName to groupName in the AAA server, along with other
> access rights information.
>
> I think that (a) is simple, but has the potential disadvantage of losing
> the individual identity of the user (or command generator).  It may be
> interesting to keep that for auditing purposes, e.g. syslog.
>

Well, see my rant above. the auditing issue could be handled
on the NMS, but I can see that that might not be sufficient.

> I think that (b) perpetuates an impediment to deployment.
>
probably

> I think that (c) is almost a simple as (a) and is the best choice.
>
As long as we can define a way to do that without having to
touch many many places inside an SNMP implementation.
I think at the bginning of my response above, I may have started
to think about how we could do that. The way I describe it there
I think tries to leave VACM alone and instead allow
(at session setup) to populate some entries and maybe assign a dynamic
userName or some such (that maps into a temporrary/dynamic securityName).
That way, the code changes could be localized to where we must add/insert
the new securityModel anyway.

Bert

_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms
--=====================_241553655==.ALT-- --===============0382299929== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0382299929==-- From isms-bounces@lists.ietf.org Fri Aug 19 13:28:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AfC-0002Wq-CV; Fri, 19 Aug 2005 13:28:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6AfB-0002Wl-EY for isms@megatron.ietf.org; Fri, 19 Aug 2005 13:28:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18210 for ; Fri, 19 Aug 2005 13:28:13 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6BF9-0000NQ-TT for isms@ietf.org; Fri, 19 Aug 2005 14:05:29 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA22135 for ; Fri, 19 Aug 2005 13:30:48 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma022116; Fri, 19 Aug 05 13:30:12 -0400 Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Fri, 19 Aug 2005 13:27:32 -0400 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Fri, 19 Aug 2005 13:27:32 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 19 Aug 2005 13:27:32 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: securityName/groupName [was RE: [Isms] ISMS charter discussion] Date: Fri, 19 Aug 2005 13:27:31 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032501@MAANDMBX2.ets.enterasys.com> Thread-Topic: securityName/groupName [was RE: [Isms] ISMS charter discussion] Thread-Index: AcWk3JuBnUlAicA/TZu7F+bqG0hjMQABLvxA From: "Nelson, David" To: "Wijnen, Bert \(Bert\)" , X-OriginalArrivalTime: 19 Aug 2005 17:27:32.0525 (UTC) FILETIME=[482B35D0:01C5A4E3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:82.4442 M:97.0282 P:95.9108 R:95.9108 S:19.4545 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Bert Wijnen writes > It could be that when we get the session setup call and > we check with RADIUS, that at that point we populate some > of the internal MIB tables with (temporary maybe) securityName > and mapping into a group) and then decide that the session > must use some specific (temporary) userName (in the security > Paramters of the SNMPv3 message) that maps to the proper > securityName that was instantiated in the VACM tables for > this session. That aligns with what I was thinking. > Anyway, we have lots of work to do there I think Yes. > I have sort of preached in the past that I would popolate the MIB > at the managed device with (basically unknow) users and secrets. > They would be know on the managed device and on the NMS station. > They would (in my view) represent roles as you describe). >=20 > At the NMS, a user/person logs in (e.g. dnelson) and based on > the credentials he gives he can then act in a particular role. > It would make it so much easier if dnelsen leaves the company and > you need to remove his access rights. You only need to do it on > the NMS(es) instead of having to do it on (hundreds of) thousands > of devices. Same for when a new operator comes and joins the team. This is a method of obtaining some of the benefits of ISMS, without having to implement ISMS. I think that ISMS, at a very high level, effectively moves the mapping of the specific usernames to generic usernames (roles) out of the NMS and into the AAA server. > As long as we can define a way to do that without having to > touch many many places inside an SNMP implementation. The devil is always in the details. It is well that we understand the high level issues and work required so that we don't charter goals that are too difficult to achieve. > The way I describe it there > I think tries to leave VACM alone and instead allow > (at session setup) to populate some entries and maybe assign a dynamic > userName or some such (that maps into a temporrary/dynamic securityName). > That way, the code changes could be localized to where we must add/insert > the new securityModel anyway. Yes, I agree that is the desired approach. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 07:51:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6oLu-0005gj-JC; Sun, 21 Aug 2005 07:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6oLt-0005ge-JH for isms@megatron.ietf.org; Sun, 21 Aug 2005 07:51:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23204 for ; Sun, 21 Aug 2005 07:51:00 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6owD-0004Rz-H3 for isms@ietf.org; Sun, 21 Aug 2005 08:28:36 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id D6AFD1B7DD; Sun, 21 Aug 2005 13:50:35 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: securityName/groupName [was RE: [Isms] ISMS charter discussion] Date: Sun, 21 Aug 2005 13:47:11 +0200 Message-ID: <88F766D04E6AF3409B39E60D7D933EB20E8BD7@europa.office> Thread-Topic: securityName/groupName [was RE: [Isms] ISMS charter discussion] Thread-Index: AcWk3JuBnUlAicA/TZu7F+bqG0hjMQABLvxAAFkucTM= From: "Juergen Quittek" To: "Nelson, David" , "Wijnen, Bert (Bert)" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Woul it be acceptable for everybody if we replaced=20 "securityName and groupName" with=20 "securityName and other SNMP parameters"? =20 Juergen ________________________________ From: isms-bounces@lists.ietf.org on behalf of Nelson, David Sent: Fri 19.08.2005 19:27 To: Wijnen, Bert (Bert); isms@ietf.org Subject: RE: securityName/groupName [was RE: [Isms] ISMS charter = discussion] Bert Wijnen writes > It could be that when we get the session setup call and > we check with RADIUS, that at that point we populate some > of the internal MIB tables with (temporary maybe) securityName > and mapping into a group) and then decide that the session > must use some specific (temporary) userName (in the security > Paramters of the SNMPv3 message) that maps to the proper > securityName that was instantiated in the VACM tables for > this session. That aligns with what I was thinking. > Anyway, we have lots of work to do there I think Yes. > I have sort of preached in the past that I would popolate the MIB > at the managed device with (basically unknow) users and secrets. > They would be know on the managed device and on the NMS station. > They would (in my view) represent roles as you describe). > > At the NMS, a user/person logs in (e.g. dnelson) and based on > the credentials he gives he can then act in a particular role. > It would make it so much easier if dnelsen leaves the company and > you need to remove his access rights. You only need to do it on > the NMS(es) instead of having to do it on (hundreds of) thousands > of devices. Same for when a new operator comes and joins the team. This is a method of obtaining some of the benefits of ISMS, without having to implement ISMS. I think that ISMS, at a very high level, effectively moves the mapping of the specific usernames to generic usernames (roles) out of the NMS and into the AAA server. > As long as we can define a way to do that without having to > touch many many places inside an SNMP implementation. The devil is always in the details. It is well that we understand the high level issues and work required so that we don't charter goals that are too difficult to achieve. > The way I describe it there > I think tries to leave VACM alone and instead allow > (at session setup) to populate some entries and maybe assign a dynamic > userName or some such (that maps into a temporrary/dynamic securityName). > That way, the code changes could be localized to where we must add/insert > the new securityModel anyway. Yes, I agree that is the desired approach. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 08:07:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6oc3-0000OR-DK; Sun, 21 Aug 2005 08:07:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6oc2-0000OM-Il for isms@megatron.ietf.org; Sun, 21 Aug 2005 08:07:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24482 for ; Sun, 21 Aug 2005 08:07:41 -0400 (EDT) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6pCN-0004zc-RL for isms@ietf.org; Sun, 21 Aug 2005 08:45:17 -0400 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 534B015111; Sun, 21 Aug 2005 14:07:32 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: AD Comment: Call Home Out of Scope Date: Sun, 21 Aug 2005 14:05:58 +0200 Message-ID: <88F766D04E6AF3409B39E60D7D933EB20E8BD9@europa.office> Thread-Topic: [Isms] Re: AD Comment: Call Home Out of Scope Thread-Index: AcWkvu4bbsB+hqKDTLyQ6JvHrAz+qABicK7f From: "Juergen Quittek" To: "Eliot Lear" , "Sam Hartman" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: Andy Bierman , housley@vigilsec.com, isms@ietf.org, simon@switch.ch, netconf@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Eliot, =20 (I am using a srange terminal;=20 hope that this message is somehow reasonably formatted) =20 > From: isms-bounces@lists.ietf.org on behalf of Eliot Lear > Sent: Fri 19.08.2005 15:06 > > I'd like to draw your attention to our charter: > > > > A solution must not modify the other aspects of SNMPv3 protocol = as > > defined in STD 62 (EG, it must not create new PDU types). It = should > > also be compliant with the security model architectural = block of > > SNMPv3, as outlined in RFC 3411. And if at all = possible, it should > > also not change any other protocols either. > > > > It seems clear to me that adding a new architectural element such as > > call home falls outside that charter. >=20 > I would ask that you please explain to me how you came to this > conclusion. Further, I ask that you explain what work would have to = be > done for "call home" functionality that would NOT have to be done > otherwise such that it is out of scope. =20 I may not be exactly derived from the phrases above, but I interpret our current charter such that our goal is securing SNMP functions and that=20 this excludes adding functionality that is not directly related to = security. =20 If the SNMP community identifies the need to support "call home" and if it agrees how to support it, then it may become an issue for ISMS how to secure this feature appropriately. =20 Thanks, =20 Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 13:07:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tHk-0007XW-IR; Sun, 21 Aug 2005 13:07:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6tHi-0007XR-FA for isms@megatron.ietf.org; Sun, 21 Aug 2005 13:07:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08522 for ; Sun, 21 Aug 2005 13:06:59 -0400 (EDT) Message-Id: <200508211706.NAA08522@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6ts5-0003Yd-DB for isms@ietf.org; Sun, 21 Aug 2005 13:44:39 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050821170646011000qppue>; Sun, 21 Aug 2005 17:06:47 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Nelson, David'" , "'Wijnen, Bert \(Bert\)'" , Subject: RE: securityName/groupName [was RE: [Isms] ISMS charter discussion] Date: Sun, 21 Aug 2005 13:06:40 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB20E8BD7@europa.office> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWk3JuBnUlAicA/TZu7F+bqG0hjMQABLvxAAFkucTMACyMHIA== X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I prefer the "other SNMP parameters" wording. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Sunday, August 21, 2005 7:47 AM > To: Nelson, David; Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: securityName/groupName [was RE: [Isms] ISMS > charter discussion] > > Woul it be acceptable for everybody if we replaced > "securityName and groupName" with > "securityName and other SNMP parameters"? > > Juergen > > ________________________________ > > From: isms-bounces@lists.ietf.org on behalf of Nelson, David > Sent: Fri 19.08.2005 19:27 > To: Wijnen, Bert (Bert); isms@ietf.org > Subject: RE: securityName/groupName [was RE: [Isms] ISMS > charter discussion] > > > > Bert Wijnen writes > > > It could be that when we get the session setup call and > > we check with RADIUS, that at that point we populate some > > of the internal MIB tables with (temporary maybe) securityName > > and mapping into a group) and then decide that the session > > must use some specific (temporary) userName (in the security > > Paramters of the SNMPv3 message) that maps to the proper > > securityName that was instantiated in the VACM tables for > > this session. > > That aligns with what I was thinking. > > > Anyway, we have lots of work to do there I think > > Yes. > > > I have sort of preached in the past that I would popolate the MIB > > at the managed device with (basically unknow) users and secrets. > > They would be know on the managed device and on the NMS station. > > They would (in my view) represent roles as you describe). > > > > At the NMS, a user/person logs in (e.g. dnelson) and based on > > the credentials he gives he can then act in a particular role. > > It would make it so much easier if dnelsen leaves the company and > > you need to remove his access rights. You only need to do it on > > the NMS(es) instead of having to do it on (hundreds of) thousands > > of devices. Same for when a new operator comes and joins the team. > > This is a method of obtaining some of the benefits of ISMS, without > having to implement ISMS. I think that ISMS, at a very high level, > effectively moves the mapping of the specific usernames to generic > usernames (roles) out of the NMS and into the AAA server. > > > As long as we can define a way to do that without having to > > touch many many places inside an SNMP implementation. > > The devil is always in the details. It is well that we understand the > high level issues and work required so that we don't charter > goals that > are too difficult to achieve. > > > The way I describe it there > > I think tries to leave VACM alone and instead allow > > (at session setup) to populate some entries and maybe > assign a dynamic > > userName or some such (that maps into a temporrary/dynamic > securityName). > > That way, the code changes could be localized to where we must > add/insert > > the new securityModel anyway. > > Yes, I agree that is the desired approach. > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 16:58:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wtF-00030k-I2; Sun, 21 Aug 2005 16:58:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6wtB-00030f-Ta for isms@megatron.ietf.org; Sun, 21 Aug 2005 16:57:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18689 for ; Sun, 21 Aug 2005 16:57:55 -0400 (EDT) Message-Id: <200508212057.QAA18689@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6xTb-0000NA-Ra for isms@ietf.org; Sun, 21 Aug 2005 17:35:37 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050821205747011000rv0fe>; Sun, 21 Aug 2005 20:57:47 +0000 From: "David B Harrington" To: Date: Sun, 21 Aug 2005 16:57:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB20E8BDA@europa.office> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWmTJD5hhy64pF0RmeB6rvAZrQYdwANndBA X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] RE: ISMS charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, The main problem we are faced with in determining whether "call-home" is in or out of scope is understanding the use cases for "call-home" functionality. 1) If the purpose is to work around NATs and firewalls, then I consider this out of scope because it adds a feature not currently found in SNMP, and not directly related to security model functionality. 2) If the purpose is to permit agents to select the managers they want to be managed by, I consider this out of scope because there is no such feature in SNMP, and this is not directly related to security model functionality. 3) If the purpose is to permit trap-directed polling, then I would observe that trap-directed polling is not a function of the security model, but a use case of the application subsystem. If ISMS provides a call-home functionality, then it will need to provide a mechanism to configure where home is, and what security parameters are required. This is information contained in RFC3413, the "SNMP Applications" document. It is not within our scope to define new applications or new approaches to RFC3413 functionality. Any proposed approach should use the RFC3413 MIB modules for configuration (at least until a new WG addresses leveraging existing standards to supplement/replace RFC3413 functionality). In my opinion, the discussion of trap-directed-polling is in scope only to the degree that the security subsystem must not PREVENT the use of trap-directed polling. I am not aware that an SSH security model prevents the use of trap-directed polling. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 17:16:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6xB6-0005z8-5b; Sun, 21 Aug 2005 17:16:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6xB4-0005z0-3r for isms@megatron.ietf.org; Sun, 21 Aug 2005 17:16:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19231 for ; Sun, 21 Aug 2005 17:16:23 -0400 (EDT) Message-Id: <200508212116.RAA19231@ietf.org> Received: from sccrmhc13.comcast.net ([63.240.76.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E6xlV-0000lN-3P for isms@ietf.org; Sun, 21 Aug 2005 17:54:05 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <2005082121161601300l36dje>; Sun, 21 Aug 2005 21:16:16 +0000 From: "David B Harrington" To: Date: Sun, 21 Aug 2005 17:16:13 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032485@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWS9BELBTW2kjDVRQaKhgdxmRfBUwAlCmygAANYlaA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] securityName/groupname X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Here's what I'm hearing (and have heard in the past): 1) we have an authentication subsystem that yields a securityName. 2) we have access control currently based on group-based policies. 3) not everybody believes policies should be based on groups 4) often groups are defined to match organizational roles, but not always 5) we need a binding between the securityName and the access control policies 6) this binding should be done inside/outside the access control subsystem 7) this binding should be done inside/outside the authentication subsystem I see three aspects: 1) principal authentication 2) access control policies 3) authorization of a principal to operate within a given policy. This is similar to the RADIUS Filter-ID mechanism, where "named" filters (policies) already exist on the access device, and RADIUS authenticates the principal and identifies the filters (policies) that should be applied to the principal's traffic. The proposal in the RADEXT WG for management policies was designed to directly apply to the problem we are trying to resolve. So, let's 1) make the access control subsystem the place where filters (views) are pre-defined and named, 2) make the security model responsible for authenticating the principal, and 3) make the security model responsible for identifying the named filters to be applied. The USM security model already has two boxes for "mechanisms" for authentication and privacy; let's add a third "mechanism" for authorization. 4) let's add a parameter to the SNMPv3 ASIs for an accessFilterList, which in a standardized format contains a human-readable list of policy filters to be applied for that securityname/securityModel/securityLevel. This approach appends a new parameter, accessFilterList, to the ASIs, to be used with securityModel, securityName, and securityLevel for access control. Does this sound reasonable? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 21 22:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7278-0005xw-93; Sun, 21 Aug 2005 22:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7276-0005xo-C2 for isms@megatron.ietf.org; Sun, 21 Aug 2005 22:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02565 for ; Sun, 21 Aug 2005 22:32:38 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E72hY-000824-79 for isms@ietf.org; Sun, 21 Aug 2005 23:10:22 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3FC97E0049; Sun, 21 Aug 2005 22:31:58 -0400 (EDT) To: "Juergen Quittek" References: <88F766D04E6AF3409B39E60D7D933EB20E8BD7@europa.office> From: Sam Hartman Date: Sun, 21 Aug 2005 22:31:58 -0400 In-Reply-To: <88F766D04E6AF3409B39E60D7D933EB20E8BD7@europa.office> (Juergen Quittek's message of "Sun, 21 Aug 2005 13:47:11 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org Subject: [Isms] Re: securityName/groupName X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Juergen" == Juergen Quittek writes: Juergen> Woul it be acceptable for everybody if we replaced Juergen> "securityName and groupName" with "securityName and other Juergen> SNMP parameters"? I'm a bit concerned about over-broad wording. Wording so broad that redefining VACM was inc scope is clearly too broad. Also, is there anyone who supports remapping securityname instead of the group name? I am concerned that I may have accidentally given support to a specific proposal when what I cared about was giving support to solving a generic problem without supporting a specific solution. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 10:21:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DB7-0002KX-Ec; Mon, 22 Aug 2005 10:21:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7DB5-0002KH-AK for isms@megatron.ietf.org; Mon, 22 Aug 2005 10:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18710 for ; Mon, 22 Aug 2005 10:21:28 -0400 (EDT) Received: from galaxy.systems.pipex.net ([62.241.162.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Dld-0002LF-G1 for isms@ietf.org; Mon, 22 Aug 2005 10:59:19 -0400 Received: from pc6 (1Cust132.tnt107.lnd4.gbr.da.uu.net [213.116.62.132]) by galaxy.systems.pipex.net (Postfix) with SMTP id 0B86AE0002A0; Mon, 22 Aug 2005 15:21:06 +0100 (BST) Message-ID: <052201c5a71c$23c89d00$0601a8c0@pc6> From: "Tom Petch" To: "Juergen Quittek" , References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> <2B9BF5FAB4C5547D819BAE81@[192.168.1.111]> Subject: Re: [Isms] ISMS charter discussion Date: Mon, 22 Aug 2005 15:11:50 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Tom Petch ----- Original Message ----- From: "Juergen Quittek" To: Sent: Friday, August 19, 2005 10:18 AM Subject: RE: [Isms] ISMS charter discussion > > Please have a look at the outline of our new charter. > You will find the current outline below. > > Particularly, I would like you to express your opinion about > > - explicitly mentioning securityName and securityGroup > - having a revision RFC 3430 as one of our work items > > Ken and I will turn the outline into a text version and post > it on Monday. Then we will have next week for discussing wordings. > > Juergen > > ----------------------- > ISMS WG charter outline > ----------------------- > > Background > - USM has limited deployment > - no standard for integrating key and user management into > deployed authentication infrastructures Not quite right IMHO; even with SSH, there is no standard for integrating SSH with eg RADIUS (nor do I think isms should work on one). Rather it is the nonstandard approach - in the sense of not conforming to pre-existing standards, RFC 3414 itself is of course a standard - to key and user management taken by USM that makes integration difficult. Defining SNMP over SSH leverages the existing deployments of SSH which have performed this integration to the satisfaction of users - how, I would love to know, but noone seems to know, but what the heck, they have done it so we should trust them and get on with it. > - SSH is widely deployed > - SSH integration into AAA, e.g., RADIUS, is available > > WG goals > - define a new SNMP security model that utilzes the SSH protocol > to provide message security services for SNMP > - compliancy with SNMPv3 architecture, no modification of SNMPv3 > - work on new access control models and VACM mappings out of scope > (except for mapping via securityName or securityGroup) > - open to further transport mappings, such as BEEP, TLS, ... I think it wrong to include this potential can of worms at this point in time; later, yes. As several have pointed out, achieving consensus in isms is hard work. I strongly believe we should focus on as limited an objective as is beneficial at this time, the one transport we select, to give us the best chance of success. We can always request a more relaxed charter once we have achieved our next goal; allowing all possible options in parallel at this time can only dilute our efforts and make success less likely. > - following a session-based approach > - define a standard method for mapping from AAA-provisioned > authorization parameter(s) to SNMP securityName and securityGroup > > Work Items: > - specify how transport mapping security models (TMSMs) > fit into the SNMPv3 architecture > - specify RADIUS attributes used to populate > securityname and other SNMP parameters > - define how to use SSH between the two snmp engines this is overwhelmingly IMHO the top of the list (assuming we reach consensus on SSH as the chosen protocol) > - specify the SSH security model for SNMP > > Documents > - A document that specifies how transport mapping security models > (TMSMs) fit into the SNMPv3 architecture and which defines the Disagree, for the reasons stated above. We should focus on making work our one chosen transport. Considering all the features present and not present in other alternatives that we have not chosen can only compromise this one; if I support the choice of protocol X because it fits well with SNMP on account of unique features A and B, but then we are not allowed to use features A and B because they are not present in protocols Y or Z and so cannot form part of a generic TMSM. Forget it, choose a protocol and may be we can make it work. USM is one document, model, protocol, MIB module etc; I see no benefit in splitting up our work into multiple documents. > requirements for transport mapping security models. > - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) > - A document specifying the SSH security model for SNMP. > This specification must comply with the TMSM requirements. > - An Applicability statement that sets up reasonable mandatory to > implement methods. > ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it > with the SSH transport model (or move RFC 3430 to historic) ? > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:09:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dvd-00030l-6d; Mon, 22 Aug 2005 11:09:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Dvb-00030e-2G for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:09:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21648 for ; Mon, 22 Aug 2005 11:09:32 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7EWA-0003pT-9D for isms@ietf.org; Mon, 22 Aug 2005 11:47:23 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 67CC51BAC4D; Mon, 22 Aug 2005 17:09:19 +0200 (CEST) Date: Mon, 22 Aug 2005 18:07:04 +0200 From: Juergen Quittek To: Tom Petch , isms@ietf.org Subject: Re: [Isms] ISMS charter discussion Message-ID: <67716E61EC9A903CD904D18F@[192.168.0.112]> In-Reply-To: <052201c5a71c$23c89d00$0601a8c0@pc6> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69010324E7@MAANDMBX2.ets.enterasys.com> <2B9BF5FAB4C5547D819BAE81@[192.168.1.111]> <052201c5a71c$23c89d00$0601a8c0@pc6> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Tom, Thanks for the comments. Please see replies inline. --On 8/22/2005 3:11 PM +0200 Tom Petch wrote: > > Tom Petch > > ----- Original Message ----- > From: "Juergen Quittek" > To: > Sent: Friday, August 19, 2005 10:18 AM > Subject: RE: [Isms] ISMS charter discussion > >> >> Please have a look at the outline of our new charter. >> You will find the current outline below. >> >> Particularly, I would like you to express your opinion about >> >> - explicitly mentioning securityName and securityGroup >> - having a revision RFC 3430 as one of our work items >> >> Ken and I will turn the outline into a text version and post >> it on Monday. Then we will have next week for discussing wordings. >> >> Juergen >> >> ----------------------- >> ISMS WG charter outline >> ----------------------- >> >> Background >> - USM has limited deployment >> - no standard for integrating key and user management into >> deployed authentication infrastructures > > Not quite right IMHO; even with SSH, there is no standard for integrating SSH > with eg RADIUS (nor do I think isms should work on one). Rather it is the > nonstandard approach - in the sense of not conforming to pre-existing standards, > RFC 3414 itself is of course a standard - to key and user management taken by > USM that makes integration difficult. Defining SNMP over SSH leverages the > existing deployments of SSH which have performed this integration to the > satisfaction of users - how, I would love to know, but noone seems to know, but > what the heck, they have done it so we should trust them and get on with it. I agree in general and take the 'no standard' phrase out. >> - SSH is widely deployed >> - SSH integration into AAA, e.g., RADIUS, is available >> >> WG goals >> - define a new SNMP security model that utilzes the SSH protocol >> to provide message security services for SNMP >> - compliancy with SNMPv3 architecture, no modification of SNMPv3 >> - work on new access control models and VACM mappings out of scope >> (except for mapping via securityName or securityGroup) >> - open to further transport mappings, such as BEEP, TLS, ... > > I think it wrong to include this potential can of worms at this point in time; > later, yes. > As several have pointed out, achieving consensus in isms is hard work. I > strongly believe we should focus on as limited an objective as is beneficial at > this time, the one transport we select, to give us the best chance of success. > We can always request a more relaxed charter once we have achieved our next > goal; allowing all possible options in > parallel at this time can only dilute our efforts and make success less likely. I think it is important to be open to future transport mappings. This does not imply that a BEEP or a TLS security model is included in the charter. But this (hopefully) also does not discourage people working on other solutions. >> - following a session-based approach >> - define a standard method for mapping from AAA-provisioned >> authorization parameter(s) to SNMP securityName and securityGroup >> >> Work Items: >> - specify how transport mapping security models (TMSMs) >> fit into the SNMPv3 architecture >> - specify RADIUS attributes used to populate >> securityname and other SNMP parameters >> - define how to use SSH between the two snmp engines > > this is overwhelmingly IMHO the top of the list (assuming we reach consensus on > SSH as the chosen protocol) > >> - specify the SSH security model for SNMP >> >> Documents >> - A document that specifies how transport mapping security models >> (TMSMs) fit into the SNMPv3 architecture and which defines the > > Disagree, for the reasons stated above. We should focus on making work our one > chosen transport. Considering all the features present and > not present in other alternatives that we have not chosen can only compromise > this one; if I support the choice of protocol X because it fits well with SNMP > on account of unique features A and B, but then we are not allowed to use > features A and B because they are not present in protocols Y > or Z and so cannot form part of a generic TMSM. Forget it, choose a protocol and > may be we can make it work. > > USM is one document, model, protocol, MIB module etc; I see no benefit in > splitting up our work into multiple documents. I want to see more opinions on this issue. I see your point, but I am not yet convinced. Thanks, Juergen >> requirements for transport mapping security models. >> - A document specifying RADIUS attributes for TMSMs (in RADEXT WG?) >> - A document specifying the SSH security model for SNMP. >> This specification must comply with the TMSM requirements. >> - An Applicability statement that sets up reasonable mandatory to >> implement methods. >> ? A revision RFC 3430 (SNMP over TCP) to ensure it is aligned it >> with the SSH transport model (or move RFC 3430 to historic) ? >> > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:17:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E3H-000473-OA; Mon, 22 Aug 2005 11:17:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7E3G-00046p-QD for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:17:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22079 for ; Mon, 22 Aug 2005 11:17:28 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Edq-00045l-5p for isms@ietf.org; Mon, 22 Aug 2005 11:55:19 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 03D501BAC4D for ; Mon, 22 Aug 2005 17:17:19 +0200 (CEST) Date: Mon, 22 Aug 2005 18:15:04 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] draft of ISMS charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Here is a full text version of the charter items we discussed. Several phrases are taken from Juergen Schoenwaelder's charter proposal. Still open is the issue that Tom raised today: Shall we have two documents, a general one on TMSMs and a specific one on SSH security model, or shall we have just a single document defining architectural considerations and the SSH security model? Further open is whether or not we should also work on a revision of RFC 3430. Any opinion on that? Thanks, Juergen ========================================= Integrated Security Model for SNMP (isms) ========================================= Chair(s): N.N. N.N. Security Area Director(s) Sam Hartman Russell Housley Security Area Advisor: Sam Hartman Mailing Lists: General discussion: isms@ietf.org To (un)subscribe: isms-request@ietf.org 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 User-based security model (USM). However, the USM approach has seen limited deployment so far. One frequently reported reasons is the lack of integration of USM key and user management into deployed authentication infrastructures. SSH is a widely deployed access protocol for remote devices configuration. Many devices support the integration of SSH user authentication with AAA systems via protocols such as RADIUS. The goal of the ISMS working group is developing a new session-based security model for SNMP that integrates with widely deployed user and key management systems. For this integration the working group will define a standard method for mapping from AAA-provisioned authorization parameter(s) to corresponding SNMP parameters. In order to leverage the authentication information already accessible at managed devices, the new security model will use the SSH protocol. However, the integration of an SSH transport mapping security model into the SNMPv3 architecture should be defined such that it is open to support potential alternative transport mappings to protocols such as BEEP and TLS. The new security model must not modify any other aspects of SNMPv3 protocol as defined in STD 62 (e.g., it must not create new PDU types). It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411. Work on new access control models or centralized administration of View-based Access Control Model (VACM) rules and mappings is outside the scope of the working group. The working group will cover the following work items: - Specify how transport mapping security models (TMSMs) fit into the SNMPv3 architecture. - Specify a mapping from AAA-provisioned authorization parameter(s) to securityName and other corresponding SNMP parameters. This item might be shared with the RADEXT WG. - Define how to use SSH between the two SNMP engines - Specify the SSH security model for SNMP. Goals an Milestones: Oct 2005 Initial version of a general transport mapping security models (TMSMs) document that specifies how TMSMs fit into the SNMPv3 architecture and that defines the requirements for transport mapping security models. Oct 2005 Initial version of a document specifying RADIUS attributes for TMSMs (in RADEXT WG?) Oct 2005 Initial version of a document specifying the SSH security model for SNMP. Feb 2006 Initial version of an applicability statement that sets up reasonable mandatory to implement methods. Apr 2006 revision RFC 3430 (SNMP over TCP) to ensure it is aligned it with the SSH transport model (or move RFC 3430 to historic) Feb 2005 Submit TMSM document to IESG Feb 2005 Submit RADIUS attributes for TMSMs to IESG Jun 2005 Submit SSH TMSM to IESG Aug 2005 Submit applicability statement to IESG Aug 2005 Submit revision of RFC 3430 to IESG _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ECB-000728-Di; Mon, 22 Aug 2005 11:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EC9-0006yA-4G for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:26:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22715 for ; Mon, 22 Aug 2005 11:26:35 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Emf-0004Qv-40 for isms@ietf.org; Mon, 22 Aug 2005 12:04:26 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id B99EC39DE7; Mon, 22 Aug 2005 17:26:15 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01545-10; Mon, 22 Aug 2005 17:26:14 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 8278539DE6; Mon, 22 Aug 2005 17:26:14 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id 0454A3BA882; Mon, 22 Aug 2005 17:26:12 +0200 (CEST) Date: Mon, 22 Aug 2005 17:26:12 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Subject: Re: [Isms] ISMS charter discussion Message-ID: <20050822152612.GA15696@boskop.local> Mail-Followup-To: Juergen Quittek , Tom Petch , isms@ietf.org References: <2B9BF5FAB4C5547D819BAE81@[192.168.1.111]> <052201c5a71c$23c89d00$0601a8c0@pc6> <67716E61EC9A903CD904D18F@[192.168.0.112]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67716E61EC9A903CD904D18F@[192.168.0.112]> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 06:07:04PM +0200, Juergen Quittek wrote: > >>Documents > >> - A document that specifies how transport mapping security models > >> (TMSMs) fit into the SNMPv3 architecture and which defines the > > > >Disagree, for the reasons stated above. We should focus on making work > >our one > >chosen transport. Considering all the features present and > >not present in other alternatives that we have not chosen can only > >compromise > >this one; if I support the choice of protocol X because it fits well with > >SNMP > >on account of unique features A and B, but then we are not allowed to use > >features A and B because they are not present in protocols Y > >or Z and so cannot form part of a generic TMSM. Forget it, choose a > >protocol and > >may be we can make it work. > > > >USM is one document, model, protocol, MIB module etc; I see no benefit in > >splitting up our work into multiple documents. > > I want to see more opinions on this issue. > I see your point, but I am not yet convinced. TMSM is an architectural document by nature which explains how a transport mapping security model fits into the existing SNMPv3 architecture. We need in addition a document which defines how SNMP over SSH actually works (and I would have no problem to include in this document an applicability statement if the goal is to reduce the number of documents). It is an open question for me whether the RADIUS specific work belongs into RADEXT rather than ISMS - but in any case, I consider this another document. You seem to dislike the architectural work Dave has been doing and from the emails I have read you seem to prefer to have things muddled together in one piece of document. I do not think this is the right approach - in fact, the BEEP document does refer back to the TMSM document so there seems to be some value in having worked out the architectural issues separate from the SNMP over SSH details. Anyway, it is fine to have different opinions. I think I just stated my preference. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EIP-0008Ch-Cs; Mon, 22 Aug 2005 11:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EIN-0008Cc-Tl for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:33:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23081 for ; Mon, 22 Aug 2005 11:33:05 -0400 (EDT) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Esy-0004dc-D6 for isms@ietf.org; Mon, 22 Aug 2005 12:10:56 -0400 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D6B4239DE7; Mon, 22 Aug 2005 17:32:57 +0200 (CEST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 01887-08; Mon, 22 Aug 2005 17:32:56 +0200 (CEST) Received: from boskop.local (unknown [10.50.250.214]) by hermes.iu-bremen.de (Postfix) with ESMTP id 33C3739DE8; Mon, 22 Aug 2005 17:32:56 +0200 (CEST) Received: by boskop.local (Postfix, from userid 501) id AC62B3BA8A7; Mon, 22 Aug 2005 17:32:54 +0200 (CEST) Date: Mon, 22 Aug 2005 17:32:54 +0200 From: Juergen Schoenwaelder To: Juergen Quittek Subject: Re: [Isms] draft of ISMS charter Message-ID: <20050822153254.GB15696@boskop.local> Mail-Followup-To: Juergen Quittek , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Mon, Aug 22, 2005 at 06:15:04PM +0200, Juergen Quittek wrote: > Still open is the issue that Tom raised today: > Shall we have two documents, a general one on TMSMs and a > specific one on SSH security model, or shall we have just > a single document defining architectural considerations and > the SSH security model? > > Further open is whether or not we should also work on a > revision of RFC 3430. Any opinion on that? I am fine with keeping this out of the ISMS charter - lets see where ISMS goes and then we can take a decision whether RFC 3430 is worth to be updated or better should go to historic or just stay around as it is when we are done. The other thing to look at is the question where we do the RADIUS specific work - whether that actually falls within ISMS (which would be logical since ISMS and the RADIUS stuff must work together) or whether this actually falls within RADEXT where the RADIUS experts are hanging around which we need to review the document. I do not have a strong opinion here - perhaps something the IESG should give advise. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:44:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ETi-000279-KT; Mon, 22 Aug 2005 11:44:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ETh-00026p-Ez for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:44:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23557 for ; Mon, 22 Aug 2005 11:44:46 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7F4H-0004wd-4U for isms@ietf.org; Mon, 22 Aug 2005 12:22:38 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA27220 for ; Mon, 22 Aug 2005 11:47:22 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma027183; Mon, 22 Aug 05 11:46:29 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 22 Aug 2005 11:43:47 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 22 Aug 2005 11:43:47 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:43:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 11:43:46 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032507@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWnLv9i565ycsYcR0aI2eDBXBkt6gAALP9A From: "Nelson, David" To: , "Juergen Quittek" X-OriginalArrivalTime: 22 Aug 2005 15:43:47.0679 (UTC) FILETIME=[491C56F0:01C5A730] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:65.2979 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > The other thing to look at is the question where we do the RADIUS > specific work - whether that actually falls within ISMS (which would > be logical since ISMS and the RADIUS stuff must work together) or > whether this actually falls within RADEXT where the RADIUS experts are > hanging around which we need to review the document. I do not have a > strong opinion here - perhaps something the IESG should give advise. Speaking with my RADEXT WG Co-Chair hat on, this work could occur either in RADEXT or ISMS, but concurrent WG review and concurrent WGLC in both WGs SHOULD be required. RADEXT has similar arrangements with other WGs, such as GEOPRIV. Dave Nelson Co-Chair RADEXT WG _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 11:51:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EaU-0003Bb-3r; Mon, 22 Aug 2005 11:51:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7EaS-0003BU-Fl for isms@megatron.ietf.org; Mon, 22 Aug 2005 11:51:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23897 for ; Mon, 22 Aug 2005 11:51:45 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7FB3-00058U-Cw for isms@ietf.org; Mon, 22 Aug 2005 12:29:37 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id LAA27738 for ; Mon, 22 Aug 2005 11:54:27 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma027620; Mon, 22 Aug 05 11:53:33 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 22 Aug 2005 11:50:51 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 22 Aug 2005 11:50:51 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 11:50:50 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 11:50:49 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032509@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWnLv9i565ycsYcR0aI2eDBXBkt6gAAdP4Q From: "Nelson, David" To: , "Juergen Quittek" X-OriginalArrivalTime: 22 Aug 2005 15:50:50.0414 (UTC) FILETIME=[451494E0:01C5A731] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:99.8514 P:95.9108 R:95.9108 S:14.0549 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > The other thing to look at is the question where we do the RADIUS > specific work - whether that actually falls within ISMS (which would > be logical since ISMS and the RADIUS stuff must work together) or > whether this actually falls within RADEXT where the RADIUS experts are > hanging around which we need to review the document. I do not have a > strong opinion here - perhaps something the IESG should give advise. Speaking as an individual and co-author of a relevant I-D, I would like to point out that we have a draft under consideration in RADEXT that currently includes this functionality. http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho rization-02.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 13:26:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G49-0006Bg-43; Mon, 22 Aug 2005 13:26:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7G47-0006BY-SV for isms@megatron.ietf.org; Mon, 22 Aug 2005 13:26:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29625 for ; Mon, 22 Aug 2005 13:26:28 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Geh-0008Ho-Ge for isms@ietf.org; Mon, 22 Aug 2005 14:04:21 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j7MHQ0o5029284; Mon, 22 Aug 2005 10:26:00 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j7MHPsqE026298; Mon, 22 Aug 2005 10:25:54 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j7MHPr6B026293; Mon, 22 Aug 2005 10:25:53 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 22 Aug 2005 10:25:53 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] draft of ISMS charter In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032509@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, Every time I read the below I-D, the term "framed management" just seems inappropriate. I'm sorry that I can't offer a better term, but that term makes it seem like an inappropriate mechanism is being used. Also, when you work through the examples in section 9, I just don't believe that the model maps well to SNMPv3 VACM. Bottom line for me is that the I-D is a good start, it's not nearly well enough developed to go forward. On Mon, 22 Aug 2005, Nelson, David wrote: > > The other thing to look at is the question where we do the RADIUS > > specific work - whether that actually falls within ISMS (which would > > be logical since ISMS and the RADIUS stuff must work together) or > > whether this actually falls within RADEXT where the RADIUS experts are > > hanging around which we need to review the document. I do not have a > > strong opinion here - perhaps something the IESG should give advise. > > Speaking as an individual and co-author of a relevant I-D, I would like > to point out that we have a draft under consideration in RADEXT that > currently includes this functionality. > > http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho > rization-02.txt > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 13:53:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GUU-0003LP-5Y; Mon, 22 Aug 2005 13:53:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GUT-0003LK-A0 for isms@megatron.ietf.org; Mon, 22 Aug 2005 13:53:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01017 for ; Mon, 22 Aug 2005 13:53:43 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7H52-0000eE-Or for isms@ietf.org; Mon, 22 Aug 2005 14:31:35 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 9411C1BAC4D for ; Mon, 22 Aug 2005 19:53:30 +0200 (CEST) Date: Mon, 22 Aug 2005 20:51:17 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Re: draft of ISMS charter X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, I used the wrong year for the last 5 milestones. In > Feb 2005 Submit TMSM document to IESG > Feb 2005 Submit RADIUS attributes for TMSMs to IESG > Jun 2005 Submit SSH TMSM to IESG > Aug 2005 Submit applicability statement to IESG > Aug 2005 Submit revision of RFC 3430 to IESG all occurrences of "2005" need to be replaced by "2006". Thanks to Simon for pointing this out. Juergen --On 8/22/2005 6:15 PM +0200 Juergen Quittek wrote: > Dear all, > > Here is a full text version of the charter items we discussed. > Several phrases are taken from Juergen Schoenwaelder's charter > proposal. > > Still open is the issue that Tom raised today: > Shall we have two documents, a general one on TMSMs and a > specific one on SSH security model, or shall we have just > a single document defining architectural considerations and > the SSH security model? > > Further open is whether or not we should also work on a > revision of RFC 3430. Any opinion on that? > > Thanks, > > Juergen > > > ========================================= > Integrated Security Model for SNMP (isms) > ========================================= > > Chair(s): > N.N. > N.N. > > Security Area Director(s) > Sam Hartman > Russell Housley > > Security Area Advisor: > Sam Hartman > > Mailing Lists: > General discussion: isms@ietf.org > To (un)subscribe: isms-request@ietf.org > 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 User-based security model > (USM). However, the USM approach has seen limited deployment so far. > One frequently reported reasons is the lack of integration of USM > key and user management into deployed authentication infrastructures. > > SSH is a widely deployed access protocol for remote devices configuration. > Many devices support the integration of SSH user authentication with > AAA systems via protocols such as RADIUS. > > The goal of the ISMS working group is developing a new session-based > security model for SNMP that integrates with widely deployed user and > key management systems. > > For this integration the working group will define a standard method > for mapping from AAA-provisioned authorization parameter(s) to > corresponding SNMP parameters. > > In order to leverage the authentication information already accessible > at managed devices, the new security model will use the SSH protocol. > However, the integration of an SSH transport mapping security model into > the SNMPv3 architecture should be defined such that it is open to support > potential alternative transport mappings to protocols such as BEEP and TLS. > > The new security model must not modify any other aspects of SNMPv3 > protocol as defined in STD 62 (e.g., it must not create new PDU types). > It should also be compliant with the security model architectural block > of SNMPv3, as outlined in RFC 3411. > > Work on new access control models or centralized administration of > View-based Access Control Model (VACM) rules and mappings is outside > the scope of the working group. > > The working group will cover the following work items: > > - Specify how transport mapping security models (TMSMs) fit into > the SNMPv3 architecture. > - Specify a mapping from AAA-provisioned authorization parameter(s) > to securityName and other corresponding SNMP parameters. This > item might be shared with the RADEXT WG. > - Define how to use SSH between the two SNMP engines > - Specify the SSH security model for SNMP. > > Goals an Milestones: > > Oct 2005 Initial version of a general transport mapping security models > (TMSMs) document that specifies how TMSMs fit into the SNMPv3 > architecture and that defines the requirements for transport > mapping security models. > Oct 2005 Initial version of a document specifying RADIUS attributes for > TMSMs (in RADEXT WG?) > Oct 2005 Initial version of a document specifying the SSH security > model for SNMP. > Feb 2006 Initial version of an applicability statement that sets up > reasonable mandatory to implement methods. > Apr 2006 revision RFC 3430 (SNMP over TCP) to ensure it is aligned it > with the SSH transport model (or move RFC 3430 to historic) > Feb 2005 Submit TMSM document to IESG > Feb 2005 Submit RADIUS attributes for TMSMs to IESG > Jun 2005 Submit SSH TMSM to IESG > Aug 2005 Submit applicability statement to IESG > Aug 2005 Submit revision of RFC 3430 to IESG > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 13:55:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GW3-0003gN-SZ; Mon, 22 Aug 2005 13:55:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GW2-0003fz-Do for isms@megatron.ietf.org; Mon, 22 Aug 2005 13:55:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01098 for ; Mon, 22 Aug 2005 13:55:21 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7H6e-0000gx-CC for isms@ietf.org; Mon, 22 Aug 2005 14:33:12 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA06695 for ; Mon, 22 Aug 2005 13:58:01 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma006610; Mon, 22 Aug 05 13:56:51 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 22 Aug 2005 13:54:08 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 22 Aug 2005 13:54:08 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 13:54:08 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: RADIUS attribues for SNMPv3 (was RE: [Isms] draft of ISMS charter) Date: Mon, 22 Aug 2005 13:54:07 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250B@MAANDMBX2.ets.enterasys.com> Thread-Topic: RADIUS attribues for SNMPv3 (was RE: [Isms] draft of ISMS charter) Thread-Index: AcWnPpW0KirG04gzSwO7ykBKd7ATBQAAHYLw From: "Nelson, David" To: "David T. Perkins" X-OriginalArrivalTime: 22 Aug 2005 17:54:08.0289 (UTC) FILETIME=[7E8EB910:01C5A742] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:87.1726 M:99.8514 P:95.9108 R:95.9108 S:51.0383 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Perkins writes... > Every time I read the below I-D, the term "framed management" just seems > inappropriate. I'm sorry that I can't offer a better term, but that > term makes it seem like an inappropriate mechanism is being used. If the only issue is the name, that certainly can be changed. This document is written from a RADIUS perspective, based on the terminology, context and history of RADIUS documentation. In my previous discussions on this topic, I have sometimes found that AAA experts phrase the issues differently than SNMP experts. What draft this is attempting to say is that there are two basic types of management access to hosts (managed entities): (a) command line interactive, via terminal emulation, and (b) "other". Other involves the use of an application layer protocol, such as SNMP or HTTP. CLI does not involve such a protocol. Yes, remote CLI runs over application protocols such as telnet and rlogin. But the management objects themselves are expressed in the non-protocol domain of ASCII command strings. Perhaps this is not a very useful distinction to make. It would be possible to collapse the selection of SNMPv3 as a remote management protocol from two RADIUS attributes down to one. The current version of the draft selects SNMPv3 by using a Service-Type of Framed-Management together with a Framed-Management-Protocol of SNMPv3. One could "flatten" this design by introducing a new Service-Type value of SNMPv3. We would have to flatten all the other remote management protocol types as well. Do you think this is a significant issue of RADIUS protocol clarity? > Also, when you work through the examples in section 9, I just don't > believe that the model maps well to SNMPv3 VACM. The authors have been waiting to see how this debate settles out in ISMS before submitting the next revision. I have seen discussion on this list suggesting that *some* AAA-provisioned indication of the desired SNMP access control policy is needed. It has been suggested that the RADIUS attribute could provide (a) the SNMP securityName, (b) the SNMP groupName, or (c) some new object to used for this kind of mapping. >From a RADIUS perspective, it really doesn't matter. > Bottom line for me is that the I-D is a good start, it's not nearly > well enough developed to go forward. First, let me say that the draft intended to describe a new RADIUS attribute that could be used for the purposes of ISMS. It does not contain any details as to *how" ISMS would use the attribute, beyond the general notion that it provides a mapping into existing access control mechanisms of SNMPv3. Those details do need to be specified. They can be specified in a RADIUS document or an SNMP document. As always, suggestions are welcome. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 15:44:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IDW-0007mW-Ps; Mon, 22 Aug 2005 15:44:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IDV-0007mP-2g for isms@megatron.ietf.org; Mon, 22 Aug 2005 15:44:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08222 for ; Mon, 22 Aug 2005 15:44:19 -0400 (EDT) Message-Id: <200508221944.PAA08222@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Io7-000466-15 for isms@ietf.org; Mon, 22 Aug 2005 16:22:12 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <20050822194218011000ttj5e>; Mon, 22 Aug 2005 19:42:18 +0000 From: "David B Harrington" To: "'Sam Hartman'" , "'Juergen Quittek'" Subject: RE: [Isms] Re: securityName/groupName Date: Mon, 22 Aug 2005 15:42:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWmweDH0rrBsmU9TAK4xcb+WQl+MAAjiwlA X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, The mapping from a model-specific identity to a securityName is model-specific by definition. There are issues associated with using securityName in a manner that loses granularity. If the remapping is done within the security model and the security model addresses those issues adequately, I see no problem. If the remapping is done inside the ACM model and the ACM addresses these issues adeqautely, I see no problem. I think remapping securityName instead of groupName is fine to keep as an option, but I definitely prefer a groupName mapping to overloading securityName. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Sunday, August 21, 2005 10:32 PM > To: Juergen Quittek > Cc: isms@ietf.org > Subject: [Isms] Re: securityName/groupName > > >>>>> "Juergen" == Juergen Quittek writes: > > Juergen> Woul it be acceptable for everybody if we replaced > Juergen> "securityName and groupName" with "securityName and other > Juergen> SNMP parameters"? > > > I'm a bit concerned about over-broad wording. Wording so broad that > redefining VACM was inc scope is clearly too broad. Also, is there > anyone who supports remapping securityname instead of the group name? > I am concerned that I may have accidentally given support to a > specific proposal when what I cared about was giving support to > solving a generic problem without supporting a specific solution. > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 15:47:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IGs-0008LB-KN; Mon, 22 Aug 2005 15:47:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IGq-0008L6-TT for isms@megatron.ietf.org; Mon, 22 Aug 2005 15:47:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08363 for ; Mon, 22 Aug 2005 15:47:46 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7IrS-0004Ap-O5 for isms@ietf.org; Mon, 22 Aug 2005 16:25:40 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id A879C1BAC4D; Mon, 22 Aug 2005 21:47:36 +0200 (CEST) Date: Mon, 22 Aug 2005 22:45:21 +0200 From: Juergen Quittek To: "Nelson, David" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] draft of ISMS charter Message-ID: <779266560F3C5483AA6C3F03@[192.168.0.112]> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, I am fine with both ways, having such a document either as ISMS or as RADEXT WG document. The ISMS charter can be shaped to include it. After reading the RADEXT charter I am not sure what would be the procedure for establishing the document as RADEXT work item. What does your arrangement with GEOPRIV look like? Anyway, I fully agree with you that such a document should receive extensive guidance and reviews from both WGs. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 8/22/2005 11:50 AM -0400 Nelson, David wrote: >> The other thing to look at is the question where we do the RADIUS >> specific work - whether that actually falls within ISMS (which would >> be logical since ISMS and the RADIUS stuff must work together) or >> whether this actually falls within RADEXT where the RADIUS experts are >> hanging around which we need to review the document. I do not have a >> strong opinion here - perhaps something the IESG should give advise. > > Speaking as an individual and co-author of a relevant I-D, I would like > to point out that we have a draft under consideration in RADEXT that > currently includes this functionality. > > http://www.ietf.org/internet-drafts/draft-nelson-radius-management-autho > rization-02.txt > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 16:04:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IWp-0004HK-Ox; Mon, 22 Aug 2005 16:04:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IWo-0004Gt-JV for isms@megatron.ietf.org; Mon, 22 Aug 2005 16:04:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11040 for ; Mon, 22 Aug 2005 16:04:15 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7J7I-0005JT-Tq for isms@ietf.org; Mon, 22 Aug 2005 16:42:09 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7MK44ZC007077 for ; Mon, 22 Aug 2005 16:04:04 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 22 Aug 2005 16:04:04 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 22 Aug 2005 16:04:04 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 22 Aug 2005 16:04:03 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 16:04:03 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250E@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWnUl3/BaPOwearTqCgqaOF1FCrvAAACOxg From: "Nelson, David" To: "Juergen Quittek" , X-OriginalArrivalTime: 22 Aug 2005 20:04:03.0945 (UTC) FILETIME=[A5216D90:01C5A754] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:56.4095 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, Bernard Aboba X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen, > I am fine with both ways, having such a document either > as ISMS or as RADEXT WG document. If it is a very simple document (one or two attributes) it may be better to include it in a related RADIUS document, but that is not a major decision point. > The ISMS charter can be shaped to include it. > After reading the RADEXT charter I am not sure what would > be the procedure for establishing the document as RADEXT > work item. A formal request from ISMS would likely be all that is required. This work is not going to be making any extensions to RADIUS that would raise charter flags on the basis of RADIUS backwards compatibility or Diameter forwards compatibility issues. The document that I have co-authored with Greg Weber should be ready for consideration as a RADEXT WG document once the needs of ISMS have been clarified. It is our intent to submit it as a WG work item. > What does your arrangement with GEOPRIV look like? The document is chartered in GEOPRIV and we are providing concurrent review. We are also chartered to work on documents in RADEXT that have been requested through liaison letters from other SDOs, such as 3GPP, 3GPP2, WiFi Alliance, WiMAX, etc. > Anyway, I fully agree with you that such a document should > receive extensive guidance and reviews from both WGs. Yes. Thanks! -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 16:13:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7IdB-0007NI-QM; Mon, 22 Aug 2005 16:10:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Id9-0007Mp-VC for isms@megatron.ietf.org; Mon, 22 Aug 2005 16:10:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13114 for ; Mon, 22 Aug 2005 16:10:49 -0400 (EDT) Message-Id: <200508222010.QAA13114@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7JDl-00067K-Jn for isms@ietf.org; Mon, 22 Aug 2005 16:48:42 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050822201036012005kp2ue>; Mon, 22 Aug 2005 20:10:37 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Juergen Quittek'" , Subject: RE: [Isms] ISMS charter discussion Date: Mon, 22 Aug 2005 16:10:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <052201c5a71c$23c89d00$0601a8c0@pc6> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnJR4RVP7vkHEnRPaovXa3n93y3gALKoRQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > > WG goals > > - open to further transport mappings, such as BEEP, TLS, ... > > I think it wrong to include this potential can of worms at > this point in time; > later, yes. > As several have pointed out, achieving consensus in isms is > hard work. I > strongly believe we should focus on as limited an objective > as is beneficial at > this time, the one transport we select, to give us the best > chance of success. I agree that we need to allow for this potential can of worms later, and that for now we should focus on one chosen security model. For that reason, I believe we need to discuss how additional proposals fit within the architecture of SNMPv3, i.e. by defining an architectural extension in TMSM to show how multiple models could exist concurrently (in keeping with the general philosophy of RFC 3411), and by focusing the WG efforts on ONE security model based on SSH ast this time. If proponents of alternative models want to spend time developing their proposals in parallel, I have no problem wth that, since we obviously cannot prohibit them from doing so, but the WG should assign no resources to that task, and should be careful that input from the parallel effort be constrained to being relevant to the SSH proposal or TMSM architectural extension. > > USM is one document, model, protocol, MIB module etc; I see > no benefit in > splitting up our work into multiple documents. USM is one document, one model WITHIN the SNMPv3 architecture. RFC3414 cannot stand alone. ISMS is not working on developing one security model WITHIN the SNMPv3 architecture; It appears to be the consensus of the ISMS WG to also include 1) new transport mappings (TCP-based transport PLUS "application" layers such as TLS, BEEP, and SSH), 2) message security applied by the transport mapping/application layer rather than in doing it strictly within the RFC3411 security subsystem, 3) sessions that can be used for multiple SNMP messages, 4) authorization mappings from authenticated identities to access control groupNames, and so on. These are significant changes to the architecture defined in RFC3411 and RFC3412 and other SNMPv3 documents. The TMSM document serves the purpose of identifying the architectural changes, and defining how TMSM-based models fit within the SNMPv3 architecture. That is very different than simply defining a security model within the RFC3411 security subsystem. The TMSM document also provides a place to discuss the common issues that will apply to future TMSM-based security models, such as session management. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 16:46:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7JBl-00019Z-WA; Mon, 22 Aug 2005 16:46:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7JBk-00019U-9r for isms@megatron.ietf.org; Mon, 22 Aug 2005 16:46:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20324 for ; Mon, 22 Aug 2005 16:46:33 -0400 (EDT) Message-Id: <200508222046.QAA20324@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7JmL-0000gi-RF for isms@ietf.org; Mon, 22 Aug 2005 17:24:28 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005082220455801400k8a2ne>; Mon, 22 Aug 2005 20:45:59 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 16:45:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnLMoKE6hF5zRbQ82oaZiDKhAA6QAKRDEQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Comments inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Monday, August 22, 2005 12:15 PM > To: isms@ietf.org > Subject: [Isms] draft of ISMS charter > > Dear all, > > Here is a full text version of the charter items we discussed. > Several phrases are taken from Juergen Schoenwaelder's charter > proposal. > > Still open is the issue that Tom raised today: > Shall we have two documents, a general one on TMSMs and a > specific one on SSH security model, or shall we have just > a single document defining architectural considerations and > the SSH security model? RFC3412 combined both the message processing architecture, in sections 1-5, and the SNMPv3-specific message processing, in Sections 6-7. Very few people recognize the distinction, and often mistake the way things are done for SNMPv3 messages as being an architectural requirement. I believe it makes more sense to have two documents, one for the architectural aspects, and a second with the specifics of the SSH security model. > > Further open is whether or not we should also work on a > revision of RFC 3430. Any opinion on that? Some of the issues discussed in RFC3430 will probably need to be discussed in the TMSM document. I think the WG does not need to take responsibility for updating RFC 3430. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 17:00:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7JOi-0004Ig-8m; Mon, 22 Aug 2005 17:00:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7JOe-0004Ib-8V for isms@megatron.ietf.org; Mon, 22 Aug 2005 16:59:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20947 for ; Mon, 22 Aug 2005 16:59:53 -0400 (EDT) Message-Id: <200508222059.QAA20947@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7JzG-00013Y-Fc for isms@ietf.org; Mon, 22 Aug 2005 17:37:47 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050822205945012005si1ke>; Mon, 22 Aug 2005 20:59:45 +0000 From: "David B Harrington" To: "'Nelson, David'" , , "'Juergen Quittek'" Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 16:59:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032507@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnLv9i565ycsYcR0aI2eDBXBkt6gAALP9AAArEgkA= X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I think the definiton of RADIUS attributes for management belongs in RADEXT. I think the mapping of securityname to a groupName is an architecural extensions to the SNMPv3 architecture, and belongs in ISMS, as a separate architectural extension document with its own MIB module that is independent of the specific authorization model. To put this in other words, this is another generic MIB module that describes how to add authorization to the security subsystem. I think the RADIUS attribute to SNMP groupName mapping is a specific authorization mechanism, just as AES is a specific encryption mechanism for the privacy mechanism of the SNMP security subsystem. It should be described in a separate document, just as the AES-for-SNMP mechanism is defined in a separate document (RFC 3826). Using a separate document would permit future designers to add a module for TACACS+ or authentication mechanisms. The RADIUS attribute mappng may use the subsytem-common MIB module of the architecural extensions document, or its own RADIUS-specific MIB module. This is consistent with the SNMPv3 philosophy of designing subsystems that can be upgraded/supplemented over time. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Monday, August 22, 2005 11:44 AM > To: j.schoenwaelder@iu-bremen.de; Juergen Quittek > Cc: isms@ietf.org > Subject: RE: [Isms] draft of ISMS charter > > > The other thing to look at is the question where we do the RADIUS > > specific work - whether that actually falls within ISMS (which would > > be logical since ISMS and the RADIUS stuff must work together) or > > whether this actually falls within RADEXT where the RADIUS > experts are > > hanging around which we need to review the document. I do not have a > > strong opinion here - perhaps something the IESG should give advise. > > Speaking with my RADEXT WG Co-Chair hat on, this work could > occur either > in RADEXT or ISMS, but concurrent WG review and concurrent > WGLC in both > WGs SHOULD be required. RADEXT has similar arrangements with > other WGs, > such as GEOPRIV. > > Dave Nelson > > Co-Chair > RADEXT WG > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 22 18:40:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KxU-00032F-An; Mon, 22 Aug 2005 18:40:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7KxS-000327-Iy for isms@megatron.ietf.org; Mon, 22 Aug 2005 18:39:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28267 for ; Mon, 22 Aug 2005 18:39:55 -0400 (EDT) Message-Id: <200508222239.SAA28267@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7KxS-0004Q0-8j for isms@ietf.org; Mon, 22 Aug 2005 18:39:58 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005082222394801400k8ogne>; Mon, 22 Aug 2005 22:39:48 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] draft of ISMS charter Date: Mon, 22 Aug 2005 18:39:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnLMoKE6hF5zRbQ82oaZiDKhAA6QANQxjg X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Some wordsmithing comments inline. dbh > ========================================= > Integrated Security Model for SNMP (isms) > ========================================= > > Chair(s): > N.N. > N.N. > > Security Area Director(s) > Sam Hartman > Russell Housley > > Security Area Advisor: > Sam Hartman > > Mailing Lists: > General discussion: isms@ietf.org > To (un)subscribe: isms-request@ietf.org > 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 User-based security model Message security services through the security subsystem, for which there is one currently defined model - the User-based security model > (USM). However, the USM approach has seen limited deployment so far. > One frequently reported reasons is the lack of integration of USM > key and user management into deployed authentication infrastructures. > > SSH is a widely deployed access protocol for remote devices > configuration. > Many devices support the integration of SSH user authentication with > AAA systems via protocols such as RADIUS. > > The goal of the ISMS working group is developing a new session-based The goal of the ISMS working group is developing a new > security model for SNMP that integrates with widely deployed user and > key management systems. key management systems, as a supplement to the USM security model. > > For this integration the working group will define a standard method > for mapping from AAA-provisioned authorization parameter(s) to > corresponding SNMP parameters. > > In order to leverage the authentication information already accessible > at managed devices, the new security model will use the SSH protocol. at managed devices, the new security model will use the SSH protocol for message protection, and RADIUS for AAA-provisioned user authentication and authorization. > However, the integration of an SSH transport mapping security > However, the integration of a transport mapping security > model into > the SNMPv3 architecture should be defined such that it is > open to support > potential alternative transport mappings to protocols such as > BEEP and TLS. > > The new security model must not modify any other aspects of SNMPv3 > protocol as defined in STD 62 (e.g., it must not create new > PDU types). > It should also be compliant with the security model > architectural block > of SNMPv3, as outlined in RFC 3411. [ The TMSM approach is not complaint with the security model architectural block of SNMPv3, as outlined in RFC 3411. The RFC 3411 architecture does not permit using a lower-layer protocol to provide authentication, encryption, and intergity checking. Using sessions modifies aspects of the SNMPv3 architecure; The closest we'll get is to develop architectural extensions compatible with the philosophy expoused in RFC3411 et al.] > > Work on new access control models or centralized administration of > View-based Access Control Model (VACM) rules and mappings is outside > the scope of the working group. > > The working group will cover the following work items: > > - Specify how transport mapping security models (TMSMs) fit into - Specify an architectural extension that describes how transport mapping security models (TMSMs) fit into > the SNMPv3 architecture. > - Specify a mapping from AAA-provisioned authorization parameter(s) - Specify an architectural extension that describes how to perform a mapping from AAA-provisioned user-authentication and authorization parameter(s)to securityName and other corresponding SNMP parameters. - Specify a mapping from RADIUS-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. - Specify a mapping from locally-provisioned authentication and authorization parameter(s) to securityName and other corresponding SNMP parameters. > This > item might be shared with the RADEXT WG. > - Define how to use SSH between the two SNMP engines > - Specify the SSH security model for SNMP. > > Goals an Milestones: > > Oct 2005 Initial version of a general transport mapping > security models > (TMSMs) document that specifies how TMSMs fit into > the SNMPv3 > architecture and that defines the requirements for transport > mapping security models. > Oct 2005 Initial version of a document specifying RADIUS > attributes for > TMSMs (in RADEXT WG?) > Oct 2005 Initial version of a document specifying the SSH security > model for SNMP. Dec 2006 Initial version of a document specifying the RADIUS authentication and authorization mapping model for SNMP. > Feb 2006 Initial version of an applicability statement that sets up > reasonable mandatory to implement methods. > Apr 2006 revision RFC 3430 (SNMP over TCP) to ensure it is aligned it > with the SSH transport model (or move RFC 3430 to historic) > Feb 2005 Submit TMSM document to IESG > Feb 2005 Submit RADIUS attributes for TMSMs to IESG > Jun 2005 Submit SSH TMSM to IESG > Aug 2005 Submit applicability statement to IESG > Aug 2005 Submit revision of RFC 3430 to IESG > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 03:31:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7TFb-0000Xr-CW; Tue, 23 Aug 2005 03:31:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7TFZ-0000Xm-MI for isms@megatron.ietf.org; Tue, 23 Aug 2005 03:31:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18821 for ; Tue, 23 Aug 2005 03:31:12 -0400 (EDT) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7TFb-0002bY-T4 for isms@ietf.org; Tue, 23 Aug 2005 03:31:18 -0400 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.253.24.20]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j7N7Ut9u021126 for ; Tue, 23 Aug 2005 07:30:55 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j7N7Usaq023542 for ; Tue, 23 Aug 2005 07:30:55 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005082300305410063 for ; Tue, 23 Aug 2005 00:30:54 -0700 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 00:30:48 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 00:30:48 -0700 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 03:30:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 03:26:14 -0400 Message-ID: <3DEC199BD7489643817ECA151F7C592901B1CC0B@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWmweDH0rrBsmU9TAK4xcb+WQl+MAAjiwlAABi2FcA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 23 Aug 2005 07:30:47.0120 (UTC) FILETIME=[9422FD00:01C5A7B4] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org =20 1. SecurityName is required to identify the principal in a security model-independent way. Thus mapping from model-specific to model-independent name is needed. 2. Mapping of securityName to groupName is required as VACM is group-based. Thus *some* piece of the new architecture must provide that mapping. 3. Roles are similar enough to groups, that groups should be usable for role-based management. So I prefer that both securityName and groupName became "mapped" after NewSM is done processing the request. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Monday, August 22, 2005 12:42 PM To: 'Sam Hartman'; 'Juergen Quittek' Cc: isms@ietf.org Subject: RE: [Isms] Re: securityName/groupName Hi Sam, The mapping from a model-specific identity to a securityName is model-specific by definition. There are issues associated with using securityName in a manner that loses granularity. If the remapping is done within the security model and the security model addresses those issues adequately, I see no problem. If the remapping is done inside the ACM model and the ACM addresses these issues adeqautely, I see no problem.=20 I think remapping securityName instead of groupName is fine to keep as an option, but I definitely prefer a groupName mapping to overloading securityName. dbh=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Sunday, August 21, 2005 10:32 PM > To: Juergen Quittek > Cc: isms@ietf.org > Subject: [Isms] Re: securityName/groupName >=20 > >>>>> "Juergen" =3D=3D Juergen Quittek writes: >=20 > Juergen> Woul it be acceptable for everybody if we replaced > Juergen> "securityName and groupName" with "securityName and other > Juergen> SNMP parameters"? >=20 >=20 > I'm a bit concerned about over-broad wording. Wording so broad that > redefining VACM was inc scope is clearly too broad. Also, is there > anyone who supports remapping securityname instead of the group name? > I am concerned that I may have accidentally given support to a > specific proposal when what I cared about was giving support to > solving a generic problem without supporting a specific solution. >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 03:55:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Tcu-0004g9-QE; Tue, 23 Aug 2005 03:55:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Tct-0004g4-J3 for isms@megatron.ietf.org; Tue, 23 Aug 2005 03:55:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19855 for ; Tue, 23 Aug 2005 03:55:18 -0400 (EDT) Received: from i9fd9.i.pppool.de ([85.73.159.217] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7Tcx-0003HH-6F for isms@ietf.org; Tue, 23 Aug 2005 03:55:24 -0400 Received: by boskop.local (Postfix, from userid 501) id A455F3BAB8B; Tue, 23 Aug 2005 09:54:58 +0200 (CEST) Date: Tue, 23 Aug 2005 09:54:58 +0200 From: Juergen Schoenwaelder To: "Blumenthal, Uri" Subject: Re: [Isms] Re: securityName/groupName Message-ID: <20050823075458.GA16236@boskop.local> Mail-Followup-To: "Blumenthal, Uri" , isms@ietf.org References: <3DEC199BD7489643817ECA151F7C592901B1CC0B@pysmsx401.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DEC199BD7489643817ECA151F7C592901B1CC0B@pysmsx401.amr.corp.intel.com> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > 2. Mapping of securityName to groupName is required as VACM is > group-based. Thus *some* piece of the new architecture must provide that > mapping. Just to be clear about this: The securityName to groupName mapping does exist as part of VACM today and a new security model would work just fine with it. Since people find this mapping difficult to maintain, there is obviously interest to relevant VACM mapping table entries on the fly as part of the authentication exchange with an AAA server. In fact, I believe that an SSH security model can work with local accounts and the existing local securityName to groupName mapping and should allow this option. In addition, there should be a RADIUS interface which allows to replace local account authentication with RADIUS authentication and this might provide in addition VACM mapping table entries. I do not think that the architectural changes required to accomodate transport mapping security models automatically call for architectural changes or features to support new securityName to groupName mappings. (In fact, I believe that a group is a VACM only concept that does not really exist in the SNMPv3 architecture per se.) /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 12:21:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bXC-0002as-B2; Tue, 23 Aug 2005 12:21:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bXB-0002an-Sr for isms@megatron.ietf.org; Tue, 23 Aug 2005 12:21:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13128 for ; Tue, 23 Aug 2005 12:21:55 -0400 (EDT) Message-Id: <200508231621.MAA13128@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7bXL-0001Bs-34 for isms@ietf.org; Tue, 23 Aug 2005 12:22:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005082316214401100ditpfe>; Tue, 23 Aug 2005 16:21:44 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 12:21:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050823075458.GA16236@boskop.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnuAnKW0LtjfTeSaqEEyHmMj0lRwAQgsVA X-Spam-Score: 0.1 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I agree that the SNMP architectural changes required to accomodate transport mapping security models (for message authentication and encryption, and presumably user authentication) are separate from the SNMP architectural changes or features to support new securityName to groupName mappings (for authorization). Recognize that with a AAA architecture like that used for RADIUS, that the authentication and authorization features are bound together, deliberately for security-binding reasons. Therefore it may be difficult for SNMP to separate the authentication and authorization specifications when using RADIUS or other protocols that require such bindings. I have a question. The vacmSecurityToGroupTable can be populated by multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a column that identifies how each row was configured? Should the Table have a column that identifies for which session the binding is applicable? Here's why I ask. Assume I could SET a user-to-group mapping "dbh:root" in the vacmSecurityToGroupTable, possibly using the netconf interface, which doesn't yet support access control. Then I send SNMP messages using the SSH/RADIUS security model, and it populates the table from RADIUS with user-to-group mappings of "dbh:operator" and "dbh:helpdesk". When RADIUS authenticated dbh, it explicitly did NOT send attributes mapping "dbh:root" because dbh should not have root privileges. Will dbh be allowed to perform SNMP operations as a member of the "root" group? The Access-Accept message has bindings between the authenticated entity and the (proposed) attributes it sends for mapping to groups for that authenticated session. How do we maintain the RADIUS bindings without causing bindings between the SNMP authentication and access control models? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Tuesday, August 23, 2005 3:55 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: Re: [Isms] Re: securityName/groupName > > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > > > 2. Mapping of securityName to groupName is required as VACM is > > group-based. Thus *some* piece of the new architecture must > provide that > > mapping. > > Just to be clear about this: The securityName to groupName mapping > does exist as part of VACM today and a new security model would work > just fine with it. Since people find this mapping difficult to > maintain, there is obviously interest to relevant VACM mapping table > entries on the fly as part of the authentication exchange with an AAA > server. > > In fact, I believe that an SSH security model can work with local > accounts and the existing local securityName to groupName mapping and > should allow this option. In addition, there should be a RADIUS > interface which allows to replace local account authentication with > RADIUS authentication and this might provide in addition VACM mapping > table entries. > > I do not think that the architectural changes required to accomodate > transport mapping security models automatically call for architectural > changes or features to support new securityName to groupName mappings. > (In fact, I believe that a group is a VACM only concept that does not > really exist in the SNMPv3 architecture per se.) > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 13:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7c8Q-0003dV-TP; Tue, 23 Aug 2005 13:00:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7c8Q-0003dQ-71 for isms@megatron.ietf.org; Tue, 23 Aug 2005 13:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15522 for ; Tue, 23 Aug 2005 13:00:23 -0400 (EDT) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7c8W-0002YG-Fw for isms@ietf.org; Tue, 23 Aug 2005 13:00:36 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA15777; Tue, 23 Aug 2005 10:00:13 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j7NH0Cv03629; Tue, 23 Aug 2005 12:00:12 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 10:00:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 10:00:11 -0700 Message-ID: <474EEBD229DF754FB83D256004D02108BBC8B1@XCH-NW-6V1.nw.nos.boeing.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWnuAnKW0LtjfTeSaqEEyHmMj0lRwAQgsVAAAJJdHA= From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 23 Aug 2005 17:00:12.0195 (UTC) FILETIME=[201BB730:01C5A804] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, My probably controversial viewpoint is that if RADIUS is being used for SNMP authentication and authorization by ISMS, then that means that RADIUS *replaces* SNMP authentication/authorization across the board. Specifically, SNMP shall not be able to use SET or any other provision to modify RADIUS authentication/authorization or to "tune" it for SNMP usage. Rather, any tuning must be done at RADIUS itself, otherwise it would be possible for SNMP authentication/authorization to get out of synch with RADIUS authentication/authorization, which gives "the bad guys" lots of opportunity to do damage. (Note: bad guys needn't be crackers, it could also be careless local managers.) --Eric -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Tuesday, August 23, 2005 9:22 AM To: isms@ietf.org Subject: RE: [Isms] Re: securityName/groupName Hi, I agree that the SNMP architectural changes required to accomodate transport mapping security models (for message authentication and encryption, and presumably user authentication) are separate from the SNMP architectural changes or features to support new securityName to groupName mappings (for authorization). Recognize that with a AAA architecture like that used for RADIUS, that the authentication and authorization features are bound together, deliberately for security-binding reasons. Therefore it may be difficult for SNMP to separate the authentication and authorization specifications when using RADIUS or other protocols that require such bindings. I have a question. The vacmSecurityToGroupTable can be populated by multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a column that identifies how each row was configured? Should the Table have a column that identifies for which session the binding is applicable? Here's why I ask. Assume I could SET a user-to-group mapping "dbh:root" in the vacmSecurityToGroupTable, possibly using the netconf interface, which doesn't yet support access control. Then I send SNMP messages using the SSH/RADIUS security model, and it populates the table from RADIUS with user-to-group mappings of "dbh:operator" and "dbh:helpdesk". When RADIUS authenticated dbh, it explicitly did NOT send attributes mapping "dbh:root" because dbh should not have root privileges. Will dbh be allowed to perform SNMP operations as a member of the "root" group? The Access-Accept message has bindings between the authenticated entity and the (proposed) attributes it sends for mapping to groups for that authenticated session. How do we maintain the RADIUS bindings without causing bindings between the SNMP authentication and access control models? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Tuesday, August 23, 2005 3:55 AM > To: Blumenthal, Uri > Cc: isms@ietf.org > Subject: Re: [Isms] Re: securityName/groupName >=20 > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: >=20 > > 2. Mapping of securityName to groupName is required as VACM is=20 > > group-based. Thus *some* piece of the new architecture must > provide that > > mapping. >=20 > Just to be clear about this: The securityName to groupName mapping=20 > does exist as part of VACM today and a new security model would work=20 > just fine with it. Since people find this mapping difficult to=20 > maintain, there is obviously interest to relevant VACM mapping table=20 > entries on the fly as part of the authentication exchange with an AAA > server. >=20 > In fact, I believe that an SSH security model can work with local=20 > accounts and the existing local securityName to groupName mapping and > should allow this option. In addition, there should be a RADIUS=20 > interface which allows to replace local account authentication with=20 > RADIUS authentication and this might provide in addition VACM mapping > table entries. >=20 > I do not think that the architectural changes required to accomodate=20 > transport mapping security models automatically call for architectural > changes or features to support new securityName to groupName mappings. > (In fact, I believe that a group is a VACM only concept that does not > really exist in the SNMPv3 architecture per se.) >=20 > /js >=20 > --=20 > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561,=20 > 28725 Bremen, Germany >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 13:30:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cb7-0001n9-Fb; Tue, 23 Aug 2005 13:30:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7cb5-0001mL-JJ for isms@megatron.ietf.org; Tue, 23 Aug 2005 13:30:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17047 for ; Tue, 23 Aug 2005 13:30:00 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7cbA-0003UC-KS for isms@ietf.org; Tue, 23 Aug 2005 13:30:13 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2005 10:29:50 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="656266009:sNHT30544052" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7NHTdQN003859; Tue, 23 Aug 2005 10:29:39 -0700 (PDT) Message-Id: <6.2.0.14.0.20050823102241.043ac040@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Aug 2005 10:29:41 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] Re: securityName/groupName In-Reply-To: <200508231621.MAA13128@ietf.org> References: <20050823075458.GA16236@boskop.local> <200508231621.MAA13128@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, First of all we are talking about two different security models and hence the user "dbh" within the USM is different from the user "dbh" on the RADIUS server. They are different name spaces. Now coming to authorization, I still believe that the cleanest model is to use the RADIUS attribute to refer to a VACM group. This way the RADIUS server is never assigning permissions for SNMP but primarily describing membership. The permission assignment happens via the mapping of the group to the view on the SNMP engine, this way the VACM permission model stays the same irrespective of whether you use USM or ISMS. regards, kaushik! At 09:21 AM 8/23/2005, David B Harrington wrote: >Hi, > >I agree that the SNMP architectural changes required to accomodate >transport mapping security models (for message authentication and >encryption, and presumably user authentication) are separate from the >SNMP architectural changes or features to support new securityName to >groupName mappings (for authorization). > >Recognize that with a AAA architecture like that used for RADIUS, that >the authentication and authorization features are bound together, >deliberately for security-binding reasons. Therefore it may be >difficult for SNMP to separate the authentication and authorization >specifications when using RADIUS or other protocols that require such >bindings. > >I have a question. The vacmSecurityToGroupTable can be populated by >multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a >column that identifies how each row was configured? Should the Table >have a column that identifies for which session the binding is >applicable? > >Here's why I ask. Assume I could SET a user-to-group mapping >"dbh:root" in the vacmSecurityToGroupTable, possibly using the netconf >interface, which doesn't yet support access control. Then I send SNMP >messages using the SSH/RADIUS security model, and it populates the >table from RADIUS with user-to-group mappings of "dbh:operator" and >"dbh:helpdesk". When RADIUS authenticated dbh, it explicitly did NOT >send attributes mapping "dbh:root" because dbh should not have root >privileges. Will dbh be allowed to perform SNMP operations as a member >of the "root" group? > >The Access-Accept message has bindings between the authenticated >entity and the (proposed) attributes it sends for mapping to groups >for that authenticated session. How do we maintain the RADIUS bindings >without causing bindings between the SNMP authentication and access >control models? > >David Harrington >dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, August 23, 2005 3:55 AM > > To: Blumenthal, Uri > > Cc: isms@ietf.org > > Subject: Re: [Isms] Re: securityName/groupName > > > > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > > > > > 2. Mapping of securityName to groupName is required as VACM is > > > group-based. Thus *some* piece of the new architecture must > > provide that > > > mapping. > > > > Just to be clear about this: The securityName to groupName mapping > > does exist as part of VACM today and a new security model would work > > just fine with it. Since people find this mapping difficult to > > maintain, there is obviously interest to relevant VACM mapping table > > entries on the fly as part of the authentication exchange with an >AAA > > server. > > > > In fact, I believe that an SSH security model can work with local > > accounts and the existing local securityName to groupName mapping >and > > should allow this option. In addition, there should be a RADIUS > > interface which allows to replace local account authentication with > > RADIUS authentication and this might provide in addition VACM >mapping > > table entries. > > > > I do not think that the architectural changes required to accomodate > > transport mapping security models automatically call for >architectural > > changes or features to support new securityName to groupName >mappings. > > (In fact, I believe that a group is a VACM only concept that does >not > > really exist in the SNMPv3 architecture per se.) > > > > /js > > > > -- > > Juergen Schoenwaelder International University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > > > > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 13:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7d0w-0001r9-6O; Tue, 23 Aug 2005 13:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7d0u-0001qZ-5r for isms@megatron.ietf.org; Tue, 23 Aug 2005 13:56:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18775 for ; Tue, 23 Aug 2005 13:56:43 -0400 (EDT) Message-Id: <200508231756.NAA18775@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7d12-0004Sg-2Q for isms@ietf.org; Tue, 23 Aug 2005 13:56:54 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005082317563001100djbq7e>; Tue, 23 Aug 2005 17:56:30 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 13:56:29 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <474EEBD229DF754FB83D256004D02108BBC8B1@XCH-NW-6V1.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWnuAnKW0LtjfTeSaqEEyHmMj0lRwAQgsVAAAJJdHAAAiLP0A== X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Eric, I don't think that's controversial at all. I think if we're going to provide a user-to-group mapping based on RADIUS attributes, we need to provide a binding between the authentication session and the authorization. dbh > -----Original Message----- > From: Fleischman, Eric [mailto:eric.fleischman@boeing.com] > Sent: Tuesday, August 23, 2005 1:00 PM > To: ietfdbh@comcast.net; isms@ietf.org > Subject: RE: [Isms] Re: securityName/groupName > > David, > > My probably controversial viewpoint is that if RADIUS is > being used for > SNMP authentication and authorization by ISMS, then that means that > RADIUS *replaces* SNMP authentication/authorization across the board. > Specifically, SNMP shall not be able to use SET or any other provision > to modify RADIUS authentication/authorization or to "tune" it for SNMP > usage. Rather, any tuning must be done at RADIUS itself, otherwise it > would be possible for SNMP authentication/authorization to get out of > synch with RADIUS authentication/authorization, which gives "the bad > guys" lots of opportunity to do damage. (Note: bad guys needn't be > crackers, it could also be careless local managers.) > > --Eric > > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Tuesday, August 23, 2005 9:22 AM > To: isms@ietf.org > Subject: RE: [Isms] Re: securityName/groupName > > > Hi, > > I agree that the SNMP architectural changes required to accomodate > transport mapping security models (for message authentication and > encryption, and presumably user authentication) are separate from the > SNMP architectural changes or features to support new securityName to > groupName mappings (for authorization). > > Recognize that with a AAA architecture like that used for RADIUS, that > the authentication and authorization features are bound together, > deliberately for security-binding reasons. Therefore it may > be difficult > for SNMP to separate the authentication and authorization > specifications > when using RADIUS or other protocols that require such bindings. > > I have a question. The vacmSecurityToGroupTable can be populated by > multiple means - SNMP, RADIUS, CLI, etc. Should the Table > have a column > that identifies how each row was configured? Should the Table have a > column that identifies for which session the binding is applicable? > > Here's why I ask. Assume I could SET a user-to-group mapping > "dbh:root" > in the vacmSecurityToGroupTable, possibly using the netconf interface, > which doesn't yet support access control. Then I send SNMP messages > using the SSH/RADIUS security model, and it populates the table from > RADIUS with user-to-group mappings of "dbh:operator" and > "dbh:helpdesk". > When RADIUS authenticated dbh, it explicitly did NOT send attributes > mapping "dbh:root" because dbh should not have root > privileges. Will dbh > be allowed to perform SNMP operations as a member of the "root" group? > > The Access-Accept message has bindings between the > authenticated entity > and the (proposed) attributes it sends for mapping to groups for that > authenticated session. How do we maintain the RADIUS bindings without > causing bindings between the SNMP authentication and access control > models? > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Tuesday, August 23, 2005 3:55 AM > > To: Blumenthal, Uri > > Cc: isms@ietf.org > > Subject: Re: [Isms] Re: securityName/groupName > > > > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > > > > > 2. Mapping of securityName to groupName is required as VACM is > > > group-based. Thus *some* piece of the new architecture must > > provide that > > > mapping. > > > > Just to be clear about this: The securityName to groupName mapping > > does exist as part of VACM today and a new security model > would work > > just fine with it. Since people find this mapping difficult to > > maintain, there is obviously interest to relevant VACM > mapping table > > entries on the fly as part of the authentication exchange with an > AAA > > server. > > > > In fact, I believe that an SSH security model can work with local > > accounts and the existing local securityName to groupName mapping > and > > should allow this option. In addition, there should be a RADIUS > > interface which allows to replace local account authentication with > > RADIUS authentication and this might provide in addition VACM > mapping > > table entries. > > > > I do not think that the architectural changes required to > accomodate > > transport mapping security models automatically call for > architectural > > changes or features to support new securityName to groupName > mappings. > > (In fact, I believe that a group is a VACM only concept that does > not > > really exist in the SNMPv3 architecture per se.) > > > > /js > > > > -- > > Juergen Schoenwaelder International > University Bremen > > P.O. Box 750 561, > > 28725 Bremen, Germany > > > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 14:14:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dGa-0006Ip-BE; Tue, 23 Aug 2005 14:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dGW-0006IG-Qw for isms@megatron.ietf.org; Tue, 23 Aug 2005 14:12:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19882 for ; Tue, 23 Aug 2005 14:12:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7dGf-00051D-O5 for isms@ietf.org; Tue, 23 Aug 2005 14:13:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E92E3160846; Tue, 23 Aug 2005 14:12:06 -0400 (EDT) To: "Nelson, David" References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250B@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Tue, 23 Aug 2005 14:12:06 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103250B@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Mon, 22 Aug 2005 13:54:07 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org Subject: [Isms] Re: RADIUS attribues for SNMPv3 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> What draft this is attempting to say is that there are Nelson,> two basic types of management access to hosts (managed Nelson,> entities): (a) command line interactive, via terminal Nelson,> emulation, and (b) "other". Other involves the use of an Nelson,> application layer protocol, such as SNMP or HTTP. CLI Nelson,> does not involve such a protocol. Yes, remote CLI runs Nelson,> over application protocols such as telnet and rlogin. Nelson,> But the management objects themselves are expressed in Nelson,> the non-protocol domain of ASCII command strings. Nelson,> Perhaps this is not a very useful distinction to make. I really think HTTP (at least without SOAP) looks a lot more like CLI than SNMP. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 14:58:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dyH-0000yv-DW; Tue, 23 Aug 2005 14:58:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7dyG-0000yq-1a for isms@megatron.ietf.org; Tue, 23 Aug 2005 14:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23270 for ; Tue, 23 Aug 2005 14:58:02 -0400 (EDT) Message-Id: <200508231858.OAA23270@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7dyQ-0006aR-Fl for isms@ietf.org; Tue, 23 Aug 2005 14:58:14 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005082318575301400k2bjle>; Tue, 23 Aug 2005 18:57:54 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 14:57:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <6.2.0.14.0.20050823102241.043ac040@email.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWoCEMqVk//mALXSNab7b2uBa11cQABCV3A X-Spam-Score: 0.1 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Kaushik, 1) I'm sorry my shorthand distracted you. I understand USM and RADIUS are different namespaces. But the WG is talking about populatng the vacmSecurityToGroupTable, so the USM and RADIUS elements get translated into one namespace - the vacm namespace of vacmSecurityModel/vacmSecurityname and vacmGroupName. 2) The VACM Elements of Procedure (RFC 3415 section 3) utilize the vacmSecurityToGroupTable. So unless we choose to modify VACM, it appears that populating the vacmSecurityToGroupTable behind the scenes is the simplest approach from a documentation perspective (but I personally dislike it because I think it muddies the architectural separation of the subsystems and the models, and ties the solution to the VACM-specific access control model). So the question remains, if the vacmSecurityToGroupTable can be populated by multiple means, do we need to modify the table to recognize how each row was populated? By which session? AAA-server? Server-type? Etc. When do the rows get deleted from the table? Which subsystem has that responsibility? Should each row have an "expiration" parameter? Should the document that describes how to do this RADIUS-to-VacmSecurityToGroupTable mapping define a MIB module that extends the snmpVacmMIB to contain these extra columns? 3) We can use RADIUS attributes to refer to a vacm group, but if the security subsystem gets the info, then it needs to pass it to the ACM subsystem. Populating the vacmSecurityToGroupTable behind the scenes is one approach (the "magic happens" approach). I have suggested an alternate approach that passes a list of "groupnames" in an additional parameter of the ASI. Then VACM *or any other ACM model* can use the info, if desired. Passing it as a parameter ensures that the groups are specific to the session, and maintains the binding between the authentication/authorization for the session. 4) If we move the user-to-**group** mapping outside of the ACM subsystem, then we'll force all future models to use a group membership concept for ACM. I personally don't think we should force all future models of ACM to be based on a group-membership approach to access; there were segments of the SNMPv3 WG that did not want groups, but had other approaches they wanted to be able to use. VACM happened to use groups, and the user-to-group mapping is within the snmpVacmMIB because the decision to use groups is meant to be VACM-specific. I prefer to not use "group" in our choice of words. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Tuesday, August 23, 2005 1:30 PM > To: ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: RE: [Isms] Re: securityName/groupName > > Hi David, > > First of all we are talking about two different security models > and hence the user "dbh" within the USM is different from > the user "dbh" on the RADIUS server. They are different > name spaces. > > Now coming to authorization, I still believe that the cleanest > model is to use the RADIUS attribute to refer to a VACM > group. This way the RADIUS server is never assigning > permissions for SNMP but primarily describing membership. > The permission assignment happens via the mapping of the > group to the view on the SNMP engine, this way the VACM > permission model stays the same irrespective of whether you > use USM or ISMS. > > regards, > kaushik! > > > > > > > > > At 09:21 AM 8/23/2005, David B Harrington wrote: > >Hi, > > > >I agree that the SNMP architectural changes required to accomodate > >transport mapping security models (for message authentication and > >encryption, and presumably user authentication) are separate from the > >SNMP architectural changes or features to support new securityName to > >groupName mappings (for authorization). > > > >Recognize that with a AAA architecture like that used for > RADIUS, that > >the authentication and authorization features are bound together, > >deliberately for security-binding reasons. Therefore it may be > >difficult for SNMP to separate the authentication and authorization > >specifications when using RADIUS or other protocols that require such > >bindings. > > > >I have a question. The vacmSecurityToGroupTable can be populated by > >multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a > >column that identifies how each row was configured? Should the Table > >have a column that identifies for which session the binding is > >applicable? > > > >Here's why I ask. Assume I could SET a user-to-group mapping > >"dbh:root" in the vacmSecurityToGroupTable, possibly using > the netconf > >interface, which doesn't yet support access control. Then I send SNMP > >messages using the SSH/RADIUS security model, and it populates the > >table from RADIUS with user-to-group mappings of "dbh:operator" and > >"dbh:helpdesk". When RADIUS authenticated dbh, it explicitly did NOT > >send attributes mapping "dbh:root" because dbh should not have root > >privileges. Will dbh be allowed to perform SNMP operations > as a member > >of the "root" group? > > > >The Access-Accept message has bindings between the authenticated > >entity and the (proposed) attributes it sends for mapping to groups > >for that authenticated session. How do we maintain the > RADIUS bindings > >without causing bindings between the SNMP authentication and access > >control models? > > > >David Harrington > >dbharrington@comcast.net > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > > > Schoenwaelder > > > Sent: Tuesday, August 23, 2005 3:55 AM > > > To: Blumenthal, Uri > > > Cc: isms@ietf.org > > > Subject: Re: [Isms] Re: securityName/groupName > > > > > > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > > > > > > > 2. Mapping of securityName to groupName is required as VACM is > > > > group-based. Thus *some* piece of the new architecture must > > > provide that > > > > mapping. > > > > > > Just to be clear about this: The securityName to groupName mapping > > > does exist as part of VACM today and a new security model > would work > > > just fine with it. Since people find this mapping difficult to > > > maintain, there is obviously interest to relevant VACM > mapping table > > > entries on the fly as part of the authentication exchange with an > >AAA > > > server. > > > > > > In fact, I believe that an SSH security model can work with local > > > accounts and the existing local securityName to groupName mapping > >and > > > should allow this option. In addition, there should be a RADIUS > > > interface which allows to replace local account > authentication with > > > RADIUS authentication and this might provide in addition VACM > >mapping > > > table entries. > > > > > > I do not think that the architectural changes required to > accomodate > > > transport mapping security models automatically call for > >architectural > > > changes or features to support new securityName to groupName > >mappings. > > > (In fact, I believe that a group is a VACM only concept that does > >not > > > really exist in the SNMPv3 architecture per se.) > > > > > > /js > > > > > > -- > > > Juergen Schoenwaelder International University Bremen > > > P.O. Box 750 561, > > > 28725 Bremen, Germany > > > > > > _______________________________________________ > > > Isms mailing list > > > Isms@lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > >_______________________________________________ > >Isms mailing list > >Isms@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 15:07:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7e7Q-0003BT-Uj; Tue, 23 Aug 2005 15:07:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7e7Q-0003Ah-0z for isms@megatron.ietf.org; Tue, 23 Aug 2005 15:07:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24028 for ; Tue, 23 Aug 2005 15:07:30 -0400 (EDT) Message-Id: <200508231907.PAA24028@ietf.org> Received: from sccrmhc14.comcast.net ([63.240.76.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7e7Z-0006sj-Aa for isms@ietf.org; Tue, 23 Aug 2005 15:07:42 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005082319072101400k7g7ge>; Tue, 23 Aug 2005 19:07:21 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 15:07:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcWoDPOaxz8jOodmRAmEcGVJUW/bbAACB/DQ X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Somebody privately questioned my assertion about RADIUS binding authn and authz: > Recognize that with a AAA architecture like that used for > RADIUS, that the authentication and authorization features > are bound together, deliberately for security-binding > reasons. If it is possible to authenticate the user within the security model, and wait until the access control model to get the authorizations, that could greatly alleviate my concerns about muddying the architectural waters. Is it possible to get a RADIUS authorization only, without an authentication? If so, can somebody explain the RADIUS messages and attributes involved in doing this? Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 15:16:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eGR-0005kj-BA; Tue, 23 Aug 2005 15:16:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eGQ-0005ke-Dh for isms@megatron.ietf.org; Tue, 23 Aug 2005 15:16:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25067 for ; Tue, 23 Aug 2005 15:16:48 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7eGZ-0007CS-3O for isms@ietf.org; Tue, 23 Aug 2005 15:17:01 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2005 12:16:39 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7NJGY0K007288; Tue, 23 Aug 2005 12:16:34 -0700 (PDT) Message-Id: <6.2.0.14.0.20050823121005.043afb30@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Aug 2005 12:16:36 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] Re: securityName/groupName In-Reply-To: <200508231907.PAA24028@ietf.org> References: <200508231907.PAA24028@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > >Is it possible to get a RADIUS authorization only, without an >authentication? >If so, can somebody explain the RADIUS messages and attributes >involved in doing this? I don't think so that is possible since authorization information is passed backed to the NAS in a Access_Accept (there isn't a separate RADIUS packet type for authorization requests). This one of big differences between RADIUS and TACACS+, TACACS+ does have a separate packet type for authorization and allows authorization only requests. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 15:35:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eYF-0000eh-Pj; Tue, 23 Aug 2005 15:35:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7eYD-0000ec-LE for isms@megatron.ietf.org; Tue, 23 Aug 2005 15:35:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26100 for ; Tue, 23 Aug 2005 15:35:12 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7eYM-0007gQ-Da for isms@ietf.org; Tue, 23 Aug 2005 15:35:24 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA20490 for ; Tue, 23 Aug 2005 15:37:46 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma020469; Tue, 23 Aug 05 15:36:57 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 23 Aug 2005 15:34:15 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 23 Aug 2005 15:34:15 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Aug 2005 15:34:14 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 15:34:14 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWoDPOaxz8jOodmRAmEcGVJUW/bbAACB/DQAACuRBA= From: "Nelson, David" To: , X-OriginalArrivalTime: 23 Aug 2005 19:34:14.0976 (UTC) FILETIME=[A53C2C00:01C5A819] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:78.8161 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Is it possible to get a RADIUS authorization only, without an > authentication? It is possible. It didn't use to be, but with the introduction of Dynamic RADIUS (RFC 3576) and the Service-Type of Authorize-Only it is possible. Dynamic RADIUS is primarily use for re-authorization of an existing session, presumably one that was authenticated and authorized to begin with. While this is possible, I would not recommend it as the primary means of integration of RADIUS into ISMS. Using the initial binding of authentication to authorization provided in the Access-Accept message is the most straightforward approach. BTW, the usage scenarios for Authorize-Only are have been the subject of recent debate on the RADEXT WW mailing list, and the subject of a discussion in RADEXT Issues and Fixes I-D. This kind of separation of authentication and authorization only works if RADIUS Server and Client share a well defined concept of an existing session, and the strength of the resultant "binding", based on session context is considered to be adequate for the application environment.=20 > If so, can somebody explain the RADIUS messages and attributes > involved in doing this? Presumably one would perform an initial RADIUS authentication (Access-Request, Access-Accept exchange). The session could then be re-authorized with some specific authorization information. In the Dynamic RADIUS scenario, it is typically the RADIUS Server that initiates the revised authorization. It may also be possible for the RADIUS Client to initiate an Authorize-Only authentication request, but this is currently subject to controversy in RADEXT. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 15:50:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7enH-0003oT-Rc; Tue, 23 Aug 2005 15:50:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7enG-0003oN-3g for isms@megatron.ietf.org; Tue, 23 Aug 2005 15:50:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26932 for ; Tue, 23 Aug 2005 15:50:44 -0400 (EDT) Received: from iba74.i.pppool.de ([85.73.186.116] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7enQ-00088E-Th for isms@ietf.org; Tue, 23 Aug 2005 15:50:57 -0400 Received: by boskop.local (Postfix, from userid 501) id 26C853BB017; Tue, 23 Aug 2005 21:50:26 +0200 (CEST) Date: Tue, 23 Aug 2005 21:50:25 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Re: securityName/groupName Message-ID: <20050823195025.GB931@boskop.local> Mail-Followup-To: David B Harrington , isms@ietf.org References: <20050823075458.GA16236@boskop.local> <200508231621.MAA13128@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200508231621.MAA13128@ietf.org> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Tue, Aug 23, 2005 at 12:21:43PM -0400, David B Harrington wrote: > I have a question. The vacmSecurityToGroupTable can be populated by > multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a > column that identifies how each row was configured? Should the Table > have a column that identifies for which session the binding is > applicable? Yes, I think such an augmentation would be useful/needed if we go down this path. /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 16:08:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f4g-0001Rf-Lv; Tue, 23 Aug 2005 16:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f4f-0001RG-Nu for isms@megatron.ietf.org; Tue, 23 Aug 2005 16:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01126 for ; Tue, 23 Aug 2005 16:08:43 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7f4o-0001VQ-CL for isms@ietf.org; Tue, 23 Aug 2005 16:08:56 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2005 13:08:29 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7NK8O0K029126; Tue, 23 Aug 2005 13:08:24 -0700 (PDT) Message-Id: <6.2.0.14.0.20050823130618.043b0fb0@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Aug 2005 13:08:26 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] Re: securityName/groupName In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Dave, It is possible. It didn't use to be, but with the introduction of >Dynamic RADIUS (RFC 3576) and the Service-Type of Authorize-Only it is >possible. Dynamic RADIUS is primarily use for re-authorization of an >existing session, presumably one that was authenticated and authorized >to begin with. Isn't CoA primarily addressing the network access use case wherein a session is established and re-authorization needs to happen because of some policy change. I am not sure the ISMS use case has a similar premise, wouldn't it be real stretch to extend CoA to ISMS. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 16:13:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f8r-0003EG-63; Tue, 23 Aug 2005 16:13:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7f8p-0003Dg-5f for isms@megatron.ietf.org; Tue, 23 Aug 2005 16:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02415 for ; Tue, 23 Aug 2005 16:13:01 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7f8k-0001xN-6d for isms@ietf.org; Tue, 23 Aug 2005 16:13:14 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7NKCaZC005058 for ; Tue, 23 Aug 2005 16:12:36 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 23 Aug 2005 16:12:37 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 23 Aug 2005 16:12:37 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 23 Aug 2005 16:12:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 16:12:36 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032519@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWoHpAnkT5Gjn8cRyiNvyu6i3xKxAAAAtSA From: "Nelson, David" To: "Kaushik Narayan" X-OriginalArrivalTime: 23 Aug 2005 20:12:36.0976 (UTC) FILETIME=[01557F00:01C5A81F] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.9607 P:95.9108 R:95.9108 S:74.4858 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > Isn't CoA primarily addressing the network access use case wherein > a session is established and re-authorization needs to happen because > of some policy change. I am not sure the ISMS use case has a similar > premise, wouldn't it be real stretch to extend CoA to ISMS. I very much agree. However there have been proposals floated in RADEXT to allow Authorize-Only behavior in a wider context, beyond that of CoA. That may have been what Dave Harrington heard. That extended Authorize-Only usage is currently under debate in RADEXT and is considered controversial. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 16:30:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fPR-0006Ns-Vn; Tue, 23 Aug 2005 16:30:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fPP-0006I0-KQ for isms@megatron.ietf.org; Tue, 23 Aug 2005 16:30:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08991 for ; Tue, 23 Aug 2005 16:30:09 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7fPV-0004cL-A3 for isms@ietf.org; Tue, 23 Aug 2005 16:30:19 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2005 13:29:56 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="656308826:sNHT32759758" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7NKTrQN012410; Tue, 23 Aug 2005 13:29:54 -0700 (PDT) Message-Id: <6.2.0.14.0.20050823132223.043af8a0@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 23 Aug 2005 13:29:53 -0700 To: From: Kaushik Narayan Subject: RE: [Isms] Re: securityName/groupName In-Reply-To: <40qjma$37vacl@sj-inbound-e.cisco.com> References: <6.2.0.14.0.20050823102241.043ac040@email.cisco.com> <40qjma$37vacl@sj-inbound-e.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36fb765c89ed47dab364ab702a78e8fd Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, I think updating the vacmSecurityToGroupTable behind the scenes would not be a good idea since this would actually become part of the configuration of the SNMP engine. The groupName would be passed down from the RADIUS server for every session so I would consider part of the session state and not really long term configuration. I think it would be preferable that would an additional parameter to the ASI. regards, kaushik! At 11:57 AM 8/23/2005, David B Harrington wrote: >Hi Kaushik, > >1) I'm sorry my shorthand distracted you. > >I understand USM and RADIUS are different namespaces. But the WG is >talking about populatng the vacmSecurityToGroupTable, so the USM and >RADIUS elements get translated into one namespace - the vacm namespace >of vacmSecurityModel/vacmSecurityname and vacmGroupName. > >2) The VACM Elements of Procedure (RFC 3415 section 3) utilize the >vacmSecurityToGroupTable. So unless we choose to modify VACM, it >appears that populating the vacmSecurityToGroupTable behind the scenes >is the simplest approach from a documentation perspective (but I >personally dislike it because I think it muddies the architectural >separation of the subsystems and the models, and ties the solution to >the VACM-specific access control model). > >So the question remains, if the vacmSecurityToGroupTable can be >populated by multiple means, do we need to modify the table to >recognize how each row was populated? By which session? AAA-server? >Server-type? Etc. > >When do the rows get deleted from the table? Which subsystem has that >responsibility? Should each row have an "expiration" parameter? > >Should the document that describes how to do this >RADIUS-to-VacmSecurityToGroupTable mapping define a MIB module that >extends the snmpVacmMIB to contain these extra columns? > >3) We can use RADIUS attributes to refer to a vacm group, but if the >security subsystem gets the info, then it needs to pass it to the ACM >subsystem. Populating the vacmSecurityToGroupTable behind the scenes >is one approach (the "magic happens" approach). > >I have suggested an alternate approach that passes a list of >"groupnames" in an additional parameter of the ASI. Then VACM *or any >other ACM model* can use the info, if desired. Passing it as a >parameter ensures that the groups are specific to the session, and >maintains the binding between the authentication/authorization for the >session. > >4) If we move the user-to-**group** mapping outside of the ACM >subsystem, then we'll force all future models to use a group >membership concept for ACM. I personally don't think we should force >all future models of ACM to be based on a group-membership approach to >access; there were segments of the SNMPv3 WG that did not want groups, >but had other approaches they wanted to be able to use. VACM happened >to use groups, and the user-to-group mapping is within the snmpVacmMIB >because the decision to use groups is meant to be VACM-specific. I >prefer to not use "group" in our choice of words. > >David Harrington >dbharrington@comcast.net > > > > > -----Original Message----- > > From: Kaushik Narayan [mailto:kaushik@cisco.com] > > Sent: Tuesday, August 23, 2005 1:30 PM > > To: ietfdbh@comcast.net > > Cc: isms@ietf.org > > Subject: RE: [Isms] Re: securityName/groupName > > > > Hi David, > > > > First of all we are talking about two different security models > > and hence the user "dbh" within the USM is different from > > the user "dbh" on the RADIUS server. They are different > > name spaces. > > > > Now coming to authorization, I still believe that the cleanest > > model is to use the RADIUS attribute to refer to a VACM > > group. This way the RADIUS server is never assigning > > permissions for SNMP but primarily describing membership. > > The permission assignment happens via the mapping of the > > group to the view on the SNMP engine, this way the VACM > > permission model stays the same irrespective of whether you > > use USM or ISMS. > > > > regards, > > kaushik! > > > > > > > > > > > > > > > > > > At 09:21 AM 8/23/2005, David B Harrington wrote: > > >Hi, > > > > > >I agree that the SNMP architectural changes required to accomodate > > >transport mapping security models (for message authentication and > > >encryption, and presumably user authentication) are separate from >the > > >SNMP architectural changes or features to support new securityName >to > > >groupName mappings (for authorization). > > > > > >Recognize that with a AAA architecture like that used for > > RADIUS, that > > >the authentication and authorization features are bound together, > > >deliberately for security-binding reasons. Therefore it may be > > >difficult for SNMP to separate the authentication and authorization > > >specifications when using RADIUS or other protocols that require >such > > >bindings. > > > > > >I have a question. The vacmSecurityToGroupTable can be populated by > > >multiple means - SNMP, RADIUS, CLI, etc. Should the Table have a > > >column that identifies how each row was configured? Should the >Table > > >have a column that identifies for which session the binding is > > >applicable? > > > > > >Here's why I ask. Assume I could SET a user-to-group mapping > > >"dbh:root" in the vacmSecurityToGroupTable, possibly using > > the netconf > > >interface, which doesn't yet support access control. Then I send >SNMP > > >messages using the SSH/RADIUS security model, and it populates the > > >table from RADIUS with user-to-group mappings of "dbh:operator" and > > >"dbh:helpdesk". When RADIUS authenticated dbh, it explicitly did >NOT > > >send attributes mapping "dbh:root" because dbh should not have root > > >privileges. Will dbh be allowed to perform SNMP operations > > as a member > > >of the "root" group? > > > > > >The Access-Accept message has bindings between the authenticated > > >entity and the (proposed) attributes it sends for mapping to groups > > >for that authenticated session. How do we maintain the > > RADIUS bindings > > >without causing bindings between the SNMP authentication and access > > >control models? > > > > > >David Harrington > > >dbharrington@comcast.net > > > > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > > > > Schoenwaelder > > > > Sent: Tuesday, August 23, 2005 3:55 AM > > > > To: Blumenthal, Uri > > > > Cc: isms@ietf.org > > > > Subject: Re: [Isms] Re: securityName/groupName > > > > > > > > On Tue, Aug 23, 2005 at 03:26:14AM -0400, Blumenthal, Uri wrote: > > > > > > > > > 2. Mapping of securityName to groupName is required as VACM is > > > > > group-based. Thus *some* piece of the new architecture must > > > > provide that > > > > > mapping. > > > > > > > > Just to be clear about this: The securityName to groupName >mapping > > > > does exist as part of VACM today and a new security model > > would work > > > > just fine with it. Since people find this mapping difficult to > > > > maintain, there is obviously interest to relevant VACM > > mapping table > > > > entries on the fly as part of the authentication exchange with >an > > >AAA > > > > server. > > > > > > > > In fact, I believe that an SSH security model can work with >local > > > > accounts and the existing local securityName to groupName >mapping > > >and > > > > should allow this option. In addition, there should be a RADIUS > > > > interface which allows to replace local account > > authentication with > > > > RADIUS authentication and this might provide in addition VACM > > >mapping > > > > table entries. > > > > > > > > I do not think that the architectural changes required to > > accomodate > > > > transport mapping security models automatically call for > > >architectural > > > > changes or features to support new securityName to groupName > > >mappings. > > > > (In fact, I believe that a group is a VACM only concept that >does > > >not > > > > really exist in the SNMPv3 architecture per se.) > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder International University >Bremen > > > > P.O. Box 750 561, > > > > 28725 Bremen, Germany > > > > > > > > _______________________________________________ > > > > Isms mailing list > > > > Isms@lists.ietf.org > > > > https://www1.ietf.org/mailman/listinfo/isms > > > > > > > > > > > > > > > >_______________________________________________ > > >Isms mailing list > > >Isms@lists.ietf.org > > >https://www1.ietf.org/mailman/listinfo/isms > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 17:04:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fw5-0004IP-Ev; Tue, 23 Aug 2005 17:03:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7fw4-0004IK-CW for isms@megatron.ietf.org; Tue, 23 Aug 2005 17:03:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11811 for ; Tue, 23 Aug 2005 17:03:54 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7fwE-0005xc-RP for isms@ietf.org; Tue, 23 Aug 2005 17:04:08 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7NL2UX1003778; Tue, 23 Aug 2005 16:02:31 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Aug 2005 23:02:30 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0DB4B@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: Kaushik Narayan , ietfdbh@comcast.net Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 23:02:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of Kaushik Narayan > Sent: Tuesday, August 23, 2005 22:30 > To: ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: RE: [Isms] Re: securityName/groupName > > > Hi David, > > I think updating the vacmSecurityToGroupTable behind the scenes > would not be a good idea since this would actually become part of the > configuration of the SNMP engine. The groupName would be passed > down from the RADIUS server for every session so I would consider > part of the session state and not really long term configuration. > > I think it would be preferable that would an additional parameter to > the ASI. > It has been a long time that I worked on the SNMPv3 Architecture document i.e. RFC3411. But I do recall that we tried to make the ASIs such that we would not have to change them for new access or scurity models. Now we may have failed in doing so, but if my recollection is correct, then I would hesitate to change any ASI unless we absolutely have to. Dave Harrington wrote in an earlier message: 4) let's add a parameter to the SNMPv3 ASIs for an accessFilterList, which in a standardized format contains a human-readable list of policy filters to be applied for that securityname/securityModel/securityLevel. This approach appends a new parameter, accessFilterList, to the ASIs, to be used with securityModel, securityName, and securityLevel for access control. Does this sound reasonable? Could you pls list for me the ASI (or ASIs) that you think should be modified. That way I can better think about what you are sugegsting Bert > regards, > kaushik! > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 23 20:20:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7j0Y-00026T-8l; Tue, 23 Aug 2005 20:20:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7j0W-00026O-Sg for isms@megatron.ietf.org; Tue, 23 Aug 2005 20:20:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21647 for ; Tue, 23 Aug 2005 20:20:43 -0400 (EDT) Message-Id: <200508240020.UAA21647@ietf.org> Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7j0i-0002xu-3M for isms@ietf.org; Tue, 23 Aug 2005 20:20:58 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050824002028012005tbkbe>; Wed, 24 Aug 2005 00:20:28 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Re: securityName/groupName Date: Tue, 23 Aug 2005 20:20:24 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoJiQ7AvyukS5BSQGahD7mrcQmMAADjOPA In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507E0DB4B@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Bert, > i.e. RFC3411. But I do recall that we tried to make the ASIs such that > we would not have to change them for new access or scurity models. > Now we may have failed in doing so, but if my recollection is correct, > then I would hesitate to change any ASI unless we absolutely have to. Our intention was to define the expected dataflows to support the separation between the subsystems/models such that we would not have to change them for new access or security models (or message models or applications or transports ...). It is important to not modify the ASIs in model-specific ways to accommodate specific new models. However, I believe it was considered likely that, as we gained experience, we might need to define additional dataflows between subsystems, **for use by any/all models within the subsystems, and in a way that created no dependencies between specific models within different subsystems**. We felt that separating authentication and access control (which included a user-to-group mapping) was adequate and appropriate. The ASIs were built accordingly. But, it appears there are three parts to the puzzle: authentication, authorization (the user-to-group mapping), and access control (the group-to-policies mapping). AAA binds the authentication and authorization pieces together (e.g. RADIUS returns the authorizations as a list of attributes in the Access-Accept message returned during the authentication phase), so effectively this forces us to move the user-to-group mapping functionality into the security subsystem. To add user-to-group mapping into the architecture as a function of the security subsystem instead of being a function of the access control subsystem will require changing the expected dataflows (ASIs). (or we need to accept the alternative approach that works like "the authentication triggers the sending of authorization stuff that magically appears inside the vacmSecurityToGroupTable", and "the close of a session magically causes stuff to disappear from the vacmSecurityToGroupTable." Ugh!) Note that VACM has chosen group as the thing to map to access control, and limits membership to one and only one group per user - "The combination of a securityModel and a securityName maps to at most one group." Other ACM models may use things other than group membership, or support multiple groups/domains/etc per user, so I have proposed a filterlist to name the (potentially multiple) things that would map to access control policies. Changing the ASIs: It appears to me any ASI that passes securityName from the security subsystem forward toward the access control subsystem would need to include the filterlist (grouplist). It would presumably not be necessary to modify any ASI that is outgoing. Here are the ones I think would be affected: processIncomingMsg() - the MP subsystem passes an incoming message to the security subsystem, identifying the securityModel and securityLevel; the security subsystem includes the filterlist it received from AAA in its OUT parameters, with securityName. prepareDataElements() - the MP subsystem passes the filterlist to the dispatcher. processPdu() - the dispatcher passes the list to the applications subsystem isAccessAllowed() - the application passes the list to the access control model -- I think these ASIs would be unaffected: sendPdu() returnResponsePdu() processResponsePdu() prepareOutgoingMessage() prepareResponseMessage() generateRequestMsg() David Harrington dbharrington@comcast.net > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Tuesday, August 23, 2005 5:02 PM > To: Kaushik Narayan; ietfdbh@comcast.net > Cc: isms@ietf.org > Subject: RE: [Isms] Re: securityName/groupName > > Inline > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On > > Behalf Of Kaushik Narayan > > Sent: Tuesday, August 23, 2005 22:30 > > To: ietfdbh@comcast.net > > Cc: isms@ietf.org > > Subject: RE: [Isms] Re: securityName/groupName > > > > > > Hi David, > > > > I think updating the vacmSecurityToGroupTable behind the scenes > > would not be a good idea since this would actually become > part of the > > configuration of the SNMP engine. The groupName would be passed > > down from the RADIUS server for every session so I would consider > > part of the session state and not really long term configuration. > > > > I think it would be preferable that would an additional parameter to > > the ASI. > > > > It has been a long time that I worked on the SNMPv3 > Architecture document > i.e. RFC3411. But I do recall that we tried to make the ASIs such that > we would not have to change them for new access or scurity models. > Now we may have failed in doing so, but if my recollection is correct, > then I would hesitate to change any ASI unless we absolutely have to. > > Dave Harrington wrote in an earlier message: > > 4) let's add a parameter to the SNMPv3 ASIs for an > accessFilterList, > which in a standardized format contains a human-readable list of > policy filters to be applied for that > securityname/securityModel/securityLevel. > > This approach appends a new parameter, accessFilterList, > to the ASIs, > to be used with securityModel, securityName, and securityLevel for > access control. > > Does this sound reasonable? > > Could you pls list for me the ASI (or ASIs) that you think should be > modified. That way I can better think about what you are sugegsting > > Bert > > regards, > > kaushik! > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:17:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ysO-0005wV-UZ; Wed, 24 Aug 2005 13:17:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ysI-0005pT-Ak for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:17:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06371 for ; Wed, 24 Aug 2005 13:17:15 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ysb-0000Bg-Ay for isms@ietf.org; Wed, 24 Aug 2005 13:17:40 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B58671BAC4D; Wed, 24 Aug 2005 19:17:04 +0200 (CEST) Date: Wed, 24 Aug 2005 19:17:03 +0200 From: Juergen Quittek To: ietfdbh@comcast.net, isms@ietf.org Subject: RE: [Isms] draft of ISMS charter Message-ID: <860E431CF9A6C61B94772518@[192.168.0.112]> In-Reply-To: <20050822224451.D1E5EDC66@smtp0.netlab.nec.de> References: <20050822224451.D1E5EDC66@smtp0.netlab.nec.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, Thanks for the improvements. Please find replies inline. --On 8/23/2005 12:39 AM +0200 David B Harrington wrote: > Hi, > > Some wordsmithing comments inline. > > dbh > >> ========================================= >> Integrated Security Model for SNMP (isms) >> ========================================= >> >> Chair(s): >> N.N. >> N.N. >> >> Security Area Director(s) >> Sam Hartman >> Russell Housley >> >> Security Area Advisor: >> Sam Hartman >> >> Mailing Lists: >> General discussion: isms@ietf.org >> To (un)subscribe: isms-request@ietf.org >> 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 User-based security model > > Message security services through the security subsystem, for which > there is one currently defined model - the User-based security model Fine. >> (USM). However, the USM approach has seen limited deployment so far. >> One frequently reported reasons is the lack of integration of USM >> key and user management into deployed authentication > infrastructures. >> >> SSH is a widely deployed access protocol for remote devices >> configuration. >> Many devices support the integration of SSH user authentication with >> AAA systems via protocols such as RADIUS. >> >> The goal of the ISMS working group is developing a new session-based > > The goal of the ISMS working group is developing a new Fine. >> security model for SNMP that integrates with widely deployed user > and >> key management systems. > > key management systems, as a supplement to the USM security model. Done. >> >> For this integration the working group will define a standard method >> for mapping from AAA-provisioned authorization parameter(s) to >> corresponding SNMP parameters. >> >> In order to leverage the authentication information already > accessible >> at managed devices, the new security model will use the SSH > protocol. > > at managed devices, the new security model will use the SSH protocol > for > message protection, and RADIUS for AAA-provisioned user authentication > and authorization. Done. >> However, the integration of an SSH transport mapping security > >> However, the integration of a transport mapping security Done. >> model into >> the SNMPv3 architecture should be defined such that it is >> open to support >> potential alternative transport mappings to protocols such as >> BEEP and TLS. >> >> The new security model must not modify any other aspects of SNMPv3 >> protocol as defined in STD 62 (e.g., it must not create new >> PDU types). >> It should also be compliant with the security model >> architectural block >> of SNMPv3, as outlined in RFC 3411. > > [ The TMSM approach is not complaint with the security model > architectural > block of SNMPv3, as outlined in RFC 3411. The RFC 3411 architecture > does not permit using a lower-layer protocol to provide > authentication, encryption, and intergity checking. > > Using sessions modifies aspects of the SNMPv3 architecure; The closest > we'll get is to develop architectural extensions compatible with the > philosophy expoused in RFC3411 et al.] I see. I suggest deleting the sentence you refer to. >> >> Work on new access control models or centralized administration of >> View-based Access Control Model (VACM) rules and mappings is outside >> the scope of the working group. >> >> The working group will cover the following work items: >> >> - Specify how transport mapping security models (TMSMs) fit into > > - Specify an architectural extension that describes how transport > mapping security models (TMSMs) fit into > >> the SNMPv3 architecture. >> - Specify a mapping from AAA-provisioned authorization > parameter(s) > > - Specify an architectural extension that describes how to perform a > mapping from AAA-provisioned user-authentication and authorization > parameter(s)to securityName and other corresponding SNMP parameters. > - Specify a mapping from RADIUS-provisioned authentication and > authorization parameter(s) to securityName and other corresponding > SNMP parameters. > - Specify a mapping from locally-provisioned authentication and > authorization parameter(s) to securityName and other corresponding > SNMP parameters. Added. >> This >> item might be shared with the RADEXT WG. > >> - Define how to use SSH between the two SNMP engines >> - Specify the SSH security model for SNMP. > > >> >> Goals an Milestones: >> >> Oct 2005 Initial version of a general transport mapping >> security models >> (TMSMs) document that specifies how TMSMs fit into >> the SNMPv3 >> architecture and that defines the requirements for > transport >> mapping security models. >> Oct 2005 Initial version of a document specifying RADIUS >> attributes for >> TMSMs (in RADEXT WG?) >> Oct 2005 Initial version of a document specifying the SSH security >> model for SNMP. > > Dec 2006 Initial version of a document specifying the RADIUS > authentication and authorization mapping model > for SNMP. Do you really think we need all five documents? - general TMSMs - RADIUS attributes for TMSMs (in RADEXT WG) - SSH TMSM - RADIUS mapping model for SNMP - applicability statement If we add this document here, we also need a final submission deadline further below. Thanks, Juergen >> Feb 2006 Initial version of an applicability statement that sets up >> reasonable mandatory to implement methods. >> Apr 2006 revision RFC 3430 (SNMP over TCP) to ensure it is aligned > it >> with the SSH transport model (or move RFC 3430 to > historic) >> Feb 2005 Submit TMSM document to IESG >> Feb 2005 Submit RADIUS attributes for TMSMs to IESG >> Jun 2005 Submit SSH TMSM to IESG >> Aug 2005 Submit applicability statement to IESG >> Aug 2005 Submit revision of RFC 3430 to IESG >> >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >> > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:19:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yuf-0006jN-Tp; Wed, 24 Aug 2005 13:19:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7yue-0006jI-Bu for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:19:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06454 for ; Wed, 24 Aug 2005 13:19:41 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7yv0-0000Ft-JR for isms@ietf.org; Wed, 24 Aug 2005 13:20:07 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 87B711BAC4D; Wed, 24 Aug 2005 19:19:34 +0200 (CEST) Date: Wed, 24 Aug 2005 19:19:33 +0200 From: Juergen Quittek To: ietfdbh@comcast.net, "Nelson, David" , j.schoenwaelder@iu-bremen.de Subject: RE: [Isms] draft of ISMS charter Message-ID: <32EF20EB3117B96E36E378F0@[192.168.0.112]> In-Reply-To: <20050822205946.1455E15223@smtp0.netlab.nec.de> References: <20050822205946.1455E15223@smtp0.netlab.nec.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David (Nelson), --On 8/22/2005 10:59 PM +0200 David B Harrington wrote: > I think the definiton of RADIUS attributes for management belongs in > RADEXT. I also would prefer this option. Do you think we should bring the issue to the RADEXT mailing list? Thanks, Juergen > I think the mapping of securityname to a groupName is an architecural > extensions to the SNMPv3 architecture, and belongs in ISMS, as a > separate architectural extension document with its own MIB module that > is independent of the specific authorization model. > To put this in other words, this is another generic MIB module that > describes how to add authorization to the security subsystem. > > I think the RADIUS attribute to SNMP groupName mapping is a specific > authorization mechanism, just as AES is a specific encryption > mechanism for the privacy mechanism of the SNMP security subsystem. It > should be described in a separate document, just as the AES-for-SNMP > mechanism is defined in a separate document (RFC 3826). Using a > separate document would permit future designers to add a module for > TACACS+ or authentication mechanisms. The RADIUS attribute mappng may > use the subsytem-common MIB module of the architecural extensions > document, or its own RADIUS-specific MIB module. This is consistent > with the SNMPv3 philosophy of designing subsystems that can be > upgraded/supplemented over time. > > David Harrington > dbharrington@comcast.net > >> -----Original Message----- >> From: isms-bounces@lists.ietf.org >> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David >> Sent: Monday, August 22, 2005 11:44 AM >> To: j.schoenwaelder@iu-bremen.de; Juergen Quittek >> Cc: isms@ietf.org >> Subject: RE: [Isms] draft of ISMS charter >> >> > The other thing to look at is the question where we do the RADIUS >> > specific work - whether that actually falls within ISMS (which > would >> > be logical since ISMS and the RADIUS stuff must work together) or >> > whether this actually falls within RADEXT where the RADIUS >> experts are >> > hanging around which we need to review the document. I do not have > a >> > strong opinion here - perhaps something the IESG should give > advise. >> >> Speaking with my RADEXT WG Co-Chair hat on, this work could >> occur either >> in RADEXT or ISMS, but concurrent WG review and concurrent >> WGLC in both >> WGs SHOULD be required. RADEXT has similar arrangements with >> other WGs, >> such as GEOPRIV. >> >> Dave Nelson >> >> Co-Chair >> RADEXT WG >> >> _______________________________________________ >> Isms mailing list >> Isms@lists.ietf.org >> https://www1.ietf.org/mailman/listinfo/isms >> > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:21:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ywe-0006st-Au; Wed, 24 Aug 2005 13:21:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ywd-0006rs-FK for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:21:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06499 for ; Wed, 24 Aug 2005 13:21:44 -0400 (EDT) Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7ywy-0000IN-CS for isms@ietf.org; Wed, 24 Aug 2005 13:22:09 -0400 Received: from h-64-105-136-41.snvacaid.dynamic.covad.net ([64.105.136.41] helo=oemcomputer) by pop-cowbird.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E7ywW-0001Bx-00 for isms@ietf.org; Wed, 24 Aug 2005 13:21:40 -0400 Message-ID: <002801c5a8d0$87784fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200508240020.UAA21647@ietf.org> Subject: Re: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 10:23:22 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David B Harrington" > To: > Sent: Tuesday, August 23, 2005 5:20 PM > Subject: RE: [Isms] Re: securityName/groupName ... > (or we need to accept the alternative approach that works like "the > authentication triggers the sending of authorization stuff that > magically appears inside the vacmSecurityToGroupTable", and "the close > of a session magically causes stuff to disappear from the > vacmSecurityToGroupTable." Ugh!) ... I don't see what is so magical or so "ugh" about this alternative, particularly if the table is augmented to indicate how an entry came to be, so that, for example, the close of a session with a (redundant) mapping didn't cause a non-volatile entry to be deleted. Of course, I'm being consciously narrow-minded about finishing the isms work, and am not particularly interested in enabling more. > Note that VACM has chosen group as the thing to map to access control, > and limits membership to one and only one group per user - "The > combination of a securityModel and a securityName maps to at most one > group." Other ACM models may use things other than group membership, > or support multiple groups/domains/etc per user, so I have proposed a > filterlist to name the (potentially multiple) things that would map to > access control policies. ... I think we're one the verge of some serious over-engineering here. How serious are we about defining other access control models, and how much energy as part of the isms effort should go into supporting them? The architectural effort makes sense to me only if we're actually planning to build something on that architecture. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:45:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJ9-0006Pm-5B; Wed, 24 Aug 2005 13:45:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zJ7-0006Nk-IK for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:45:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07826 for ; Wed, 24 Aug 2005 13:45:00 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zJR-00016i-Vr for isms@ietf.org; Wed, 24 Aug 2005 13:45:24 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id NAA11047 for ; Wed, 24 Aug 2005 13:47:39 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma011015; Wed, 24 Aug 05 13:47:05 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 13:44:22 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 13:44:22 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 13:44:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft of ISMS charter Date: Wed, 24 Aug 2005 13:44:21 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032522@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWo0AQ9TNrJfZ1KRwiuAol9+Nfq5wAAfqfA From: "Nelson, David" To: "Juergen Quittek" , , X-OriginalArrivalTime: 24 Aug 2005 17:44:22.0093 (UTC) FILETIME=[75FBCFD0:01C5A8D3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0659 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org, radiusext@ops.ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Juergen Quittek writes... (Cross posted to RADEXT and ISMS WG lists) > --On 8/22/2005 10:59 PM +0200 David B Harrington wrote: >=20 > > I think the definiton of RADIUS attributes for management belongs in > > RADEXT. >=20 > I also would prefer this option. > Do you think we should bring the issue to the RADEXT mailing list? Yes. As I have already indicated, we have an existing draft under consideration in RADEXT that contains this type of new attribute. It is fairly close to being ready for adoption as a WG work item. We could use this existing draft, or we could break it out as separate draft. I think the important things for ISMS to communicate to RADEXT are: (a) That ISMS has a requirement for standardization of a RADIUS attribute for the purpose of providing authorization of SNMPv3 access to the NAS (managed entity) via the ISMS mechanisms (i.e. SSH, etc.). (b) That the attribute will be used in the ISMS security method to map into one or more SNMP security parameters, such as securityName or groupName. (c) The desired milestone date for sending such an I-D to the IESG for approval, that aligns with the ISMS WG milestones. Since, I've already cross posted this message to RADEXT, we can use this as the starting point for discussions. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:46:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKI-0006nE-Uw; Wed, 24 Aug 2005 13:46:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zKG-0006mK-T7 for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:46:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07910 for ; Wed, 24 Aug 2005 13:46:12 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zKc-00018i-3W for isms@ietf.org; Wed, 24 Aug 2005 13:46:35 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id A28A8E0047; Wed, 24 Aug 2005 13:45:28 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] Re: securityName/groupName References: <200508231858.OAA23270@ietf.org> From: Sam Hartman Date: Wed, 24 Aug 2005 13:45:28 -0400 In-Reply-To: <200508231858.OAA23270@ietf.org> (David B. Harrington's message of "Tue, 23 Aug 2005 14:57:49 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> So the question remains, if the vacmSecurityToGroupTable David> can be populated by multiple means, do we need to modify David> the table to recognize how each row was populated? By which David> session? AAA-server? Server-type? Etc. If you are going to modify VACM at all then please do something that you believe is an architecturally consistent and reasonable solution. I will point out that there are scope issues as to whether it is appropriate for us to modify VACM. However there is a compelling argument that if we don't fix the group mapping problem, ISMS is not all that useful. In decreasing order of preference from my standpoint: 1) Find some clean way of not modifying VACM 2) Modify VACM to allow alternate soruces of group mapping in an architecturally reasonable manner. 3) Modify the VACM table behind the scenes possibly adding book keeping. I dislike this approach because it sounds like specifying things that should be implementation matters. This is particularly bad because it will force implementation decisions that complicate the implementation and lead to non-ideal behavior. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 13:49:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zNU-0008Bd-Bi; Wed, 24 Aug 2005 13:49:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zNS-00089v-21 for isms@megatron.ietf.org; Wed, 24 Aug 2005 13:49:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08232 for ; Wed, 24 Aug 2005 13:49:29 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zNo-0001Ix-D4 for isms@ietf.org; Wed, 24 Aug 2005 13:49:52 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 50FEAE0047; Wed, 24 Aug 2005 13:48:52 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 13:48:51 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Tue, 23 Aug 2005 15:34:14 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: >> Is it possible to get a RADIUS authorization only, without an >> authentication? Nelson,> It is possible. It didn't use to be, but with the Nelson,> introduction of Dynamic RADIUS (RFC 3576) and the Nelson,> Service-Type of Authorize-Only it is possible. Dynamic Nelson,> RADIUS is primarily use for re-authorization of an Nelson,> existing session, presumably one that was authenticated Nelson,> and authorized to begin with. Nelson,> While this is possible, I would not recommend it as the Nelson,> primary means of integration of RADIUS into ISMS. Using Nelson,> the initial binding of authentication to authorization Nelson,> provided in the Access-Accept message is the most Nelson,> straightforward approach. How would you invision authentication methods like gssapi-with-mic or publickey working if we don't separate authorization from authentication? I do agree that for the password based methods we don't want this separation. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 14:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zYS-0003IR-LZ; Wed, 24 Aug 2005 14:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zYP-0003IJ-Rk for isms@megatron.ietf.org; Wed, 24 Aug 2005 14:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08807 for ; Wed, 24 Aug 2005 14:00:49 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zYl-0001ds-6W for isms@ietf.org; Wed, 24 Aug 2005 14:01:12 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA11980 for ; Wed, 24 Aug 2005 14:03:27 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma011951; Wed, 24 Aug 05 14:02:58 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 14:00:16 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 14:00:16 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 14:00:16 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 14:00:15 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo1EpRAQcxP6vAQJS/ty+lVLW3WwAABj/w From: "Nelson, David" To: "Sam Hartman" X-OriginalArrivalTime: 24 Aug 2005 18:00:16.0171 (UTC) FILETIME=[AEA88FB0:01C5A8D5] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:92.2363 M:98.0659 P:95.9108 R:95.9108 S:73.3379 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman Writes... > How would you invision authentication methods like gssapi-with-mic or > publickey working if we don't separate authorization from > authentication? In order to answer your question directly, I'll need to do some research. To provide a meta-answer, I would note that there is a crucial difference between AAA systems and authentication (A) systems - and that's the two additional "A"s, authorization and accounting. While there is no identified need in ISMS for accounting, we have identified a need for authorization. The detailed answer to your question is based on what provisions authentication systems, such as those you've mentioned, make for authorization data. Generally speaking, authorization data needs to be cryptographically bound to the authentication result, in order to provide robust security of the access controls. In AAA systems, this requirement is met by placing the authorization data in the integrity protected authentication acceptance message. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:06:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Zv-0008F9-FE; Wed, 24 Aug 2005 15:06:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80Zt-0008ET-E9 for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:06:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12126 for ; Wed, 24 Aug 2005 15:06:24 -0400 (EDT) Received: from i885a.i.pppool.de ([85.73.136.90] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80aF-0003ga-9N for isms@ietf.org; Wed, 24 Aug 2005 15:06:48 -0400 Received: by boskop.local (Postfix, from userid 501) id 25CD03BCCAC; Wed, 24 Aug 2005 21:05:55 +0200 (CEST) Date: Wed, 24 Aug 2005 21:05:55 +0200 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Re: securityName/groupName Message-ID: <20050824190555.GB4944@boskop.local> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <200508240020.UAA21647@ietf.org> <002801c5a8d0$87784fc0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002801c5a8d0$87784fc0$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 10:23:22AM -0700, Randy Presuhn wrote: > > Note that VACM has chosen group as the thing to map to access control, > > and limits membership to one and only one group per user - "The > > combination of a securityModel and a securityName maps to at most one > > group." Other ACM models may use things other than group membership, > > or support multiple groups/domains/etc per user, so I have proposed a > > filterlist to name the (potentially multiple) things that would map to > > access control policies. > > I think we're one the verge of some serious over-engineering here. > How serious are we about defining other access control models, > and how much energy as part of the isms effort should go into > supporting them? The architectural effort makes sense to me only > if we're actually planning to build something on that architecture. Since we talk about multiple ACMs: I never really understood how this would work. How does a command responder choose the correct ACM to apply if you have more than one? My understanding is that each ACM would provide the isAccessAllowed ASI - it remains unclear to me how the decision would be taken which of these isAccessAllowed ASIs to call... /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:14:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80hp-0003BB-Lk; Wed, 24 Aug 2005 15:14:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80hn-0003B6-MC for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:14:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12863 for ; Wed, 24 Aug 2005 15:14:34 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80i5-0003uz-Vy for isms@ietf.org; Wed, 24 Aug 2005 15:14:59 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 24 Aug 2005 12:14:20 -0700 X-IronPort-AV: i="3.96,138,1122879600"; d="scan'208"; a="656552221:sNHT27382200" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7OJE8QN014971; Wed, 24 Aug 2005 12:14:13 -0700 (PDT) Message-Id: <6.2.0.14.0.20050824121244.04249928@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 24 Aug 2005 12:14:12 -0700 To: Sam Hartman From: Kaushik Narayan Subject: Re: [Isms] Re: securityName/groupName In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >How would you invision authentication methods like gssapi-with-mic or >publickey working if we don't separate authorization from >authentication? > > >I do agree that for the password based methods we don't want this separation. I think the discussion was around separation of authentication and authorization requests for RADIUS (which is largely password based). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:18:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80li-0004L3-GW; Wed, 24 Aug 2005 15:18:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80lg-0004JX-BC for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:18:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13328 for ; Wed, 24 Aug 2005 15:18:34 -0400 (EDT) Message-Id: <200508241918.PAA13328@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80m1-00042u-Hf for isms@ietf.org; Wed, 24 Aug 2005 15:18:59 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005082419182201100ljaele>; Wed, 24 Aug 2005 19:18:22 +0000 From: "David B Harrington" To: Date: Wed, 24 Aug 2005 15:18:18 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo4JUu3ydqmJmGQGm78QvfCiM4Fg== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Architectural issues X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I hate playing the heavy here, but as co-chair of the SNMPv3 WG, co-author of RFC 3411 and RFC 3412, and a member of the SNMPv2 Design Team whose job was to figure out how to salvage SNMPv2 and whose proposal was to utilize this modular architecture as the solution, I am very cognizent of what can happen if we ignore the architectural boundaries, and cognizant of the intentions of the desigtners of SNMPv3. This WG contains many members from the SNMPv3 WG, and might choose to override the architectural guidelines and applicability statements provided by the SNMPv3 WG, assuming the area directors permit this, but I believe that would be folly. Recognize that I believe 1) the SNMPv3 WG got the modularity right given the information they had at the time; 2) the SNMPv3 WG got the modularity wrong from the standpoint of integration with how other security frameworks and the IETF AAA framework would subsequently develop; 3) the SNMPv3 WG got it right when they grouped authorization and access control as part of a single subsystem (see RFC 3410) because access control can be based on different approaches, not just group membership; 4) the SNMPv3 WG got it wrong from the standpoint of integrating with the subsequent approach of IETF AAA framework, which tends to group authentication and authorization together. I believe the RFC 341x architecture needs to be modified to allow integration with existing security frameworks and existing authorization frameworks (and will probably need more adjustments to accommodate existing accounting frameworks to complete the AAA picture). We can make these adjustments in various ways. We can ignore the existing RFC 3411 architecture and its underlying philosophy and create dependencies between models in different subsystems; we can ignore the existing architecture and simply move authorization from the access control subsystem to the security subsystem and make VACM the only access control model; we can define architectural extensions that work to preserve the existing architecture as much as possible, but work around some of the limitations of that existing architecture; or we can scrap RFC 3411 and write a new architecture that better fits our updated set of requirements. I prefer the third approach, because it will, hopefully, not require us to modify any existing SNMPv3 documents, and still make it possible to integarte with existing external infrastructures. David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:21:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80oH-0005Oj-8Q; Wed, 24 Aug 2005 15:21:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80oF-0005Ob-Dl for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:21:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13606 for ; Wed, 24 Aug 2005 15:21:14 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80ob-00048w-QN for isms@ietf.org; Wed, 24 Aug 2005 15:21:39 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 24 Aug 2005 12:21:06 -0700 Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7OJKvZ2028151; Wed, 24 Aug 2005 12:20:58 -0700 (PDT) Message-Id: <6.2.0.14.0.20050824121455.091c6a10@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 24 Aug 2005 12:21:01 -0700 To: "Nelson, David" From: Kaushik Narayan Subject: RE: [Isms] Re: securityName/groupName In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.ent erasys.com> References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Sam Hartman , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > > >Generally speaking, authorization data needs to be cryptographically >bound to the authentication result, in order to provide robust security >of the access controls. In AAA systems, this requirement is met by >placing the authorization data in the integrity protected authentication >acceptance message. > I am not sure about the statement "authorization data needs to be cryptographically bound to the authentication result" applies to all cases. I agree to the applicability of this to authorization data pertaining to network access use cases where in there needs to be a binding between the user "session" and authorization data specific to the session. I also agree to this binding in administrative security use cases where a privilege level or group-name needs to be provided for an authenticated user. However, there are certain use cases where this binding is not necessary for e.g. authorization of CLI commands or a per-command basis via TACACS+ does not require a binding to an already authenticated user. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:22:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80pf-00061w-4C; Wed, 24 Aug 2005 15:22:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80pc-00061D-Rw for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:22:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13697 for ; Wed, 24 Aug 2005 15:22:39 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80pz-0004Cv-7n for isms@ietf.org; Wed, 24 Aug 2005 15:23:04 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id BA0F2E0049; Wed, 24 Aug 2005 15:22:03 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 15:22:03 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 14:00:15 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> Generally speaking, authorization data needs to be Nelson,> cryptographically bound to the authentication result, in Nelson,> order to provide robust security of the access controls. Nelson,> In AAA systems, this requirement is met by placing the Nelson,> authorization data in the integrity protected Nelson,> authentication acceptance message. I understand that authorization data needs to be integrity protected between the authorizing agent and the relying party. I don't understand why it needs to be bound to the authentication though. I'm actually aware of cases where for example using the same keying material resulting from authentication weakens authorization. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:24:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80rU-0006Qx-Fi; Wed, 24 Aug 2005 15:24:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80rS-0006Qs-Iu for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:24:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13805 for ; Wed, 24 Aug 2005 15:24:33 -0400 (EDT) Message-Id: <200508241924.PAA13805@ietf.org> Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80rp-0004F6-2W for isms@ietf.org; Wed, 24 Aug 2005 15:24:58 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050824192404012000eqn3e>; Wed, 24 Aug 2005 19:24:04 +0000 From: "David B Harrington" To: "'Nelson, David'" , "'Sam Hartman'" Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 15:23:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo1EpRAQcxP6vAQJS/ty+lVLW3WwAABj/wAAMbscA= In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032523@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > To provide a meta-answer, I would note that there is a > crucial difference between AAA systems and authentication (A) > systems - > and that's the two additional "A"s, authorization and > accounting. While > there is no identified need in ISMS for accounting, we have > identified a > need for authorization. A historical note: One of the prime reasons we adopted a human-readable securityName was to accommodate the requirement for a logging/user-accountability capability in SNMP. I think accounting frequently includes the accountability function. YMMV. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:25:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80sg-0006h6-IF; Wed, 24 Aug 2005 15:25:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E80se-0006dw-30 for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13874 for ; Wed, 24 Aug 2005 15:25:46 -0400 (EDT) Message-Id: <200508241925.PAA13874@ietf.org> Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E80t0-0004I4-GD for isms@ietf.org; Wed, 24 Aug 2005 15:26:11 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005082419253701100lfiike>; Wed, 24 Aug 2005 19:25:37 +0000 From: "David B Harrington" To: , "'Randy Presuhn'" Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 15:25:32 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo3xQzNUNWuqCHRcugQ3QXMun56QAAmlbg In-Reply-To: <20050824190555.GB4944@boskop.local> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org The ASIs certainly are not perfect, and we knew that at the time we published them. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Wednesday, August 24, 2005 3:06 PM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] Re: securityName/groupName > > On Wed, Aug 24, 2005 at 10:23:22AM -0700, Randy Presuhn wrote: > > > > Note that VACM has chosen group as the thing to map to > access control, > > > and limits membership to one and only one group per user - "The > > > combination of a securityModel and a securityName maps to > at most one > > > group." Other ACM models may use things other than group > membership, > > > or support multiple groups/domains/etc per user, so I > have proposed a > > > filterlist to name the (potentially multiple) things that > would map to > > > access control policies. > > > > I think we're one the verge of some serious over-engineering here. > > How serious are we about defining other access control models, > > and how much energy as part of the isms effort should go into > > supporting them? The architectural effort makes sense to me only > > if we're actually planning to build something on that architecture. > > Since we talk about multiple ACMs: I never really understood how this > would work. How does a command responder choose the correct ACM to > apply if you have more than one? > > My understanding is that each ACM would provide the isAccessAllowed > ASI - it remains unclear to me how the decision would be taken which > of these isAccessAllowed ASIs to call... > > /js > > -- > Juergen Schoenwaelder International University Bremen > P.O. Box 750 561, > 28725 Bremen, Germany > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:37:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E814D-0002HL-Rz; Wed, 24 Aug 2005 15:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E814B-0002HA-Ph for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14645 for ; Wed, 24 Aug 2005 15:37:42 -0400 (EDT) Message-Id: <200508241937.PAA14645@ietf.org> Received: from sccrmhc12.comcast.net ([63.240.76.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E814Y-0004hu-AE for isms@ietf.org; Wed, 24 Aug 2005 15:38:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc12) with SMTP id <20050824193733012000atd0e>; Wed, 24 Aug 2005 19:37:33 +0000 From: "David B Harrington" To: "'Sam Hartman'" , "'Nelson, David'" Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 15:37:28 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo4TA3+HtccSifQxSXhUKlMGFmVgAAJhUg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, In the SNMPv3 WG, we recognized that authentication and authorization needed to be bound together; In SNMPv2, they were explicitly bound together, but they were bound so tightly it caused us problems because we could not choose one solution that met the requirements of all industry segments, and there were slight differences in the interpretations of the semantics of the shared variables utilized by various authentication and authorization functions. We saw the benefit of being able to separate them into different subsystems/models, such that each function (AA) and each method had it own variables, except those variables necessary to provide a (cryptographic?) binding between the assertions of the authentication system and the access control functions. The passing of securityModel/securityName/securityLevel is the binding used in SNMPv3 between the authentication and authorization functions. It was also intended to serve as the binding to accounting, if and when that was addressed. There is a fundamental acceptance that the interface between subsystems is trusted. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, August 24, 2005 3:22 PM > To: Nelson, David > Cc: ietfdbh@comcast.net; isms@ietf.org > Subject: Re: [Isms] Re: securityName/groupName > > >>>>> "Nelson," == Nelson, David writes: > > Nelson,> Generally speaking, authorization data needs to be > Nelson,> cryptographically bound to the authentication result, in > Nelson,> order to provide robust security of the access controls. > Nelson,> In AAA systems, this requirement is met by placing the > Nelson,> authorization data in the integrity protected > Nelson,> authentication acceptance message. > > I understand that authorization data needs to be integrity protected > between the authorizing agent and the relying party. I don't > understand why it needs to be bound to the authentication though. > > I'm actually aware of cases where for example using the same keying > material resulting from authentication weakens authorization. > > --Sam > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:39:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E815g-0002qv-L7; Wed, 24 Aug 2005 15:39:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E815e-0002oM-QI for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:39:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14735 for ; Wed, 24 Aug 2005 15:39:13 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8161-0004js-A4 for isms@ietf.org; Wed, 24 Aug 2005 15:39:38 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA18268 for ; Wed, 24 Aug 2005 15:41:54 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma018218; Wed, 24 Aug 05 15:41:41 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 15:38:58 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 15:38:58 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 15:38:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 15:38:57 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032525@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo4Tvbp0Ked5FcSWWXfHlUcBvDTwAAGGqg From: "Nelson, David" To: "Sam Hartman" X-OriginalArrivalTime: 24 Aug 2005 19:38:58.0265 (UTC) FILETIME=[78806490:01C5A8E3] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0742 P:95.9108 R:95.9108 S:73.8529 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > I understand that authorization data needs to be integrity protected > between the authorizing agent and the relying party. I don't > understand why it needs to be bound to the authentication though. Authorization, as I use the term, is permission granted by an authoritative entity (the grantor) to a specific authenticated entity (the grantee) for access to some specific service or object, to be validated by the relying party. One example of such an authorization in the physical world is an entry visa to a foreign country. Typically the visa stamp is placed in your passport. The passport is a means of authentication (verification of identity) that the customs agent can easily validate. Placing the entry visa (an authorization for access to the country's borders) in the passport binds the visa issuance (authorization) to the identity of the passport holder (authentication). The reason it is important, in many application environments, to bind the authorization message to the authentication message is to ensure that the authorization may be used for access only by the original grantee. There are many ways in which this binding can take place, of course. In my passport example, if the visa were stamped on a blank sheet of paper that was loosely stuck in my passport, then I might be able to pass along a visa validly issue issued to me to some bad guy who would not otherwise be allowed into the country. > I'm actually aware of cases where for example using the same keying > material resulting from authentication weakens authorization. Yes, I believe that is true. I also believe that it is possible to avoid this issue, but still include the authorization data along with the authentication acceptance message. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:51:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81HC-0007Eh-NA; Wed, 24 Aug 2005 15:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81HA-0007EG-W6 for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:51:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15359 for ; Wed, 24 Aug 2005 15:51:07 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81HX-00059Q-LI for isms@ietf.org; Wed, 24 Aug 2005 15:51:32 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5F8A2E0049; Wed, 24 Aug 2005 15:50:32 -0400 (EDT) To: Kaushik Narayan Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> <6.2.0.14.0.20050824121244.04249928@email.cisco.com> From: Sam Hartman Date: Wed, 24 Aug 2005 15:50:32 -0400 In-Reply-To: <6.2.0.14.0.20050824121244.04249928@email.cisco.com> (Kaushik Narayan's message of "Wed, 24 Aug 2005 12:14:12 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Kaushik" == Kaushik Narayan writes: >> How would you invision authentication methods like >> gssapi-with-mic or publickey working if we don't separate >> authorization from authentication? >> >> >> I do agree that for the password based methods we don't want >> this separation. Kaushik> I think the discussion was around separation of Kaushik> authentication and authorization requests for RADIUS Kaushik> (which is largely password based). Yes, but I think a lot of operators who do use things like Kerberos may also use RADIUS for authorization. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:56:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Lu-0008AR-T3; Wed, 24 Aug 2005 15:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81Ls-0008AJ-Ud for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:56:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15968 for ; Wed, 24 Aug 2005 15:55:59 -0400 (EDT) Received: from i92d0.i.pppool.de ([85.73.146.208] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81MG-0005PN-GV for isms@ietf.org; Wed, 24 Aug 2005 15:56:24 -0400 Received: by boskop.local (Postfix, from userid 501) id E4D713BCD87; Wed, 24 Aug 2005 21:55:47 +0200 (CEST) Date: Wed, 24 Aug 2005 21:55:47 +0200 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Re: securityName/groupName Message-ID: <20050824195547.GA5111@boskop.local> Mail-Followup-To: David B Harrington , 'Randy Presuhn' , isms@ietf.org References: <20050824190555.GB4944@boskop.local> <20050824192540.A393939C2D@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050824192540.A393939C2D@hermes.iu-bremen.de> User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org On Wed, Aug 24, 2005 at 03:25:32PM -0400, David B Harrington wrote: > The ASIs certainly are not perfect, and we knew that at the time we > published them. Are you saying you also do not really know how multiple access control models would work? In my view, there is not a bug in the isAccessAllowed ASI or other ASIs. What is simply missing is the mechanism to choose which ACM to apply, or more concrete which data is used to select the ACM to apply. RFC 3413 section 3.2 item (5) simply says that isAccessAllowed is called and there are no provisions to determine the particular ACM to choose. The same applies to RFC 3413 section 3.3 items (2) and (3). If we conclude that multiple ACMs do not really work given RFC 3411 and friends, then we should be pragmatic and (a) drop all proposals which would basically rely on a new ACM and (b) reduce the impact of arguments which assume more ACMs will be defined in the future as this is not as easy as the introduction of new security models (even though this also turns out not to be all that easy ;-). /js -- Juergen Schoenwaelder International University Bremen P.O. Box 750 561, 28725 Bremen, Germany _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 15:57:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81NS-00008I-Sh; Wed, 24 Aug 2005 15:57:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81NQ-000088-PP for isms@megatron.ietf.org; Wed, 24 Aug 2005 15:57:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16159 for ; Wed, 24 Aug 2005 15:57:35 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81Nh-0005Tc-4t for isms@ietf.org; Wed, 24 Aug 2005 15:58:00 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7OJvQZC023575 for ; Wed, 24 Aug 2005 15:57:26 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 15:57:27 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 15:57:27 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 15:57:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 15:57:26 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032526@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo5Sv/YchFfUZwRRiwC4tLcfVzyQAAIt2Q From: "Nelson, David" To: "Sam Hartman" , "Kaushik Narayan" X-OriginalArrivalTime: 24 Aug 2005 19:57:27.0140 (UTC) FILETIME=[0D714A40:01C5A8E6] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:84.0661 M:98.9607 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > Yes, but I think a lot of operators who do use things like Kerberos > may also use RADIUS for authorization. Do you have any specific examples in mind? I'm not aware of any hybrid Kerberos/RADIUS applications where Kerberos provides authentication and RADIUS provides [unauthenticated] authorization. Or did you mean something else? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:01:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81RX-0001eo-W0; Wed, 24 Aug 2005 16:01:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81RX-0001ej-81 for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:01:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16895 for ; Wed, 24 Aug 2005 16:01:49 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81Rt-0005wS-D6 for isms@ietf.org; Wed, 24 Aug 2005 16:02:14 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7EA3BE0049; Wed, 24 Aug 2005 16:01:13 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032525@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 16:01:13 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032525@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 15:38:57 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> Sam Hartman writes... >> I understand that authorization data needs to be integrity >> protected between the authorizing agent and the relying party. >> I don't understand why it needs to be bound to the >> authentication though. Nelson,> Authorization, as I use the term, is permission granted Nelson,> by an authoritative entity (the grantor) to a specific Nelson,> authenticated entity (the grantee) for access to some Nelson,> specific service or object, to be validated by the Nelson,> relying party. Mmm. I don't like that formulation much for protocol design although I agree it is formally correct. I think of authorization as a statement from a grantor to a set of relying parties that the grantee is allowed to perform some action. Nelson,> One example of such an authorization in the physical Nelson,> world is an entry visa to a foreign country. Typically Nelson,> the visa stamp is placed in your passport. The passport Nelson,> is a means of authentication (verification of identity) Nelson,> that the customs agent can easily validate. Placing the Nelson,> entry visa (an authorization for access to the country's Nelson,> borders) in the passport binds the visa issuance Nelson,> (authorization) to the identity of the passport holder Nelson,> (authentication). Here, though, the grantor is interested in bindingthe permission to the grantee. I think this is carried in pasports because it is convenient to to do so and because it avoids naming problems in identifying the name of the grantee. I agree that authorization needs to be cryptographically bound to the grantee and to any contingent conditions (time of day, network port, etc) that are factors in the authorization decision. What I don't see and what your message does not explain is why I need to bind the authorization message to the authentication message. Nelson,> The reason it is important, in many application Nelson,> environments, to bind the authorization message to the Nelson,> authentication message is to ensure that the Nelson,> authorization may be used for access only by the original Nelson,> grantee. There are many ways in which this binding can Nelson,> take place, of course. I don't see how the desired goal (binding permission to grantee) creates a requirement on binding messages. I do agree that binding messages is sometimes a convenient implementation strategy. >> I'm actually aware of cases where for example using the same >> keying material resulting from authentication weakens >> authorization. Nelson,> Yes, I believe that is true. I also believe that it is Nelson,> possible to avoid this issue, but still include the Nelson,> authorization data along with the authentication Nelson,> acceptance message. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:04:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81UN-0003oE-M5; Wed, 24 Aug 2005 16:04:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81UM-0003o9-AH for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:04:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17228 for ; Wed, 24 Aug 2005 16:04:44 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81Uj-000655-1O for isms@ietf.org; Wed, 24 Aug 2005 16:05:10 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 42E33E0049; Wed, 24 Aug 2005 16:04:09 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032526@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 16:04:09 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032526@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 15:57:26 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> Sam Hartman writes... >> Yes, but I think a lot of operators who do use things like >> Kerberos may also use RADIUS for authorization. Nelson,> Do you have any specific examples in mind? I'm not aware Nelson,> of any hybrid Kerberos/RADIUS applications where Kerberos Nelson,> provides authentication and RADIUS provides Nelson,> [unauthenticated] authorization. I'm aware of cases where RADIUS servers will take passwords and then use Kerberos for authentication. I would consider it unacceptable to force ssh implementations in such a case to use password rather than gssapi-with-mic. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:24:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81ne-0003tP-J2; Wed, 24 Aug 2005 16:24:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81nb-0003tC-Hm for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:24:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18504 for ; Wed, 24 Aug 2005 16:24:37 -0400 (EDT) Message-Id: <200508242024.QAA18504@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81nx-0006ou-Cz for isms@ietf.org; Wed, 24 Aug 2005 16:25:03 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc11) with SMTP id <2005082420242601100lkuk4e>; Wed, 24 Aug 2005 20:24:26 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 16:24:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo0Gm0Zb+GQg8DS8mLSKkfFa/QAQAE2TRw In-Reply-To: <002801c5a8d0$87784fc0$7f1afea9@oemcomputer> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > I think we're one the verge of some serious over-engineering here. > How serious are we about defining other access control models, > and how much energy as part of the isms effort should go into > supporting them? The architectural effort makes sense to me only > if we're actually planning to build something on that architecture. > > Randy The consensus of the SNMPv3 WG was to allow multiple ACM models. Otherwise we wouldn't have bothered describing VACM as being one model within the Access Control subsystem. Any solution that makes VACM the only access control model violates the consensus of the SNMPv3 WG. But that's history. It could have been argued "How serious are we about defining other security models?", not very long ago. USM meets all the requirements we had defined as being requirements, but integration with other security infrastructures was NOT one of the requirements. In fact, it was a requirement that we have no dependencies on other security infrastructure but now we've learned the operator community doesn't like the USM approach. Have you surveyed the equipment vendors? How many actually support VACM in their products as a way to control access to the functionality of the device? Have you surveyed the operators? How many actually use VACM as a way to control access to the functionality of the devices in their networks? My experience says VACM is not widely deployed. I think once we solve the USM problem, oerators might start to use VACM, but I suspect we'll learn the operator community doesn't like the VACM approach because it doesn't leverage their existing access control infrastructure (presumably neither the one applied to the CLI or to web-based management). Let's look at the future. One issue I have had with the IETF network management community is a failure to consider the integration of its various solutions. We've had talks about "wouldn't it be nice if the various approaches used a common database, etc." but most of that falls by the wayside. Honestly, it hasn't been important that SNMP and NETCONF and CLI and web-based managament share their databases, just as it has not been important that SNMP local users and SSH local users be the same. But now security has become one of the most important things in networking, and network management is at the top of the scale for vulnerability impact. Network managemnent must be secure, and security requires balance. Network management protocols are simply interfaces to the underlying instrumentation, whether you are using CLI, SNMP, NETCONF, or web-based interfaces, or other approaches. They all access the same instrumentation, and that instrumentation needs to be secured. [and with legislation like Sarbanes-Oxley, you can believe that corporatioons are getting very serious about making sure their security doesn't have gaping holes.] If I have a house with three doors, and I put ten deadbolts on one door, five on the second door, and none on the third door, my house is only as secure as the weakest door. ISMS is addressing the need to balance security across NM interfaces by adopting an SSH solution that is also commonly used by CLI, and by NETCONF. It has similar security characteristics to the TLS used for HTTPS. The ISMS SSH solution will presumably integrate with SSH encryption and integrity checking and existing local "users" and existing RADIUS "users". So message security and user authentication are being balanced across multiple NM interfaces by our efforts here. When we move to discussing access control, we need to consider how to leverage existing access control mechanisms for other network management systems, to ensure balanced security at the data level. No other IETF NM protocol uses OIDs to organize its data. NETCONF might adopt a hierarchical XML schema, which could then use a VACM-like view-based approach to access control. [If SNMP adopts an XML encoding, we might share such a schema and the resulting access control.] Web-based management typically works with documents; maybe the W3C will develop an access control mechanism that is hierarchical in nature, and a view-based access control mechanism could be applied to web-based management. To my knowledge, most CLIs do not use a hierarchical organization of attributes, but rather use a functional approach to access control. I think it highly likely the industry will need to develop a common NM access control approach in order to provide balanced data security across NM interfaces. I think SNMP may well need to define a new or supplementary access control mechanisms to leverage existing and future access control infrastructures. The modular SNMPv3 architecture was defined so SNMP could evolve as industry requirements changed. I think it would be a mistake to think that VACM is the only access control model we will ever need in SNMP (unless of course you want to work on the assumption that SNMP is nearing death anyway, and then I question why we should bother doing any of this work.) David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:27:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81qb-00058l-Lj; Wed, 24 Aug 2005 16:27:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81qa-00058c-9t for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:27:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18754 for ; Wed, 24 Aug 2005 16:27:42 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81qw-0006wJ-8H for isms@ietf.org; Wed, 24 Aug 2005 16:28:08 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id QAA21100 for ; Wed, 24 Aug 2005 16:30:22 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma021089; Wed, 24 Aug 05 16:29:44 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 16:27:00 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 16:27:00 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 16:27:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 16:27:00 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032529@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo5qpZZSUeSrP6TD6vBfiks99mpwAAmSPw From: "Nelson, David" To: "Sam Hartman" X-OriginalArrivalTime: 24 Aug 2005 20:27:00.0703 (UTC) FILETIME=[2E9186F0:01C5A8EA] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:83.3589 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > Nelson,> Authorization, as I use the term, is permission granted > Nelson,> by an authoritative entity (the grantor) to a specific > Nelson,> authenticated entity (the grantee) for access to some > Nelson,> specific service or object, to be validated by the > Nelson,> relying party. >=20 > Mmm. I don't like that formulation much for protocol design although > I agree it is formally correct. Well... Doesn't my formal definition pretty much describe a Kerberos Ticket? > I think of authorization as a statement from a grantor to a set of > relying parties that the grantee is allowed to perform some action. ... a Kerberos Ticket-Granting-Ticket? > I agree that authorization needs to be cryptographically bound to the > grantee and to any contingent conditions (time of day, network port, > etc) that are factors in the authorization decision. OK. =20 > What I don't see and what your message does not explain is why I need > to bind the authorization message to the authentication message. Well, as you point out, you don't... or at least there are other ways to design a system with the property that the authorization data is cryptographically bound to the identity of the grantee, besides including the authorization data in an integrity protected message indicating successful completion of authentication. However, that is the way RADIUS does it. > I don't see how the desired goal (binding permission to grantee) > creates a requirement on binding messages. I do agree that > binding messages is sometimes a convenient implementation > strategy. Yes, I would agree with that statement. Note, however, that, as I indicated above, this is the way RADIUS and Diameter do it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:32:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81v0-00065e-QA; Wed, 24 Aug 2005 16:32:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81uy-00065I-Pa for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:32:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19020 for ; Wed, 24 Aug 2005 16:32:15 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81vL-00077e-Qz for isms@ietf.org; Wed, 24 Aug 2005 16:32:41 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Aug 2005 13:32:06 -0700 X-IronPort-AV: i="3.96,138,1122879600"; d="scan'208"; a="207354453:sNHT29756904" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7OKW4Z2016507; Wed, 24 Aug 2005 13:32:04 -0700 (PDT) Message-Id: <6.2.0.14.0.20050824132936.0428b4a0@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 24 Aug 2005 13:32:03 -0700 To: Sam Hartman From: Kaushik Narayan Subject: Re: [Isms] Re: securityName/groupName In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032517@MAANDMBX2.ets.enterasys.com> <6.2.0.14.0.20050824121244.04249928@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, inline, >Yes, but I think a lot of operators who do use things like Kerberos >may also use RADIUS for authorization. I have my doubts about real life examples of this, I have seen RADIUS and Kerberos used in conjunction but it has been more like a Kerberos KDC serving as a backend authentication system for a RADIUS server. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:33:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81vr-0006MW-5G; Wed, 24 Aug 2005 16:33:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E81vo-0006Lg-Ms for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19165 for ; Wed, 24 Aug 2005 16:33:06 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E81wC-0007BB-Ju for isms@ietf.org; Wed, 24 Aug 2005 16:33:32 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7OKX6ZC024839 for ; Wed, 24 Aug 2005 16:33:06 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 16:33:06 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 16:33:06 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 16:33:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 16:33:05 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252A@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo5xMfIsqlSmjpTye4y6edxxr7OwAAyKcw From: "Nelson, David" To: "Sam Hartman" X-OriginalArrivalTime: 24 Aug 2005 20:33:06.0625 (UTC) FILETIME=[08ACCB10:01C5A8EB] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0742 P:95.9108 R:95.9108 S:98.7411 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > I'm aware of cases where RADIUS servers will take passwords and then > use Kerberos for authentication. Absolutely. RADIUS servers generally use "call outs" to other authentication systems, including Kerberos, NIS, Active Directory, etc. > I would consider it unacceptable to force ssh implementations in such > a case to use password rather than gssapi-with-mic. This may place a requirement of the AAA infrastructure (RADIUS, Diameter, etc.) to support gssapi-with-mic as an authentication method within the respective protocols. Today, RADIUS supports password (PAP), CHAP, MS-CHAP, and EAP. There is a draft in RADEXT to add Digest Authentication [RFC2617] for SIP usage. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:48:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82B0-0003xp-FV; Wed, 24 Aug 2005 16:48:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82Ay-0003xk-BT for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:48:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20297 for ; Wed, 24 Aug 2005 16:48:46 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82BL-0007jN-Jf for isms@ietf.org; Wed, 24 Aug 2005 16:49:12 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 22035E0049; Wed, 24 Aug 2005 16:48:11 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252A@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 16:48:11 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252A@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 16:33:05 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> This may place a requirement of the AAA infrastructure Nelson,> (RADIUS, Diameter, etc.) to support gssapi-with-mic as an Nelson,> authentication method within the respective protocols. "you could do it that way." Honestly I think that separating authorization and authentication in this instance is a better architectural approach. It is the approach adopted by PAM and a fair number of network applications that use plugins for passwords+authorization but just handle authorization when network authentication is taking place. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 16:51:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82Da-00050N-Vc; Wed, 24 Aug 2005 16:51:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82DW-0004wy-13 for isms@megatron.ietf.org; Wed, 24 Aug 2005 16:51:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20420 for ; Wed, 24 Aug 2005 16:51:24 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82Dt-0007og-90 for isms@ietf.org; Wed, 24 Aug 2005 16:51:50 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 8857CE0049; Wed, 24 Aug 2005 16:50:48 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032529@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 16:50:48 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032529@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 16:27:00 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> Sam Hartman writes... >> Nelson,> Authorization, as I use the term, is permission >> granted Nelson,> by an authoritative entity (the grantor) to a >> specific Nelson,> authenticated entity (the grantee) for access >> to some Nelson,> specific service or object, to be validated by >> the Nelson,> relying party. >> >> Mmm. I don't like that formulation much for protocol design >> although I agree it is formally correct. Nelson,> Well... Doesn't my formal definition pretty much Nelson,> describe a Kerberos Ticket? No. a grantee cannot even read a Kerberos ticket. The tickte is a message from the KDC to the relying party. >> I think of authorization as a statement from a grantor to a set >> to the grantee and to any contingent conditions (time of day, >> network port, etc) that are factors in the authorization >> decision. Nelson,> OK. >> What I don't see and what your message does not explain is why >> I need to bind the authorization message to the authentication >> message. Nelson,> Well, as you point out, you don't... or at least there Nelson,> are other ways to design a system with the property that Nelson,> the authorization data is cryptographically bound to the Nelson,> identity of the grantee, besides including the Nelson,> authorization data in an integrity protected message Nelson,> indicating successful completion of authentication. Like including it in an integrity protected message indicating successful completion of authorization? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 17:04:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82Qb-0000RN-NN; Wed, 24 Aug 2005 17:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82QZ-0000PR-30 for isms@megatron.ietf.org; Wed, 24 Aug 2005 17:04:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20944 for ; Wed, 24 Aug 2005 17:04:53 -0400 (EDT) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82Qw-00089e-8S for isms@ietf.org; Wed, 24 Aug 2005 17:05:19 -0400 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA23557 for ; Wed, 24 Aug 2005 17:07:33 -0400 (EDT) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma023533; Wed, 24 Aug 05 17:06:52 -0400 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 24 Aug 2005 17:04:10 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 24 Aug 2005 17:04:10 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 24 Aug 2005 17:04:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Re: securityName/groupName Date: Wed, 24 Aug 2005 17:04:09 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252B@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Re: securityName/groupName Thread-Index: AcWo7ZgYN83cIcYmSqi7qYKvVFIHZAAAEv1Q From: "Nelson, David" To: "Sam Hartman" X-OriginalArrivalTime: 24 Aug 2005 21:04:09.0953 (UTC) FILETIME=[5F4E1510:01C5A8EF] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.4553 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Sam Hartman writes... > Like including it in an integrity protected message indicating > successful completion of authorization? Maybe. Does the above-described message indicate the identity of the grantee? If not, how does the relying party know which grantee this authorization applies to? Is this simply based on some session context? In the PAM models, I rather suspect that there is some implementation dependent session context that provides the desired binding of authorization to grantee identity. It may also be assumed that the username (or other formal "name") of the grantee is unique within the administrative scope of the grantor. In that case, it may be sufficient for the authorization message to simply contain that username. I have vague concerns that this scheme leaves some potential windows for an attack, but I will need to think about the trust model and the details of this kind of separation of authentication and authorization for a while longer. All of this is well and good, in theory, and as applied to some authentication frameworks, e.g. PAM. I'm not sure that it helps us integrate with other AAA systems such as RADIUS and Diameter, however. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 17:08:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82UI-0001ip-Ou; Wed, 24 Aug 2005 17:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82UH-0001iW-4r for isms@megatron.ietf.org; Wed, 24 Aug 2005 17:08:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21241 for ; Wed, 24 Aug 2005 17:08:42 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82Uf-0008J9-6Y for isms@ietf.org; Wed, 24 Aug 2005 17:09:09 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 721C9E0049; Wed, 24 Aug 2005 17:08:08 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] Re: securityName/groupName References: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252B@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Wed, 24 Aug 2005 17:08:08 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D690103252B@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 24 Aug 2005 17:04:09 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> Sam Hartman writes... >> Like including it in an integrity protected message indicating >> successful completion of authorization? Nelson,> Maybe. Does the above-described message indicate the Nelson,> identity of the grantee? Yes. Nelson,> In the PAM models, I rather suspect that there is some Nelson,> implementation dependent session context that provides Nelson,> the desired binding of authorization to grantee identity. There is not. Nelson,> It may also be assumed that the username (or other formal Nelson,> "name") of the grantee is unique within the Nelson,> administrative scope of the grantor. Or at least there is a unique identity to be authorized and authorization takes place in terms of that identity. In that case, it Nelson,> may be sufficient for the authorization message to simply Nelson,> contain that username. I have vague concerns that this Nelson,> scheme leaves some potential windows for an attack, but I Nelson,> will need to think about the trust model and the details Nelson,> of this kind of separation of authentication and Nelson,> authorization for a while longer. Sure. Also, note that I'm just trying to understand the problem, not to propose any change to RADIUS. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 17:15:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82af-0003AL-8I; Wed, 24 Aug 2005 17:15:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E82ab-00039X-At for isms@megatron.ietf.org; Wed, 24 Aug 2005 17:15:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21811 for ; Wed, 24 Aug 2005 17:15:15 -0400 (EDT) Message-Id: <200508242115.RAA21811@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E82ax-0000AA-Ng for isms@ietf.org; Wed, 24 Aug 2005 17:15:42 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc13) with SMTP id <20050824211500013005dpfje>; Wed, 24 Aug 2005 21:15:00 +0000 From: "David B Harrington" To: Date: Wed, 24 Aug 2005 17:14:53 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo07ZNoausUtTyS0+UUbIaYMt+KAAAxLsw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Multiple access control models X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I think #1 can be achieved by describing in an ISMS security model how the vacmSecurityToGroupTable gets populated by additional sources, and augmenting the VACM MIB module with source information; this info can also provide the information necessary to delete session-specific rows when the session closes. There are two major architectural problems with this approach - it is totally dependent on VACM being the only ACM model the solution will work with, and any security model that utilizes AAA to populate the table creates dependencies between specific models in the security subsystem and specific models in the AC subsystem. That is contrary to the RFC3411 architectural philosophy. I think #2 can be achieved by using an architectural extension. This "authorization" extension to the security subsystem would describe gathering a grouplist/filterlist from a (generic) authorization server, and then passing the grouplist/filterlist through the intermediate ASIs to the access control subsystem (to any/all access control models). If the grouplist is message-based, an ACM model can work directly from the grouplist. If the grouplist is session-based, then we need to identify whether the security subsystem caches the authorization info and passes it with each message, or a lookup token, and whether ACM models should use the grouplist directly or copy the grouplist into local tables, and how ACM models that copy the info into their own local tables avoid populating duplicate information for the same session, and how access control models know of the end of the life of the session, so any created entries in local tables can be deleted. I believe the best approach is to have ACM models not copy the grouplist into local tables. An example appendix could show how this architectural extension can be implemented with RADIUS as the authorization server protocol. We will need to nail down which attributes are to be used. Realize that if we develop this based on the management attributes in RADEXT, that no current RADIUS server supports them (to my knowledge). If this appendix would be large, it would probably be better as a separate document, but I think most of the issues will actually be covered by the architectural extension. A Co-existence appendix could describe how to apply this in a backwards-compatible way to VACM, as defined in RFC 3415, possibly by having the vacmSecurityToGroupTable populated from the grouplist, but then we need to address how to handle sessions and data lifetime. It would probably be better to specify that VACM should use the passed grouplist directly rather than the vacmSecurityToGroupTable. Using a co-existence document would be consistent with the SNMPv1/v2/v3 Coexistence document, where we avoided redefining SNMPv1 and SNMPv2 documents by providing a coexistence document (RFC 3584). I have concerns with #3 because either we specify how this is done, which might violate the standard vs. implementation threshold, or we don't specify it, which could lead to ambiguity and interoperability issues. If others believe #3 is a viable approach, I'd like to see a concrete (or at least partially-hardened) proposal so we can determine whether this can be implementation-independent and unambiguous. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, August 24, 2005 1:45 PM > To: ietfdbh@comcast.net > Cc: 'Kaushik Narayan'; isms@ietf.org > Subject: Re: [Isms] Re: securityName/groupName > > >>>>> "David" == David B Harrington writes: > > David> So the question remains, if the vacmSecurityToGroupTable > David> can be populated by multiple means, do we need to modify > David> the table to recognize how each row was populated? By which > David> session? AAA-server? Server-type? Etc. > > > If you are going to modify VACM at all then please do something that > you believe is an architecturally consistent and reasonable solution. > I will point out that there are scope issues as to whether it is > appropriate for us to modify VACM. However there is a compelling > argument that if we don't fix the group mapping problem, ISMS is not > all that useful. > > > In decreasing order of preference from my standpoint: > > 1) Find some clean way of not modifying VACM > > 2) Modify VACM to allow alternate soruces of group mapping in > an architecturally reasonable manner. > > 3) Modify the VACM table behind the scenes possibly adding book > keeping. I dislike this approach because it sounds like specifying > things that should be implementation matters. This is particularly > bad because it will force implementation decisions that complicate > the implementation and lead to non-ideal behavior. > > --Sam > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 17:52:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83Ae-0000wS-01; Wed, 24 Aug 2005 17:52:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83Ac-0000wN-Jy for isms@megatron.ietf.org; Wed, 24 Aug 2005 17:52:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23532 for ; Wed, 24 Aug 2005 17:52:28 -0400 (EDT) Message-Id: <200508242152.RAA23532@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83B0-0001LA-5n for isms@ietf.org; Wed, 24 Aug 2005 17:52:55 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (sccrmhc14) with SMTP id <2005082421515301400sqrdpe>; Wed, 24 Aug 2005 21:51:53 +0000 From: "David B Harrington" To: Date: Wed, 24 Aug 2005 17:51:49 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWo9gdEH0Bz4rSjTB+0is/niBB0Jw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Mandatory-to-implement X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, There has been some mention of mandatory-to-implement. I have concerns with what that means relative to SNMPv3. Is there intention in this WG to make the ISMS security model mandatory-to-implement for SNMPv3 compliance? I think that would be a mistake, especially since the data gathering done by this WG has shown that there are no existing security infrastructures that meet the requirements of all (or even most) segments of the SNMP community. SNMPv3 already has a mandatory-to-implement security model - USM - which meets a variety of requirements we haven't been discussing in the WG, and I am not convinced SSH can meet them - 1) USM provides a solution that works even if no third party authentication server is accessible (say in a partially broken network), 2) USM uses UDP, which reputedly can get through in some instances when TCP isn't viable, 3) USM supports auto-discovery of SNMP-capable devices by NMS applications, and 4) USM is defined to be viable in a resource-contrained environment (that doesn't have such things as RADIUS support). In addition, using a TCP-based transport presents opportunities that may not be backwards compatible, such as defining managed objects that can be passed via TCP, but wouldn't fit into a 484-byte UDP packet. The IETF SNMP community needs to decide whether a MIB module not compatible with the UDP transport mapping is allowed or not, and if it is, whether there is some boilerplate text that will need to included, and whether the MIB module needs to have some NMS-accessible object that identifies the need for TCP transport capabilities. I'm fairly sure there are other issues we haven't been discussing. I think it would be a mistake to think that the ISMS security model will be able to REPLACE USM as the mandatory-to-implement security model. Given that, we might want to consider a "coexistence" document or appendix that describes how to configure USM in a simple manner to permit these additional functions to be performed via the USM security model. Such an appendix might be appropriate for the Applicability Statements document, describing for which uses the SSH/RADIUS/TCP approach is applicable, and for which uses the USM/UDP approach is applicable. If we assume USM will always be available, new security models, including the ISMS security model, may not need to support all the requirements supported by USM. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Wed Aug 24 18:29:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83kf-0005V5-TS; Wed, 24 Aug 2005 18:29:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E83kf-0005V0-0a for isms@megatron.ietf.org; Wed, 24 Aug 2005 18:29:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26699 for ; Wed, 24 Aug 2005 18:29:42 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E83l4-0002YG-1B for isms@ietf.org; Wed, 24 Aug 2005 18:30:10 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 24 Aug 2005 15:29:36 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7OMTXoo017106; Wed, 24 Aug 2005 15:29:33 -0700 (PDT) Received: from [171.71.117.212] (dhcp-171-71-117-212.cisco.com [171.71.117.212]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7OMPaWJ006302; Wed, 24 Aug 2005 15:25:37 -0700 Message-ID: <430CF4CF.6030102@cisco.com> Date: Wed, 24 Aug 2005 15:29:35 -0700 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dbharrington@comcast.net Subject: Re: [Isms] Mandatory-to-implement References: <200508242152.RAA23532@ietf.org> In-Reply-To: <200508242152.RAA23532@ietf.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1062; t=1124922337; x=1125354537; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20[Isms]=20Mandatory-to-implement| From:Eliot=20Lear=20| Date:Wed,=2024=20Aug=202005=2015=3A29=3A35=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=lDPCdO7PyoxM6it57hW0DeB+oslb46tCXfkE5ke1LEBV7Gvg/eIDdkPJyOg9HmfgOspRCiH4 ojIZzPinR7RsPd9k68bC+PFxgBuUyxHnCX+e5Wn5qgZSMBzEm/f1CEreX0qSxLHvMXypUhbbv3J HFNZO6VNfrNnD4eEeOhsDDuA= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dave, David B Harrington wrote: > I think it would be a mistake to think that the ISMS security model > will be able to REPLACE USM as the mandatory-to-implement security > model. I think this has been an unspoken assumption, that if you implement ISMS there will be a "mandatory to implement" set of ISMS components. I don't think anyone envisioned NOT doing USM - or at least not at this time. > Given that, we might want to consider a "coexistence" document or > appendix that describes how to configure USM in a simple manner to > permit these additional functions to be performed via the USM security > model. Such an appendix might be appropriate for the Applicability > Statements document, describing for which uses the SSH/RADIUS/TCP > approach is applicable, and for which uses the USM/UDP approach is > applicable. If we assume USM will always be available, new security > models, including the ISMS security model, may not need to support all > the requirements supported by USM. Having both USM and ISMS coexist will be necessary, but I'm not sure it's desirable. Remember, the group's goal has been to INTEGRATE security models, reducing complexity. Also, "always" is a long time. Based on success of ISMS one could envision revisiting UDP for ISMS at some point. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 13:58:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Lzd-0004Gw-6S; Thu, 25 Aug 2005 13:58:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Lzb-0004Fe-PJ for isms@megatron.ietf.org; Thu, 25 Aug 2005 13:58:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04153 for ; Thu, 25 Aug 2005 13:58:22 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8M0A-0003cR-8A for isms@ietf.org; Thu, 25 Aug 2005 13:58:59 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id AD172E0049; Thu, 25 Aug 2005 13:58:14 -0400 (EDT) To: dbharrington@comcast.net Subject: Re: [Isms] Architectural issues References: <200508241918.PAA13328@ietf.org> From: Sam Hartman Date: Thu, 25 Aug 2005 13:58:14 -0400 In-Reply-To: <200508241918.PAA13328@ietf.org> (David B. Harrington's message of "Wed, 24 Aug 2005 15:18:18 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "David" == David B Harrington writes: David> Hi, I hate playing the heavy here, but as co-chair of the David> SNMPv3 WG, As a point of information, is SNMPV3 still open? David> We can make these adjustments in various ways. We can David> ignore the existing RFC 3411 architecture and its David> underlying philosophy and create dependencies between David> models in different subsystems; we can ignore the existing David> architecture and simply move authorization from the access David> control subsystem to the security subsystem and make VACM David> the only access control model; we can define architectural David> extensions that work to preserve the existing architecture David> as much as possible, but work around some of the David> limitations of that existing architecture; or we can scrap David> RFC 3411 and write a new architecture that better fits our David> updated set of requirements. David> I prefer the third approach, because it will, hopefully, David> not require us to modify any existing SNMPv3 documents, and David> still make it possible to integarte with existing external David> infrastructures. Do you see anyone arguing for other than the third approach? --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 14:02:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8M3h-0005O1-GC; Thu, 25 Aug 2005 14:02:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8M3g-0005NW-6C for isms@megatron.ietf.org; Thu, 25 Aug 2005 14:02:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04503 for ; Thu, 25 Aug 2005 14:02:35 -0400 (EDT) Message-Id: <200508251802.OAA04503@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8M4E-0003kT-DN for isms@ietf.org; Thu, 25 Aug 2005 14:03:11 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005082518020501400hfi47e>; Thu, 25 Aug 2005 18:02:05 +0000 From: "David B Harrington" To: "'Keith McCloghrie'" , Subject: RE: [Isms] Multiple access control models Date: Thu, 25 Aug 2005 14:02:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWpdCh1kaAhhZquT5Cs4ldl8vi1gAAImFkg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200508251254.FAA21474@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Keith, Thank you for your comments. I agree with them. I hope I wasn't too subtle. I agree that populating a vacm table from a security model is **broken** and do not believe it should be done that way. Some proposals seem to argue for that solution, and while it is one way to achieve the mapping, it has serious architectural problems to do it that way. Thank you for reinforcing this. If populating the vacm table is done as part of VACM, where does the information come from? How do you maintain the cryptographic binding between the authentication and the authorization? RFC 3411 provides the model/level/name triplet in the ASIs to provide such binding. But how does one use that from within VACM to access e.g. RADIUS attributes for authorization? dbh > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Thursday, August 25, 2005 8:55 AM > To: ietfdbh@comcast.net > Subject: Re: [Isms] Multiple access control models > > Dave, > > Forwarded message: > > From: "David B Harrington" > > To: > > Date: Wed, 24 Aug 2005 17:14:53 -0400 > > Subject: [Isms] Multiple access control models > > > > Hi, > > > > I think #1 can be achieved by describing in an ISMS > security model how > > the vacmSecurityToGroupTable gets populated by additional > sources, and > > augmenting the VACM MIB module with source information; > this info can > > also provide the information necessary to delete > session-specific rows > > when the session closes. > > > > There are two major architectural problems with this > approach - it is > > totally dependent on VACM being the only ACM model the solution will > > work with, and any security model that utilizes AAA to populate the > > table creates dependencies between specific models in the security > > subsystem and specific models in the AC subsystem. That is > contrary to > > the RFC3411 architectural philosophy. > > Note that the vacmSecurityToGroupTable is defined in RFC 3415 > (i.e., in VACM, not in *any* security model) and is not referenced in > any other SNMPv3 RFC. Thus, "describing in an ISMS security model how > the vacmSecurityToGroupTable gets populated by additional sources" is > obviously broken. > > If #1 is achieved by a solution which has problems, then by > definition, > that solution will have problems. But that's the solution's > fault, not > #1's fault. > > If instead, "how the vacmSecurityToGroupTable gets populated by > additional sources" is defined as part of VACM, then there are no such > problems. > > Also, I think the way in which multiple access control models can > co-exist is for the particular Access Model (used to resolve an > "isAccessAllowed" test) to be determined by the securityName, i.e., > the Access Control Model is determined by > (securityModel,securityName). > So, for example: > > -- today: (USM, fred) uses VACM > and (USM, joe) uses VACM > -- add in future: (TMSM, fred) uses VACM > and (TMSM, joe) uses the XXX Access Control Model > > where the XXX Access Control Model would have its own MIB table > corresponding to vacmSecurityToGroupTable, and each > (securityModel,securityName) would either have a row in > vacmSecurityToGroupTable or in XXX's corresponding table, not in both. > > keith. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 14:27:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MRc-0006I6-Me; Thu, 25 Aug 2005 14:27:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8MRb-0006HX-6N for isms@megatron.ietf.org; Thu, 25 Aug 2005 14:27:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05907 for ; Thu, 25 Aug 2005 14:27:17 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8MS8-0004Vu-Lr for isms@ietf.org; Thu, 25 Aug 2005 14:27:55 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Aug 2005 11:27:07 -0700 X-IronPort-AV: i="3.96,141,1122879600"; d="scan'208"; a="335771824:sNHT32681168" Received: from cisco.com (cypher.cisco.com [171.69.11.142]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7PIR5oo008949; Thu, 25 Aug 2005 11:27:05 -0700 (PDT) Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id LAA01502; Thu, 25 Aug 2005 11:27:05 -0700 (PDT) From: Keith McCloghrie Message-Id: <200508251827.LAA01502@cisco.com> Subject: Re: [Isms] Multiple access control models To: ietfdbh@comcast.net Date: Thu, 25 Aug 2005 11:27:05 -0700 (PDT) In-Reply-To: from "David B Harrington" at Aug 25, 2005 02:02:00 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Take the example I gave where (TMSM, joe) uses XXX-ACM, and (USM, fred) uses VACM. Then, if the authentication information contained in, say, a RADIUS response can be mapped to (TMSM, joe), then the authorization information in that same RADIUS response can be mapped to XXX-ACM. Similarly, if the authentication information contained in some other kind of response can be mapped to (USM, fred), then that response's authorization information can be mapped to VACM. Keith. PS. Please forgive me for discussing proposals which are outside the scope of this WG's charter. > Hi Keith, > > Thank you for your comments. I agree with them. > > I hope I wasn't too subtle. I agree that populating a vacm table from > a security model is **broken** and do not believe it should be done > that way. Some proposals seem to argue for that solution, and while it > is one way to achieve the mapping, it has serious architectural > problems to do it that way. > > Thank you for reinforcing this. > > If populating the vacm table is done as part of VACM, where does the > information come from? How do you maintain the cryptographic binding > between the authentication and the authorization? RFC 3411 provides > the model/level/name triplet in the ASIs to provide such binding. But > how does one use that from within VACM to access e.g. RADIUS > attributes for authorization? > > dbh > > > -----Original Message----- > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > Sent: Thursday, August 25, 2005 8:55 AM > > To: ietfdbh@comcast.net > > Subject: Re: [Isms] Multiple access control models > > > > Dave, > > > > Forwarded message: > > > From: "David B Harrington" > > > To: > > > Date: Wed, 24 Aug 2005 17:14:53 -0400 > > > Subject: [Isms] Multiple access control models > > > > > > Hi, > > > > > > I think #1 can be achieved by describing in an ISMS > > security model how > > > the vacmSecurityToGroupTable gets populated by additional > > sources, and > > > augmenting the VACM MIB module with source information; > > this info can > > > also provide the information necessary to delete > > session-specific rows > > > when the session closes. > > > > > > There are two major architectural problems with this > > approach - it is > > > totally dependent on VACM being the only ACM model the solution > will > > > work with, and any security model that utilizes AAA to populate > the > > > table creates dependencies between specific models in the security > > > subsystem and specific models in the AC subsystem. That is > > contrary to > > > the RFC3411 architectural philosophy. > > > > Note that the vacmSecurityToGroupTable is defined in RFC 3415 > > (i.e., in VACM, not in *any* security model) and is not referenced > in > > any other SNMPv3 RFC. Thus, "describing in an ISMS security model > how > > the vacmSecurityToGroupTable gets populated by additional sources" > is > > obviously broken. > > > > If #1 is achieved by a solution which has problems, then by > > definition, > > that solution will have problems. But that's the solution's > > fault, not > > #1's fault. > > > > If instead, "how the vacmSecurityToGroupTable gets populated by > > additional sources" is defined as part of VACM, then there are no > such > > problems. > > > > Also, I think the way in which multiple access control models can > > co-exist is for the particular Access Model (used to resolve an > > "isAccessAllowed" test) to be determined by the securityName, i.e., > > the Access Control Model is determined by > > (securityModel,securityName). > > So, for example: > > > > -- today: (USM, fred) uses VACM > > and (USM, joe) uses VACM > > -- add in future: (TMSM, fred) uses VACM > > and (TMSM, joe) uses the XXX Access Control Model > > > > where the XXX Access Control Model would have its own MIB table > > corresponding to vacmSecurityToGroupTable, and each > > (securityModel,securityName) would either have a row in > > vacmSecurityToGroupTable or in XXX's corresponding table, not in > both. > > > > keith. > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 15:16:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NDG-0005g1-1f; Thu, 25 Aug 2005 15:16:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8NDF-0005fr-4P for isms@megatron.ietf.org; Thu, 25 Aug 2005 15:16:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09430 for ; Thu, 25 Aug 2005 15:16:31 -0400 (EDT) Message-Id: <200508251916.PAA09430@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8NDn-00060R-16 for isms@ietf.org; Thu, 25 Aug 2005 15:17:09 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005082519162001400hfrfee>; Thu, 25 Aug 2005 19:16:20 +0000 From: "David B Harrington" To: "'Sam Hartman'" , Subject: RE: [Isms] Architectural issues Date: Thu, 25 Aug 2005 15:16:15 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWpnwint3QVGWbRTGeKncny8rCjUQAADu0Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Sam, > As a point of information, is SNMPV3 still open? The SNMPv3 WG has concluded. (Sorry, I usually include that when referencing the co-chair position.) > > Do you see anyone arguing for other than the third approach? > Yes, I see some (quasi-) proposals that seem to play very loosely with the architecture. I would like to see some of the proposals presented in a more fully-baked fashion, including discussion of how it fits into the architecture, so we can see more clearly whether they abide by the existing architecture or not. David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 16:21:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OEF-0004wW-LQ; Thu, 25 Aug 2005 16:21:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8OEE-0004wG-3V for isms@megatron.ietf.org; Thu, 25 Aug 2005 16:21:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16571 for ; Thu, 25 Aug 2005 16:21:36 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8OEn-0000zj-QK for isms@ietf.org; Thu, 25 Aug 2005 16:22:15 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 3FD3EE0049; Thu, 25 Aug 2005 16:21:29 -0400 (EDT) To: Eliot Lear Subject: Re: [Isms] Mandatory-to-implement References: <200508242152.RAA23532@ietf.org> <430CF4CF.6030102@cisco.com> From: Sam Hartman Date: Thu, 25 Aug 2005 16:21:29 -0400 In-Reply-To: <430CF4CF.6030102@cisco.com> (Eliot Lear's message of "Wed, 24 Aug 2005 15:29:35 -0700") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Eliot" == Eliot Lear writes: Eliot> Dave, Eliot> David B Harrington wrote: >> I think it would be a mistake to think that the ISMS security >> model will be able to REPLACE USM as the mandatory-to-implement >> security model. Eliot> I think this has been an unspoken assumption, that if you Eliot> implement ISMS there will be a "mandatory to implement" set Eliot> of ISMS components. I don't think anyone envisioned NOT Eliot> doing USM - or at least not at this time. I believe Eliot is correct. I would be very reluctant to take an ISMS proposal to the IESG without a set of components that is required to implement for all ISMS implementations. I don't think it is in scope for us to change mandatory to implement technologies for SNMP itself. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 17:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PEu-0003GX-VY; Thu, 25 Aug 2005 17:26:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8PEt-0003GS-1T for isms@megatron.ietf.org; Thu, 25 Aug 2005 17:26:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20887 for ; Thu, 25 Aug 2005 17:26:20 -0400 (EDT) Message-Id: <200508252126.RAA20887@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8PFS-0002pL-4F for isms@ietf.org; Thu, 25 Aug 2005 17:27:00 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005082521261001400kmbgae>; Thu, 25 Aug 2005 21:26:10 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , Subject: RE: [Isms] draft of ISMS charter Date: Thu, 25 Aug 2005 17:26:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWoz6bLBP130ZH0R1axB+tHn03OwgA5j+0w X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <860E431CF9A6C61B94772518@[192.168.0.112]> X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi Juergen, I never answered this question for you. > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > > Do you really think we need all five documents? > - general TMSMs > - RADIUS attributes for TMSMs (in RADEXT WG) > - SSH TMSM > - RADIUS mapping model for SNMP > - applicability statement > I think we have seven distinct pieces to document; some may be able to be combined into the same documents. Be aware that the SNMPv3 documents combined architecture discussion and model-specific stuff to reduce the number of documents, and it has led to misunderstandings about the separation of architectural issues from model-specific issues. YMMV. Here are the things we need to document: 1) the architectural extensions (TMSM) needed to use lower-layer protocols for message security. 2) the SSH-specific model (SSHSM) to do this, including examples using SSH local accounts and SSH-handoff-to-RADIUS for user authentication. 3) the architectural extensions needed to map AAA-provided authorization into a user-to-group mapping for use by the Access Control subsystem 4) the RADIUS attributes for management (to be done in the RADEXT WG) 5) the RADIUS-specific model for mapping attributes into a user-to-group mapping for use by the Access Control subsystem 6) the VACM-specific addendum for mapping the user-to-group information into a VACM-specific, backwards-compatible format 7) applicability statement, including discussion of the ramifications of differences in security models - TCP vs UDP, message-based vs session-based, and so on. Personally, I think the WG would be smart to solve 1, 2, and 7 first, because there are plenty of issues in solving these problems, and we have volunteers to research and edit the documents on these issues, and previous work has already started addressing these issues (TMSM, RFC 3430, Netconf, etc.) Then we could recharter to solve 3 through 6, which is a separate set of problems. I have not seen volunteers to research and edit the documents on these issues, and the attributes we plan to use haven't even been accepted as RADEXT work items yet, AFAIK. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 20:06:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Rjh-0003Wf-6O; Thu, 25 Aug 2005 20:06:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Rjf-0003Wa-II for isms@megatron.ietf.org; Thu, 25 Aug 2005 20:06:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00911 for ; Thu, 25 Aug 2005 20:06:18 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8RkF-0007uv-PE for isms@ietf.org; Thu, 25 Aug 2005 20:06:58 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 47F2311D7FF; Thu, 25 Aug 2005 17:06:02 -0700 (PDT) From: Wes Hardaker To: Juergen Quittek Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 Organization: Sparta References: <42FF549A.1070605@cisco.com> Date: Thu, 25 Aug 2005 17:05:58 -0700 In-Reply-To: (Juergen Quittek's message of "Mon, 15 Aug 2005 02:34:07 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 15 Aug 2005 02:34:07 +0200, Juergen Quittek said: Juergen> As stated at the saag session, I think that the following decisions Juergen> made the ISMS session need approval from the mailing list: Juergen> 1. The ISMS WG will work on one transport protocol only Juergen> 2. ISMS will use SSH as transport protocol ... Juergen> For 1. I am not aware of contrary opinions. I see consensus on 1. Juergen> Anyone who disagrees, please speak up soon. Sorry for the delay of about 10 days, but it's been a very busy 10 days following vacation (which is really short for "let-build-up-happen-at-work"). Trying to be brief, but I'll probably fail. 1) I do think we should pick one transport as mandatory, and that transport should be SSH since it is the most widely deployed. 2) I think it would be a mistake to only work on just that one for various reasons. 2a) I don't know for sure, as I documented in a long message sometime in July, whether eliminating UDP from ISMS proposals is a wise choice. Maybe it would be ok, but I'm not at all comfortable with saying we don't need it (and forcing a fall back to USM doesn't help me at all). 2b) SSH, though quite popular, only meets the criteria of some of the operators out there. Locking down to just one pretty much tells the rest of them to conform, which I doubt they'll do. 2c) If SSH is replaced by something in the future in operational environments and we've only put work forward in one solution then I worry that we'll be back at some point in the future starting from too little work. 3) I do think we should focus, however, but if someone was willing to write an ID and he/she had volunteers to read and review it, great. Why would I want to stop him/her? If Eliot wants to provide further work in BEEP, I think that's excellent since I don't know if it'll be used in the future. If his prediction that it's needed for network is true, I'd much rather have an ID ready to go in that case than no work done on it. 4) Personally, I don't care if netconf failed to support call home for netconf/SSH and the only option is netconf/BEEP. The best solution there is not to force ISMS to use BEEP because another WG made a bad decision. The right thing to do is see if netconf will update their document to allow for call home support. There is almost no deployment of BEEP today and a lot of SSH. If that changes, great, and I'd rather have a draft to support it. But the only reason I'm writing so much is that I do agree that SSH should be the mandatory one based on today's world. 5) If I need to commit to reading/reviewing/what-have-you on documents I'm very willing to commit to helping out with SSH, DTLS and probably TLS as well since it'd be easy to do both DTLS and TLS at once so why wouldn't ya? I wouldn't commit my personal resources to BEEP, but I don't care if others do. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 20:08:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RlQ-0004Q1-Dv; Thu, 25 Aug 2005 20:08:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RlO-0004Oi-96 for isms@megatron.ietf.org; Thu, 25 Aug 2005 20:08:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01270 for ; Thu, 25 Aug 2005 20:08:05 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8Rlz-00084u-QQ for isms@ietf.org; Thu, 25 Aug 2005 20:08:45 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 0598D11D801; Thu, 25 Aug 2005 17:08:00 -0700 (PDT) From: Wes Hardaker To: Eliot Lear Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 Organization: Sparta References: <42FF549A.1070605@cisco.com> <43009847.1060300@cisco.com> Date: Thu, 25 Aug 2005 17:07:59 -0700 In-Reply-To: <43009847.1060300@cisco.com> (Eliot Lear's message of "Mon, 15 Aug 2005 15:27:35 +0200") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Mon, 15 Aug 2005 15:27:35 +0200, Eliot Lear said: Eliot> In addition to these concerns, I also raised the concern that if this Eliot> group chooses SSH where NETCONF has chosen BEEP for p2p/call home, we Eliot> end up moving AWAY from our goal of integration of security Eliot> management. I do want netconf and SNMPv3 to converge, as I've been saying for ages. But I don't necessarily think that netconf/beep will actually prevail in the market. I think it's more likely to see netconf/ssh get fixed faster than netconf/BEEP to get widely deployed. Maybe I'm wrong. I simply don't know. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 20:18:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Rve-0004Al-FN; Thu, 25 Aug 2005 20:18:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Rvc-0004AV-S6 for isms@megatron.ietf.org; Thu, 25 Aug 2005 20:18:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02609 for ; Thu, 25 Aug 2005 20:18:39 -0400 (EDT) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8RwE-0000DE-Ip for isms@ietf.org; Thu, 25 Aug 2005 20:19:19 -0400 Received: by wes.hardakers.net (Postfix, from userid 274) id 3A85D11D802; Thu, 25 Aug 2005 17:18:35 -0700 (PDT) From: Wes Hardaker To: Juergen Quittek Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 Organization: Sparta References: <42FF549A.1070605@cisco.com> Date: Thu, 25 Aug 2005 17:18:34 -0700 In-Reply-To: (Wes Hardaker's message of "Thu, 25 Aug 2005 17:05:58 -0700") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> On Thu, 25 Aug 2005 17:05:58 -0700, Wes Hardaker said: ... Wes> 5) If I need to commit to reading/reviewing/what-have-you on documents Wes> I'm very willing to commit to helping out with SSH, DTLS and Wes> probably TLS as well since it'd be easy to do both DTLS and TLS at Wes> once so why wouldn't ya? I wouldn't commit my personal resources Wes> to BEEP, but I don't care if others do. 6) If forced, I'd rather see 1 SSH RFC and 0 others than 0 total. IE, if the choice was SSH only or WG closure, SSH would be better than nothing at all. -- Wes Hardaker Sparta, Inc. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Thu Aug 25 20:32:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8S9Q-0006cp-Ne; Thu, 25 Aug 2005 20:32:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8S9P-0006ch-CP for isms@megatron.ietf.org; Thu, 25 Aug 2005 20:32:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03265 for ; Thu, 25 Aug 2005 20:32:54 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8S9z-0000eL-2r for isms@ietf.org; Thu, 25 Aug 2005 20:33:34 -0400 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Aug 2005 17:32:43 -0700 X-IronPort-AV: i="3.96,142,1122879600"; d="scan'208"; a="207686449:sNHT30401844" Received: from kaushik-w2k03.cisco.com ([171.69.75.224]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7Q0Wd2j018707; Thu, 25 Aug 2005 17:32:40 -0700 (PDT) Message-Id: <6.2.0.14.0.20050825160446.091eaee8@email.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 25 Aug 2005 16:15:39 -0700 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: RE: [Isms] draft of ISMS charter In-Reply-To: <200508252126.RAA20887@ietf.org> References: <860E431CF9A6C61B94772518@[192.168.0.112]> <200508252126.RAA20887@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-PMX-Version: 4.7.1.128075 X-from-outside-Cisco: [171.69.75.224] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, Please find my reply inline. >Here are the things we need to document: >1) the architectural extensions (TMSM) needed to use lower-layer >protocols for message security. >2) the SSH-specific model (SSHSM) to do this, including examples using >SSH local accounts and SSH-handoff-to-RADIUS for user authentication. > >3) the architectural extensions needed to map AAA-provided >authorization into a user-to-group mapping for use by the Access >Control subsystem >4) the RADIUS attributes for management (to be done in the RADEXT WG) >5) the RADIUS-specific model for mapping attributes into a >user-to-group mapping for use by the Access Control subsystem >6) the VACM-specific addendum for mapping the user-to-group >information into a VACM-specific, backwards-compatible format > >7) applicability statement, including discussion of the ramifications >of differences in security models - TCP vs UDP, message-based vs >session-based, and so on. > >Personally, I think the WG would be smart to solve 1, 2, and 7 first, >because there are plenty of issues in solving these problems, and we >have volunteers to research and edit the documents on these issues, >and previous work has already started addressing these issues (TMSM, >RFC 3430, Netconf, etc.) > >Then we could recharter to solve 3 through 6, which is a separate set >of problems. I have not seen volunteers to research and edit the >documents on these issues, and the attributes we plan to use haven't >even been accepted as RADEXT work items yet, AFAIK. I am willing to volunteer to drive the discussions around solutions for #3 to #6 including any editorial responsibilities in documenting the solutions. There is some ground work done part of our EUSM work and also work done by Dave Nelson and Greg Weber's in RADEXT would seed this. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 26 10:27:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fB5-0007XE-Ds; Fri, 26 Aug 2005 10:27:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fB3-0007Uf-Uz for isms@megatron.ietf.org; Fri, 26 Aug 2005 10:27:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23581 for ; Fri, 26 Aug 2005 10:27:28 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fBm-00004x-43 for isms@ietf.org; Fri, 26 Aug 2005 10:28:16 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 26 Aug 2005 07:27:19 -0700 X-IronPort-AV: i="3.96,144,1122879600"; d="scan'208"; a="336061326:sNHT30744552" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j7QERFoo005144; Fri, 26 Aug 2005 07:27:16 -0700 (PDT) Received: from [171.71.117.212] (dhcp-171-71-117-212.cisco.com [171.71.117.212]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7QENBBp022434; Fri, 26 Aug 2005 07:23:12 -0700 Message-ID: <430F26C6.6090206@cisco.com> Date: Fri, 26 Aug 2005 07:27:18 -0700 From: Eliot Lear User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker Subject: Re: Call for consensus, was: [Isms] request for confirmation (or lack thereof) of the decisions made at IETF63 References: <42FF549A.1070605@cisco.com> In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=281; t=1125066192; x=1125498392; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20Call=20for=20consensus, =20was=3A=20[Isms]=20request=20for=20conf irmation=20(or=0A=20lack=20thereof)=20of=20the=20decisions=20made=20at=20IE TF63| From:Eliot=20Lear=20| Date:Fri,=2026=20Aug=202005=2007=3A27=3A18=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=MAh+A8aDBTTnwxex+T7cUaduEIbuubmLSBbat8+37ig38ppghZ0VJVPwn01k4oIqxfKDsRao Hl7sX1g7PS9IC2H3Asv5g6nY9vSabBqC3bucpc6jSbrcRiBRqS2VR7dVvZMz6FJS0l5PUq5QKEC 3R8gT8tul1pErjPzoCMF2ohA= Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Wes, Thanks for your message. I'm a bit beyond the protocol discussion at this point. BEEP is just bits, same as SSH. I suspect we could redo lots of stuff in SSH that BEEP has done, and it wouldn't kill me. To be very brief, my greater concern is an implementation of the CH functionality, which has for the moment been ruled out of scope. Eliot _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 26 12:16:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gsq-0005eJ-UX; Fri, 26 Aug 2005 12:16:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gso-0005e9-O6 for isms@megatron.ietf.org; Fri, 26 Aug 2005 12:16:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29701 for ; Fri, 26 Aug 2005 12:16:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8gtZ-0003xV-QP for isms@ietf.org; Fri, 26 Aug 2005 12:17:34 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 5B7D5E0049; Fri, 26 Aug 2005 12:16:40 -0400 (EDT) To: ietfdbh@comcast.net Subject: Re: [Isms] draft of ISMS charter References: <200508252126.RAA20887@ietf.org> From: Sam Hartman Date: Fri, 26 Aug 2005 12:16:40 -0400 In-Reply-To: <200508252126.RAA20887@ietf.org> (David B. Harrington's message of "Thu, 25 Aug 2005 17:26:04 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David, are you objecting to the proposed charter or just saying you would do things differently? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Fri Aug 26 14:48:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jFo-0007BK-GT; Fri, 26 Aug 2005 14:48:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8jFn-0007BF-1e for isms@megatron.ietf.org; Fri, 26 Aug 2005 14:48:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06315 for ; Fri, 26 Aug 2005 14:48:37 -0400 (EDT) Message-Id: <200508261848.OAA06315@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8jGY-0008Tp-C4 for isms@ietf.org; Fri, 26 Aug 2005 14:49:27 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005082618482501400kpjhae>; Fri, 26 Aug 2005 18:48:25 +0000 From: "David B Harrington" To: "'Sam Hartman'" Subject: RE: [Isms] draft of ISMS charter Date: Fri, 26 Aug 2005 14:48:17 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWqWZDqTBgvoZbOSjSaJFuT5eGBkAAEy0ug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, I do not object to the proposed charter. I am suggesting an alternative arrangement of the goals/deadlines that keeps our promised deliverables in line with our committed resources, to maximize our ability to meet the charter deadlines. So far, our chairs have not aggressively recruited volunteers and then held their feet to the fire to ensure deadlines were met. I am concerned that committing to deliverables without having volunteers willing to commit and follow-through to produce those deliverables increases our chance of failure. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Friday, August 26, 2005 12:17 PM > To: ietfdbh@comcast.net > Cc: 'Juergen Quittek'; isms@ietf.org > Subject: Re: [Isms] draft of ISMS charter > > David, are you objecting to the proposed charter or just saying you > would do things differently? > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 27 10:21:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yf-0000nq-IY; Sat, 27 Aug 2005 10:21:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Ye-0000mH-Ek for isms@megatron.ietf.org; Sat, 27 Aug 2005 10:21:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15715 for ; Sat, 27 Aug 2005 10:21:18 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E91Zb-0001bw-2y for isms@ietf.org; Sat, 27 Aug 2005 10:22:19 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7REL29l007738; Sat, 27 Aug 2005 09:21:05 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Aug 2005 16:21:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0E38C@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, isms@ietf.org Subject: RE: [Isms] Multiple access control models Date: Sat, 27 Aug 2005 16:21:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of David B Harrington > Sent: Wednesday, August 24, 2005 23:15 > To: isms@ietf.org > Subject: [Isms] Multiple access control models > > > Hi, > > I think #1 can be achieved by describing in an ISMS security model how > the vacmSecurityToGroupTable gets populated by additional sources, and > augmenting the VACM MIB module with source information; this info can > also provide the information necessary to delete session-specific rows > when the session closes. > > There are two major architectural problems with this approach - it is > totally dependent on VACM being the only ACM model the solution will > work with, and any security model that utilizes AAA to populate the > table creates dependencies between specific models in the security > subsystem and specific models in the AC subsystem. That is contrary to > the RFC3411 architectural philosophy. > I am not sure I understand this discussion. If we add entries to the vacmXxxTables in the snmpVacmMib module, then WHY does that have to be done such that it can be used by other possible Access Control Model(s) in the future? Is the fact that the VACM mib module is defined in a VACM specific document not indicative of the fact that we intend(ed) it to be used specifically by VACM (and possibly not by other ACM models)? If in the future a new ACM gets added, then that modular document will have to specify how it uses current SNMP USM info (securityModel, securityLevel, securityName) to map it into its access control mechanisms. So if by that time we have defined how the SSH Security Model maps into VACM, then that new ACM will also have to define how SSH Security Model maps into that new ACM. Or am I hallucinating again? Bert _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 27 10:21:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yi-0000sM-QB; Sat, 27 Aug 2005 10:21:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yh-0000rZ-5R for isms@megatron.ietf.org; Sat, 27 Aug 2005 10:21:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15721 for ; Sat, 27 Aug 2005 10:21:20 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E91Zd-0001bx-RD for isms@ietf.org; Sat, 27 Aug 2005 10:22:22 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7REL2M1007737; Sat, 27 Aug 2005 09:21:08 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Aug 2005 16:21:02 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0E38D@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: dbharrington@comcast.net, isms@ietf.org Subject: RE: [Isms] Mandatory-to-implement Date: Sat, 27 Aug 2005 16:21:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org I would say that an implementation that wants to claim compliance with SNMPv3 (STD62) MUST implement USM. If such an implementation at the same time wants to claim compliance with an ISMS developed standard, then that standard can require that it MUST implement X (SSH for example). It is then up to the user/customer of such an SNMP implementation as to what he/she wants to deploy. Or so is my thinking. Bert > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of David B Harrington > Sent: Wednesday, August 24, 2005 23:52 > To: isms@ietf.org > Subject: [Isms] Mandatory-to-implement > > > Hi, > > There has been some mention of mandatory-to-implement. I have concerns > with what that means relative to SNMPv3. Is there intention in this WG > to make the ISMS security model mandatory-to-implement for SNMPv3 > compliance? > > I think that would be a mistake, especially since the data gathering > done by this WG has shown that there are no existing security > infrastructures that meet the requirements of all (or even most) > segments of the SNMP community. > > SNMPv3 already has a mandatory-to-implement security model - USM - > which meets a variety of requirements we haven't been discussing in > the WG, and I am not convinced SSH can meet them - > 1) USM provides a solution that works even if no third party > authentication server is accessible (say in a partially broken > network), > 2) USM uses UDP, which reputedly can get through in some instances > when TCP isn't viable, > 3) USM supports auto-discovery of SNMP-capable devices by NMS > applications, and > 4) USM is defined to be viable in a resource-contrained environment > (that doesn't have such things as RADIUS support). > > In addition, using a TCP-based transport presents opportunities that > may not be backwards compatible, such as defining managed objects that > can be passed via TCP, but wouldn't fit into a 484-byte UDP packet. > The IETF SNMP community needs to decide whether a MIB module not > compatible with the UDP transport mapping is allowed or not, and if it > is, whether there is some boilerplate text that will need to included, > and whether the MIB module needs to have some NMS-accessible object > that identifies the need for TCP transport capabilities. > > I'm fairly sure there are other issues we haven't been discussing. > > I think it would be a mistake to think that the ISMS security model > will be able to REPLACE USM as the mandatory-to-implement security > model. > > Given that, we might want to consider a "coexistence" document or > appendix that describes how to configure USM in a simple manner to > permit these additional functions to be performed via the USM security > model. Such an appendix might be appropriate for the Applicability > Statements document, describing for which uses the SSH/RADIUS/TCP > approach is applicable, and for which uses the USM/UDP approach is > applicable. If we assume USM will always be available, new security > models, including the ISMS security model, may not need to support all > the requirements supported by USM. > > David Harrington > dbharrington@comcast.net > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 27 10:21:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Ym-0000vu-KW; Sat, 27 Aug 2005 10:21:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yi-0000sK-Nb for isms@megatron.ietf.org; Sat, 27 Aug 2005 10:21:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15729 for ; Sat, 27 Aug 2005 10:21:22 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E91Zf-0001bz-G6 for isms@ietf.org; Sat, 27 Aug 2005 10:22:23 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7RELC8q007799; Sat, 27 Aug 2005 09:21:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Aug 2005 16:21:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0E38E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, "'Sam Hartman'" , dbharrington@comcast.net Subject: RE: [Isms] Architectural issues Date: Sat, 27 Aug 2005 16:21:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org W.r.t. > > > > Do you see anyone arguing for other than the third approach? > > > > Yes, I see some (quasi-) proposals that seem to play very loosely with > the architecture. > And that we (SNMPv3 architecture conscious people) should worry about and we should rty to help find solutions that do fit in and comply with the SNMPv3 architecture. > I would like to see some of the proposals presented in a more > fully-baked fashion, including discussion of how it fits into the > architecture, so we can see more clearly whether they abide by the > existing architecture or not. > That would be very good indeed. And if they do not abide at first, I would rather first see if we can change/modify them so that they do abide. Only if we fail at that, then we should consider a new architecture (which I think is what you meant with your 3rd option, but I am not 100% sure, so pls confirm if I got it right). Bert > David Harrington > dbharrington@comcast.net > co-chair IETF SNMPv3 WG, concluded > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sat Aug 27 10:21:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yp-0000x1-SD; Sat, 27 Aug 2005 10:21:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E91Yp-0000ws-2n for isms@megatron.ietf.org; Sat, 27 Aug 2005 10:21:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15741 for ; Sat, 27 Aug 2005 10:21:28 -0400 (EDT) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E91Zk-0001cC-Ow for isms@ietf.org; Sat, 27 Aug 2005 10:22:30 -0400 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j7RELC0X007797; Sat, 27 Aug 2005 09:21:13 -0500 (CDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Sat, 27 Aug 2005 16:21:12 +0200 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B15507E0E38F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, "'Keith McCloghrie'" , isms@ietf.org Subject: RE: [Isms] Multiple access control models Date: Sat, 27 Aug 2005 16:21:02 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Inline > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On > Behalf Of David B Harrington > Sent: Thursday, August 25, 2005 20:02 > To: 'Keith McCloghrie'; isms@ietf.org > Subject: RE: [Isms] Multiple access control models > > > Hi Keith, > > Thank you for your comments. I agree with them. > > I hope I wasn't too subtle. I agree that populating a vacm table from > a security model is **broken** and do not believe it should be done > that way. Some proposals seem to argue for that solution, and while it > is one way to achieve the mapping, it has serious architectural > problems to do it that way. > Well... are you sure? I know that in many implementations, the VACM tables get populated from both config files and from possible SNMP SET commands. If people follow some of the suggestions in the appendices of both RFC3414 and RFC3415, then they may possibly (at install time) ask a few questions (in CLI mode I guess) from the installing-person and based on his/her answers, several entries may get populated in the VACM and USM tables. SO there you have 3 ways that vacm tables get populated these days I think. And currently we do NOT differentiate as to where that information comes from. So when you read the VACM tables, you cannot (for sure) say how the entries got created. So for me it is not so clear yet that we cannot have some SSH/RADIUS paramters/attributes to cause implied populations of various tables at session setup. And similarly such entries could be destroyed when the session gets broken. Of course we need to work that out, but I would not a priori claim that it is against the architecture. Maybe I am missing things that you see. If so, pls explain. > Thank you for reinforcing this. > > If populating the vacm table is done as part of VACM, where does the > information come from? How do you maintain the cryptographic binding > between the authentication and the authorization? RFC 3411 provides > the model/level/name triplet in the ASIs to provide such binding. But > how does one use that from within VACM to access e.g. RADIUS > attributes for authorization? > I do not yet know that answer. Because I do not understand the SSH/RADIUS mechanisms and paramters and attributes well enough yet. Bert > dbh > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Sun Aug 28 22:24:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZJa-0004Tf-LR; Sun, 28 Aug 2005 22:24:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9ZJY-0004TX-RM for isms@megatron.ietf.org; Sun, 28 Aug 2005 22:24:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26031 for ; Sun, 28 Aug 2005 22:23:58 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9ZKn-0006MU-HY for isms@ietf.org; Sun, 28 Aug 2005 22:25:18 -0400 Received: from [192.168.0.112] (HSI-KBW-085-216-002-068.hsi.kabelbw.de [85.216.2.68]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C36521BAC4D; Mon, 29 Aug 2005 04:23:46 +0200 (CEST) Date: Mon, 29 Aug 2005 04:23:52 +0200 From: Juergen Quittek To: ietfdbh@comcast.net, "'Sam Hartman'" Subject: RE: [Isms] draft of ISMS charter Message-ID: <2DE38324FDA81F7E27A3A760@[192.168.0.112]> In-Reply-To: <20050826184827.D3F89DC31@smtp0.netlab.nec.de> References: <20050826184827.D3F89DC31@smtp0.netlab.nec.de> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi David, --On 8/26/2005 2:48 PM -0400 David B Harrington wrote: > Hi, > > I do not object to the proposed charter. > > I am suggesting an alternative arrangement of the goals/deadlines that > keeps our promised deliverables in line with our committed resources, Can you be more concrete how the alternative arrangement would look like? > to maximize our ability to meet the charter deadlines. So far, our > chairs have not aggressively recruited volunteers and then held their > feet to the fire to ensure deadlines were met. Do you refer to draft-ietf-isms-proposal-comparison-00.txt? Which volunteer's feet did we hold to the fire? > I am concerned that > committing to deliverables without having volunteers willing to commit > and follow-through to produce those deliverables increases our chance > of failure. Yes, there is always the risk of failure. I also know that we cannot commit documents without having a community to write and evaluate them. But we do have a list of volunteers and we are just finishing the controversy discussion on which documents we need and what should be their content. But now, with most of these things converging, indeed time has come for discussing contributions. Thanks, Juergen > David Harrington > dbharrington@comcast.net > >> -----Original Message----- >> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >> Sent: Friday, August 26, 2005 12:17 PM >> To: ietfdbh@comcast.net >> Cc: 'Juergen Quittek'; isms@ietf.org >> Subject: Re: [Isms] draft of ISMS charter >> >> David, are you objecting to the proposed charter or just saying you >> would do things differently? >> >> > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 10:15:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kP6-0002ZD-PD; Mon, 29 Aug 2005 10:14:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kP4-0002Z6-UK for isms@megatron.ietf.org; Mon, 29 Aug 2005 10:14:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11917 for ; Mon, 29 Aug 2005 10:14:25 -0400 (EDT) Message-Id: <200508291414.KAA11917@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kQP-00011o-TX for isms@ietf.org; Mon, 29 Aug 2005 10:15:51 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005082914141501400kkdooe>; Mon, 29 Aug 2005 14:14:16 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Sam Hartman'" Subject: RE: [Isms] draft of ISMS charter Date: Mon, 29 Aug 2005 10:14:07 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWsQLCPSZsiPjM9SzyjLnCmr34tywAYsC+A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <2DE38324FDA81F7E27A3A760@[192.168.0.112]> X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Juergen Quittek [mailto:quittek@netlab.nec.de] > > > > I am suggesting an alternative arrangement of the > goals/deadlines that > > keeps our promised deliverables in line with our committed > resources, > > Can you be more concrete how the alternative arrangement > would look like? I made a concrete alternative proposal in my mail of 8/25 5:29 David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 10:26:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kaI-000562-Mu; Mon, 29 Aug 2005 10:26:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kaH-00055x-LJ for isms@megatron.ietf.org; Mon, 29 Aug 2005 10:26:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13241 for ; Mon, 29 Aug 2005 10:25:59 -0400 (EDT) Message-Id: <200508291425.KAA13241@ietf.org> Received: from rwcrmhc12.comcast.net ([204.127.198.43]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kbc-0001SN-QG for isms@ietf.org; Mon, 29 Aug 2005 10:27:26 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005082914255001400knk17e>; Mon, 29 Aug 2005 14:25:50 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Multiple access control models Date: Mon, 29 Aug 2005 10:25:45 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWrEpBhqWegtA5jQhy8qN7us5LUkQBkckaA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507E0E38C@nl0006exch001u.nl.lucent.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > I am not sure I understand this discussion. > This discussion is difficult to follow because we have no concrete proposal on the table to discuss, but are talking purely in generaltities and assumptions. I recommend that this WG get a concrete proposal for how to pass authorization information into the access control subsystem, or into the VACM model, so we can actually see how the proposal would address the architectural issues, and then adjust the approach to be architecturally correct if necessary. Lacking such a concrete proposal, I suggest the new charter focus on message security issues, as covered in TMSM and the SSH model, and put the authorization issue off until we have a concrete proposal to start from. dbh _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 10:33:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9khB-00067F-LR; Mon, 29 Aug 2005 10:33:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kh9-00066l-Vx for isms@megatron.ietf.org; Mon, 29 Aug 2005 10:33:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13535 for ; Mon, 29 Aug 2005 10:33:04 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9kiN-0001bU-VD for isms@ietf.org; Mon, 29 Aug 2005 10:34:30 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7TEWrZC008704 for ; Mon, 29 Aug 2005 10:32:53 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 29 Aug 2005 10:32:53 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 29 Aug 2005 10:32:53 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Aug 2005 10:32:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] draft of ISMS charter Date: Mon, 29 Aug 2005 10:32:52 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032548@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] draft of ISMS charter Thread-Index: AcWsQLCPSZsiPjM9SzyjLnCmr34tywAYsC+AAACAfkA= From: "Nelson, David" To: X-OriginalArrivalTime: 29 Aug 2005 14:32:53.0351 (UTC) FILETIME=[8A39A770:01C5ACA6] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:97.0282 P:95.9108 R:95.9108 S:86.4001 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > I made a concrete alternative proposal in my mail of 8/25 5:29 Which was: >Personally, I think the WG would be smart to solve 1, 2, and 7 first, >because there are plenty of issues in solving these problems, and we have >volunteers to research and edit the documents on these issues, and previous >work has already started addressing these issues (TMSM, RFC 3430, Netconf, >etc.) > >Then we could recharter to solve 3 through 6, which is a separate set of >problems. I have not seen volunteers to research and edit the documents on >these issues, and the attributes we plan to use haven't even been accepted >as RADEXT work items yet, AFAIK. I understand, all too well, the desire to keep focus and to not charter more that the WG can reliably produce. OTOH, it seems to me that the WG needs to produce a solution, not just a few components that are part of a solution. Structuring the work, in terms of an order of completion, is probably a good idea. Chartering only part of the solution, with the resultant requirement to re-charter to finish the job, seems like a bad idea. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 10:38:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kmE-00072u-MA; Mon, 29 Aug 2005 10:38:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9kmD-00072p-D8 for isms@megatron.ietf.org; Mon, 29 Aug 2005 10:38:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13865 for ; Mon, 29 Aug 2005 10:38:19 -0400 (EDT) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9knE-0001k8-Lo for isms@ietf.org; Mon, 29 Aug 2005 10:39:46 -0400 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j7TEbwZC008958 for ; Mon, 29 Aug 2005 10:37:58 -0400 (EDT) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 29 Aug 2005 10:37:58 -0400 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 29 Aug 2005 10:37:58 -0400 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 29 Aug 2005 10:37:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Multiple access control models Date: Mon, 29 Aug 2005 10:37:57 -0400 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032549@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Multiple access control models Thread-Index: AcWrEpBhqWegtA5jQhy8qN7us5LUkQBkckaAAACW8wA= From: "Nelson, David" To: X-OriginalArrivalTime: 29 Aug 2005 14:37:58.0320 (UTC) FILETIME=[40003B00:01C5ACA7] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:69.3312 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org David Harrington writes... > Lacking such a concrete proposal, I suggest the new charter focus on > message security issues, as covered in TMSM and the SSH model, and put > the authorization issue off until we have a concrete proposal to start > from. I disagree. If this work is out of scope of the charter, we're going to have a hard time discussing it on the mailing list. I think our recent history bears me out here. So then it becomes a chicken-and-egg issue. We can't discus authorization because it's not in the charter and we can't add it to the charter until we have a concrete proposal. :-( _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 12:58:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mxv-0000se-El; Mon, 29 Aug 2005 12:58:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9mxs-0000s8-4A for isms@megatron.ietf.org; Mon, 29 Aug 2005 12:58:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20858 for ; Mon, 29 Aug 2005 12:58:29 -0400 (EDT) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9mzF-0005yR-9D for isms@ietf.org; Mon, 29 Aug 2005 12:59:57 -0400 Received: from [192.168.0.241] (p54ACF7E0.dip.t-dialin.net [84.172.247.224]) by kyoto.netlab.nec.de (Postfix) with ESMTP id B65B41BAC4D for ; Mon, 29 Aug 2005 18:58:21 +0200 (CEST) Date: Mon, 29 Aug 2005 18:58:24 +0200 From: Juergen Quittek To: isms@ietf.org Message-ID: In-Reply-To: References: <42FF549A.1070605@cisco.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] Stating rough consensus, was: Call for consensus X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Dear all, Hereby Ken and I state that the WG has achieved rough consensus on two issues: 1. The ISMS WG will work on one transport protocol only. 2. ISMS will use SSH as transport protocol. The consensus is not as clear as these statements look like. There was quite some controversy discussion that is partially reflected by the following comments on the consensus: - The WG focuses its resources on one transport protocol that is most promising in the near future. - SSH is the protocol to which the new charter of the WG will be restricted. The ISMS WG does not claim that SSH is the only suitable choice. - The WG encourages people developing solutions based on alternative transport protocols, such as BEEP or TLS, to pursue their work in parallel to the work done by the ISMS WG and to discuss their progress and results on the ISMS mailing list and at ISMS sessions. Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 8/15/2005 2:34 AM +0200 Juergen Quittek wrote: > As stated at the saag session, I think that the following decisions > made the ISMS session need approval from the mailing list: > > 1. The ISMS WG will work on one transport protocol only > > 2. ISMS will use SSH as transport protocol > > These issues are not exactly the ones from your list, but they > are targeting at the same direction and reflect the discussion > at the Paris session. > > For 1. I am not aware of contrary opinions. I see consensus on 1. > Anyone who disagrees, please speak up soon. > > For 2. there was a clear preference at the session. However, > there were statements challenging this decision on the list, > mainly from people in favor of BEEP. At the session there > were also also people favoring TLS+SASL, but so far they did > not express severe concerns on the mailing list about choosing > SSH instead. > > Concerns were raised at the meeting that none of the alternatives > (TLS+SASL, BEEP, SSH, and DTLS) are sufficiently described by an > Internet draft (for BEEP we have the most detailed description) > for making the decision. > > However, we need to make progress and arguments have been exchanged > extensively. Therefore I ask particularly people who did not > participate in the Paris session to express their concerns about > ISMS using SSH as transport protocol. > > Thanks, > > Juergen _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 18:36:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sEf-0006QC-Js; Mon, 29 Aug 2005 18:36:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sEd-0006Pz-LG for isms@megatron.ietf.org; Mon, 29 Aug 2005 18:36:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16391 for ; Mon, 29 Aug 2005 18:36:09 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9sG3-00011V-7W for isms@ietf.org; Mon, 29 Aug 2005 18:37:40 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D5AAEE0049; Mon, 29 Aug 2005 18:36:00 -0400 (EDT) To: Juergen Quittek Subject: Re: [Isms] Stating rough consensus, was: Call for consensus References: <42FF549A.1070605@cisco.com> From: Sam Hartman Date: Mon, 29 Aug 2005 18:36:00 -0400 In-Reply-To: (Juergen Quittek's message of "Mon, 29 Aug 2005 18:58:24 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org One other thing I think you should encourage is people working on non-SSH solutions to give input to the architectural extensions. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 18:38:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sGy-0007Fx-Dc; Mon, 29 Aug 2005 18:38:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sGw-0007Bs-G0 for isms@megatron.ietf.org; Mon, 29 Aug 2005 18:38:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16499 for ; Mon, 29 Aug 2005 18:38:31 -0400 (EDT) Received: from carter-zimmerman.mit.edu ([18.18.3.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9sIL-00014y-Vo for isms@ietf.org; Mon, 29 Aug 2005 18:40:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 7CD3BE0049; Mon, 29 Aug 2005 18:38:29 -0400 (EDT) To: "Nelson, David" Subject: Re: [Isms] draft of ISMS charter References: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032548@MAANDMBX2.ets.enterasys.com> From: Sam Hartman Date: Mon, 29 Aug 2005 18:38:29 -0400 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032548@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Mon, 29 Aug 2005 10:32:52 -0400") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org >>>>> "Nelson," == Nelson, David writes: Nelson,> OTOH, it seems to me that the WG needs to produce a Nelson,> solution, not just a few components that are part of a Nelson,> solution. Structuring the work, in terms of an order of Nelson,> completion, is probably a good idea. Chartering only Nelson,> part of the solution, with the resultant requirement to Nelson,> re-charter to finish the job, seems like a bad idea. I agree here as an individual and likely as an AD. I don't want to have to recharter in order to solve the problem. OTOH, the chairs do have flexibility to limit what charter items are worked on at any point in time. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 19:03:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sfE-0004UI-1z; Mon, 29 Aug 2005 19:03:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9sfC-0004Tv-HE for isms@megatron.ietf.org; Mon, 29 Aug 2005 19:03:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19017 for ; Mon, 29 Aug 2005 19:03:35 -0400 (EDT) Message-Id: <200508292303.TAA19017@ietf.org> Received: from rwcrmhc14.comcast.net ([204.127.198.54] helo=rwcrmhc12.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9sgc-0002DX-4m for isms@ietf.org; Mon, 29 Aug 2005 19:05:07 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc14) with SMTP id <2005082923032701400hhrage>; Mon, 29 Aug 2005 23:03:27 +0000 From: "David B Harrington" To: Date: Mon, 29 Aug 2005 19:03:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWs7drh2zy8A8M/QwaYDJxBU05XUQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: Subject: [Isms] SSH vs SNMP concepts X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, In SNMP, it is acceptable to have multiple engines resident on the same device, typically listening at different transport addresses. SNMPv3 uses the engineID (SNMPv3) to differentiate the engines. If multiple SSH servers or multiple SSH clients exist on the same host, how would one differentiate them? Is this standardized? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 19:23:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9syl-0005fs-Pc; Mon, 29 Aug 2005 19:23:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9syk-0005fn-Qy for isms@megatron.ietf.org; Mon, 29 Aug 2005 19:23:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23336 for ; Mon, 29 Aug 2005 19:23:47 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9t09-00041E-Oq for isms@ietf.org; Mon, 29 Aug 2005 19:25:20 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 29 Aug 2005 16:23:40 -0700 X-IronPort-AV: i="3.96,151,1122879600"; d="scan'208"; a="657294455:sNHT29232896" Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7TNNWQM024135; Mon, 29 Aug 2005 16:23:32 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] SSH vs SNMP concepts Date: Mon, 29 Aug 2005 16:28:32 -0700 Message-ID: <7210B31550AC934A8637D6619739CE6905C8C562@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] SSH vs SNMP concepts Thread-Index: AcWs7drh2zy8A8M/QwaYDJxBU05XUQAAnPmg From: "Salowey, Joe" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Multiple SSH clients can be resident on a host. I believe that multiple SSH server would require each server to run on a different port. Depending on what you want to achieve you may be able to have multiple subsystems running in a single server, however all of those subsystems would be authenticated to the SSH client with the same credential used in establishing the SSH session. =20 > -----Original Message----- > From: David B Harrington [mailto:dbharrington@comcast.net]=20 > Sent: Monday, August 29, 2005 4:03 PM > To: isms@ietf.org > Subject: [Isms] SSH vs SNMP concepts >=20 > Hi, >=20 > In SNMP, it is acceptable to have multiple engines resident=20 > on the same device, typically listening at different=20 > transport addresses. > SNMPv3 uses the engineID (SNMPv3) to differentiate the engines. >=20 > If multiple SSH servers or multiple SSH clients exist on the=20 > same host, how would one differentiate them? Is this standardized? >=20 > David Harrington > dbharrington@comcast.net >=20 >=20 >=20 >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 23:00:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wLx-0004iD-Oi; Mon, 29 Aug 2005 23:00:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9wLw-0004i2-PR for isms@megatron.ietf.org; Mon, 29 Aug 2005 23:00:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02440 for ; Mon, 29 Aug 2005 22:59:58 -0400 (EDT) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9wNM-0001AZ-Fn for isms@ietf.org; Mon, 29 Aug 2005 23:01:31 -0400 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j7U2wRo5014358; Mon, 29 Aug 2005 19:58:27 -0700 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j7U2wM6b027318; Mon, 29 Aug 2005 19:58:22 -0700 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j7U2wLNU027315; Mon, 29 Aug 2005 19:58:22 -0700 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 29 Aug 2005 19:58:21 -0700 (PDT) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Salowey, Joe" Subject: RE: [Isms] SSH vs SNMP concepts In-Reply-To: <7210B31550AC934A8637D6619739CE6905C8C562@e2k-sea-xch2.sea-alpha.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: dbharrington@comcast.net, isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org HI, A little known secret of SNMP is that "command generators" (that is, management applications) DO NOT need to have a value of an engineID. Likewise, receivers of TRAPs and "proxy" senders of INFORMs do not need a value for an SNMP engineID. And in the majority of the implementations of SNMP management applications, there is not a shared SNMP engine. Each one uses a separate (and unique) transport address. The reason that the above do not need an SNMP engineID is that SNMPengineIDs are used for two purposes (identifying the "source" of management info, and for use in USM of identifying the "authoritative engine"), and that these two uses are not applicable to command generators, TRAP receivers, or proxy INFORM senders. For ISMS-SSH security model, more than likely the sub-fields of field msgAuthoritativeEngineID will be totally different than those for USM, and thus, field msgAuthoritativeEngineID will not be in messages! Also, if is possible for multiple SNMP engines to be sharing the same transport address. The value of contextEngineID specifies which command responder that a request is for. That is, the transport addresse (and message type) determines the value of msgAuthoritativeEngineID to use for SNMPv3/USM, and contextEngineID specifies for ALL SNMPv3/* messages the "source" of the management info. Back to your question, for SSH, you can specify as a startup option what port you want an SSH server to use, (and the port that you want an SSH client to use for the server). However, I don't know if the the "known_hosts" files used by most (maybe all) SSH implementations, contain just NETWORK addresses (that is just IP address), or can also contain TRANSPORT addresses. If so, then multiple SSH servers can be accessed on a system. This would only be needed if "ships in the night" implementation was needed for multiple SNMP command responders on the same system. Or "ships in the night" implementation of a command responder and one or more "notification receivers." I hope this helps, but it may confuse readers. Sorry. Please ask questions if you are confused. On Mon, 29 Aug 2005, Salowey, Joe wrote: > Multiple SSH clients can be resident on a host. I believe that multiple > SSH server would require each server to run on a different port. > Depending on what you want to achieve you may be able to have multiple > subsystems running in a single server, however all of those subsystems > would be authenticated to the SSH client with the same credential used > in establishing the SSH session. > > > -----Original Message----- > > From: David B Harrington [mailto:dbharrington@comcast.net] > > Sent: Monday, August 29, 2005 4:03 PM > > To: isms@ietf.org > > Subject: [Isms] SSH vs SNMP concepts > > > > Hi, > > > > In SNMP, it is acceptable to have multiple engines resident > > on the same device, typically listening at different > > transport addresses. > > SNMPv3 uses the engineID (SNMPv3) to differentiate the engines. > > > > If multiple SSH servers or multiple SSH clients exist on the > > same host, how would one differentiate them? Is this standardized? > > > > David Harrington > > dbharrington@comcast.net Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Mon Aug 29 23:59:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xHY-0004Nz-79; Mon, 29 Aug 2005 23:59:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xHW-0004NL-00 for isms@megatron.ietf.org; Mon, 29 Aug 2005 23:59:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04767 for ; Mon, 29 Aug 2005 23:59:27 -0400 (EDT) Received: from pop-sarus.atl.sa.earthlink.net ([207.69.195.72]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9xIz-0002bl-7K for isms@ietf.org; Tue, 30 Aug 2005 00:01:01 -0400 Received: from h-68-164-241-191.snvacaid.dynamic.covad.net ([68.164.241.191] helo=oemcomputer) by pop-sarus.atl.sa.earthlink.net with smtp (Exim 3.36 #10) id 1E9xHU-0002dF-00 for isms@ietf.org; Mon, 29 Aug 2005 23:59:28 -0400 Message-ID: <010601c5ad17$7cf03fe0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] SSH vs SNMP concepts Date: Mon, 29 Aug 2005 21:01:23 -0700 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi - > From: "David T. Perkins" > To: "Salowey, Joe" > Cc: ; > Sent: Monday, August 29, 2005 7:58 PM > Subject: RE: [Isms] SSH vs SNMP concepts ... > A little known secret of SNMP is that "command generators" (that > is, management applications) DO NOT need to have a value of > an engineID. Likewise, receivers of TRAPs and "proxy" senders > of INFORMs do not need a value for an SNMP engineID. Of course, the keys for such an application can't be managed using USM, since entries in the usmUserTable are indexed by, of all things, usmUserEngineID, and usmUserName. This means that even if one has key update infrastructure in place to update all the "agents", these "managers" are out in the cold. Could this deployment strategy be a problem? > And in the majority of the implementations of SNMP management > applications, there is not a shared SNMP engine. Each one > uses a separate (and unique) transport address. It's perfectly reasonable for a single engine to use multiple transport addresses. Whether different applications do (or don't) share an SNMP engine is an implementation decision. For things like handling notifications, using multiple engines would clearly have some rather undesireable properties, but when we did SNMPv3 it was crystal clear that the architecture had to be able to support it, and it was one of the motivations for the introduction of the engineID concept. > The reason that the above do not need an SNMP engineID is > that SNMPengineIDs are used for two purposes (identifying > the "source" of management info, and for use in USM of > identifying the "authoritative engine"), and that these > two uses are not applicable to command generators, TRAP > receivers, or proxy INFORM senders. You omit a third important purpose: key distribution using the mechanisms of RFC 3413. > For ISMS-SSH security model, more than likely the sub-fields > of field msgAuthoritativeEngineID will be totally different > than those for USM, and thus, field msgAuthoritativeEngineID > will not be in messages! I don't understand the logic of this statement. USM knows nothing about the sub-field structure of msgAuthoritativeEngineID. The motivation for the structure of engineIDs is to provide a means of ensuring uniqueness in an administrative domain, and not to support any other inferences that might be made as a result of parsing them. They are supposed to be essentially opaque. > Also, if is possible for multiple SNMP engines to be > sharing the same transport address. The value of > contextEngineID specifies which command responder > that a request is for. That is, the transport addresse > (and message type) determines the value of > msgAuthoritativeEngineID to use for SNMPv3/USM, and > contextEngineID specifies for ALL SNMPv3/* messages > the "source" of the management info. ... A slight clarification to Dave's statement: "determines" should not be understood as "allows one to compute a priori". Rather, knowing the transport address and message type, if one has a cached engineID for that combination, permits one to use that engineID in the hope of avoiding a round-trip for engineID discovery. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@lists.ietf.org Tue Aug 30 10:25:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA73B-0003sT-6A; Tue, 30 Aug 2005 10:25:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA739-0003sJ-2E for isms@megatron.ietf.org; Tue, 30 Aug 2005 10:25:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16003 for ; Tue, 30 Aug 2005 10:25:16 -0400 (EDT) Message-Id: <200508301425.KAA16003@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EA74f-0002i4-JK for isms@ietf.org; Tue, 30 Aug 2005 10:26:56 -0400 Received: from djyxpy41 (c-24-128-104-6.hsd1.nh.comcast.net[24.128.104.6]) by comcast.net (rwcrmhc12) with SMTP id <2005083014250601400apmige>; Tue, 30 Aug 2005 14:25:06 +0000 From: "David B Harrington" To: Subject: RE: [Isms] SSH vs SNMP concepts Date: Tue, 30 Aug 2005 10:24:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWtF0taHT5W5L3+TMac4t4IJONO+QAVkurg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <010601c5ad17$7cf03fe0$7f1afea9@oemcomputer> X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@lists.ietf.org Errors-To: isms-bounces@lists.ietf.org Hi, Let's not confuse all the non-SNMP security people on this list by discussing "little known secrets of SNMP" that have little relevance to the question asked. If you want to discuss SNMP esoterica, I suggest at least changing the subject line. The question asked was about whether SSH had a mechanism that would allow us to mirror a specific SNMP capability - "If multiple SSH servers or multiple SSH clients exist on the same host, how would one differentiate them? Is this standardized?" Thanks, dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Tuesday, August 30, 2005 12:01 AM > To: isms@ietf.org > Subject: Re: [Isms] SSH vs SNMP concepts > > Hi - > > > From: "David T. Perkins" > > To: "Salowey, Joe" > > Cc: ; > > Sent: Monday, August 29, 2005 7:58 PM > > Subject: RE: [Isms] SSH vs SNMP concepts > ... > > A little known secret of SNMP is that "command generators" (that > > is, management applications) DO NOT need to have a value of > > an engineID. Likewise, receivers of TRAPs and "proxy" senders > > of INFORMs do not need a value for an SNMP engineID. > > Of course, the keys for such an application can't be managed using > USM, since entries in the usmUserTable are indexed by, of all things, > usmUserEngineID, and usmUserName. This means that even if one > has key update infrastructure in place to update all the > "agents", these > "managers" are out in the cold. Could this deployment strategy be a > problem? > > > And in the majority of the implementations of SNMP management > > applications, there is not a shared SNMP engine. Each one > > uses a separate (and unique) transport address. > > It's perfectly reasonable for a single engine to use multiple > transport > addresses. Whether different applications do (or don't) share an > SNMP engine is an implementation decision. For things like handling > notifications, using multiple engines would clearly have some rather > undesireable properties, but when we did SNMPv3 it was crystal clear > that the architecture had to be able to support it, and it was one of > the motivations for the introduction of the engineID concept. > > > The reason that the above do not need an SNMP engineID is > > that SNMPengineIDs are used for two purposes (identifying > > the "source" of management info, and for use in USM of > > identifying the "authoritative engine"), and that these > > two uses are not applicable to command generators, TRAP > > receivers, or proxy INFORM senders. > > You omit a third important purpose: key distribution using the > mechanisms of RFC 3413. > > > For ISMS-SSH security model, more than likely the sub-fields > > of field msgAuthoritativeEngineID will be totally different > > than those for USM, and thus, field msgAuthoritativeEngineID > > will not be in messages! > > I don't understand the logic of this statement. USM knows nothing > about the sub-field structure of msgAuthoritativeEngineID. > The motivation for the structure of engineIDs is to provide a means > of ensuring uniqueness in an administrative domain, and not to support > any other inferences that might be made as a result of parsing them. > They are supposed to be essentially opaque. > > > Also, if is possible for multiple SNMP engines to be > > sharing the same transport address. The value of > > contextEngineID specifies which command responder > > that a request is for. That is, the transport addresse > > (and message type) determines the value of > > msgAuthoritativeEngineID to use for SNMPv3/USM, and > > contextEngineID specifies for ALL SNMPv3/* messages > > the "source" of the management info. > ... > > A slight clarification to Dave's statement: "determines" should > not be understood as "allows one to compute a priori". Rather, > knowing the transport address and message type, if one has a > cached engineID for that combination, permits one to use that > engineID in the hope of avoiding a round-trip for engineID discovery. > > Randy > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms