From isms-bounces@ietf.org Tue Feb 1 10:21:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14985; Tue, 1 Feb 2005 10:21:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw08R-0004rc-9w; Tue, 01 Feb 2005 10:40:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvzjS-00085H-36; Tue, 01 Feb 2005 10:14:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvzdd-0005RJ-3K for isms@megatron.ietf.org; Tue, 01 Feb 2005 10:08:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13147 for ; Tue, 1 Feb 2005 10:08:19 -0500 (EST) 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.33) id 1Cvzvm-0004Vh-Um for isms@ietf.org; Tue, 01 Feb 2005 10:27:08 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id BBC8C11D9FE; Tue, 1 Feb 2005 07:08:17 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] Evaluation status [and more] Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190E1@MAANDMBX2.ets.enterasys.com> Date: Tue, 01 Feb 2005 07:08:17 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190E1@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Mon, 31 Jan 2005 18:35:15 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 >>>>> On Mon, 31 Jan 2005 18:35:15 -0500, "Nelson, David" said: David> I believe that authorization *needs* to be strongly bound to David> authentication, to be robust and trustworthy. I think we've hashed this argument enough before and the different viewpoints on the subject are already known. Everyone does agree with the above statement to the extend that it must be possible for the authorization system to trust the authentication system to (securely) hand it information about how a request/response was authenticated and using what security mechanisms. Everyone is in agreement there. >> I would not mind, personally, if the charter were updated to >> include such future work as well but right now we haven't >> actually accomplished the immediate goals of determining an >> architectural direction to solve the current problem. David> Agreed. We need to keep the pressure on to complete current David> goals. That doesn't mean that authorization is unimportant, David> however. And there! -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 1 13:25:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03255; Tue, 1 Feb 2005 13:25:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw30p-0001At-GQ; Tue, 01 Feb 2005 13:44:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2er-0005t4-Ca; Tue, 01 Feb 2005 13:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2QS-0003pB-WB for isms@megatron.ietf.org; Tue, 01 Feb 2005 13:06:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01668 for ; Tue, 1 Feb 2005 13:06:52 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw2ic-0000lW-2n for isms@ietf.org; Tue, 01 Feb 2005 13:25:43 -0500 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 j11I6D7I024389 for ; Tue, 1 Feb 2005 10:06:13 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76TMM8>; Tue, 1 Feb 2005 10:07:14 -0800 Message-ID: From: "McDonald, Ira" To: isms@ietf.org Date: Tue, 1 Feb 2005 10:07:13 -0800 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: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Isms] Let's move forward now 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi, Four months ago, the authors of three ISMS proposals rushed out their I-Ds in a few weeks. Since then, nothing productive has happened. The ISMS WG is rapidly headed toward failure. Randy has noted that the WG is free under IETF rules to ignore the recommendation of the selection team. But that's simply impossible, because the odor of ten years wasted on SNMPv2 and SNMPv3 lingers in the collective memory of the IESG. So I suggest a radical departure: The authors of the existing three ISMS proposals (and any others with good ideas) should begin immediately to revise and reissue their I-Ds, assuming that they will advance as individual contributions. The operator and user communities would be much better served by this approach than the current 'deer in the headlights' fatalistic approach. 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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 1 13:35:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04454; Tue, 1 Feb 2005 13:35:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw3A6-0001S6-V9; Tue, 01 Feb 2005 13:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2qL-0000wZ-67; Tue, 01 Feb 2005 13:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw2hX-0006eV-1y for isms@megatron.ietf.org; Tue, 01 Feb 2005 13:24:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03153 for ; Tue, 1 Feb 2005 13:24:32 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw2zi-00018b-Ic for isms@ietf.org; Tue, 01 Feb 2005 13:43:24 -0500 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 KAA18663; Tue, 1 Feb 2005 10:23:53 -0800 (PST) Received: from xch-nwbh-01.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 j11INnJ11696; Tue, 1 Feb 2005 12:23:49 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 1 Feb 2005 10:23:50 -0800 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] Evaluation status [and more] Date: Tue, 1 Feb 2005 10:23:50 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDBC4@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcUHia3vQJtlcCzSSwiU9OQXdOALSgABT7vgAD4jDfA= From: "Fleischman, Eric" To: , "Wijnen, Bert \(Bert\)" , "Martin Soukup" , "David T. Perkins" X-OriginalArrivalTime: 01 Feb 2005 18:23:50.0555 (UTC) FILETIME=[2D6D6EB0:01C5088B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: quoted-printable Wherever I turn I keep bumping into requirements such as "separation of duties with least privilege" or "security zones" (e.g., subdomains within a deployment with more stringent (or unique) security requirements) which are increasingly being met by techniques such as Role Based Access Control (RBAC) technologies. "Public", "private" and "superuser" can be viewed as possible RBAC roles.=20 Regardless, the point I want to make is that the system we are devising is more powerful -- and more useful -- if it is easily extended to support arbitrary (from the ISMS perspective) RBAC authentication and access control groupings, leveraging one or more of the deployments' existing authentication systems. I do not think that the system should presume or require RBAC. I rather believe that a possible requirement is that it should be configurable to be able to operate in RBAC environments when needed. -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, January 31, 2005 5:10 AM To: 'Wijnen, Bert (Bert)'; 'Martin Soukup'; 'David T. Perkins' Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] People who have always managed their networks using communities need to change their mindset to think in terms of views and contexts and groups. Think about the large number of people who run using the current defaults of "public", "private" and "superuser" communities because the vendors didn't make it easy to change the community names on their devices, or because SNMP security hasn't been their highest priority because there are so many other security problems they need to work on. And if you get the migration from communities to context, views, and groups wrong, they could endanger the security or the manageability of the network. And you expect them to just "grok" VACM from the examples in the appendix of RFC3415? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 2 12:21:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01393; Wed, 2 Feb 2005 12:21:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwOUJ-0006HQ-8Z; Wed, 02 Feb 2005 12:40:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNsB-0005kt-7t; Wed, 02 Feb 2005 12:00:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwNlD-0004Ig-Aq for isms@megatron.ietf.org; Wed, 02 Feb 2005 11:53:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28498 for ; Wed, 2 Feb 2005 11:53:42 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40] helo=smtp2.netlab.nec.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwO3Z-0005Mk-5F for isms@ietf.org; Wed, 02 Feb 2005 12:12:48 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp2.netlab.nec.de (Postfix) with ESMTP id 423EB1F6D6; Wed, 2 Feb 2005 17:55:43 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Feb 2005 17:53:12 +0100 Date: Wed, 02 Feb 2005 17:53:12 +0100 From: Juergen Quittek To: "McDonald, Ira" , isms@ietf.org Subject: Re: [Isms] Let's move forward now Message-ID: <04671C4D15CABB4BED7B8E41@[10.1.1.171]> 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-OriginalArrivalTime: 02 Feb 2005 16:53:12.0112 (UTC) FILETIME=[AE46A300:01C50947] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Ira, I understand that you are getting impatient. But after waiting four months, why don't you wait for just 12 more days until you see the recommendation of the evaluation team. If then you still feel that 'radical departure' is the way to go, feel free to initiate it. 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 01.02.2005 19:07 Uhr +0100 McDonald, Ira wrote: > Hi, > > Four months ago, the authors of three ISMS proposals rushed > out their I-Ds in a few weeks. Since then, nothing productive > has happened. > > The ISMS WG is rapidly headed toward failure. Randy has > noted that the WG is free under IETF rules to ignore the > recommendation of the selection team. But that's simply > impossible, because the odor of ten years wasted on SNMPv2 > and SNMPv3 lingers in the collective memory of the IESG. > > So I suggest a radical departure: > > The authors of the existing three ISMS proposals (and any > others with good ideas) should begin immediately to revise > and reissue their I-Ds, assuming that they will advance > as individual contributions. > > The operator and user communities would be much better served > by this approach than the current 'deer in the headlights' > fatalistic approach. > > 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 > > _______________________________________________ > 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@ietf.org Wed Feb 2 12:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05622; Wed, 2 Feb 2005 12:54:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwP0b-0007Up-7H; Wed, 02 Feb 2005 13:13:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOey-0007en-4a; Wed, 02 Feb 2005 12:51:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwOYP-0005al-Dh for isms@megatron.ietf.org; Wed, 02 Feb 2005 12:44:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04347 for ; Wed, 2 Feb 2005 12:44:32 -0500 (EST) 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.33) id 1CwOqk-000762-HI for isms@ietf.org; Wed, 02 Feb 2005 13:03:39 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 2C07011D9FE; Wed, 2 Feb 2005 09:44:16 -0800 (PST) From: Wes Hardaker To: Juergen Quittek Subject: Re: [Isms] Let's move forward now Organization: Sparta References: <04671C4D15CABB4BED7B8E41@[10.1.1.171]> Date: Wed, 02 Feb 2005 09:44:16 -0800 In-Reply-To: <04671C4D15CABB4BED7B8E41@[10.1.1.171]> (Juergen Quittek's message of "Wed, 02 Feb 2005 17:53:12 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >>>>> On Wed, 02 Feb 2005 17:53:12 +0100, Juergen Quittek said: Juergen> But after waiting four months, why don't you wait for just 12 Juergen> more days until you see the recommendation of the evaluation Juergen> team. Actually, last I heard there was hope it would be done by the end of January. Apparently we're now going with the hard deadline in Feb. At least that one can't slip! Well, technically it could be we technically/officially/legally couldn't talk about the results during the meeting if I remember the whole point behind the cut-off date in the first place. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 2 13:39:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11941; Wed, 2 Feb 2005 13:39:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPhd-0000sw-Bn; Wed, 02 Feb 2005 13:58:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPLg-0004tQ-BX; Wed, 02 Feb 2005 13:35:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPAe-00017e-Mn for isms@megatron.ietf.org; Wed, 02 Feb 2005 13:24:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09451 for ; Wed, 2 Feb 2005 13:24:03 -0500 (EST) Message-Id: <200502021824.NAA09451@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwPT4-0000Bi-63 for isms@ietf.org; Wed, 02 Feb 2005 13:43:10 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005020218233501300katbte>; Wed, 2 Feb 2005 18:23:36 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'McDonald, Ira'" , Subject: RE: [Isms] Let's move forward now Date: Wed, 2 Feb 2005 13:23:31 -0500 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: AcUJS54fKJK0Ed2kQaKHxwI5x4lG4AABWbjw In-Reply-To: <04671C4D15CABB4BED7B8E41@[10.1.1.171]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi, It seems a real waste of resources and time to ask us all to sit on our hands and wait, especially since the team has now missed three(?) deadlines in a row. We have people willing to work on the problems this WG is meant to address, but they are not being utilized. Let's utilize the resources we have, while we have them! I agree with Ira that we should at least keep working while we wait. I'm uncomfortable with Ira's suggestion because I think it will cause people to become entrenched in their positions. Could I suggest a middle path (or a bunch of alternate middle paths)? Can the evaluation team identify areas in each approach that they felt needed more work (after three months of analysis, they should be able to do this even before finishing their full evaluation and report) and then the authors can start to address the concerns to make the discussions at the meeting more fruitful. If how to address the concerns is not clear, the WG can begin to discuss how the concerns might be addressed. Of course, this could be a waste of time and resources if the team has reached agreement that one or more should simply be eliminated from consideration, and the WG plans to adopt only one (or two) proposals for further work. This recommendation to eliminate also should be something that the team could reveal without full details. In that case, the authors of the (proposed) eliminated proposals could spend their time reviewing the other proposals to determine how they might work with the authors of the remaining proposals. [Of course, since the recommendations of a design/evaluation team are supposed to hold no more weight than alternative proposals/evaluations, the authors might want to start preparing defenses of their proposals.] Or the eval team might have decided that the proposals each had good points and bad points and should be merged, and the team should be able to quickly summarize the strengths/weaknesses of each without details, and the rest of the WG could start to work at analyzing how the proposals might be merged. In each of these cases, the WG could be doing something rather than just waiting. I personally am beginning to question my commitment to this WG if the chairs are going to allow deadlines to repeatedly slip, and continually hold back the willing members from doing anything useful. Let us do work! 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: Wednesday, February 02, 2005 11:53 AM > To: McDonald, Ira; isms@ietf.org > Subject: Re: [Isms] Let's move forward now > > Ira, > > I understand that you are getting impatient. > > But after waiting four months, why don't you wait for just > 12 more days until you see the recommendation of the evaluation > team. > > If then you still feel that 'radical departure' is the way to > go, feel free to initiate it. > > 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 01.02.2005 19:07 Uhr +0100 McDonald, Ira wrote: > > > Hi, > > > > Four months ago, the authors of three ISMS proposals rushed > > out their I-Ds in a few weeks. Since then, nothing productive > > has happened. > > > > The ISMS WG is rapidly headed toward failure. Randy has > > noted that the WG is free under IETF rules to ignore the > > recommendation of the selection team. But that's simply > > impossible, because the odor of ten years wasted on SNMPv2 > > and SNMPv3 lingers in the collective memory of the IESG. > > > > So I suggest a radical departure: > > > > The authors of the existing three ISMS proposals (and any > > others with good ideas) should begin immediately to revise > > and reissue their I-Ds, assuming that they will advance > > as individual contributions. > > > > The operator and user communities would be much better served > > by this approach than the current 'deer in the headlights' > > fatalistic approach. > > > > 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 > > > > _______________________________________________ > > 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@ietf.org Wed Feb 2 14:03:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14544; Wed, 2 Feb 2005 14:03:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQ57-0001gD-ML; Wed, 02 Feb 2005 14:22:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPft-0003lZ-6X; Wed, 02 Feb 2005 13:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwPYx-0000Of-3H for isms@megatron.ietf.org; Wed, 02 Feb 2005 13:49:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13201 for ; Wed, 2 Feb 2005 13:49:11 -0500 (EST) 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.33) id 1CwPrL-0001G7-VS for isms@ietf.org; Wed, 02 Feb 2005 14:08:17 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id C597F11D9FE; Wed, 2 Feb 2005 10:49:09 -0800 (PST) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] Let's move forward now Organization: Sparta References: <200502021824.NAA09451@ietf.org> Date: Wed, 02 Feb 2005 10:49:09 -0800 In-Reply-To: <200502021824.NAA09451@ietf.org> (David B. Harrington's message of "Wed, 2 Feb 2005 13:23:31 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 >>>>> On Wed, 2 Feb 2005 13:23:31 -0500, "David B Harrington" said: David> Of course, this could be a waste of time and resources if the David> team has reached agreement that one or more should simply be David> eliminated from consideration, and the WG plans to adopt only David> one (or two) proposals for further work. So another thought would be why don't we request feedback from the WG now about which proposals they think should go forward and see if we can eliminate some now? Options: 1) vote for 1 2) vote for up to 2 3) vote for up to 3 I actually think #2 is useful, but probably #1 will produce better direction assuming there is no dead-even split. We've certainly had enough banter about them all so in theory we should be informed enough about them to make a choice (even if the there is disagreement about their analysis of the costs and benefits of each one). Anyone else feel this would be worthwhile? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 2 14:22:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16722; Wed, 2 Feb 2005 14:22:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQNu-0002IA-8i; Wed, 02 Feb 2005 14:41:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQ4B-0002nM-1o; Wed, 02 Feb 2005 14:21:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQ1C-0001ui-MZ for isms@megatron.ietf.org; Wed, 02 Feb 2005 14:18:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16176 for ; Wed, 2 Feb 2005 14:18:22 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQJa-000287-6j for isms@ietf.org; Wed, 02 Feb 2005 14:37:28 -0500 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 LAA14719; Wed, 2 Feb 2005 11:17:37 -0800 (PST) Received: from xch-nwbh-01.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 j12JHjK12154; Wed, 2 Feb 2005 11:17:45 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by xch-nwbh-01.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Feb 2005 11:17:45 -0800 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] Let's move forward now Date: Wed, 2 Feb 2005 11:17:44 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDBD8@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Let's move forward now Thread-Index: AcUJWqXCD6uBAHyQQFWyHx46JJho6gAALluQ From: "Fleischman, Eric" To: "Wes Hardaker" , X-OriginalArrivalTime: 02 Feb 2005 19:17:45.0372 (UTC) FILETIME=[DFF115C0:01C5095B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable I think that this is a good idea. However, I'd also like to know *why* that person voted as he/she did including the specific problems he/she had with the proposals they did not vote for.=20 -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 So another thought would be why don't we request feedback from the WG now about which proposals they think should go forward and see if we can eliminate some now? Options: 1) vote for 1 2) vote for up to 2 3) vote for up to 3 I actually think #2 is useful, but probably #1 will produce better direction assuming there is no dead-even split. We've certainly had enough banter about them all so in theory we should be informed enough about them to make a choice (even if the there is disagreement about their analysis of the costs and benefits of each one). Anyone else feel this would be worthwhile? --=20 Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 2 14:58:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21301; Wed, 2 Feb 2005 14:58:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQwI-0003f3-Dd; Wed, 02 Feb 2005 15:17:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQbR-0004bU-21; Wed, 02 Feb 2005 14:55:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQU2-0001jp-2Q for isms@megatron.ietf.org; Wed, 02 Feb 2005 14:48:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19632 for ; Wed, 2 Feb 2005 14:48:09 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQmQ-0003DB-Jg for isms@ietf.org; Wed, 02 Feb 2005 15:07:16 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 5B802E77C; Wed, 2 Feb 2005 20:47:35 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 00733-04; Wed, 2 Feb 2005 20:47:34 +0100 (CET) Received: from james (Ibe30.i.pppool.de [85.73.190.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 3B7B5DF27; Wed, 2 Feb 2005 20:47:34 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CwQTM-0000cS-BW; Wed, 02 Feb 2005 20:47:32 +0100 Date: Wed, 2 Feb 2005 20:47:32 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Let's move forward now Message-ID: <20050202194732.GA2343@james> Mail-Followup-To: Wes Hardaker , ietfdbh@comcast.net, isms@ietf.org References: <200502021824.NAA09451@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de 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 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 On Wed, Feb 02, 2005 at 10:49:09AM -0800, Wes Hardaker wrote: > So another thought would be why don't we request feedback from the WG > now about which proposals they think should go forward and see if we > can eliminate some now? > > Options: > 1) vote for 1 > 2) vote for up to 2 > 3) vote for up to 3 The IETF generally does not vote and I think there are some good reasons for this. What I personally would find useful is information how the various people speaking up here rank the proposals and the rationale behind their ranking. The point would be to gather opinions as just that - opinions. We should not try to argue why we have different results. I would just be interested to understand what others are thinking and why. For this to work, people would have to send their opinion statement to some trusted party who will collect them and post them together after a week or so. This would help to get unbiased and original opinions. Not sure whether the result will really help - but it would at least an interesting approach to gather opinions and lines of reasoning while we continue to wait to hear something from the evaluation team. /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@ietf.org Wed Feb 2 15:01:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21804; Wed, 2 Feb 2005 15:01:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwQzV-0003kW-3B; Wed, 02 Feb 2005 15:20:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQg4-0006qt-R6; Wed, 02 Feb 2005 15:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwQbw-0005AD-FO for isms@megatron.ietf.org; Wed, 02 Feb 2005 14:56:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20993 for ; Wed, 2 Feb 2005 14:56:20 -0500 (EST) 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.33) id 1CwQuK-0003YU-UN for isms@ietf.org; Wed, 02 Feb 2005 15:15:27 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id EF73D11D9FE; Wed, 2 Feb 2005 11:56:15 -0800 (PST) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] Let's move forward now Organization: Sparta References: <200502021824.NAA09451@ietf.org> <20050202194732.GA2343@james> Date: Wed, 02 Feb 2005 11:56:15 -0800 In-Reply-To: <20050202194732.GA2343@james> (Juergen Schoenwaelder's message of "Wed, 2 Feb 2005 20:47:32 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab >>>>> On Wed, 2 Feb 2005 20:47:32 +0100, Juergen Schoenwaelder said: Juergen> The IETF generally does not vote and I think there are some good Juergen> reasons for this. Vote was a poor choice of words, I agree. My point was to figure out if one or more of the proposals could be discarded due to consensus not to head that direction. As is, I have heard from a number of people making arguments but I'm uncertain where the general consensus lies because we've been arguing more for fundamental concepts and less for a particular solution. Given that we have to pick a solution, it would seem worthwhile to select which of the options best incorporates these features that are needed by the peopling doing the arguing. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 2 15:34:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25990; Wed, 2 Feb 2005 15:34:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwRVZ-0004lx-0y; Wed, 02 Feb 2005 15:53:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwR9H-0002KI-70; Wed, 02 Feb 2005 15:30:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwR6O-00081h-Ev for isms@megatron.ietf.org; Wed, 02 Feb 2005 15:27:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25166 for ; Wed, 2 Feb 2005 15:27:48 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CwROo-0004Vx-6h for isms@ietf.org; Wed, 02 Feb 2005 15:46:55 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j12KRhD1013761 for ; Wed, 2 Feb 2005 15:27:43 -0500 (EST) Message-Id: <200502022027.j12KRhD1013761@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Let's move forward now In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Wed, 02 Feb 2005 15:27:42 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad >Vote was a poor choice of words, I agree. My point was to figure out >if one or more of the proposals could be discarded due to consensus >not to head that direction. Okay, well, in the interest of moving forward .... I suggest that we eliminate the TLS proposal from consideration. Comments? --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 8 18:25:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21251; Tue, 8 Feb 2005 18:25:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyf35-00009g-2g; Tue, 08 Feb 2005 18:45:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyecX-0003Xq-NK; Tue, 08 Feb 2005 18:18:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyeTU-0004y3-CQ for isms@megatron.ietf.org; Tue, 08 Feb 2005 18:08:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14224 for ; Tue, 8 Feb 2005 18:08:49 -0500 (EST) Message-Id: <200502082308.SAA14224@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyen9-0006nJ-PR for isms@ietf.org; Tue, 08 Feb 2005 18:29:13 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005020823081801500o7cgie>; Tue, 8 Feb 2005 23:08:18 +0000 From: "David B Harrington" To: "'Ken Hornstein'" , Subject: RE: [Isms] Let's move forward now Date: Tue, 8 Feb 2005 18:08:12 -0500 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: <200502022027.j12KRhD1013761@ginger.cmf.nrl.navy.mil> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJZqPWEqg37Tq5QNyLQjpaqtYLkgEwO+rQ X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: 7bit Hi, I made the suggestion to drop the TLS proposal at the last meeting. I do have hesitations about discarding this proposal however. Here are my thoughts. Security is only as strong as its weakest link, and for device management, there are multiple links - interactive CLI, CLI scripting, web-based management (html/http), the emerging netconf, snmpv1, snmpv2c, and snmpv3. To build one of these management interfaces to be dramatically more secure than the others, without being able to fully retire the others, simply makes that choice not the weakest link; it doesn't help to balance the security across all the management interfaces. CLI and CLI scripting are frequently secured with SSH, and netconf plans to utilize SSH as the preferred "application transport", so TLS will be used to secure these interfaces. Web-based mgmt utilizes HTTP/SSL (or TLS 1.0). Each of these approaches "outsources" the message security to the transport layer, and supplements that with a session-based user-authentication (for access control) at a higher layer. For the best integration of SNMP security with the security used for other management interfaces, it would seem to make sense to also "outsource" the message security to the transport layer, and then supplement that with session-based user-authentication for access control. Either EUSM or SBSM could be used to provide the session-based user authentication for access control. One of the charter goals is to "maximize useability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible." Utilizing the same security approaches for SNMP as are used for CLI, CLI scripting, netconf, and web-based mgmt certainly eases the operational and deployment costs, and given that the operators indicated SSH as the preferred mechanism for netconf, I expect they would also support deploying it for SNMP. Utilizing the same security mechanisms that are already in the devices in support of secure CLI, CLI scripting, and web-based mgmt helps to minimize the implementation costs for vendors, and could minimize time to deployment. Of course, to utilize the same security mechanisms will require supporting a TCP transport for SNMP, something already specified in RFC 3430, or adding support for something similar to DTLS. To utilize SSH user-authentication (both centralized and local) would require adding an SNMP security model to leverage those. Again either EUSM or SBSM might be able to be adapted to provide this. I believe the long-term benefits of differentiating transport security and access control security, and balancing the security across management interfaces, would justify keeping the TLS approach on the table. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein > Sent: Wednesday, February 02, 2005 3:28 PM > To: isms@ietf.org > Subject: Re: [Isms] Let's move forward now > > >Vote was a poor choice of words, I agree. My point was to figure out > >if one or more of the proposals could be discarded due to consensus > >not to head that direction. > > Okay, well, in the interest of moving forward .... I suggest that we > eliminate the TLS proposal from consideration. Comments? > > --Ken > > _______________________________________________ > 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@ietf.org Tue Feb 8 19:09:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24261; Tue, 8 Feb 2005 19:09:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyfk5-00017g-AW; Tue, 08 Feb 2005 19:30:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyfPa-0007XE-W3; Tue, 08 Feb 2005 19:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyfGy-0005pY-Sa for isms@megatron.ietf.org; Tue, 08 Feb 2005 19:00:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23535 for ; Tue, 8 Feb 2005 18:59:57 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyfaf-0000tb-LW for isms@ietf.org; Tue, 08 Feb 2005 19:20:22 -0500 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 j18NxApt011979; Tue, 8 Feb 2005 15:59:10 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76V88D>; Tue, 8 Feb 2005 15:59:41 -0800 Message-ID: From: "McDonald, Ira" To: "'ietfdbh@comcast.net'" , "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Let's move forward now Date: Tue, 8 Feb 2005 15:59:40 -0800 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: 37af5f8fbf6f013c5b771388e24b09e7 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Hi, I agree with David's rationale for keeping TLS on the table. Bear in mind that currently RADIUS has no mind-share at all as an authentication mechanism for systems management but (as David observes below) SSL/TLS has all the marbles. 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 David B Harrington Sent: Tuesday, February 08, 2005 6:08 PM To: 'Ken Hornstein'; isms@ietf.org Subject: RE: [Isms] Let's move forward now Hi, I made the suggestion to drop the TLS proposal at the last meeting. I do have hesitations about discarding this proposal however. Here are my thoughts. Security is only as strong as its weakest link, and for device management, there are multiple links - interactive CLI, CLI scripting, web-based management (html/http), the emerging netconf, snmpv1, snmpv2c, and snmpv3. To build one of these management interfaces to be dramatically more secure than the others, without being able to fully retire the others, simply makes that choice not the weakest link; it doesn't help to balance the security across all the management interfaces. CLI and CLI scripting are frequently secured with SSH, and netconf plans to utilize SSH as the preferred "application transport", so TLS will be used to secure these interfaces. Web-based mgmt utilizes HTTP/SSL (or TLS 1.0). Each of these approaches "outsources" the message security to the transport layer, and supplements that with a session-based user-authentication (for access control) at a higher layer. For the best integration of SNMP security with the security used for other management interfaces, it would seem to make sense to also "outsource" the message security to the transport layer, and then supplement that with session-based user-authentication for access control. Either EUSM or SBSM could be used to provide the session-based user authentication for access control. One of the charter goals is to "maximize useability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible." Utilizing the same security approaches for SNMP as are used for CLI, CLI scripting, netconf, and web-based mgmt certainly eases the operational and deployment costs, and given that the operators indicated SSH as the preferred mechanism for netconf, I expect they would also support deploying it for SNMP. Utilizing the same security mechanisms that are already in the devices in support of secure CLI, CLI scripting, and web-based mgmt helps to minimize the implementation costs for vendors, and could minimize time to deployment. Of course, to utilize the same security mechanisms will require supporting a TCP transport for SNMP, something already specified in RFC 3430, or adding support for something similar to DTLS. To utilize SSH user-authentication (both centralized and local) would require adding an SNMP security model to leverage those. Again either EUSM or SBSM might be able to be adapted to provide this. I believe the long-term benefits of differentiating transport security and access control security, and balancing the security across management interfaces, would justify keeping the TLS approach on the table. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein > Sent: Wednesday, February 02, 2005 3:28 PM > To: isms@ietf.org > Subject: Re: [Isms] Let's move forward now > > >Vote was a poor choice of words, I agree. My point was to figure out > >if one or more of the proposals could be discarded due to consensus > >not to head that direction. > > Okay, well, in the interest of moving forward .... I suggest that we > eliminate the TLS proposal from consideration. Comments? > > --Ken > > _______________________________________________ > 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@ietf.org Tue Feb 8 19:28:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25186; Tue, 8 Feb 2005 19:28:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyg2H-0001Qy-Ug; Tue, 08 Feb 2005 19:48:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyfdp-0002Ty-Or; Tue, 08 Feb 2005 19:23:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyfcP-0001sL-P6 for isms@megatron.ietf.org; Tue, 08 Feb 2005 19:22:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24839 for ; Tue, 8 Feb 2005 19:22:06 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyfw7-0001Js-2H for isms@ietf.org; Tue, 08 Feb 2005 19:42:31 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j190CMFx004765 for ; Tue, 8 Feb 2005 19:12:22 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j190CJFx004728 for ; Tue, 8 Feb 2005 19:12:20 -0500 (EST) Subject: RE: [Isms] Let's move forward now MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Feb 2005 02:22:04 +0200 Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Thread-Topic: [Isms] Let's move forward now Thread-Index: AcUJZqPWEqg37Tq5QNyLQjpaqtYLkgEwO+rQAAUwd1A= From: "Romascanu, Dan \(Dan\)" To: , "Ken Hornstein" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable FWIW, I am also in favor of keeping TLS on the table for now. Out of the = solutions under discussion it looks to me like the TLS-based one is = closer to meet the goal of providing an acceptable security mechanism = for different management interfaces, based on a technology quite well = understood and deployed. Eliminating it will make it much harder to = integrate the transport, security, data modeling, and access control in = the future. Regards, Dan > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org]On Behalf Of David B Harrington > Sent: 09 February, 2005 1:08 AM > To: 'Ken Hornstein'; isms@ietf.org > Subject: RE: [Isms] Let's move forward now=20 >=20 >=20 > Hi, >=20 > I made the suggestion to drop the TLS proposal at the last meeting. >=20 > I do have hesitations about discarding this proposal however. Here are > my thoughts. >=20 > Security is only as strong as its weakest link, and for device > management, there are multiple links - interactive CLI, CLI scripting, > web-based management (html/http), the emerging netconf, snmpv1, > snmpv2c, and snmpv3. To build one of these management interfaces to be > dramatically more secure than the others, without being able to fully > retire the others, simply makes that choice not the weakest link; it > doesn't help to balance the security across all the management > interfaces. >=20 > CLI and CLI scripting are frequently secured with SSH, and netconf > plans to utilize SSH as the preferred "application transport", so TLS > will be used to secure these interfaces. Web-based mgmt utilizes > HTTP/SSL (or TLS 1.0). Each of these approaches "outsources" the > message security to the transport layer, and supplements that with a > session-based user-authentication (for access control) at a higher > layer. >=20 > For the best integration of SNMP security with the security used for > other management interfaces, it would seem to make sense to also > "outsource" the message security to the transport layer, and then > supplement that with session-based user-authentication for access > control. Either EUSM or SBSM could be used to provide the > session-based user authentication for access control. >=20 > One of the charter goals is to "maximize useability in operational > environments to achieve high deployment success and at the same time > minimize implementation and deployment costs to minimize the time > until deployment is possible." >=20 > Utilizing the same security approaches for SNMP as are used for CLI, > CLI scripting, netconf, and web-based mgmt certainly eases the > operational and deployment costs, and given that the operators > indicated SSH as the preferred mechanism for netconf, I expect they > would also support deploying it for SNMP. >=20 > Utilizing the same security mechanisms that are already in the devices > in support of secure CLI, CLI scripting, and web-based mgmt helps to > minimize the implementation costs for vendors, and could minimize time > to deployment. >=20 > Of course, to utilize the same security mechanisms will require > supporting a TCP transport for SNMP, something already specified in > RFC 3430, or adding support for something similar to DTLS. To utilize > SSH user-authentication (both centralized and local) would require > adding an SNMP security model to leverage those. Again either EUSM or > SBSM might be able to be adapted to provide this. >=20 > I believe the long-term benefits of differentiating transport security > and access control security, and balancing the security across > management interfaces, would justify keeping the TLS approach on the > table. >=20 > David Harrington > dbharrington@comcast.net=20 >=20 > > -----Original Message----- > > From: isms-bounces@lists.ietf.org=20 > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein > > Sent: Wednesday, February 02, 2005 3:28 PM > > To: isms@ietf.org > > Subject: Re: [Isms] Let's move forward now=20 > >=20 > > >Vote was a poor choice of words, I agree. My point was to figure > out > > >if one or more of the proposals could be discarded due to consensus > > >not to head that direction. > >=20 > > Okay, well, in the interest of moving forward .... I suggest that we > > eliminate the TLS proposal from consideration. Comments? > >=20 > > --Ken > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=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@ietf.org Thu Feb 10 13:47:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25055; Thu, 10 Feb 2005 13:47:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJg5-0002bj-9B; Thu, 10 Feb 2005 14:08:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJJz-00025N-O9; Thu, 10 Feb 2005 13:45:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJE8-0000ll-Ax for isms@megatron.ietf.org; Thu, 10 Feb 2005 13:39:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24543 for ; Thu, 10 Feb 2005 13:39:41 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJYB-0002PA-Gg for isms@ietf.org; Thu, 10 Feb 2005 14:00:28 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j1AIdae5023374 for ; Thu, 10 Feb 2005 13:39:37 -0500 (EST) Message-Id: <200502101839.j1AIdae5023374@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Let's move forward now In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Thu, 10 Feb 2005 13:39:37 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Everyone, I had gotten the feeling that there might be consensus to take TLS off of the table from the last WG meeting. That's really my only reason for the suggestion (I know a couple of people asked me privately what my reasoning was). Clearly, there is _not_ consensus to do so, so TLS will still stay on the table for now. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 14 11:53:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21116; Mon, 14 Feb 2005 11:53:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0joB-0006lV-4R; Mon, 14 Feb 2005 12:14:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jSW-0007y8-OC; Mon, 14 Feb 2005 11:52:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0jPX-0007O9-Lw for isms@megatron.ietf.org; Mon, 14 Feb 2005 11:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20747 for ; Mon, 14 Feb 2005 11:49:20 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40] helo=smtp2.netlab.nec.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0jkO-0006eA-Sk for isms@ietf.org; Mon, 14 Feb 2005 12:10:58 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp2.netlab.nec.de (Postfix) with ESMTP id 4CCB6DC3B for ; Mon, 14 Feb 2005 17:54:20 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Feb 2005 17:48:50 +0100 Date: Mon, 14 Feb 2005 17:48:56 +0100 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-OriginalArrivalTime: 14 Feb 2005 16:48:50.0795 (UTC) FILETIME=[0F79D3B0:01C512B5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Isms] proposal comparison I-D 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Dear all, The evaluation team has completed its work. It took longer than expected (as so many IETF tasks), but now they delivered us a comparison of the three proposals and give a recommendation on how the WG should proceed. I thank all team members for their excellent work, and Randy and Lakshminath for acting as document editors. The I-D was just submitted today. For all who do not want to wait until it gets posted officially by the end of the week, I put a copy at: Please have a look at it and let's start a (certainly controversial) discussion on it as soon as possible. The recommendations in section 3 provide a lot of useful input to shaping a WG agenda. 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@ietf.org Mon Feb 14 19:50:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09583; Mon, 14 Feb 2005 19:50:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0r4d-0004oV-PJ; Mon, 14 Feb 2005 20:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0qiv-0002wt-P0; Mon, 14 Feb 2005 19:37:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0qf6-000287-Ld for isms@megatron.ietf.org; Mon, 14 Feb 2005 19:33:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07886 for ; Mon, 14 Feb 2005 19:33:50 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0qyP-0003u0-8T for isms@ietf.org; Mon, 14 Feb 2005 19:53:54 -0500 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 j1F0Vdxx019663; Mon, 14 Feb 2005 16:31:39 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76X054>; Mon, 14 Feb 2005 16:31:41 -0800 Message-ID: From: "McDonald, Ira" To: "'Juergen Quittek'" , isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Date: Mon, 14 Feb 2005 16:31:34 -0800 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: d0bdc596f8dd1c226c458f0b4df27a88 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Hi, Well written document! I liked the architectural perspective on the three ISMS proposals. But the revised I-D cutoff for IETF 62 passed today. That means an I-D publication blackout until mid-March. So it's difficult to see how this working group doesn't fail. Are the minutes of the ISMS WG meeting at IETF 62 to constitute the sole proof that the WG has 'selected' a proposal by the end-of-March? Especially in light of the evaluation team's recommendation that EUSM be substantially modified to add features from both of the other proposals? All - please read the evaluation team's short cogent document soon - please minimize email rhetoric on second-order features and stick to the architectural guidance on first-order features in the evaluation I-D. 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 Juergen Quittek Sent: Monday, February 14, 2005 11:49 AM To: isms@ietf.org Subject: [Isms] proposal comparison I-D Dear all, The evaluation team has completed its work. It took longer than expected (as so many IETF tasks), but now they delivered us a comparison of the three proposals and give a recommendation on how the WG should proceed. I thank all team members for their excellent work, and Randy and Lakshminath for acting as document editors. The I-D was just submitted today. For all who do not want to wait until it gets posted officially by the end of the week, I put a copy at: Please have a look at it and let's start a (certainly controversial) discussion on it as soon as possible. The recommendations in section 3 provide a lot of useful input to shaping a WG agenda. 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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 14 20:44:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13786; Mon, 14 Feb 2005 20:44:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0s6k-0006PK-JW; Mon, 14 Feb 2005 21:06:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0rke-0000PY-Rv; Mon, 14 Feb 2005 20:43:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0rit-0000Dx-R8 for isms@megatron.ietf.org; Mon, 14 Feb 2005 20:41:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13640 for ; Mon, 14 Feb 2005 20:41:53 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0s3p-0006LD-V3 for isms@ietf.org; Mon, 14 Feb 2005 21:03:34 -0500 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 j1F1fMgG023717; Mon, 14 Feb 2005 17:41:22 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1F1fRPo004832; Mon, 14 Feb 2005 17:41:28 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1F1fR7H004829; Mon, 14 Feb 2005 17:41:27 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 14 Feb 2005 17:41:27 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "McDonald, Ira" Subject: RE: [Isms] proposal comparison I-D In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f HI, I couldn't understand "So it's difficult to see how this working group doesn't fail." Would you elaborate. On Mon, 14 Feb 2005, McDonald, Ira wrote: > Hi, > > Well written document! I liked the architectural perspective > on the three ISMS proposals. > > But the revised I-D cutoff for IETF 62 passed today. That > means an I-D publication blackout until mid-March. > > So it's difficult to see how this working group doesn't fail. > Are the minutes of the ISMS WG meeting at IETF 62 to constitute > the sole proof that the WG has 'selected' a proposal by the > end-of-March? Especially in light of the evaluation team's > recommendation that EUSM be substantially modified to add > features from both of the other proposals? > > All - please read the evaluation team's short cogent document > soon - please minimize email rhetoric on second-order features > and stick to the architectural guidance on first-order features > in the evaluation I-D. > > Cheers, > - Ira Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 14 21:47:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17696; Mon, 14 Feb 2005 21:47:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0t4z-0007VN-DE; Mon, 14 Feb 2005 22:08:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0si6-0006TW-5j; Mon, 14 Feb 2005 21:45:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0shQ-0006Ma-Qm for isms@megatron.ietf.org; Mon, 14 Feb 2005 21:44:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17560 for ; Mon, 14 Feb 2005 21:44:26 -0500 (EST) Message-Id: <200502150244.VAA17560@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0t2O-0007SN-9a for isms@ietf.org; Mon, 14 Feb 2005 22:06:08 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005021502435701200f81f7e>; Tue, 15 Feb 2005 02:43:57 +0000 From: "David B Harrington" To: "'McDonald, Ira'" , "'Juergen Quittek'" , Subject: RE: [Isms] proposal comparison I-D Date: Mon, 14 Feb 2005 21:43:56 -0500 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: AcUS9rGNcQI4nN/XTxOTjlVqPILfxQADzEPg X-Spam-Score: 0.1 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Hi Ira, Juergen said the document was submitted today, and it was apparently received before the cutoff time, since it is now reflected on the charter page. Based on the charter deadlines, the WG still has through March to make a "decision about which solution approach the WG will focus its efforts on." We also have until the end of March to recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time. I think we will be able to reach consensus on a technical direction by that time. While there are benefits to the TLSM proposal, I have no issue with it being put aside to focus on the EUSM model. The TLSM approach can always be written as a future alternative if desired. The EUSM model, with the eval-team suggested changes to make it more modular, should be flexible enough to meet the needs of many industry segments. 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: Monday, February 14, 2005 7:32 PM > To: 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] proposal comparison I-D > > Hi, > > Well written document! I liked the architectural perspective > on the three ISMS proposals. > > But the revised I-D cutoff for IETF 62 passed today. That > means an I-D publication blackout until mid-March. > > So it's difficult to see how this working group doesn't fail. > Are the minutes of the ISMS WG meeting at IETF 62 to constitute > the sole proof that the WG has 'selected' a proposal by the > end-of-March? Especially in light of the evaluation team's > recommendation that EUSM be substantially modified to add > features from both of the other proposals? > > All - please read the evaluation team's short cogent document > soon - please minimize email rhetoric on second-order features > and stick to the architectural guidance on first-order features > in the evaluation I-D. > > 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 Juergen Quittek > Sent: Monday, February 14, 2005 11:49 AM > To: isms@ietf.org > Subject: [Isms] proposal comparison I-D > > > Dear all, > > The evaluation team has completed its work. > It took longer than expected (as so many IETF tasks), > but now they delivered us a comparison of the three proposals > and give a recommendation on how the WG should proceed. > > I thank all team members for their excellent work, and > Randy and Lakshminath for acting as document editors. > > The I-D was just submitted today. For all who do not want > to wait until it gets posted officially by the end of the > week, I put a copy at: > > roposal-compar > ison-00.txt> > > Please have a look at it and let's start a (certainly > controversial) discussion on it as soon as possible. > > The recommendations in section 3 provide a lot > of useful input to shaping a WG agenda. > > 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 > > _______________________________________________ > 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@ietf.org Tue Feb 15 08:10:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28312; Tue, 15 Feb 2005 08:10:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12o6-0004EP-4C; Tue, 15 Feb 2005 08:32:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D12PA-0000iq-5Y; Tue, 15 Feb 2005 08:06:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D12LI-0008UI-Be for isms@megatron.ietf.org; Tue, 15 Feb 2005 08:02:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27389 for ; Tue, 15 Feb 2005 08:02:14 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D12gJ-0003xI-HS for isms@ietf.org; Tue, 15 Feb 2005 08:24:00 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kp.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1FD1e019200 for ; Tue, 15 Feb 2005 08:01:41 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLMDR3>; Tue, 15 Feb 2005 08:01:42 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B959@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Date: Tue, 15 Feb 2005 08:01:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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="===============0009260203==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0009260203== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5135E.779E2DBF" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5135E.779E2DBF Content-Type: text/plain All, In section 3.5 of the proposal evaluation, a comparison between the key provisioning for an external authentication source (AAA server) and the goal of ISMS is made. It should be noted that the provisioning of a single key per device rather than a key per-user-per-device is of a significantly different complexity. Also, there are numerous solutions and solutions in progress to remove the need for this communication key provisioning for standard external authentication protocols (e.g. Kerberos, RADIUS), and this should appropriately be solved in the context of the AAA protocol and not SNMP, IMO. Martin. ------_=_NextPart_001_01C5135E.779E2DBF Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] proposal comparison I-D

All,

In section 3.5 of the proposal evaluation, a = comparison between the key provisioning for an external authentication = source (AAA server) and the goal of ISMS is made. It should be noted = that the provisioning of a single key per device rather than a key = per-user-per-device is of a significantly different complexity. Also, = there are numerous solutions and solutions in progress to remove the = need for this communication key provisioning for standard external = authentication protocols (e.g. Kerberos, RADIUS), and this should = appropriately be solved in the context of the AAA protocol and not = SNMP, IMO.

Martin.

------_=_NextPart_001_01C5135E.779E2DBF-- --===============0009260203== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0009260203==-- From isms-bounces@ietf.org Tue Feb 15 13:23:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07217; Tue, 15 Feb 2005 13:23:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17hR-00084s-K3; Tue, 15 Feb 2005 13:45:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15L3-0005o0-LC; Tue, 15 Feb 2005 11:14:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D14gS-0001yy-12; Tue, 15 Feb 2005 10:32:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13648; Tue, 15 Feb 2005 10:32:13 -0500 (EST) Message-Id: <200502151532.KAA13648@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 15 Feb 2005 10:32:13 -0500 Cc: isms@ietf.org Subject: [Isms] I-D ACTION:draft-ietf-isms-proposal-comparison-00.txt 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Integrated Security Model for SNMP Working Group of the IETF. Title : Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol) Author(s) : U. Blumenthal, et al. Filename : draft-ietf-isms-proposal-comparison-00.txt Pages : 21 Date : 2005-2-14 Although the Simple Network Management Protocol (SNMPv3) is secure, operators and administrators have found that deploying it can be problematic in large distributions, due to a lack of integration between its User-Based Security Model (USM) and other authentication and user management infrastructure. This memo contains an evaluation of three proposals for an integrated security model for SNMP, and, based on these proposals, suggests how the ISMS (Integrated Security Model for SNMP) working group might move forward. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-isms-proposal-comparison-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-isms-proposal-comparison-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-2-15103724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-isms-proposal-comparison-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-isms-proposal-comparison-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-2-15103724.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --NextPart-- From isms-bounces@ietf.org Tue Feb 15 15:17:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06654; Tue, 15 Feb 2005 15:17:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19U1-0008Vl-Pw; Tue, 15 Feb 2005 15:39:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18kh-0001vm-7a; Tue, 15 Feb 2005 14:52:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18HY-0001VE-D3 for isms@megatron.ietf.org; Tue, 15 Feb 2005 14:22:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25199 for ; Tue, 15 Feb 2005 14:22:47 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D18ce-0005NL-GD for isms@ietf.org; Tue, 15 Feb 2005 14:44:36 -0500 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 j1FJME2G009890; Tue, 15 Feb 2005 11:22:14 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76YJTJ>; Tue, 15 Feb 2005 11:22:12 -0800 Message-ID: From: "McDonald, Ira" To: "'ietfdbh@comcast.net'" , "McDonald, Ira" , "'Juergen Quittek'" , isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Date: Tue, 15 Feb 2005 11:22:02 -0800 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: 20f22c03b5c66958bff5ef54fcda6e48 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Hi David Harrington and David Perkins, My concerns that this WG may fail are based on: (a) some WG participants (but not most) will meet in person in early March at IETF 62; (b) minutes from IETF face-to-face meetings are usually very slow to appear; (c) other members of this mailing list won't know what concensus, if any, was reached at IETF 62 until mid-March; (d) revising the WG charter based entirely on email threads (without a new version of the EUSM proposal per suggestions of the evaluation team) seems dubious. Chairs - is the IESG likely to accept a recharter without any I-D to point at documenting the "decision about approach"? Is the evaluation I-D itself sufficient? The changes that were suggested to EUSM are certainly not cosmetic. Again - I hope this working group succeeds - I really believe that this is the 'last chance' for SNMPv3 to start getting _deployed_ by customers. Proprietary HTTP, CLI, OASIS WSDM, and too many other choices are already competing here (and they can all use TLS). My colleagues in the network printer industry (working on IEEE/ISTO PWG standards) keep telling me that their upper management say "SNMP is dead". The development funds seem to be going toward Web solutions: (a) Proprietary HTTP forms/etc.; or (b) SOAP over HTTP (OASIS WSDM, etc.). And proprietary HTTP solutions are the only ones currently shipping from any printer vendor. This is not good. 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: Monday, February 14, 2005 9:44 PM To: 'McDonald, Ira'; 'Juergen Quittek'; isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Hi Ira, Juergen said the document was submitted today, and it was apparently received before the cutoff time, since it is now reflected on the charter page. Based on the charter deadlines, the WG still has through March to make a "decision about which solution approach the WG will focus its efforts on." We also have until the end of March to recharter to include publication goals or shutdown if no consensus on a technical direction is reached by this time. I think we will be able to reach consensus on a technical direction by that time. While there are benefits to the TLSM proposal, I have no issue with it being put aside to focus on the EUSM model. The TLSM approach can always be written as a future alternative if desired. The EUSM model, with the eval-team suggested changes to make it more modular, should be flexible enough to meet the needs of many industry segments. 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: Monday, February 14, 2005 7:32 PM > To: 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] proposal comparison I-D > > Hi, > > Well written document! I liked the architectural perspective > on the three ISMS proposals. > > But the revised I-D cutoff for IETF 62 passed today. That > means an I-D publication blackout until mid-March. > > So it's difficult to see how this working group doesn't fail. > Are the minutes of the ISMS WG meeting at IETF 62 to constitute > the sole proof that the WG has 'selected' a proposal by the > end-of-March? Especially in light of the evaluation team's > recommendation that EUSM be substantially modified to add > features from both of the other proposals? > > All - please read the evaluation team's short cogent document > soon - please minimize email rhetoric on second-order features > and stick to the architectural guidance on first-order features > in the evaluation I-D. > > 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 Juergen Quittek > Sent: Monday, February 14, 2005 11:49 AM > To: isms@ietf.org > Subject: [Isms] proposal comparison I-D > > > Dear all, > > The evaluation team has completed its work. > It took longer than expected (as so many IETF tasks), > but now they delivered us a comparison of the three proposals > and give a recommendation on how the WG should proceed. > > I thank all team members for their excellent work, and > Randy and Lakshminath for acting as document editors. > > The I-D was just submitted today. For all who do not want > to wait until it gets posted officially by the end of the > week, I put a copy at: > > roposal-compar > ison-00.txt> > > Please have a look at it and let's start a (certainly > controversial) discussion on it as soon as possible. > > The recommendations in section 3 provide a lot > of useful input to shaping a WG agenda. > > 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 > > _______________________________________________ > 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@ietf.org Tue Feb 15 15:32:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08753; Tue, 15 Feb 2005 15:32:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19iT-0000ZU-NN; Tue, 15 Feb 2005 15:54:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19Ao-0003HZ-3w; Tue, 15 Feb 2005 15:19:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18sa-0007En-Kh for isms@megatron.ietf.org; Tue, 15 Feb 2005 15:01:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02953 for ; Tue, 15 Feb 2005 15:01:03 -0500 (EST) Message-Id: <200502152001.PAA02953@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Df-0007gQ-Mg for isms@ietf.org; Tue, 15 Feb 2005 15:22:53 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20050215200029015006j0obe>; Tue, 15 Feb 2005 20:00:29 +0000 From: "David B Harrington" To: "'McDonald, Ira'" , "'Juergen Quittek'" , Subject: RE: [Isms] proposal comparison I-D Date: Tue, 15 Feb 2005 15:00:27 -0500 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: AcUTk6ie4wHYs8FfRTSaWnCiJlV/fwAAF/dw X-Spam-Score: 0.1 (/) X-Scan-Signature: e1924de3f9fb68e58c31920136007eb1 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: 7bit Hi, Regarding pronouncements that SNMP is dead - I've heard it so many times in the IETF, but so seldom from buying customers, that I don't put a lot of stock in such pronouncements. Which is not to say that valid criticisms of SNMP shouldn't be paid attention to; SNMP has been around for a long time and is used in ways it was not designed for, and hasn't kept up with related advances in technology. I think it is important to recognize that management interfaces for printers are normally for element management, not network, service, or business process management. Generally one does not need to compare the status of the paper tray across printers. For monitoring a specific device status, a CLI or web-based interface is typically fine. SNMP isn't required for that use-case (although traps could certainly be useful). While many TLS-based management interfaces are available, most do not have what has really made SNMP successful - a vendor-neutral schema for management data, widely-deployed industry-standard data models for consistency across multiple vendors' products, a widely-deployed vendor-neutral protocol for remote data manipulation, and a wide selection of value-add applications capable of monitoring (and sometimes managing) network/service/business functionality and not just individual devices. Leveraging TLS could certainly be a good thing, it also introduces problems that would need to be resolved (just as all the proposals will introduce problems to be resolved). Regarding whether we fail or not, consdier this: A) Bert Wijnen will be among the missing at IETF62, and his opinion will probably carry a great deal of weight in deciding whether our consensus on direction justifies being rechartered. B) the chairs can turn around the minutes very quickly when necessary. C) consensus is determined by the whole WG, not just meeting attendees; while face-to-face contact can help bring people together for negotiating positions and reaching compromise, the mailing list is required to determine WG consensus. D) our goal is to decide on a direction, not to have a finished document by the end of March. I think it would make a lot of sense to recharter without having the EUSM republished first (although having an updated revision would be nice). I look rather optimistically at what this WG has achieved so far, and what we will yet achieve. David Harrington dbharrington@comcast.net > -----Original Message----- > From: McDonald, Ira [mailto:imcdonald@sharplabs.com] > Sent: Tuesday, February 15, 2005 2:22 PM > To: 'ietfdbh@comcast.net'; McDonald, Ira; 'Juergen Quittek'; > isms@ietf.org > Subject: RE: [Isms] proposal comparison I-D > > Hi David Harrington and David Perkins, > > My concerns that this WG may fail are based on: > (a) some WG participants (but not most) will meet in person in > early March at IETF 62; > (b) minutes from IETF face-to-face meetings are usually very > slow to appear; > (c) other members of this mailing list won't know what concensus, > if any, was reached at IETF 62 until mid-March; > (d) revising the WG charter based entirely on email threads > (without a new version of the EUSM proposal per suggestions > of the evaluation team) seems dubious. > > Chairs - is the IESG likely to accept a recharter without > any I-D to point at documenting the "decision about approach"? > Is the evaluation I-D itself sufficient? > > The changes that were suggested to EUSM are certainly not > cosmetic. > > Again - I hope this working group succeeds - I really believe > that this is the 'last chance' for SNMPv3 to start getting > _deployed_ by customers. Proprietary HTTP, CLI, OASIS WSDM, > and too many other choices are already competing here (and they > can all use TLS). > > My colleagues in the network printer industry (working on > IEEE/ISTO PWG standards) keep telling me that their upper > management say "SNMP is dead". The development funds seem > to be going toward Web solutions: > (a) Proprietary HTTP forms/etc.; or > (b) SOAP over HTTP (OASIS WSDM, etc.). > And proprietary HTTP solutions are the only ones currently > shipping from any printer vendor. This is not good. > > 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: Monday, February 14, 2005 9:44 PM > To: 'McDonald, Ira'; 'Juergen Quittek'; isms@ietf.org > Subject: RE: [Isms] proposal comparison I-D > > > Hi Ira, > > Juergen said the document was submitted today, and it was apparently > received before the cutoff time, since it is now reflected on the > charter page. > > Based on the charter deadlines, the WG still has through March to make > a "decision about which solution approach the WG will focus its > efforts on." We also have until the end of March to recharter to > include publication goals or shutdown if no consensus on a technical > direction is reached by this time. > > I think we will be able to reach consensus on a technical direction by > that time. While there are benefits to the TLSM proposal, I have no > issue with it being put aside to focus on the EUSM model. The TLSM > approach can always be written as a future alternative if desired. The > EUSM model, with the eval-team suggested changes to make it more > modular, should be flexible enough to meet the needs of many industry > segments. > > 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: Monday, February 14, 2005 7:32 PM > > To: 'Juergen Quittek'; isms@ietf.org > > Subject: RE: [Isms] proposal comparison I-D > > > > Hi, > > > > Well written document! I liked the architectural perspective > > on the three ISMS proposals. > > > > But the revised I-D cutoff for IETF 62 passed today. That > > means an I-D publication blackout until mid-March. > > > > So it's difficult to see how this working group doesn't fail. > > Are the minutes of the ISMS WG meeting at IETF 62 to constitute > > the sole proof that the WG has 'selected' a proposal by the > > end-of-March? Especially in light of the evaluation team's > > recommendation that EUSM be substantially modified to add > > features from both of the other proposals? > > > > All - please read the evaluation team's short cogent document > > soon - please minimize email rhetoric on second-order features > > and stick to the architectural guidance on first-order features > > in the evaluation I-D. > > > > 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 Juergen Quittek > > Sent: Monday, February 14, 2005 11:49 AM > > To: isms@ietf.org > > Subject: [Isms] proposal comparison I-D > > > > > > Dear all, > > > > The evaluation team has completed its work. > > It took longer than expected (as so many IETF tasks), > > but now they delivered us a comparison of the three proposals > > and give a recommendation on how the WG should proceed. > > > > I thank all team members for their excellent work, and > > Randy and Lakshminath for acting as document editors. > > > > The I-D was just submitted today. For all who do not want > > to wait until it gets posted officially by the end of the > > week, I put a copy at: > > > > > roposal-compar > > ison-00.txt> > > > > Please have a look at it and let's start a (certainly > > controversial) discussion on it as soon as possible. > > > > The recommendations in section 3 provide a lot > > of useful input to shaping a WG agenda. > > > > 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 > > > > _______________________________________________ > > 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@ietf.org Tue Feb 15 15:36:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09455; Tue, 15 Feb 2005 15:36:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19mP-0000ju-Tg; Tue, 15 Feb 2005 15:58:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19PL-0001HI-BC; Tue, 15 Feb 2005 15:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19Eb-0004sr-Bf for isms@megatron.ietf.org; Tue, 15 Feb 2005 15:23:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07845 for ; Tue, 15 Feb 2005 15:23:47 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D19Zh-0000K4-BK for isms@ietf.org; Tue, 15 Feb 2005 15:45:38 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j1FKNXO7026266 for ; Tue, 15 Feb 2005 15:23:33 -0500 (EST) Message-Id: <200502152023.j1FKNXO7026266@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] proposal comparison I-D In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 15 Feb 2005 15:23:33 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 >Chairs - is the IESG likely to accept a recharter without >any I-D to point at documenting the "decision about approach"? >Is the evaluation I-D itself sufficient? > >The changes that were suggested to EUSM are certainly not >cosmetic. Well ... here's my interpretation of the mandate set before us from the IESG. We have to decide on a _single_ technical direction by the March meeting. In my mind, if the WG accepts the evaluation team's recommendations (EUSM with the suggested changes), that to me is clearly a single direction. We definately don't have to have the protocol all hashed out. Clear enough? --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 15 18:11:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25720; Tue, 15 Feb 2005 18:11:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1CC3-0004vY-94; Tue, 15 Feb 2005 18:33:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1BqS-0006Nr-EI; Tue, 15 Feb 2005 18:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Bkd-0004lC-Fu for isms@megatron.ietf.org; Tue, 15 Feb 2005 18:05:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24573 for ; Tue, 15 Feb 2005 18:05:00 -0500 (EST) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1C5k-0004ic-Hv for isms@ietf.org; Tue, 15 Feb 2005 18:26:53 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 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 j1FN4UB8032005 for ; Tue, 15 Feb 2005 23:04:30 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 j1FN4ULh013721 for ; Tue, 15 Feb 2005 23:04:30 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005021515043007382 for ; Tue, 15 Feb 2005 15:04:30 -0800 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, 15 Feb 2005 15:04:30 -0800 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, 15 Feb 2005 15:04:30 -0800 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, 15 Feb 2005 18:04:27 -0500 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] proposal comparison I-D Date: Tue, 15 Feb 2005 18:04:21 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929B08F31@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] proposal comparison I-D Thread-Index: AcUTnig4MBkc+1enRgS1cHMlMX/QBwAFHdkg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 15 Feb 2005 23:04:27.0765 (UTC) FILETIME=[B2F84A50:01C513B2] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable =20 I'd say - Hell yes! :-) -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein Sent: Tuesday, February 15, 2005 3:24 PM To: isms@ietf.org Subject: Re: [Isms] proposal comparison I-D=20 >Chairs - is the IESG likely to accept a recharter without >any I-D to point at documenting the "decision about approach"? >Is the evaluation I-D itself sufficient? =20 > >The changes that were suggested to EUSM are certainly not=20 >cosmetic. Well ... here's my interpretation of the mandate set before us from the IESG. We have to decide on a _single_ technical direction by the March meeting. In my mind, if the WG accepts the evaluation team's recommendations (EUSM with the suggested changes), that to me is clearly a single direction. We definately don't have to have the protocol all hashed out. Clear enough? --Ken _______________________________________________ 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@ietf.org Tue Feb 15 18:33:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28216; Tue, 15 Feb 2005 18:33:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1CXE-0005PI-GG; Tue, 15 Feb 2005 18:55:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1C79-0002r9-EY; Tue, 15 Feb 2005 18:28:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1C5P-00029E-DX for isms@megatron.ietf.org; Tue, 15 Feb 2005 18:26:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27733 for ; Tue, 15 Feb 2005 18:26:27 -0500 (EST) Received: from keymaster.sharplabs.com ([216.65.151.107] helo=sharplabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1CQV-0005Fz-TK for isms@ietf.org; Tue, 15 Feb 2005 18:48:21 -0500 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 j1FNPsmi021953 for ; Tue, 15 Feb 2005 15:25:54 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B76YMMY>; Tue, 15 Feb 2005 15:25:51 -0800 Message-ID: From: "McDonald, Ira" To: "'isms@ietf.org'" Subject: Re: [Isms] proposal comparison I-D Date: Tue, 15 Feb 2005 15:25:50 -0800 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: 082a9cbf4d599f360ac7f815372a6a15 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Hi, Well I'm heartened that people seem to think that this WG still has good prospects of success (smile). About printers - CLI or embedded Web interfaces are NOT sufficient. The printer industry has experienced the same crushing reduction in hardware profits that the computer industry has experienced. There are only two areas of profit left, to whit, supplies (now under great competitive pressure) and fleet management. Fleet management applications from printer vendors are all currently proprietary - and the typical customers have networks with thousands or tens-of-thousands of printers. That is to say, printers are far more common than either network servers or network infrastructure (routers and hubs) in typical enterprise networks. I suggest that the SNMP standards community not focus so exclusively on network infrastructure for their management requirements. 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: Tuesday, February 15, 2005 3:00 PM To: 'McDonald, Ira'; 'Juergen Quittek'; isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Hi, Regarding pronouncements that SNMP is dead - I've heard it so many times in the IETF, but so seldom from buying customers, that I don't put a lot of stock in such pronouncements. Which is not to say that valid criticisms of SNMP shouldn't be paid attention to; SNMP has been around for a long time and is used in ways it was not designed for, and hasn't kept up with related advances in technology. I think it is important to recognize that management interfaces for printers are normally for element management, not network, service, or business process management. Generally one does not need to compare the status of the paper tray across printers. For monitoring a specific device status, a CLI or web-based interface is typically fine. SNMP isn't required for that use-case (although traps could certainly be useful). <...snip...> I look rather optimistically at what this WG has achieved so far, and what we will yet achieve. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Feb 15 18:39:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28943; Tue, 15 Feb 2005 18:39:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1CdC-0005c9-FN; Tue, 15 Feb 2005 19:01:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CDB-0004R5-6a; Tue, 15 Feb 2005 18:34:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1CCh-00049L-Av for isms@megatron.ietf.org; Tue, 15 Feb 2005 18:34:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28266 for ; Tue, 15 Feb 2005 18:34:00 -0500 (EST) 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.33) id 1D1CXo-0005Pp-UQ for isms@ietf.org; Tue, 15 Feb 2005 18:55:54 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 57B3D11DBC6; Tue, 15 Feb 2005 15:33:53 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Tue, 15 Feb 2005 15:33:52 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.0 (++) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Isms] clarification: protocol on the wire unchanged 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 You know, many people say its a plus to have the protocol on the wire unchanged (IE, the security parameters format is still USM). I've yet to find someone that can explain the rational behind that? Some have argued code change required, but that doesn't make sense since you have to write code to support the new integration with whatever the new keying mechanism is. I don't buy any argument that all such integration code will be less than modifying the security parameters fields in all cases (unless of you course you don't have a set of BER routines available, but we all know everything does already). In short, all 3 protocols require new code in both the manager and the agent. Some of the protocols require new protocol extensions in other protocols (EG EUSM's needed modifications to Radius) and new code in the deployment base of those new protocols on both the manager and the agent (err... CG and CR) side of the transaction. Don't get me wrong, I'm not arguing that we should change it if we don't have to. I fail to see the "advantages" that people state are there for not changing it. (especially since all solutions to date will require new security protocol identifies anyway, so it's not like you can take any solutions protocol and throw it through an unmodified SNMPv3 stack in the first place (unless such a stack is already broken in that it ignores the security protocol identifier in the packet today)). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 16 15:52:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23118; Wed, 16 Feb 2005 15:52:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1WUv-00021a-SB; Wed, 16 Feb 2005 16:14:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VyA-0002rM-S3; Wed, 16 Feb 2005 15:40:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Vjo-00029W-JG for isms@megatron.ietf.org; Wed, 16 Feb 2005 15:25:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18363 for ; Wed, 16 Feb 2005 15:25:30 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1W56-0000Rk-N6 for isms@ietf.org; Wed, 16 Feb 2005 15:47:34 -0500 Received: from dialin-145-254-215-105.arcor-ip.net (dialin-145-254-215-105.arcor-ip.net [145.254.215.105]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 62EA21BAC9E for ; Wed, 16 Feb 2005 21:24:52 +0100 (CET) Date: Wed, 16 Feb 2005 21:24:52 +0100 From: Juergen Quittek To: isms@ietf.org Subject: RE: [Isms] proposal comparison I-D Message-ID: In-Reply-To: <3DEC199BD7489643817ECA151F7C5929B08F31@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C5929B08F31@pysmsx401.amr.corp.intel.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.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Dear all, Continuing clarifications, here is our work plan for the next weeks as I see it: - Until the ISMS session in MPLS we discuss the proposal comparison I-D on the mailing list, particularly concrete comments agreeing or disagreeing with statements in Section 3 are very welcome. Also we should look out for indicators of potential WG consensus: Would the WG accept the recommendations? Do some of them need to be modified? Does the WG prefer a different way to go? - At the ISMS session in MPLS I see two major agenda items: 1. Continue and (hopefully) conclude the discussion on the way to go. 2. Discuss a draft of a new charter for the WG. - After the ISMS session in MPLS until end of March 1. we need to achieve rough consensus on the way to go very soon on the mailing list. 2. Then we need to agree on a draft charter for our future work. 3. We will submit our charter proposal to our ADs and the IESG. - Depending on comments we receive from AD and IESG review some charter modifications will probably be required. - If we are successful then we will have a new charter accepted by the IESG at some time after end of March. The charter will contain some milestones and require us to produce (at least) one WG document specifying a new security model for SNMP. Ken and I will ask WG participants to establish a design team for writing this (these) document(s). If you disagree with this plan, and particularly if you have suggestions for improvements, please comment. 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 16.02.2005 0:04 h +0100 Blumenthal, Uri wrote: > > I'd say - Hell yes! :-) > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of Ken Hornstein > Sent: Tuesday, February 15, 2005 3:24 PM > To: isms@ietf.org > Subject: Re: [Isms] proposal comparison I-D > >> Chairs - is the IESG likely to accept a recharter without >> any I-D to point at documenting the "decision about approach"? >> Is the evaluation I-D itself sufficient? >> >> The changes that were suggested to EUSM are certainly not >> cosmetic. > > Well ... here's my interpretation of the mandate set before us from the > IESG. > > We have to decide on a _single_ technical direction by the March > meeting. In my mind, if the WG accepts the evaluation team's > recommendations (EUSM with the suggested changes), that to me is > clearly a single direction. We definately don't have to have the > protocol all hashed out. > > Clear enough? > > --Ken > > _______________________________________________ > 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@ietf.org Thu Feb 17 16:01:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04764; Thu, 17 Feb 2005 16:01:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1t7f-0007eF-PJ; Thu, 17 Feb 2005 16:23:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1qoF-0000f8-3H; Thu, 17 Feb 2005 13:55:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ony-0000bZ-L8 for isms@megatron.ietf.org; Thu, 17 Feb 2005 11:47:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20625 for ; Thu, 17 Feb 2005 11:47:04 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1p9R-0002dW-OX for isms@ietf.org; Thu, 17 Feb 2005 12:09:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 17 Feb 2005 08:46:34 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j1HGkVTj005367; Thu, 17 Feb 2005 08:46:32 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn6-70.cisco.com [10.21.120.70]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYG08821; Thu, 17 Feb 2005 08:46:30 -0800 (PST) Message-Id: <6.2.0.14.0.20050217082329.03c988d0@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 17 Feb 2005 08:46:30 -0800 To: isms@ietf.org From: Kaushik Narayan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Isms] Follow up to ISMS Proposal Comparison ID 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Hi All, draft-ietf-isms-proposal-comparison-00.txt says: The evaluation team concludes that the EUSM architecture would be the right direction for the ISMS WG. However, a number of aspects of the EUSM design need moderate to substantial revision. In the following, we first describe the components of the design that we consider most attractive, and then list the components that need to be revised and suggest components from other proposals as examples as appropriate: We realize that this is only the conclusion of the evaluation team, and not the conclusion of the WG. However, we have asked the WG chairs how we can help this process along, and their advice is that we apply as many of the evaluation team's suggestions to our I-D as we can, and thereby we may be able to help to speed up the overall process (even if the WG were to decide to take another direction). To this end, we plan to submit an updated I-D (i.e., to submit draft-kaushik-snmp-external-usm-02.txt) before next Sunday evening's deadline. Below is a list of the specific changes we propose to make. If anyone has any better ideas, please let us know. Proposed changes: 1. Follow the SNMPv3 architecture and not distinguish between manager and agents. 2. Document and justify protocol choices such PEAP vs EAP-TLS vs TTLS and choice of inner EAP methods. Clean up the reference to CBC-DES. 3. Document the dependencies on other work in progress such as PANA, EAP and Radius. We also propose to make the following changes but will not be able to complete these changes before next Sunday's deadline. 1. Rewrite the core proposal similar to TLSM illustrating the integration with RFC3411. 2. We will try to augment the generic description of the EUSM architecture with a use case illustrating the support for Kerberos. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 17 17:40:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19214; Thu, 17 Feb 2005 17:40:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1uf2-0003G0-15; Thu, 17 Feb 2005 18:02:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1toX-00024I-Bx; Thu, 17 Feb 2005 17:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1tcB-0000pN-MD for isms@megatron.ietf.org; Thu, 17 Feb 2005 16:55:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10879 for ; Thu, 17 Feb 2005 16:55:13 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1txg-0000va-Qn for isms@ietf.org; Thu, 17 Feb 2005 17:17:31 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id D599F9C1A; Thu, 17 Feb 2005 22:54:40 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 20559-05; Thu, 17 Feb 2005 22:54:39 +0100 (CET) Received: from james (Iada5.i.pppool.de [85.73.173.165]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A926930EB; Thu, 17 Feb 2005 22:54:39 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1D1tbZ-0000pZ-UH; Thu, 17 Feb 2005 22:54:37 +0100 Date: Thu, 17 Feb 2005 22:54:37 +0100 From: Juergen Schoenwaelder To: Juergen Quittek Subject: Re: [Isms] proposal comparison I-D Message-ID: <20050217215437.GA3169@james> 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.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Mon, Feb 14, 2005 at 05:48:56PM +0100, Juergen Quittek wrote: > The evaluation team has completed its work. > It took longer than expected (as so many IETF tasks), > but now they delivered us a comparison of the three proposals > and give a recommendation on how the WG should proceed. I just read the output produced by the evaluation team. I very much like the architectural analysis and the way the document is written. I was definitely worth to wait a bit longer for this well prepared analysis to show up. I can very well support the overall recommendation. EUSM addresses an important part of the overall problem space, namely integration with external AAA servers. I believe it is good to focus the ISMS effort in this direction. Thanks to all people involved in the evaluation. /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@ietf.org Thu Feb 17 19:08:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28475; Thu, 17 Feb 2005 19:08:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1w2e-0005Ww-2f; Thu, 17 Feb 2005 19:30:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1vOL-0006uX-M2; Thu, 17 Feb 2005 18:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1uyU-0004Xt-4N for isms@megatron.ietf.org; Thu, 17 Feb 2005 18:22:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23288 for ; Thu, 17 Feb 2005 18:22:19 -0500 (EST) 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.33) id 1D1vK1-0004C9-Ug for isms@ietf.org; Thu, 17 Feb 2005 18:44:38 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id E6C7311DBF6; Thu, 17 Feb 2005 15:22:18 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Thu, 17 Feb 2005 15:22:17 -0800 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Security Through Obscurity, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Isms] achieving market saturation with 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be One of the whole reasons behind David and my efforts to get this work under way within the IETF was to try and help the operators with deployed authentication infrastructures (of any type) to be able to access their devices securely over SNMPv3 using identical authentication mechanisms. The most critical problem with deploying SNMPv3 wasn't that it wasn't better than v1/v2c but that it was hard to deploy due the maintenance it required. This is, of course, already known. When we approached the IESG about starting a working group, we were asked to prove that people needed such a change and this was the reason many people weren't using SNMPv3 in the first place. To do this, we offered a survey and advertised it to NANOG and a few other places. We got 149 responses. Some of the questions that were asked had surprising results, some were expected. To recap some of the important things to consider as this work goes forward: 26% of the people that responded used SNMPv3 at that time. Of the various authentication systems in use at that time by the people that responded: 66% local accounts 49% SSH-keys 40% Radius 29% TACACS+ 14% X.509 Certificates 10% Kerberos [numbers don't add to 100 because more than one option could be selected] This result set actually surprised me. I knew that SSH was popular as was local accounts, but I actually expected Radius to be in greater use than it was. 40% is certainly heavy usage, but it is hardly market dominance. One of the reasons that I've told many people that I'd be happy with a transport based solution, such as the TLSM solution had offered, even though it wasn't my number one choice, was that it would at least meet the criteria of getting the largest percentage of deployment possible. Specifically, it would be easy to make it work with both local accounts over a TLS tunnel as well as SSH based identities over a SSH tunnel. Thus, it would likely have a huge impact on the usability of SNMPv3. Where I'm going with all of this is that I disagree with section 3.2 that states: The evaluation team also recommends, in the interest of interoperability, that the working group select a single mandatory-to-implement mechanism. The evaluation team recommends RADIUS [RFC2865] for this purpose, due to its widespread use. If you offered operators a solution which was couched around Radius and they didn't use it, you wouldn't be offering them anything. It's somewhat akin to saying "Ok, we learned that you didn't like SNMPv3 because you didn't want to maintain another infrastructure. We've now fixed that, here install this different infrastructure (Radius) instead." We've already seen the ramifications of selecting an authentication system which people didn't want to use. I don't think that if you selected Radius as a mandatory to implement protocol that you would much greater than 40% saturation with it, which in my opinion is way too low. As much as the security side of me hates to say it, I think we should strongly consider making local accounts the mandatory to implement form because that is simply what is in use the most. Even worse, if EUSM-like is the path chosen it requires that Radius or any other protocol be modified before it could be used by this architecture. That's a rather important point, so I'll restate it. The other protocols must be modified before they'll work. It's important because it means the current deployed base of the modified protocol is 0%. It means that even if you shipped the solution today, everyone would have to upgrade their infrastructure or install new infrastructures in order to make the solution work. That, to me, is not giving the operators what they've been asking for: to make SNMPv3 work with what they have today. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 18 04:17:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08385; Fri, 18 Feb 2005 04:17:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D24bu-0002AU-PK; Fri, 18 Feb 2005 04:39:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D24Bg-00082N-Jo; Fri, 18 Feb 2005 04:12:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D246h-00062y-4a for isms@megatron.ietf.org; Fri, 18 Feb 2005 04:07:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07804 for ; Fri, 18 Feb 2005 04:07:23 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D24SI-0001xE-67 for isms@ietf.org; Fri, 18 Feb 2005 04:29:46 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1I96o409565; Fri, 18 Feb 2005 04:06:50 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL32AA>; Fri, 18 Feb 2005 04:06:51 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B989@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Wes Hardaker'" , isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Date: Fri, 18 Feb 2005 04:06:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 1c0c3d540ad9f95212b1c2a9a2cc2595 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="===============0358619327==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 3b3709b7fb3320c78bd7b1555081f0fc This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0358619327== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51599.2BE664E1" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C51599.2BE664E1 Content-Type: text/plain Wes, My understanding of the evaluation report was that there were two mandatory-to-implement mechanisms, one implicit and the other explicit. The explicit mechanism was in fact RADIUS but I believe the support of local accounts was implicitly required as well (where the device acts as a RADIUS key distributor) for clients connecting to it. Perhaps the evaluation team can confirm? I don't feel that those using SSH tunnelling require SNMPv3 (since SSH provides authentication and privacy), so I'm not sure where that combination comes from. Could you explain that? I agree with Wes' point that the result of this effort should be careful to address the requirement to make SNMPv3 deployment easy in existing deployments but I would note that from this survey it would appear that RADIUS is the market leader for centralized AAA, we just need to be sure to support non-centralized AAA as well. I think most of the people on the list have been saying this all along. Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Wes Hardaker > Sent: February 18, 2005 12:22 AM > To: isms@ietf.org > Subject: [Isms] achieving market saturation with ISMS > > > One of the whole reasons behind David and my efforts to get this work > under way within the IETF was to try and help the operators with > deployed authentication infrastructures (of any type) to be able to > access their devices securely over SNMPv3 using identical > authentication mechanisms. The most critical problem with deploying > SNMPv3 wasn't that it wasn't better than v1/v2c but that it was hard > to deploy due the maintenance it required. This is, of course, > already known. > > When we approached the IESG about starting a working group, we were > asked to prove that people needed such a change and this was the > reason many people weren't using SNMPv3 in the first place. To do > this, we offered a survey and advertised it to NANOG and a few other > places. We got 149 responses. Some of the questions that were asked > had surprising results, some were expected. > > To recap some of the important things to consider as this work goes > forward: > > 26% of the people that responded used SNMPv3 at that time. > > Of the various authentication systems in use at that time by the > people that responded: > > 66% local accounts > 49% SSH-keys > 40% Radius > 29% TACACS+ > 14% X.509 Certificates > 10% Kerberos > > [numbers don't add to 100 because more than one option could be > selected] > > This result set actually surprised me. I knew that SSH was popular as > was local accounts, but I actually expected Radius to be in greater > use than it was. 40% is certainly heavy usage, but it is hardly > market dominance. > > One of the reasons that I've told many people that I'd be happy with a > transport based solution, such as the TLSM solution had offered, even > though it wasn't my number one choice, was that it would at least meet > the criteria of getting the largest percentage of deployment > possible. Specifically, it would be easy to make it work with both > local accounts over a TLS tunnel as well as SSH based identities over > a SSH tunnel. Thus, it would likely have a huge impact on the > usability of SNMPv3. > > Where I'm going with all of this is that I disagree with section > 3.2 that states: > > The evaluation team also recommends, in the interest of > interoperability, that the working group select a single > mandatory-to-implement mechanism. The evaluation team recommends > RADIUS [RFC2865] for this purpose, due to its widespread use. > > If you offered operators a solution which was couched around Radius > and they didn't use it, you wouldn't be offering them anything. It's > somewhat akin to saying "Ok, we learned that you didn't like SNMPv3 > because you didn't want to maintain another infrastructure. We've now > fixed that, here install this different infrastructure (Radius) instead." > > We've already seen the ramifications of selecting an authentication > system which people didn't want to use. I don't think that if you > selected Radius as a mandatory to implement protocol that you would > much greater than 40% saturation with it, which in my opinion is way > too low. As much as the security side of me hates to say it, I think > we should strongly consider making local accounts the mandatory to > implement form because that is simply what is in use the most. > > Even worse, if EUSM-like is the path chosen it requires that Radius or > any other protocol be modified before it could be used by this > architecture. That's a rather important point, so I'll restate it. > The other protocols must be modified before they'll work. It's > important because it means the current deployed base of the modified > protocol is 0%. It means that even if you shipped the solution today, > everyone would have to upgrade their infrastructure or install new > infrastructures in order to make the solution work. That, to me, is > not giving the operators what they've been asking for: to make SNMPv3 > work with what they have today. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C51599.2BE664E1 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] achieving market saturation with ISMS

Wes,

My understanding of the evaluation report was that = there were two mandatory-to-implement mechanisms, one implicit and the = other explicit. The explicit mechanism was in fact RADIUS but I believe = the support of local accounts was implicitly required as well (where = the device acts as a RADIUS key distributor) for clients connecting to = it. Perhaps the evaluation team can confirm?

I don't feel that those using SSH tunnelling require = SNMPv3 (since SSH provides authentication and privacy), so I'm not sure = where that combination comes from. Could you explain that?

I agree with Wes' point that the result of this = effort should be careful to address the requirement to make SNMPv3 = deployment easy in existing deployments but I would note that from this = survey it would appear that RADIUS is the market leader for centralized = AAA, we just need to be sure to support non-centralized AAA as well. I = think most of the people on the list have been saying this all = along.

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Wes Hardaker
> Sent: February 18, 2005 12:22 AM
> To: isms@ietf.org
> Subject: [Isms] achieving market saturation = with ISMS
>
>
> One of the whole reasons behind David and my = efforts to get this work
> under way within the IETF was to try and help = the operators with
> deployed authentication infrastructures (of any = type) to be able to
> access their devices securely over SNMPv3 using = identical
> authentication mechanisms.  The most = critical problem with deploying
> SNMPv3 wasn't that it wasn't better than v1/v2c = but that it was hard
> to deploy due the maintenance it = required.  This is, of course,
> already known.
>
> When we approached the IESG about starting a = working group, we were
> asked to prove that people needed such a change = and this was the
> reason many people weren't using SNMPv3 in the = first place.  To do
> this, we offered a survey and advertised it to = NANOG and a few other
> places.  We got 149 responses.  Some = of the questions that were asked
> had surprising results, some were = expected.
>
> To recap some of the important things to = consider as this work goes
> forward:
>
> 26% of the people that responded used SNMPv3 at = that time.
>
> Of the various authentication systems in use at = that time by the
> people that responded:
>
>   66%  local accounts
>   49%  SSH-keys
>   40%  Radius
>   29%  TACACS+
>   14%  X.509 Certificates
>   10%  Kerberos
>
>   [numbers don't add to 100 because = more than one option could be
> selected]
>
> This result set actually surprised me.  I = knew that SSH was popular as
> was local accounts, but I actually expected = Radius to be in greater
> use than it was.  40% is certainly heavy = usage, but it is hardly
> market dominance.
>
> One of the reasons that I've told many people = that I'd be happy with a
> transport based solution, such as the TLSM = solution had offered, even
> though it wasn't my number one choice, was that = it would at least meet
> the criteria of getting the largest percentage = of deployment
> possible.  Specifically, it would be easy = to make it work with both
> local accounts over a TLS tunnel as well as SSH = based identities over
> a SSH tunnel.  Thus, it would likely have = a huge impact on the
> usability of SNMPv3.
>
> Where I'm going with all of this is that I = disagree with section
> 3.2 that states:
>
>    The evaluation team also = recommends, in the interest of
>    interoperability, that the = working group select a single
>    mandatory-to-implement = mechanism.  The evaluation team recommends
>    RADIUS [RFC2865] for this = purpose, due to its widespread use.
>
> If you offered operators a solution which was = couched around Radius
> and they didn't use it, you wouldn't be = offering them anything.  It's
> somewhat akin to saying "Ok, we learned = that you didn't like SNMPv3
> because you didn't want to maintain another = infrastructure.  We've now
> fixed that, here install this different = infrastructure (Radius) instead."
>
> We've already seen the ramifications of = selecting an authentication
> system which people didn't want to use.  I = don't think that if you
> selected Radius as a mandatory to implement = protocol that you would
> much greater than 40% saturation with it, which = in my opinion is way
> too low.  As much as the security side of = me hates to say it, I think
> we should strongly consider making local = accounts the mandatory to
> implement form because that is simply what is = in use the most.
>
> Even worse, if EUSM-like is the path chosen it = requires that Radius or
> any other protocol be modified before it could = be used by this
> architecture.  That's a rather important = point, so I'll restate it.
> The other protocols must be modified before = they'll work.  It's
> important because it means the current deployed = base of the modified
> protocol is 0%.  It means that even if you = shipped the solution today,
> everyone would have to upgrade their = infrastructure or install new
> infrastructures in order to make the solution = work.  That, to me, is
> not giving the operators what they've been = asking for: to make SNMPv3
> work with what they have today.
>
> --
> Wes Hardaker
> Sparta
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C51599.2BE664E1-- --===============0358619327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --===============0358619327==-- From isms-bounces@ietf.org Fri Feb 18 11:56:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06511; Fri, 18 Feb 2005 11:56:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2BmK-0001Ui-PH; Fri, 18 Feb 2005 12:18:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2B2l-0002Fl-Rh; Fri, 18 Feb 2005 11:31:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ANm-0000ZJ-CR for isms@megatron.ietf.org; Fri, 18 Feb 2005 10:49:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20183 for ; Fri, 18 Feb 2005 10:49:28 -0500 (EST) Message-Id: <200502181549.KAA20183@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2AjQ-0004rI-DP for isms@ietf.org; Fri, 18 Feb 2005 11:11:55 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005021815485501300qnckhe>; Fri, 18 Feb 2005 15:48:55 +0000 From: "David B Harrington" To: "'Martin Soukup'" , "'Wes Hardaker'" , Date: Fri, 18 Feb 2005 10:48:51 -0500 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: <0BDFFF51DC89434FA33F8B37FCE363D501F2B989@zcarhxm2.corp.nortel.com> thread-index: AcUVmqXBRpoodBWtSOSUROrO3QhTyQALlXTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Subject: [Isms] SSH tunneling and SNMPv3 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Content-Transfer-Encoding: 7bit Hi Martin, It is important to identify, preferably using SecSH terms and references, just what "SSH tunneling" means. SecSh Transport Layer Protocol provides authentication, integrity checking, and encryption. from draft-ietf-secsh-transport-22.txt: "Authentication in this protocol level is host-based; this protocol does not perform user authentication. A higher level protocol for user authentication can be designed on top of this protocol." SNMPv3 is designed to provide per-user controlled access to data, so host authentication is inadequate to meet the design goals for SNMPv3 (that were established by IETF consensus). The SecSH Authentication Protocol (draft-ietf-secsh-userauth-25.txt) provides user authentication, and that comes closer to meeting SNMPv3 per-user requirements. However, it is necessary to have a binding between the user authentication of SecSH and the user identity used for per-user access control. I could use SecSH authentication to establish a session for user "dbh", and then pass an SNMPv1 message claiming rights to the "super-user" community (or an SNMPv3 message claiming a USM identity of "super-user" rather than dbh). There needs to be a binding between the authentication of the user and the application of access permissions for that user. So either SecSH needs to be pass the authenticated user identity to the SNMP engine so SNMP can apply appropriate access control, or SNMP has to perform its own user authentication independent of SecSH. Also, SNMPv3 provides a wealth of features beyond authentication and privacy that are important to some, but not all, environments. I won't go into them here, because that is not within the scope of this WG. I leave it to you to understand the benefits of engineID, contextEngineID, a standardized proxy, a standardized notification addressing mechanism, a standardized notification filtering mechanism, etc. David Harrington dbharrington@comcast.net ________________________________ From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Martin Soukup Sent: Friday, February 18, 2005 4:07 AM To: 'Wes Hardaker'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Wes, My understanding of the evaluation report was that there were two mandatory-to-implement mechanisms, one implicit and the other explicit. The explicit mechanism was in fact RADIUS but I believe the support of local accounts was implicitly required as well (where the device acts as a RADIUS key distributor) for clients connecting to it. Perhaps the evaluation team can confirm? I don't feel that those using SSH tunnelling require SNMPv3 (since SSH provides authentication and privacy), so I'm not sure where that combination comes from. Could you explain that? I agree with Wes' point that the result of this effort should be careful to address the requirement to make SNMPv3 deployment easy in existing deployments but I would note that from this survey it would appear that RADIUS is the market leader for centralized AAA, we just need to be sure to support non-centralized AAA as well. I think most of the people on the list have been saying this all along. Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Wes Hardaker > Sent: February 18, 2005 12:22 AM > To: isms@ietf.org > Subject: [Isms] achieving market saturation with ISMS > > > One of the whole reasons behind David and my efforts to get this work > under way within the IETF was to try and help the operators with > deployed authentication infrastructures (of any type) to be able to > access their devices securely over SNMPv3 using identical > authentication mechanisms. The most critical problem with deploying > SNMPv3 wasn't that it wasn't better than v1/v2c but that it was hard > to deploy due the maintenance it required. This is, of course, > already known. > > When we approached the IESG about starting a working group, we were > asked to prove that people needed such a change and this was the > reason many people weren't using SNMPv3 in the first place. To do > this, we offered a survey and advertised it to NANOG and a few other > places. We got 149 responses. Some of the questions that were asked > had surprising results, some were expected. > > To recap some of the important things to consider as this work goes > forward: > > 26% of the people that responded used SNMPv3 at that time. > > Of the various authentication systems in use at that time by the > people that responded: > > 66% local accounts > 49% SSH-keys > 40% Radius > 29% TACACS+ > 14% X.509 Certificates > 10% Kerberos > > [numbers don't add to 100 because more than one option could be > selected] > > This result set actually surprised me. I knew that SSH was popular as > was local accounts, but I actually expected Radius to be in greater > use than it was. 40% is certainly heavy usage, but it is hardly > market dominance. > > One of the reasons that I've told many people that I'd be happy with a > transport based solution, such as the TLSM solution had offered, even > though it wasn't my number one choice, was that it would at least meet > the criteria of getting the largest percentage of deployment > possible. Specifically, it would be easy to make it work with both > local accounts over a TLS tunnel as well as SSH based identities over > a SSH tunnel. Thus, it would likely have a huge impact on the > usability of SNMPv3. > > Where I'm going with all of this is that I disagree with section > 3.2 that states: > > The evaluation team also recommends, in the interest of > interoperability, that the working group select a single > mandatory-to-implement mechanism. The evaluation team recommends > RADIUS [RFC2865] for this purpose, due to its widespread use. > > If you offered operators a solution which was couched around Radius > and they didn't use it, you wouldn't be offering them anything. It's > somewhat akin to saying "Ok, we learned that you didn't like SNMPv3 > because you didn't want to maintain another infrastructure. We've now > fixed that, here install this different infrastructure (Radius) instead." > > We've already seen the ramifications of selecting an authentication > system which people didn't want to use. I don't think that if you > selected Radius as a mandatory to implement protocol that you would > much greater than 40% saturation with it, which in my opinion is way > too low. As much as the security side of me hates to say it, I think > we should strongly consider making local accounts the mandatory to > implement form because that is simply what is in use the most. > > Even worse, if EUSM-like is the path chosen it requires that Radius or > any other protocol be modified before it could be used by this > architecture. That's a rather important point, so I'll restate it. > The other protocols must be modified before they'll work. It's > important because it means the current deployed base of the modified > protocol is 0%. It means that even if you shipped the solution today, > everyone would have to upgrade their infrastructure or install new > infrastructures in order to make the solution work. That, to me, is > not giving the operators what they've been asking for: to make SNMPv3 > work with what they have today. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > 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@ietf.org Mon Feb 21 01:46:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29459; Mon, 21 Feb 2005 01:46:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D37gp-0007Vl-Ip; Mon, 21 Feb 2005 02:09:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36k2-0000mP-MP; Mon, 21 Feb 2005 01:08:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D36fa-0007Dc-1l for isms@megatron.ietf.org; Mon, 21 Feb 2005 01:03:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26727 for ; Mon, 21 Feb 2005 01:03:40 -0500 (EST) From: kaushik@cisco.com 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.33) id 1D371h-0006aQ-5l for isms@ietf.org; Mon, 21 Feb 2005 01:26:38 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 20 Feb 2005 23:17:08 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,101,1107734400"; d="txt'?scan'208"; a="227306273:sNHT57044488" Received: from tiffin.cisco.com (tiffin.cisco.com [171.70.70.154]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1L631q8009674; Sun, 20 Feb 2005 22:03:01 -0800 (PST) Received: (kaushik@localhost) by tiffin.cisco.com (8.11.2/CISCO.WS.1.2) id j1L635905167; Sun, 20 Feb 2005 22:03:05 -0800 (PST) Message-Id: <200502210603.j1L635905167@tiffin.cisco.com> To: isms@ietf.org Date: Sun, 20 Feb 2005 22:03:05 -0800 (PST) X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="%--multipart-mixed-boundary-1.3064.1108965785--%" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7f30a46178edfef2bdd484ce718b5b0a Subject: [Isms] New EUSM -02 draft 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: b787d1992fb8a7f79e3b476be548ce51 --%--multipart-mixed-boundary-1.3064.1108965785--% Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, A new EUSM -02 draft has been submitted. It will take some time going through the queue. I am attaching the draft that was posted. regards, kaushik! --%--multipart-mixed-boundary-1.3064.1108965785--% Content-Type: text/plain Content-Description: ascii text Content-Disposition: attachment; filename="draft-kaushik-snmp-external-usm-02.txt" Content-Transfer-Encoding: 7bit Network Working Group Kaushik Narayan Internet-Draft Keith McCloghrie Expiration Date: August 17, 2005 Joseph Salowey Cisco Systems Inc. Feb 2005 External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3) draft-kaushik-snmp-external-usm-02.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire in August 2005. Copyright Notice Copyright (C) The Internet Society 2005. Narayan et al. Expires Aug 2005 [Page 1] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 Abstract This specification defines a framework for SNMPv3 authentication and key distribution with support for various authentication systems such as RADIUS, X.509 certificates, Local Accounts, Kerberos etc. Support for these authentication systems for SNMPv3 allows for a common identity to be used with/shared across all management protocols since the other network management interfaces such as the NetConf protocol and device Command Line Interface (CLI) are already using these authentication systems. This specification defines a new security model for SNMPv3, the External User Security Model (EUSM). This EUSM model differs from USM in only one respect: it uses out-of-band authentication protocols to establish keying material for the user for achieving the security goals defined in "RFC3414". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language. . . . . . . . . . . . . . . . . 4 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Issues with USM. . . . . . . . . . . . . . . . . . . . 4 2.2. Design Considerations . . . . . . . . . . . . . . . . . 4 3. Elements of the Solution . . . . . . . . . . . . . . . . . . . . 6 3.1. Key Setup Protocol . . . . . . . . . . . . . . . . . . . 6 3.2. Key Request Protocol . . . . . . . . . . . . . . . . . . 8 3.3. EUSM Processing . . . . . . . . . . . . . . . . . . . . .10 3.4. Modifications to SNMPv3 View Based Access Control (VACM).11 3.5. Key Caching . . . . . . . . . . . . . . . . . . . . . . .11 3.5.1. Handling Cache Synchronization Issues. . . . . . 12 3.6 Security Context Identification . . . . . . . . . . . . .13 3.7 RADIUS Server Failover . . . . . . . . . . . . . . . . 14 4. Dependencies on Work in Progress. . . . . . . . . . . . . . . . 14 4.1. Extensible Authentication Protocol (EAP) . . . . . . . .14 4.2. RADIUS. . . . . . . . . . . . . . . . . . . . . . . . . .14 4.3. Protocol for carrying Authentication for Network Access .14 5. Security Considerations. . . . . . . . . . . . . . . . . . . . .15 6. IPv6 Considerations. . . . . . . . . . . . . . . . . . . . . . .15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 10. Intellectual Property Statement . . . . . . . . . . . . . . . . 18 Narayan et al. Expires Aug 2005 [Page 2] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 1. Introduction SNMPv3 provides a framework for user identity based authentication, privacy and granular access control. SNMPv3 aids secure manageability and overcomes one of major drawbacks in previous versions of the SNMP standard. There has been a significant lack of uptake for deployment of SNMPv3, and a number of organizations are still using SNMPv1/SNMPv2c. This is because SNMPv3 does not integrate with authentication systems currently used by existing management interfaces like the device command line interfaces. This specification defines a new security model for SNMPv3, the External User Security Model (EUSM). The EUSM primarily addresses the same threats as defined in the SNMPv3 USM Specification [RFC3414], this model intends to achieve the same goals as USM, this model intends to remove the constraint, i.e. "The security protocol nor its underlying security mechanisms should depend upon the ready availability of other network services". This EUSM model will use out-of-band authentication protocols to establish keying material for the user for achieving the security goals defined in [RFC3414]. EUSM is exactly similar to USM in all aspects, except for one key difference, that security information is established dynamically, as opposed to having it permanently stored in the Local Configuration Datastore. The use of out-of-band authentication protocols, namely the Extensible Authentication Protocol (EAP), allows EUSM to support a variety of authentication systems such as RADIUS servers, X.509 certificates, Local Accounts and Kerberos. EUSM defines a framework for SNMPv3 authentication and key distribution. The Extensible Authentication Protocol (EAP) has been commonly used in 802.1x environments for authentication and key establishment, this specification leverages work done in that area. This memo allows SNMPv3 authentication and privacy keys to be established out-of-band based on credentials managed locally on devices hosting the SNMP engines or credentials externally managed by a AAA server. Current schemes require SNMPv3 keys to be configured on a per engine basis. Support for a variety of local authentication systems in addition to support for external authentication via AAA protocols provides the advantage of allowing a common identity to be used with/shared across all management protocols since the other network management interfaces like device CLI and XML access are capable of authentication with the same authentication systems. Such sharing of common authentication systems removes the need for their separate maintenance, and thereby reduces administrative overhead. Narayan et al. Expires Aug 2005 [Page 3] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 1.1. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Overview EUSM describes the use of an out-of-band Key Setup Protocol for mutual authentication and setup of a security context to establish keys for SNMP engines. The security context refers to a pair of data structures that contain shared state information, which is required in order that per-message security services may be provided to SNMPv3 packets. Examples of state that are shared as part of a security context are cryptographic keys, and message sequence numbers. The security context specified here is different from the SNMP context described in [RFC3411]. The Key Setup protocol operates between SNMP engines or between the non-authoritative SNMP engine and a AAA server based on the desired authentication system to be used. In case a AAA server is involved, the non-authoritative SNMP engine will setup the security context with the AAA server prior to communicating with the authoritative SNMP engines. This specification recommends the use of the Extensible Authentication Protocol (EAP) as the Key Setup Protocol. As part of the establishment of a security context, the two SNMP engines or the non-authoritative SNMP engine and the AAA server are mutually authenticated, and on successful authentication, will generate a master session key. Keys derived from the master session key will be used to protect the communication between the two authenticated SNMP Engines or in case of the AAA server being involved, keys derived from the master session key will be used to protect the communication between the non-authoritative SNMP engine and all authoritative SNMP engines. This specification also describes a Key Request Protocol that is used by the authoritative SNMP engines to acquire session keys. The Key Request will not involve an over-the-wire protocol in case of authentication systems that do not involve an external AAA server. In case of authentication systems that do involve an external AAA server, the authoritative SNMP engines acquire these session keys from the AAA server via a Key Request Protocol. Narayan et al. Expires Aug 2005 [Page 4] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The AAA Server MUST derive the session keys for the authoritative SNMP engines. These per-engine "session" keys are derived from the master session key by the process of SNMPv3 key localization. RADIUS is the mandatory to implement external authentication mechanism , but any other AAA Protocol with similar characteristics could also be used. The authoritative SNMP engines also cache the session keys for a short time interval; this time interval is either locally configured or supplied by the RADIUS Server as part of response to Key Request Protocol based on the authentication system used. 2.1. Issues with USM SNMPv3 USM [RFC3414] requires the users and user keys to be configured on every SNMP engine. Although the process can be automated via a SNMPv3 user management application, it does require a configuration management application that can configure ten of thousands of network elements in real time. Further, the USM model creates a parallel universe of SNMPv3 users which are completely different from the users that are used by the other management interfaces like CLI, TCL engine and XML based programmatic interfaces (XMLCONF). 2.2. Design Considerations The design for EUSM are based on the following considerations: 1) The requirement of a scheme for SNMPv3 to support multiple authentication systems such as RADIUS, X.509 certificates, Local accounts and Kerberos to unify the approach for administrative security model for SNMPv3 and CLI. 2) The requirement for SNMPv3 to use strong authentication and key exchange and eliminate the need to use long term secrets to protect SNMPv3 packets. 3) The requirement for minimum number of changes, preferably none to the SNMPv3 packet format given the current status of the SNMPv3 standard. 4) The scheme MUST extend the capability of the AAA server to provide key material for authentication, privacy and integrity protection for SNMPv3 engines. 5) The scheme MUST provide support for a variety of client authentication mechanisms including passwords, tokens and certificates. 6) The scheme MUST to optimize the key management scheme to scale to large numbers of SNMP engines. 7) The scheme MUST distribute keys based on valid security context. 8) The scheme MUST ensure that a separate AAA request is not generated for every SNMP request. 9) This scheme MUST be generic and should apply to existing and future AAA protocols. Narayan et al. Expires Aug 2005 [Page 5] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3. Elements of the Solution 3.1. Key Setup Protocol The Extensible Authentication Protocol (EAP) will be used as the Key Setup Protocol. Not all EAP mechanisms may be suitable for this . The recommended mechanism depends upon the on desired authentication system as follows. a. EAP-TLS is RECOMMENDED to implement for authentication systems that do not require an external server and where the authentication conversation terminates on the SNMP engine. EAP-TLS supports several types of credentials with various ciphersuites. It supports X.509 PKI credentials using RSA and DSA based ciphersuites, it supports Kerberos with Kerberos based ciphersuites and it supports pre-shared keys using pre-shared key ciphersuites. The figure below illustrates the use of EAP-TLS method as part of Key Setup Protocol operating between two SNMP engines. This EAP method will be used for authentication systems that have credentials managed by the device hosting the SNMP engines. This EAP method will support authentication systems such as local accounts, X.509 certificates and Kerberos. ------------ PANA (EAP(EAP-TLS)), Key Setup Protocol ---------- | |<--------------------------------------->| | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| SNMPv3 message | (Author) | | |<--------------------------------------->| | | | | | ------------ ---------- *Author => Authoritative Figure 1: EUSM with EAP-TLS for local authentication systems The EAP-TLS exchange depicted above will setup the master session key on both SNMP engines. The SNMP engines will acquire session keys for communication from the EAP sub-system. In above exchange the EAP messages need to be transported within an appropriate transport protocol that can transport EAP, RADIUS is not usable since it would require all SNMP engines maintain shared secrets. Instead an IP based protocol used to carry EAP messages similar to the one defined by [PANA] can be used. Narayan et al. Expires Aug 2005 [Page 6] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 b. For authentication systems that require the transmission of password based credentials such as one time passwords or plaintext passwords to an external server, such as a RADIUS server, a tunneled mechanism such as PEAP or TTLS MUST be used. PEAPv2 is RECOMMENDED to implement. PEAPv2 will be used as the Key Setup Protocol in EUSM to support RADIUS authentication. The EAP messages can be transported in two modes, the specification supports both modes of transport. The figure below depicts the first mode, the RADIUS protocol is used as transport. The RADIUS protocol is used to carry the EAP messages between the non-authoritative SNMP engine and the RADIUS server. This scheme requires all non-authoritative SNMP engines to have explicit knowledge of the RADIUS server. ------------ SNMPv3 message ---------- | |<---------------------------------------->| | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| | (Author) | | | | | ------------ ---------- ^ ^ | | | | | | | RADIUS (EAP (PEAPv2)) RADIUS Protocol | | Key Setup Protocol Acquire Session Keys | | | | | | --------- | ----------------------> | | <----------------- | RADIUS | | Server | | | --------- *Author => Authoritative Figure 2: EUSM with PEAPv2 for RADIUS authentication using RADIUS to transport EAP messages The second mode depicted in the figure below uses an IP based transport such as PANA to carry the EAP messages. This is similar to exchanges used in 802.1x environments. The non-authoritative SNMP engine is similar to a 802.1x supplicant and requires no knowledge of the RADIUS server. The PEAPv2 conversation between the non-authoritative SNMP engine and the RADIUS server is relayed through any one of the authoritative SNMP Engines. Narayan et al. Expires Aug 2005 [Page 7] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 PANA (EAP (PEAPv2)) ------------ Key Setup Protocol ----------- | | <------------------------------> | | | SNMP | | SNMP | | Engine | SNMPv3 message | Engine | |(Non-Author)| <------------------------------> | (Author) | | | | | ------------ ----------- ^ ^ | | RADIUS (EAP (PEAPv2)) | | RADIUS Key Setup Protocol | | Acquire | | Session | | Keys --------- | | | | <------------ | | RADIUS | | | Server | | | | <----------------- --------- *Author => Authoritative Figure 3: EUSM with PEAPv2 for RADIUS authentication using PANA to transport EAP messages Both modes described above only differ in the transport mechanism used for the Key Setup Protocol. All other aspects of this memo apply identically. The rest of this memo uses the first mode for illustration of EUSM for RADIUS authentication, all the flows and processing will identically apply to second scheme as well. 3.2. Key Request Protocol The SNMP engines would use Key Request to acquire session keys. In case of authentication using the EAP-TLS method for local authentication systems, the Key Request will not require an over-the-wire protocol. In case of RADIUS authentication, the authoritative SNMP engine MUST obtain the session keys from the RADIUS server using the RADIUS Key Request Protocol. The authoritative SNMP engine MUST provide the IP address of the non-authoritative SNMP engine and username as part of the Key Request Protocol. The username and IP address of the non-authoritative SNMP engine are used to identify the security contexts, in the future the use of a security context identifier (SCID) is desirable. Narayan et al. Expires Aug 2005 [Page 8] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The RADIUS server MUST make sure that it is distributing the keys to authoritative SNMP engines authorized to receive those keys by verifying the authoritative SNMP engines with their SNMPv3 engine IDs. This requires the RADIUS server to be administratively configured with the SNMPv3 Engine IDs for all the authoritative SNMP engines that would be requesting keys. The RADIUS key deliverance mechanism described in [KEYREQ] MUST be used to download keying material from Radius servers to authoritative SNMP engines. The RADIUS exchange between the RADIUS server and authoritative SNMP engine is illustrated in the Figure below. ------------ SNMPv3 Message ----------- | | <-------------------------> | | | SNMP | | SNMP | | Engine | | Engine | |(Non-Author)| | (Author) | | | | | ------------ ----------- ^ ^ | | |RADIUS Access_Request/ | |Access_Accept | |PEAP Exchange RADIUS Key_Request| RADIUS Key_Accept{ | { Key (App ID), | Key (Key, IV, Key ID | Calling-Station-ID,| Lifetime, App ID, | User-Name } | KEKID), | | SNMP-Protection-Type, | --------- | SNMP-Group-Name} | | | | -------------> | |<-------------- | RADIUS | | Server | | | --------- *Author => Authoritative Figure 4: EUSM with RADIUS key deliverance The RADIUS Key attribute defined in the [KEYREQ] is used without modification. The authoritative SNMP engine while processing the SNMPv3 packet MUST request the RADIUS server for keys relevant to that particular request, the username and non-authoritative SNMP engine IP address MUST be utilized as security context identifier to determine the SNMPv3 keys relevant to the particular request. Narayan et al. Expires Aug 2005 [Page 9] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 The authoritative SNMP engine MUST construct a Key_Request and MUST include the Key attribute with the App ID field set to the value indicating that SNMPv3 is the application requesting the keys. The authoritative SNMP engine MUST also include the username from the received SNMPv3 packet in the User-Name attribute and the IP Address of the non-authoritative SNMP engine MUST be included in the Calling-Station-ID attribute. The request must also contain a message authentication attribute as defined in [KEYWRAP]. The RADIUS server on processing the Key_Request MUST reference the App ID field in the Key attribute to determine that the request represents an SNMPv3 key request from an SNMPv3 engine. The RADIUS Server MUST proceed to process the User-Name and Calling-Station-ID attributes and MUST obtain the appropriate master session key based on the username and IP Address of the non-authoritative SNMP engine. The RADIUS server MUST then create localized keys using the SNMP engine ID for the authoritative SNMP engine requesting the keys. The Radius Server MUST then construct an Key_Accept and include the Key attribute, the Key attribute will carry the localized key, the Initialization Vector (IV), the Key Lifetime, Key ID, the KEK ID and App ID. The App ID included in the key attribute should be the same as the App ID received in the request. The Key Lifetime represents the duration of time beyond which the authoritative SNMP engine MUST NOT cache the keys retrieved from the RADIUS server. The RADIUS Server MUST also include the SNMP-Protection-Type and SNMP-Group-Name attributes, the SNMP-Protection-Type attribute specifies the SNMP encryption and authentication protocols to be used. The SNMP-Group-Name attribute specifies the VACM group for the user. The SNMPv3 authentication and privacy keys are placed in two separate Key attributes. 3.3. EUSM Processing The EUSM model will use EAP/RADIUS to establish keying material for the user for achieving the security goals defined in [RFC3414]. The EUSM will not modify the SNMPv3 message format defined in [RFC3414], there would only be a small change in the SNMP message processing. In case of packets received with the security model set to EUSM. authoritative SNMP engines will not use the USM Local Configuration Database (LCD); they would use the EUSM cache. The EUSM cache would be populated from the local EAP subsystem in case of authentication via locally defined credentials. The RADIUS request/response mechanism defined in section 3.2 will be used to support RADIUS authentication. Narayan et al. Expires Aug 2005 [Page 10] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.4 Modifications to SNMPv3 View Based Access Control (VACM) Processing for RADIUS authentication 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 Key Request mechanism server 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 Key Request mechanism 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." 3.5. Key Caching The key cache-time for the session keys cached on the authoritative SNMP engines should typically be in the range of 90-180 seconds, this duration represents the typical time window for a network management operation. In case a RADIUS authentication is used, this session key cache-time can be configured on the RADIUS server. The caching interval for the master session key, setup as part of the Key Setup Protocol would in the order of eight hours, this time interval can be configured on all non-authoritative SNMP engines, it can also be configured on the RADIUS server, in case RADIUS authentication is used. Narayan et al. Expires Aug 2005 [Page 11] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.5.1. Handling Cache Synchronization Issues This issue is only applicable to RADIUS authentication wherein a single master session key is used to derive session keys for multiple authoritative SNMP engines. The authoritative SNMP engines will cache the localized session keys for the duration of the session key cache time. In case the master session key changes during that time window, it would result in authentication failures for at least one request on all authoritative SNMP engines with valid session keys derived from that master session key. The authentication failure would be the only way to detect such synchronization issues which is not appropriate This memo defines a method to handle such cache synchronization issues, this is done by maintaining a residual timer on the master session key. Every time the RADIUS server responds to authoritative SNMP engine requests for session keys, it MUST save a residual timer on the master session key, the value of the timer will equal the session key cache time. There MUST be only one residual timer for a master session key and it MUST updated every time a localized key is distributed to authoritative SNMP engines. The RADIUS server during security context setup MUST check on any valid residual timer on the previous master session key, it SHOULD proceed with the key exchange but MUST return the residual timer value along with the new master session key. The non-authoritative SNMP engine MUST NOT use the new master session key until after expiry of the residual timer. This will prevent any synchronization issues between the per-engine session keys and master session keys. Implementation Note The residual timer will result in a small black out period for the non-authoritative SNMP engine during which time the non-authoritative SNMP engine MUST not send any SNMP messages to the authoritative SNMP engine. This really is not a significant problem since the only time the residual timer would be used is a case wherein the non-authoritative SNMP engine initiates a new Key Setup for a user within 90-180 secs of terminating an older security context for the same user. In such cases, network management operations performed by that user on the non-authoritative SNMP engine would be delayed for a few seconds. Most of the real time collection in network management applications are not tied to active user sessions and in such cases there will never be a residual timer set, a new security context for the network management system user would be created only on expiration of the older security context and the residual timer would never be set in such cases. Narayan et al. Expires Aug 2005 [Page 12] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.6. Security Context Identification for RADIUS authentication All references to "context" in this document refer to a security context which has no relationship to a SNMPv3 context; that is, a security context is independent of, and applies to all relevant SNMPv3 contexts. This memo uses the IP Address of the non-authoritative SNMP Engine and the username to identify the security context in case of RADIUS authentication. Alternate methods of security context identification like the use a Security Context ID are currently not possible, since that would involve changes to the SNMPv3 protocol. This method of security identification SHOULD be replaced with an appropriate Security Context ID in future revisions whenever possible. The use of IP Address of the non-authoritative SNMP engine doesn't result in any loss of functionality and this proposal is fully capable of supporting non-authoritative SNMP engines that use dynamic IP Address assignment. The design considerations for use of IP Address of the non-authoritative SNMP engine in this proposal are. 1) AAA protocol servers like RADIUS and TACACS+ servers use IP Address based association to authenticate requests from clients using the shared secret, the shared secrets are configured per client or one for several clients and the IP Address is used by the AAA server to determine the appropriate shared secret. This would mean that the RADIUS server would already have an IP Address based association with non-authoritative SNMP engines in case RADIUS transport is used. 2) This proposal does not use the IP Address for any long term association, the IP Address of the non-authoritative SNMP engine is used by the AAA server to index the appropriate master secret. The master secret is typically valid for the duration of 8 hours and the association with a particular non-authoritative SNMP engine's IP address will last only for that duration. Moreover in event of a reboot of the non-authoritative SNMP engine and reassignment of it's IP Address, the non-authoritative SNMP engine will create new master secrets for the new sessions initiated after the reboot. This makes this proposal capable of working with dynamic IP addresses. Narayan et al. Expires Aug 2005 [Page 13] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 3.7. RADIUS Server failover Network elements currently allow for definition of multiple RADIUS servers to handle failover. In case, all RADIUS servers are unreachable, the SNMPv3 EUSM allows failover to other authentication systems that use locally defined credentials such as local accounts. This allows SNMPv3 authentication to occur local to the device in case the network interface providing the transport to the AAA server goes down. This behavior is similar to other management interfaces like CLI that would be accessible via a local accounts in case the AAA server is unreachable. 4. Dependencies on work in progress This section specifies the dependency of EUSM on other work in progress within the IETF. 4.1. Extensible Authentication Protocol (EAP) This proposal makes use of the EAP framework which is defined in [EAP]. The optimization for operations on a large number of engines requires definition of the key hierarchy and key naming which is being worked on in [EAP-KEY]. For several types of credentials EAP-TLS [EAP-TLS] can be used, however for token card based credentials and password based credentials other mechanisms must be used. There are several mechanisms supported in deployed environments such as PEAP and EAP-TTLS. There is ongoing work in defining EAP-Methods for this purpose including [PEAP], [TTLS] and [EAP-POTP]. 4.2. RADIUS RADIUS already has specifications for carrying EAP in [RADIUS-EAP]. Existing mechanisms for the transport of key material are supported in RADIUS deployments of 802.11, however it is recommended that stronger protection mechanisms be used such as [KEYWRAP]. The optimization for support of operations on a large number of SNMP engines requires new RADIUS functionality and messages described in [KEYREQ]. 4.3. Protocol for carrying Authentication for Network Access (PANA) There are several layer 3 protocol which have been adapted to carry EAP. There currently are discussions within the PANA working group on extending the PANA solution to work in a multi-hop environment [MULTI-EAP]. This could make a good transport for the Key Setup Protocol for supporting authentication systems other than RADIUS. Narayan et al. Expires Aug 2005 [Page 14] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 5. Security Considerations PEAPv1 is susceptible to a man in the middle attack as described in [CompoundBinding]. The attack uses lack of mutual authentication during security context establishment, since the PEAP client is authenticated via the inner EAP method after the security context has been established. PEAPv2 [PEAP] mitigates the problem by creating a cryptographic binding between the inner and the outer protocols. This memo recommends the use of PEAPv2 to enable the use of the security enhancements. The master session key used to derive localized keys for SNMP engine SHOULD be completely random SHOULD have no co-relation to the user's password, the user's password is never used to seed any key derivation. The process of localization defined in [RFC3414] derives per authoritative SNMP engine session keys from the master session key using a one way hash (MD5), this effectively ensures that the compromise of the per authoritative SNMP engine session key does not compromise the master session key. The session keys are distributed to the authoritative SNMP engines from the AAA server by using RADIUS exchanges as defined in this memo. The security for this exchange would be based on the security provided by the underlying AAA protocol. The RADIUS Key Attribute is protected using the scheme defined in [KEYWRAP]. The AAA servers MUST make sure that the authoritative SNMP engines are authorized to receive the keys they are requesting. The usage of IPSec to protect these RADIUS and TACACS+ exchanges is recommended for better security. 6. IPv6 Considerations Every mention of "IP Address" in this document is intended to provide equivalent support for IPv6 and IPv4. For example, in MIB syntax, the usage would be of InetAddress, not IpAddress. 7. Acknowledgements Thanks (in no particular order) to Don Livinghouse, Eliot Lear, Glen Zorn, Greg Weber, Fabio Maino, Azita Kia, Barry Bruins, Mark Basinski, Jeremy Stieglitz, Arthur Zavalkovsky, Darren Potter for useful feedback. Narayan et al. Expires Aug 2005 [Page 15] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 8. References 8.1 Normative References [RFC3412] Case, J., "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 3412, STD 62, December 2002 [RFC3415] Wijen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 3415, STD 62, December 2002. [RFC3414] Wijen, B. and U. Blumenthal, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, STD 62, December 2002. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [KEYREQ] Zorn, G., Zhou H., Salowey J., "Session Key Transport in RADIUS", http://www.ietf.org /internet-drafts/draft-zorn- radius-keyreq-03.txt [KEYWRAP] Zorn, G., Zhang T., Walker J., Salowey J., "RADIUS Attributes for Key Delivery", http://www.ietf.org /internet-drafts/draft-zorn-radius-keywrap-03.txt [PEAP] Palekar, A., et al., "Protected EAP Protocol (PEAP)", draft -josefsson-pppext-eap-tls-eap-10.txt, Internet draft (work in progress), May 2004. [CompoundBinding] Puthenkulam, J., Lortz, V., Palekar, A. and D. Simon, "The Compound Authentication Binding Problem", draft-puthenkulam -eap-binding-04.txt, Internet Draft (work in progress), October 2003. Narayan et al. Expires Aug 2005 [Page 16] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 [PANA] D. Fosberg et al., "Protocol for Carrying Authentication for Network Access", draft-ietf-pana-pana-04.txt [EAP-KEY] Aboba et. Al. "Extensible Authentication Protocol (EAP) Key Management Framework", draft-ietf-eap-keying-04.txt, Internet Draft (work in progress). [TTLS] Funk, P. and S. Blake-Wilson, "EAP Tunneled TLS Authentication Protocol Version 1 (EAP-TTLSv1)", draft-funk-eap-ttls-v1-00.txt, Internet Draft (work in progress). [MULTI-EAP] Giraetta, et. Al. "Usage Scenarios and Requirements for Multi-hop EAP Lower Layer", draft-ohba-multihop-eap-00, Internet Draft (work in progress). 9. Authors' Addresses Kaushik Narayan Cisco Systems, Inc. 125 Rio Robbles San Jose, CA. 95134 USA Phone: +1-408-526-8168 EMail: kaushik@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 East Tasman Drive San Jose, CA. 95134-1706 USA Phone: +1-408-526-5260 EMail: kzm@cisco.com Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 USA Phone: +1-206-256-3380 EMail: jsalowey@cisco.com Narayan et al. Expires Aug 2005 [Page 17] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 10. Intellectual Property Considerations The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Full Copyright Notice Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayan et al. Expires Aug 2005 [Page 18] INTERNET-DRAFT External USM for SNMPv3 Feb 2005 --%--multipart-mixed-boundary-1.3064.1108965785--% Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms --%--multipart-mixed-boundary-1.3064.1108965785--%-- From isms-bounces@ietf.org Mon Feb 21 17:22:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22103; Mon, 21 Feb 2005 17:22:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3MJ6-0006oh-Pm; Mon, 21 Feb 2005 17:45:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Jyn-0007hY-7H; Mon, 21 Feb 2005 15:16:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3IyK-0007JE-0u for isms@megatron.ietf.org; Mon, 21 Feb 2005 14:11:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02231 for ; Mon, 21 Feb 2005 14:11:49 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3JKZ-0001wC-Mn for isms@ietf.org; Mon, 21 Feb 2005 14:34:56 -0500 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 LAA21542 for ; Mon, 21 Feb 2005 11:11:14 -0800 (PST) Received: from XCH-NWBH-02.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 j1LJBEI20393 for ; Mon, 21 Feb 2005 11:11:14 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Feb 2005 11:11:08 -0800 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 Date: Mon, 21 Feb 2005 11:11:07 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDC7E@xch-nw-09.nw.nos.boeing.com> Thread-Topic: My feedback on draft-ietf-isms-proposal-comparison-00.txt Thread-Index: AcUTt58myM4JqZIRQK6sVmw/z5+U+wEjbRVQ From: "Fleischman, Eric" To: X-OriginalArrivalTime: 21 Feb 2005 19:11:08.0081 (UTC) FILETIME=[18FC8A10:01C51849] X-Spam-Score: 2.0 (++) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Subject: [Isms] My feedback on draft-ietf-isms-proposal-comparison-00.txt 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: quoted-printable Co-workers, I am grateful to the authors of the "Comparison of Proposals..." document for providing a catalyst for our discussion, despite my disappointment in their analysis. Specifically, in Section 2.4.1 they mention only two current disadvantages to the USM. This surprised me because I thought that the WG had formed a pretty solid consensus on the need to address at least a third issue: Session security (i.e., SNMPv3 privacy key security). Certainly, one of the proposals, TLSM, was centrally and primarily addressing this important issue. Thus, it is difficult for me to understand how the authors could have overlooked this key issue as an additional discriminator for making their recommendation. In any case, the authors, while not acknowledging this third issue to be a problem nor using it as a discriminator, nevertheless considered it to be important enough to included as Section 3.4 (Sessions) within their recommendation. I find this disconnect to be very puzzling. >From where I sit, I recommend: 1) If EUSM is chosen as the starting place, that it be extended to include additional authentication infrastructures (i.e., Kerberos and PKI really must also be on the list) AND it be supplemented to more explicitly address Session security. For example, the group might want to consider merging EUSM with aspects of TLSM as a possible starting point. 2)However, I personally believe that SBSM is the more complete solution and offers a framework to scratch all of the articulated itches (e.g., the above 3 USM issues as well as my own prioritized list of 6 issues). I didn't notice an answer on the list to Wes' query below, but it seems to me that if that issue is indeed is the primary reason that the did authors not recommend SBSM as they stated, then an answer really needs to be provided (e.g., I puzzled by the same question as Wes asked).=20 The WG can either proceed bottom up or top down as a mechanism for proceeding from here. Taking EUSM, which is already deployed, and enhancing it to scratch all of the itches, could be a possible bottoms-up approach for the WG. However, a preferable Top-down approach (e.g., for Top-down people like me) is to take the solution with the most complete architectural foundation, SBSM, and define it to successive degrees of specificity.=20 It's the WG's call which approach is used. However, the purpose of this email is to state that addressing/solving SNMPv3 session issues/problems *MUST* also be a key design issue for this WG: The ultimate WG's recommendations need to be extended to also address session issues. --Eric -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 Sent: Tuesday, February 15, 2005 3:34 PM To: isms@ietf.org Subject: [Isms] clarification: protocol on the wire unchanged You know, many people say its a plus to have the protocol on the wire unchanged (IE, the security parameters format is still USM). I've yet to find someone that can explain the rational behind that? Some have argued code change required, but that doesn't make sense since you have to write code to support the new integration with whatever the new keying mechanism is. I don't buy any argument that all such integration code will be less than modifying the security parameters fields in all cases (unless of you course you don't have a set of BER routines available, but we all know everything does already). In short, all 3 protocols require new code in both the manager and the agent. Some of the protocols require new protocol extensions in other protocols (EG EUSM's needed modifications to Radius) and new code in the deployment base of those new protocols on both the manager and the agent (err... CG and CR) side of the transaction. Don't get me wrong, I'm not arguing that we should change it if we don't have to. I fail to see the "advantages" that people state are there for not changing it. (especially since all solutions to date will require new security protocol identifies anyway, so it's not like you can take any solutions protocol and throw it through an unmodified SNMPv3 stack in the first place (unless such a stack is already broken in that it ignores the security protocol identifier in the packet today)). --=20 Wes Hardaker Sparta _______________________________________________ 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@ietf.org Wed Feb 23 00:13:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09314; Wed, 23 Feb 2005 00:13:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3pCX-0001oj-2Y; Wed, 23 Feb 2005 00:36:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3jAu-0003DK-VO; Tue, 22 Feb 2005 18:10:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3c9v-00026U-JR for isms@megatron.ietf.org; Tue, 22 Feb 2005 10:41:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12728 for ; Tue, 22 Feb 2005 10:41:03 -0500 (EST) 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.33) id 1D3cWK-0000Er-Nq for isms@ietf.org; Tue, 22 Feb 2005 11:04:22 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2005 08:54:50 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,107,1107734400"; d="scan'208"; a="227806432:sNHT475179428" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1MFeVq8018001; Tue, 22 Feb 2005 07:40:31 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn7-799.cisco.com [10.21.147.31]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYI73778; Tue, 22 Feb 2005 07:40:29 -0800 (PST) Message-Id: <6.2.0.14.0.20050222073035.0408c328@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 22 Feb 2005 07:40:29 -0800 To: isms@ietf.org From: Kaushik Narayan Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Isms] Clarifications about EUSM 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi All, There have been some questions about the capability of EUSM to support multiple authentication systems such as X.509 certificates, Kerberos, Local accounts etc. in addition to RADIUS. We do not think that this is in conflict with the EUSM proposal and EUSM -02 draft addresses this requirement and elaborates on how these various authentication systems can be supported. EUSM recommends using EAP and does not depend upon RADIUS for its operation any more that EAP does. The authentication conversation could terminate on the SNMP engine such as when EAP-TLS is used with PKI, Kerberos or Local credentials. There was also a question about changes required to AAA protocols. The current EUSM proposal specifies an optimization wherein a single master session key can be used to derive session keys for multiple authoritative SNMP engines which requires new functionality in RADIUS, but this is not out of line with proposals that have been discussed in the IEEE for similar key distribution problems. Actually, if this optimization is not used then integration with RADIUS servers that already support 802.11 should work with little or no modification. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 23 17:31:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01675; Wed, 23 Feb 2005 17:31:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D45PS-0005rC-0j; Wed, 23 Feb 2005 17:55:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3km1-00067P-Ci; Tue, 22 Feb 2005 19:53:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3OZz-0005km-1M for isms@megatron.ietf.org; Mon, 21 Feb 2005 20:11:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07786 for ; Mon, 21 Feb 2005 20:11:04 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3OwF-0002b0-N7 for isms@ietf.org; Mon, 21 Feb 2005 20:34:14 -0500 Received: from smtpout1.bayarea.net ([209.128.95.10]) by mx2.foretec.com with esmtp (Exim 4.24) id 1D3OZp-0002d6-Ue for isms@ietf.org; Mon, 21 Feb 2005 20:11:02 -0500 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 j1M1ASdW028705 for ; Mon, 21 Feb 2005 17:10:28 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1M1AX52011222 for ; Mon, 21 Feb 2005 17:10:33 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1M1AWdi011212 for ; Mon, 21 Feb 2005 17:10:33 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 21 Feb 2005 17:10:32 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Isms] Section 2.3 results 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 HI, For all of us that have worked on SNMP over the years, we much appreciate voluteer efforts that will lead to broader deployment of the technology. And know from personal experience that it is difficult and time consuming to evaluate security aspects of a protocol. However, I'm confused by the eval I-D. Reading through it, section 2.2 lists the goals. These look in alignment with the WG charter. This is followed by section 2.3 that says "How well proposals satisfy the goals described above can be evaluated by looking at specific operational scenarios or use cases. ...." This looks pretty reasonable. Section 2.4 (and its contained subsections), then describe each proposal at a high level so that the details of the proposal do not have to be dug through. That seems reasonable. Next comes section 3 with recommendations. Here, the I-D writers seemed to get off track, and stated several incorrect items. Not so good. For example, section 3.2 says "The eval team recommends that the WG adopt an approach that can accommodate multiple security infrastructures concurrently. The EUSM proposal was the clearest in this regard..." This is CLEARLY not correct! Now the conclusion, section 3.7 comes up, and I have yet to see the evaluations called for in section 2.3. Instead I found conformance with goals not listed in section 2.2. That is, conformance with goals not found in the ISMS WG charter. Thus, I do not see how the eval authors came to their conclusion. Because of this, I believe that the eval I-D is fatally flawed, and should be discarded by the WG. The eval I-D does contain an interesting approach in looking at the architectures of the proposals, and this should be included, and extended in a replacement eval I-D. The replacement must focuses on the PRIMARY goal as stated in the WG charter. That is to create a security model for SNMPv3 that will meet the security and operational needs of network administrators by eliminating the authentication system specific to SNMPv3, and replacing it with one that reuses the existing (not just one) security infrastructures. The solution is further constrained to maximize useability in operational environments to achieve high deployment success and at the same time minimize implementation and deployment costs to minimize the time until deployment is possible. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 23 17:33:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02115; Wed, 23 Feb 2005 17:33:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D45RB-0005vB-8S; Wed, 23 Feb 2005 17:56:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmW-0006KS-6F; Tue, 22 Feb 2005 19:53:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3RkE-00006I-CL for isms@megatron.ietf.org; Mon, 21 Feb 2005 23:33:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03715 for ; Mon, 21 Feb 2005 23:33:50 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3S6Y-00026Z-8i for isms@ietf.org; Mon, 21 Feb 2005 23:57:03 -0500 Received: from smtpout1.bayarea.net ([209.128.95.10]) by mx2.foretec.com with esmtp (Exim 4.24) id 1D3Rk7-0007e2-CV for isms@ietf.org; Mon, 21 Feb 2005 23:33:51 -0500 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 j1M4XJdW027866 for ; Mon, 21 Feb 2005 20:33:19 -0800 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) (authenticated bits=0) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1M4XNjN031759 for ; Mon, 21 Feb 2005 20:33:24 -0800 Message-Id: <5.2.0.9.2.20050221200915.025ec9f0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 21 Feb 2005 20:33:11 -0800 To: isms@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Isms] Comments on EUSM I-D -02 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 HI, I just got through reading the -02 version of the EUSM I-D. And I must say it is a vastly different proposal than the -00 version. If it had three small changes, then I could live with it. These are: 1) use SNMP to carry EAP (that is, use SNMP as the key setup protocol) 2) drop the use of a key request protocol, since it it is not really needed! 3) drop the religion of message syntax compatibility with SNMPv3/USM When the above changes are done, the result will be very much like SBSM! The remaining difference will be how replay detection is done. SBSM support for replay detection resolves two nasty operational issues in SNMPv3/USM, and, thus, I believe its value exceeds the cost. The two issues in USM, but not in SBSM are: 1) retries due to drops, busy managed systems, or variation operation execution cause cascading buildup of load 2) the receiver being the authoritative engine on informs causes unnecessary administrative complication and duplication Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Feb 23 23:19:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15896; Wed, 23 Feb 2005 23:19:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Apq-0002k8-Hk; Wed, 23 Feb 2005 23:42:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43w3-0003RQ-I7; Wed, 23 Feb 2005 16:20:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D43w1-0003RK-OO for isms@megatron.ietf.org; Wed, 23 Feb 2005 16:20:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18833 for ; Wed, 23 Feb 2005 16:20:39 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D44Im-0002Do-EM for isms@ietf.org; Wed, 23 Feb 2005 16:44:13 -0500 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 j1NLKUTU013615 for ; Wed, 23 Feb 2005 13:20:30 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1NLKaqu002897 for ; Wed, 23 Feb 2005 13:20:36 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1NLKa2u002894 for ; Wed, 23 Feb 2005 13:20:36 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 23 Feb 2005 13:20:36 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Isms] Test message 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad HI, I sent 2 messages on monday, and neither one seemed to be sent to the mailing list. This is a check. regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 01:22:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00167; Thu, 24 Feb 2005 01:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cl2-0007eN-9B; Thu, 24 Feb 2005 01:45:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D45pm-0007yc-4D; Wed, 23 Feb 2005 18:22:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D45pj-0007w8-RV for isms@megatron.ietf.org; Wed, 23 Feb 2005 18:22:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11988 for ; Wed, 23 Feb 2005 18:22:16 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46CW-00006y-JX for isms@ietf.org; Wed, 23 Feb 2005 18:45:52 -0500 Received: from h-68-165-5-98.snvacaid.dynamic.covad.net ([68.165.5.98] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D45pg-0002c7-00 for isms@ietf.org; Wed, 23 Feb 2005 15:22:17 -0800 Message-ID: <016401c519fe$b72d15e0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B959@zcarhxm2.corp.nortel.com> Subject: Re: [Isms] proposal comparison I-D Date: Wed, 23 Feb 2005 15:23:43 -0800 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: 21c69d3cfc2dd19218717dbe1d974352 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Hi - (Sorry for the delay - I've been off-line since January.) > From: "Martin Soukup" > To: > Sent: Tuesday, February 15, 2005 5:01 AM > Subject: RE: [Isms] proposal comparison I-D ... > In section 3.5 of the proposal evaluation, a comparison between the key > provisioning for an external authentication source (AAA server) and the goal > of ISMS is made. It should be noted that the provisioning of a single key > per device rather than a key per-user-per-device is of a significantly > different complexity. During my discussions with non-SNMP people about USM and VACM, I've found that many had an important misconception about how key provisioning works, despite our best efforts in RFC 3415 appendix A and RFC 3414 Appendix A. One needs to "manually" key exactly ONE user, known as "initial". All other user creation and keying would be done in-band with SNMPv3. If someone is manually setting keys for any users other than "initial", they're not doing things the way the WG intended when the SNMPv3 documents were developed. > Also, there are numerous solutions and solutions in > progress to remove the need for this communication key provisioning for > standard external authentication protocols (e.g. Kerberos, RADIUS), and this > should appropriately be solved in the context of the AAA protocol and not > SNMP, IMO. ... The point in the evaluation is that AAA provisioning, (currently) requiring a key to be set in every device, needs the same amount of manual work as does using SNMPv3 as it was designed to be used. (Of course, some people seem intent on making more work for themselves.) You're absolutely right that *solving* that is AAA's problem, not SNMP's. The only thing I've seen in the SNMP space to address the problem is leap-of-faith solutions like the kick-start in RFC 2786. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 01:27:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02022; Thu, 24 Feb 2005 01:27:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cpn-0008Eg-KA; Thu, 24 Feb 2005 01:50:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41yg-0005rY-8H; Wed, 23 Feb 2005 14:15:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D41yf-0005qf-ET for isms@megatron.ietf.org; Wed, 23 Feb 2005 14:15:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01765 for ; Wed, 23 Feb 2005 14:15:10 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D42LJ-0006O9-FQ for isms@ietf.org; Wed, 23 Feb 2005 14:38:42 -0500 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 LAA27766; Wed, 23 Feb 2005 11:15:00 -0800 (PST) Received: from XCH-NWBH-02.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 j1NJExE08552; Wed, 23 Feb 2005 13:14:59 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Feb 2005 11:14:58 -0800 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] Clarifications about EUSM Date: Wed, 23 Feb 2005 11:14:57 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDC91@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrg From: "Fleischman, Eric" To: "Kaushik Narayan" X-OriginalArrivalTime: 23 Feb 2005 19:14:58.0026 (UTC) FILETIME=[F6DEDCA0:01C519DB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Kaushik, Thank you for this good news. I hoped that EUSM wouldn't have problems also supporting Kerberos and PKI-based authentication, but I needed you to verify that. Thank you for having done so. This support makes your proposal much more attractive to me. The final remaining point is to better understand how you enhance SNMP session security. For example, would it be possible for EUSM to leverage TLS (e.g., see http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt)? --Eric -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Tuesday, February 22, 2005 7:40 AM To: isms@ietf.org Subject: [Isms] Clarifications about EUSM Hi All, There have been some questions about the capability of EUSM to support multiple authentication systems such as X.509 certificates, Kerberos, Local accounts etc. in addition to RADIUS. We do not think that this is in conflict with the EUSM proposal and EUSM -02 draft addresses this requirement and elaborates on how these various authentication systems can be supported. EUSM recommends using EAP and does not depend upon RADIUS for its operation any more that EAP does. The authentication conversation could terminate on the SNMP engine such as when EAP-TLS is used with PKI, Kerberos or Local credentials. There was also a question about changes required to AAA protocols. The current EUSM proposal specifies an optimization wherein a single master session key can be used to derive session keys for multiple authoritative SNMP engines which requires new functionality in RADIUS, but this is not out of line with proposals that have been discussed in the IEEE for similar key distribution problems. Actually, if this optimization is not used then integration with RADIUS servers that already support 802.11 should work with little or no modification. regards, kaushik! _______________________________________________ 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@ietf.org Thu Feb 24 01:29:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03214; Thu, 24 Feb 2005 01:29:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4CsA-0000Av-9O; Thu, 24 Feb 2005 01:53:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Eh-0005gK-2x; Wed, 23 Feb 2005 18:48:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D46Ee-0005fV-Su for isms@megatron.ietf.org; Wed, 23 Feb 2005 18:48:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16275 for ; Wed, 23 Feb 2005 18:48:01 -0500 (EST) Received: from pop-a065c32.pas.sa.earthlink.net ([207.217.121.247]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D46bR-0001Jm-TS for isms@ietf.org; Wed, 23 Feb 2005 19:11:38 -0500 Received: from h-68-165-5-98.snvacaid.dynamic.covad.net ([68.165.5.98] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D46Ed-0003Wq-00 for isms@ietf.org; Wed, 23 Feb 2005 15:48:03 -0800 Message-ID: <019501c51a02$50dacae0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B989@zcarhxm2.corp.nortel.com> Subject: Re: [Isms] achieving market saturation with ISMS Date: Wed, 23 Feb 2005 15:49:29 -0800 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: 769a46790fb42fbb0b0cc700c82f7081 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Hi - (Responding to points Wes and Martin raised, speaking for myself with some knowledge of the discussions that led to the evaluation report - ) > From: "Martin Soukup" > To: "'Wes Hardaker'" ; > Sent: Friday, February 18, 2005 1:06 AM > Subject: RE: [Isms] achieving market saturation with ISMS > > Wes, > > My understanding of the evaluation report was that there were two > mandatory-to-implement mechanisms, one implicit and the other explicit. The > explicit mechanism was in fact RADIUS but I believe the support of local > accounts was implicitly required as well (where the device acts as a RADIUS > key distributor) for clients connecting to it. Perhaps the evaluation team > can confirm? Local accounts were *NOT* a mandatory-to-implement mechanism from the perspective of the evaluation. Operationally, I do believe that USM users will need to be provisioned, in order to support fire-fighting access when AAA infrastructure is down. ... > I agree with Wes' point that the result of this effort should be careful to > address the requirement to make SNMPv3 deployment easy in existing > deployments but I would note that from this survey it would appear that > RADIUS is the market leader for centralized AAA, we just need to be sure to > support non-centralized AAA as well. I think most of the people on the list > have been saying this all along. ... The members of the evaluation team had no great love of RADIUS. The spirit of the recommendation was, I believe, "whatever AAA protocol that is useable that is most pervasive" should be mandatory to implement. Here's what bugs me about local accounts: The effort required to provision and maintain local accounts is arguably even greater than that required to maintain USM users, because at least the USM user maintenance is easily accomplished remotely through a highly standardized interface. If USM is too much work, then how would making local accounts be an improvement? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 02:41:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11938; Thu, 24 Feb 2005 02:41:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DzW-0005Qc-Ic; Thu, 24 Feb 2005 03:04:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DaZ-0004Wh-Np; Thu, 24 Feb 2005 02:39:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4DaW-0004TR-Lw for isms@megatron.ietf.org; Thu, 24 Feb 2005 02:39:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11716 for ; Thu, 24 Feb 2005 02:39:06 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4DxM-0005NO-8E for isms@ietf.org; Thu, 24 Feb 2005 03:02:45 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1CA299C7E; Thu, 24 Feb 2005 08:38:50 +0100 (CET) Received: from hermes.iu-bremen.de ([212.201.44.23]) by localhost (demetrius [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 06117-09; Thu, 24 Feb 2005 08:38:49 +0100 (CET) Received: from james (I8951.i.pppool.de [85.73.137.81]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id DF8A09C32; Thu, 24 Feb 2005 08:38:48 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1D4DaB-0000tu-9o; Thu, 24 Feb 2005 08:38:47 +0100 Date: Thu, 24 Feb 2005 08:38:47 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] achieving market saturation with ISMS Message-ID: <20050224073847.GA2284@james> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B989@zcarhxm2.corp.nortel.com> <019501c51a02$50dacae0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <019501c51a02$50dacae0$7f1afea9@oemcomputer> User-Agent: Mutt/1.5.6+20040907i X-Virus-Scanned: by amavisd-new 20030616p5 at demetrius.iu-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote: > Here's what bugs me about local accounts: > The effort required to provision and maintain local accounts is arguably > even greater than that required to maintain USM users, because at least > the USM user maintenance is easily accomplished remotely through a > highly standardized interface. If USM is too much work, then how would > making local accounts be an improvement? Local accounts are a reality on all boxes that I can think of. You telnet, ssh, whatever into local accounts as the default. On some installations, you find AAA setups to simplify the maintenance of accounts in the normal case (when the core network is running). The point is that USM does typically not interface with neither these local accounts nor AAA systems. In other words, USM is too much work because it is extra work in _addition_ to the management of local accounts or AAA accounts. [I am surprised that the core of the problem still seems to be not well understood.] /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@ietf.org Thu Feb 24 03:33:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16472; Thu, 24 Feb 2005 03:33:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Enq-0006XX-QG; Thu, 24 Feb 2005 03:56:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4EPU-0001q2-LT; Thu, 24 Feb 2005 03:31:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4EPS-0001pu-Ju for isms@megatron.ietf.org; Thu, 24 Feb 2005 03:31:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16305 for ; Thu, 24 Feb 2005 03:31:44 -0500 (EST) Message-Id: <200502240831.DAA16305@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4EmJ-0006VK-Sv for isms@ietf.org; Thu, 24 Feb 2005 03:55:24 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005022408313101300qdeeve>; Thu, 24 Feb 2005 08:31:31 +0000 From: "David B Harrington" To: , "'Randy Presuhn'" Subject: RE: [Isms] achieving market saturation with ISMS Date: Thu, 24 Feb 2005 03:31:27 -0500 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: <20050224073847.GA2284@james> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUaRDuaxqwEMaTpRLSVSKZe2kaLnwAA0HFQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Hi, I think the core problem is well understood, but many people simply aren't looking at the problem from the right direction, and making it harder for themelves. I suggest that USM and SNMPv3 could make it easier to maintain local and centralized accounts for SSH, telnet, web-based mgmt, and netconf. As Randy points out, only an "initial" user needs to be configured manually (or by default) in USM, and then subsequent users and passwords can be configured using SNMPv3. If we specified how implementers could utilize the USM MIB to store local accounts for all management interfaces, then the work would not be extra. With read-write SNMP agents, operators could configure their local accounts programatically and securely using SNMPv3. Converging the local accounts for SNMP and SSH and telnet and web-based mgmt and netconf would greatly reduce the extra work involved in configuring all these management interfaces. And if we add support for centralized AAA or key distribution to SNMPv3, that could also be used by the non-SNMP management interfaces. And if we converged data models and access controls, we could reduce the extra work of learning and configuring these for multiple management interfaces. Trying to force all management interfaces to emulate the CLI approach with its lack of standardized data models, lack of standardized access controls, and lack of standardized local accounts seems to be the wrong direction in my eyes. We should be striving for convergence via the use of standard data models, standardized access controls, standardized local accounts, and standardized support for centralized AAA, and SNMPv3 is the leader in providing such standardization, except, so far, for the centralized AAA support. 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: Thursday, February 24, 2005 2:39 AM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] achieving market saturation with ISMS > > On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote: > > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local > accounts is arguably > > even greater than that required to maintain USM users, > because at least > > the USM user maintenance is easily accomplished remotely through a > > highly standardized interface. If USM is too much work, > then how would > > making local accounts be an improvement? > > Local accounts are a reality on all boxes that I can think of. You > telnet, ssh, whatever into local accounts as the default. On some > installations, you find AAA setups to simplify the maintenance of > accounts in the normal case (when the core network is running). > The point is that USM does typically not interface with neither > these local accounts nor AAA systems. In other words, USM is too > much work because it is extra work in _addition_ to the management > of local accounts or AAA accounts. [I am surprised that the core > of the problem still seems to be not well understood.] > > /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@ietf.org Thu Feb 24 09:15:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22611; Thu, 24 Feb 2005 09:15:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4K9T-0006jg-2n; Thu, 24 Feb 2005 09:39:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JlP-0003Zv-HM; Thu, 24 Feb 2005 09:14:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4JlN-0003Zg-Ru for isms@megatron.ietf.org; Thu, 24 Feb 2005 09:14:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22317 for ; Thu, 24 Feb 2005 09:14:44 -0500 (EST) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4K8I-0006gf-6t for isms@ietf.org; Thu, 24 Feb 2005 09:38:26 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1OEEZKF025653 for ; Thu, 24 Feb 2005 14:14:35 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 j1OEESaI004013 for ; Thu, 24 Feb 2005 14:14:35 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 M2005022406143531721 for ; Thu, 24 Feb 2005 06:14:35 -0800 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, 24 Feb 2005 06:14:35 -0800 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, 24 Feb 2005 06:14:35 -0800 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, 24 Feb 2005 09:14:34 -0500 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] proposal comparison I-D Date: Thu, 24 Feb 2005 09:14:25 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD6A48@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] proposal comparison I-D Thread-Index: AcUaOR/c6PajvMfrTvu/1oIqF5qhEwAQMcRA From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 24 Feb 2005 14:14:34.0375 (UTC) FILETIME=[2A59B970:01C51A7B] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Excellent points, Randy! More inline. -----Original Message----- >> In section 3.5 of the proposal evaluation, a comparison between the key >> provisioning for an external authentication source (AAA server) and the goal >> of ISMS is made. It should be noted that the provisioning of a single key >> per device rather than a key per-user-per-device is of a significantly >> different complexity. > > During my discussions with non-SNMP people about USM and VACM, > I've found that many had an important misconception about how key > provisioning works, despite our best efforts in RFC 3415 appendix A > and RFC 3414 Appendix A. One needs to "manually" key exactly ONE > user, known as "initial". All other user creation and keying would be > done in-band with SNMPv3. I can only wonder what is missing from our documents to allow for such a crucial misconception. > If someone is manually setting keys for any users other than "initial", > they're not doing things the way the WG intended when the SNMPv3 > documents were developed. >> Also, there are numerous solutions and solutions in >> progress to remove the need for this communication key provisioning for >> standard external authentication protocols (e.g. Kerberos, RADIUS), and this >> should appropriately be solved in the context of the AAA protocol and not >> SNMP, IMO. No protocol can possibly remove the need for initial provisioning. But once that one protocol itself has been provisioned - through it other protocols can be "initialized". After that each of those protocols can in turn perform its own user administration, or leave it to that first protocol. Amount of work is likely to be the same. > The point in the evaluation is that AAA provisioning, (currently) requiring a > key to be set in every device, needs the same amount of manual work as > does using SNMPv3 as it was designed to be used. (Of course, some > people seem intent on making more work for themselves.) You're absolutely > right that *solving* that is AAA's problem, not SNMP's. The only thing I've > seen in the SNMP space to address the problem is leap-of-faith solutions > like the kick-start in RFC 2786. Precisely. The only argument in favor of AAA is that some customers *already* have AAA deployed, so they may find it attractive *not* to deploy a second infrastructure for SNMP - but rather tie it to the existing AAA infrastructure. Starting from scratch - the amount of work to provision AAA keys or SNMPv3 keys is absolutely the same. Starting from AAA infrastructure - no extra keys are necessary, but a piece of software that would interact with both SNMPv3 and AAA to perform key management for SNMPv3, plus a standard defining how that piec of software should behave... Pretty much what we're doing here anyway. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 09:23:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23879; Thu, 24 Feb 2005 09:23:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KGT-000708-P6; Thu, 24 Feb 2005 09:46:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jr5-0007PF-4E; Thu, 24 Feb 2005 09:20:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jr3-0007Oa-4R for isms@megatron.ietf.org; Thu, 24 Feb 2005 09:20:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23403 for ; Thu, 24 Feb 2005 09:20:35 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KDx-0006t1-Hi for isms@ietf.org; Thu, 24 Feb 2005 09:44:18 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1OEKRBE005117 for ; Thu, 24 Feb 2005 14:20:27 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 j1OEK2aW008947 for ; Thu, 24 Feb 2005 14:20:27 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 M2005022406202732297 for ; Thu, 24 Feb 2005 06:20:27 -0800 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, 24 Feb 2005 06:20:27 -0800 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, 24 Feb 2005 06:20:26 -0800 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, 24 Feb 2005 09:20:26 -0500 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] Clarifications about EUSM Date: Thu, 24 Feb 2005 09:20:18 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD6A53@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrgACgK/XA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 24 Feb 2005 14:20:26.0029 (UTC) FILETIME=[FBF3DDD0:01C51A7B] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: quoted-printable There are two issues: (a) user and key management, and (b) providing per-message security. Some say that USM provides adequate per-message security (especially with AES draft), and what's missing is convenient key management that's tied to other existing infrastructure such as RADIUS or Kerberos. Interests and requirements of those will be addressed by this WG, hopefully to everybody's satisfaction. Others say that USM itself isn't secure enough for them, and other per-message protection mechanisms are necessary. These folks should design their own security model, utilizing whatever mechanisms they fancy (DTLS, for example) - and submit their drafts as additional security models for SNMPv3 (as v3 architecture allows multiple security models). Within that model they're free to use any key management approach they like. But this work is out of scope for this WG, IMHO. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Wednesday, February 23, 2005 2:15 PM To: Kaushik Narayan Cc: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Kaushik, Thank you for this good news. I hoped that EUSM wouldn't have problems also supporting Kerberos and PKI-based authentication, but I needed you to verify that. Thank you for having done so. This support makes your proposal much more attractive to me. The final remaining point is to better understand how you enhance SNMP session security. For example, would it be possible for EUSM to leverage TLS (e.g., see http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt)? --Eric -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Tuesday, February 22, 2005 7:40 AM To: isms@ietf.org Subject: [Isms] Clarifications about EUSM Hi All, There have been some questions about the capability of EUSM to support multiple authentication systems such as X.509 certificates, Kerberos, Local accounts etc. in addition to RADIUS. We do not think that this is in conflict with the EUSM proposal and EUSM -02 draft addresses this requirement and elaborates on how these various authentication systems can be supported. EUSM recommends using EAP and does not depend upon RADIUS for its operation any more that EAP does. The authentication conversation could terminate on the SNMP engine such as when EAP-TLS is used with PKI, Kerberos or Local credentials. There was also a question about changes required to AAA protocols. The current EUSM proposal specifies an optimization wherein a single master session key can be used to derive session keys for multiple authoritative SNMP engines which requires new functionality in RADIUS, but this is not out of line with proposals that have been discussed in the IEEE for similar key distribution problems. Actually, if this optimization is not used then integration with RADIUS servers that already support 802.11 should work with little or no modification. regards, kaushik! _______________________________________________ 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@ietf.org Thu Feb 24 09:25:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24131; Thu, 24 Feb 2005 09:25:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KIN-00073y-K7; Thu, 24 Feb 2005 09:48:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Juc-0000wJ-3h; Thu, 24 Feb 2005 09:24:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Jub-0000w2-5q for isms@megatron.ietf.org; Thu, 24 Feb 2005 09:24:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24013 for ; Thu, 24 Feb 2005 09:24:15 -0500 (EST) Received: from fmr16.intel.com ([192.55.52.70] helo=fmsfmr006.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KHV-00071n-Qy for isms@ietf.org; Thu, 24 Feb 2005 09:47:58 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1OEO8KF030389; Thu, 24 Feb 2005 14:24:08 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 j1OENVae012175; Thu, 24 Feb 2005 14:24:07 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 M2005022406240732644 ; Thu, 24 Feb 2005 06:24:07 -0800 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, 24 Feb 2005 06:24:07 -0800 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, 24 Feb 2005 06:24:07 -0800 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, 24 Feb 2005 09:24:05 -0500 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] achieving market saturation with ISMS Date: Thu, 24 Feb 2005 09:23:57 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD6A5F@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS Thread-Index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpg From: "Blumenthal, Uri" To: "Randy Presuhn" , X-OriginalArrivalTime: 24 Feb 2005 14:24:06.0030 (UTC) FILETIME=[7F155AE0:01C51A7C] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable > Here's what bugs me about local accounts: > The effort required to provision and maintain local accounts is arguably > even greater than that required to maintain USM users, because at least > the USM user maintenance is easily accomplished remotely through a > highly standardized interface. If USM is too much work, then how would > making local accounts be an improvement? IMHO, the answer is "Simply Not My Problem". I think that proponents of this approach hope that local accounts somehow will have to be provisioned [for the box to function properly] AND SOMEBODY ELSE WILL HAVE TO TAKE CARE OF THAT. So if they just offer an interface to local account-based authentication, they'll avoid all the provisioning needs. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 10:06:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28840; Thu, 24 Feb 2005 10:06:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Kwg-00088B-Pn; Thu, 24 Feb 2005 10:30:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4KVQ-0007EY-Hv; Thu, 24 Feb 2005 10:02:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4KVO-0007EL-M4 for isms@megatron.ietf.org; Thu, 24 Feb 2005 10:02:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28220 for ; Thu, 24 Feb 2005 10:02:16 -0500 (EST) Message-Id: <200502241502.KAA28220@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4KsI-00080v-LS for isms@ietf.org; Thu, 24 Feb 2005 10:25:59 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005022415020501500l6fkie>; Thu, 24 Feb 2005 15:02:05 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , "'Randy Presuhn'" , Subject: RE: [Isms] achieving market saturation with ISMS Date: Thu, 24 Feb 2005 10:01:56 -0500 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: <3DEC199BD7489643817ECA151F7C5929BD6A5F@pysmsx401.amr.corp.intel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpgAABkeiA= X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Hi, I'm a proponent of having local accounts as a fallback to centralized accounts. I believe this is important for troubleshooting broken networks when a AAA server or centralized key distribution infrastructure may not be reachable. I don't think we should just provide an interface to local accounts that are somehow provisioned in a way that is "simply not my problem". I think we should make both provisioning of local accounts and leveraging centralized accounts part of the SNMPv3 solution. What we need to do is to show that having SNMP do the provisioning for the local accounts for all management interfaces would be easier than provisioning the local accounts of different management interfaces using different mechanisms. The biggest win would be to converge the multiple local account databases into one consistent local account database that is manageable using any of the (equivalently-secure) management interfaces. To do this means we need to develop a standard virtual data model for a user-authentication database that can be used by the different user-authentication mechanisms supported by different management interfaces (e.g. the USM-MIB). We would also need to develop equivalent (or at least balanced) security for each of the management interfaces, so one interface doesn't provide less protection of the keys than other interfaces. If SNMPv3 uses its own unique security model, then we'll need to figure out how to provide equivalenet security for other management protocols to converge them; it would be easier to achieve equivalent security by having SNMP adopt the existing security solutions used by other management interfaces (even if this might mean lessening the strength of SNMPv3 security to match the other solutions). David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, February 24, 2005 9:24 AM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS > > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local accounts is > arguably > > even greater than that required to maintain USM users, because at > least > > the USM user maintenance is easily accomplished remotely through a > > highly standardized interface. If USM is too much work, then how > would > > making local accounts be an improvement? > > IMHO, the answer is "Simply Not My Problem". I think that > proponents of > this approach hope that local accounts somehow will have to be > provisioned [for the box to function properly] AND SOMEBODY ELSE WILL > HAVE TO TAKE CARE OF THAT. So if they just offer an interface to local > account-based authentication, they'll avoid all the > provisioning needs. > :-) > > _______________________________________________ > 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@ietf.org Thu Feb 24 11:53:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14798; Thu, 24 Feb 2005 11:53:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4McR-0003VV-8o; Thu, 24 Feb 2005 12:17:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MDz-0006HE-10; Thu, 24 Feb 2005 11:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4MDy-0006H9-GY for isms@megatron.ietf.org; Thu, 24 Feb 2005 11:52:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14614 for ; Thu, 24 Feb 2005 11:52:23 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40] helo=smtp2.netlab.nec.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Mau-0003SO-HB for isms@ietf.org; Thu, 24 Feb 2005 12:16:08 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp2.netlab.nec.de (Postfix) with ESMTP id E218610ECD for ; Thu, 24 Feb 2005 17:52:17 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 17:52:16 +0100 Date: Thu, 24 Feb 2005 17:52:33 +0100 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-OriginalArrivalTime: 24 Feb 2005 16:52:16.0941 (UTC) FILETIME=[327AB5D0:01C51A91] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Subject: [Isms] draft agenda for Minneapolis 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Dear all, Below please find a draft agenda for our Minneapolis session. Any 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 ============================================= Integrated Security Model for SNMP WG (isms) IETF #62 Monday 7, 2005 : 1930-2200 ============================================ Chairs: Ken Hornstein Juergen Quittek AGENDA: 1) Agenda bashing, WG Status ( 5 min) 2) Proposal Comparison (45 min) - presentation of draft-ietf-isms-proposal-comparison-00.txt 3) Discussion of WG direction (30 min) - on which solution approach will the WG focus its efforts? 4) Charter discussion (45 min) 5) Update of the EUSM proposal (optional) (20 min) - draft-kaushik-snmp-external-usm-02.txt 6) Wrap up ( 5 min) - action points, schedule for evalaution INTERNET DRAFTS: Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol) http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt Transport Layer Security Model (TLSM) for the Simple Network Management Protocol version 3 (SNMPv3) http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt A Session-Based Security Model (SBSM) for version 3 of the Simple Network Management Protocol (SNMPv3) http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt External User Security Model (EUSM) for version 3 of the Simple Network Management Protocol (SNMPv3) http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 14:35:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05229; Thu, 24 Feb 2005 14:35:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P8K-0008R4-S6; Thu, 24 Feb 2005 14:58:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ok1-0002T5-5f; Thu, 24 Feb 2005 14:33:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Ojz-0002Sr-U8 for isms@megatron.ietf.org; Thu, 24 Feb 2005 14:33:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04695 for ; Thu, 24 Feb 2005 14:33:37 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4P6v-0008KO-IS for isms@ietf.org; Thu, 24 Feb 2005 14:57:23 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D4Ojp-0005MZ-1i for isms@ietf.org; Thu, 24 Feb 2005 14:33:29 -0500 Date: Thu, 24 Feb 2005 14:33:58 -0500 From: Robert Story To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS Message-ID: <20050224143358.17a26160@aud> In-Reply-To: <019501c51a02$50dacae0$7f1afea9@oemcomputer> References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B989@zcarhxm2.corp.nortel.com> <019501c51a02$50dacae0$7f1afea9@oemcomputer> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit On Wed, 23 Feb 2005 15:49:29 -0800 Randy wrote: RP> Here's what bugs me about local accounts: RP> The effort required to provision and maintain local accounts is arguably RP> even greater than that required to maintain USM users, If we are talking about provisioning by hand, then that's probably true. RP> at least the USM user maintenance is easily accomplished remotely through a RP> highly standardized interface. If it's so easy, then were are the standardized tools to accomplish this? We're going to have trouble getting people to switch from existing methods of managing local accounts (eg Kerberos and NIS) to something that doesn't exist yet. (More on getting it to exist in a bit.) RP> If USM is too much work, then how would making local accounts be an RP> improvement? On Thu, 24 Feb 2005 09:23:57 -0500 Blumenthal, wrote: BU> IMHO, the answer is "Simply Not My Problem". I think that proponents of BU> this approach hope that local accounts somehow will have to be BU> provisioned [for the box to function properly] AND SOMEBODY ELSE WILL BU> HAVE TO TAKE CARE OF THAT. I think it's more like somebody else has already taken care of it. Obviously provisioning 100 new boxes will arguably require similar amounts of work for initial provisioning. But the idea here is to take advantage of existing infrastructure and tools. On Thu, 24 Feb 2005 10:01:56 -0500 David wrote: DBH> I think we should make both provisioning of local accounts and DBH> leveraging centralized accounts part of the SNMPv3 solution. What we DBH> need to do is to show that having SNMP do the provisioning for the DBH> local accounts for all management interfaces would be easier than DBH> provisioning the local accounts of different management interfaces DBH> using different mechanisms. I think David hit Randy's nail on the head here. It would be wonderful to have a standardized interface for user accounts. However, this isn't going to happen anytime soon, and it's out of scope for this WG. But I think the first step in this direction is in scope. First we need to get our foot in the door by integrating with existing infrastructure. In keeping with the SNMP tradition, this first step will be providing use and monitoring of the existing infrastructure (eg read-only access). Once that is in place, we can move on to the more lofty goal of standardized management. --- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 14:45:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06697; Thu, 24 Feb 2005 14:45:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PI5-0000Kr-RU; Thu, 24 Feb 2005 15:08:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Osr-00053j-3O; Thu, 24 Feb 2005 14:42:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Osp-0004z6-6o for isms@megatron.ietf.org; Thu, 24 Feb 2005 14:42:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06445 for ; Thu, 24 Feb 2005 14:42:45 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PFl-0000Hd-Em for isms@ietf.org; Thu, 24 Feb 2005 15:06:31 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D4Osj-0005On-Ad; Thu, 24 Feb 2005 14:42:41 -0500 Date: Thu, 24 Feb 2005 14:43:11 -0500 From: Robert Story To: "Blumenthal, Uri" Subject: Re: [Isms] Clarifications about EUSM Message-ID: <20050224144311.7e025912@aud> In-Reply-To: <3DEC199BD7489643817ECA151F7C5929BD6A53@pysmsx401.amr.corp.intel.com> References: <3DEC199BD7489643817ECA151F7C5929BD6A53@pysmsx401.amr.corp.intel.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-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: 7655788c23eb79e336f5f8ba8bce7906 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Thu, 24 Feb 2005 09:20:18 -0500 Blumenthal, wrote: BU> Others say that USM itself isn't secure enough for them, and other BU> per-message protection mechanisms are necessary. These folks should BU> design their own security model, utilizing whatever mechanisms they BU> fancy (DTLS, for example) - and submit their drafts as additional BU> security models for SNMPv3 (as v3 architecture allows multiple security BU> models). Within that model they're free to use any key management BU> approach they like. But this work is out of scope for this WG, IMHO. I think that this attitude is a bit extreme. For interoperability, the fewer security models the better. The WG must produce something that is no less secure than USM, but that doesn't mean it can't produce something more secure. I agree that additional per-message security shouldn't be the primary goal of the WG, but if a proposal offers better security, I think it is perfectly reasonable to take that into consideration while comparing the proposals. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 15:00:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08049; Thu, 24 Feb 2005 15:00:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PWp-0000eH-7c; Thu, 24 Feb 2005 15:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4P8m-0002cV-E5; Thu, 24 Feb 2005 14:59:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4P8l-0002cC-13 for isms@megatron.ietf.org; Thu, 24 Feb 2005 14:59:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07905 for ; Thu, 24 Feb 2005 14:59:12 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4PVi-0000c2-3V for isms@ietf.org; Thu, 24 Feb 2005 15:22:58 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1OJx4BE010376 for ; Thu, 24 Feb 2005 19:59:04 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 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 j1OJwfai001295 for ; Thu, 24 Feb 2005 19:59:04 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 M2005022411590417879 for ; Thu, 24 Feb 2005 11:59:04 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 11:59:04 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 11:59:04 -0800 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, 24 Feb 2005 14:59:02 -0500 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] achieving market saturation with ISMS Date: Thu, 24 Feb 2005 14:58:54 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD6DDD@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS Thread-Index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpgAABkeiAAB92aYA== From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 24 Feb 2005 19:59:02.0419 (UTC) FILETIME=[4976F630:01C51AAB] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Well, provisioning of local accounts is nice - but it requires a large chunk of software to do/manage it, plus an acceptable MIB... -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Thursday, February 24, 2005 10:02 AM To: Blumenthal, Uri; 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Hi, I'm a proponent of having local accounts as a fallback to centralized accounts. I believe this is important for troubleshooting broken networks when a AAA server or centralized key distribution infrastructure may not be reachable. I don't think we should just provide an interface to local accounts that are somehow provisioned in a way that is "simply not my problem". I think we should make both provisioning of local accounts and leveraging centralized accounts part of the SNMPv3 solution. What we need to do is to show that having SNMP do the provisioning for the local accounts for all management interfaces would be easier than provisioning the local accounts of different management interfaces using different mechanisms.=20 The biggest win would be to converge the multiple local account databases into one consistent local account database that is manageable using any of the (equivalently-secure) management interfaces. To do this means we need to develop a standard virtual data model for a user-authentication database that can be used by the different user-authentication mechanisms supported by different management interfaces (e.g. the USM-MIB).=20 We would also need to develop equivalent (or at least balanced) security for each of the management interfaces, so one interface doesn't provide less protection of the keys than other interfaces. If SNMPv3 uses its own unique security model, then we'll need to figure out how to provide equivalenet security for other management protocols to converge them; it would be easier to achieve equivalent security by having SNMP adopt the existing security solutions used by other management interfaces (even if this might mean lessening the strength of SNMPv3 security to match the other solutions). David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, February 24, 2005 9:24 AM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS >=20 > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local accounts is > arguably > > even greater than that required to maintain USM users, because at > least > > the USM user maintenance is easily accomplished remotely through a > > highly standardized interface. If USM is too much work, then how > would > > making local accounts be an improvement? >=20 > IMHO, the answer is "Simply Not My Problem". I think that=20 > proponents of > this approach hope that local accounts somehow will have to be > provisioned [for the box to function properly] AND SOMEBODY ELSE WILL > HAVE TO TAKE CARE OF THAT. So if they just offer an interface to local > account-based authentication, they'll avoid all the=20 > provisioning needs. > :-) >=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@ietf.org Thu Feb 24 15:12:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10724; Thu, 24 Feb 2005 15:12:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Pi7-0001I8-PX; Thu, 24 Feb 2005 15:35:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PKu-0002HK-3N; Thu, 24 Feb 2005 15:11:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4PKs-0002FV-52 for isms@megatron.ietf.org; Thu, 24 Feb 2005 15:11:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10646 for ; Thu, 24 Feb 2005 15:11:43 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Phn-0001G9-Dr for isms@ietf.org; Thu, 24 Feb 2005 15:35:29 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1OKBXBE015644 for ; Thu, 24 Feb 2005 20:11:33 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 j1OKBXaC026053 for ; Thu, 24 Feb 2005 20:11:33 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 M2005022412113217047 for ; Thu, 24 Feb 2005 12:11:32 -0800 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, 24 Feb 2005 12:11:21 -0800 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, 24 Feb 2005 12:11:21 -0800 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, 24 Feb 2005 15:11:20 -0500 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] Clarifications about EUSM Date: Thu, 24 Feb 2005 15:11:13 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD6DFA@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUaqQhUXW1pxdbeQCqqe0vSO/WAegAAnvaQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 24 Feb 2005 20:11:20.0059 (UTC) FILETIME=[0121E4B0:01C51AAD] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Right now there's exactly one security model. If another model is proposed - it will be two. "Few enough", IMHO. If the current model (USM) doesn't satisfy the needs of a subset of the users - why don't they design one that does? Define it, define its relation to VACM [or if VACM doesn't fit their needs too - OACM (Other Access Control Model)] and be done with it. SNMPv3 architecture has no problem with such an approach. And if it turns out that this new model is more popular than USM - the market will vote with money, and one model will supersede the other. A lot of protocols have negotiable choice of options, sub-protocols, cipher suites, etc. It doesn't seem to hurt interoperability. P.S. I noticed that I react strangely to terms like "more security", "better security", "more better products"...=20 -----Original Message----- From: Robert Story [mailto:rstory@freesnmp.com]=20 Sent: Thursday, February 24, 2005 2:43 PM To: Blumenthal, Uri Cc: isms@ietf.org Subject: Re: [Isms] Clarifications about EUSM On Thu, 24 Feb 2005 09:20:18 -0500 Blumenthal, wrote: BU> Others say that USM itself isn't secure enough for them, and other BU> per-message protection mechanisms are necessary. These folks should BU> design their own security model, utilizing whatever mechanisms they BU> fancy (DTLS, for example) - and submit their drafts as additional BU> security models for SNMPv3 (as v3 architecture allows multiple security BU> models). Within that model they're free to use any key management BU> approach they like. But this work is out of scope for this WG, IMHO. I think that this attitude is a bit extreme. For interoperability, the fewer security models the better. The WG must produce something that is no less secure than USM, but that doesn't mean it can't produce something more secure. I agree that additional per-message security shouldn't be the primary goal of the WG, but if a proposal offers better security, I think it is perfectly reasonable to take that into consideration while comparing the proposals. --=20 Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 16:00:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20520; Thu, 24 Feb 2005 16:00:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Q5g-0003zP-Bk; Thu, 24 Feb 2005 16:00:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Q4A-0002oG-R2; Thu, 24 Feb 2005 15:58:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Q49-0002lt-JP for isms@megatron.ietf.org; Thu, 24 Feb 2005 15:58:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20409 for ; Thu, 24 Feb 2005 15:58:31 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Q47-0003we-Rf for isms@ietf.org; Thu, 24 Feb 2005 15:58:33 -0500 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 j1OKwMTU010973; Thu, 24 Feb 2005 12:58:22 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1OKwRJw030137; Thu, 24 Feb 2005 12:58:27 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1OKwRLd030128; Thu, 24 Feb 2005 12:58:27 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 24 Feb 2005 12:58:27 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Quittek Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f HI, I would like to see a few changes made. Before item #2 below, lets add a 10 minute review of the problem that is to be solved and review of the operational scenarios. Then, after item #3 below, add time to talk about EVAL #2, since EVAL #1 is fatally flawed, and we need to do another one, with probably a different team. As I pointed out, the -02 version of EUSM is radially different from the -00 version, and closes the gap between it and SBSM. Lets add a new item to see what can be done to get a proposal that blends the two. The -02 EUSM depends on two NEW protocols - the key setup protocol and the Key Request Protocol. These are new, and a short presentation about them would be useful. Regards, /david t. perkins On Thu, 24 Feb 2005, Juergen Quittek wrote: > Dear all, > > Below please find a draft agenda for our Minneapolis session. > > Any 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 > > ============================================= > > > Integrated Security Model for SNMP WG (isms) > IETF #62 > Monday 7, 2005 : 1930-2200 > ============================================ > > Chairs: > > Ken Hornstein > Juergen Quittek > > AGENDA: > > 1) Agenda bashing, WG Status ( 5 min) > > 2) Proposal Comparison (45 min) > - presentation of > draft-ietf-isms-proposal-comparison-00.txt > > 3) Discussion of WG direction (30 min) > - on which solution approach will the WG > focus its efforts? > > 4) Charter discussion (45 min) > > > 5) Update of the EUSM proposal (optional) (20 min) > - draft-kaushik-snmp-external-usm-02.txt > > 6) Wrap up ( 5 min) > - action points, schedule for evalaution > > > INTERNET DRAFTS: > > Comparison of Proposals for Integrated Security Models for SNMP > (Simple Network Management Protocol) > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt > > Transport Layer Security Model (TLSM) for the Simple Network > Management Protocol version 3 (SNMPv3) > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt > > A Session-Based Security Model (SBSM) for version 3 of the Simple > Network Management Protocol (SNMPv3) > http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > > External User Security Model (EUSM) for version 3 of the Simple > Network Management Protocol (SNMPv3) > http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt > > > _______________________________________________ > 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@ietf.org Thu Feb 24 16:07:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21320; Thu, 24 Feb 2005 16:07:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4QCd-0004Jj-Bs; Thu, 24 Feb 2005 16:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4QAu-0000b4-Lp; Thu, 24 Feb 2005 16:05:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4QAs-0000ak-CH for isms@megatron.ietf.org; Thu, 24 Feb 2005 16:05:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21103 for ; Thu, 24 Feb 2005 16:05:28 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4QAq-0004Ff-Mk for isms@ietf.org; Thu, 24 Feb 2005 16:05:30 -0500 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 j1OL5ITU014496 for ; Thu, 24 Feb 2005 13:05:18 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1OL5OBQ000499 for ; Thu, 24 Feb 2005 13:05:24 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1OL5NrY000492 for ; Thu, 24 Feb 2005 13:05:23 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 24 Feb 2005 13:05:23 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b HI, This is a resend. Sorry if you get it twice, but it's VERY IMPORTANT. Regards, /david t. perkins ---------- Forwarded message ---------- Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) From: David T. Perkins To: Juergen Schoenwaelder Cc: Randy Presuhn , isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS HI, Juergen is so right. We covered this topic in the BOFs that lead up to the formation of ISMS. That is, when a box is set up, work is done to use other management interfaces. Unfortunately, to deploy SNMPv3/USM on the box, extra work has to be done. And for on-going operations, extra work needs to be done to support SNMPv3/USM. The ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this "extra" work. I believe the EVAL team didn't GET THIS, and thus, they came out with a fatally flawed I-D. Again, THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For example, they believed that boxes must continue to support USM, so if an authentication service was not available, there would be a fallback method to authentication. WRONG!! There is NO NEED for USM, except for backwards compatibility with the VERY small number of SNMPv3/USM managers. The WG will continue to go around in circles and come up with clever engineering solutions (because the EVAL authors and members of the WG are really smart engineers) until some basic understanding is reached on the operational problem to be solved. Please, WG chairs supply some guidance on solving the appropriate problem. Please ask the EVAL team, or a new team do the evals specified in section 2.3 of the EVAL I-D, and drop all of the other eval considerations that they added. On Thu, 24 Feb 2005, Juergen Schoenwaelder wrote: > On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote: > > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local accounts is arguably > > even greater than that required to maintain USM users, because at least > > the USM user maintenance is easily accomplished remotely through a > > highly standardized interface. If USM is too much work, then how would > > making local accounts be an improvement? > > Local accounts are a reality on all boxes that I can think of. You > telnet, ssh, whatever into local accounts as the default. On some > installations, you find AAA setups to simplify the maintenance of > accounts in the normal case (when the core network is running). > The point is that USM does typically not interface with neither > these local accounts nor AAA systems. In other words, USM is too > much work because it is extra work in _addition_ to the management > of local accounts or AAA accounts. [I am surprised that the core > of the problem still seems to be not well understood.] > > /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@ietf.org Thu Feb 24 20:15:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16016; Thu, 24 Feb 2005 20:15:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4U4a-0001jz-FK; Thu, 24 Feb 2005 20:15:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4U4A-0006ir-DL; Thu, 24 Feb 2005 20:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4U47-0006ik-Mr for isms@megatron.ietf.org; Thu, 24 Feb 2005 20:14:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15984 for ; Thu, 24 Feb 2005 20:14:44 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4U47-0001iu-K9 for isms@ietf.org; Thu, 24 Feb 2005 20:14:50 -0500 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 RAA22626; Thu, 24 Feb 2005 17:14:34 -0800 (PST) Received: from XCH-NWBH-02.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 j1P1EYE17538; Thu, 24 Feb 2005 19:14:34 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 17:14:33 -0800 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] Clarifications about EUSM Date: Thu, 24 Feb 2005 17:14:33 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCA8@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrgACgK/XAAFu53MA== From: "Fleischman, Eric" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 25 Feb 2005 01:14:33.0679 (UTC) FILETIME=[5D5FFDF0:01C51AD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Content-Transfer-Encoding: quoted-printable Come on now, Uri. There is no reason why we can't satisfy both needs in this one activity. Your final paragraph is completely disingenuous. I believe that the whole purpose of this WG is to finally make SNMPv3 security "secure enough" for everybody. If we aren't doing this, then we are wasting our time. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Thursday, February 24, 2005 6:20 AM To: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM There are two issues: (a) user and key management, and (b) providing per-message security. Some say that USM provides adequate per-message security (especially with AES draft), and what's missing is convenient key management that's tied to other existing infrastructure such as RADIUS or Kerberos. Interests and requirements of those will be addressed by this WG, hopefully to everybody's satisfaction. Others say that USM itself isn't secure enough for them, and other per-message protection mechanisms are necessary. These folks should design their own security model, utilizing whatever mechanisms they fancy (DTLS, for example) - and submit their drafts as additional security models for SNMPv3 (as v3 architecture allows multiple security models). Within that model they're free to use any key management approach they like. But this work is out of scope for this WG, IMHO. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Wednesday, February 23, 2005 2:15 PM To: Kaushik Narayan Cc: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Kaushik, Thank you for this good news. I hoped that EUSM wouldn't have problems also supporting Kerberos and PKI-based authentication, but I needed you to verify that. Thank you for having done so. This support makes your proposal much more attractive to me. The final remaining point is to better understand how you enhance SNMP session security. For example, would it be possible for EUSM to leverage TLS (e.g., see http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt)? --Eric -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Tuesday, February 22, 2005 7:40 AM To: isms@ietf.org Subject: [Isms] Clarifications about EUSM Hi All, There have been some questions about the capability of EUSM to support multiple authentication systems such as X.509 certificates, Kerberos, Local accounts etc. in addition to RADIUS. We do not think that this is in conflict with the EUSM proposal and EUSM -02 draft addresses this requirement and elaborates on how these various authentication systems can be supported. EUSM recommends using EAP and does not depend upon RADIUS for its operation any more that EAP does. The authentication conversation could terminate on the SNMP engine such as when EAP-TLS is used with PKI, Kerberos or Local credentials. There was also a question about changes required to AAA protocols. The current EUSM proposal specifies an optimization wherein a single master session key can be used to derive session keys for multiple authoritative SNMP engines which requires new functionality in RADIUS, but this is not out of line with proposals that have been discussed in the IEEE for similar key distribution problems. Actually, if this optimization is not used then integration with RADIUS servers that already support 802.11 should work with little or no modification. regards, kaushik! _______________________________________________ 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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Feb 24 20:18:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16663; Thu, 24 Feb 2005 20:18:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4U7Z-0001wi-A4; Thu, 24 Feb 2005 20:18:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4U77-00011E-P2; Thu, 24 Feb 2005 20:17:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4U76-0000sM-BW for isms@megatron.ietf.org; Thu, 24 Feb 2005 20:17:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16612 for ; Thu, 24 Feb 2005 20:17:49 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4U78-0001vp-G3 for isms@ietf.org; Thu, 24 Feb 2005 20:17:54 -0500 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 TAA25151; Thu, 24 Feb 2005 19:17:42 -0600 (CST) Received: from XCH-NWBH-02.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 j1P1HfE19624; Thu, 24 Feb 2005 19:17:42 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 17:17:40 -0800 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] achieving market saturation with ISMS Date: Thu, 24 Feb 2005 17:17:40 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCA9@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS Thread-Index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpgAABkeiAAB92aYAAOn5SQ From: "Fleischman, Eric" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 25 Feb 2005 01:17:40.0716 (UTC) FILETIME=[CCDB92C0:01C51AD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: quoted-printable There is a difference between ISMS provisioning local accounts and ISMS being designed with interfaces so that it could interwork with an existing IETF approach (e.g., RADIUS, COPS) to provision local accounts. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Thursday, February 24, 2005 11:59 AM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Well, provisioning of local accounts is nice - but it requires a large chunk of software to do/manage it, plus an acceptable MIB... -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Thursday, February 24, 2005 10:02 AM To: Blumenthal, Uri; 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Hi, I'm a proponent of having local accounts as a fallback to centralized accounts. I believe this is important for troubleshooting broken networks when a AAA server or centralized key distribution infrastructure may not be reachable. I don't think we should just provide an interface to local accounts that are somehow provisioned in a way that is "simply not my problem". I think we should make both provisioning of local accounts and leveraging centralized accounts part of the SNMPv3 solution. What we need to do is to show that having SNMP do the provisioning for the local accounts for all management interfaces would be easier than provisioning the local accounts of different management interfaces using different mechanisms.=20 The biggest win would be to converge the multiple local account databases into one consistent local account database that is manageable using any of the (equivalently-secure) management interfaces. To do this means we need to develop a standard virtual data model for a user-authentication database that can be used by the different user-authentication mechanisms supported by different management interfaces (e.g. the USM-MIB).=20 We would also need to develop equivalent (or at least balanced) security for each of the management interfaces, so one interface doesn't provide less protection of the keys than other interfaces. If SNMPv3 uses its own unique security model, then we'll need to figure out how to provide equivalenet security for other management protocols to converge them; it would be easier to achieve equivalent security by having SNMP adopt the existing security solutions used by other management interfaces (even if this might mean lessening the strength of SNMPv3 security to match the other solutions). David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, February 24, 2005 9:24 AM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS >=20 > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local accounts is > arguably > > even greater than that required to maintain USM users, because at > least > > the USM user maintenance is easily accomplished remotely through a=20 > > highly standardized interface. If USM is too much work, then how > would > > making local accounts be an improvement? >=20 > IMHO, the answer is "Simply Not My Problem". I think that > proponents of > this approach hope that local accounts somehow will have to be > provisioned [for the box to function properly] AND SOMEBODY ELSE WILL > HAVE TO TAKE CARE OF THAT. So if they just offer an interface to local > account-based authentication, they'll avoid all the > provisioning needs. > :-) >=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@ietf.org Thu Feb 24 21:25:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21969; Thu, 24 Feb 2005 21:25:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4VAh-0003Gb-MN; Thu, 24 Feb 2005 21:25:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VAD-0008Rs-JR; Thu, 24 Feb 2005 21:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VAA-0008Ri-HV for isms@megatron.ietf.org; Thu, 24 Feb 2005 21:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21955 for ; Thu, 24 Feb 2005 21:25:04 -0500 (EST) 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.33) id 1D4VAA-0003Fj-TG for isms@ietf.org; Thu, 24 Feb 2005 21:25:09 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 24 Feb 2005 18:36:31 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j1P2Ocq8021818 for ; Thu, 24 Feb 2005 18:24:38 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.63]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYL61679; Thu, 24 Feb 2005 18:24:43 -0800 (PST) Message-Id: <6.2.0.14.0.20050224180255.07b28bc0@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 24 Feb 2005 18:24:43 -0800 To: isms@ietf.org From: Kaushik Narayan Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Hi All, We would like the clarify that EUSM -02 draft does not have anything new. The use of EAP as the Key Setup Protocol was the basis of our original proposal. The only thing that has been changed in this draft is that we took the Evaluation team's advice and explained how the proposal could support authentication systems such as Kerberos, X.509 etc. Also, there aren't any new protocols introduced in this revision. In fact, it was an explicit design decision for EUSM that we would use existing protocols like EAP/RADIUS. regards, kaushik! At 12:58 PM 2/24/2005, David T. Perkins wrote: >HI, > >I would like to see a few changes made. > >Before item #2 below, >lets add a 10 minute review of the problem that is to >be solved and review of the operational scenarios. > >Then, after item #3 below, add time to talk about >EVAL #2, since EVAL #1 is fatally flawed, and we >need to do another one, with probably a different >team. > >As I pointed out, the -02 version of EUSM is radially >different from the -00 version, and closes the gap >between it and SBSM. Lets add a new item to see what >can be done to get a proposal that blends the two. > >The -02 EUSM depends on two NEW protocols - the >key setup protocol and the Key Request Protocol. >These are new, and a short presentation about them >would be useful. > >Regards, >/david t. perkins > >On Thu, 24 Feb 2005, Juergen Quittek wrote: > > > Dear all, > > > > Below please find a draft agenda for our Minneapolis session. > > > > Any 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 > > > > ============================================= > > > > > > Integrated Security Model for SNMP WG (isms) > > IETF #62 > > Monday 7, 2005 : 1930-2200 > > ============================================ > > > > Chairs: > > > > Ken Hornstein > > Juergen Quittek > > > > AGENDA: > > > > 1) Agenda bashing, WG Status ( 5 min) > > > > 2) Proposal Comparison (45 min) > > - presentation of > > draft-ietf-isms-proposal-comparison-00.txt > > > > 3) Discussion of WG direction (30 min) > > - on which solution approach will the WG > > focus its efforts? > > > > 4) Charter discussion (45 min) > > > > > > 5) Update of the EUSM proposal (optional) (20 min) > > - draft-kaushik-snmp-external-usm-02.txt > > > > 6) Wrap up ( 5 min) > > - action points, schedule for evalaution > > > > > > INTERNET DRAFTS: > > > > Comparison of Proposals for Integrated Security Models for SNMP > > (Simple Network Management Protocol) > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt > > > > Transport Layer Security Model (TLSM) for the Simple Network > > Management Protocol version 3 (SNMPv3) > > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt > > > > A Session-Based Security Model (SBSM) for version 3 of the Simple > > Network Management Protocol (SNMPv3) > > http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > > > > External User Security Model (EUSM) for version 3 of the Simple > > Network Management Protocol (SNMPv3) > > http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt > > > > > > _______________________________________________ > > 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@ietf.org Thu Feb 24 21:46:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23612; Thu, 24 Feb 2005 21:46:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4VUV-0003fq-6e; Thu, 24 Feb 2005 21:46:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VTl-0007Cv-4b; Thu, 24 Feb 2005 21:45:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4VTj-00078Q-BJ for isms@megatron.ietf.org; Thu, 24 Feb 2005 21:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23572 for ; Thu, 24 Feb 2005 21:45:16 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4VTl-0003ef-4y for isms@ietf.org; Thu, 24 Feb 2005 21:45:21 -0500 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 j1P2icTU029988; Thu, 24 Feb 2005 18:44:38 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1P2ihrD009881; Thu, 24 Feb 2005 18:44:43 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1P2ihFC009877; Thu, 24 Feb 2005 18:44:43 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 24 Feb 2005 18:44:43 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaushik Narayan Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: <6.2.0.14.0.20050224180255.07b28bc0@mira-sjc5-a.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 HI, Interesting.... If it's the same, then it doesn't support Kerboros, X.509 etc. nor local accounts. However, I believe the proposal has really been changed. It does, require two new protocols, which are the key setup and key request protocols. Maybe, not new from -00 to -02, but new, in that they are not defined in RFCs on the standards track, nor is there existing running code in commercial off the shelf products that I'm of. I can't tell if you are open or not to creating a blended approach using technology from EUSM and from SBSM. What is your position on this? What is your position on the three small changes that I suggested in a previous EMAIL. What are the pros and cons? Regards, /david t. perkins On Thu, 24 Feb 2005, Kaushik Narayan wrote: > Hi All, > > We would like the clarify that EUSM -02 draft does not have > anything new. The use of EAP as the Key Setup Protocol > was the basis of our original proposal. The only thing that > has been changed in this draft is that we took the Evaluation > team's advice and explained how the proposal could support > authentication systems such as Kerberos, X.509 etc. > > Also, there aren't any new protocols introduced in this revision. > In fact, it was an explicit design decision for EUSM that we > would use existing protocols like EAP/RADIUS. > > regards, > kaushik! > > > > At 12:58 PM 2/24/2005, David T. Perkins wrote: > >HI, > > > >I would like to see a few changes made. > > > >Before item #2 below, > >lets add a 10 minute review of the problem that is to > >be solved and review of the operational scenarios. > > > >Then, after item #3 below, add time to talk about > >EVAL #2, since EVAL #1 is fatally flawed, and we > >need to do another one, with probably a different > >team. > > > >As I pointed out, the -02 version of EUSM is radially > >different from the -00 version, and closes the gap > >between it and SBSM. Lets add a new item to see what > >can be done to get a proposal that blends the two. > > > >The -02 EUSM depends on two NEW protocols - the > >key setup protocol and the Key Request Protocol. > >These are new, and a short presentation about them > >would be useful. > > > >Regards, > >/david t. perkins > > > >On Thu, 24 Feb 2005, Juergen Quittek wrote: > > > > > Dear all, > > > > > > Below please find a draft agenda for our Minneapolis session. > > > > > > Any 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 > > > > > > ============================================= > > > > > > > > > Integrated Security Model for SNMP WG (isms) > > > IETF #62 > > > Monday 7, 2005 : 1930-2200 > > > ============================================ > > > > > > Chairs: > > > > > > Ken Hornstein > > > Juergen Quittek > > > > > > AGENDA: > > > > > > 1) Agenda bashing, WG Status ( 5 min) > > > > > > 2) Proposal Comparison (45 min) > > > - presentation of > > > draft-ietf-isms-proposal-comparison-00.txt > > > > > > 3) Discussion of WG direction (30 min) > > > - on which solution approach will the WG > > > focus its efforts? > > > > > > 4) Charter discussion (45 min) > > > > > > > > > 5) Update of the EUSM proposal (optional) (20 min) > > > - draft-kaushik-snmp-external-usm-02.txt > > > > > > 6) Wrap up ( 5 min) > > > - action points, schedule for evalaution > > > > > > > > > INTERNET DRAFTS: > > > > > > Comparison of Proposals for Integrated Security Models for SNMP > > > (Simple Network Management Protocol) > > > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt > > > > > > Transport Layer Security Model (TLSM) for the Simple Network > > > Management Protocol version 3 (SNMPv3) > > > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt > > > > > > A Session-Based Security Model (SBSM) for version 3 of the Simple > > > Network Management Protocol (SNMPv3) > > > http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > > > > > > External User Security Model (EUSM) for version 3 of the Simple > > > Network Management Protocol (SNMPv3) > > > http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 25 04:49:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23719; Fri, 25 Feb 2005 04:49:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4c6d-0004IS-OF; Fri, 25 Feb 2005 04:49:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c69-0004Ar-U3; Fri, 25 Feb 2005 04:49:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4c67-00048m-K0 for isms@megatron.ietf.org; Fri, 25 Feb 2005 04:49:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23608 for ; Fri, 25 Feb 2005 04:49:21 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40] helo=smtp2.netlab.nec.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4c6D-0004GT-LH for isms@ietf.org; Fri, 25 Feb 2005 04:49:30 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp2.netlab.nec.de (Postfix) with ESMTP id DA6C11316A; Fri, 25 Feb 2005 10:49:24 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 10:49:13 +0100 Date: Fri, 25 Feb 2005 10:49:33 +0100 From: Juergen Quittek To: "David T. Perkins" Subject: Re: [Isms] draft agenda for Minneapolis Message-ID: <0C86F0307701A7F2645ADFEB@[10.1.1.171]> 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-OriginalArrivalTime: 25 Feb 2005 09:49:13.0470 (UTC) FILETIME=[432A29E0:01C51B1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Content-Transfer-Encoding: 7bit Hi David, --On 24.02.2005 21:58 Uhr +0100 David T. Perkins wrote: > HI, > > I would like to see a few changes made. > > Before item #2 below, > lets add a 10 minute review of the problem that is to > be solved and review of the operational scenarios. I'd very much appreciate starting discussions on different understandings of the WG goals and operational scenarios as soon as possible on the mailing list. It is a good idea to remind the WG of its goals and to clarify them. However, goals and operational scenarios are the titles of sections 2.2 and 2.3 of the comparison I-D. So, I expect the presentation of the I-D to cover these issues. If you have a view that differs from what is stated in the comparison I-D, then I suggest that you prepare bring these issues to the mailing list and - depending on the progress of the discussion - prepare some slides stating your view. If we do not agree on our goals and operational scenarios, we will add this discussion to the agenda. > Then, after item #3 below, add time to talk about > EVAL #2, since EVAL #1 is fatally flawed, and we > need to do another one, with probably a different > team. This issue fits well in #3. During #2 there is time for identifying flaws in the evaluation. After we have got an idea of the list of flaws and their severity, we can discuss the issue in #3. But anyway, let's try to progress the discussion on flaws of the evaluation I-D as far as possible on the mailing list before the Minneapolis meeting. > As I pointed out, the -02 version of EUSM is radially > different from the -00 version, and closes the gap > between it and SBSM. Version -02 was not yet subject of the evaluation. It is intentionally discussed at the end of our session. We will discuss our WG direction rather independent of this version. However, if time allows we can discuss at the end of the session whether or not this modification of EUSM follows the way we want to go. > Lets add a new item to see what > can be done to get a proposal that blends the two. This discussion will be part of #3 and #4. The evaluation I-D came to the conclusion that neither of the three proposals matches all recommendations. It suggests taking EUSM as starting point for developing an ISMS that also integrates features of the other proposals. We will discuss which features of the three proposals need to be integrated. You may call this 'blending' them. > The -02 EUSM depends on two NEW protocols - the > key setup protocol and the Key Request Protocol. > These are new, and a short presentation about them > would be useful. I take this as a recommendation for Kaushik concerning the outline of his presentation on suggested EUSM modifications. 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 > Regards, > /david t. perkins > > On Thu, 24 Feb 2005, Juergen Quittek wrote: > >> Dear all, >> >> Below please find a draft agenda for our Minneapolis session. >> >> Any 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 >> >> ============================================= >> >> >> Integrated Security Model for SNMP WG (isms) >> IETF #62 >> Monday 7, 2005 : 1930-2200 >> ============================================ >> >> Chairs: >> >> Ken Hornstein >> Juergen Quittek >> >> AGENDA: >> >> 1) Agenda bashing, WG Status ( 5 min) >> >> 2) Proposal Comparison (45 min) >> - presentation of >> draft-ietf-isms-proposal-comparison-00.txt >> >> 3) Discussion of WG direction (30 min) >> - on which solution approach will the WG >> focus its efforts? >> >> 4) Charter discussion (45 min) >> >> >> 5) Update of the EUSM proposal (optional) (20 min) >> - draft-kaushik-snmp-external-usm-02.txt >> >> 6) Wrap up ( 5 min) >> - action points, schedule for evalaution >> >> >> INTERNET DRAFTS: >> >> Comparison of Proposals for Integrated Security Models for SNMP >> (Simple Network Management Protocol) >> http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt >> >> Transport Layer Security Model (TLSM) for the Simple Network >> Management Protocol version 3 (SNMPv3) >> http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt >> >> A Session-Based Security Model (SBSM) for version 3 of the Simple >> Network Management Protocol (SNMPv3) >> http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt >> >> External User Security Model (EUSM) for version 3 of the Simple >> Network Management Protocol (SNMPv3) >> http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt >> >> >> _______________________________________________ >> 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@ietf.org Fri Feb 25 05:48:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28451; Fri, 25 Feb 2005 05:48:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4d1g-0005bH-F5; Fri, 25 Feb 2005 05:48:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4d0k-0002RL-3g; Fri, 25 Feb 2005 05:47:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4d0g-0002PQ-VX for isms@megatron.ietf.org; Fri, 25 Feb 2005 05:47:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28385 for ; Fri, 25 Feb 2005 05:47:48 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40] helo=smtp2.netlab.nec.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4d0m-0005ZM-GQ for isms@ietf.org; Fri, 25 Feb 2005 05:47:57 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp2.netlab.nec.de (Postfix) with ESMTP id 313C4DC5E; Fri, 25 Feb 2005 11:47:52 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 11:47:40 +0100 Date: Fri, 25 Feb 2005 11:48:00 +0100 From: Juergen Quittek To: "David T. Perkins" , isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Message-ID: <0241A9801C5254335DE01455@[10.1.1.171]> 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-OriginalArrivalTime: 25 Feb 2005 10:47:40.0197 (UTC) FILETIME=[6D563D50:01C51B27] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit Hi David, --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > HI, > > This is a resend. Sorry if you get it twice, but > it's VERY IMPORTANT. > > Regards, > /david t. perkins > > ---------- Forwarded message ---------- > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > From: David T. Perkins > To: Juergen Schoenwaelder > Cc: Randy Presuhn , isms@ietf.org > Subject: Re: [Isms] achieving market saturation with ISMS > > HI, > > Juergen is so right. We covered this topic in the BOFs > that lead up to the formation of ISMS. > > That is, when a box is set up, work is done to use > other management interfaces. Unfortunately, to deploy > SNMPv3/USM on the box, extra work has to be done. And for > on-going operations, extra work needs to be done to support > SNMPv3/USM. The ABSOLUTELY PRIMARY goal of ISMS is to > ELIMINATE this "extra" work. Sorry, to which part of the I-D are you referring? > I believe the EVAL team > didn't GET THIS, and thus, they came out with a fatally > flawed I-D. Again, THEY DIDN'T UNDERSTAND THE PRIMARY > PROBLEM TO BE SOLVED! For example, Do you have more examples or even the full list? > they believed that > boxes must continue to support USM, so if an authentication > service was not available, there would be a fallback > method to authentication. WRONG!! What the I-D states is * Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution * ... * Must not break basic device discovery. (Retaining USM support would satisfy this goal.) I don't see a statement saying "boxes must continue to support USM". > There is NO NEED for > USM, except for backwards compatibility with the > VERY small number of SNMPv3/USM managers. Is there support for this statement by other WG members? > The WG will continue to go around in circles and come > up with clever engineering solutions (because the > EVAL authors and members of the WG are really smart > engineers) until some basic understanding is reached > on the operational problem to be solved. > > Please, WG chairs supply some guidance on solving > the appropriate problem. Please ask the EVAL team, > or a new team do the evals specified in section 2.3 > of the EVAL I-D, and drop all of the other > eval considerations that they added. > > On Thu, 24 Feb 2005, Juergen Schoenwaelder wrote: > >> On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote: >> >> > Here's what bugs me about local accounts: >> > The effort required to provision and maintain local accounts is arguably >> > even greater than that required to maintain USM users, because at least >> > the USM user maintenance is easily accomplished remotely through a >> > highly standardized interface. If USM is too much work, then how would >> > making local accounts be an improvement? >> >> Local accounts are a reality on all boxes that I can think of. You >> telnet, ssh, whatever into local accounts as the default. On some >> installations, you find AAA setups to simplify the maintenance of >> accounts in the normal case (when the core network is running). >> The point is that USM does typically not interface with neither >> these local accounts nor AAA systems. In other words, USM is too >> much work because it is extra work in _addition_ to the management >> of local accounts or AAA accounts. [I am surprised that the core >> of the problem still seems to be not well understood.] >> >> /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@ietf.org Fri Feb 25 08:51:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15598; Fri, 25 Feb 2005 08:51:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fsQ-00010C-Sn; Fri, 25 Feb 2005 08:51:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fnl-00056N-Vq; Fri, 25 Feb 2005 08:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fnk-00056E-Rj for isms@megatron.ietf.org; Fri, 25 Feb 2005 08:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15075 for ; Fri, 25 Feb 2005 08:46:39 -0500 (EST) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fnt-0000to-0t for isms@ietf.org; Fri, 25 Feb 2005 08:46:49 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1PDkQ5r009093 for ; Fri, 25 Feb 2005 13:46:26 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 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 j1PDkQ3O021206 for ; Fri, 25 Feb 2005 13:46:26 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 M2005022505462600595 for ; Fri, 25 Feb 2005 05:46:26 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 05:46:26 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 05:46:26 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 08:46:25 -0500 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] Clarifications about EUSM Date: Fri, 25 Feb 2005 08:46:17 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD7061@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrgACgK/XAAFu53MAAZ3rmg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 25 Feb 2005 13:46:25.0116 (UTC) FILETIME=[65E301C0:01C51B40] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: quoted-printable Eric, we had this discussion before. Security costs, both in performance degradation and administration. "Secure enough" means different levels with different costs for different people. For example, I don't want to be as secure as you want to - and pay the cost that you'll pay for that. This is why SNMPv3 from the beginning aimed at being modular and capable of using several security models, possibly at the same time within the same SNMP engine. The idea is - there's no "one sie fits all" solution. There will always be Erics for who the existing model isn't "secure enough", and then some other guys (name withheld to protect the guilty) for who SHA-1 is too slow - so it must be MD5, otherwise he cannot use message integrity; and then everything in between... Other security models are encouraged, especially if there is market demand for them. What's so difficult about this?! IMHO the one thing one has to take care designing a new security model is clean integration with SNMPv3 Access Control (VACM or other model if you care to create one) - make sure all the necessary information is collected and passed to it from your security model. And of course preserving the outer message wrapper so that the protocol engine can pass it to the right security model, would help. That's it!=20 What I want out of this WG is an easy clean method to integrate with other infrastructures, such that access to authorizing capabilities of SNMPv3 is available and clean. A method that can be used by any security model.=20 -----Original Message----- From: Fleischman, Eric [mailto:eric.fleischman@boeing.com]=20 Sent: Thursday, February 24, 2005 8:15 PM To: Blumenthal, Uri; isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Come on now, Uri. There is no reason why we can't satisfy both needs in this one activity. Your final paragraph is completely disingenuous. I believe that the whole purpose of this WG is to finally make SNMPv3 security "secure enough" for everybody. If we aren't doing this, then we are wasting our time. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Thursday, February 24, 2005 6:20 AM To: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM There are two issues: (a) user and key management, and (b) providing per-message security. Some say that USM provides adequate per-message security (especially with AES draft), and what's missing is convenient key management that's tied to other existing infrastructure such as RADIUS or Kerberos. Interests and requirements of those will be addressed by this WG, hopefully to everybody's satisfaction. Others say that USM itself isn't secure enough for them, and other per-message protection mechanisms are necessary. These folks should design their own security model, utilizing whatever mechanisms they fancy (DTLS, for example) - and submit their drafts as additional security models for SNMPv3 (as v3 architecture allows multiple security models). Within that model they're free to use any key management approach they like. But this work is out of scope for this WG, IMHO. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Wednesday, February 23, 2005 2:15 PM To: Kaushik Narayan Cc: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Kaushik, Thank you for this good news. I hoped that EUSM wouldn't have problems also supporting Kerberos and PKI-based authentication, but I needed you to verify that. Thank you for having done so. This support makes your proposal much more attractive to me. The final remaining point is to better understand how you enhance SNMP session security. For example, would it be possible for EUSM to leverage TLS (e.g., see http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt)? --Eric -----Original Message----- From: Kaushik Narayan [mailto:kaushik@cisco.com]=20 Sent: Tuesday, February 22, 2005 7:40 AM To: isms@ietf.org Subject: [Isms] Clarifications about EUSM Hi All, There have been some questions about the capability of EUSM to support multiple authentication systems such as X.509 certificates, Kerberos, Local accounts etc. in addition to RADIUS. We do not think that this is in conflict with the EUSM proposal and EUSM -02 draft addresses this requirement and elaborates on how these various authentication systems can be supported. EUSM recommends using EAP and does not depend upon RADIUS for its operation any more that EAP does. The authentication conversation could terminate on the SNMP engine such as when EAP-TLS is used with PKI, Kerberos or Local credentials. There was also a question about changes required to AAA protocols. The current EUSM proposal specifies an optimization wherein a single master session key can be used to derive session keys for multiple authoritative SNMP engines which requires new functionality in RADIUS, but this is not out of line with proposals that have been discussed in the IEEE for similar key distribution problems. Actually, if this optimization is not used then integration with RADIUS servers that already support 802.11 should work with little or no modification. regards, kaushik! _______________________________________________ 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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 25 08:51:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15616; Fri, 25 Feb 2005 08:51:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fsS-00010L-GH; Fri, 25 Feb 2005 08:51:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fsE-0006Qk-Ea; Fri, 25 Feb 2005 08:51:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4fsC-0006Oe-Q4 for isms@megatron.ietf.org; Fri, 25 Feb 2005 08:51:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15588 for ; Fri, 25 Feb 2005 08:51:15 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4fsL-0000ze-6s for isms@ietf.org; Fri, 25 Feb 2005 08:51:25 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 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 j1PDp6Ow015990; Fri, 25 Feb 2005 13:51:06 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 j1PDp1Hl012964; Fri, 25 Feb 2005 13:51:06 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005022505510607284 ; Fri, 25 Feb 2005 05:51:06 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 05:51:06 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 05:51:05 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 08:51:04 -0500 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] achieving market saturation with ISMS Date: Fri, 25 Feb 2005 08:50:56 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929BD7066@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS Thread-Index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpgAABkeiAAB92aYAAOn5SQABox3kA= From: "Blumenthal, Uri" To: "Fleischman, Eric" , X-OriginalArrivalTime: 25 Feb 2005 13:51:04.0430 (UTC) FILETIME=[0C5EF0E0:01C51B41] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable > There is a difference between ISMS provisioning local accounts and ISMS > being designed with interfaces so that it could interwork with an > existing IETF approach (e.g., RADIUS, COPS) to provision local accounts. To provision anything, MIB and corresponding code must exist - in addition to interfaces to other things (RADIUS, etc). I don't think I got your point - are you objecting that in order to use SNMP for provisioning, [large] extra piece of software and a corresponding MIB will be necessary - in addition to whatever code is written to use that thing (local accounts?) to authenticate SNMP messages themselves? -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Thursday, February 24, 2005 11:59 AM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Well, provisioning of local accounts is nice - but it requires a large chunk of software to do/manage it, plus an acceptable MIB... -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Thursday, February 24, 2005 10:02 AM To: Blumenthal, Uri; 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS Hi, I'm a proponent of having local accounts as a fallback to centralized accounts. I believe this is important for troubleshooting broken networks when a AAA server or centralized key distribution infrastructure may not be reachable. I don't think we should just provide an interface to local accounts that are somehow provisioned in a way that is "simply not my problem". I think we should make both provisioning of local accounts and leveraging centralized accounts part of the SNMPv3 solution. What we need to do is to show that having SNMP do the provisioning for the local accounts for all management interfaces would be easier than provisioning the local accounts of different management interfaces using different mechanisms.=20 The biggest win would be to converge the multiple local account databases into one consistent local account database that is manageable using any of the (equivalently-secure) management interfaces. To do this means we need to develop a standard virtual data model for a user-authentication database that can be used by the different user-authentication mechanisms supported by different management interfaces (e.g. the USM-MIB).=20 We would also need to develop equivalent (or at least balanced) security for each of the management interfaces, so one interface doesn't provide less protection of the keys than other interfaces. If SNMPv3 uses its own unique security model, then we'll need to figure out how to provide equivalenet security for other management protocols to converge them; it would be easier to achieve equivalent security by having SNMP adopt the existing security solutions used by other management interfaces (even if this might mean lessening the strength of SNMPv3 security to match the other solutions). David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Blumenthal, Uri > Sent: Thursday, February 24, 2005 9:24 AM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS >=20 > > Here's what bugs me about local accounts: > > The effort required to provision and maintain local accounts is > arguably > > even greater than that required to maintain USM users, because at > least > > the USM user maintenance is easily accomplished remotely through a=20 > > highly standardized interface. If USM is too much work, then how > would > > making local accounts be an improvement? >=20 > IMHO, the answer is "Simply Not My Problem". I think that > proponents of > this approach hope that local accounts somehow will have to be > provisioned [for the box to function properly] AND SOMEBODY ELSE WILL > HAVE TO TAKE CARE OF THAT. So if they just offer an interface to local > account-based authentication, they'll avoid all the > provisioning needs. > :-) >=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@ietf.org Fri Feb 25 11:35:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05785; Fri, 25 Feb 2005 11:35:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iRD-0005gY-9r; Fri, 25 Feb 2005 11:35:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iQN-0003TD-Rp; Fri, 25 Feb 2005 11:34:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4iQM-0003Nf-Un for isms@megatron.ietf.org; Fri, 25 Feb 2005 11:34:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05608 for ; Fri, 25 Feb 2005 11:34:38 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iQT-0005df-8q for isms@ietf.org; Fri, 25 Feb 2005 11:34:51 -0500 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 j1PGYTTU008557; Fri, 25 Feb 2005 08:34:29 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1PGYYW1016579; Fri, 25 Feb 2005 08:34:34 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1PGYYlA016573; Fri, 25 Feb 2005 08:34:34 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 25 Feb 2005 08:34:34 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Quittek Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: <0C86F0307701A7F2645ADFEB@[10.1.1.171]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc HI, I appreciate your response, but I got lost in the details. Were you going to change the agenda? Regards, /david t. perkins On Fri, 25 Feb 2005, Juergen Quittek wrote: > Hi David, > > --On 24.02.2005 21:58 Uhr +0100 David T. Perkins wrote: > > > HI, > > > > I would like to see a few changes made. > > > > Before item #2 below, > > lets add a 10 minute review of the problem that is to > > be solved and review of the operational scenarios. > > I'd very much appreciate starting discussions on > different understandings of the WG goals and operational > scenarios as soon as possible on the mailing list. > > It is a good idea to remind the WG of its goals and to > clarify them. However, goals and operational scenarios > are the titles of sections 2.2 and 2.3 of the comparison > I-D. So, I expect the presentation of the I-D to cover > these issues. > > If you have a view that differs from what is stated in > the comparison I-D, then I suggest that you prepare > bring these issues to the mailing list and - depending > on the progress of the discussion - prepare some slides > stating your view. If we do not agree on our goals and > operational scenarios, we will add this discussion to > the agenda. > > > Then, after item #3 below, add time to talk about > > EVAL #2, since EVAL #1 is fatally flawed, and we > > need to do another one, with probably a different > > team. > > This issue fits well in #3. During #2 there is time for > identifying flaws in the evaluation. After we have got > an idea of the list of flaws and their severity, we can > discuss the issue in #3. > > But anyway, let's try to progress the discussion on > flaws of the evaluation I-D as far as possible on the > mailing list before the Minneapolis meeting. > > > As I pointed out, the -02 version of EUSM is radially > > different from the -00 version, and closes the gap > > between it and SBSM. > > Version -02 was not yet subject of the evaluation. > It is intentionally discussed at the end of our session. > We will discuss our WG direction rather independent > of this version. However, if time allows we can discuss > at the end of the session whether or not this > modification of EUSM follows the way we want to go. > > > Lets add a new item to see what > > can be done to get a proposal that blends the two. > > This discussion will be part of #3 and #4. The > evaluation I-D came to the conclusion that neither > of the three proposals matches all recommendations. > It suggests taking EUSM as starting point for developing > an ISMS that also integrates features of the other > proposals. We will discuss which features of the three > proposals need to be integrated. You may call this > 'blending' them. > > > The -02 EUSM depends on two NEW protocols - the > > key setup protocol and the Key Request Protocol. > > These are new, and a short presentation about them > > would be useful. > > I take this as a recommendation for Kaushik concerning > the outline of his presentation on suggested EUSM > modifications. > > 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 > > > > Regards, > > /david t. perkins > > > > On Thu, 24 Feb 2005, Juergen Quittek wrote: > > > >> Dear all, > >> > >> Below please find a draft agenda for our Minneapolis session. > >> > >> Any 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 > >> > >> ============================================= > >> > >> > >> Integrated Security Model for SNMP WG (isms) > >> IETF #62 > >> Monday 7, 2005 : 1930-2200 > >> ============================================ > >> > >> Chairs: > >> > >> Ken Hornstein > >> Juergen Quittek > >> > >> AGENDA: > >> > >> 1) Agenda bashing, WG Status ( 5 min) > >> > >> 2) Proposal Comparison (45 min) > >> - presentation of > >> draft-ietf-isms-proposal-comparison-00.txt > >> > >> 3) Discussion of WG direction (30 min) > >> - on which solution approach will the WG > >> focus its efforts? > >> > >> 4) Charter discussion (45 min) > >> > >> > >> 5) Update of the EUSM proposal (optional) (20 min) > >> - draft-kaushik-snmp-external-usm-02.txt > >> > >> 6) Wrap up ( 5 min) > >> - action points, schedule for evalaution > >> > >> > >> INTERNET DRAFTS: > >> > >> Comparison of Proposals for Integrated Security Models for SNMP > >> (Simple Network Management Protocol) > >> http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt > >> > >> Transport Layer Security Model (TLSM) for the Simple Network > >> Management Protocol version 3 (SNMPv3) > >> http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt > >> > >> A Session-Based Security Model (SBSM) for version 3 of the Simple > >> Network Management Protocol (SNMPv3) > >> http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > >> > >> External User Security Model (EUSM) for version 3 of the Simple > >> Network Management Protocol (SNMPv3) > >> http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt > >> > >> > >> _______________________________________________ > >> 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@ietf.org Fri Feb 25 11:53:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07247; Fri, 25 Feb 2005 11:53:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4iiJ-000623-KH; Fri, 25 Feb 2005 11:53:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4ih0-0004hA-93; Fri, 25 Feb 2005 11:51:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4igy-0004gD-V3 for isms@megatron.ietf.org; Fri, 25 Feb 2005 11:51:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07118 for ; Fri, 25 Feb 2005 11:51:49 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ih7-0005zi-0L for isms@ietf.org; Fri, 25 Feb 2005 11:52:02 -0500 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 j1PGpaTU013202; Fri, 25 Feb 2005 08:51:36 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1PGpfbG021798; Fri, 25 Feb 2005 08:51:41 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1PGpf93021794; Fri, 25 Feb 2005 08:51:41 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 25 Feb 2005 08:51:41 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Quittek Subject: Re: [Isms] achieving market saturation with ISMS (fwd) In-Reply-To: <0241A9801C5254335DE01455@[10.1.1.171]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 HI, The WG is the guide, not the EVAL I-D. The EVAL I-D is fatally flawed because, 1) It used eval aspects not included in the WG charter or that had rough concensus on the WG charter. 2) It specified eval criteria in section 2.3 (operational scenarios), but did not include the result of these operational scenarios in the EVAL I-D. 3) It mischaracterized the features of the proposals. 4) It based it's recomendations on facts the authors didn't know and ignored facts authors should know (or that could be determined). Does this help with your questions below? On USM support, why don't you ask the EVAL authors instead of trying to interpret their double talk. That is, EVAL authors, 1) Can a new security model replace USM so that there would be no need for its deployment. That is, after the new security model is available for deployment, will there be any need for USM except where it is already deployed? On Fri, 25 Feb 2005, Juergen Quittek wrote: > Hi David, > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > HI, > > > > This is a resend. Sorry if you get it twice, but > > it's VERY IMPORTANT. > > > > Regards, > > /david t. perkins > > > > ---------- Forwarded message ---------- > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > From: David T. Perkins > > To: Juergen Schoenwaelder > > Cc: Randy Presuhn , isms@ietf.org > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > HI, > > > > Juergen is so right. We covered this topic in the BOFs > > that lead up to the formation of ISMS. > > > > That is, when a box is set up, work is done to use > > other management interfaces. Unfortunately, to deploy > > SNMPv3/USM on the box, extra work has to be done. And for > > on-going operations, extra work needs to be done to support > > SNMPv3/USM. The ABSOLUTELY PRIMARY goal of ISMS is to > > ELIMINATE this "extra" work. > > Sorry, to which part of the I-D are you referring? > > > I believe the EVAL team > > didn't GET THIS, and thus, they came out with a fatally > > flawed I-D. Again, THEY DIDN'T UNDERSTAND THE PRIMARY > > PROBLEM TO BE SOLVED! For example, > > Do you have more examples or even the full list? > > > they believed that > > boxes must continue to support USM, so if an authentication > > service was not available, there would be a fallback > > method to authentication. WRONG!! > > What the I-D states is > > * Must not preclude the use of USM [RFC3414], particularly if > network instability could cause problems for the proposed > solution > * ... > * Must not break basic device discovery. (Retaining USM support > would satisfy this goal.) > > I don't see a statement saying "boxes must continue to support USM". > > > There is NO NEED for > > USM, except for backwards compatibility with the > > VERY small number of SNMPv3/USM managers. > > Is there support for this statement by other WG members? > > > The WG will continue to go around in circles and come > > up with clever engineering solutions (because the > > EVAL authors and members of the WG are really smart > > engineers) until some basic understanding is reached > > on the operational problem to be solved. > > > > Please, WG chairs supply some guidance on solving > > the appropriate problem. Please ask the EVAL team, > > or a new team do the evals specified in section 2.3 > > of the EVAL I-D, and drop all of the other > > eval considerations that they added. > > > > On Thu, 24 Feb 2005, Juergen Schoenwaelder wrote: > > > >> On Wed, Feb 23, 2005 at 03:49:29PM -0800, Randy Presuhn wrote: > >> > >> > Here's what bugs me about local accounts: > >> > The effort required to provision and maintain local accounts is arguably > >> > even greater than that required to maintain USM users, because at least > >> > the USM user maintenance is easily accomplished remotely through a > >> > highly standardized interface. If USM is too much work, then how would > >> > making local accounts be an improvement? > >> > >> Local accounts are a reality on all boxes that I can think of. You > >> telnet, ssh, whatever into local accounts as the default. On some > >> installations, you find AAA setups to simplify the maintenance of > >> accounts in the normal case (when the core network is running). > >> The point is that USM does typically not interface with neither > >> these local accounts nor AAA systems. In other words, USM is too > >> much work because it is extra work in _addition_ to the management > >> of local accounts or AAA accounts. [I am surprised that the core > >> of the problem still seems to be not well understood.] > >> > >> /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@ietf.org Fri Feb 25 12:41:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11894; Fri, 25 Feb 2005 12:41:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jTZ-00076e-FJ; Fri, 25 Feb 2005 12:42:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jQM-0002cW-K2; Fri, 25 Feb 2005 12:38:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4jQK-0002bS-M4 for isms@megatron.ietf.org; Fri, 25 Feb 2005 12:38:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11514 for ; Fri, 25 Feb 2005 12:38:41 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4jQT-00071W-V4 for isms@ietf.org; Fri, 25 Feb 2005 12:38:55 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA25381; Fri, 25 Feb 2005 11:38:32 -0600 (CST) Received: from XCH-NWBH-02.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 j1PHcWI10320; Fri, 25 Feb 2005 09:38:32 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 25 Feb 2005 09:38:27 -0800 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] achieving market saturation with ISMS Date: Fri, 25 Feb 2005 09:38:27 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCAA@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS Thread-Index: AcUaOh8+kXbhb2PQQXmqyrzfYvnI5AAQfjpgAABkeiAAB92aYAAOn5SQABox3kAAB4imsA== From: "Fleischman, Eric" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 25 Feb 2005 17:38:27.0913 (UTC) FILETIME=[D0853B90:01C51B60] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >> There is a difference between ISMS provisioning local accounts and ISMS >> being designed with interfaces so that it could interwork with an=20 >> existing IETF approach (e.g., RADIUS, COPS) to provision local accounts. >To provision anything, MIB and corresponding code must exist - in >addition to interfaces to other things (RADIUS, etc). >I don't think I got your point - are you objecting that in order=20 >to use SNMP for provisioning, [large] extra piece of software and=20 >a corresponding MIB will be necessary - in addition to whatever=20 >code is written to use that thing (local accounts?) to authenticate=20 >SNMP messages themselves? I was merely thinking that each of the proposals have assumed other IETF work as mechanisms to enhance aspects of SNMP USM security. That other IETF work has desirable attributes from which we could benefit regardless of whether we incorporate it into ISMS in a monolithic manner or whether we provide interfaces from ISMS to that other technology. I am fond of the latter approach because it permits us to benefit from however those technologies are enhanced over time and it reduces our work overall. For example, if we decide to leverage TLS, our responsibility is to do so via a secure and flexible interface but it is not our responsibility to define MIBs or other structures for TLS -- that rather is work that we have offloaded to the keepers of TLS. Similarly, if we choose an approach like EUSM, then we can benefit from RADIUS' ability to orchestrate local accounts without having to invent our own local account management approach (in addition to the approach already present in USM). _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 25 14:07:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18806; Fri, 25 Feb 2005 14:07:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4ko0-0000R7-OC; Fri, 25 Feb 2005 14:07:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4kmP-0006vO-6b; Fri, 25 Feb 2005 14:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4kmN-0006sg-ST for isms@megatron.ietf.org; Fri, 25 Feb 2005 14:05:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18720 for ; Fri, 25 Feb 2005 14:05:34 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4kmY-0000PZ-Mu for isms@ietf.org; Fri, 25 Feb 2005 14:05:47 -0500 Received: from dialin-145-254-223-226.arcor-ip.net (dialin-145-254-223-226.arcor-ip.net [145.254.223.226]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 2BBA71BAC4D; Fri, 25 Feb 2005 20:05:16 +0100 (CET) Date: Fri, 25 Feb 2005 20:05:31 +0100 From: Juergen Quittek To: "David T. Perkins" Subject: Re: [Isms] draft agenda for Minneapolis 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: 3.0 (+++) X-Scan-Signature: bacfc6c7290e34d410f9bc22b825ce96 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 3.0 (+++) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 Content-Transfer-Encoding: 7bit Hi David, --On 25.02.2005 17:34 Uhr +0100 David T. Perkins wrote: > HI, > > I appreciate your response, but I got lost in the > details. Were you going to change the agenda? Your points: - 10 minute review of WG goals: Fits well in the current agenda. It's part of #2 anyway. You are welcome to provide input for this, for example in form of slides. Still, we should try to discuss this issue as far as possible before the meeting. - Talking about eval team#2: Fits well in item #3 (discussion of WG direction) Setting up a new eval team is a change of plan and needs to be discussed in #3. - EUSM -02: The presentation at the end is rather for information. I think we could focus on our main targets. Whether or not the progress from EUSM -01 to -02 is useful for achieving our goals can be discussed after we made our decisions. In summary: no visible change of the agenda, but your issues are well covered. 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 > Regards, > /david t. perkins > > > > On Fri, 25 Feb 2005, Juergen Quittek wrote: > >> Hi David, >> >> --On 24.02.2005 21:58 Uhr +0100 David T. Perkins wrote: >> >> > HI, >> > >> > I would like to see a few changes made. >> > >> > Before item #2 below, >> > lets add a 10 minute review of the problem that is to >> > be solved and review of the operational scenarios. >> >> I'd very much appreciate starting discussions on >> different understandings of the WG goals and operational >> scenarios as soon as possible on the mailing list. >> >> It is a good idea to remind the WG of its goals and to >> clarify them. However, goals and operational scenarios >> are the titles of sections 2.2 and 2.3 of the comparison >> I-D. So, I expect the presentation of the I-D to cover >> these issues. >> >> If you have a view that differs from what is stated in >> the comparison I-D, then I suggest that you prepare >> bring these issues to the mailing list and - depending >> on the progress of the discussion - prepare some slides >> stating your view. If we do not agree on our goals and >> operational scenarios, we will add this discussion to >> the agenda. >> >> > Then, after item #3 below, add time to talk about >> > EVAL #2, since EVAL #1 is fatally flawed, and we >> > need to do another one, with probably a different >> > team. >> >> This issue fits well in #3. During #2 there is time for >> identifying flaws in the evaluation. After we have got >> an idea of the list of flaws and their severity, we can >> discuss the issue in #3. >> >> But anyway, let's try to progress the discussion on >> flaws of the evaluation I-D as far as possible on the >> mailing list before the Minneapolis meeting. >> >> > As I pointed out, the -02 version of EUSM is radially >> > different from the -00 version, and closes the gap >> > between it and SBSM. >> >> Version -02 was not yet subject of the evaluation. >> It is intentionally discussed at the end of our session. >> We will discuss our WG direction rather independent >> of this version. However, if time allows we can discuss >> at the end of the session whether or not this >> modification of EUSM follows the way we want to go. >> >> > Lets add a new item to see what >> > can be done to get a proposal that blends the two. >> >> This discussion will be part of #3 and #4. The >> evaluation I-D came to the conclusion that neither >> of the three proposals matches all recommendations. >> It suggests taking EUSM as starting point for developing >> an ISMS that also integrates features of the other >> proposals. We will discuss which features of the three >> proposals need to be integrated. You may call this >> 'blending' them. >> >> > The -02 EUSM depends on two NEW protocols - the >> > key setup protocol and the Key Request Protocol. >> > These are new, and a short presentation about them >> > would be useful. >> >> I take this as a recommendation for Kaushik concerning >> the outline of his presentation on suggested EUSM >> modifications. >> >> 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 >> >> >> > Regards, >> > /david t. perkins >> > >> > On Thu, 24 Feb 2005, Juergen Quittek wrote: >> > >> >> Dear all, >> >> >> >> Below please find a draft agenda for our Minneapolis session. >> >> >> >> Any 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 >> >> >> >> ============================================= >> >> >> >> >> >> Integrated Security Model for SNMP WG (isms) >> >> IETF #62 >> >> Monday 7, 2005 : 1930-2200 >> >> ============================================ >> >> >> >> Chairs: >> >> >> >> Ken Hornstein >> >> Juergen Quittek >> >> >> >> AGENDA: >> >> >> >> 1) Agenda bashing, WG Status ( 5 min) >> >> >> >> 2) Proposal Comparison (45 min) >> >> - presentation of >> >> draft-ietf-isms-proposal-comparison-00.txt >> >> >> >> 3) Discussion of WG direction (30 min) >> >> - on which solution approach will the WG >> >> focus its efforts? >> >> >> >> 4) Charter discussion (45 min) >> >> >> >> >> >> 5) Update of the EUSM proposal (optional) (20 min) >> >> - draft-kaushik-snmp-external-usm-02.txt >> >> >> >> 6) Wrap up ( 5 min) >> >> - action points, schedule for evalaution >> >> >> >> >> >> INTERNET DRAFTS: >> >> >> >> Comparison of Proposals for Integrated Security Models for SNMP >> >> (Simple Network Management Protocol) >> >> http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt >> >> >> >> Transport Layer Security Model (TLSM) for the Simple Network >> >> Management Protocol version 3 (SNMPv3) >> >> http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt >> >> >> >> A Session-Based Security Model (SBSM) for version 3 of the Simple >> >> Network Management Protocol (SNMPv3) >> >> http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt >> >> >> >> External User Security Model (EUSM) for version 3 of the Simple >> >> Network Management Protocol (SNMPv3) >> >> http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt >> >> >> >> >> >> _______________________________________________ >> >> 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@ietf.org Fri Feb 25 18:41:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16276; Fri, 25 Feb 2005 18:41:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4p5R-0006VP-F4; Fri, 25 Feb 2005 18:41:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4p55-00073M-JP; Fri, 25 Feb 2005 18:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4p54-00073D-9C for isms@megatron.ietf.org; Fri, 25 Feb 2005 18:41:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16265 for ; Fri, 25 Feb 2005 18:41:06 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4p5H-0006V1-8S for isms@ietf.org; Fri, 25 Feb 2005 18:41:23 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 25 Feb 2005 15:41:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,118,1107763200"; d="scan'208"; a="163860584:sNHT23023344" Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j1PNesYO009860; Fri, 25 Feb 2005 15:40:55 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.63]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYM46033; Fri, 25 Feb 2005 15:40:46 -0800 (PST) Message-Id: <6.2.0.14.0.20050225150635.07df0b58@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Feb 2005 15:40:46 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: References: <6.2.0.14.0.20050224180255.07b28bc0@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b045c2b078f76b9f842d469de8a32de3 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae Hi David, Please find my reply inline. At 06:44 PM 2/24/2005, David T. Perkins wrote: >HI, > >Interesting.... If it's the same, then it doesn't >support Kerboros, X.509 etc. nor local accounts. > >However, I believe the proposal has really been changed. >It does, require two new protocols, which are the >key setup and key request protocols. Maybe, not >new from -00 to -02, but new, in that they are >not defined in RFCs on the standards track, nor is >there existing running code in commercial off the shelf >products that I'm of. We am not sure about your above statement. EUSM does not define new protocols but mandates the of use existing protocols for Key Setup and Key Request. The introduction of the terminology of Key Setup Protocol and Key Request Protocol was done based on the recommendations to describe the EUSM proposal in more generic terms. To summarize EUSM continues to uses continues to uses EAP (as defined in RFC 2278) as what we now call the "Key Setup Protocol" - this term was not present in draft-kaushik-snmp-external-usm-01.txt, but the use of EAP was there, and the use of EAP is unchanged in draft-kaushik-snmp-external-usm-02.txt. In other words, this is only a change in terminology. Similarly, in case we need to use the optimization of using a single master session key to distribute keys to multiple SNMP engines, then we will need to use the RADIUS as what we now call the "Key Request protocol", the use of RADIUS is unchanged and still continues to be as defined in. http://www.ietf.org/internet-drafts/draft-zorn-radius-keyreq-03.txt As far as relation to existing RFCs and running implementation. EUSM will use the EAP-TLS protocol defined in RFC2716 as the EAP method to support authentication systems such as Kerberos, X.509 and local accounts. The PEAPv2 specification defined in http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-10.txt will be used as the EAP method for key setup to support RADIUS. EAP will use RADIUS transport for EAP as defined in RFC3579. In case of Key Setup between SNMP engines using EAP-TLS, EUSM will use the multi-hop PANA protocol as specified in http://www.ietf.org/internet-drafts/draft-ohba-multihop-eap-00.txt In case, we do not use the optimization of key generation for multiple engines, then SNMP engines can obtain keys after Key Setup via mechanisms described in RFC3579 for RADIUS authentication. RFC2278, RFC2716, RFC3579 and PEAPv2 are fairly well implemented. Multi-hop PANA is currently implemented part of 802.1x solutions. >I can't tell if you are open or not to creating a >blended approach using technology from EUSM and >from SBSM. What is your position on this? >What is your position on the three small changes >that I suggested in a previous EMAIL. What are >the pros and cons? If the WG were to decide that merging the two proposals was the way forward, then of course we would agree to do so, but we don't believe that is the best approach nor do we believe that the changes that you are suggesting are "small". regards, kaushik! >Regards, >/david t. perkins > >On Thu, 24 Feb 2005, Kaushik Narayan wrote: > > Hi All, > > > > We would like the clarify that EUSM -02 draft does not have > > anything new. The use of EAP as the Key Setup Protocol > > was the basis of our original proposal. The only thing that > > has been changed in this draft is that we took the Evaluation > > team's advice and explained how the proposal could support > > authentication systems such as Kerberos, X.509 etc. > > > > Also, there aren't any new protocols introduced in this revision. > > In fact, it was an explicit design decision for EUSM that we > > would use existing protocols like EAP/RADIUS. > > > > regards, > > kaushik! > > > > > > > > At 12:58 PM 2/24/2005, David T. Perkins wrote: > > >HI, > > > > > >I would like to see a few changes made. > > > > > >Before item #2 below, > > >lets add a 10 minute review of the problem that is to > > >be solved and review of the operational scenarios. > > > > > >Then, after item #3 below, add time to talk about > > >EVAL #2, since EVAL #1 is fatally flawed, and we > > >need to do another one, with probably a different > > >team. > > > > > >As I pointed out, the -02 version of EUSM is radially > > >different from the -00 version, and closes the gap > > >between it and SBSM. Lets add a new item to see what > > >can be done to get a proposal that blends the two. > > > > > >The -02 EUSM depends on two NEW protocols - the > > >key setup protocol and the Key Request Protocol. > > >These are new, and a short presentation about them > > >would be useful. > > > > > >Regards, > > >/david t. perkins > > > > > >On Thu, 24 Feb 2005, Juergen Quittek wrote: > > > > > > > Dear all, > > > > > > > > Below please find a draft agenda for our Minneapolis session. > > > > > > > > Any 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 > > > > > > > > ============================================= > > > > > > > > > > > > Integrated Security Model for SNMP WG (isms) > > > > IETF #62 > > > > Monday 7, 2005 : 1930-2200 > > > > ============================================ > > > > > > > > Chairs: > > > > > > > > Ken Hornstein > > > > Juergen Quittek > > > > > > > > AGENDA: > > > > > > > > 1) Agenda bashing, WG Status ( 5 min) > > > > > > > > 2) Proposal Comparison (45 min) > > > > - presentation of > > > > draft-ietf-isms-proposal-comparison-00.txt > > > > > > > > 3) Discussion of WG direction (30 min) > > > > - on which solution approach will the WG > > > > focus its efforts? > > > > > > > > 4) Charter discussion (45 min) > > > > > > > > > > > > 5) Update of the EUSM proposal (optional) (20 min) > > > > - draft-kaushik-snmp-external-usm-02.txt > > > > > > > > 6) Wrap up ( 5 min) > > > > - action points, schedule for evalaution > > > > > > > > > > > > INTERNET DRAFTS: > > > > > > > > Comparison of Proposals for Integrated Security Models for SNMP > > > > (Simple Network Management Protocol) > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-isms-proposal-comparison-00.txt > > > > > > > > Transport Layer Security Model (TLSM) for the Simple Network > > > > Management Protocol version 3 (SNMPv3) > > > > http://www.ietf.org/internet-drafts/draft-schoenw-snmp-tlsm-01.txt > > > > > > > > A Session-Based Security Model (SBSM) for version 3 of the Simple > > > > Network Management Protocol (SNMPv3) > > > > > http://www.ietf.org/internet-drafts/draft-hardaker-snmp-session-sm-03.txt > > > > > > > > External User Security Model (EUSM) for version 3 of the Simple > > > > Network Management Protocol (SNMPv3) > > > > > http://www.ietf.org/internet-drafts/draft-kaushik-snmp-external-usm-02.txt > > > > > > > > > > > > _______________________________________________ > > > > 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 > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Feb 25 20:00:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21115; Fri, 25 Feb 2005 20:00:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qK4-0007q5-Or; Fri, 25 Feb 2005 20:00:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qIh-0008OE-Ap; Fri, 25 Feb 2005 19:59:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4qIf-0008LM-Vs for isms@megatron.ietf.org; Fri, 25 Feb 2005 19:59:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21034 for ; Fri, 25 Feb 2005 19:59:14 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4qIs-0007oq-2V for isms@ietf.org; Fri, 25 Feb 2005 19:59:32 -0500 Received: from h-68-164-242-29.snvacaid.dynamic.covad.net ([68.164.242.29] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D4qIb-0007gx-00 for isms@ietf.org; Fri, 25 Feb 2005 16:59:13 -0800 Message-ID: <002d01c51b9e$9a0db720$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Date: Fri, 25 Feb 2005 17:00:44 -0800 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.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Hi - > From: "David T. Perkins" > To: "Juergen Quittek" > Cc: > Sent: Friday, February 25, 2005 8:51 AM > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > HI, > > The WG is the guide, not the EVAL I-D. > > The EVAL I-D is fatally flawed because, > 1) It used eval aspects not included in the WG charter > or that had rough concensus on the WG charter. Please forgive us for attempting to include points raised in discussion on the working group mailing list, like those from Eric Fleischman's wish list, that appeared to not be contentious, as well as any other criteria that we may have used in trying to identify a clear "winner" from among the proposals. > 2) It specified eval criteria in section 2.3 (operational > scenarios), but did not include the result of > these operational scenarios in the EVAL I-D. Please forgive us for submitting a -00- draft that is not perfect. I guess we erred by trying to produce something helpful in time for the i-d cutoff, rather than waiting for something that was complete in all respects. > 3) It mischaracterized the features of the proposals. Please forgive us for not getting everything right. Please send text, and we'll happily correct errors where we've misunderstood the proposals. > 4) It based it's recomendations on facts the authors > didn't know and ignored facts authors should know > (or that could be determined). Please forgive our lack of omniscience. We'll happily incorporate text that will improve the document, particularly if it would enable a more clear-cut decision by the WG. However, the WG should, I think, be focusing on moving ahead. As much as we would have like to be able to pick one of the proposals and say "this is perfect and we should procede from here", things, at least as we saw them, were not so clear-cut. > Does this help with your questions below? > On USM support, why don't you ask the EVAL authors > instead of trying to interpret their double talk. I'm not sure what you're calling "double talk." The requirement "Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution" has not previously been disputed, as far as I know. > That is, EVAL authors, > 1) Can a new security model replace USM so that there > would be no need for its deployment. That is, > after the new security model is available for > deployment, will there be any need for USM > except where it is already deployed? I think any model that potentially relies on external AAA needs some kind of self-sufficient fallback. USM fuflfills that requirement. It's probably possible to define a new security model with comparable fallback capabilities, like the local accounts in SBSM, but that begs the question of how these are managed. So yes, to the extent that a new model re-impliments some key USM features,and doesn't break other key needs, like device discovery, it could replace USM. Whether doing so would actually be desirable is not clear. > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > Hi David, > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > HI, > > > > > > This is a resend. Sorry if you get it twice, but > > > it's VERY IMPORTANT. > > > > > > Regards, > > > /david t. perkins > > > > > > ---------- Forwarded message ---------- > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > From: David T. Perkins > > > To: Juergen Schoenwaelder > > > Cc: Randy Presuhn , isms@ietf.org > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > HI, > > > > > > Juergen is so right. We covered this topic in the BOFs > > > that lead up to the formation of ISMS. > > > > > > That is, when a box is set up, work is done to use > > > other management interfaces. Unfortunately, to deploy > > > SNMPv3/USM on the box, extra work has to be done. And for > > > on-going operations, extra work needs to be done to support > > > SNMPv3/USM. The ABSOLUTELY PRIMARY goal of ISMS is to > > > ELIMINATE this "extra" work. > > > > Sorry, to which part of the I-D are you referring? > > > > > I believe the EVAL team > > > didn't GET THIS, and thus, they came out with a fatally > > > flawed I-D. Again, THEY DIDN'T UNDERSTAND THE PRIMARY > > > PROBLEM TO BE SOLVED! For example, The "extra" work, setting the keys for the "initial" user, isn't addressed by any of the proposals. In some respects they compound the problem by requiring provisioning of AAA keys. This has been discussed on this mailing list at some length. What other parts of the problem don't we get? > > Do you have more examples or even the full list? These would be appreciated; we're trying to be useful. > > > they believed that > > > boxes must continue to support USM, so if an authentication > > > service was not available, there would be a fallback > > > method to authentication. WRONG!! So if there is no authentication service available, things should simply not work? If the fallback is to local accounts, we're back to the problem of specifying how they're managed, unless you accept the argument that it's simply someone else's problem. > > What the I-D states is > > > > * Must not preclude the use of USM [RFC3414], particularly if > > network instability could cause problems for the proposed > > solution > > * ... > > * Must not break basic device discovery. (Retaining USM support > > would satisfy this goal.) > > > > I don't see a statement saying "boxes must continue to support USM". ... Indeed, we did not say boxes must continue to support USM. The requirement is that this solution must not preclude supporting USM. > > > There is NO NEED for > > > USM, except for backwards compatibility with the > > > VERY small number of SNMPv3/USM managers. > > > > Is there support for this statement by other WG members? > > > > > The WG will continue to go around in circles and come > > > up with clever engineering solutions (because the > > > EVAL authors and members of the WG are really smart > > > engineers) until some basic understanding is reached > > > on the operational problem to be solved. ... Which operational problem(s) do you believe are the ones to be solved, if not the ones in our charter? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 11:29:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06163; Mon, 28 Feb 2005 11:29:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nmo-0002OY-BG; Mon, 28 Feb 2005 11:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nfq-0007Si-N1; Mon, 28 Feb 2005 11:23:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5nfp-0007Sd-8R for isms@megatron.ietf.org; Mon, 28 Feb 2005 11:23:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05605 for ; Mon, 28 Feb 2005 11:23:07 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5nga-0002Fm-D6 for isms@ietf.org; Mon, 28 Feb 2005 11:23:57 -0500 Received: from cmf.nrl.navy.mil (elvis.cmf.nrl.navy.mil [134.207.10.38]) (authenticated bits=0) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j1SGN1iH011667 for ; Mon, 28 Feb 2005 11:23:02 -0500 (EST) Message-Id: <200502281623.j1SGN1iH011667@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] draft agenda for Minneapolis In-Reply-To: <6.2.0.14.0.20050225150635.07df0b58@mira-sjc5-a.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 28 Feb 2005 11:23:02 -0500 From: Ken Hornstein X-Spam-Score: () hits=0 User Authenticated X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >EUSM will use the EAP-TLS protocol defined in RFC2716 as the >EAP method to support authentication systems such as Kerberos, >X.509 and local accounts. (WG chair hat off) Upon reading RFC2716, I've discovered that it only mentions Kerberos (and Public Key) once. Specifically, it says: Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. To date however, EAP methods such as [6] have focussed on authenticating a client to a server. It doesn't really mention how this will happen. If you look at the EAP document (RFC3748), it doesn't explain how you could use Kerberos or PKI with EAP either (I looked at PEAP, but that seems to focus only on protecting the EAP exchange, rather than doing certificate validation as part of the EAP authentication). Maybe I'm missing something, but it seems like there's a bit of handwaving here. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 12:17:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12038; Mon, 28 Feb 2005 12:17:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oXD-0003ip-2M; Mon, 28 Feb 2005 12:18:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oVl-0008MQ-DW; Mon, 28 Feb 2005 12:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oVj-0008ME-Lg for isms@megatron.ietf.org; Mon, 28 Feb 2005 12:16:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11940 for ; Mon, 28 Feb 2005 12:16:45 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oWV-0003h5-MD for isms@ietf.org; Mon, 28 Feb 2005 12:17:36 -0500 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 LAA14545; Mon, 28 Feb 2005 11:16:31 -0600 (CST) Received: from XCH-NWBH-02.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 j1SHGVE03455; Mon, 28 Feb 2005 11:16:31 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 09:16:28 -0800 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] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 09:16:28 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCB6@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1Iw From: "Fleischman, Eric" To: "Randy Presuhn" , X-OriginalArrivalTime: 28 Feb 2005 17:16:28.0867 (UTC) FILETIME=[3D8C0930:01C51DB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Content-Transfer-Encoding: quoted-printable "Wish List"??? It is my belief that I have been articulating security requirements for the new protocol. I have frequently invited discussions as to why the following SNMPv3 USM blemishes need to be improved. Other than discussions in the SNMP mail list over two years ago, I haven't had any takers in this WG. Thus, from where I sit, the following ARE consensus ISMS requirements, listed in order of increasing importance: 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys 6) SNMPv3 USM keys are unrelated to any existing authentication system within a deployment (e.g., Kerberos, PKI, Radius, etc.) --Eric -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Friday, February 25, 2005 5:01 PM To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Hi - > From: "David T. Perkins" > To: "Juergen Quittek" > Cc: > Sent: Friday, February 25, 2005 8:51 AM > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > HI, > > The WG is the guide, not the EVAL I-D. > > The EVAL I-D is fatally flawed because, > 1) It used eval aspects not included in the WG charter > or that had rough concensus on the WG charter. Please forgive us for attempting to include points raised in discussion on the working group mailing list, like those from Eric Fleischman's wish list, that appeared to not be contentious, as well as any other criteria that we may have used in trying to identify a clear "winner" from among the proposals. > 2) It specified eval criteria in section 2.3 (operational > scenarios), but did not include the result of > these operational scenarios in the EVAL I-D. Please forgive us for submitting a -00- draft that is not perfect. I guess we erred by trying to produce something helpful in time for the i-d cutoff, rather than waiting for something that was complete in all respects. > 3) It mischaracterized the features of the proposals. Please forgive us for not getting everything right. Please send text, and we'll happily correct errors where we've misunderstood the proposals. > 4) It based it's recomendations on facts the authors > didn't know and ignored facts authors should know > (or that could be determined). Please forgive our lack of omniscience. We'll happily incorporate text that will improve the document, particularly if it would enable a more clear-cut decision by the WG. However, the WG should, I think, be focusing on moving ahead. As much as we would have like to be able to pick one of the proposals and say "this is perfect and we should procede from here", things, at least as we saw them, were not so clear-cut. > Does this help with your questions below? > On USM support, why don't you ask the EVAL authors > instead of trying to interpret their double talk. I'm not sure what you're calling "double talk." The requirement "Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution" has not previously been disputed, as far as I know. > That is, EVAL authors, > 1) Can a new security model replace USM so that there > would be no need for its deployment. That is, > after the new security model is available for > deployment, will there be any need for USM > except where it is already deployed? I think any model that potentially relies on external AAA needs some kind of self-sufficient fallback. USM fuflfills that requirement. It's probably possible to define a new security model with comparable fallback capabilities, like the local accounts in SBSM, but that begs the question of how these are managed. So yes, to the extent that a new model re-impliments some key USM features,and doesn't break other key needs, like device discovery, it could replace USM. Whether doing so would actually be desirable is not clear. > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > Hi David, > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > HI, > > > > > > This is a resend. Sorry if you get it twice, but > > > it's VERY IMPORTANT. > > > > > > Regards, > > > /david t. perkins > > > > > > ---------- Forwarded message ---------- > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > From: David T. Perkins > > > To: Juergen Schoenwaelder > > > Cc: Randy Presuhn , isms@ietf.org > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > HI, > > > > > > Juergen is so right. We covered this topic in the BOFs that lead=20 > > > up to the formation of ISMS. > > > > > > That is, when a box is set up, work is done to use > > > other management interfaces. Unfortunately, to deploy SNMPv3/USM=20 > > > on the box, extra work has to be done. And for on-going=20 > > > operations, extra work needs to be done to support SNMPv3/USM. The > > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this "extra" work. > > > > Sorry, to which part of the I-D are you referring? > > > > > I believe the EVAL team didn't GET=20 > > > THIS, and thus, they came out with a fatally flawed I-D. Again,=20 > > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For=20 > > > example, The "extra" work, setting the keys for the "initial" user, isn't addressed by any of the proposals. In some respects they compound the problem by requiring provisioning of AAA keys. This has been discussed on this mailing list at some length. What other parts of the problem don't we get? > > Do you have more examples or even the full list? These would be appreciated; we're trying to be useful. > > > they believed that boxes must=20 > > > continue to support USM, so if an authentication service was not=20 > > > available, there would be a fallback method to authentication.=20 > > > WRONG!! So if there is no authentication service available, things should simply not work? If the fallback is to local accounts, we're back to the problem of specifying how they're managed, unless you accept the argument that it's simply someone else's problem. > > What the I-D states is > > > > * Must not preclude the use of USM [RFC3414], particularly if > > network instability could cause problems for the proposed > > solution > > * ... > > * Must not break basic device discovery. (Retaining USM support > > would satisfy this goal.) > > > > I don't see a statement saying "boxes must continue to support USM". ... Indeed, we did not say boxes must continue to support USM. The requirement is that this solution must not preclude supporting USM. > > > There is NO NEED for USM, except > > > for backwards compatibility with the VERY small number of=20 > > > SNMPv3/USM managers. > > > > Is there support for this statement by other WG members? > > > > > The WG will continue to go around in circles and come > > > up with clever engineering solutions (because the > > > EVAL authors and members of the WG are really smart > > > engineers) until some basic understanding is reached > > > on the operational problem to be solved. ... Which operational problem(s) do you believe are the ones to be solved, if not the ones in our charter? 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@ietf.org Mon Feb 28 12:23:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12675; Mon, 28 Feb 2005 12:23:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5odV-0003qj-CL; Mon, 28 Feb 2005 12:24:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oaI-00025P-Ew; Mon, 28 Feb 2005 12:21:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oaH-00025K-IO for isms@megatron.ietf.org; Mon, 28 Feb 2005 12:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12417 for ; Mon, 28 Feb 2005 12:21:26 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ob3-0003ny-Of for isms@ietf.org; Mon, 28 Feb 2005 12:22:18 -0500 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id C9F7E284D1; Mon, 28 Feb 2005 09:45:27 -0800 (PST) To: "Fleischman, Eric" Subject: Re: [Isms] achieving market saturation with ISMS (fwd) In-reply-to: Your message of "Mon, 28 Feb 2005 09:16:28 PST." <5B58696DB20B9140AD20E0685C573A6404FDDCB6@xch-nw-09.nw.nos.boeing.com> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Mon, 28 Feb 2005 09:25:18 -0800 From: Eric Rescorla Message-Id: <20050228174527.C9F7E284D1@sierra.rtfm.com> 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Fleischman, Eric wrote: > "Wish List"??? It is my belief that I have been articulating security > requirements for the new protocol. I have frequently invited discussions > as to why the following SNMPv3 USM blemishes need to be improved. Other > than discussions in the SNMP mail list over two years ago, I haven't had > any takers in this WG. Thus, from where I sit, the following ARE > consensus ISMS requirements, listed in order of increasing importance: > > 1) no provisions for two-factored authentication > 2) SNMP symmetric keys may be assembled from passwords I'm not sure that this is a showstopper. Obviously, it's better to have an authentication system that's not susceptible to dictionary attack, but a system which is susceptible to dictionary attack is far better than no system at all (cf. CRAM-MD5, etc.) Do you want to ban passwords or simply provide an alternative. > 3) Key updates do not provide for Perfect Forward Security Why do you think this is a requirement? Many security systems (e.g. SSL) do perfectly well without using PFS. (SSL has a PFS mode, but the dominant modes, at least for HTTPS, do not provide PFS). -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 12:31:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13235; Mon, 28 Feb 2005 12:31:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5okm-0003yf-60; Mon, 28 Feb 2005 12:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oi5-0004C6-IC; Mon, 28 Feb 2005 12:29:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5oi2-0004Bw-UP for isms@megatron.ietf.org; Mon, 28 Feb 2005 12:29:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13087 for ; Mon, 28 Feb 2005 12:29:28 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5oip-0003x2-CZ for isms@ietf.org; Mon, 28 Feb 2005 12:30:19 -0500 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 JAA19878; Mon, 28 Feb 2005 09:29:19 -0800 (PST) Received: from XCH-NWBH-02.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 j1SHTJE22920; Mon, 28 Feb 2005 11:29:19 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 09:29:16 -0800 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] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 09:29:15 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCB7@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGsVpw From: "Fleischman, Eric" To: "Randy Presuhn" , X-OriginalArrivalTime: 28 Feb 2005 17:29:16.0206 (UTC) FILETIME=[06EAACE0:01C51DBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Content-Transfer-Encoding: quoted-printable I feel very sad, Randy, that you read David's posting as a put-down. I did not read it that way. Would you mind re-reading his posting after considering my next paragraphs? I fully concur with what David wrote. However, I simultaneously have respect and appreciation for what you and the other authors accomplished by your draft. I honor you, despite my belief that your work was flawed because it did not consider all of the consensus requirements of the working group. Rather, it only considered a small subset.=20 All this comes back to my frequent earlier emails months ago that the noble undertaking which you so graciously volunteered to do was unlikely to be successful unless it was pegged to specific documented requirements and a documented evaluation criteria. When we learned that this was not the case, I was fairly certain that your work could not be adequate, which was how it proved to be. This is a process issue and not a personnel issue: I am confident that all four of you are outstanding technical people and that had you addressed documented requirements in terms of documented evaluation criteria that you would have produced an outstanding draft.=20 --Eric -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Friday, February 25, 2005 5:01 PM To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Hi - > From: "David T. Perkins" > To: "Juergen Quittek" > Cc: > Sent: Friday, February 25, 2005 8:51 AM > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > HI, > > The WG is the guide, not the EVAL I-D. > > The EVAL I-D is fatally flawed because, > 1) It used eval aspects not included in the WG charter > or that had rough concensus on the WG charter. Please forgive us for attempting to include points raised in discussion on the working group mailing list, like those from Eric Fleischman's wish list, that appeared to not be contentious, as well as any other criteria that we may have used in trying to identify a clear "winner" from among the proposals. > 2) It specified eval criteria in section 2.3 (operational > scenarios), but did not include the result of > these operational scenarios in the EVAL I-D. Please forgive us for submitting a -00- draft that is not perfect. I guess we erred by trying to produce something helpful in time for the i-d cutoff, rather than waiting for something that was complete in all respects. > 3) It mischaracterized the features of the proposals. Please forgive us for not getting everything right. Please send text, and we'll happily correct errors where we've misunderstood the proposals. > 4) It based it's recomendations on facts the authors > didn't know and ignored facts authors should know > (or that could be determined). Please forgive our lack of omniscience. We'll happily incorporate text that will improve the document, particularly if it would enable a more clear-cut decision by the WG. However, the WG should, I think, be focusing on moving ahead. As much as we would have like to be able to pick one of the proposals and say "this is perfect and we should procede from here", things, at least as we saw them, were not so clear-cut. > Does this help with your questions below? > On USM support, why don't you ask the EVAL authors > instead of trying to interpret their double talk. I'm not sure what you're calling "double talk." The requirement "Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution" has not previously been disputed, as far as I know. > That is, EVAL authors, > 1) Can a new security model replace USM so that there > would be no need for its deployment. That is, > after the new security model is available for > deployment, will there be any need for USM > except where it is already deployed? I think any model that potentially relies on external AAA needs some kind of self-sufficient fallback. USM fuflfills that requirement. It's probably possible to define a new security model with comparable fallback capabilities, like the local accounts in SBSM, but that begs the question of how these are managed. So yes, to the extent that a new model re-impliments some key USM features,and doesn't break other key needs, like device discovery, it could replace USM. Whether doing so would actually be desirable is not clear. > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > Hi David, > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > HI, > > > > > > This is a resend. Sorry if you get it twice, but > > > it's VERY IMPORTANT. > > > > > > Regards, > > > /david t. perkins > > > > > > ---------- Forwarded message ---------- > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > From: David T. Perkins > > > To: Juergen Schoenwaelder > > > Cc: Randy Presuhn , isms@ietf.org > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > HI, > > > > > > Juergen is so right. We covered this topic in the BOFs that lead=20 > > > up to the formation of ISMS. > > > > > > That is, when a box is set up, work is done to use > > > other management interfaces. Unfortunately, to deploy SNMPv3/USM=20 > > > on the box, extra work has to be done. And for on-going=20 > > > operations, extra work needs to be done to support SNMPv3/USM. The > > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this "extra" work. > > > > Sorry, to which part of the I-D are you referring? > > > > > I believe the EVAL team didn't GET=20 > > > THIS, and thus, they came out with a fatally flawed I-D. Again,=20 > > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For=20 > > > example, The "extra" work, setting the keys for the "initial" user, isn't addressed by any of the proposals. In some respects they compound the problem by requiring provisioning of AAA keys. This has been discussed on this mailing list at some length. What other parts of the problem don't we get? > > Do you have more examples or even the full list? These would be appreciated; we're trying to be useful. > > > they believed that boxes must=20 > > > continue to support USM, so if an authentication service was not=20 > > > available, there would be a fallback method to authentication.=20 > > > WRONG!! So if there is no authentication service available, things should simply not work? If the fallback is to local accounts, we're back to the problem of specifying how they're managed, unless you accept the argument that it's simply someone else's problem. > > What the I-D states is > > > > * Must not preclude the use of USM [RFC3414], particularly if > > network instability could cause problems for the proposed > > solution > > * ... > > * Must not break basic device discovery. (Retaining USM support > > would satisfy this goal.) > > > > I don't see a statement saying "boxes must continue to support USM". ... Indeed, we did not say boxes must continue to support USM. The requirement is that this solution must not preclude supporting USM. > > > There is NO NEED for USM, except > > > for backwards compatibility with the VERY small number of=20 > > > SNMPv3/USM managers. > > > > Is there support for this statement by other WG members? > > > > > The WG will continue to go around in circles and come > > > up with clever engineering solutions (because the > > > EVAL authors and members of the WG are really smart > > > engineers) until some basic understanding is reached > > > on the operational problem to be solved. ... Which operational problem(s) do you believe are the ones to be solved, if not the ones in our charter? 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@ietf.org Mon Feb 28 12:49:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15411; Mon, 28 Feb 2005 12:49:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5p2g-0004Qp-3r; Mon, 28 Feb 2005 12:50:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5p0J-0000vA-Be; Mon, 28 Feb 2005 12:48:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5p0I-0000v5-26 for isms@megatron.ietf.org; Mon, 28 Feb 2005 12:48:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15198 for ; Mon, 28 Feb 2005 12:48:19 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5p14-0004OG-S2 for isms@ietf.org; Mon, 28 Feb 2005 12:49:11 -0500 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 JAA20990; Mon, 28 Feb 2005 09:47:57 -0800 (PST) Received: from XCH-NWBH-02.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 j1SHm8E19077; Mon, 28 Feb 2005 11:48:08 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 09:48:06 -0800 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] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 09:48:05 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCB8@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQ From: "Fleischman, Eric" To: "Eric Rescorla" X-OriginalArrivalTime: 28 Feb 2005 17:48:06.0342 (UTC) FILETIME=[A887BE60:01C51DBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable From: Eric Rescorla [mailto:ekr@rtfm.com]=20 >> 2) SNMP symmetric keys may be assembled from passwords >I'm not sure that this is a showstopper. Obviously, it's=20 >better to have an authentication system that's not susceptible=20 >to dictionary attack, but a system which is susceptible to=20 >dictionary attack is far better than no system at all (cf.=20 >CRAM-MD5, etc.) Do you want to ban passwords or simply provide=20 >an alternative. I agree with you, Eric: this is not a show-stopper. Undesirable, yes. That is why it is at the beginning of the list (i.e., not a highest priority item). What makes it bad, in my mind, is when it is combined with other issues, such as Issue 3 (no PFS), and issue 5 (i.e., the default lifetimes of the privacy key). As Uri has pointed out, support for AES has dampened the affect of these combined blemishes but they nevertheless are weaknesses that can be leveraged by "bad guys". No, I certainly don't want to ban passwords, since they are part of the current USM. My view is that USM is good for many deployments and so those deployments shouldn't be forced to undergo the disruptions that change causes. However, some deployments have need for more security than what USM provides, and that is what we in the ISMS WG are trying to address -- or, at least, this is what I think we are trying to address. >> 3) Key updates do not provide for Perfect Forward Security >Why do you think this is a requirement? Many security=20 >systems (e.g. SSL) do perfectly well without using PFS.=20 >(SSL has a PFS mode, but the dominant modes, at least for HTTPS,=20 >do not provide PFS). Good point, Eric. I fear that my point is motivated by the local USM situation and that, had we more adequate keys (i.e., keys that were stronger than passwords) and had we more adequate privacy (i.e., if we had a "session concept" such as TLS) and had we a better operationally secure system (e.g., fool-proof symmetric key exchange) SNMP-deployment-wide, then this wouldn't be an issue. However, given password-assembled keys and bad privacy default configurations, the lack of PFS is A Very Big Deal -- something it wouldn't have been if the keys were stronger to begin with. Uri will probably argue that given AES, this is no longer a big deal. Half of my mind agrees with him, but then the other half remembers how creatively I've been cracked in the past, and I really don't want to be giving the crackers any needless ammunition. Rather, I want SNMP to have similar strong defense in depth as the rest of my systems, which a near-total reliance on AES does not provide. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 13:03:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16677; Mon, 28 Feb 2005 13:03:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pFX-0004mZ-Ui; Mon, 28 Feb 2005 13:04:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pCQ-0003fr-8B; Mon, 28 Feb 2005 13:00:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pCO-0003fe-Jy for isms@megatron.ietf.org; Mon, 28 Feb 2005 13:00:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16458 for ; Mon, 28 Feb 2005 13:00:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pDB-0004i4-Iq for isms@ietf.org; Mon, 28 Feb 2005 13:01:41 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2005 10:01:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== 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 j1SI0PqA005476; Mon, 28 Feb 2005 10:00:37 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] draft agenda for Minneapolis Date: Mon, 28 Feb 2005 10:03:40 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6904C5B080@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] draft agenda for Minneapolis Thread-Index: AcUdszCX2hrDDaCjSOWF3wI7JUaE/gACqHlw From: "Salowey, Joe" To: "Ken Hornstein" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Monday, February 28, 2005 8:23 AM > To: isms@ietf.org > Subject: Re: [Isms] draft agenda for Minneapolis=20 >=20 > >EUSM will use the EAP-TLS protocol defined in RFC2716 as the=20 > EAP method=20 > >to support authentication systems such as Kerberos, > >X.509 and local accounts. >=20 > (WG chair hat off) >=20 > Upon reading RFC2716, I've discovered that it only mentions=20 > Kerberos (and Public Key) once. Specifically, it says: >=20 > Through the use of EAP, support for a number of=20 > authentication schemes may be added, including smart cards,=20 > Kerberos, Public Key, One Time Passwords, and others. To date=20 > however, EAP methods such as [6] have focussed on=20 > authenticating a client to a server. >=20 > It doesn't really mention how this will happen. If you look=20 > at the EAP document (RFC3748), it doesn't explain how you=20 > could use Kerberos or PKI with EAP either (I looked at PEAP,=20 > but that seems to focus only on protecting the EAP exchange,=20 > rather than doing certificate validation as part of the EAP=20 > authentication). >=20 > Maybe I'm missing something, but it seems like there's a bit=20 > of handwaving here. >=20 [Joe] It is true that EAP (RFC 3748) does not specify authentication methods, it specifies a way to carry out an authentication exchange. It is also true that there are few EAP Methods that are currently defined as RFCs. However, RFC 2716 specifies EAP-TLS which uses TLS ciphersuites for authentication. TLS ciphersuites provide mutual authentication of peers using various types of credentials. The EAP-TLS specification is no worse than the TLS specification a specifying how PKI can be used in any particular environment, but I agree that there needs to be some additional specification around how certificates and PKI can be used with respect to SNMPv3, but my feeling is that TLS ciphersuites give us as good a good basic mechanism for PKI support. All of the EAP-TLS implementations I know support X.509 public key certificates for mutual authentication. =20 RFC 2712 describes Kerberos ciphersuites for TLS. I agree that here as well additional specification around how Kerberos is used specific to SNMP is needed (for example what principal name is used), but I also feel that this provides a good base. Perhaps there are better ways to implement a Kerberos EAP mechanism, the Kitten working group is making enhancements to GSSAPI which could make a GSSAPI EAP mechanism easier to implement. This is something the working group can discuss. In any case I think it would be advantageous to use an existing authentication frameworks (such as EAP and TLS) where possible and if required extend these frameworks with new methods that could be used with other solutions. The requirements for SNMP should not be radically different than other uses for EAP so it is the intent that enhancements made for SNMP should be applicable to the mainstream of EAP development. Joe > --Ken >=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@ietf.org Mon Feb 28 13:03:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16717; Mon, 28 Feb 2005 13:03:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pFk-0004n3-6C; Mon, 28 Feb 2005 13:04:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pDp-00042q-0w; Mon, 28 Feb 2005 13:02:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pDm-00042l-Rb for isms@megatron.ietf.org; Mon, 28 Feb 2005 13:02:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16546 for ; Mon, 28 Feb 2005 13:02:16 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pEZ-0004kH-LQ for isms@ietf.org; Mon, 28 Feb 2005 13:03:08 -0500 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 MAA09795; Mon, 28 Feb 2005 12:02:08 -0600 (CST) Received: from XCH-NWBH-02.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 j1SI27E08448; Mon, 28 Feb 2005 12:02:07 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 10:02:04 -0800 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] Clarifications about EUSM Date: Mon, 28 Feb 2005 10:02:04 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCB9@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrgACgK/XAAFu53MAAZ3rmgAJ5SrUA= From: "Fleischman, Eric" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 28 Feb 2005 18:02:04.0591 (UTC) FILETIME=[9C2A63F0:01C51DBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: quoted-printable Uri, >From where I sit, there are two fundamental issues for this WG to agree upon: 1) Are we trying to improve USM security in a manner that is as transparent as possible to USM (e.g., create a USMv2) or are we creating a configuration alternative to potentially replace USM, both of which are possibilities anticipated by SNMPv3?=20 2) If we are creating a security alternative to USM, then what are the security requirements we are hoping to address? I have provided such a list, as have others. We as a community need to articulate the official ISMS list if we are to make progress. I thought that the answer to the first question was that we were creating an enhanced security model that needs not be compatible with USM (i.e., it is a possible configuration replacement for USM). Is this also how you see things? Given my answer to the first question, it seems obvious to me that our efforts need to address all of the perceived blemishes with USM such that deployments will have three basic SNMP configuration alternatives to choose between: (1) no SNMP security, (2) USM security, and (3) ISMS security. If ISMS security doesn't address all of the perceived blemishes with USM, then who-knows-how-many additional alternatives will be proposed to USM, which would create churn/confusion, which would be very bad for SNMP in general and an untenable situation for product developers and end users in particular. --Eric -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Friday, February 25, 2005 5:46 AM To: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Eric, we had this discussion before. Security costs, both in performance degradation and administration. "Secure enough" means different levels with different costs for different people. For example, I don't want to be as secure as you want to - and pay the cost that you'll pay for that. This is why SNMPv3 from the beginning aimed at being modular and capable of using several security models, possibly at the same time within the same SNMP engine. The idea is - there's no "one sie fits all" solution. There will always be Erics for who the existing model isn't "secure enough", and then some other guys (name withheld to protect the guilty) for who SHA-1 is too slow - so it must be MD5, otherwise he cannot use message integrity; and then everything in between... Other security models are encouraged, especially if there is market demand for them. What's so difficult about this?! IMHO the one thing one has to take care designing a new security model is clean integration with SNMPv3 Access Control (VACM or other model if you care to create one) - make sure all the necessary information is collected and passed to it from your security model. And of course preserving the outer message wrapper so that the protocol engine can pass it to the right security model, would help. That's it!=20 What I want out of this WG is an easy clean method to integrate with other infrastructures, such that access to authorizing capabilities of SNMPv3 is available and clean. A method that can be used by any security model.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 13:18:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18471; Mon, 28 Feb 2005 13:18:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pTY-0005Bv-Hv; Mon, 28 Feb 2005 13:18:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pQb-0008FG-7h; Mon, 28 Feb 2005 13:15:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5pQZ-0008FB-Ra for isms@megatron.ietf.org; Mon, 28 Feb 2005 13:15:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18286 for ; Mon, 28 Feb 2005 13:15:29 -0500 (EST) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5pRH-00058k-1B for isms@ietf.org; Mon, 28 Feb 2005 13:16:21 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j1SIFJZC004133 for ; Mon, 28 Feb 2005 13:15:19 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 28 Feb 2005 13:15:19 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 28 Feb 2005 13:15:19 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 13:15:19 -0500 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: WG Consensus? (was RE: [Isms] achieving market saturation with ISMS (fwd)) Date: Mon, 28 Feb 2005 13:15:18 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19148@MAANDMBX2.ets.enterasys.com> Thread-Topic: WG Consensus? (was RE: [Isms] achieving market saturation with ISMS (fwd)) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1IwAAHvDOA= From: "Nelson, David" To: X-OriginalArrivalTime: 28 Feb 2005 18:15:19.0327 (UTC) FILETIME=[75DD7AF0:01C51DC1] 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:41.5966 ) 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 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Eric Fleishman writes... > Other > than discussions in the SNMP mail list over two years ago, I haven't had > any takers in this WG. Thus, from where I sit, the following ARE > consensus ISMS requirements, listed in order of increasing importance: I'm responding to what is written here, without the benefit of context, so clarification is welcomed. However, what I read is an assertion that postings of requirements, which received no discussion on the WG mailing list, constitute the WG consensus. There are times when silence is acquiescence, but more and more these days silence simply means disengagement. More often now, WG consensus needs to be ascertained by active responses, rather than passive non-responses. =20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 14:16:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24356; Mon, 28 Feb 2005 14:16:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qOR-0006Ul-Am; Mon, 28 Feb 2005 14:17:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qMM-0007dX-Ou; Mon, 28 Feb 2005 14:15:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qMK-0007dR-PN for isms@megatron.ietf.org; Mon, 28 Feb 2005 14:15:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24244 for ; Mon, 28 Feb 2005 14:15:11 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qN6-0006Sv-9l for isms@ietf.org; Mon, 28 Feb 2005 14:16:02 -0500 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 LAA05460; Mon, 28 Feb 2005 11:14:48 -0800 (PST) Received: from XCH-NWBH-02.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 j1SJExE03460; Mon, 28 Feb 2005 13:14:59 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 11:14:55 -0800 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: WG Consensus? (was RE: [Isms] achieving market saturation with ISMS(fwd)) Date: Mon, 28 Feb 2005 11:14:54 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCBC@xch-nw-09.nw.nos.boeing.com> Thread-Topic: WG Consensus? (was RE: [Isms] achieving market saturation with ISMS(fwd)) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1IwAAHvDOAAAdeokA== From: "Fleischman, Eric" To: "Nelson, David" , X-OriginalArrivalTime: 28 Feb 2005 19:14:55.0186 (UTC) FILETIME=[C93E4320:01C51DC9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable David, What you write is certainly a possibility. However, the basis for my claim for WG consensus on my list of requirements is that:=20 1) I posted essentially the same list at least five times to this WG since it was formed -- eight times if you include the BOFs,=20 2) I didn't receive push-back to this list=20 3) I did receive clarifying comments/discussions, such as what Eric Rescorla has just done,=20 4) several people responded favorably, agreeing with listed requirements 5) all three submitted I-Ds have addressed some of these requirements (with one addressing all of them). It thus represents the Union of the requirements to which the I-Ds responded. However, what I care about is having the WG creating a concrete list of requirements TOGETHER rather than others necessarily adopt my list as is. That is, what is needed is a common list WG-wide -- this should have been formally done months ago. My list is an appropriate starting point, since it represents a TENTATIVE consensus. However, I sincerely doubt that my list will be the final finishing point for the WG since I have not updated it by including the insights of others (i.e., postings of other requirements by other WG participants). --Eric -----Original Message----- From: Nelson, David [mailto:dnelson@enterasys.com]=20 Sent: Monday, February 28, 2005 10:15 AM To: isms@ietf.org Subject: WG Consensus? (was RE: [Isms] achieving market saturation with ISMS(fwd)) Eric Fleishman writes... > Other > than discussions in the SNMP mail list over two years ago, I haven't had > any takers in this WG. Thus, from where I sit, the following ARE=20 > consensus ISMS requirements, listed in order of increasing importance: I'm responding to what is written here, without the benefit of context, so clarification is welcomed. However, what I read is an assertion that postings of requirements, which received no discussion on the WG mailing list, constitute the WG consensus. There are times when silence is acquiescence, but more and more these days silence simply means disengagement. More often now, WG consensus needs to be ascertained by active responses, rather than passive non-responses. =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@ietf.org Mon Feb 28 14:41:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27677; Mon, 28 Feb 2005 14:41:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qmY-0007A1-Av; Mon, 28 Feb 2005 14:42:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qkq-0005mx-91; Mon, 28 Feb 2005 14:40:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5qko-0005mr-KU for isms@megatron.ietf.org; Mon, 28 Feb 2005 14:40:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27595 for ; Mon, 28 Feb 2005 14:40:29 -0500 (EST) Message-Id: <200502281940.OAA27595@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5qlc-00078Y-9z for isms@ietf.org; Mon, 28 Feb 2005 14:41:20 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005022819402001200rq8gje>; Mon, 28 Feb 2005 19:40:20 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Randy Presuhn'" , Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 14:40:17 -0500 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: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1IwAAO1g6A= In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCB6@xch-nw-09.nw.nos.boeing.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: f6ef73100908d67495ce675c3fe8f472 Content-Transfer-Encoding: 7bit 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a0ecb232550b38fd41a3cf6a312fbabc Content-Transfer-Encoding: 7bit Hi Eric, >From where I sit as a proposal writer, I am not of the impression that your list is ISMS consensus of the requirements, and have not been working to address each of your requirements with the TLSM proposal. I consider your list to be a wish list from one contributor - an important contributor, but still just one contributor. >From the charter: "Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. ... The ISMS working group will focus on finding and identifying a solution for the first of the two above mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators. ... It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411." RFC3411 lists Security Requirements of the Architecture; I consider that list to be the security requirements. In a BOF held a few years ago, "Security Requirements for Network Management Protocols", sponsored by the Security Area and attended by many operators, it was concluded that SNMPv3 (using USM and VACM) was secure, although AES support was desired. I have seen extremely few complaints that USM is inadequately secure (given AES support); I recall complaints from you and from Wes, but not from others. I don't consider the WG consensus to be that we were striving to provide stronger security, but rather that we are trying to improve the deployability of SNMPv3 by leveraging existing security infrastructure to meet the SNMPv3 requirements for security defined in RFC3411. I have seen many complaints that SNMPv3 is hard to deploy; I have been trying to address the deployment issue, and I think the bulk of the WG are focusing on the deployment issue. In an IAB workshop for network management, with numerous operators present, there were complaints about the SNMP ease-of-use, but none about SNMPv3 not being secure enough. I think 90% of operators are satisifed that USM is secure, and the WG is trying to make it possible for that 90% to deploy SNMPv3 (with security comparable to USM) more easily. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Monday, February 28, 2005 12:16 PM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS (fwd) > > "Wish List"??? It is my belief that I have been articulating security > requirements for the new protocol. I have frequently invited > discussions > as to why the following SNMPv3 USM blemishes need to be > improved. Other > than discussions in the SNMP mail list over two years ago, I > haven't had > any takers in this WG. Thus, from where I sit, the following ARE > consensus ISMS requirements, listed in order of increasing importance: > 1) no provisions for two-factored authentication > 2) SNMP symmetric keys may be assembled from passwords > 3) Key updates do not provide for Perfect Forward Security > 4) Inherent Symmetric Key distribution problems > 5) Lack of viable session keys > 6) SNMPv3 USM keys are unrelated to any existing authentication system > within a deployment (e.g., Kerberos, PKI, Radius, etc.) > > --Eric > > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, February 25, 2005 5:01 PM > To: isms@ietf.org > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > > Hi - > > > From: "David T. Perkins" > > To: "Juergen Quittek" > > Cc: > > Sent: Friday, February 25, 2005 8:51 AM > > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > > > > HI, > > > > The WG is the guide, not the EVAL I-D. > > > > The EVAL I-D is fatally flawed because, > > 1) It used eval aspects not included in the WG charter > > or that had rough concensus on the WG charter. > > Please forgive us for attempting to include points raised in > discussion > on the working group mailing list, like those from Eric Fleischman's > wish list, that appeared to not be contentious, as well as any other > criteria that we may have used in trying to identify a clear "winner" > from among the proposals. > > > 2) It specified eval criteria in section 2.3 (operational > > scenarios), but did not include the result of > > these operational scenarios in the EVAL I-D. > > Please forgive us for submitting a -00- draft that is not perfect. I > guess we erred by trying to produce something helpful in time for the > i-d cutoff, rather than waiting for something that was complete in all > respects. > > > 3) It mischaracterized the features of the proposals. > > Please forgive us for not getting everything right. Please send text, > and we'll happily correct errors where we've misunderstood the > proposals. > > > 4) It based it's recomendations on facts the authors > > didn't know and ignored facts authors should know > > (or that could be determined). > > Please forgive our lack of omniscience. We'll happily > incorporate text > that will improve the document, particularly if it would enable a more > clear-cut decision by the WG. However, the WG should, I think, be > focusing on moving ahead. As much as we would have like to be able to > pick one of the proposals and say "this is perfect and we > should procede > from here", things, at least as we saw them, were not so clear-cut. > > > Does this help with your questions below? > > On USM support, why don't you ask the EVAL authors > > instead of trying to interpret their double talk. > > I'm not sure what you're calling "double talk." The requirement > "Must not preclude the use of USM [RFC3414], particularly if network > instability could cause problems for the proposed solution" has not > previously been disputed, as far as I know. > > > That is, EVAL authors, > > 1) Can a new security model replace USM so that there > > would be no need for its deployment. That is, > > after the new security model is available for > > deployment, will there be any need for USM > > except where it is already deployed? > > I think any model that potentially relies on external AAA needs some > kind of self-sufficient fallback. USM fuflfills that > requirement. It's > probably possible to define a new security model with comparable > fallback capabilities, like the local accounts in SBSM, but that begs > the question of how these are managed. So yes, to the extent > that a new > model re-impliments some key USM features,and doesn't break other key > needs, like device discovery, it could replace USM. Whether doing so > would actually be desirable is not clear. > > > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > > > Hi David, > > > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > > > HI, > > > > > > > > This is a resend. Sorry if you get it twice, but > > > > it's VERY IMPORTANT. > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > ---------- Forwarded message ---------- > > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > > From: David T. Perkins > > > > To: Juergen Schoenwaelder > > > > Cc: Randy Presuhn , isms@ietf.org > > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > > > HI, > > > > > > > > Juergen is so right. We covered this topic in the BOFs > that lead > > > > up to the formation of ISMS. > > > > > > > > That is, when a box is set up, work is done to use > > > > other management interfaces. Unfortunately, to deploy > SNMPv3/USM > > > > on the box, extra work has to be done. And for on-going > > > > operations, extra work needs to be done to support > SNMPv3/USM. The > > > > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this > "extra" work. > > > > > > Sorry, to which part of the I-D are you referring? > > > > > > > I believe the EVAL team didn't GET > > > > THIS, and thus, they came out with a fatally flawed I-D. Again, > > > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For > > > > example, > > The "extra" work, setting the keys for the "initial" user, isn't > addressed by any of the proposals. In some respects they compound the > problem by requiring provisioning of AAA keys. This has been > discussed > on this mailing list at some length. What other parts of the problem > don't we get? > > > > Do you have more examples or even the full list? > > These would be appreciated; we're trying to be useful. > > > > > they believed that > boxes must > > > > continue to support USM, so if an authentication > service was not > > > > available, there would be a fallback method to authentication. > > > > WRONG!! > > So if there is no authentication service available, things > should simply > not work? If the fallback is to local accounts, we're back to the > problem of specifying how they're managed, unless you accept the > argument that it's simply someone else's problem. > > > > What the I-D states is > > > > > > * Must not preclude the use of USM [RFC3414], > particularly if > > > network instability could cause problems for the proposed > > > solution > > > * ... > > > * Must not break basic device discovery. (Retaining USM > support > > > would satisfy this goal.) > > > > > > I don't see a statement saying "boxes must continue to > support USM". > ... > > Indeed, we did not say boxes must continue to support USM. > The requirement is that this solution must not preclude > supporting USM. > > > > > There is NO NEED for > USM, except > > > > > for backwards compatibility with the VERY small number of > > > > SNMPv3/USM managers. > > > > > > Is there support for this statement by other WG members? > > > > > > > The WG will continue to go around in circles and come > > > > up with clever engineering solutions (because the > > > > EVAL authors and members of the WG are really smart > > > > engineers) until some basic understanding is reached > > > > on the operational problem to be solved. > ... > > Which operational problem(s) do you believe are the ones to > be solved, if not the ones in our charter? > > 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@ietf.org Mon Feb 28 15:03:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00084; Mon, 28 Feb 2005 15:03:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5r88-0007Zm-0a; Mon, 28 Feb 2005 15:04:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5r4U-0003AE-11; Mon, 28 Feb 2005 15:00:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5r4S-0003A9-TD for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:00:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29602 for ; Mon, 28 Feb 2005 15:00:47 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5r5F-0007Wq-Uh for isms@ietf.org; Mon, 28 Feb 2005 15:01:39 -0500 Received: from h-68-165-5-77.snvacaid.dynamic.covad.net ([68.165.5.77] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D5r4J-000026-00 for isms@ietf.org; Mon, 28 Feb 2005 12:00:39 -0800 Message-ID: <006501c51dd0$2cbe4fc0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <5B58696DB20B9140AD20E0685C573A6404FDDCBC@xch-nw-09.nw.nos.boeing.com> Subject: Re: WG Consensus? (was RE: [Isms] achieving market saturation withISMS(fwd)) Date: Mon, 28 Feb 2005 12:00:38 -0800 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Hi - > From: "Fleischman, Eric" > To: "Nelson, David" ; > Sent: Monday, February 28, 2005 11:14 AM > Subject: RE: WG Consensus? (was RE: [Isms] achieving market saturation withISMS(fwd)) .. > 5) all three submitted I-Ds have addressed some of these requirements > (with one addressing all of them). It thus represents the Union of the > requirements to which the I-Ds responded. ... Not quite. Some I-Ds addressed requirements not on your list. Consequently, your list is not the union of the requirements. If it were, the decision would have been relatively simple in favor of the one proposal that attempts to address your list. Other requirements, e.g., those from the charter, make things less clear cut. David Nelson is making an important point, and it's an issue the evaluation team debated: whether your list should be treated as consensus requirements or not. Dave Perkins seems to believe the evaluation team erred in considering those requirements, since they were not spelled out in the WG charter. Others clearly believe we should have given them more weight. > However, what I care about is having the WG creating a concrete list of > requirements TOGETHER rather than others necessarily adopt my list as > is. That is, what is needed is a common list WG-wide -- this should have This certainly would have made evaluation easier. I suspect that getting WG-wide agreement on some of the items will not be easy, though it ultimately has to be done, even if only ex post facto in the definition of what the protocol does. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 15:40:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04637; Mon, 28 Feb 2005 15:40:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rha-0008KA-8u; Mon, 28 Feb 2005 15:41:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rex-0002si-H9; Mon, 28 Feb 2005 15:38:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5reu-0002sY-S5 for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:38:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04518 for ; Mon, 28 Feb 2005 15:38:27 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rfi-0008Hl-Mf for isms@ietf.org; Mon, 28 Feb 2005 15:39:19 -0500 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 MAA26827; Mon, 28 Feb 2005 12:38:17 -0800 (PST) Received: from XCH-NWBH-02.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 j1SKcHI05095; Mon, 28 Feb 2005 12:38:17 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:38:16 -0800 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] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 12:38:16 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCBD@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1IwAAO1g6AAAjzwoA== From: "Fleischman, Eric" To: , "Randy Presuhn" , X-OriginalArrivalTime: 28 Feb 2005 20:38:16.0900 (UTC) FILETIME=[6E7F4040:01C51DD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 46ad68ada464411807db2a0edd5648ae Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 Content-Transfer-Encoding: quoted-printable David, Your charter quote concerns me because I believe that it endorses what I have been suggesting and you apparently interpret it differently. Concerning the phrase in the charter "creating a security model", do you interpret that as being an optional replacement for USM or a modification to USM? I assume by your last paragraph that you believe the former. If so, then we are somewhat on the same page together. Concerning your 90% number, what is to be lost in addressing the needs of the remaining 10% who do not believe SNMP USM to be adequately secure -- or, more accurately, who believe that the current USM implementations cannot be readily deployed in a secure manner in large, multi-vendor environments? Would you have SNMP continue to fragment in terms of various security gradations when one alteration could satisfy everyone? After all, what I am seeking are three possible deployment configurations (1) no security, (2) traditional USM security, and (3) adequate security for the environments in which I work. Why do you apparently urge needless and destructive fragmentation, fragmentation that does not address the security needs of the large deployment, which is what ISMS is explicitly trying to do (i.e., READ THE CHARTER!!!)?=20 It has been my contention all along that the reason why it is difficult to securely deploy the SNMPv3 USM in large distributions is due to inherent and significant weaknesses within the USM's security design that are difficult to overcome when creating secure multi-vendor deployment. This is the basis for my requirements list. I disagree with your claims that RFC 3411 lists our security requirements. It is very obvious to me that the SNMP security community has NEVER historically considered the larger deployment environment -- otherwise it NEVER would have defined a security proposal that cannot interwork with ANY other IETF protocol nor with any installed authentication/authorization system. This is a big reason for why the charter is written as it is. Therefore, I STATE that RFC 3411 reflects the historic bias of the SNMP security community rather than the needs of the SNMP user community. Therefore, the view from my knothole as an SNMP user, is that you have not yet accepted the ISMS charter nor understood why ISMS is needed. You are therefore not appropriately responding to the ISMS goals. In your favor, I do believe that there are numerous user communities with fairly homogeneous device deployments (e.g., ISPs) and/or with very small (tiny) numbers of devices (e.g., less than 100,000) that probably can securely deploy SNMPv3 USM exactly as it currently is defined. However, since I do not work in such an environment, I very much would like SNMP's security to become adequate for the environment in which I do work. This is why I oppose what you are suggesting because you are basically saying that my type of user is not worthy of being supported, since we are only 10% of the deployments. However, consider how many billions of devices are included in our 10%!!!! In any case, the bottom line is that the ISMS WG is primarily created to support users like me since the needs of your 90% are already covered. --Eric -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Monday, February 28, 2005 11:40 AM To: Fleischman, Eric; 'Randy Presuhn'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Hi Eric, >From where I sit as a proposal writer, I am not of the impression that your list is ISMS consensus of the requirements, and have not been working to address each of your requirements with the TLSM proposal. I consider your list to be a wish list from one contributor - an important contributor, but still just one contributor. >From the charter: "Although the enhanced protocol is secure, operators and administrators find that deploying it can be problematic in large distributions. ... The ISMS working group will focus on finding and identifying a solution for the first of the two above mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators. ... It should also be compliant with the security model architectural block of SNMPv3, as outlined in RFC 3411."=20 RFC3411 lists Security Requirements of the Architecture; I consider that list to be the security requirements. In a BOF held a few years ago, "Security Requirements for Network Management Protocols", sponsored by the Security Area and attended by many operators, it was concluded that SNMPv3 (using USM and VACM) was secure, although AES support was desired. I have seen extremely few complaints that USM is inadequately secure (given AES support); I recall complaints from you and from Wes, but not from others. I don't consider the WG consensus to be that we were striving to provide stronger security, but rather that we are trying to improve the deployability of SNMPv3 by leveraging existing security infrastructure to meet the SNMPv3 requirements for security defined in RFC3411.=20 I have seen many complaints that SNMPv3 is hard to deploy; I have been trying to address the deployment issue, and I think the bulk of the WG are focusing on the deployment issue. In an IAB workshop for network management, with numerous operators present, there were complaints about the SNMP ease-of-use, but none about SNMPv3 not being secure enough. I think 90% of operators are satisifed that USM is secure, and the WG is trying to make it possible for that 90% to deploy SNMPv3 (with security comparable to USM) more easily. David Harrington dbharrington@comcast.net=20 > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Monday, February 28, 2005 12:16 PM > To: Randy Presuhn; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS (fwd) >=20 > "Wish List"??? It is my belief that I have been articulating security > requirements for the new protocol. I have frequently invited > discussions > as to why the following SNMPv3 USM blemishes need to be=20 > improved. Other > than discussions in the SNMP mail list over two years ago, I=20 > haven't had > any takers in this WG. Thus, from where I sit, the following ARE > consensus ISMS requirements, listed in order of increasing importance: > 1) no provisions for two-factored authentication > 2) SNMP symmetric keys may be assembled from passwords > 3) Key updates do not provide for Perfect Forward Security > 4) Inherent Symmetric Key distribution problems > 5) Lack of viable session keys > 6) SNMPv3 USM keys are unrelated to any existing authentication system > within a deployment (e.g., Kerberos, PKI, Radius, etc.) >=20 > --Eric >=20 > -----Original Message----- > From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] > Sent: Friday, February 25, 2005 5:01 PM > To: isms@ietf.org > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) >=20 >=20 > Hi - >=20 > > From: "David T. Perkins" > > To: "Juergen Quittek" > > Cc: > > Sent: Friday, February 25, 2005 8:51 AM > > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > >=20 > > HI, > > > > The WG is the guide, not the EVAL I-D. > > > > The EVAL I-D is fatally flawed because, > > 1) It used eval aspects not included in the WG charter > > or that had rough concensus on the WG charter. >=20 > Please forgive us for attempting to include points raised in > discussion > on the working group mailing list, like those from Eric Fleischman's > wish list, that appeared to not be contentious, as well as any other > criteria that we may have used in trying to identify a clear "winner" > from among the proposals. >=20 > > 2) It specified eval criteria in section 2.3 (operational > > scenarios), but did not include the result of > > these operational scenarios in the EVAL I-D. >=20 > Please forgive us for submitting a -00- draft that is not perfect. I=20 > guess we erred by trying to produce something helpful in time for the > i-d cutoff, rather than waiting for something that was complete in all > respects. >=20 > > 3) It mischaracterized the features of the proposals. >=20 > Please forgive us for not getting everything right. Please send text, > and we'll happily correct errors where we've misunderstood the=20 > proposals. >=20 > > 4) It based it's recomendations on facts the authors > > didn't know and ignored facts authors should know > > (or that could be determined). >=20 > Please forgive our lack of omniscience. We'll happily > incorporate text > that will improve the document, particularly if it would enable a more > clear-cut decision by the WG. However, the WG should, I think, be=20 > focusing on moving ahead. As much as we would have like to be able to > pick one of the proposals and say "this is perfect and we > should procede > from here", things, at least as we saw them, were not so clear-cut. >=20 > > Does this help with your questions below? > > On USM support, why don't you ask the EVAL authors > > instead of trying to interpret their double talk. >=20 > I'm not sure what you're calling "double talk." The requirement > "Must not preclude the use of USM [RFC3414], particularly if network=20 > instability could cause problems for the proposed solution" has not=20 > previously been disputed, as far as I know. >=20 > > That is, EVAL authors, > > 1) Can a new security model replace USM so that there > > would be no need for its deployment. That is, > > after the new security model is available for > > deployment, will there be any need for USM > > except where it is already deployed? >=20 > I think any model that potentially relies on external AAA needs some=20 > kind of self-sufficient fallback. USM fuflfills that requirement.=20 > It's probably possible to define a new security model with comparable > fallback capabilities, like the local accounts in SBSM, but that begs > the question of how these are managed. So yes, to the extent > that a new > model re-impliments some key USM features,and doesn't break other key > needs, like device discovery, it could replace USM. Whether doing so=20 > would actually be desirable is not clear. >=20 > > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > > > Hi David, > > > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > > > HI, > > > > > > > > This is a resend. Sorry if you get it twice, but > > > > it's VERY IMPORTANT. > > > > > > > > Regards, > > > > /david t. perkins > > > > > > > > ---------- Forwarded message ---------- > > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > > From: David T. Perkins > > > > To: Juergen Schoenwaelder > > > > Cc: Randy Presuhn , isms@ietf.org > > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > > > HI, > > > > > > > > Juergen is so right. We covered this topic in the BOFs > that lead > > > > up to the formation of ISMS. > > > > > > > > That is, when a box is set up, work is done to use other=20 > > > > management interfaces. Unfortunately, to deploy > SNMPv3/USM > > > > on the box, extra work has to be done. And for on-going > > > > operations, extra work needs to be done to support=20 > SNMPv3/USM. The >=20 > > > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this > "extra" work. > > > > > > Sorry, to which part of the I-D are you referring? > > > > > > > I believe the EVAL team didn't GET=20 > > > > THIS, and thus, they came out with a fatally flawed I-D. Again,=20 > > > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For > > > > example, >=20 > The "extra" work, setting the keys for the "initial" user, isn't=20 > addressed by any of the proposals. In some respects they compound the > problem by requiring provisioning of AAA keys. This has been > discussed > on this mailing list at some length. What other parts of the problem > don't we get? >=20 > > > Do you have more examples or even the full list? >=20 > These would be appreciated; we're trying to be useful. >=20 > > > > they believed that > boxes must > > > > continue to support USM, so if an authentication > service was not > > > > available, there would be a fallback method to authentication. > > > > WRONG!! >=20 > So if there is no authentication service available, things=20 > should simply > not work? If the fallback is to local accounts, we're back to the > problem of specifying how they're managed, unless you accept the > argument that it's simply someone else's problem. >=20 > > > What the I-D states is > > > > > > * Must not preclude the use of USM [RFC3414],=20 > particularly if > > > network instability could cause problems for the proposed > > > solution > > > * ... > > > * Must not break basic device discovery. (Retaining USM > support > > > would satisfy this goal.) > > > > > > I don't see a statement saying "boxes must continue to=20 > support USM". > ... >=20 > Indeed, we did not say boxes must continue to support USM. > The requirement is that this solution must not preclude=20 > supporting USM. >=20 > > > > There is NO NEED for=20 > USM, except >=20 > > > > for backwards compatibility with the VERY small number of=20 > > > > SNMPv3/USM managers. > > > > > > Is there support for this statement by other WG members? > > > > > > > The WG will continue to go around in circles and come > > > > up with clever engineering solutions (because the > > > > EVAL authors and members of the WG are really smart > > > > engineers) until some basic understanding is reached > > > > on the operational problem to be solved. > ... >=20 > Which operational problem(s) do you believe are the ones to > be solved, if not the ones in our charter? >=20 > Randy >=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 >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 15:41:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04757; Mon, 28 Feb 2005 15:41:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rj4-0008MO-Ep; Mon, 28 Feb 2005 15:42:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rcA-0002gn-46; Mon, 28 Feb 2005 15:35:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rc8-0002gi-FK for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:35:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04216 for ; Mon, 28 Feb 2005 15:35:34 -0500 (EST) Received: from fmr13.intel.com ([192.55.52.67] helo=fmsfmr001.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rcv-0008Dv-GN for isms@ietf.org; Mon, 28 Feb 2005 15:36:27 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1SKZNYl026209; Mon, 28 Feb 2005 20:35:23 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) 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 j1SKZNwZ006487; Mon, 28 Feb 2005 20:35:23 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 M2005022812352319456 ; Mon, 28 Feb 2005 12:35:23 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:35:19 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:35:18 -0800 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, 28 Feb 2005 15:35:16 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Clarifications about EUSM Date: Mon, 28 Feb 2005 15:35:04 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C218A7@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Clarifications about EUSM Thread-Index: AcUZZw7k4081CkTjQ3qq9VE/lR1ZAAAdAFrgACgK/XAAFu53MAAZ3rmgAJ5SrUAABlvgsA== From: "Blumenthal, Uri" To: "Fleischman, Eric" , X-OriginalArrivalTime: 28 Feb 2005 20:35:16.0765 (UTC) FILETIME=[0320D4D0:01C51DD5] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: quoted-printable > 1) Are we trying to improve USM security in a manner that is as > transparent as possible to USM (e.g., create a USMv2) or are we creating > a configuration alternative to potentially replace USM, both of which > are possibilities anticipated by SNMPv3?=20 IMHO, neither. We are trying to introduce a concept of "session" in SNMP (something that was proposed approximately a decade ago and rejected then as too expensive to manage by a dumb SNMP agent). Now we're back to it, and we want it - for the benefits it offers, especially in ssecurity area. Then utilizing session - create a relation between SNMP security mechanisms and existing security infrastructure(s) such as RADIUS (or Kerberos, or PKI). This "session" concept automatically takes care of keying, both long-term and session-wide (these now are dynamic, the mapping between dynamic user name and VACM entry is created when session is established and destroyed when the session is deleted, PFS becomes possible, etc), and happens to improve security by giving clean separation between long-term and traffic (session) keys. We are not modifying USM - we're providing a "wrapper" for a security model. Like David H. said - we don't hear complaints that USM isn't secure enough (except from you, and maybe Wes). USM was reviewed several times, and found OK. What people do complain loudly about - is difficulty of deployment, and lack of integration with their existing security infrastructures. We're taking care of this (hopefully), by offering a mechanism to integrate. > I thought that the answer to the first question was that we were > creating an enhanced security model that needs not be compatible with > USM (i.e., it is a possible configuration replacement for USM). Is this > also how you see things? No this is not. We're addressing deployability issue, trying to change as little as possible/practical. IMHO, if somebody wants a different security model (with greater or lesser security than USM) - all he has to do is design it. The two requirements this new model should satisfy are: - integration with ACM (providing enough information for xACM to make decisions); - using the SNMPv3 message wrapper (so the message can be handled to the right security model). It would be nice if the purpose/reasons for this new model were given, but it is not required nor necessary. And overall, there are gazillion ways to protect SNMP traffic. For example, tunnel it through Ipsec pipe with user keying. It won't satisfy the conditions I listed above - but it surely can work. > If ISMS security doesn't address all of the perceived blemishes with USM, Perceived by who? Market doesn't seem to complain. > then who-knows-how-many additional alternatives will > be proposed to USM, which would create churn/confusion, which would be > very bad for SNMP in general and an untenable situation for product > developers and end users in particular. I'd like to see at least one alternative, that people would say "yea this is what we want!" So far, there isn't a crowd storming the gates with cartloads of new security models. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Friday, February 25, 2005 5:46 AM To: isms@ietf.org Subject: RE: [Isms] Clarifications about EUSM Eric, we had this discussion before. Security costs, both in performance degradation and administration. "Secure enough" means different levels with different costs for different people. For example, I don't want to be as secure as you want to - and pay the cost that you'll pay for that. This is why SNMPv3 from the beginning aimed at being modular and capable of using several security models, possibly at the same time within the same SNMP engine. The idea is - there's no "one sie fits all" solution. There will always be Erics for who the existing model isn't "secure enough", and then some other guys (name withheld to protect the guilty) for who SHA-1 is too slow - so it must be MD5, otherwise he cannot use message integrity; and then everything in between... Other security models are encouraged, especially if there is market demand for them. What's so difficult about this?! IMHO the one thing one has to take care designing a new security model is clean integration with SNMPv3 Access Control (VACM or other model if you care to create one) - make sure all the necessary information is collected and passed to it from your security model. And of course preserving the outer message wrapper so that the protocol engine can pass it to the right security model, would help. That's it!=20 What I want out of this WG is an easy clean method to integrate with other infrastructures, such that access to authorizing capabilities of SNMPv3 is available and clean. A method that can be used by any security model.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 15:44:32 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05194; Mon, 28 Feb 2005 15:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rlb-0008Tq-UA; Mon, 28 Feb 2005 15:45:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rjO-0003fx-7r; Mon, 28 Feb 2005 15:43:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rjK-0003fn-ON for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:43:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04886 for ; Mon, 28 Feb 2005 15:43:01 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rk8-0008O1-PK for isms@ietf.org; Mon, 28 Feb 2005 15:43:53 -0500 Received: from fmsfmr101.fm.intel.com (fmsfmr101.fm.intel.com [10.1.192.59]) 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 j1SKgqfk026949; Mon, 28 Feb 2005 20:42:52 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 j1SKfmxF013330; Mon, 28 Feb 2005 20:42:52 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 M2005022812425204484 ; Mon, 28 Feb 2005 12:42:52 -0800 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, 28 Feb 2005 12:42:51 -0800 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, 28 Feb 2005 12:42:51 -0800 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, 28 Feb 2005 15:42:50 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 15:42:37 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C218BC@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUbnoA4YdNnseF5T+2D0RODPOvuLgCGg1IwAAdBM8A= From: "Blumenthal, Uri" To: "Fleischman, Eric" , "Randy Presuhn" , X-OriginalArrivalTime: 28 Feb 2005 20:42:50.0258 (UTC) FILETIME=[116E5F20:01C51DD6] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee Content-Transfer-Encoding: quoted-printable > 1) no provisions for two-factored authentication Seems that nobody cares (except for you). > 2) SNMP symmetric keys may be assembled from passwords Any keys may be assembled from passswords - just run a crypto-hash over them. SNMP just offers a "standard" way of doing that. > 3) Key updates do not provide for Perfect Forward Security Seems that nobody cares. > 4) Inherent Symmetric Key distribution problems Use symmatric key algorithms - have key distribution. We're addressing this. > 5) Lack of viable session keys "No session" =3D "no session keys". We're addressing this. > 6) SNMPv3 USM keys are unrelated to any existing authentication system > within a deployment (e.g., Kerberos, PKI, Radius, etc.) With no session concept - it's the only feasible way. As we're introducing session - we're addressing this. -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Friday, February 25, 2005 5:01 PM To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Hi - > From: "David T. Perkins" > To: "Juergen Quittek" > Cc: > Sent: Friday, February 25, 2005 8:51 AM > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > HI, > > The WG is the guide, not the EVAL I-D. > > The EVAL I-D is fatally flawed because, > 1) It used eval aspects not included in the WG charter > or that had rough concensus on the WG charter. Please forgive us for attempting to include points raised in discussion on the working group mailing list, like those from Eric Fleischman's wish list, that appeared to not be contentious, as well as any other criteria that we may have used in trying to identify a clear "winner" from among the proposals. > 2) It specified eval criteria in section 2.3 (operational > scenarios), but did not include the result of > these operational scenarios in the EVAL I-D. Please forgive us for submitting a -00- draft that is not perfect. I guess we erred by trying to produce something helpful in time for the i-d cutoff, rather than waiting for something that was complete in all respects. > 3) It mischaracterized the features of the proposals. Please forgive us for not getting everything right. Please send text, and we'll happily correct errors where we've misunderstood the proposals. > 4) It based it's recomendations on facts the authors > didn't know and ignored facts authors should know > (or that could be determined). Please forgive our lack of omniscience. We'll happily incorporate text that will improve the document, particularly if it would enable a more clear-cut decision by the WG. However, the WG should, I think, be focusing on moving ahead. As much as we would have like to be able to pick one of the proposals and say "this is perfect and we should procede from here", things, at least as we saw them, were not so clear-cut. > Does this help with your questions below? > On USM support, why don't you ask the EVAL authors > instead of trying to interpret their double talk. I'm not sure what you're calling "double talk." The requirement "Must not preclude the use of USM [RFC3414], particularly if network instability could cause problems for the proposed solution" has not previously been disputed, as far as I know. > That is, EVAL authors, > 1) Can a new security model replace USM so that there > would be no need for its deployment. That is, > after the new security model is available for > deployment, will there be any need for USM > except where it is already deployed? I think any model that potentially relies on external AAA needs some kind of self-sufficient fallback. USM fuflfills that requirement. It's probably possible to define a new security model with comparable fallback capabilities, like the local accounts in SBSM, but that begs the question of how these are managed. So yes, to the extent that a new model re-impliments some key USM features,and doesn't break other key needs, like device discovery, it could replace USM. Whether doing so would actually be desirable is not clear. > On Fri, 25 Feb 2005, Juergen Quittek wrote: > > > Hi David, > > > > --On 24.02.2005 22:05 h +0100 David T. Perkins wrote: > > > > > HI, > > > > > > This is a resend. Sorry if you get it twice, but > > > it's VERY IMPORTANT. > > > > > > Regards, > > > /david t. perkins > > > > > > ---------- Forwarded message ---------- > > > Date: Thu, 24 Feb 2005 12:37:11 -0800 (PST) > > > From: David T. Perkins > > > To: Juergen Schoenwaelder > > > Cc: Randy Presuhn , isms@ietf.org > > > Subject: Re: [Isms] achieving market saturation with ISMS > > > > > > HI, > > > > > > Juergen is so right. We covered this topic in the BOFs that lead=20 > > > up to the formation of ISMS. > > > > > > That is, when a box is set up, work is done to use > > > other management interfaces. Unfortunately, to deploy SNMPv3/USM=20 > > > on the box, extra work has to be done. And for on-going=20 > > > operations, extra work needs to be done to support SNMPv3/USM. The > > > ABSOLUTELY PRIMARY goal of ISMS is to ELIMINATE this "extra" work. > > > > Sorry, to which part of the I-D are you referring? > > > > > I believe the EVAL team didn't GET=20 > > > THIS, and thus, they came out with a fatally flawed I-D. Again,=20 > > > THEY DIDN'T UNDERSTAND THE PRIMARY PROBLEM TO BE SOLVED! For=20 > > > example, The "extra" work, setting the keys for the "initial" user, isn't addressed by any of the proposals. In some respects they compound the problem by requiring provisioning of AAA keys. This has been discussed on this mailing list at some length. What other parts of the problem don't we get? > > Do you have more examples or even the full list? These would be appreciated; we're trying to be useful. > > > they believed that boxes must=20 > > > continue to support USM, so if an authentication service was not=20 > > > available, there would be a fallback method to authentication.=20 > > > WRONG!! So if there is no authentication service available, things should simply not work? If the fallback is to local accounts, we're back to the problem of specifying how they're managed, unless you accept the argument that it's simply someone else's problem. > > What the I-D states is > > > > * Must not preclude the use of USM [RFC3414], particularly if > > network instability could cause problems for the proposed > > solution > > * ... > > * Must not break basic device discovery. (Retaining USM support > > would satisfy this goal.) > > > > I don't see a statement saying "boxes must continue to support USM". ... Indeed, we did not say boxes must continue to support USM. The requirement is that this solution must not preclude supporting USM. > > > There is NO NEED for USM, except > > > for backwards compatibility with the VERY small number of=20 > > > SNMPv3/USM managers. > > > > Is there support for this statement by other WG members? > > > > > The WG will continue to go around in circles and come > > > up with clever engineering solutions (because the > > > EVAL authors and members of the WG are really smart > > > engineers) until some basic understanding is reached > > > on the operational problem to be solved. ... Which operational problem(s) do you believe are the ones to be solved, if not the ones in our charter? 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@ietf.org Mon Feb 28 15:53:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06334; Mon, 28 Feb 2005 15:53:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rts-0000OU-9C; Mon, 28 Feb 2005 15:53:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rsI-0008Vt-Bv; Mon, 28 Feb 2005 15:52:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rsH-0008Vo-5F for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:52:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06244 for ; Mon, 28 Feb 2005 15:52:15 -0500 (EST) Received: from fmr14.intel.com ([192.55.52.68] helo=fmsfmr002.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rt4-0000My-HE for isms@ietf.org; Mon, 28 Feb 2005 15:53:07 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 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 j1SKq2fk030160; Mon, 28 Feb 2005 20:52:02 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 j1SKpmSF001739; Mon, 28 Feb 2005 20:51:59 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 M2005022812515931602 ; Mon, 28 Feb 2005 12:51:59 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:51:59 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:51:59 -0800 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, 28 Feb 2005 15:51:53 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 15:51:41 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C218C6@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SA= From: "Blumenthal, Uri" To: "Fleischman, Eric" , "Eric Rescorla" X-OriginalArrivalTime: 28 Feb 2005 20:51:53.0298 (UTC) FILETIME=[551BB320:01C51DD7] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable >>> 3) Key updates do not provide for Perfect Forward Security >> >>Why do you think this is a requirement? Many security=20 >>systems (e.g. SSL) do perfectly well without using PFS.=20 >>(SSL has a PFS mode, but the dominant modes, at least for HTTPS,=20 >>do not provide PFS). > >Good point, Eric. I fear that my point is motivated by the local USM >situation and that, had we more adequate keys (i.e., keys that were >stronger than passwords) and had we more adequate privacy (i.e., if we >had a "session concept" such as TLS) and had we a better operationally >secure system (e.g., fool-proof symmetric key exchange) >SNMP-deployment-wide, then this wouldn't be an issue. However, given >password-assembled keys and bad privacy default configurations, the lack >of PFS is A Very Big Deal -- something it wouldn't have been if the keys >were stronger to begin with. Again, what is lacking is "session" (with which comes separation between long-term and short-term or session keys). It is being addressed. > Uri will probably argue that given AES, this is no longer a big deal. Encryption algorithm has little to do with this issue. Creating session machanism=20 Has everything to do with it. I myself am perfectly happy if USM users are dynamic (and their key lifetime is session-long), created with the session by xUSM protocol. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 15:54:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06532; Mon, 28 Feb 2005 15:54:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rut-0000RT-Ma; Mon, 28 Feb 2005 15:54:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rtB-0000GK-V0; Mon, 28 Feb 2005 15:53:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5rtB-0000GD-0M for isms@megatron.ietf.org; Mon, 28 Feb 2005 15:53:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06360 for ; Mon, 28 Feb 2005 15:53:11 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5rtz-0000OS-GI for isms@ietf.org; Mon, 28 Feb 2005 15:54:03 -0500 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 OAA24179; Mon, 28 Feb 2005 14:53:02 -0600 (CST) Received: from XCH-NWBH-02.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 j1SKr2E19518; Mon, 28 Feb 2005 14:53:02 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 12:52:59 -0800 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: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Date: Mon, 28 Feb 2005 12:52:59 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCC1@xch-nw-09.nw.nos.boeing.com> Thread-Topic: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Thread-Index: AcUd0IekHS+ERqw2RfacnN+BwnxMZgABrYEw From: "Fleischman, Eric" To: "Randy Presuhn" , X-OriginalArrivalTime: 28 Feb 2005 20:52:59.0631 (UTC) FILETIME=[7CA54FF0:01C51DD7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: quoted-printable Randy, Thank you for this posting. Do you agree with me that for us to make progress that we need to formally agree as a community as to what requirements we are seeking to address? If you do, do you further agree with me that my list should be supplemented by additional requirements that I failed to note? --Eric -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com]=20 Sent: Monday, February 28, 2005 12:01 PM To: isms@ietf.org Subject: Re: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Hi - > From: "Fleischman, Eric" > To: "Nelson, David" ; > Sent: Monday, February 28, 2005 11:14 AM > Subject: RE: WG Consensus? (was RE: [Isms] achieving market saturation > withISMS(fwd)) .. > 5) all three submitted I-Ds have addressed some of these requirements=20 > (with one addressing all of them). It thus represents the Union of the > requirements to which the I-Ds responded. ... Not quite. Some I-Ds addressed requirements not on your list. Consequently, your list is not the union of the requirements. If it were, the decision would have been relatively simple in favor of the one proposal that attempts to address your list. Other requirements, e.g., those from the charter, make things less clear cut. David Nelson is making an important point, and it's an issue the evaluation team debated: whether your list should be treated as consensus requirements or not. Dave Perkins seems to believe the evaluation team erred in considering those requirements, since they were not spelled out in the WG charter. Others clearly believe we should have given them more weight. > However, what I care about is having the WG creating a concrete list=20 > of requirements TOGETHER rather than others necessarily adopt my list=20 > as is. That is, what is needed is a common list WG-wide -- this should > have This certainly would have made evaluation easier. I suspect that getting WG-wide agreement on some of the items will not be easy, though it ultimately has to be done, even if only ex post facto in the definition of what the protocol does. 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@ietf.org Mon Feb 28 16:06:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07591; Mon, 28 Feb 2005 16:06:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5s6q-0000pg-Ln; Mon, 28 Feb 2005 16:07:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s43-0004l9-J7; Mon, 28 Feb 2005 16:04:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5s42-0004kq-Is for isms@megatron.ietf.org; Mon, 28 Feb 2005 16:04:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07489 for ; Mon, 28 Feb 2005 16:04:24 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5s4o-0000n9-NB for isms@ietf.org; Mon, 28 Feb 2005 16:05:17 -0500 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 NAA02746; Mon, 28 Feb 2005 13:03:59 -0800 (PST) Received: from XCH-NWBH-02.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 j1SL4BI19614; Mon, 28 Feb 2005 13:04:11 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 13:04:05 -0800 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] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 13:04:04 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCC2@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkA== From: "Fleischman, Eric" To: "Blumenthal, Uri" X-OriginalArrivalTime: 28 Feb 2005 21:04:05.0476 (UTC) FILETIME=[09853240:01C51DD9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Uri, It seems that you and I are starting to think similarly. This is good news. >Again, what is lacking is "session" (with which comes separation between >long-term and short-term or session keys). It is being addressed. I certainly agree with you about the need for "session" but I do not believe that "session" alone will meet all of our needs. Specifically, I remain very concerned about weaknesses in the authentication system being exploited by crackers. It may be that you can hit both birds with one stone. If so, I'm very interested in how you propose doing so. Certainly, our world would be much easier if the SNMP authentication system were based on at least one of our deployed authentication infrastructures. >I myself am perfectly happy if USM users are dynamic (and their=20 >key lifetime is session-long), created with the session by=20 >xUSM protocol. I too would be very happy with such a world **if** both the session and authentication security requirements were met and the system leverage widely deployed authentication infrastructures. Replacing USM has never been my goal -- being able to security deploy SNMP in large, multivendor environments has always been my goal. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 16:41:44 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10976; Mon, 28 Feb 2005 16:41:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sez-0001XN-GA; Mon, 28 Feb 2005 16:42:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sbm-0005Ob-Ln; Mon, 28 Feb 2005 16:39:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sbl-0005OW-6p for isms@megatron.ietf.org; Mon, 28 Feb 2005 16:39:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10813 for ; Mon, 28 Feb 2005 16:39:13 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5scV-0001VY-Aq for isms@ietf.org; Mon, 28 Feb 2005 16:40:06 -0500 Received: from h-68-165-5-77.snvacaid.dynamic.covad.net ([68.165.5.77] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D5sbd-00053r-00 for isms@ietf.org; Mon, 28 Feb 2005 13:39:09 -0800 Message-ID: <009001c51ddd$ef347ea0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <5B58696DB20B9140AD20E0685C573A6404FDDCC1@xch-nw-09.nw.nos.boeing.com> Subject: Re: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Date: Mon, 28 Feb 2005 13:38:46 -0800 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: b5d20af10c334b36874c0264b10f59f1 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Hi - I agree that there's value in nailing down as many of the requirements as is practical. I'd like to see as much of this done *before* Minneapolis as possible; that way we can focus our face-time on the hard stuff. In some cases, the decision might not be binary. For example, supporting some requirement might be nice, but not if it comes at the expense of satisfying some other requirement. Some of these "other" requirements may be long-standing but oft-unspoken assumptions about the operation of management protocols, such as the desire to keep the number of round-trips to a minimum, in order to maximize the likelihood of completing operations in stressed networks. I think all of the points from your Eric Fleischman's list, the charter, and any "new" ones that folks think may have crept into the evaluation are fair game for discussion. Randy ----- Original Message ----- From: "Fleischman, Eric" To: "Randy Presuhn" ; Sent: Monday, February 28, 2005 12:52 PM Subject: RE: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Randy, Thank you for this posting. Do you agree with me that for us to make progress that we need to formally agree as a community as to what requirements we are seeking to address? If you do, do you further agree with me that my list should be supplemented by additional requirements that I failed to note? --Eric -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, February 28, 2005 12:01 PM To: isms@ietf.org Subject: Re: WG Consensus? (was RE: [Isms] achieving market saturationwithISMS(fwd)) Hi - > From: "Fleischman, Eric" > To: "Nelson, David" ; > Sent: Monday, February 28, 2005 11:14 AM > Subject: RE: WG Consensus? (was RE: [Isms] achieving market saturation > withISMS(fwd)) .. > 5) all three submitted I-Ds have addressed some of these requirements > (with one addressing all of them). It thus represents the Union of the > requirements to which the I-Ds responded. ... Not quite. Some I-Ds addressed requirements not on your list. Consequently, your list is not the union of the requirements. If it were, the decision would have been relatively simple in favor of the one proposal that attempts to address your list. Other requirements, e.g., those from the charter, make things less clear cut. David Nelson is making an important point, and it's an issue the evaluation team debated: whether your list should be treated as consensus requirements or not. Dave Perkins seems to believe the evaluation team erred in considering those requirements, since they were not spelled out in the WG charter. Others clearly believe we should have given them more weight. > However, what I care about is having the WG creating a concrete list > of requirements TOGETHER rather than others necessarily adopt my list > as is. That is, what is needed is a common list WG-wide -- this should > have This certainly would have made evaluation easier. I suspect that getting WG-wide agreement on some of the items will not be easy, though it ultimately has to be done, even if only ex post facto in the definition of what the protocol does. 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@ietf.org Mon Feb 28 16:44:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11213; Mon, 28 Feb 2005 16:44:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5shb-0001al-7p; Mon, 28 Feb 2005 16:45:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sgQ-0006ZL-2L; Mon, 28 Feb 2005 16:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sgL-0006ZF-4X for isms@megatron.ietf.org; Mon, 28 Feb 2005 16:44:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11155 for ; Mon, 28 Feb 2005 16:43:58 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sh8-0001ZO-JC for isms@ietf.org; Mon, 28 Feb 2005 16:44:52 -0500 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 j1SLhncJ020575 for ; Mon, 28 Feb 2005 13:43:49 -0800 Received: from NB5.dsperkins.com (shell4.bayarea.net [209.128.82.1]) (authenticated bits=0) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1SLhr23030371 for ; Mon, 28 Feb 2005 13:43:53 -0800 Message-Id: <5.2.0.9.2.20050228105452.025dee30@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 28 Feb 2005 12:13:58 -0800 To: isms@ietf.org From: "David T. Perkins" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Subject: [Isms] ISMS Operational Scenario/Goal 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 HI, The ISMS WG was chartered to develop a new security model for SNMPv3 to reduce the operational costs to deploy and for on-going operations with respect to identity authentication. The charter explicitly ruled out working on reducing the operational cost of authorization in the first phase. So what does this mean? Well, this was shown in detail at the first BOF. This message is a review of the operational cost scenarios. There are many types of network equipment with variation on their hardware and procedures for initial deployment and ongoing operations. Below is the description of two representative boxes. (If you don't believe that these boxes are representative, then create another description.) Representative Network Equipment -------------------------------- 1) System description a) It has a serial interface that a "terminal" is connected to that is used for initial configuration and management b) It has an Ethernet interface (typically 10/100) for management c) It can support a redundant Ethernet interface for management d) It has other interfaces for "user traffic", which may also be used for in-band management traffic e) It supports CLI management via the serial interface; telnet and ssh over the Ethernet management interface(s); and possibly ssh over the "user traffic" interfaces f) It supports WEB and SNMP management over the Ethernet management interface(s), and possibly over the "user traffic" interfaces g) It has a button to reboot the box, and the boot up has a way to "break in" on a terminal connected to the serial port so that instead of a normal startup the configuration can be erased (so the box will be like it was when it can from the manufacturer). Initial deployment a) System software is present on the box from the manufacturer b) There is no configuration, and the only way to communicate with the box is via CLI commands on a terminal connected to the serial port c) There is no operation of the Ethernet management interfaces nor operation of the user data interfaces. d) there is a single user called "admin" on the box with a zero length password. e) On boot, the box prompts for user and password. f) After successfully logging on to the box, the configuration can be changed. g) the password for user admin would be changed. h) IP configuration (such as IPv4 address, network mask, default router, etc) is specified for a management port i) ssh service is enabled, and a RSA key pair is configured for the ssh server j) either a key pair and self-signed X.509 cert is generated, or certs in PKCS#12 format are loaded (the protected content of info in PKCS#12 format would contain a CA-CERT, the box's keypair, and the box's X.509 cert). h) a CLI script is run from a configuration system over an ssh connection to set up: 1) any additional local accounts 2) the ip address and shared key for each radius server that is to be used 3) any policy rules about where management can take place, such as "local accounts" can be used only over the serial and management interface 4) the rest of the configuration is done so that the device can perform it's role in the network On going a) As new operators are added, new accounts are added to the Radius server(s) b) When an operator's password is changed, it is changed at the Radius server(s) c) When an operator's account is disabled (say, due to, say, time of day, day or week, vacation/holiday), the account is disabled at the Radius server d) When an operator's account is closed, it is closed at the radius server 2) System description a) It has no serial interface b) It has an Ethernet interface (typically 10/100) for management and "user traffic" c) It has other interfaces for "user traffic", which may also be used for in-band management traffic d) It supports CLI management via ssh over the Ethernet interface, and possibly over the "user traffic" interfaces f) It supports WEB and SNMP management over the Ethernet interface interface, and possibly over the "user traffic" interfaces g) It has a button to reboot the box, and a second button that is used to clear the configuration back to "factory defaults". If the first button is pressed, the box reboots. If second button is held pressed in while the box is booting, the configuration is cleared so the box will be like it was when it can from the manufacturer. Initial deployment a) System software is present on the box from the manufacturer b) There is no configuration, and the only way to communicate with the box is via the Ethernet interface. c) The box provides a very simple DHCP service, and a simple WEB server, and uses the IP address of 192.168.1.1. d) A PC or workstation is connected directly to the box, and uses DHCP to obtain an IP address. A Web browser is opened, and any HTTP URL is redirected to the box, and the user is guided through screens to configure the initial configuration for the box. This includes: 1) the password for user admim 2) the IP configuration (such as IPv4 address, network mask, default router, etc) for the Ethernet interface 3) the ssh service is enabled, and a RSA key pair is configured for the ssh server 4) either a key pair and self-signed X.509 cert is generated, or certs in PKCS#12 format are loaded (the protected content of info in PKCS#12 format would contain a CA-CERT, the box's keypair, and the box's X.509 cert). 5) the box would be rebooted, and direct connect of the PC (or workstation) would be removed. e) a CLI script is run from a configuration system over an ssh connection to set up: 1) any additional local accounts 2) the ip address and shared key for each radius server that is to be used 3) any policy rules about where management can take place, such as "local accounts" can be used only over the serial and management interface 4) the rest of the configuration is done so that the device can perform it's role in the network On going a) As new operators are added, new accounts are added to the Radius server(s) b) When an operator's password is changed, it is changed at the Radius server(s) c) When an operator's account is disabled (say, due to, say, time of day, day or week, vacation/holiday), the account is disabled at the Radius server d) When an operator's account is closed, it is closed at the radius server NOTE: system 1 and 2 differ primarily by one having a serial interface and the other not having one. This causes initial deployment (and reset to "factory settings") to be done slightly differently. Now, with SNMPv3/USM, extra work must be done and/or specialized run for initial deployment and ongoing operations. The Goal of ISMS is to develop is security model so that nothing extra is done. All that is needed is to simply configure the SNMP agent to support SNMPv3/ISMS. That is nothing is done to set up SNMP users, change SNMP user keys, or to disable SNMP users. One final note.... To use SNMPv3/ISMS, the information that is needed is ONLY the IP address of the system to be managed, a user identity, proof of the user identity, and verifier or the identity of the managed system. An examples of this last part include the SSH fingerprint, or the CA cert of the managed system's cert. There SHOULD NEVER be a requirement that there be an IP address and/or key for a Radius server. They are not needed now for management via SSH or via a WEB browser. Hope this helps. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 17:06:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13322; Mon, 28 Feb 2005 17:06:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5t2p-00022S-6x; Mon, 28 Feb 2005 17:07:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5t1p-0002qc-JN; Mon, 28 Feb 2005 17:06:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5t1o-0002qT-13 for isms@megatron.ietf.org; Mon, 28 Feb 2005 17:06:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13271 for ; Mon, 28 Feb 2005 17:06:09 -0500 (EST) Received: from gtfw2.enterasys.com ([12.25.1.128] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5t2I-00021Y-7V for isms@ietf.org; Mon, 28 Feb 2005 17:07:03 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j1SM5mZC012006 for ; Mon, 28 Feb 2005 17:05:48 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 28 Feb 2005 17:05:49 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 28 Feb 2005 17:05:49 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 17:05:49 -0500 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 Operational Scenario/Goal Date: Mon, 28 Feb 2005 17:05:48 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914A@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS Operational Scenario/Goal Thread-Index: AcUd3rRS9rBYRoVDRPOi9eOhzC1CXQAAgP6Q From: "Nelson, David" To: X-OriginalArrivalTime: 28 Feb 2005 22:05:49.0046 (UTC) FILETIME=[A9052160:01C51DE1] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:81.6251 M:99.2571 P:95.9108 R:95.9108 S:57.8780 ) 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable David Perkins writes... > One final note.... > To use SNMPv3/ISMS, the information that is needed is > ONLY the IP address of the system to be managed, a user > identity, proof of the user identity, and verifier or > the identity of the managed system. An examples of this > last part include the SSH fingerprint, or the CA cert > of the managed system's cert. There SHOULD NEVER be > a requirement that there be an IP address and/or key > for a Radius server. They are not needed now for management > via SSH or via a WEB browser. I think this is an {unfortunate | undesirable | mistaken} requirement. I specifically object to the notion that "the SSH fingerprint, or the CA cert of the managed system's cert" are acceptable configuration prerequisites but "the IP address and/or key for a Radius server" are not acceptable. That distinction "cooks the books" in terms of eliminating potential solutions from consideration. If you want to use just about any commercially deployed AAA client-server system, then the AAA clients will need to share pre-configured credentials with the AAA server. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 17:18:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14132; Mon, 28 Feb 2005 17:18:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tEd-0002EH-ID; Mon, 28 Feb 2005 17:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tD6-0006gV-Ib; Mon, 28 Feb 2005 17:17:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tD5-0006gK-A5 for isms@megatron.ietf.org; Mon, 28 Feb 2005 17:17:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14067 for ; Mon, 28 Feb 2005 17:17:49 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tDu-0002Dd-Dz for isms@ietf.org; Mon, 28 Feb 2005 17:18:42 -0500 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 j1SMHVcJ029609; Mon, 28 Feb 2005 14:17:31 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1SMHbj6007844; Mon, 28 Feb 2005 14:17:37 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1SMHagF007837; Mon, 28 Feb 2005 14:17:37 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 28 Feb 2005 14:17:36 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] ISMS Operational Scenario/Goal In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914A@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: 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 HI, Show me now where management users need IP address and secret of Radius server to perform management. We are talking about reducing the operational costs, not increasing them! This is not some intellectual exercise to show how smart we are. It's to get SNMP in use at the lowest incremental operational (not capital) cost to operators (not to device vendors either). On Mon, 28 Feb 2005, Nelson, David wrote: > David Perkins writes... > > > One final note.... > > To use SNMPv3/ISMS, the information that is needed is > > ONLY the IP address of the system to be managed, a user > > identity, proof of the user identity, and verifier or > > the identity of the managed system. An examples of this > > last part include the SSH fingerprint, or the CA cert > > of the managed system's cert. There SHOULD NEVER be > > a requirement that there be an IP address and/or key > > for a Radius server. They are not needed now for management > > via SSH or via a WEB browser. > > I think this is an {unfortunate | undesirable | mistaken} requirement. > I specifically object to the notion that "the SSH fingerprint, or the CA > cert of the managed system's cert" are acceptable configuration > prerequisites but "the IP address and/or key for a Radius server" are > not acceptable. That distinction "cooks the books" in terms of > eliminating potential solutions from consideration. If you want to use > just about any commercially deployed AAA client-server system, then the > AAA clients will need to share pre-configured credentials with the AAA > server. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 17:40:21 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15871; Mon, 28 Feb 2005 17:40:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tZj-0002h9-7z; Mon, 28 Feb 2005 17:41:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tYR-0003K9-Pk; Mon, 28 Feb 2005 17:39:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tYP-0003K4-Hu for isms@megatron.ietf.org; Mon, 28 Feb 2005 17:39:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15836 for ; Mon, 28 Feb 2005 17:39:51 -0500 (EST) Received: from ctron-dnm.enterasys.com ([12.25.1.120] ident=firewall-user) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tZC-0002gu-2D for isms@ietf.org; Mon, 28 Feb 2005 17:40:45 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA28380 for ; Mon, 28 Feb 2005 17:40:12 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma028366; Mon, 28 Feb 05 17:39:37 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 28 Feb 2005 17:39:11 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 28 Feb 2005 17:39:11 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 17:39:11 -0500 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 Operational Scenario/Goal Date: Mon, 28 Feb 2005 17:39:10 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914B@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS Operational Scenario/Goal Thread-Index: AcUd40/3cpAKVFQAQZKwkHjSur87aQAAh69Q From: "Nelson, David" To: "David T. Perkins" X-OriginalArrivalTime: 28 Feb 2005 22:39:11.0358 (UTC) FILETIME=[527DB1E0:01C51DE6] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:51.8443 M:98.8113 P:95.9108 R:95.9108 S:46.7996 ) 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: de4f315c9369b71d7dd5909b42224370 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Dave Perkins writes... > Show me now where management users need IP address and > secret of Radius server to perform management. If you simply want to allow remote management of devices that provides for data confidentiality of the management "session", without providing the "single sign-on" infrastructure of an Authentication, Authorization, and Accounting (AAA) system, then you're correct -- no client-server relationship is required. I think you miss the point about minimizing OpEx costs, however. Failing to utilize the existing AAA infrastructure, and instead relying on disjoint authentication mechanisms, is exactly the "cost" we are attempting to avoid, IMHO.=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 17:59:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17748; Mon, 28 Feb 2005 17:59:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5tsA-0003FG-Ui; Mon, 28 Feb 2005 18:00:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tqb-0007kq-7Y; Mon, 28 Feb 2005 17:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5tqZ-0007kh-3E for isms@megatron.ietf.org; Mon, 28 Feb 2005 17:58:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17705 for ; Mon, 28 Feb 2005 17:58:36 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5trN-0003E2-9w for isms@ietf.org; Mon, 28 Feb 2005 17:59:30 -0500 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 j1SMwLcJ012942; Mon, 28 Feb 2005 14:58:21 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1SMwRUq017668; Mon, 28 Feb 2005 14:58:27 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1SMwRD6017663; Mon, 28 Feb 2005 14:58:27 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 28 Feb 2005 14:58:27 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] ISMS Operational Scenario/Goal In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914B@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: 4adaf050708fb13be3316a9eee889caa 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c HI, You are just not following. Let me give an example. When using SSH, the user of SSH does not know anything about Radius servers. The user doesn't know how authentication is done. It's magic. All the user knows is the IP address of the system to connect to, the user's ID, the user's password, and the fingerprint of the SSH server on the system. Now, if the operator that set up the system want AAA, they set it up by configuring the managed system to use Radius authentication, accounting, and authorization. Again, the user does not know what is going on "behind the curtain". What is needed with a new SNMP security model is something that requires no new work, nor new information to be held by users to run SNMP management applications. And it uses what ever existing security infrastructure. That is what I'm saying. Use existing infrastructure. Use existing information. On Mon, 28 Feb 2005, Nelson, David wrote: > Dave Perkins writes... > > > Show me now where management users need IP address and > > secret of Radius server to perform management. > > If you simply want to allow remote management of devices that provides > for data confidentiality of the management "session", without providing > the "single sign-on" infrastructure of an Authentication, Authorization, > and Accounting (AAA) system, then you're correct -- no client-server > relationship is required. > > I think you miss the point about minimizing OpEx costs, however. > Failing to utilize the existing AAA infrastructure, and instead relying > on disjoint authentication mechanisms, is exactly the "cost" we are > attempting to avoid, IMHO. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 18:17:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19812; Mon, 28 Feb 2005 18:17:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5u9Z-0003XZ-SX; Mon, 28 Feb 2005 18:18:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5u7E-0001mk-2F; Mon, 28 Feb 2005 18:15:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5u7B-0001mc-VO for isms@megatron.ietf.org; Mon, 28 Feb 2005 18:15:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19648 for ; Mon, 28 Feb 2005 18:15:47 -0500 (EST) Message-Id: <200502282315.SAA19648@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5u81-0003WC-J2 for isms@ietf.org; Mon, 28 Feb 2005 18:16:41 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2005022823154001600shssge>; Mon, 28 Feb 2005 23:15:40 +0000 From: "David B Harrington" To: "'David T. Perkins'" , "'Nelson, David'" Subject: RE: [Isms] ISMS Operational Scenario/Goal Date: Mon, 28 Feb 2005 18:15:37 -0500 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: AcUd6ScRcPlU0CliSMCiOQBrsx43CQAASsyg In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Hi, David P, Isn't the operator that sets up the system also a management user? How does he use management with AAA centralized user authentication without having to know the IP address and AAA credentials to set up the system? I don't think anybody is arguing that each management user must provide the IP address and secret in their requests; that is done once by the operator who sets up the system. Or is there specific text in one of the proposals or in the documentation for a specific AAA protocol that you are thinking about? If that is the case, can you point us to the text so we can all be on the same page? David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins > Sent: Monday, February 28, 2005 5:58 PM > To: Nelson, David > Cc: isms@ietf.org > Subject: RE: [Isms] ISMS Operational Scenario/Goal > > HI, > > You are just not following. Let me give an example. > > When using SSH, the user of SSH does not know anything > about Radius servers. The user doesn't know how authentication > is done. It's magic. All the user knows is the IP address > of the system to connect to, the user's ID, the user's > password, and the fingerprint of the SSH server on the > system. Now, if the operator that set up the system > want AAA, they set it up by configuring the managed > system to use Radius authentication, accounting, > and authorization. Again, the user does not know > what is going on "behind the curtain". > > What is needed with a new SNMP security model is > something that requires no new work, nor new > information to be held by users to run SNMP > management applications. And it uses what ever > existing security infrastructure. That is what > I'm saying. Use existing infrastructure. Use > existing information. > > > On Mon, 28 Feb 2005, Nelson, David wrote: > > > Dave Perkins writes... > > > > > Show me now where management users need IP address and > > > secret of Radius server to perform management. > > > > If you simply want to allow remote management of devices > that provides > > for data confidentiality of the management "session", > without providing > > the "single sign-on" infrastructure of an Authentication, > Authorization, > > and Accounting (AAA) system, then you're correct -- no client-server > > relationship is required. > > > > I think you miss the point about minimizing OpEx costs, however. > > Failing to utilize the existing AAA infrastructure, and > instead relying > > on disjoint authentication mechanisms, is exactly the "cost" we are > > attempting to avoid, IMHO. > > > > 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@ietf.org Mon Feb 28 18:35:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21498; Mon, 28 Feb 2005 18:35:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uR4-0003tv-KC; Mon, 28 Feb 2005 18:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uPY-0004qh-Cw; Mon, 28 Feb 2005 18:34:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uPX-0004qZ-2r for isms@megatron.ietf.org; Mon, 28 Feb 2005 18:34:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21432 for ; Mon, 28 Feb 2005 18:34:44 -0500 (EST) 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.33) id 1D5uQN-0003sM-0q for isms@ietf.org; Mon, 28 Feb 2005 18:35:39 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2005 15:47:05 -0800 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 j1SNYXq8021120; Mon, 28 Feb 2005 15:34:33 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] draft agenda for Minneapolis Date: Mon, 28 Feb 2005 15:37:33 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6904C5B26B@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] draft agenda for Minneapolis Thread-Index: AcUdszCX2hrDDaCjSOWF3wI7JUaE/gACqHlwAAvJiiA= From: "Salowey, Joe" To: "Ken Hornstein" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Salowey, Joe=20 > Sent: Monday, February 28, 2005 10:04 AM > To: Ken Hornstein; isms@ietf.org > Subject: RE: [Isms] draft agenda for Minneapolis=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > > Sent: Monday, February 28, 2005 8:23 AM > > To: isms@ietf.org > > Subject: Re: [Isms] draft agenda for Minneapolis > >=20 > > >EUSM will use the EAP-TLS protocol defined in RFC2716 as the > > EAP method > > >to support authentication systems such as Kerberos, > > >X.509 and local accounts. > >=20 > > (WG chair hat off) > >=20 > > Upon reading RFC2716, I've discovered that it only mentions=20 > Kerberos=20 > > (and Public Key) once. Specifically, it says: > >=20 > > Through the use of EAP, support for a number of=20 > authentication schemes=20 > > may be added, including smart cards, Kerberos, Public Key, One Time=20 > > Passwords, and others. To date however, EAP methods such as=20 > [6] have=20 > > focussed on authenticating a client to a server. > >=20 > > It doesn't really mention how this will happen. If you look at the=20 > > EAP document (RFC3748), it doesn't explain how you could=20 > use Kerberos=20 > > or PKI with EAP either (I looked at PEAP, but that seems to=20 > focus only=20 > > on protecting the EAP exchange, rather than doing certificate=20 > > validation as part of the EAP authentication). > >=20 > > Maybe I'm missing something, but it seems like there's a bit of=20 > > handwaving here. > >=20 >=20 > [Joe] It is true that EAP (RFC 3748) does not specify=20 > authentication methods, it specifies a way to carry out an=20 > authentication exchange. It is also true that there are few=20 > EAP Methods that are currently defined as RFCs. However, RFC=20 > 2716 specifies EAP-TLS which uses TLS ciphersuites for=20 > authentication. TLS ciphersuites provide mutual=20 > authentication of peers using various types of credentials. =20 > The EAP-TLS specification is no worse than the TLS=20 > specification a specifying how PKI can be used in any=20 > particular environment, but I agree that there needs to be=20 > some additional specification around how certificates and PKI=20 > can be used with respect to SNMPv3, but my feeling is that=20 > TLS ciphersuites give us as good a good basic mechanism for=20 > PKI support. > All of the EAP-TLS implementations I know support X.509=20 > public key certificates for mutual authentication. =20 >=20 > RFC 2712 describes Kerberos ciphersuites for TLS. I agree=20 > that here as well additional specification around how=20 > Kerberos is used specific to SNMP is needed (for example what=20 > principal name is used), but I also feel that this provides a=20 > good base. Perhaps there are better ways to implement a=20 > Kerberos EAP mechanism, the Kitten working group is making=20 > enhancements to GSSAPI which could make a GSSAPI EAP=20 > mechanism easier to implement. This is something the working=20 > group can discuss. >=20 > In any case I think it would be advantageous to use an=20 > existing authentication frameworks (such as EAP and TLS)=20 > where possible and if required extend these frameworks with=20 > new methods that could be used with other solutions.=20 [Joe] I just wanted to clarify what I meant by "TLS framework" since I received some offline questions on it. TLS provides a framework for authenticated key exchange which can be extended to support different credential types by defining different ciphersuites. I was not referring to the use of TLS for anything other than authenticated key exchange, this is consistent with the current usage of EAP-TLS.=20 >The=20 > requirements for SNMP should not be radically different than=20 > other uses for EAP so it is the intent that enhancements made=20 > for SNMP should be applicable to the mainstream of EAP development. >=20 >=20 > Joe >=20 >=20 >=20 > > --Ken > >=20 > > _______________________________________________ > > Isms mailing list > > Isms@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/isms > >=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@ietf.org Mon Feb 28 18:47:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22423; Mon, 28 Feb 2005 18:47:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5ucd-00048c-9Y; Mon, 28 Feb 2005 18:48:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uXL-0006De-Ch; Mon, 28 Feb 2005 18:42:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uXJ-0006DZ-RK for isms@megatron.ietf.org; Mon, 28 Feb 2005 18:42:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22092 for ; Mon, 28 Feb 2005 18:42:47 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uY9-00042y-QQ for isms@ietf.org; Mon, 28 Feb 2005 18:43:42 -0500 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 j1SNgXcJ025918; Mon, 28 Feb 2005 15:42:33 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j1SNgdpI030348; Mon, 28 Feb 2005 15:42:39 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j1SNgc73030344; Mon, 28 Feb 2005 15:42:39 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 28 Feb 2005 15:42:38 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: RE: [Isms] ISMS Operational Scenario/Goal In-Reply-To: <200502282315.j1SNFee8018448@mx1.bayarea.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 HI, Picture..... A B C mgr system managed system system containing Radius server ---------- -------------- ------------------------------- | | | | | | ---------- -------------- ------------------------------- Has address Doesn't have Has shared secret for IP addr C of B identity Joe Knows identity Joe Uses identity Has IP address Knows pw for Joe "Joe" of C Has pw for Has shared secret "Joe" with C for Radius Doesn't operations know anything Has RSA key pair about C for SSH or Has finger X.509 Cert print of B's RSA public key or CA cert for B's cert This is what exists for SSH and/or secure Web browser access by operator Joe from any computer A. Operator Alice may have set up systems B and C. Operator Joe does not know how authentication occurs. It's magic to him. There is NO NEED or DESIRE to set up on system A information about the Radius server on system C. On Mon, 28 Feb 2005, David B Harrington wrote: > Hi, David P, > > Isn't the operator that sets up the system also a management user? How > does he use management with AAA centralized user authentication > without having to know the IP address and AAA credentials to set up > the system? > > I don't think anybody is arguing that each management user must > provide the IP address and secret in their requests; that is done once > by the operator who sets up the system. Or is there specific text in > one of the proposals or in the documentation for a specific AAA > protocol that you are thinking about? If that is the case, can you > point us to the text so we can all be on the same page? > > David Harrington > dbharrington@comcast.net > > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins > > Sent: Monday, February 28, 2005 5:58 PM > > To: Nelson, David > > Cc: isms@ietf.org > > Subject: RE: [Isms] ISMS Operational Scenario/Goal > > > > HI, > > > > You are just not following. Let me give an example. > > > > When using SSH, the user of SSH does not know anything > > about Radius servers. The user doesn't know how authentication > > is done. It's magic. All the user knows is the IP address > > of the system to connect to, the user's ID, the user's > > password, and the fingerprint of the SSH server on the > > system. Now, if the operator that set up the system > > want AAA, they set it up by configuring the managed > > system to use Radius authentication, accounting, > > and authorization. Again, the user does not know > > what is going on "behind the curtain". > > > > What is needed with a new SNMP security model is > > something that requires no new work, nor new > > information to be held by users to run SNMP > > management applications. And it uses what ever > > existing security infrastructure. That is what > > I'm saying. Use existing infrastructure. Use > > existing information. > > > > > > On Mon, 28 Feb 2005, Nelson, David wrote: > > > > > Dave Perkins writes... > > > > > > > Show me now where management users need IP address and > > > > secret of Radius server to perform management. > > > > > > If you simply want to allow remote management of devices > > that provides > > > for data confidentiality of the management "session", > > without providing > > > the "single sign-on" infrastructure of an Authentication, > > Authorization, > > > and Accounting (AAA) system, then you're correct -- no > client-server > > > relationship is required. > > > > > > I think you miss the point about minimizing OpEx costs, however. > > > Failing to utilize the existing AAA infrastructure, and > > instead relying > > > on disjoint authentication mechanisms, is exactly the "cost" we > are > > > attempting to avoid, IMHO. > > > > > > > Regards, > > /david t. perkins > > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 20:00:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28517; Mon, 28 Feb 2005 20:00:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vku-0005Zg-Jj; Mon, 28 Feb 2005 20:00:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5viX-0001T4-Jm; Mon, 28 Feb 2005 19:58:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5viV-0001Sz-Hx for isms@megatron.ietf.org; Mon, 28 Feb 2005 19:58:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28417 for ; Mon, 28 Feb 2005 19:58:24 -0500 (EST) Message-Id: <200503010058.TAA28417@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vjM-0005Xu-8v for isms@ietf.org; Mon, 28 Feb 2005 19:59:20 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2005030100581701600sjs1ne>; Tue, 1 Mar 2005 00:58:17 +0000 From: "David B Harrington" To: "'David T. Perkins'" Subject: RE: [Isms] ISMS Operational Scenario/Goal Date: Mon, 28 Feb 2005 19:58:10 -0500 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: AcUd7yxymc+NvTkyTea2cq0HjKWVJgAB0u3w In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: 7bit Hi DP, Your text description of the scenario definitely was not clear. Thanks for the picture. I think one thing is missing in your scenario. Typically RADIUS uses a challenge and response protocol for user authentication. It is a typical requirement at A for Joe to be present to provide the current pw for Joe in response to a RADIUS challenge. For automated every-5-minute-polling purposes, it would be rather undesirable for the user to have to respond to a challenge for every poll. Allowing the SNMP application to act as a RADIUS client to proxy for Joe can mitigate that requirement. If you were to use automated scripts to establish the SSH sessions for Joe, either Joe would need to run them and respond to the challenge, or a lookup must be done to get Joe's credentials using, say, a "Windows integrated security" single sign-on approach, or Joe's password would need to be hardcoded into the script. If the scripts need to know the password, then that solution suffers the same "extra" work you refer to, and you have a credentials distribution and update problem. There may be other ways to work around this problem, but the "requirement" of user presence at A should be recognized in your scenarios for SSH and web-based management interfaces. We want to avoid that requirement for SNMP. David Harrington dbharrington@comcast.net > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Monday, February 28, 2005 6:43 PM > To: David B Harrington > Cc: 'Nelson, David'; isms@ietf.org > Subject: RE: [Isms] ISMS Operational Scenario/Goal > > HI, > > Picture..... > > A B C > mgr system managed system system containing Radius server > ---------- -------------- ------------------------------- > | | | | | > | > ---------- -------------- ------------------------------- > Has address Doesn't have Has shared secret for IP addr C > of B identity Joe Knows identity Joe > Uses identity Has IP address Knows pw for Joe > "Joe" of C > Has pw for Has shared secret > "Joe" with C for Radius > Doesn't operations > know anything Has RSA key pair > about C for SSH or > Has finger X.509 Cert > print of B's > RSA public > key or > CA cert for > B's cert > > This is what exists for SSH and/or secure Web browser access > by operator Joe from any computer A. > > Operator Alice may have set up systems B and C. Operator Joe > does not know how authentication occurs. It's magic to him. > > There is NO NEED or DESIRE to set up on system A information > about the Radius server on system C. > > > On Mon, 28 Feb 2005, David B Harrington wrote: > > Hi, David P, > > > > Isn't the operator that sets up the system also a > management user? How > > does he use management with AAA centralized user authentication > > without having to know the IP address and AAA credentials to set up > > the system? > > > > I don't think anybody is arguing that each management user must > > provide the IP address and secret in their requests; that > is done once > > by the operator who sets up the system. Or is there specific text in > > one of the proposals or in the documentation for a specific AAA > > protocol that you are thinking about? If that is the case, can you > > point us to the text so we can all be on the same page? > > > > David Harrington > > dbharrington@comcast.net > > > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of David T. Perkins > > > Sent: Monday, February 28, 2005 5:58 PM > > > To: Nelson, David > > > Cc: isms@ietf.org > > > Subject: RE: [Isms] ISMS Operational Scenario/Goal > > > > > > HI, > > > > > > You are just not following. Let me give an example. > > > > > > When using SSH, the user of SSH does not know anything > > > about Radius servers. The user doesn't know how authentication > > > is done. It's magic. All the user knows is the IP address > > > of the system to connect to, the user's ID, the user's > > > password, and the fingerprint of the SSH server on the > > > system. Now, if the operator that set up the system > > > want AAA, they set it up by configuring the managed > > > system to use Radius authentication, accounting, > > > and authorization. Again, the user does not know > > > what is going on "behind the curtain". > > > > > > What is needed with a new SNMP security model is > > > something that requires no new work, nor new > > > information to be held by users to run SNMP > > > management applications. And it uses what ever > > > existing security infrastructure. That is what > > > I'm saying. Use existing infrastructure. Use > > > existing information. > > > > > > > > > On Mon, 28 Feb 2005, Nelson, David wrote: > > > > > > > Dave Perkins writes... > > > > > > > > > Show me now where management users need IP address and > > > > > secret of Radius server to perform management. > > > > > > > > If you simply want to allow remote management of devices > > > that provides > > > > for data confidentiality of the management "session", > > > without providing > > > > the "single sign-on" infrastructure of an Authentication, > > > Authorization, > > > > and Accounting (AAA) system, then you're correct -- no > > client-server > > > > relationship is required. > > > > > > > > I think you miss the point about minimizing OpEx costs, however. > > > > Failing to utilize the existing AAA infrastructure, and > > > instead relying > > > > on disjoint authentication mechanisms, is exactly the "cost" we > > are > > > > attempting to avoid, IMHO. > > > > > > > > > > Regards, > > > /david t. perkins > > > > > Regards, > /david t. perkins > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 20:47:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02014; Mon, 28 Feb 2005 20:47:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wUj-0006Pc-2S; Mon, 28 Feb 2005 20:48:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wTR-0008LJ-PW; Mon, 28 Feb 2005 20:46:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wTQ-0008LE-7M for isms@megatron.ietf.org; Mon, 28 Feb 2005 20:46:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01973 for ; Mon, 28 Feb 2005 20:46:54 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wUG-0006Om-5U for isms@ietf.org; Mon, 28 Feb 2005 20:47:49 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D5wTL-0001fz-Aw; Mon, 28 Feb 2005 20:46:51 -0500 Date: Mon, 28 Feb 2005 20:47:24 -0500 From: Robert Story To: ietfdbh@comcast.net Subject: Re: [Isms] ISMS Operational Scenario/Goal Message-ID: <20050228204724.53b90fb5@aud> In-Reply-To: <200503010058.TAA28417@ietf.org> References: <200503010058.TAA28417@ietf.org> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-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: 79899194edc4f33a41f49410777972f8 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit On Mon, 28 Feb 2005 19:58:10 -0500 David wrote: DBH> There may be other ways to work around this problem, but the DBH> "requirement" of user presence at A should be recognized in your DBH> scenarios for SSH and web-based management interfaces. We want to DBH> avoid that requirement for SNMP. SSH allows for password-less authentication. I use it all the time for remote backups. Joe's configuration would simply have to be set up to accept the private key he is using on A. You also seem to imply that SNMP doesn't require user presence. I don't see how SNMP is any different from ssh. If I want to periodically poll a device, the credentials have to be configured somewhere, or the user has to be present to provide the information. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Feb 28 21:05:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03153; Mon, 28 Feb 2005 21:05:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wmS-0006j0-Fv; Mon, 28 Feb 2005 21:06:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wkK-0001tC-Vj; Mon, 28 Feb 2005 21:04:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5wkJ-0001t2-Dt for isms@megatron.ietf.org; Mon, 28 Feb 2005 21:04:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03045 for ; Mon, 28 Feb 2005 21:04:21 -0500 (EST) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5wl8-0006hC-EQ for isms@ietf.org; Mon, 28 Feb 2005 21:05:16 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 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 j2124BH4004585 for ; Tue, 1 Mar 2005 02:04:11 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 j2124BS5016155 for ; Tue, 1 Mar 2005 02:04:11 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 M2005022818041020251 for ; Mon, 28 Feb 2005 18:04:10 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 18:04:10 -0800 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 18:04:10 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 28 Feb 2005 21:04:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Mon, 28 Feb 2005 21:03:45 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C21A3F@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 01 Mar 2005 02:04:08.0825 (UTC) FILETIME=[F45A3E90:01C51E02] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: quoted-printable 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@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable > I certainly agree with you about the need for "session" but I do not > believe that "session" alone will meet all of our needs. Specifically, I > remain very concerned about weaknesses in the authentication system > being exploited by crackers.=20 What specific weaknesses in what part of authentication system? Rememeber that the traffic is protected by session-wide keys that are created when the session is established and are gone once the session is terminated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms