From mailman-bounces@ietf.org Sat Jan 1 05:23:30 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 FAA05915 for ; Sat, 1 Jan 2005 05:23:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ckgbj-0006Wv-4F for isms-archive@ietf.org; Sat, 01 Jan 2005 05:35:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ckg5T-0002Aw-Se for isms-archive@ietf.org; Sat, 01 Jan 2005 05:02:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: lists.ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: isms-archive@ietf.org X-No-Archive: yes Message-ID: Date: Sat, 01 Jan 2005 05:00:37 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your lists.ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@lists.ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@lists.ietf.org. Thanks! Passwords for isms-archive@ietf.org: List Password // URL ---- -------- isms@lists.ietf.org riufwi https://www1.ietf.org/mailman/options/isms/isms-archive%40ietf.org From isms-bounces@ietf.org Tue Jan 4 12:59: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 MAA02552; Tue, 4 Jan 2005 12:59:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CltA9-0002mb-LN; Tue, 04 Jan 2005 13:12:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clsqz-0000k8-1o; Tue, 04 Jan 2005 12:52:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Clsjx-0006dp-K2 for isms@megatron.ietf.org; Tue, 04 Jan 2005 12:45: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 MAA01260 for ; Tue, 4 Jan 2005 12:45:02 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ClswA-0002OW-74 for isms@ietf.org; Tue, 04 Jan 2005 12:57:55 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA22276; Tue, 4 Jan 2005 09:44:15 -0800 (PST) Received: from xch-nw-10p.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j04HiHF29722; Tue, 4 Jan 2005 09:44:17 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by xch-nw-10p.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 4 Jan 2005 09:44:17 -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 results? Date: Tue, 4 Jan 2005 09:44:16 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDAE9@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation results? Thread-Index: AcTukdCikezqFF85QNaP9VRxYB7L1gD8IFiQ From: "Fleischman, Eric" To: X-OriginalArrivalTime: 04 Jan 2005 17:44:17.0000 (UTC) FILETIME=[031CAE80:01C4F285] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: quoted-printable Thank you, Wes, for this posting.=20 I too am eager to see what the evaluation committee is currently thinking. Since I was unable to attend the last IETF, I do not know how this esteemed group is evaluating the alternatives. My previous email request asking for the requirements and rationales for their evaluation left me feeling concerned (i.e., there didn't appear to be a universally agreed set, which leaves open the possibility of much disagreement on their conclusions).=20 In fact, I was so concerned that I again posted my list of what I believe to be the security weaknesses of SNMPv3 that I believe the proposals should be evaluated against (i.e., these weaknesses are the reason I spent so much time arguing for the formation of this WG). From where I sit, this WG can only be a success if all of these weaknesses have been addressed.=20 The following is my list of SNMPv3 USM security problems that need to be fixed by this WG (listed in order of increasing importance): 1) No provisions supporting two-factored authentication. 2) SNMPv3's symmetric keys may be assembled from passwords (several SNMP implementations require that they must be so assembled due to symmetric key distribution problems). Such keys are no more secure than the passwords they are derived from. 3) Key updates do not provide for Perfect Forward Security (PFS). 4) There is an inherent problem with SNMPv3's Symmetric Key distribution such that it is difficult to deploy multi-vendor SNMPv3 systems in a manner that is not operationally insecure. (Yes, I do know about RFC 2786 but I note that it is an informational RFC that is not universally implemented.) 5) SNMPv3's session (i.e., privacy) keys are often default-deployed in (security) non-viable ways. 6) SNMPv3's symmetric keys are unique within a deployment (i.e., SNMP keys are unique to SNMP and are not integrated with any other IETF protocol). Similarly, SNMPv3 cannot use any existing authentication/authorization infrastructures already present in that deployment (e.g., Kerberos, PKI, RADIUS, etc.). --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 7 13:47: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 NAA04228; Fri, 7 Jan 2005 13:47:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmzMD-00065h-Oy; Fri, 07 Jan 2005 14:01:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cmz8D-00085G-8O; Fri, 07 Jan 2005 13: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 1Cmz3P-0006py-0G for isms@megatron.ietf.org; Fri, 07 Jan 2005 13:41:43 -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 NAA04065 for ; Fri, 7 Jan 2005 13:41:41 -0500 (EST) Message-Id: <200501071841.NAA04065@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CmzGQ-0005ut-Cx for isms@ietf.org; Fri, 07 Jan 2005 13:55:11 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005010718410901300stp7ce>; Fri, 7 Jan 2005 18:41:09 +0000 From: "David B Harrington" To: Date: Fri, 7 Jan 2005 13:41:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcTukLMOBq+Td8bJQ5Cl0BhPtUEFCwGTh/Kg X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Isms] Evaluation status 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hi, To the WG chairs and the evaluation team members: Can we get a status report on the evaluation effort? I'm not asking for status of the evaluation, but of the evaluation team's effort. Has the team met? How recently? Are all members still committed to doing the evaluation asap (although obviously not by WG-specified deadline)? Have all team members read the three proposals yet? Has the team established evaluation guidelines? Can we know what the evaluation guidelines are? Has the team started analyzing the three proposals against the guidelines yet? Has the team decided how they will report the results of the evaluation? Has the team started to document their results yet? Does the team have an estimated date for completion of their report? As already pointed out, we have a tight charter deadline, but all work is completely suspended while waiting for the results from the evaluation team. Is the evaluation team making any progress? Should we be looking for a new evaluation team? Thanks, David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 08:13:13 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 IAA16492; Mon, 10 Jan 2005 08:13:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnzZm-00006q-80; Mon, 10 Jan 2005 08:27:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnzH1-0000p3-W1; Mon, 10 Jan 2005 08:07:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CnzFk-0000K9-MH for isms@megatron.ietf.org; Mon, 10 Jan 2005 08:06: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 IAA16059 for ; Mon, 10 Jan 2005 08:06:35 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CnzTM-0008GO-Cy for isms@ietf.org; Mon, 10 Jan 2005 08:20:40 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 61E451BAC9F; Mon, 10 Jan 2005 14:05:59 +0100 (CET) Date: Mon, 10 Jan 2005 14:05:57 +0100 From: Juergen Quittek To: ietfdbh@comcast.net, isms@ietf.org Subject: Re: [Isms] Evaluation status Message-ID: <2147483647.1105365957@[10.1.1.171]> In-Reply-To: <200501071841.NAA04065@ietf.org> References: <200501071841.NAA04065@ietf.org> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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: 10ba05e7e8a9aa6adb025f426bef3a30 Content-Transfer-Encoding: 7bit Dear all, I wish you all a happy new year! Wes, Eric, and David, thank you for the call for more information. Indeed it was too quiet on this list over the holiday break and I can understand that many people want to know about the status of the evaluation process. I apologize for not clarifying things earlier. The most important news is that our shepherding AD granted a deadline extension until March for the WG decision on the solution to focus on. You will find this reflected on our charter web page. The evaluation team has met and discussed all proposals. The team will produce an Internet draft reflecting the discussion and giving a recommendation to the WG. There is already a version of this draft, but the essential section, the recommendation, is still to be done. One of the problems the team is facing is that the different proposals cover different aspects of the overall problem. I hope that the team will be able to sketch the recommendation in January and have the draft ready for the cut-off date on February 14. 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 07.01.2005 13:41 h -0500 David B Harrington wrote: > Hi, > > To the WG chairs and the evaluation team members: > > Can we get a status report on the evaluation effort? > I'm not asking for status of the evaluation, but of the evaluation > team's effort. > > Has the team met? > How recently? > Are all members still committed to doing the evaluation asap (although > obviously not by WG-specified deadline)? > Have all team members read the three proposals yet? > Has the team established evaluation guidelines? > Can we know what the evaluation guidelines are? > Has the team started analyzing the three proposals against the > guidelines yet? > Has the team decided how they will report the results of the > evaluation? > Has the team started to document their results yet? > Does the team have an estimated date for completion of their report? > > As already pointed out, we have a tight charter deadline, but all work > is completely suspended while waiting for the results from the > evaluation team. > Is the evaluation team making any progress? > Should we be looking for a new evaluation team? > > Thanks, > David Harrington > dbharrington@comcast.net > > > > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 11:38: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 LAA03422; Mon, 10 Jan 2005 11:38:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co2mw-0008AZ-H9; Mon, 10 Jan 2005 11:53:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2Rq-0005jL-3w; Mon, 10 Jan 2005 11:31:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co2I2-0003UM-LI for isms@megatron.ietf.org; Mon, 10 Jan 2005 11:21: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 LAA29435 for ; Mon, 10 Jan 2005 11:21:08 -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 1Co2Vd-0007Du-4r for isms@ietf.org; Mon, 10 Jan 2005 11:35:16 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id E8B3A11D825; Mon, 10 Jan 2005 08:20:58 -0800 (PST) From: Wes Hardaker To: Juergen Quittek Subject: Re: [Isms] Evaluation status Organization: Sparta References: <200501071841.NAA04065@ietf.org> <2147483647.1105365957@[10.1.1.171]> Date: Mon, 10 Jan 2005 08:20:56 -0800 In-Reply-To: <2147483647.1105365957@[10.1.1.171]> (Juergen Quittek's message of "Mon, 10 Jan 2005 14:05:57 +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: 79899194edc4f33a41f49410777972f8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 >>>>> On Mon, 10 Jan 2005 14:05:57 +0100, Juergen Quittek said: Juergen> The most important news is that our shepherding AD granted a Juergen> deadline extension until March for the WG decision on the Juergen> solution to focus on. You will find this reflected on our Juergen> charter web page. I actually don't find this a big change. The original November date was really just an early deadline that tried to emphasize the urgency of the one in march which was the real cut-off: decide something or shut down. By simply aligning the should-be-decided deadline with the must-be-decided deadline you haven't really changed anything. The end result is still the same: if you wait until Feb 14th to let the members of the group know what 4-6 people have decided, I have strong doubts that there is enough time between that point and the MUST-have-consensus deadline to handle the resulting discussions. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 12:27: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 MAA07214; Mon, 10 Jan 2005 12:27:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3YC-0001kz-80; Mon, 10 Jan 2005 12:41:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3HS-0001QB-T8; Mon, 10 Jan 2005 12:24:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3AW-0007Jx-Jf for isms@megatron.ietf.org; Mon, 10 Jan 2005 12:17: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 MAA06560 for ; Mon, 10 Jan 2005 12:17:25 -0500 (EST) Message-Id: <200501101717.MAA06560@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3O8-0001Pl-Ou for isms@ietf.org; Mon, 10 Jan 2005 12:31:35 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011017165401400ggihfe>; Mon, 10 Jan 2005 17:16:54 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Juergen Quittek'" Subject: RE: [Isms] Evaluation status Date: Mon, 10 Jan 2005 12:16:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT3MF++1DJ6ZYOKT6uZOIpptP1nvwAANYuw X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit I agree. I don't feel this is a significant change. The question posed was essentially, is the evaluation team making real progress? The answer "we have permission to push back an interim deadline" doesn't answer the question asked. I think the more important points are that: 1) The evaluation team has met and discussed all proposals. It is good to know that the team has been active, although this doesn't give us much info on how active. They met at IETF61. It would be nice if they and the chairs chose to share info, like how many times have they met and had useful discussions. We are looking for assurance that the team is seriously working on comparing and discussing the proposals, and that the recommendations they provide will be well-researched. They apparently have not conferred with the authors of the proposals for any clarifications yet, and that seriously concerns me. I do not feel comfortable that we will have meaningful comparisons completed before the March IETF meeting. Please comfort me. 2) The team will produce an Internet draft reflecting the discussion and giving a recommendation to the WG. OK. But do we get to know what they are using for evaluation guidelines, or do we have to wait until feb14 to find out how the evaluation is being done? If we don't even get to know what guidelines are being used before the final publication deadline for the March meeting, we certainly will not have time to do much if the WG disagrees with the guidelines. Eric proposed some guidelines to meet his security needs; Dave Perkins proposed some application guidelines; Wes published a table of attributes for various potential solutions. Are any or all of these proposed guidelines being taken into account in defining the team's guidelines? Are all team members using the same guidelines, or each using their own guidelines? I just want to know what the team's guidelines are so we are not blind-sided if the evaluation team doesn't consider the issues that the WG agrees need to be considered. The secrecy combined with the tight deadline is stressful; I'd like to know if there is something the rest of the WG or the authors of the proposals could be doing to make the evaluation process more effective/efficient. 3) There is already a version of this draft, but the essential section, the recommendation, is still to be done. Understood. Having an empty template for an internet-draft isn't very reassuring, however. Does the initial version indicate what factors are being considered in the analysis - e.g. an abstraction of the guidelines being used? 4) One of the problems the team is facing is that the different proposals cover different aspects of the overall problem. So is there anything we can do to help make it easier to complete the evaluation? Can I clarify anything in the TLS proposal, or provide additional specifications to address specfic aspects that are not currently covered in the proposal, or provide research services such as providing references to sections of other documents to help the team quickly compare the proposals? dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Monday, January 10, 2005 11:21 AM > To: Juergen Quittek > Cc: ietfdbh@comcast.net; isms@ietf.org > Subject: Re: [Isms] Evaluation status > > >>>>> On Mon, 10 Jan 2005 14:05:57 +0100, Juergen Quittek > said: > > Juergen> The most important news is that our shepherding AD granted a > Juergen> deadline extension until March for the WG decision on the > Juergen> solution to focus on. You will find this reflected on our > Juergen> charter web page. > > I actually don't find this a big change. The original November date > was really just an early deadline that tried to emphasize the urgency > of the one in march which was the real cut-off: decide something or > shut down. By simply aligning the should-be-decided deadline with the > must-be-decided deadline you haven't really changed anything. The end > result is still the same: if you wait until Feb 14th to let the > members of the group know what 4-6 people have decided, I have strong > doubts that there is enough time between that point and the > MUST-have-consensus deadline to handle the resulting discussions. > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 12:47: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 MAA08448; Mon, 10 Jan 2005 12:47:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3r8-0002KX-Ln; Mon, 10 Jan 2005 13:01:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3aD-0004CL-6C; Mon, 10 Jan 2005 12:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3YD-0003jn-DX for isms@megatron.ietf.org; Mon, 10 Jan 2005 12:41:58 -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 MAA08100 for ; Mon, 10 Jan 2005 12:41:54 -0500 (EST) Message-Id: <200501101741.MAA08100@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co3lq-00022w-On for isms@ietf.org; Mon, 10 Jan 2005 12:56:04 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011017412401400gga48e>; Mon, 10 Jan 2005 17:41:24 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Ken Hornstein'" , Subject: RE: [Isms] Evaluation process? Date: Mon, 10 Jan 2005 12:41:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <2147483647.1101832344@[10.1.1.171]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcTW81cabrO1JNw2RbKbqHD8pO39oQgR4P7g X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Juergen and Ken, > I think we are still fine if we have a recommendation from > the evaluation > team before Christmas. Do you still think we are fine? > This will be late but still in time > to agree or > disagree on the recommendation on the mailing list Do you still feel we will have adequate time to agree or disagree on the mailing list before the next meeting in March? > and, in > case of agreement, > to discuss a new charter before the next meeting in March. Do you still feel we will have adequate time to discuss a new charter before the next meeting in March? David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 13:12: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 NAA10533; Mon, 10 Jan 2005 13:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co4FJ-00039p-Px; Mon, 10 Jan 2005 13:26:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3yG-0008JC-59; Mon, 10 Jan 2005 13:08:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co3n2-0006Fi-Kq for isms@megatron.ietf.org; Mon, 10 Jan 2005 12:57: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 MAA09308 for ; Mon, 10 Jan 2005 12:57:13 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co40f-0002ay-Sh for isms@ietf.org; Mon, 10 Jan 2005 13:11:23 -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 JAA28100; Mon, 10 Jan 2005 09:56:29 -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 j0AHuTP26661; Mon, 10 Jan 2005 09:56:29 -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.0); Mon, 10 Jan 2005 09:56:25 -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 Date: Mon, 10 Jan 2005 09:56:24 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDB0C@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation status Thread-Index: AcT3MF++1DJ6ZYOKT6uZOIpptP1nvwAANYuwAAJn8sA= From: "Fleischman, Eric" To: , "Wes Hardaker" , "Juergen Quittek" X-OriginalArrivalTime: 10 Jan 2005 17:56:25.0235 (UTC) FILETIME=[B3A70630:01C4F73D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable From: David B Harrington [mailto:ietfdbh@comcast.net] wrote: >4) One of the problems the team is facing is that the=20 > different proposals cover different aspects of the overall problem. >So is there anything we can do to help make it easier to=20 >complete the evaluation? Can I clarify anything in the=20 >TLS proposal, or provide additional specifications to address=20 >specfic aspects that are not currently covered in the proposal,=20 >or provide research services such as providing references to=20 >sections of other documents to help the team quickly compare=20 >the proposals? I value David's and Wes' (and doubtlessly the other authors as well) desire to assist the evaluators, if possible. Thank you! However, my concern remains that I am uncertain what evaluation criteria and requirements the evaluators are using. There are indeed multiple aspects to the overall problem. However, my satisfaction with the evaluation conclusions will be a function of how they addressed the prioritized list requirements that I have repeatedly enumerated to the IETF over the past 18 months or so. I can't imagine being a happy camper if the requirements that I believe to be the highest priority are disregarded altogether at the expense of issues that I either don't value or else believe to be of low importance. I am very willing to justify my prioritized list. However, such discussions should have occurred before the evaluation, rather than not occurring at all. Here is my prioritized list (listed in order of increasing importance): 1) No provisions supporting two-factored authentication. 2) SNMPv3's symmetric keys may be assembled from passwords (several SNMP implementations require that they must be so assembled due to symmetric key distribution problems). Such keys are no more secure than the passwords they are derived from. 3) Key updates do not provide for Perfect Forward Security (PFS). 4) There is an inherent problem with SNMPv3's Symmetric Key distribution such that it is difficult to deploy multi-vendor SNMPv3 systems in a manner that is not operationally insecure. (Yes, I do know about RFC 2786 but I note that it is an informational RFC that is not universally implemented.) 5) SNMPv3's session (i.e., privacy) keys are often default-deployed in (security) non-viable ways. 6) SNMPv3's symmetric keys are unique within a deployment (i.e., SNMP keys are unique to SNMP and are not integrated with any other IETF protocol). Similarly, SNMPv3 cannot use any existing authentication/authorization infrastructures already present in that deployment (e.g., Kerberos, PKI, RADIUS, etc.). --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 17:09: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 RAA07789; Mon, 10 Jan 2005 17:09:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co7wY-00047g-CG; Mon, 10 Jan 2005 17:23:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co7bK-0003KM-OS; Mon, 10 Jan 2005 17:01:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co7Ws-00027X-TJ for isms@megatron.ietf.org; Mon, 10 Jan 2005 16:56: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 QAA06653 for ; Mon, 10 Jan 2005 16:56:48 -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 1Co7kW-0003me-LP for isms@ietf.org; Mon, 10 Jan 2005 17:10:59 -0500 Received: from h-69-3-26-208.snvacaid.dynamic.covad.net ([69.3.26.208] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Co7Wn-0007eF-00 for isms@ietf.org; Mon, 10 Jan 2005 13:56:46 -0800 Message-ID: <00bf01c4f75f$64032ce0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <5B58696DB20B9140AD20E0685C573A6404FDDB0C@xch-nw-09.nw.nos.boeing.com> Subject: Re: [Isms] Evaluation status Date: Mon, 10 Jan 2005 13:57:34 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 769a46790fb42fbb0b0cc700c82f7081 Hi - Would the authors of the proposals on the table care to address Eric's list in terms of (a) how their proposal does(n't) meet each of his requirements, and (b) how much importance they'd attribute each of his requirements? Randy > From: "Fleischman, Eric" ... > Cc: > Sent: Monday, January 10, 2005 9:56 AM > Subject: RE: [Isms] Evaluation status ... > I am very willing to justify my prioritized list. However, such > discussions should have occurred before the evaluation, rather than not > occurring at all. > > Here is my prioritized list (listed in order of increasing importance): > > 1) No provisions supporting two-factored authentication. > 2) SNMPv3's symmetric keys may be assembled from passwords (several > SNMP implementations require that they must be so assembled due to > symmetric key distribution problems). Such keys are no more secure than > the passwords they are derived from. > 3) Key updates do not provide for Perfect Forward Security (PFS). > 4) There is an inherent problem with SNMPv3's Symmetric Key > distribution such that it is difficult to deploy multi-vendor SNMPv3 > systems in a manner that is not operationally insecure. (Yes, I do know > about RFC 2786 but I note that it is an informational RFC that is not > universally implemented.) > 5) SNMPv3's session (i.e., privacy) keys are often default-deployed > in (security) non-viable ways. > 6) SNMPv3's symmetric keys are unique within a deployment (i.e., > SNMP keys are unique to SNMP and are not integrated with any other IETF > protocol). Similarly, SNMPv3 cannot use any existing > authentication/authorization infrastructures already present in that > deployment (e.g., Kerberos, PKI, RADIUS, etc.). ... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 17:47: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 RAA10048; Mon, 10 Jan 2005 17:47:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8Xe-0004yx-SS; Mon, 10 Jan 2005 18:01:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8GT-0004HS-LJ; Mon, 10 Jan 2005 17:43:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co8DN-0003lN-8S for isms@megatron.ietf.org; Mon, 10 Jan 2005 17:40: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 RAA09681 for ; Mon, 10 Jan 2005 17:40:42 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Co8Qy-0004of-TM for isms@ietf.org; Mon, 10 Jan 2005 17:54:54 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id A696CD4E2; Mon, 10 Jan 2005 23:40:07 +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 07392-07; Mon, 10 Jan 2005 23:40:06 +0100 (CET) Received: from james (I97ad.i.pppool.de [85.73.151.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 41B07C465; Mon, 10 Jan 2005 23:40:06 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Co8Ci-0000k5-9g; Mon, 10 Jan 2005 23:40:04 +0100 Date: Mon, 10 Jan 2005 23:40:04 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Evaluation status Message-ID: <20050110224004.GB2739@james> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <5B58696DB20B9140AD20E0685C573A6404FDDB0C@xch-nw-09.nw.nos.boeing.com> <00bf01c4f75f$64032ce0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bf01c4f75f$64032ce0$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: cd26b070c2577ac175cd3a6d878c6248 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: b7b9551d71acde901886cc48bfc088a6 On Mon, Jan 10, 2005 at 01:57:34PM -0800, Randy Presuhn wrote: > Would the authors of the proposals on the table care to address > Eric's list in terms of (a) how their proposal does(n't) meet each of > his requirements, and (b) how much importance they'd attribute > each of his requirements? I can try (although I am not even sure we decided or lets say attempted to decide that Eric's requirements are the WGs requirements). > > 1) No provisions supporting two-factored authentication. The idea behind the transport layer security model was to provide a generic mechanism to bind a security service operating at the transport layer (as seen from an SNMP architecture perspective) into the SNMP architecture with the goal to make existing security protocols which provide two-factored authentication usable within SNMP. (I hope there is one. ;-) > > 2) SNMPv3's symmetric keys may be assembled from passwords (several > > SNMP implementations require that they must be so assembled due to > > symmetric key distribution problems). Such keys are no more secure than > > the passwords they are derived from. This is USM specific and perhaps even implementation specific. Should not be an issue with a transport layer security model. > > 3) Key updates do not provide for Perfect Forward Security (PFS). Boils down to the concrete security protocol one would use with the transport layer security model. > > 4) There is an inherent problem with SNMPv3's Symmetric Key > > distribution such that it is difficult to deploy multi-vendor SNMPv3 > > systems in a manner that is not operationally insecure. (Yes, I do know > > about RFC 2786 but I note that it is an informational RFC that is not > > universally implemented.) Key distribution is always difficult. While Kerberos works in some environments, there are others where Kerberos does not exist. Different environments use different things - the nice thing about the transport layer security model proposal is that once defined it should allow to interface to different things providing security below SNMP in a common way. > > 5) SNMPv3's session (i.e., privacy) keys are often default-deployed > > in (security) non-viable ways. Not sure what this is - probably a request for vendors and implementors not to ship default keys? If yes, no standard can't fix stupidity. > > 6) SNMPv3's symmetric keys are unique within a deployment (i.e., > > SNMP keys are unique to SNMP and are not integrated with any other IETF > > protocol). Similarly, SNMPv3 cannot use any existing > > authentication/authorization infrastructures already present in that > > deployment (e.g., Kerberos, PKI, RADIUS, etc.). This is what the transport layer security model was trying to address. Now, does this help? I guess not. The proposals on the table indeed focus on different aspects of the overall problem space. The best thing that could come out of the evaluation in my mind would be a description in which SNMP application areas or environments the different proposals help to solve the SNMPv3 deployment problems and how. There seem to be big differences how different organizations with different backgrounds and cultures address their security needs and the one solution fits all approach is probably not realistic. So the decision will likely be on which environment(s) to focus this work, taking very well into account that the solution might not be interesting for all of us since other solutions (not selected) might work better in other segments of the overall market space. /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 Mon Jan 10 19:32:05 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 TAA18037; Mon, 10 Jan 2005 19:32:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoAAr-00076b-QD; Mon, 10 Jan 2005 19:46:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9vy-0000mV-B5; Mon, 10 Jan 2005 19:30:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Co9ob-0007yI-IU for isms@megatron.ietf.org; Mon, 10 Jan 2005 19:23: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 TAA17477 for ; Mon, 10 Jan 2005 19:23:14 -0500 (EST) Received: from pop-a065d19.pas.sa.earthlink.net ([207.217.121.253]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoA2J-0006w4-HN for isms@ietf.org; Mon, 10 Jan 2005 19:37:27 -0500 Received: from h-69-3-26-208.snvacaid.dynamic.covad.net ([69.3.26.208] helo=oemcomputer) by pop-a065d19.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Co9oZ-0000l6-00 for isms@ietf.org; Mon, 10 Jan 2005 16:23:15 -0800 Message-ID: <001201c4f773$dba77120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <5B58696DB20B9140AD20E0685C573A6404FDDB0C@xch-nw-09.nw.nos.boeing.com> <00bf01c4f75f$64032ce0$7f1afea9@oemcomputer> <20050110224004.GB2739@james> Subject: Re: [Isms] Evaluation status Date: Mon, 10 Jan 2005 16:24:04 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: a7d6aff76b15f3f56fcb94490e1052e4 Hi - Thanks! I'd love to hear from the other authors as well. One minor comment follows below. > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Monday, January 10, 2005 2:40 PM > Subject: Re: [Isms] Evaluation status > > On Mon, Jan 10, 2005 at 01:57:34PM -0800, Randy Presuhn wrote: > > > Would the authors of the proposals on the table care to address > > Eric's list in terms of (a) how their proposal does(n't) meet each of > > his requirements, and (b) how much importance they'd attribute > > each of his requirements? > > I can try (although I am not even sure we decided or lets say attempted > to decide that Eric's requirements are the WGs requirements). ... That's why I was careful to phrase it as "Eric's list" and "his requirements". That's also why anything that looks like "requirements" in the design team's recommendations must not be given undue weight. There has been no proclamation of consensus on what the WG requirements might be, beyond what's dictated by the WG charter. At least Eric has been willing to state what he wants, though as I understand what he's asking for, none of the proposals before us will make him happy, and some of his requirements seem to me to be contradictory. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 22:53:00 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 WAA00551; Mon, 10 Jan 2005 22:53:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoDJK-0002VX-Jm; Mon, 10 Jan 2005 23:07:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoD4V-000804-On; Mon, 10 Jan 2005 22:51:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoD0l-0007Xg-P8 for isms@megatron.ietf.org; Mon, 10 Jan 2005 22: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 WAA00311 for ; Mon, 10 Jan 2005 22:48:01 -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 1CoDET-0002Pc-7L for isms@ietf.org; Mon, 10 Jan 2005 23:02:16 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id C2A0011D825; Mon, 10 Jan 2005 19:47:55 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" Subject: Re: [Isms] Evaluation status Organization: Sparta References: <5B58696DB20B9140AD20E0685C573A6404FDDB0C@xch-nw-09.nw.nos.boeing.com> <00bf01c4f75f$64032ce0$7f1afea9@oemcomputer> Date: Mon, 10 Jan 2005 19:47:55 -0800 In-Reply-To: <00bf01c4f75f$64032ce0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Mon, 10 Jan 2005 13:57:34 -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: a7d2e37451f7f22841e3b6f40c67db0f 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: 5ebbf074524e58e662bc8209a6235027 >>>>> On Mon, 10 Jan 2005 13:57:34 -0800, "Randy Presuhn" said: Randy> Would the authors of the proposals on the table care to address Randy> Eric's list in terms of (a) how their proposal does(n't) meet Randy> each of his requirements, and (b) how much importance they'd Randy> attribute each of his requirements? I think the matrix I've posted a number of times here covers most of the aspects in the list plus more. However, I'd be more than happy to respond to it directly. >> 1) No provisions supporting two-factored authentication. SBSM as is doesn't support this, but only because the draft hadn't documented a complete solution for that type of security mechanism. It actually was within my plans to make that support possible. >> 2) SNMPv3's symmetric keys may be assembled from passwords (several >> SNMP implementations require that they must be so assembled due to >> symmetric key distribution problems). Such keys are no more secure than >> the passwords they are derived from. I don't find this a realistic complaint. You need to purchase software from the people that support the modes you need to operate in. If your software doesn't offer support for direct input of randomly generated keys then don't buy it until they do. And, most importantly, tell them that. There seems to be an ever growing gap in communication between the people that sell software of any kind and the people that use it. That being said, all of the items in this list do not adequately describe one of the fundamental differences between USM and, actually, all of the proposals: the separation between identity authentication and message integrity authentication. All of the solutions use a independent key for message integrity authentication (SBSM included, since I should talk mostly about that), which makes them all better in this respect. As far as authenticating a user, SBSM can use multiple mechanisms for identifying a user in order to tie those message integrity keys to a user. Passwords are still possible if need be, as are better forms of user authentication. The SBSM draft is fairly silent on which forms of authentication should be put into the resulting WG draft since it was expected that the WG would likely be making the decision as to which authentication mechanisms should be used and which was the mandatory one (if one). >> 3) Key updates do not provide for Perfect Forward Security (PFS). Again, which keys? SBSM provides PFS for session keys. It does not provide a mechanism in the current draft to change the authentication keys since that is dependent on the authentication mechanism used, and it is not clear if the WG will or even should work on how to manage existing security infrastructures (we're just trying to make use of them first). >> 4) There is an inherent problem with SNMPv3's Symmetric Key >> distribution such that it is difficult to deploy multi-vendor SNMPv3 >> systems in a manner that is not operationally insecure. (Yes, I do know >> about RFC 2786 but I note that it is an informational RFC that is not >> universally implemented.) Again, if you require software that implements a known feature tell that to your vendor... However, SBSM allows for mechanisms other than symmetric keys to be used for authentication which solves Eric's problem. I'm assuming here he means for user authentication and not message integrity, since again he was unclear and they are not equal. (though SBSM generates session keys securely, so the answer will still be "supported"). >> 5) SNMPv3's session (i.e., privacy) keys are often default-deployed >> in (security) non-viable ways. I have no idea what this is trying to get at. Well, thats not true, I have about 100 ideas but I'm just not sure which one he means as the question is too vague. >> 6) SNMPv3's symmetric keys are unique within a deployment (i.e., >> SNMP keys are unique to SNMP and are not integrated with any other >> IETF protocol). Similarly, SNMPv3 cannot use any existing >> authentication/authorization infrastructures already present in >> that deployment (e.g., Kerberos, PKI, RADIUS, etc.). Well, since that's the fundamental root of the WG, I'm sure they're all going to claim this is solved ;-) SBSM certainly solves it. It's interesting that this is last on Eric's list when it's first on many other people's (it wouldn't be first or last on mine, but I haven't ranked them). I do find it interesting that the most common authentication mechanism, according to the poll I took near the start of the WG, showed that local accounts (read: passwords) were the most common form of authentication in use out there. Hence requirements #2 and #6 are somewhat in conflict. Note that if you only picked one form of authentication to support, even the most popular (being local accounts), you'd only make a fraction of the world happy. I'm convinced that the results of this WG will the most usable by the community at large if multiple potential authentication systems are considered. The question is what is the right number so that you don't end up with everyone implementing something different, and which should be mandatory to ensure at least minimal interoperability. That is a topic I'm hoping the WG will hit at some point post initial direction decision. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 10 23:56:00 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 XAA04203; Mon, 10 Jan 2005 23:56:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoEIG-0003k6-Lv; Tue, 11 Jan 2005 00:10:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoE0d-0001iT-I5; Mon, 10 Jan 2005 23:51:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoDym-0001Yz-9M for isms@megatron.ietf.org; Mon, 10 Jan 2005 23:50: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 XAA03994 for ; Mon, 10 Jan 2005 23:50:01 -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 1CoECS-0003e3-Kf for isms@ietf.org; Tue, 11 Jan 2005 00:04:17 -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 j0B4nNI1018766; Mon, 10 Jan 2005 20:49:23 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id ; Mon, 10 Jan 2005 20:50:05 -0800 Message-ID: From: "McDonald, Ira" To: "'Wes Hardaker'" , Randy Presuhn Subject: RE: [Isms] Evaluation status Date: Mon, 10 Jan 2005 20:50:03 -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: 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 Wes Hardaker wrote: >> 6) SNMPv3's symmetric keys are unique within a deployment (i.e., >> SNMP keys are unique to SNMP and are not integrated with any other >> IETF protocol). Similarly, SNMPv3 cannot use any existing >> authentication/authorization infrastructures already present in >> that deployment (e.g., Kerberos, PKI, RADIUS, etc.). Well, since that's the fundamental root of the WG, I'm sure they're all going to claim this is solved ;-) SBSM certainly solves it. It's interesting that this is last on Eric's list when it's first on many other people's (it wouldn't be first or last on mine, but I haven't ranked them). Note that Eric's list is ordered towards INCREASING importance (which is unfortunate, because folks keep missing that). 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 Jan 11 01:24: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 BAA07828; Tue, 11 Jan 2005 01:24:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoFgK-00055M-RO; Tue, 11 Jan 2005 01:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoFNm-0001lP-FQ; Tue, 11 Jan 2005 01:19:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoFMM-0001Dx-U2 for isms@megatron.ietf.org; Tue, 11 Jan 2005 01:18: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 BAA07430 for ; Tue, 11 Jan 2005 01:18:29 -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 1CoFa6-0004yL-S4 for isms@ietf.org; Tue, 11 Jan 2005 01:32:44 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id EF8B411D825; Mon, 10 Jan 2005 22:18:24 -0800 (PST) From: Wes Hardaker To: "McDonald, Ira" Subject: Re: [Isms] Evaluation status Organization: Sparta References: Date: Mon, 10 Jan 2005 22:18:24 -0800 In-Reply-To: (Ira McDonald's message of "Mon, 10 Jan 2005 20:50:03 -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: 7bac9cb154eb5790ae3b2913587a40de 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: 08170828343bcf1325e4a0fb4584481c >>>>> On Mon, 10 Jan 2005 20:50:03 -0800, "McDonald, Ira" said: Ira> Note that Eric's list is ordered towards INCREASING importance (which Ira> is unfortunate, because folks keep missing that). Yep. You're absolutely right, I missed that. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 03:12: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 DAA27531; Tue, 11 Jan 2005 03:12:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoHME-0006j7-U7; Tue, 11 Jan 2005 03:26:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoH7A-0001GK-55; Tue, 11 Jan 2005 03:10:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoH6R-00018K-SY for isms@megatron.ietf.org; Tue, 11 Jan 2005 03:10: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 DAA27486 for ; Tue, 11 Jan 2005 03:10:10 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoHKA-0006gm-VS for isms@ietf.org; Tue, 11 Jan 2005 03:24:26 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 5BBF11BACA3; Tue, 11 Jan 2005 09:09:36 +0100 (CET) Date: Tue, 11 Jan 2005 09:09:35 +0100 From: Juergen Quittek To: ietfdbh@comcast.net, "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Evaluation process? Message-ID: <2147483647.1105434575@[10.1.1.171]> In-Reply-To: <20050110174553.E76D22299F@smtp0.netlab.nec.de> References: <20050110174553.E76D22299F@smtp0.netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit David, --On 10.01.2005 12:41 Uhr -0500 David B Harrington wrote: > Juergen and Ken, > >> I think we are still fine if we have a recommendation from >> the evaluation >> team before Christmas. > > Do you still think we are fine? Yes, I do. However, we need to make progress this month. >> This will be late but still in time >> to agree or >> disagree on the recommendation on the mailing list > > Do you still feel we will have adequate time to agree or disagree on > the mailing list before the next meeting in March? Yes. Assuming a draft available on Feb 14, we will have three weeks on the list before the meeting. If there is no consensus, we will use the meeting for exchanging our arguments one last time in a face-to-face manner. Then we will either select a proposal or decide to close the WG. >> and, in >> case of agreement, >> to discuss a new charter before the next meeting in March. > > Do you still feel we will have adequate time to discuss a new charter > before the next meeting in March? I see our main challenge in reaching consensus on the solution to focus on. If we achieve this milestone in time, we won't fail on the charter discussion. 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 > 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 Jan 11 03:22:45 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 DAA27947; Tue, 11 Jan 2005 03:22:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoHWM-0006r1-8o; Tue, 11 Jan 2005 03:37:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoHB7-0001t3-Ub; Tue, 11 Jan 2005 03:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoH9z-0001dD-OK for isms@megatron.ietf.org; Tue, 11 Jan 2005 03:13: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 DAA27635 for ; Tue, 11 Jan 2005 03:13:50 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoHNl-0006jg-QZ for isms@ietf.org; Tue, 11 Jan 2005 03:28:06 -0500 Received: from [10.1.1.171] (mito.netlab.nec.de [195.37.70.39]) by kyoto.netlab.nec.de (Postfix) with ESMTP id C53511BACA3; Tue, 11 Jan 2005 09:13:19 +0100 (CET) Date: Tue, 11 Jan 2005 09:13:18 +0100 From: Juergen Quittek To: ietfdbh@comcast.net, "'Wes Hardaker'" Subject: RE: [Isms] Evaluation status Message-ID: <2147483647.1105434798@[10.1.1.171]> In-Reply-To: <20050110172124.331172297D@smtp0.netlab.nec.de> References: <20050110172124.331172297D@smtp0.netlab.nec.de> X-Mailer: Mulberry/3.0.3 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: 7bit David, --On 10.01.2005 12:16 Uhr -0500 David B Harrington wrote: > I agree. I don't feel this is a significant change. > The question posed was essentially, is the evaluation team making real > progress? > The answer "we have permission to push back an interim deadline" > doesn't answer the question asked. > > I think the more important points are that: > 1) The evaluation team has met and discussed all proposals. > > It is good to know that the team has been active, although this > doesn't give us much info on how active. They met at IETF61. It would > be nice if they and the chairs chose to share info, like how many > times have they met and had useful discussions. We are looking for > assurance that the team is seriously working on comparing and > discussing the proposals, and that the recommendations they provide > will be well-researched. > > They apparently have not conferred with the authors of the proposals > for any clarifications yet, and that seriously concerns me. I do not > feel comfortable that we will have meaningful comparisons completed > before the March IETF meeting. Please comfort me. > > 2) The team will produce an Internet draft reflecting the > discussion and giving a recommendation to the WG. > > OK. But do we get to know what they are using for evaluation > guidelines, or do we have to wait until feb14 to find out how the > evaluation is being done? If we don't even get to know what guidelines > are being used before the final publication deadline for the March > meeting, we certainly will not have time to do much if the WG > disagrees with the guidelines. Eric proposed some guidelines to meet > his security needs; Dave Perkins proposed some application guidelines; > Wes published a table of attributes for various potential solutions. > Are any or all of these proposed guidelines being taken into account > in defining the team's guidelines? Are all team members using the same > guidelines, or each using their own guidelines? > > I just want to know what the team's guidelines are so we are not > blind-sided if the evaluation team doesn't consider the issues that > the WG agrees need to be considered. The secrecy combined with the > tight deadline is stressful; I'd like to know if there is something > the rest of the WG or the authors of the proposals could be doing to > make the evaluation process more effective/efficient. > > 3) There is already a version of this draft, but the essential > section, the recommendation, is still to be done. > > Understood. Having an empty template for an internet-draft isn't very > reassuring, however. Thank you for the kind comment. You are very right! However, a missing essential section does not necessarily imply an empty document. I wouldn't have called it an initial version in such a case. The evaluation team spent effort on discussing and comparing the proposals and this is reflected by the initial version. 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 > Does the initial version indicate what factors > are being considered in the analysis - e.g. an abstraction of the > guidelines being used? > > 4) One of the problems the team is facing is that the different > proposals cover different aspects of the overall problem. > > So is there anything we can do to help make it easier to complete the > evaluation? > Can I clarify anything in the TLS proposal, or provide additional > specifications to address specfic aspects that are not currently > covered in the proposal, or provide research services such as > providing references to sections of other documents to help the team > quickly compare the proposals? > > dbh > >> -----Original Message----- >> From: Wes Hardaker [mailto:hardaker@tislabs.com] >> Sent: Monday, January 10, 2005 11:21 AM >> To: Juergen Quittek >> Cc: ietfdbh@comcast.net; isms@ietf.org >> Subject: Re: [Isms] Evaluation status >> >> >>>>> On Mon, 10 Jan 2005 14:05:57 +0100, Juergen Quittek >> said: >> >> Juergen> The most important news is that our shepherding AD granted > a >> Juergen> deadline extension until March for the WG decision on the >> Juergen> solution to focus on. You will find this reflected on our >> Juergen> charter web page. >> >> I actually don't find this a big change. The original November date >> was really just an early deadline that tried to emphasize the > urgency >> of the one in march which was the real cut-off: decide something or >> shut down. By simply aligning the should-be-decided deadline with > the >> must-be-decided deadline you haven't really changed anything. The > end >> result is still the same: if you wait until Feb 14th to let the >> members of the group know what 4-6 people have decided, I have > strong >> doubts that there is enough time between that point and the >> MUST-have-consensus deadline to handle the resulting discussions. >> >> -- >> Wes Hardaker >> Sparta >> > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 08:45: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 IAA23785; Tue, 11 Jan 2005 08:45:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMYX-0005iH-2r; Tue, 11 Jan 2005 08:59:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMIU-0000U7-VA; Tue, 11 Jan 2005 08:42:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMH4-00009X-Rp for isms@megatron.ietf.org; Tue, 11 Jan 2005 08:41: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 IAA23602 for ; Tue, 11 Jan 2005 08:41:29 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMUq-0005dL-V9 for isms@ietf.org; Tue, 11 Jan 2005 08:55:48 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0BDerL06540; Tue, 11 Jan 2005 08:40:53 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jan 2005 08:40:54 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B6C3@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Juergen Quittek'" , ietfdbh@comcast.net, "'Ken Hornstein'" , isms@ietf.org Subject: RE: [Isms] Evaluation process? Date: Tue, 11 Jan 2005 08:40:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============0529454498==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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. --===============0529454498== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F7E3.29A20E56" 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_01C4F7E3.29A20E56 Content-Type: text/plain > >> This will be late but still in time > >> to agree or > >> disagree on the recommendation on the mailing list > > > > Do you still feel we will have adequate time to agree or disagree on > > the mailing list before the next meeting in March? > > Yes. > > Assuming a draft available on Feb 14, we will have three weeks on > the list before the meeting. If there is no consensus, we will use > the meeting for exchanging our arguments one last time in a > face-to-face manner. > > Then we will either select a proposal or decide to close the WG. Closing the WG would be a real shame. Is there no way to build consensus outside of the evaluation process to such a minimize risk? Martin. ------_=_NextPart_001_01C4F7E3.29A20E56 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Evaluation process?

> >> This will be late but still in = time
> >> to agree or
> >> disagree on the recommendation on the = mailing list
> >
> > Do you still feel we will have adequate = time to agree or disagree on
> > the mailing list before the next meeting = in March?
>
> Yes.
>
> Assuming a draft available on Feb 14, we will = have three weeks on
> the list before the meeting.  If there is = no consensus, we will use
> the meeting for exchanging our arguments one = last time in a
> face-to-face manner.
>
> Then we will either select a proposal or decide = to close the WG.

Closing the WG would be a real shame. Is there no way = to build consensus outside of the evaluation process to such a minimize = risk?

Martin.

------_=_NextPart_001_01C4F7E3.29A20E56-- --===============0529454498== 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 --===============0529454498==-- From isms-bounces@ietf.org Tue Jan 11 09:08:40 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 JAA25015; Tue, 11 Jan 2005 09:08:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMvC-00067Y-P0; Tue, 11 Jan 2005 09:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMbi-0003FJ-6D; Tue, 11 Jan 2005 09:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoMWi-0002OP-QO for isms@megatron.ietf.org; Tue, 11 Jan 2005 08:57: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 IAA24348 for ; Tue, 11 Jan 2005 08:57:39 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoMkX-0005vJ-Cs for isms@ietf.org; Tue, 11 Jan 2005 09:11:58 -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 j0BDv3w28111 for ; Tue, 11 Jan 2005 08:57:03 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 11 Jan 2005 08:57:02 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B6C4@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Randy Presuhn'" , isms@ietf.org Subject: RE: [Isms] Evaluation status Date: Tue, 11 Jan 2005 08:56:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============1061010389==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 86f85b2f88b0d50615aed44a7f9e33c7 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. --===============1061010389== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F7E5.68AD9B90" 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_01C4F7E5.68AD9B90 Content-Type: text/plain I'm not an author, but I'd like to add my two cents on how I see the priorities of these items. > > 1) No provisions supporting two-factored authentication. This is a major issue - and not just two-factor. For this solution to have longevity it must support multi-factor authentication and should be composed in such a way as to be extensible to N-form. > > 2) SNMPv3's symmetric keys may be assembled from passwords (several > > SNMP implementations require that they must be so assembled due to > > symmetric key distribution problems). Such keys are no more secure than > > the passwords they are derived from. This is only true if the password is the complete key generation material. If the key is generated from multiple key generation material of which the password is a part this is not an issue. In either case, I don't think this is of high importance since I suspect it would be advantageous for different implementations to use different key material. In fact, I'd like to see a way to integrate the proposal with an SSO system and use application session tokens as key material for generating SNMP session keys. > > 3) Key updates do not provide for Perfect Forward Security (PFS). This is an important issue, probably about #3. > > 4) There is an inherent problem with SNMPv3's Symmetric Key > > distribution such that it is difficult to deploy multi-vendor SNMPv3 > > systems in a manner that is not operationally insecure. (Yes, I do know > > about RFC 2786 but I note that it is an informational RFC that is not > > universally implemented.) What will make the product of this WG more successful? > > 5) SNMPv3's session (i.e., privacy) keys are often default-deployed > > in (security) non-viable ways. If I understand this correctly, any proposal should include the inability to function in a default key state? If so I think this is an easy-win big-ticket. > > 6) SNMPv3's symmetric keys are unique within a deployment (i.e., > > SNMP keys are unique to SNMP and are not integrated with any other IETF > > protocol). Similarly, SNMPv3 cannot use any existing > > authentication/authorization infrastructures already present in that > > deployment (e.g., Kerberos, PKI, RADIUS, etc.). This is the reason we're here, I think. One thing I haven't seen clearly in any of the three proposals is how to allow authorization information to be exchanged during session key establishment (a la typical RADIUS). Is this outside of the scope of the WG? Did I miss it? Martin. ------_=_NextPart_001_01C4F7E5.68AD9B90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Evaluation status

I'm not an author, but I'd like to add my two cents = on how I see the priorities of these items.

> > 1) No provisions supporting two-factored = authentication.

This is a major issue - and not just two-factor. For = this solution to have longevity it must support multi-factor = authentication and should be composed in such a way as to be extensible = to N-form.

> > 2) SNMPv3's symmetric keys may be assembled = from passwords (several
> > SNMP implementations require that they = must be so assembled due to
> > symmetric key distribution problems). Such = keys are no more secure than
> > the passwords they are derived = from.

This is only true if the password is the complete key = generation material. If the key is generated from multiple key = generation material of which the password is a part this is not an = issue. In either case, I don't think this is of high importance since I = suspect it would be advantageous for different implementations to use = different key material. In fact, I'd like to see a way to integrate the = proposal with an SSO system and use application session tokens as key = material for generating SNMP session keys.

> > 3) Key updates do not provide for Perfect = Forward Security (PFS).

This is an important issue, probably about #3.

> > 4) There is an inherent problem with = SNMPv3's Symmetric Key
> > distribution such that it is difficult to = deploy multi-vendor SNMPv3
> > systems in a manner that is not = operationally insecure. (Yes, I do know
> > about RFC 2786 but I note that it is an = informational RFC that is not
> > universally implemented.)

What will make the product of this WG more = successful?

> > 5) SNMPv3's session (i.e., privacy) keys = are often default-deployed
> > in (security) non-viable ways.

If I understand this correctly, any proposal should = include the inability to function in a default key state? If so I think = this is an easy-win big-ticket.

> > 6) SNMPv3's symmetric keys are unique = within a deployment (i.e.,
> > SNMP keys are unique to SNMP and are not = integrated with any other IETF
> > protocol). Similarly, SNMPv3 cannot use = any existing
> > authentication/authorization = infrastructures already present in that
> > deployment (e.g., Kerberos, PKI, RADIUS, = etc.).

This is the reason we're here, I think.

One thing I haven't seen clearly in any of the three = proposals is how to allow authorization information to be exchanged = during session key establishment (a la typical RADIUS). Is this outside = of the scope of the WG? Did I miss it?

Martin.

------_=_NextPart_001_01C4F7E5.68AD9B90-- --===============1061010389== 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 --===============1061010389==-- From isms-bounces@ietf.org Tue Jan 11 10:04: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 KAA28956; Tue, 11 Jan 2005 10:04:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoNnZ-0007Gs-FV; Tue, 11 Jan 2005 10:19:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNUY-00034e-BV; Tue, 11 Jan 2005 09:59:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoNQO-0002fV-UT for isms@megatron.ietf.org; Tue, 11 Jan 2005 09:55: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 JAA28347 for ; Tue, 11 Jan 2005 09:55: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 1CoNeE-00076V-Rw for isms@ietf.org; Tue, 11 Jan 2005 10:09:31 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DA3CB11D825; Tue, 11 Jan 2005 06:55:07 -0800 (PST) From: Wes Hardaker To: "Martin Soukup" Subject: Re: [Isms] Evaluation status Organization: Sparta References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B6C4@zcarhxm2.corp.nortel.com> Date: Tue, 11 Jan 2005 06:55:06 -0800 In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2B6C4@zcarhxm2.corp.nortel.com> (Martin Soukup's message of "Tue, 11 Jan 2005 08:56:54 -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: e5ba305d0e64821bf3d8bc5d3bb07228 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 >>>>> On Tue, 11 Jan 2005 08:56:54 -0500, "Martin Soukup" said: >> > 1) No provisions supporting two-factored authentication. Martin> This is a major issue - and not just two-factor. For this Martin> solution to have longevity it must support multi-factor Martin> authentication and should be composed in such a way as to be Martin> extensible to N-form. This would certainly be nice. One caveat that I feel obligated to mention: Adding multi-factor authentication generally complicates the protocols that support it. This is primarily because of the sudden need to have N*2 packet exchanges in order to complete the authentication state, which means adding more state and makes the state diagram tree more complex. I'm not saying its not worth doing, but it does come at a cost. Martin> One thing I haven't seen clearly in any of the three proposals Martin> is how to allow authorization information to be exchanged Martin> during session key establishment (a la typical RADIUS). Is Martin> this outside of the scope of the WG? Did I miss it? It was discussed some at the last meeting. It is out of scope, however. Ideally the solutions shouldn't do something to get in the way of the above, but the specific goal is not in the charter of the group and would need to be added. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 10:56: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 KAA03323; Tue, 11 Jan 2005 10:56:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoObm-0008Hu-0h; Tue, 11 Jan 2005 11:11:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoONZ-0000FB-EO; Tue, 11 Jan 2005 10:56:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoOLT-0008Sk-8n for isms@megatron.ietf.org; Tue, 11 Jan 2005 10:54: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 KAA03161 for ; Tue, 11 Jan 2005 10:54:09 -0500 (EST) Message-Id: <200501111554.KAA03161@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoOZI-0008Em-Jn for isms@ietf.org; Tue, 11 Jan 2005 11:08:29 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011115533201400gfj1pe>; Tue, 11 Jan 2005 15:53:33 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Martin Soukup'" Date: Tue, 11 Jan 2005 10:53:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT37uY5dT+/FxjQTg2nPiNnnAVgRgAAKgDg X-Spam-Score: 0.1 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] Network management authorization 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: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Hi, For those interested in RADIUS authorization for network management interfaces, see ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- management-authorization-00.txt. Dave Nelson and I have been discussing this approach for a while. This proposal would be useful for all management interfaces. It could be a uniting factor between management interfaces for CLI, NETCONF, SNMP, and web-based interfaces, using similarly-named policies that have different methods of implementation for different management interfaces. It could also be a uniting factor across vendor products, using similarly-named policies that have different methods of implementation for different vendors' equipment. (To be clear, the per-vendor/per-mgmtinterface "methods of implementation" would be configured by operators.) This is similar to the RFC 3580 approach which binds IEEE 802.1X network access with RADIUS authentication and the passing of a RADIUS FilterID to authorize different types of access (in RFC 3580, services are provisioned to VLANs, and the FilterID authorizes user access to the VLAN). One goal is to use it with SNMPv3, using a RADIUS message to dynamically define the association between an authenticated security principal (vacmSecurityName) and a vacmGroupName. With pre-provisioned groups having VACM access control, the RADIUS Management-Policy-ID provides the glue between the user authentication and user authorization to management information/operations. While the standardization of VACM makes this pretty straightforward for SNMPv3, similar functionality could be used to associate the user with proprietary (or TBD) mechanisms that control CLI authorizations, web-based mgmt authorizations, and NETCONF authorizations. The RFC 3580/ IEEE 802.1X/RADIUS approach to network access appears to be getting wide deployment, and using a simlar approach for mgmt access would seem to be a big win. That's why I personally would like to see the EUSM proposal, or something similar, be advanced. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker > Sent: Tuesday, January 11, 2005 9:55 AM > To: Martin Soukup > Cc: isms@ietf.org > Subject: Re: [Isms] Evaluation status > > >>>>> On Tue, 11 Jan 2005 08:56:54 -0500, "Martin Soukup" > said: > > >> > 1) No provisions supporting two-factored authentication. > > Martin> This is a major issue - and not just two-factor. For this > Martin> solution to have longevity it must support multi-factor > Martin> authentication and should be composed in such a way as to be > Martin> extensible to N-form. > > This would certainly be nice. One caveat that I feel obligated to > mention: Adding multi-factor authentication generally complicates the > protocols that support it. This is primarily because of the sudden > need to have N*2 packet exchanges in order to complete the > authentication state, which means adding more state and makes the > state diagram tree more complex. I'm not saying its not worth doing, > but it does come at a cost. > > Martin> One thing I haven't seen clearly in any of the three proposals > Martin> is how to allow authorization information to be exchanged > Martin> during session key establishment (a la typical RADIUS). Is > Martin> this outside of the scope of the WG? Did I miss it? > > It was discussed some at the last meeting. It is out of scope, > however. Ideally the solutions shouldn't do something to get in the > way of the above, but the specific goal is not in the charter of the > group and would need to be added. > > > -- > 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 Tue Jan 11 13:11:45 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 NAA14091; Tue, 11 Jan 2005 13:11:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoQiS-0003AF-G3; Tue, 11 Jan 2005 13:26:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoQRq-0000l2-U4; Tue, 11 Jan 2005 13:08:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoQMu-0000EV-Hz for isms@megatron.ietf.org; Tue, 11 Jan 2005 13:03: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 NAA13723 for ; Tue, 11 Jan 2005 13:03:45 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoQai-000313-Ra for isms@ietf.org; Tue, 11 Jan 2005 13:18:08 -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 KAA25792; Tue, 11 Jan 2005 10:02: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 j0BI2vs00299; Tue, 11 Jan 2005 12:02:58 -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.0); Tue, 11 Jan 2005 10:02:45 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isms] Evaluation status Date: Tue, 11 Jan 2005 10:02:42 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDB1F@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation status Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/Ig From: "Fleischman, Eric" To: "Martin Soukup" , "Randy Presuhn" , X-OriginalArrivalTime: 11 Jan 2005 18:02:45.0197 (UTC) FILETIME=[C08A5FD0:01C4F807] X-Spam-Score: 0.6 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============0794354010==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: d008c19e97860b8641c1851f84665a75 This is a multi-part message in MIME format. --===============0794354010== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F807.BEFC691C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F807.BEFC691C Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Martin Soukup [mailto:msoukup@nortelnetworks.com] wrote:=20 > > 4) There is an inherent problem with SNMPv3's Symmetric Key=20 > > distribution such that it is difficult to deploy multi-vendor SNMPv3 > > systems in a manner that is not operationally insecure. (Yes, I do know=20 > > about RFC 2786 but I note that it is an informational RFC that is not=20 > > universally implemented.) =20 =20 > What will make the product of this WG more successful? =20 =20 Martin is asking a very important question here, which comes right back to my "evaluation rationale" concern. The issue is that the IETF has a diverse membership with diverse agendas. When I first started attending back in 1992, I was one of two individuals in the community who were "end users" (the other was Brian Carpenter, back when he worked for CERN). The community then, as now, was dominated by researchers and product makers. As the Internet grew in importance, the IETF community has become more diverse, with healthy participation from ISPs, governmental entities, and others. Each of these entities have their own agenda and issues.=20 =20 I tremendously value Wes Hardaker and his impressive skills, but our frequent disagreements on this list is a reflection of our difference in orientation. It's not necessarily that Wes is right and I am wrong, it is rather that the issues are complicated. We can ignore a community or a perspective (including their issues and agendas) but our result is stronger if we do not. =20 So what will make this WG more successful? I believe that clearly articulating the goals, concerns and issues of the various communities that comprise us is a "path forward" to completing our task well since it would provide a clearly stated evaluation rationale for us all. =20 My issues are the following: I have concluded that the SNMPv3 USM is currently operationally insecure and far too many SNMPv3 products are prohibitively difficult to deploy securely today (i.e., a "hack me here" technology and far too often the weakest point in a deployment). We buy products and I am constrained by what vendors create. It is an expensive and time consuming game to do what Wes is suggesting on the list for us do (i.e., for us to demand that vendors change their products or else we won't buy them). We've done that in the past and it is very costly to behave in that way -- and there are many more issues to consider in buying products than security. Therefore, to me, this WG will be successful if it results in interoperable SNMP products that leverage one or more of our current Authentication infrastructures in a manner that is operationally secure. I want the specification to compel default behaviors that are secure, rather than the current situation. The larger picture is that I want better tools and protections against crackers and I want this WG to help the larger picture by correcting the current SNMPv3 USM vulnerabilities. =20 --Eric ------_=_NextPart_001_01C4F807.BEFC691C Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Martin Soukup=20 [mailto:msoukup@nortelnetworks.com]  wrote: 
> > 4)=20 There is an inherent problem with SNMPv3's Symmetric Key =
> > distribution such that it is difficult to deploy = multi-vendor=20 SNMPv3
> > systems in a manner that is = not=20 operationally insecure. (Yes, I do know
> = > about=20 RFC 2786 but I note that it is an informational RFC that is not =
> > universally implemented.)  
 
> What will make the product of = this WG more=20 successful?  
 
Martin=20 is asking a very important question here, which comes right back to my=20 "evaluation rationale" concern. The issue is that the IETF has a diverse membership with = diverse agendas.=20 When I first started attending back in 1992, I was one of two = individuals in the=20 community who were "end users" (the other was Brian Carpenter, back when = he=20 worked for CERN). The community then, as now, was dominated by = researchers and=20 product makers. As the Internet grew in importance, the IETF community = has=20 become more diverse, with healthy participation from ISPs, governmental=20 entities, and others. Each of these entities have their own agenda and = issues.=20
 
I=20 tremendously value Wes Hardaker and his impressive skills, but our = frequent=20 disagreements on this list is a reflection of our difference in = orientation.=20 It's not necessarily that Wes is right and I am wrong, it is rather that = the=20 issues are complicated. We can ignore a community or a perspective = (including=20 their issues and agendas) but our result is stronger if we do=20 not.
 
So=20 what will make this WG more successful? I believe that clearly = articulating the=20 goals, concerns and issues of the various communities that comprise us = is a=20 "path forward" to completing our task well since it would provide a = clearly=20 stated evaluation rationale for us all.
 
My=20 issues are the following: I have concluded that the SNMPv3 = USM is=20 currently operationally insecure and far too many SNMPv3 products are=20 prohibitively difficult to deploy securely today (i.e., a "hack me here" = technology and far too often the weakest point in a=20 deployment). We buy products and I am constrained = by what=20 vendors create. It is an expensive and time consuming game to do what = Wes is=20 suggesting on the list for us do (i.e., for us to demand that vendors = change=20 their products or else we won't buy them). We've done that in the past = and it is=20 very costly to behave in that way -- and there are many more issues to = consider=20 in buying products than security. Therefore, to me,  this = WG will=20 be successful if it results in interoperable SNMP products that leverage = one or=20 more of our current Authentication infrastructures in a manner that is=20 operationally secure. I want the specification to compel default = behaviors that=20 are secure, rather than the current situation. The larger picture is = that I want=20 better tools and protections against crackers and I want this WG to help = the=20 larger picture by correcting the current SNMPv3 USM=20 vulnerabilities.
 
--Eric
------_=_NextPart_001_01C4F807.BEFC691C-- --===============0794354010== 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 --===============0794354010==-- From isms-bounces@ietf.org Tue Jan 11 13:25:45 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 NAA14834; Tue, 11 Jan 2005 13:25:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoQw2-0003Pl-QY; Tue, 11 Jan 2005 13:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoQhI-0003ei-ST; Tue, 11 Jan 2005 13:24:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoQgL-0003Tl-U1 for isms@megatron.ietf.org; Tue, 11 Jan 2005 13:23:54 -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 NAA14764 for ; Tue, 11 Jan 2005 13:23:51 -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 1CoQuD-0003Nq-RD for isms@ietf.org; Tue, 11 Jan 2005 13:38:14 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 1FA2D11D825; Tue, 11 Jan 2005 10:23:47 -0800 (PST) From: Wes Hardaker To: Organization: Sparta References: <200501111550.j0BFoCGx014627@nutshell.tislabs.com> Date: Tue, 11 Jan 2005 10:23:47 -0800 In-Reply-To: <200501111550.j0BFoCGx014627@nutshell.tislabs.com> (David B. Harrington's message of "Tue, 11 Jan 2005 10:53:28 -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: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: isms@ietf.org Subject: [Isms] Re: Network management authorization X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: d6b246023072368de71562c0ab503126 >>>>> On Tue, 11 Jan 2005 10:53:28 -0500, "David B Harrington" said: David> That's why I personally would like to see the EUSM proposal, or David> something similar, be advanced. I think what you really mean there is you want the final solution to be able to use Radius (like both SBSM and the TLS one was striving for, though the details aren't spelled out in either but its in the goals)). Or do you mean you want radius to be the only supported authentication solution, like EUSM requires? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 14:23:36 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 OAA18166; Tue, 11 Jan 2005 14:23:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoRpz-0004WY-Pd; Tue, 11 Jan 2005 14:37:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRY6-0001m2-2U; Tue, 11 Jan 2005 14:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRTN-0001Hb-Fa for isms@megatron.ietf.org; Tue, 11 Jan 2005 14:14: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 OAA17631 for ; Tue, 11 Jan 2005 14:14:32 -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 1CoRhD-0004Kh-KI for isms@ietf.org; Tue, 11 Jan 2005 14:28:54 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA05595 for ; Tue, 11 Jan 2005 14:20:12 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma005579; Tue, 11 Jan 05 14:20:10 -0500 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 11 Jan 2005 14:14:26 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 11 Jan 2005 14:14:26 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Jan 2005 14:14:26 -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] Network management authorization Date: Tue, 11 Jan 2005 14:14:24 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907B@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT37uY5dT+/FxjQTg2nPiNnnAVgRgAAKgDgAAhrRmA= From: "Nelson, David" To: X-OriginalArrivalTime: 11 Jan 2005 19:14:26.0204 (UTC) FILETIME=[C423F5C0:01C4F811] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0742 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Dave Harrington writes... > For those interested in RADIUS authorization for network management > interfaces, see > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > management-authorization-00.txt. Dave Nelson and I have been > discussing this approach for a while. I think that draft has expired. I plan to update it, and perhaps have a -01 version out prior to IETF 62. Comments and suggestions are welcome. If anyone wants a copy of the -00 draft, and can't find it in an archive, please drop me a note. -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 14:49:42 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 OAA20499; Tue, 11 Jan 2005 14:49:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSFI-0005AG-5T; Tue, 11 Jan 2005 15:04:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRyn-0006Bs-Uo; Tue, 11 Jan 2005 14:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRu4-0005Ur-BM for isms@megatron.ietf.org; Tue, 11 Jan 2005 14:42: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 OAA19812 for ; Tue, 11 Jan 2005 14:42:07 -0500 (EST) Message-Id: <200501111942.OAA19812@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoS7w-0004vu-0s for isms@ietf.org; Tue, 11 Jan 2005 14:56:29 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005011119413501500n8ssae>; Tue, 11 Jan 2005 19:41:35 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] Network management authorization Date: Tue, 11 Jan 2005 14:41: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.5510 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907B@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT37uY5dT+/FxjQTg2nPiNnnAVgRgAAKgDgAAhrRmAAAQpVUA== X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Actually, it expires January 10 (i.e. yesterday) but is still available today for those who move quickly ;-) dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, January 11, 2005 2:14 PM > To: isms@ietf.org > Subject: RE: [Isms] Network management authorization > > Dave Harrington writes... > > > For those interested in RADIUS authorization for network management > > interfaces, see > > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > > management-authorization-00.txt. Dave Nelson and I have been > > discussing this approach for a while. > > I think that draft has expired. I plan to update it, and > perhaps have a > -01 version out prior to IETF 62. Comments and suggestions > are welcome. > If anyone wants a copy of the -00 draft, and can't find it in an > archive, please drop me a note. > > -- Dave > > > > _______________________________________________ > 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 Jan 11 14:55: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 OAA20728; Tue, 11 Jan 2005 14:55:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSL7-0005H6-Ev; Tue, 11 Jan 2005 15:10:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoS6q-0007Yn-2R; Tue, 11 Jan 2005 14:55:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoRzr-0006HQ-2b for isms@megatron.ietf.org; Tue, 11 Jan 2005 14:48: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 OAA20432 for ; Tue, 11 Jan 2005 14:48:05 -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 1CoSDe-00057y-T6 for isms@ietf.org; Tue, 11 Jan 2005 15:02:27 -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 j0BJlSBZ002208; Tue, 11 Jan 2005 19:47:28 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 j0BJlSWs029380; Tue, 11 Jan 2005 19:47:28 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011111472817395 ; Tue, 11 Jan 2005 11:47:28 -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); Tue, 11 Jan 2005 11:47:28 -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); Tue, 11 Jan 2005 11:47:27 -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); Tue, 11 Jan 2005 14:47:25 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 14:47:24 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C59298A8EA3@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0A= From: "Blumenthal, Uri" To: "Fleischman, Eric" X-OriginalArrivalTime: 11 Jan 2005 19:47:25.0918 (UTC) FILETIME=[602457E0:01C4F816] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.6 (/) X-Scan-Signature: 2f46977da373544777a750d5247d6ccc Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1560753195==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 23336e92cd9b2f166f17126afcdd84ec This is a multi-part message in MIME format. --===============1560753195== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F816.5FC59719" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F816.5FC59719 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I tremendously value Wes Hardaker and his impressive skills, but our frequent disagreements on this list is a reflection of our difference in orientation. It's not necessarily that Wes is right and I am wrong, it is rather that the issues are complicated. We can ignore a community or a perspective (including their issues and agendas) but our result is stronger if we do not. =20 Uri> Perhaps we should concentrate on the common part of all the proposals - which is the most foreign to SNMP protocol - the idea of "sessions". Once this is added cleanly - the rest ought to be easy (after all, there's lots of knowledge in science and experience in the field regarding protecting session traffic, once the entities are authenticated and session "master key" is created). Lack of "session" concept makes integration with any session-based infrastructure a hack at best. =20 Many years ago, Jeff Case and others were proposing Session-based approach. It was shot down at the time, because (a) it wasn't clear how to deal with local resource consumption; (b) it wasn't clear that it is necessary; (c) it was deemed too expensive. There was no talk of integrating with RADIUS back then (I think RADIUS protocol wasn't even defined yet). =20 What we need to add to the architecture (probably not the protocol itself - it doesn't have to show on the wire). I'll speak of sessions in terms of USM and integration with USM - though it's not an absolute necessity. But since requirements that session management lays on VACM are the same as for USM, it's reasonable to keep it in here. Especially since I see a way to avoid modifying the message or packet format. =20 Session: owns resources, requires dynamics in VACM and USM tables. In that case - not "users" but "sessions" will "own" the actual traffic keys, not "users" but "sessions" will be mapped onto VACM groups... And a "session" will be created upon successful completion of "user" authentication and high-level authorization, accomplished via non-SNMP protocol (RADIUS, Kerberos, whatever). One has to define sessions, because all the parameters (how many sessions are currently handled by this engine, what's the life-time of this session, how much traffic has it consumed, what user owns it, what protocol authorized its generation, etc) ............ Nah, probably not the right place to start this discussion....... =20 =20 I want to poll the group: do you agree that in order to cleanly integrate with any of the eisting infrastructures, SNMP needs to define and emprace the concept of a session. If there's agreement - I'll finish my write-up and submit it. [If not - I've other interesting things to do :-] =20 =20 So what will make this WG more successful? I believe that clearly articulating the goals, concerns and issues of the various communities that comprise us is a "path forward" to completing our task well since it would provide a clearly stated evaluation rationale for us all.=20 =20 Uri> We're in agreement here. =20 My issues are the following: I have concluded that the SNMPv3 USM is currently operationally insecure=20 =20 Uri> I resent this comment and find it unfounded and unjustified.=20 =20 .... and far too many SNMPv3 products are prohibitively difficult to deploy securely today (i.e., a "hack me here" technology and far too often the weakest point in a deployment).=20 =20 Uri> And why is that? =20 We buy products and I am constrained by what vendors create. It is an expensive and time consuming game to do what Wes is suggesting on the list for us do (i.e., for us to demand that vendors change their products or else we won't buy them).=20 =20 Uri> You have your needs, other have theirs - that don't match yours. So convince vendors that it's your needs that should be addressed. There is no other acceptable way - to create a special standard just so that your needs (rather than theirs) are addressed, seems too gross. =20 We've done that in the past and it is very costly to behave in that way -- and there are many more issues to consider in buying products than security.=20 =20 Uri> If only very few customers require what you need - obviously the "customized" solution will cost money. What else is news? =20 Therefore, to me, this WG will be successful if it results in interoperable SNMP products that leverage one or more of our current Authentication infrastructures in a manner that is operationally secure. =20 Uri> 1. This WG can result only in proposals later-to-become-standards, not products. 2. All of the submitted proposals leverage one or more of the current Authentication infrastructures. So this WG will be successful even if we just toss a coin to choose one. =20 I want the specification to compel default behaviors that are secure, rather than the current situation.=20 =20 Uri> "Secure" for you is "overboard" for most of other users. Why should the default favor you and not them? =20 ------_=_NextPart_001_01C4F816.5FC59719 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 tremendously value Wes Hardaker and his impressive skills, but our = frequent=20 disagreements on this list is a reflection of our difference in = orientation.=20 It's not necessarily that Wes is right and I am wrong, it is rather that = the=20 issues are complicated. We can ignore a community or a perspective = (including=20 their issues and agendas) but our result is stronger if we do=20 not.
 
Uri> Perhaps we should concentrate on = the common=20 part of all the proposals - which is the most foreign to SNMP protocol - = the=20 idea of "sessions". Once this is added cleanly - the rest ought = to be=20 easy (after all, there's lots of knowledge in science and experience in = the=20 field regarding protecting session traffic, once the entities are = authenticated=20 and session "master key"  is created). Lack of "session" concept = makes=20 integration with any session-based infrastructure a hack at=20 best.
 
Many years ago, Jeff Case and others were = proposing=20 Session-based approach. It was shot down at the time, because (a) it = wasn't=20 clear how to deal with local resource consumption; (b) it wasn't clear = that it=20 is necessary; (c) it was deemed too expensive. There was no talk of = integrating=20 with RADIUS back then (I think RADIUS protocol wasn't even defined=20 yet).
 
What we need to add to the architecture = (probably=20 not the protocol itself - it doesn't have to show on the wire). = I'll=20 speak of sessions in terms of USM and integration with USM - though = it's=20 not an absolute necessity. But since requirements that session = management lays=20 on VACM are the same as for USM, it's reasonable to keep it in here. = Especially=20 since I see a way to avoid modifying the message or packet=20 format.
 
Session: owns resources, requires = dynamics=20 in VACM and USM tables. In that case - not "users" but "sessions" = will=20 "own" the actual traffic keys, not "users" but "sessions" will be mapped = onto=20 VACM groups... And a "session" will be created upon successful = completion of=20 "user" authentication and high-level authorization, accomplished via = non-SNMP=20 protocol (RADIUS, Kerberos, whatever). One has to define sessions, = because all=20 the parameters (how many sessions are currently handled by this engine, = what's=20 the life-time of this session, how much traffic has it consumed, = what=20 user owns it, what protocol authorized its generation, = etc) ............=20 Nah, probably not the right place to start this=20 discussion.......
 
 
I want to poll the group: do you agree = that in=20 order to cleanly integrate with any of the eisting = infrastructures,=20 SNMP needs to define and emprace the concept of a session. = If=20 there's agreement - I'll finish my write-up and submit it. [If not - = I've other=20 interesting things to do :-]
 
 
So what will make this WG more successful? I believe that = clearly=20 articulating the goals, concerns and issues of the various communities = that=20 comprise us is a "path forward" to completing our task well since it = would=20 provide a clearly stated evaluation rationale for us all. 
 
Uri> We're in=20 agreement here.
 
My issues are the following: I have concluded that the SNMPv3 USM is = currently=20 operationally insecure 
 
Uri> I resent this comment and = find it=20 unfounded and unjustified. =
 
.... and far too many SNMPv3 = products are=20 prohibitively difficult to deploy securely today (i.e., a "hack me here" = technology and far too often the weakest point in a deployment). 
 
Uri> And why is=20 that?
 
We = buy products=20 and I am constrained by what vendors create. It is an expensive and time = consuming game to do what Wes is suggesting on the list for us do (i.e., = for us=20 to demand that vendors change their products or else we won't buy = them). 
 
Uri> = You have=20 your needs, other have theirs - that don't match yours. So convince = vendors=20 that it's your needs that should be addressed. There is no other=20 acceptable way - to create a special standard just so that your = needs=20 (rather than theirs) are addressed, seems too=20 gross.
 
We've done that in the past and it is very = costly to=20 behave in that way -- and there are many more issues to consider in = buying=20 products than security. 
 
Uri> = If only very=20 few customers require what you need - obviously the "customized" = solution=20 will cost money. What else is=20 news?
 
Therefore, to me,  this WG will be = successful=20 if it results in interoperable SNMP products that leverage one or more = of our=20 current Authentication infrastructures in a manner that is operationally = secure. 
 
Uri> = 1.=20 This WG can result only in proposals later-to-become-standards, not = products. 2. All of the submitted proposals leverage one or more of the = current=20 Authentication infrastructures. So this WG will be successful even if we = just=20 toss a coin to choose=20 one.
 
I want the specification to compel default = behaviors=20 that are secure, rather than the current situation. 
 
Uri> "Secure" for you is "overboard" = for most of=20 other users. Why should the default favor you and not=20 them?
  ------_=_NextPart_001_01C4F816.5FC59719-- --===============1560753195== 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 --===============1560753195==-- From isms-bounces@ietf.org Tue Jan 11 15:10: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 PAA21970; Tue, 11 Jan 2005 15:10:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSZ1-0005WB-Ci; Tue, 11 Jan 2005 15:24:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSFh-0002lm-JV; Tue, 11 Jan 2005 15:04:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSBy-0000Kq-SL for isms@megatron.ietf.org; Tue, 11 Jan 2005 15:00:38 -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 PAA20953 for ; Tue, 11 Jan 2005 15:00:37 -0500 (EST) Received: from colo-dns-ext1.juniper.net ([207.17.137.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSPq-0005Kp-Hw for isms@ietf.org; Tue, 11 Jan 2005 15:14:59 -0500 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id j0BK04923631; Tue, 11 Jan 2005 12:00:04 -0800 (PST) (envelope-from dchuang@juniper.net) Received: from juniper.net (dchuang-bsd.juniper.net [172.17.20.91]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j0BJxxe21572; Tue, 11 Jan 2005 11:59:59 -0800 (PST) (envelope-from dchuang@juniper.net) Message-ID: <41E4303E.1000508@juniper.net> Date: Tue, 11 Jan 2005 11:59:58 -0800 From: Daniel Chuang Organization: Juniper User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20040102 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietfdbh@comcast.net Subject: Re: [Isms] Network management authorization References: <200501111942.OAA19812@ietf.org> In-Reply-To: <200501111942.OAA19812@ietf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Actually you can get it from: http://www.watersprings.org/pub/id/draft-nelson-radius-management-authorization-00.txt thanks, Daniel David B Harrington wrote: >Actually, it expires January 10 (i.e. yesterday) but is still >available today for those who move quickly ;-) > >dbh > > > >>-----Original Message----- >>From: isms-bounces@lists.ietf.org >>[mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David >>Sent: Tuesday, January 11, 2005 2:14 PM >>To: isms@ietf.org >>Subject: RE: [Isms] Network management authorization >> >>Dave Harrington writes... >> >> >> >>>For those interested in RADIUS authorization for network >>> >>> >management > > >>>interfaces, see >>> >>> >>> >ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > > >>>management-authorization-00.txt. Dave Nelson and I have been >>>discussing this approach for a while. >>> >>> >>I think that draft has expired. I plan to update it, and >>perhaps have a >>-01 version out prior to IETF 62. Comments and suggestions >>are welcome. >>If anyone wants a copy of the -00 draft, and can't find it in an >>archive, please drop me a note. >> >>-- Dave >> >> >> >>_______________________________________________ >>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 Jan 11 15:15: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 PAA22622; Tue, 11 Jan 2005 15:15:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSeB-0005eS-59; Tue, 11 Jan 2005 15:29:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSOa-0001PX-IE; Tue, 11 Jan 2005 15:13:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSLa-0007VT-C8 for isms@megatron.ietf.org; Tue, 11 Jan 2005 15:10:34 -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 PAA22052 for ; Tue, 11 Jan 2005 15:10:32 -0500 (EST) Message-Id: <200501112010.PAA22052@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSZS-0005Vr-7F for isms@ietf.org; Tue, 11 Jan 2005 15:24:55 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011120100101400gl6m8e>; Tue, 11 Jan 2005 20:10:02 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Date: Tue, 11 Jan 2005 15:09:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4Cr7w/KQRD/w3Rm2zbXmLQGybmwACu4qg X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org Subject: [Isms] RE: Network management authorization 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: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit Hi, I want a solution that can use RADIUS for authentication, since RADIUS is widely deployed, and a RADIUS solution could utilize management-policy-id filters, or something comparable, to map to SNMPv3 access control mechanisms like VACM. It's not the only solution I want, but one of the solutions I want. The SBSM and the TLS proposals can also use RADIUS, but I would like to avoid solutions that provide yet another layer of indirection beyond the one provided via the securityModel abstraction. As I worked on analyzing how a transport layer security model could be implemented using protocols like TLS, DTLS, and SSH, I found that the available transport layer solutions seemed to do the same thing - provide a layer of abstraction to , and nobody actually ever seemed to solve the problem of providing a concrete solution, they only pass the buck to another protcol. Yes, different communities segments have different needs, and we should try to make it possible for those different communities to solve their needs using different solutions/mechanisms, but ultimately somebody somewhere somehow needs to make a concrete proposal that will work, and will be administratively consistent with, and equally secure as, other concrete security solutions that are actually being deployed. I don't want RADIUS to be the only supported solution, since it obviously doesn't resolve the needs of some segments of the coumminty, but I would like to see concrete proposals like EUSM that are consistent with other security solutiions that are being widely deployed. The TLS security model doesn't meet the "concreteness" goal since it provides a layer of abstraction to [TLS/DTLS/SSH], which themselves provide a layer of abstraction to ; EUSM comes close to meeting the "concreteness" criteria by using a solution that seems fairly consistent with the 802.1X/RADIUS/RFC3580 network access solution. (Of course, the fact that Bernard Aboba claimms EUSM does things with RADIUS that are forbidden by the RADIUS protocol doesn't help its case a lot.) When the TLS securitymodle, or the SBSM securitymodel, has a concrete backend specified in a way that can actually be implemented, then I'll think we're making real progress. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Tuesday, January 11, 2005 1:24 PM > To: ietfdbh@comcast.net > Cc: 'Martin Soukup'; isms@ietf.org > Subject: Re: Network management authorization > > >>>>> On Tue, 11 Jan 2005 10:53:28 -0500, "David B > Harrington" said: > > David> That's why I personally would like to see the EUSM proposal, or > David> something similar, be advanced. > > I think what you really mean there is you want the final solution to > be able to use Radius (like both SBSM and the TLS one was striving > for, though the details aren't spelled out in either but its in the > goals)). Or do you mean you want radius to be the only supported > authentication solution, like EUSM requires? > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 15:17:34 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 PAA22891; Tue, 11 Jan 2005 15:17:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoSgF-0005hV-IB; Tue, 11 Jan 2005 15:31:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSQI-0005dG-4Z; Tue, 11 Jan 2005 15:15:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSN5-0000Av-2D for isms@megatron.ietf.org; Tue, 11 Jan 2005 15:12: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 PAA22231 for ; Tue, 11 Jan 2005 15:12:05 -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 1CoSaw-0005a4-UB for isms@ietf.org; Tue, 11 Jan 2005 15:26:28 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA08710 for ; Tue, 11 Jan 2005 15:17:46 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma008688; Tue, 11 Jan 05 15:17:14 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 11 Jan 2005 15:11:30 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 11 Jan 2005 15:11:30 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Jan 2005 15:11:30 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 15:11:29 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907D@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AAA65k0A== From: "Nelson, David" To: X-OriginalArrivalTime: 11 Jan 2005 20:11:30.0407 (UTC) FILETIME=[BD1FDF70:01C4F819] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:92.2131 M:98.8113 P:95.9108 R:95.9108 S:74.7888 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 Uri Blumenthal writes... > I want to poll the group: do you agree that in order=A0 > to cleanly integrate with any of the existing infrastructures, > SNMP needs to define and embrace the concept of a=A0session. > If there's agreement - I'll finish my write-up and submit it. I agree. The notion of session might be accomplished via use of an existing = secure session context (e.g. TLS session, IPSec SA, etc.) or it could = simply be defined using the current SNMPv3 privacy mechanism, based on = the lifetime of the "session keys". We would need to adopt an = appropriate authenticated key management system (e.g. Kerberos, etc.) to = meet this requirement. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 16:38: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 QAA06378; Tue, 11 Jan 2005 16:38:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTwa-0001dh-0q; Tue, 11 Jan 2005 16:52:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoT8l-00078O-Ar; Tue, 11 Jan 2005 16:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSn1-0002xI-2W for isms@megatron.ietf.org; Tue, 11 Jan 2005 15:38:55 -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 PAA24581 for ; Tue, 11 Jan 2005 15:38:52 -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 1CoT0r-00064A-GQ for isms@ietf.org; Tue, 11 Jan 2005 15:53:15 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id PAA10090 for ; Tue, 11 Jan 2005 15:44:33 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma010077; Tue, 11 Jan 05 15:43:50 -0500 Received: from NHROCCNC1.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 11 Jan 2005 15:38:07 -0500 Received: from source ([134.141.77.90]) by host ([134.141.79.124]) with SMTP; Tue, 11 Jan 2005 15:38:07 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC1.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Jan 2005 15:38:00 -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] RE: Network management authorization Date: Tue, 11 Jan 2005 15:38:00 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907E@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Network management authorization Thread-Index: AcT4Cr7w/KQRD/w3Rm2zbXmLQGybmwACu4qgAAF6+cA= From: "Nelson, David" To: X-OriginalArrivalTime: 11 Jan 2005 20:38:00.0898 (UTC) FILETIME=[71218A20:01C4F81D] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:86.9899 M:99.2571 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 > (Of course, the fact > that Bernard Aboba claimms EUSM does things with RADIUS that are > forbidden by the RADIUS protocol doesn't help its case a lot.) I'm not sure I remember that posting. It may well have to do with the fact that RADIUS is not an authenticated key management service. There are IDs proposing to add that kind of service to RADIUS. They are currently considered out-of-scope of the RADEXT WG, because that WG's charter explicitly excludes new security methods for RADIUS. Having said that, RADIUS, using EAP methods, has been used as the AAA system behind the authenticated key management system in IEEE 802.11i wireless LANs.=20 There has also been some discussion of changes to RADIUS to make it FIPS compliant (whatever that turns out to mean), and the RADEXT charter might be revised at some point when NIST has given definitive guidance on this subject, and sufficient progress has been made on WG deliverables and milestones, to warrant a charter revision. Too soon to predict... _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 16:39: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 QAA06552; Tue, 11 Jan 2005 16:39:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTxT-0001gV-0u; Tue, 11 Jan 2005 16:53:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoT92-0007RF-EP; Tue, 11 Jan 2005 16:01:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoSy8-0000Az-5K for isms@megatron.ietf.org; Tue, 11 Jan 2005 15:50: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 PAA26127 for ; Tue, 11 Jan 2005 15:50:21 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTBw-0006iE-Ta for isms@ietf.org; Tue, 11 Jan 2005 16:04:44 -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 j0BKnlZY031575; Tue, 11 Jan 2005 12:49:47 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0BKnn38005041; Tue, 11 Jan 2005 12:49:49 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0BKnmTk005030; Tue, 11 Jan 2005 12:49:48 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 11 Jan 2005 12:49:47 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: Re: [Isms] Network management authorization In-Reply-To: <200501111554.KAA03161@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 HI, I read ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- management-authorization-00.txt and see NOTHING about about the proposal that helps EUSM. I believe that EUSM wouldn't really support that the proposal that well, but I would have to carefully re-read the EUSM proposal to come to a statement of fact. On the other hand, SBSM could use the ...radius-management-authorization... proposal pretty easily. However, Wes and I thought that solving one part first was a better approach than also working on authorization modifications. That part was to design a framework based on lightweight sessions over UDP that allowed integration with any and all existing endpoint identity authentication mechanisms. With a session approach, one can afford the overhead of a once per session retrieving authorization rules (policy). With SBSM, the security charateristics of the sessions are better than those in USM. I believe that the SBSM approach is lower in cost to develop and deploy, and then later to extend and deploy by a large margin over EUSM. On Tue, 11 Jan 2005, David B Harrington wrote: > Hi, > > For those interested in RADIUS authorization for network management > interfaces, see > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > management-authorization-00.txt. Dave Nelson and I have been > discussing this approach for a while. > > > > One goal is to use it with SNMPv3, using a RADIUS message to > dynamically define the association between an authenticated security > principal (vacmSecurityName) and a vacmGroupName. With pre-provisioned > groups having VACM access control, the RADIUS Management-Policy-ID > provides the glue between the user authentication and user > authorization to management information/operations. > > While the standardization of VACM makes this pretty straightforward > for SNMPv3, similar functionality could be used to associate the user > with proprietary (or TBD) mechanisms that control CLI authorizations, > web-based mgmt authorizations, and NETCONF authorizations. > > The RFC 3580/ IEEE 802.1X/RADIUS approach to network access appears to > be getting wide deployment, and using a simlar approach for mgmt > access would seem to be a big win. That's why I personally would like > to see the EUSM proposal, or something similar, be advanced. > Again, I don't see how it follows that EUSM works "better" than SBSM. Would you explain how you got to this conclusion. Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 16:44: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 QAA07171; Tue, 11 Jan 2005 16:44:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoU2p-0001t0-9f; Tue, 11 Jan 2005 16:59:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTQz-0000aH-HK; Tue, 11 Jan 2005 16:20:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoT8C-0006Qv-Ve for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:00: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 QAA28595 for ; Tue, 11 Jan 2005 16:00:46 -0500 (EST) Message-Id: <200501112100.QAA28595@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoTM2-0007VU-F3 for isms@ietf.org; Tue, 11 Jan 2005 16:15:09 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005011121001301300t0fp7e>; Tue, 11 Jan 2005 21:00:13 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 16:00:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907D@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AAA65k0AAA8cNg X-Spam-Score: 0.1 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: quoted-printable 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: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Hi, I would phrase the requirement slightly differently. I do not believe that "in order=A0to cleanly integrate with any of the existing infrastructures, SNMP needs to define and embrace the concept of a=A0session.", but rather if SNMP embraced the concept of a session, it would have a much much larger selection of existing infrastructures with which to integrate. If we adopt a third-party-authenticated session, we still need to have a fallback to a UDP-based trasnport and limited local authentication for troubleshooting a broken network. I think the benefits of a session approach are numerous: If we adopt a secured-transport session, we may not have to provide message authentication, integrity, and timeliness in the SNMP engine. If we adopt a secured-transport session, we might send multiple SNMP messages within the same session, to minimize the overhead. If we adopt a secured-transport session, we might make this host-to-host, which is similar to the way many operators "authenticate" SNMPv1 messages.=20 If we adopt a secured-transport session with host-level authentication, we might make user-authentication part of the authorization stage, so we don't have to pass the security principal from the transport layer to the application layer. If we adopt a secured-transport session, we might be able to transport the simpler SNMPv1 or SNMPv2c message formats securely. If we adopt a stream-based transport session, we might send much larger messages, improving SNMP's efficiency for table retrieval. If we adopt a stream-based transport session, that would make SNMP much more consistent with other management interfaces, like CLI/SSH and NETCONF. If we adopt a stream-based transport session, we could more easily utilize an XML-based data description approach, and move away from ASN.1. I, for one, would like to see us adopt a session-based approach to supplement the UDP-based approach needed for troubleshooting broken networks. My preference would be to utilize sessions already provided by lower-layer protocols, so we can simplify SNMPv3. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org=20 > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, January 11, 2005 3:11 PM > To: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] >=20 > Uri Blumenthal writes... >=20 > > I want to poll the group: do you agree that in order=A0 > > to cleanly integrate with any of the existing infrastructures, > > SNMP needs to define and embrace the concept of a=A0session. > > If there's agreement - I'll finish my write-up and submit it. >=20 > I agree. >=20 > The notion of session might be accomplished via use of an=20 > existing secure session context (e.g. TLS session, IPSec SA,=20 > etc.) or it could simply be defined using the current SNMPv3=20 > privacy mechanism, based on the lifetime of the "session=20 > keys". We would need to adopt an appropriate authenticated=20 > key management system (e.g. Kerberos, etc.) to meet this requirement. >=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 Tue Jan 11 16:55: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 QAA08030; Tue, 11 Jan 2005 16:55:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUCf-0002CT-P6; Tue, 11 Jan 2005 17:09:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTmN-0005X3-Tf; Tue, 11 Jan 2005 16:42:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTPK-0007jV-Uq for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:18: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 QAA01700 for ; Tue, 11 Jan 2005 16:18:28 -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 1CoTdB-0008Te-ET for isms@ietf.org; Tue, 11 Jan 2005 16:32:52 -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 j0BLHpKQ031841; Tue, 11 Jan 2005 21:17:51 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) 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 j0BLGw2a031805; Tue, 11 Jan 2005 21:17:50 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011113175029499 ; Tue, 11 Jan 2005 13:17:50 -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); Tue, 11 Jan 2005 13:17:50 -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); Tue, 11 Jan 2005 13:17:50 -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, 11 Jan 2005 16:17:04 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 16:17:03 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C59298A8FBE@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AAA65k0AAAz+jA From: "Blumenthal, Uri" To: "Nelson, David" , X-OriginalArrivalTime: 11 Jan 2005 21:17:04.0609 (UTC) FILETIME=[E6177510:01C4F822] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable >> I want to poll the group: do you agree that in order=A0 >> to cleanly integrate with any of the existing infrastructures, >> SNMP needs to define and embrace the concept of a=A0session. >> If there's agreement - I'll finish my write-up and submit it. > > I agree. Thank you. > The notion of session might be accomplished via use of an existing = secure > session context (e.g. TLS session, IPSec SA, etc.) I don't think so. Because in order to map it onto VACM - which none of = the proposals (except for EUSM) did - the SNMP packet itself has to = carry relevant information. Otherwise it wouldn't be any different than = just tunneling SNMP traffic through an underlying protocol (such as TLS = or IPsec). But no way to *cleanly* map the exchange to VACM. > or it could simply be defined using the current SNMPv3 privacy = mechanism, > based on the lifetime of the "session keys". We would need to adopt = an > appropriate authenticated key management system (e.g. Kerberos, etc.) > to meet this requirement. If by "privacy" you mean USM - I agree. If you mean just the = "confidentiality" feature of USM - then I don't understand. And yes - I envision creating dynamic USM entries for sessions, with = appropriate keys computed locally from "session keys" received from = Kerberos or RADIUS (or such). _______________________________________________ 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 Jan 11 16:58: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 QAA08336; Tue, 11 Jan 2005 16:58:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUFu-0002H6-5z; Tue, 11 Jan 2005 17:12:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTrL-0000V8-K1; Tue, 11 Jan 2005 16:47:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTaT-0006Km-Tm for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:30:01 -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 QAA04141 for ; Tue, 11 Jan 2005 16:29:59 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoToM-0000uT-Rs for isms@ietf.org; Tue, 11 Jan 2005 16:44:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2005 13:31:32 -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 j0BLTljw024020; Tue, 11 Jan 2005 13:29:47 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-71-254-121.cisco.com [171.71.254.121]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXE60686; Tue, 11 Jan 2005 13:29:46 -0800 (PST) Message-Id: <6.2.0.14.0.20050111125116.04b00f78@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 11 Jan 2005 13:29:45 -0800 To: ietfdbh@comcast.net From: Kaushik Narayan Subject: Re: [Isms] RE: Network management authorization In-Reply-To: <200501112010.PAA22052@ietf.org> References: <200501112010.PAA22052@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: 32b73d73e8047ed17386f9799119ce43 Hi David, We are not aware of any violations with the basic functionality of RADIUS/EAP as described in RFC3579 except for key caching which is new functionality. regards, kaushik! At 12:09 PM 1/11/2005, David B Harrington wrote: >Hi, > >I want a solution that can use RADIUS for authentication, since RADIUS >is widely deployed, and a RADIUS solution could utilize >management-policy-id filters, or something comparable, to map to >SNMPv3 access control mechanisms like VACM. It's not the only solution >I want, but one of the solutions I want. > >The SBSM and the TLS proposals can also use RADIUS, but I would like >to avoid solutions that provide yet another layer of indirection >beyond the one provided via the securityModel abstraction. As I worked >on analyzing how a transport layer security model could be implemented >using protocols like TLS, DTLS, and SSH, I found that the available >transport layer solutions seemed to do the same thing - provide a >layer of abstraction to , >and nobody actually ever seemed to solve the problem of providing a >concrete solution, they only pass the buck to another protcol. > >Yes, different communities segments have different needs, and we >should try to make it possible for those different communities to >solve their needs using different solutions/mechanisms, but ultimately >somebody somewhere somehow needs to make a concrete proposal that will >work, and will be administratively consistent with, and equally secure >as, other concrete security solutions that are actually being >deployed. > >I don't want RADIUS to be the only supported solution, since it >obviously doesn't resolve the needs of some segments of the coumminty, >but I would like to see concrete proposals like EUSM that are >consistent with other security solutiions that are being widely >deployed. The TLS security model doesn't meet the "concreteness" goal >since it provides a layer of abstraction to [TLS/DTLS/SSH], which >themselves provide a layer of abstraction to protocol>; EUSM comes close to meeting the "concreteness" criteria by >using a solution that seems fairly consistent with the >802.1X/RADIUS/RFC3580 network access solution. (Of course, the fact >that Bernard Aboba claimms EUSM does things with RADIUS that are >forbidden by the RADIUS protocol doesn't help its case a lot.) > >When the TLS securitymodle, or the SBSM securitymodel, has a concrete >backend specified in a way that can actually be implemented, then I'll >think we're making real progress. > >dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > Sent: Tuesday, January 11, 2005 1:24 PM > > To: ietfdbh@comcast.net > > Cc: 'Martin Soukup'; isms@ietf.org > > Subject: Re: Network management authorization > > > > >>>>> On Tue, 11 Jan 2005 10:53:28 -0500, "David B > > Harrington" said: > > > > David> That's why I personally would like to see the EUSM proposal, >or > > David> something similar, be advanced. > > > > I think what you really mean there is you want the final solution to > > be able to use Radius (like both SBSM and the TLS one was striving > > for, though the details aren't spelled out in either but its in the > > goals)). Or do you mean you want radius to be the only supported > > authentication solution, like EUSM requires? > > > > -- > > 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 Tue Jan 11 17:08: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 RAA09327; Tue, 11 Jan 2005 17:08:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUPq-0002YQ-1W; Tue, 11 Jan 2005 17:23:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoU07-0005Gd-LC; Tue, 11 Jan 2005 16:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTmX-0005eu-85 for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:42: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 QAA06968 for ; Tue, 11 Jan 2005 16:42:27 -0500 (EST) Message-Id: <200501112142.QAA06968@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoU0Q-0001ne-Gy for isms@ietf.org; Tue, 11 Jan 2005 16:56:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011121415601400gha0je>; Tue, 11 Jan 2005 21:41:57 +0000 From: "David B Harrington" To: "'Kaushik Narayan'" Subject: RE: [Isms] RE: Network management authorization Date: Tue, 11 Jan 2005 16:41:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <6.2.0.14.0.20050111125116.04b00f78@mira-sjc5-a.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4JK20jNRSj25ZSt6CyqiiFHDNmQAAaMFA X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7bit I don't recall what Barnard's objections were; you should check with him. dbh > -----Original Message----- > From: Kaushik Narayan [mailto:kaushik@cisco.com] > Sent: Tuesday, January 11, 2005 4:30 PM > To: ietfdbh@comcast.net > Cc: 'Wes Hardaker'; isms@ietf.org > Subject: Re: [Isms] RE: Network management authorization > > Hi David, > > We are not aware of any violations with the basic > functionality of RADIUS/EAP > as described in RFC3579 except for key caching which is new > functionality. > > regards, > kaushik! > > > At 12:09 PM 1/11/2005, David B Harrington wrote: > >Hi, > > > >I want a solution that can use RADIUS for authentication, > since RADIUS > >is widely deployed, and a RADIUS solution could utilize > >management-policy-id filters, or something comparable, to map to > >SNMPv3 access control mechanisms like VACM. It's not the > only solution > >I want, but one of the solutions I want. > > > >The SBSM and the TLS proposals can also use RADIUS, but I would like > >to avoid solutions that provide yet another layer of indirection > >beyond the one provided via the securityModel abstraction. > As I worked > >on analyzing how a transport layer security model could be > implemented > >using protocols like TLS, DTLS, and SSH, I found that the available > >transport layer solutions seemed to do the same thing - provide a > >layer of abstraction to , > >and nobody actually ever seemed to solve the problem of providing a > >concrete solution, they only pass the buck to another protcol. > > > >Yes, different communities segments have different needs, and we > >should try to make it possible for those different communities to > >solve their needs using different solutions/mechanisms, but > ultimately > >somebody somewhere somehow needs to make a concrete proposal > that will > >work, and will be administratively consistent with, and > equally secure > >as, other concrete security solutions that are actually being > >deployed. > > > >I don't want RADIUS to be the only supported solution, since it > >obviously doesn't resolve the needs of some segments of the > coumminty, > >but I would like to see concrete proposals like EUSM that are > >consistent with other security solutiions that are being widely > >deployed. The TLS security model doesn't meet the "concreteness" goal > >since it provides a layer of abstraction to [TLS/DTLS/SSH], which > >themselves provide a layer of abstraction to >protocol>; EUSM comes close to meeting the "concreteness" criteria by > >using a solution that seems fairly consistent with the > >802.1X/RADIUS/RFC3580 network access solution. (Of course, the fact > >that Bernard Aboba claimms EUSM does things with RADIUS that are > >forbidden by the RADIUS protocol doesn't help its case a lot.) > > > >When the TLS securitymodle, or the SBSM securitymodel, has a concrete > >backend specified in a way that can actually be implemented, > then I'll > >think we're making real progress. > > > >dbh > > > > > -----Original Message----- > > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > > Sent: Tuesday, January 11, 2005 1:24 PM > > > To: ietfdbh@comcast.net > > > Cc: 'Martin Soukup'; isms@ietf.org > > > Subject: Re: Network management authorization > > > > > > >>>>> On Tue, 11 Jan 2005 10:53:28 -0500, "David B > > > Harrington" said: > > > > > > David> That's why I personally would like to see the EUSM > proposal, > >or > > > David> something similar, be advanced. > > > > > > I think what you really mean there is you want the final > solution to > > > be able to use Radius (like both SBSM and the TLS one was striving > > > for, though the details aren't spelled out in either but > its in the > > > goals)). Or do you mean you want radius to be the only supported > > > authentication solution, like EUSM requires? > > > > > > -- > > > 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 Tue Jan 11 17:09:57 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 RAA09424; Tue, 11 Jan 2005 17:09:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUQn-0002Zu-A1; Tue, 11 Jan 2005 17:24:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoU0B-0005Jf-4k; Tue, 11 Jan 2005 16:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTnS-00064d-25 for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:43: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 QAA07039 for ; Tue, 11 Jan 2005 16:43:23 -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 1CoU1K-0001qI-B8 for isms@ietf.org; Tue, 11 Jan 2005 16:57:47 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j0BLhKtL013510 for ; Tue, 11 Jan 2005 16:43:20 -0500 (EST) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Tue, 11 Jan 2005 16:43:21 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Tue, 11 Jan 2005 16:43:21 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 11 Jan 2005 16:42:42 -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] Evaluation status [and more] Date: Tue, 11 Jan 2005 16:42:42 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907F@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AAA65k0AAAz+jAAAJLHfA= From: "Nelson, David" To: X-OriginalArrivalTime: 11 Jan 2005 21:42:42.0814 (UTC) FILETIME=[7AEEE9E0:01C4F826] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:51.8443 M:98.9607 P:95.9108 R:95.9108 S:82.6492 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Uri Blumenthal writes... > If by "privacy" you mean USM - I agree. If you mean just the > "confidentiality" feature of USM - then I don't understand. >=20 > And yes - I envision creating dynamic USM entries for sessions, with > appropriate keys computed locally from "session keys" received from > Kerberos or RADIUS (or such). Sorry. I wasn't very clear. What I intended to convey is that one could obtain both confidentiality and authenticity on a message-by-message basis (e.g. using UDP datagrams) without incurring the overhead of per-message authentication (USM, RADIUS, Kerberos, etc.), if the protocol payload contains some form of clear-text session ID bound to the session keys, was encrypted for confidentiality using one session key, and protected by a cryptographic MAC using another session key. The validity of the MAC under the selected (by session ID) session key provides the authenticity. The session lasts for the lifetime of the session keys. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 17:10: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 RAA09504; Tue, 11 Jan 2005 17:10:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoURt-0002bj-Ap; Tue, 11 Jan 2005 17:25:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoU0u-0005hj-5U; Tue, 11 Jan 2005 16:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoTr5-0000A8-75 for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:47: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 QAA07385 for ; Tue, 11 Jan 2005 16:47:09 -0500 (EST) Message-Id: <200501112147.QAA07385@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoU4y-0001w2-Nb for isms@ietf.org; Tue, 11 Jan 2005 17:01:33 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005011121463601300t5hsoe>; Tue, 11 Jan 2005 21:46:36 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] RE: Network management authorization Date: Tue, 11 Jan 2005 16:46:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907E@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4Cr7w/KQRD/w3Rm2zbXmLQGybmwACu4qgAAF6+cAAAsaHIA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: "'Bernard Aboba'" 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi, Bernard made the comment to me over a drink. I'm not sure I understood his concern, and don't recall what it was now. I know he had a concern, and when Bernard raises a concern about how RADIUS is used, I listen (but don't always remember). Hopefully, he can enlighten us. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, January 11, 2005 3:38 PM > To: isms@ietf.org > Subject: RE: [Isms] RE: Network management authorization > > > > (Of course, the fact > > that Bernard Aboba claimms EUSM does things with RADIUS that are > > forbidden by the RADIUS protocol doesn't help its case a lot.) > > I'm not sure I remember that posting. It may well have to do with the > fact that RADIUS is not an authenticated key management > service. There > are IDs proposing to add that kind of service to RADIUS. They are > currently considered out-of-scope of the RADEXT WG, because that WG's > charter explicitly excludes new security methods for RADIUS. > > Having said that, RADIUS, using EAP methods, has been used as the AAA > system behind the authenticated key management system in IEEE 802.11i > wireless LANs. > > There has also been some discussion of changes to RADIUS to > make it FIPS > compliant (whatever that turns out to mean), and the RADEXT charter > might be revised at some point when NIST has given definitive guidance > on this subject, and sufficient progress has been made on WG > deliverables and milestones, to warrant a charter revision. > Too soon to > predict... > > > > _______________________________________________ > 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 Jan 11 17:25: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 RAA10360; Tue, 11 Jan 2005 17:25:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUfx-0002tB-Ki; Tue, 11 Jan 2005 17:39:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUFP-00012E-Bc; Tue, 11 Jan 2005 17:12:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoU2s-0006SF-6p for isms@megatron.ietf.org; Tue, 11 Jan 2005 16:59: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 QAA08556 for ; Tue, 11 Jan 2005 16:59:19 -0500 (EST) Message-Id: <200501112159.QAA08556@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUGk-0002IB-HG for isms@ietf.org; Tue, 11 Jan 2005 17:13:43 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005011121584901500nbkr6e>; Tue, 11 Jan 2005 21:58:49 +0000 From: "David B Harrington" To: "'Nelson, David'" , Subject: RE: [Isms] RE: Network management authorization Date: Tue, 11 Jan 2005 16:58:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1907E@MAANDMBX2.ets.enterasys.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4Cr7w/KQRD/w3Rm2zbXmLQGybmwACu4qgAAF6+cAAAu8IQA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: "'Bernard Aboba'" 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Hi, As I dredge my memory on this point, it may have been the EAP usage Bernard had concerns with. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Nelson, David > Sent: Tuesday, January 11, 2005 3:38 PM > To: isms@ietf.org > Subject: RE: [Isms] RE: Network management authorization > > > > (Of course, the fact > > that Bernard Aboba claimms EUSM does things with RADIUS that are > > forbidden by the RADIUS protocol doesn't help its case a lot.) > > I'm not sure I remember that posting. It may well have to do with the > fact that RADIUS is not an authenticated key management > service. There > are IDs proposing to add that kind of service to RADIUS. They are > currently considered out-of-scope of the RADEXT WG, because that WG's > charter explicitly excludes new security methods for RADIUS. > > Having said that, RADIUS, using EAP methods, has been used as the AAA > system behind the authenticated key management system in IEEE 802.11i > wireless LANs. > > There has also been some discussion of changes to RADIUS to > make it FIPS > compliant (whatever that turns out to mean), and the RADEXT charter > might be revised at some point when NIST has given definitive guidance > on this subject, and sufficient progress has been made on WG > deliverables and milestones, to warrant a charter revision. > Too soon to > predict... > > > > _______________________________________________ > 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 Jan 11 17:26:42 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 RAA10510; Tue, 11 Jan 2005 17:26:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUhE-0002vh-NU; Tue, 11 Jan 2005 17:41:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUFS-00013x-8w; Tue, 11 Jan 2005 17:12:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoU4q-00070J-7L for isms@megatron.ietf.org; Tue, 11 Jan 2005 17:01: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 RAA08717 for ; Tue, 11 Jan 2005 17:01:21 -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 1CoUIj-0002LM-HG for isms@ietf.org; Tue, 11 Jan 2005 17:15:46 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 11 Jan 2005 15:12:58 +0000 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-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0BM0ovl022490; Tue, 11 Jan 2005 14:00:50 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-71-254-121.cisco.com [171.71.254.121]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXE64219; Tue, 11 Jan 2005 14:00:48 -0800 (PST) Message-Id: <6.2.0.14.0.20050111134238.04b20608@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 11 Jan 2005 14:00:46 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: Re: [Isms] Network management authorization In-Reply-To: References: <200501111554.KAA03161@ietf.org> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1158627293==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 --===============1158627293== Content-Type: multipart/alternative; boundary="=====================_17604634==.ALT" --=====================_17604634==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi David, EUSM has already a concrete proposal to complement the SNMPv3 VACM model. EUSM describes the use of the groupName attribute to supply group Names for authenticated users. This will allow VACM to tie the authenticated user to VACM policies locally defined on the agent. I think the management authorization proposal intends to something similar with the Management-Policy-Id attribute to pass down roles/views to managed elements. regards, kaushik! At 12:49 PM 1/11/2005, David T. Perkins wrote: >HI, > >I read ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- >management-authorization-00.txt and see NOTHING about about >the proposal that helps EUSM. I believe that EUSM >wouldn't really support that the proposal that well, but I >would have to carefully re-read the EUSM proposal to come >to a statement of fact. > >On the other hand, SBSM could use the >...radius-management-authorization... >proposal pretty easily. However, Wes and I thought that solving >one part first was a better approach than also working on >authorization modifications. >That part was to design a framework based on lightweight sessions >over UDP that allowed integration with any and all existing endpoint >identity authentication mechanisms. With a session approach, >one can afford the overhead of a once per session retrieving >authorization rules (policy). With SBSM, the security charateristics >of the sessions are better than those in USM. > >I believe that the SBSM approach is lower in cost to develop and >deploy, and then later to extend and deploy by a large margin >over EUSM. > > >On Tue, 11 Jan 2005, David B Harrington wrote: > > Hi, > > > > For those interested in RADIUS authorization for network management > > interfaces, see > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > > management-authorization-00.txt. Dave Nelson and I have been > > discussing this approach for a while. > > > > > > > > One goal is to use it with SNMPv3, using a RADIUS message to > > dynamically define the association between an authenticated security > > principal (vacmSecurityName) and a vacmGroupName. With pre-provisioned > > groups having VACM access control, the RADIUS Management-Policy-ID > > provides the glue between the user authentication and user > > authorization to management information/operations. > > > > While the standardization of VACM makes this pretty straightforward > > for SNMPv3, similar functionality could be used to associate the user > > with proprietary (or TBD) mechanisms that control CLI authorizations, > > web-based mgmt authorizations, and NETCONF authorizations. > > > > The RFC 3580/ IEEE 802.1X/RADIUS approach to network access appears to > > be getting wide deployment, and using a simlar approach for mgmt > > access would seem to be a big win. That's why I personally would like > > to see the EUSM proposal, or something similar, be advanced. > > >Again, I don't see how it follows that EUSM works "better" than >SBSM. Would you explain how you got to this conclusion. > >Regards, >/david t. perkins > > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms --=====================_17604634==.ALT Content-Type: text/html; charset="us-ascii" Hi David,

 EUSM has already a concrete proposal to complement the SNMPv3
VACM model. EUSM describes the use of the groupName attribute to supply
group Names for authenticated users. This will allow VACM to tie the
authenticated user to VACM policies locally defined on the agent.

I think the management authorization proposal intends to something
similar with the 
Management-Policy-Id attribute to pass down
roles/views to managed elements.

regards,
  kaushik!


At 12:49 PM 1/11/2005, David T. Perkins wrote:
HI,

I read ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius -
management-authorization-00.txt and see NOTHING about about
the proposal that helps EUSM. I believe that EUSM
wouldn't really support that the proposal that well, but I
would have to carefully re-read the EUSM proposal to come
to a statement of fact.

On the other hand, SBSM could use the
...radius-management-authorization...
proposal pretty easily. However, Wes and I thought that solving
one part first was a better approach than also working on
authorization modifications.
That part was to design a framework based on lightweight sessions
over UDP that allowed integration with any and all existing endpoint
identity authentication mechanisms. With a session approach,
one can afford the overhead of a once per session retrieving
authorization rules (policy). With SBSM, the security charateristics
of the sessions are better than those in USM.

I believe that the SBSM approach is lower in cost to develop and
deploy, and then later to extend and deploy by a large margin
over EUSM.
 

On Tue, 11 Jan 2005, David B Harrington wrote:
> Hi,
>
> For those interested in RADIUS authorization for network management
> interfaces, see
> ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius -
> management-authorization-00.txt. Dave Nelson and I have been
> discussing this approach for a while.
>
> <stuff cut>
>
> One goal is to use it with SNMPv3, using a RADIUS message to
> dynamically define the association between an authenticated security
> principal (vacmSecurityName) and a vacmGroupName. With pre-provisioned
> groups having VACM access control, the RADIUS Management-Policy-ID
> provides the glue between the user authentication and user
> authorization to management information/operations.
>
> While the standardization of VACM makes this pretty straightforward
> for SNMPv3, similar functionality could be used to associate the user
> with proprietary (or TBD) mechanisms that control CLI authorizations,
> web-based mgmt authorizations, and NETCONF authorizations.
>
> The RFC 3580/ IEEE 802.1X/RADIUS approach to network access appears to
> be getting wide deployment, and using a simlar approach for mgmt
> access would seem to be a big win. That's why I personally would like
> to see the EUSM proposal, or something similar, be advanced.
>
Again, I don't see how it follows that EUSM works "better" than
SBSM. Would you explain how you got to this conclusion.

Regards,
/david t. perkins


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms
--=====================_17604634==.ALT-- --===============1158627293== 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 --===============1158627293==-- From isms-bounces@ietf.org Tue Jan 11 17:37:46 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 RAA11553; Tue, 11 Jan 2005 17:37:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUrz-0003EA-4k; Tue, 11 Jan 2005 17:52:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUVe-0004ID-Cd; Tue, 11 Jan 2005 17:29:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUL2-0002FT-AG for isms@megatron.ietf.org; Tue, 11 Jan 2005 17:18: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 RAA09951 for ; Tue, 11 Jan 2005 17:18:05 -0500 (EST) Received: from pop-a065d01.pas.sa.earthlink.net ([207.217.121.248]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUYv-0002lP-Ji for isms@ietf.org; Tue, 11 Jan 2005 17:32:29 -0500 Received: from h-69-3-25-179.snvacaid.dynamic.covad.net ([69.3.25.179] helo=oemcomputer) by pop-a065d01.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CoUKz-0007j7-00 for isms@ietf.org; Tue, 11 Jan 2005 14:18:05 -0800 Message-ID: <00a101c4f82b$8b4a48c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501112100.QAA28595@ietf.org> Subject: Re: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 14:18:57 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "David B Harrington" > To: "'Nelson, David'" ; > Sent: Tuesday, January 11, 2005 1:00 PM > Subject: RE: [Isms] Evaluation status [and more] ... > I, for one, would like to see us adopt a session-based approach to > supplement the UDP-based approach needed for troubleshooting broken > networks. My preference would be to utilize sessions already provided > by lower-layer protocols, so we can simplify SNMPv3. ... At an implementation level, an SNMP Engine that supports USM already needs something very much like a session internally if it's going to be sending Informs or supporting a command generator application. It needs to remember the SnmpEngineID, boots, and time offsets of its current set of communication partners, and needs to employ some kind of caching strategy to manage memory as the membership of this set changes over time. Making these explicit in protocol and architecture could potentially make things easier to understand. From my perspective, layering user sessions atop these engine-to-engine sessions is a reasonable next step. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 18:02:36 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 SAA13074; Tue, 11 Jan 2005 18:02:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVG0-0003km-W0; Tue, 11 Jan 2005 18:17:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUq5-0001G1-QY; Tue, 11 Jan 2005 17:50:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUj7-0007yB-Q7 for isms@megatron.ietf.org; Tue, 11 Jan 2005 17:43:01 -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 RAA11715 for ; Tue, 11 Jan 2005 17:42:59 -0500 (EST) Message-Id: <200501112242.RAA11715@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoUx1-0003Hv-Nx for isms@ietf.org; Tue, 11 Jan 2005 17:57:24 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005011122422401500nahlse>; Tue, 11 Jan 2005 22:42:24 +0000 From: "David B Harrington" To: "'David T. Perkins'" Subject: RE: [Isms] Network management authorization Date: Tue, 11 Jan 2005 17:42:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4HxaYKPhFqmOpQkumDmzmtBnbQgABOQaQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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: 5d7a7e767f20255fce80fa0b77fb2433 Content-Transfer-Encoding: 7bit Hi Dave, Were you reading the mail I sent? I don't think I said that the radext proposal **helped** EUSM. But I do think EUSM section 3.2 fits especially well with the RADIUS management-policy-id proposal. In EUSM, they refer to a groupname attribute to be used with VACM. In radext, they are looking to standardize an attribute that could contain a groupname that could be used with VACM. The other proposals could use use RADIUS and a management-policy-id attribute as well, but neither discusses doing so. SBSM says working with RADIUS is a goal, but also seems to conclude that working with RADIUS simply won't work - "Several approahces were considered, but none were determined workable." If this is true, how will SBSM utilize a RADIUS management-policy-ID? I don't think I said "EUSM works 'better' than SBSM"; you extrapolated that conclusion. On the other hand, I also did not say that SBSM works better than EUSM. I said I would like to see EUSM, or something similar, advanced. I think EUSM does a better job of integrating with existing infrastructures that are achieving wide deployment, such as those described in RFC 3580 and those used for securing wireless access points. I think the EUSM proposal and the TLS proposal explicitly mention an issue I consider important - the ability to use a common identity across management interfaces, something not mentioned in the SBSM document. So from the standpoint of integrating with existing solutions, I personally favor EUSM or something similar. dbh > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Tuesday, January 11, 2005 3:50 PM > To: David B Harrington > Cc: 'Wes Hardaker'; 'Martin Soukup'; isms@ietf.org > Subject: Re: [Isms] Network management authorization > > HI, > > I read > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > management-authorization-00.txt and see NOTHING about about > the proposal that helps EUSM. I believe that EUSM > wouldn't really support that the proposal that well, but I > would have to carefully re-read the EUSM proposal to come > to a statement of fact. > > On the other hand, SBSM could use the > ...radius-management-authorization... > proposal pretty easily. However, Wes and I thought that solving > one part first was a better approach than also working on > authorization modifications. > That part was to design a framework based on lightweight sessions > over UDP that allowed integration with any and all existing endpoint > identity authentication mechanisms. With a session approach, > one can afford the overhead of a once per session retrieving > authorization rules (policy). With SBSM, the security charateristics > of the sessions are better than those in USM. > > I believe that the SBSM approach is lower in cost to develop and > deploy, and then later to extend and deploy by a large margin > over EUSM. > > > On Tue, 11 Jan 2005, David B Harrington wrote: > > Hi, > > > > For those interested in RADIUS authorization for network management > > interfaces, see > > > ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-nelson-radius- > > management-authorization-00.txt. Dave Nelson and I have been > > discussing this approach for a while. > > > > > > > > One goal is to use it with SNMPv3, using a RADIUS message to > > dynamically define the association between an authenticated security > > principal (vacmSecurityName) and a vacmGroupName. With > pre-provisioned > > groups having VACM access control, the RADIUS Management-Policy-ID > > provides the glue between the user authentication and user > > authorization to management information/operations. > > > > While the standardization of VACM makes this pretty straightforward > > for SNMPv3, similar functionality could be used to > associate the user > > with proprietary (or TBD) mechanisms that control CLI > authorizations, > > web-based mgmt authorizations, and NETCONF authorizations. > > > > The RFC 3580/ IEEE 802.1X/RADIUS approach to network access > appears to > > be getting wide deployment, and using a simlar approach for mgmt > > access would seem to be a big win. That's why I personally > would like > > to see the EUSM proposal, or something similar, be advanced. > > > Again, I don't see how it follows that EUSM works "better" than > SBSM. Would you explain how you got to this conclusion. > > Regards, > /david t. perkins > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 18:24: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 SAA15941; Tue, 11 Jan 2005 18:24:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVb0-0004Gz-23; Tue, 11 Jan 2005 18:38:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoV8M-0007s3-K6; Tue, 11 Jan 2005 18:09:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUxB-00028W-D8 for isms@megatron.ietf.org; Tue, 11 Jan 2005 17:57: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 RAA12719 for ; Tue, 11 Jan 2005 17:57:30 -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 1CoVB2-0003dn-Fx for isms@ietf.org; Tue, 11 Jan 2005 18:11:55 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id C63BD11D825; Tue, 11 Jan 2005 14:57:25 -0800 (PST) From: Wes Hardaker To: Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501112239.j0BMdDh7006391@nutshell.tislabs.com> Date: Tue, 11 Jan 2005 14:57:25 -0800 In-Reply-To: <200501112239.j0BMdDh7006391@nutshell.tislabs.com> (David B. Harrington's message of "Tue, 11 Jan 2005 17:42:20 -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: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d >>>>> On Tue, 11 Jan 2005 17:42:20 -0500, "David B Harrington" said: David> The other proposals could use use RADIUS and a David> management-policy-id attribute as well, but neither discusses David> doing so. SBSM says working with RADIUS is a goal, but also David> seems to conclude that working with RADIUS simply won't work - David> "Several approahces were considered, but none were determined David> workable." Ok, I've been too busy to respond to the rest of the comments today. But this one just irked me since you tied two totally different sections together by pulling a sentence from a later unrelated section and some how applied it to the authentication section. Specifically, you're pulling text from the history section, in particular from David's recanting of his past history about thinking about the problem. In particular, in that section he was describing how he thought about tying something directly to Radius but in the end didn't think it would be usable. In short, SBSM as is (without modification) can be tied to radius now. The authentication systems in the back aren't complete for various reasons, as the draft states and as I stated previously this week, but the local authentication mechanism that is defined there today passes the information needed to the agent for the agent to do a radius exchange. This exchange could, but doesn't have to, lead to bootstrapping of the VACM via similar mechanisms as the other drafts discuss. It's not mentioned within the SBSM document directly because it's out of scope of the working group, but maybe I should have put a note in saying that it in no way impedes progress in any VACM centralization scheme. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 18:33: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 SAA16540; Tue, 11 Jan 2005 18:33:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVjs-0004S6-GT; Tue, 11 Jan 2005 18:47:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVOG-00085G-LR; Tue, 11 Jan 2005 18:25:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoV9n-0000FP-5n for isms@megatron.ietf.org; Tue, 11 Jan 2005 18:10: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 SAA14457 for ; Tue, 11 Jan 2005 18:10: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 1CoVNh-0003xl-9V for isms@ietf.org; Tue, 11 Jan 2005 18:24:57 -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 PAA01512; Tue, 11 Jan 2005 15:09: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 j0BN9wP14734; Tue, 11 Jan 2005 15:09:58 -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.0); Tue, 11 Jan 2005 15:09:42 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 15:09:41 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDB21@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AAA65k0AAA8cNgAAVtX8A= From: "Fleischman, Eric" To: , "Nelson, David" , X-OriginalArrivalTime: 11 Jan 2005 23:09:42.0017 (UTC) FILETIME=[A1D21710:01C4F832] 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 David's comments below reflect my own beliefs concerning the importance = of supporting SNMP session security. -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Tuesday, January 11, 2005 1:00 PM To: 'Nelson, David'; isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] Hi, I would phrase the requirement slightly differently. I do not believe that "in order=A0to cleanly integrate with any of the = existing infrastructures, SNMP needs to define and embrace the concept = of a=A0session.", but rather if SNMP embraced the concept of a session, = it would have a much much larger selection of existing infrastructures = with which to integrate. If we adopt a third-party-authenticated session, we still need to have a = fallback to a UDP-based trasnport and limited local authentication for = troubleshooting a broken network. I think the benefits of a session approach are numerous: If we adopt a secured-transport session, we may not have to provide = message authentication, integrity, and timeliness in the SNMP engine. If = we adopt a secured-transport session, we might send multiple SNMP = messages within the same session, to minimize the overhead. If we adopt = a secured-transport session, we might make this host-to-host, which is = similar to the way many operators "authenticate" SNMPv1 messages.=20 If we adopt a secured-transport session with host-level authentication, = we might make user-authentication part of the authorization stage, so we = don't have to pass the security principal from the transport layer to = the application layer. If we adopt a secured-transport session, we might = be able to transport the simpler SNMPv1 or SNMPv2c message formats = securely. If we adopt a stream-based transport session, we might send much larger = messages, improving SNMP's efficiency for table retrieval. If we adopt a = stream-based transport session, that would make SNMP much more = consistent with other management interfaces, like CLI/SSH and NETCONF. = If we adopt a stream-based transport session, we could more easily = utilize an XML-based data description approach, and move away from = ASN.1. I, for one, would like to see us adopt a session-based approach to = supplement the UDP-based approach needed for troubleshooting broken = networks. My preference would be to utilize sessions already provided by = lower-layer protocols, so we can simplify SNMPv3. 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 Jan 11 19:17: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 TAA19359; Tue, 11 Jan 2005 19:17:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWQQ-0005Hh-UB; Tue, 11 Jan 2005 19:31:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVzq-0006NH-N9; Tue, 11 Jan 2005 19:04:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoVrs-0004to-OY for isms@megatron.ietf.org; Tue, 11 Jan 2005 18:56: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 SAA17726 for ; Tue, 11 Jan 2005 18:56:05 -0500 (EST) Message-Id: <200501112356.SAA17726@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoW5k-0004pl-3V for isms@ietf.org; Tue, 11 Jan 2005 19:10:31 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005011123553301300stltoe>; Tue, 11 Jan 2005 23:55:33 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Subject: RE: [Isms] Network management authorization Date: Tue, 11 Jan 2005 18:55:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT4MOzoRc0mo7R2SeegeJQCciHv7gABCqwg X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit Hi Wes, Sorry to irk you. I was responding largely to david's misquotes of what I had said, and to his claim that "On the other hand, SBSM could use the ...radius-management-authorization... proposal pretty easily." I searched the SBSM proposal to see how it supported RADIUS and could utilize the RADIUS-specific management-policy-id attribute, but didn't see how it would do so pretty easily. I see now that I misread the Goals and Objectives section - I missed the "... met by this protocol include" sentence, much as you missed Eric's "ascending importance" sentence, so it wasn't clear that a workable solution for RADIUS had been found. The SBSM proposal does not describe how it can support RADIUS at this point, so I had difficulty understanding how it would use the RADIUS management-policy-ID proposal pretty easily. I apologize for my confusion. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Tuesday, January 11, 2005 5:57 PM > To: ietfdbh@comcast.net > Cc: 'David T. Perkins'; 'Martin Soukup'; isms@ietf.org > Subject: Re: [Isms] Network management authorization > > >>>>> On Tue, 11 Jan 2005 17:42:20 -0500, "David B > Harrington" said: > > David> The other proposals could use use RADIUS and a > David> management-policy-id attribute as well, but neither discusses > David> doing so. SBSM says working with RADIUS is a goal, but also > David> seems to conclude that working with RADIUS simply won't work - > David> "Several approahces were considered, but none were determined > David> workable." > > Ok, I've been too busy to respond to the rest of the comments today. > But this one just irked me since you tied two totally different > sections together by pulling a sentence from a later unrelated section > and some how applied it to the authentication section. Specifically, > you're pulling text from the history section, in particular from > David's recanting of his past history about thinking about the > problem. In particular, in that section he was describing how he > thought about tying something directly to Radius but in the end didn't > think it would be usable. > > In short, SBSM as is (without modification) can be tied to radius now. > The authentication systems in the back aren't complete for various > reasons, as the draft states and as I stated previously this week, but > the local authentication mechanism that is defined there today passes > the information needed to the agent for the agent to do a radius > exchange. This exchange could, but doesn't have to, lead to > bootstrapping of the VACM via similar mechanisms as the other drafts > discuss. It's not mentioned within the SBSM document directly because > it's out of scope of the working group, but maybe I should have put a > note in saying that it in no way impedes progress in any VACM > centralization scheme. > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 19:44: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 TAA21159; Tue, 11 Jan 2005 19:44:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWqf-0005vk-Oa; Tue, 11 Jan 2005 19:58:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWQu-0004np-Gj; Tue, 11 Jan 2005 19:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWGK-0002CF-FI for isms@megatron.ietf.org; Tue, 11 Jan 2005 19:21: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 TAA19796 for ; Tue, 11 Jan 2005 19:21:21 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWU5-0005OC-2s for isms@ietf.org; Tue, 11 Jan 2005 19:35:47 -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 j0C0KfZY025697; Tue, 11 Jan 2005 16:20:41 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0C0Kh2F016717; Tue, 11 Jan 2005 16:20:43 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0C0KhYG016708; Tue, 11 Jan 2005 16:20:43 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 11 Jan 2005 16:20:43 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: RE: [Isms] Network management authorization In-Reply-To: <200501112355.j0BNtYZ2014455@mx1.bayarea.net> 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, DBH - I think "misquote" is a little too strong! The facts are the following: 1) SBSM can use radius (and all other authentication mechanisms that Wes and I have looked at). 2) SBSM is an umbrella approach based on light weight sessions, which can be used over a UDP or TCP transport. (NOTE: a session does not imply use of TCP.) 3) SBSM sessions have better security properties than USM 4) Authorization is out of scope of the ISMS WG. However, there are several approaches that can be supported by SBSM to make deployment and ongoing use of SNMP easier. The most obvious is to not use table vacmSecurityToGroupTable, and instead get the group using the mechanism used for authentication (such as from a Radius server). Regards, /david t. perkins On Tue, 11 Jan 2005, David B Harrington wrote: > Hi Wes, > > Sorry to irk you. > > I was responding largely to david's misquotes of what I had said, and > to his claim that "On the other hand, SBSM could use the > ...radius-management-authorization... proposal pretty easily." > > I searched the SBSM proposal to see how it supported RADIUS and could > utilize the RADIUS-specific management-policy-id attribute, but didn't > see how it would do so pretty easily. I see now that I misread the > Goals and Objectives section - I missed the "... met by this protocol > include" sentence, much as you missed Eric's "ascending importance" > sentence, so it wasn't clear that a workable solution for RADIUS had > been found. The SBSM proposal does not describe how it can support > RADIUS at this point, so I had difficulty understanding how it would > use the RADIUS management-policy-ID proposal pretty easily. > > I apologize for my confusion. > > dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > Sent: Tuesday, January 11, 2005 5:57 PM > > To: ietfdbh@comcast.net > > Cc: 'David T. Perkins'; 'Martin Soukup'; isms@ietf.org > > Subject: Re: [Isms] Network management authorization > > > > >>>>> On Tue, 11 Jan 2005 17:42:20 -0500, "David B > > Harrington" said: > > > > David> The other proposals could use use RADIUS and a > > David> management-policy-id attribute as well, but neither discusses > > David> doing so. SBSM says working with RADIUS is a goal, but also > > David> seems to conclude that working with RADIUS simply won't work > - > > David> "Several approahces were considered, but none were determined > > David> workable." > > > > Ok, I've been too busy to respond to the rest of the comments today. > > But this one just irked me since you tied two totally different > > sections together by pulling a sentence from a later unrelated > section > > and some how applied it to the authentication section. > Specifically, > > you're pulling text from the history section, in particular from > > David's recanting of his past history about thinking about the > > problem. In particular, in that section he was describing how he > > thought about tying something directly to Radius but in the end > didn't > > think it would be usable. > > > > In short, SBSM as is (without modification) can be tied to radius > now. > > The authentication systems in the back aren't complete for various > > reasons, as the draft states and as I stated previously this week, > but > > the local authentication mechanism that is defined there today > passes > > the information needed to the agent for the agent to do a radius > > exchange. This exchange could, but doesn't have to, lead to > > bootstrapping of the VACM via similar mechanisms as the other drafts > > discuss. It's not mentioned within the SBSM document directly > because > > it's out of scope of the working group, but maybe I should have put > a > > note in saying that it in no way impedes progress in any VACM > > centralization scheme. > > > > -- > > Wes Hardaker > > Sparta > > > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 19:58:42 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 TAA22259; Tue, 11 Jan 2005 19:58:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoX4O-0006DX-E3; Tue, 11 Jan 2005 20:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWhV-0008Q5-EY; Tue, 11 Jan 2005 19:49:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoWVb-0005y2-E9 for isms@megatron.ietf.org; Tue, 11 Jan 2005 19:37: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 TAA20802 for ; Tue, 11 Jan 2005 19:37:08 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoWjT-0005mP-5T for isms@ietf.org; Tue, 11 Jan 2005 19:51:34 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0C0Z4Fe020820 for ; Tue, 11 Jan 2005 19:35:04 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j0C0Z1Fe020747 for ; Tue, 11 Jan 2005 19:35:02 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Isms] Evaluation status [and more] MIME-Version: 1.0 Date: Wed, 12 Jan 2005 02:37:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Message-ID: Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AADTAXIA== From: "Romascanu, Dan \(Dan\)" To: "Blumenthal, Uri" , "Fleischman, Eric" X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0917429966==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 This is a multi-part message in MIME format. --===============0917429966== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F83E.D58A23FC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F83E.D58A23FC Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 I would agree if you change 'any' by 'many'=20 =20 Regards, Dan =20 =20 I want to poll the group: do you agree that in order to cleanly = integrate with any of the eisting infrastructures, SNMP needs to define = and emprace the concept of a session. If there's agreement - I'll finish = my write-up and submit it. [If not - I've other interesting things to do = :-] =20 =20 ------_=_NextPart_001_01C4F83E.D58A23FC Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
 
I would agree if you change 'any' by 'many'=20
 
Regards,

Dan

 
 
I want to poll the group: do you agree = that in=20 order to cleanly integrate with any of the eisting=20 infrastructures, SNMP needs to define and emprace the concept of=20 a session. If there's agreement - I'll finish my write-up = and=20 submit it. [If not - I've other interesting things to do=20 :-]
 
 
------_=_NextPart_001_01C4F83E.D58A23FC-- --===============0917429966== 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 --===============0917429966==-- From isms-bounces@ietf.org Tue Jan 11 20:40:45 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 UAA25015; Tue, 11 Jan 2005 20:40:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXj4-00075L-5M; Tue, 11 Jan 2005 20:55:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXMN-0007rU-2i; Tue, 11 Jan 2005 20:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoX9s-0005af-DE for isms@megatron.ietf.org; Tue, 11 Jan 2005 20:18: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 UAA23378 for ; Tue, 11 Jan 2005 20:18:46 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXNj-0006ao-NW for isms@ietf.org; Tue, 11 Jan 2005 20:33:11 -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 TAA29641; Tue, 11 Jan 2005 19:18:07 -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 j0C1I5s00269; Tue, 11 Jan 2005 19:18:05 -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.0); Tue, 11 Jan 2005 17:17:50 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 11 Jan 2005 17:17:49 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDB22@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcT35xMjlowc2xhaQNqn302OqrmxUgAGl/IgAAIXJ0AACjeHsA== From: "Fleischman, Eric" To: "Blumenthal, Uri" X-OriginalArrivalTime: 12 Jan 2005 01:17:50.0399 (UTC) FILETIME=[887414F0:01C4F844] X-Spam-Score: 0.9 (/) X-Scan-Signature: 3bef755d9f4ba0b7ac474570b36ffadb Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2001486359==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: dabfd8cc2c196ec56401c44f64d155c2 This is a multi-part message in MIME format. --===============2001486359== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4F844.87F1A8B4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4F844.87F1A8B4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Well, Uri, you certainly popped my balloon. Here I was thinking that perhaps this is among my best postings, and your email was certainly not the response I was expecting. =20 I will try to answer your questions (or objections) by embedding my own text below. Should my explanations not resonate with you, then perhaps we can discuss these issues at the next IETF, assuming that I will be funded to attend it? -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Tuesday, January 11, 2005 11:47 AM To: Fleischman, Eric Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] =09 =09 =20 So what will make this WG more successful? I believe that clearly articulating the goals, concerns and issues of the various communities that comprise us is a "path forward" to completing our task well since it would provide a clearly stated evaluation rationale for us all.=20 =20 Uri> We're in agreement here. =20 My issues are the following: I have concluded that the SNMPv3 USM is currently operationally insecure=20 =20 Uri> I resent this comment and find it unfounded and unjustified. =20 Eric> I am very sorry to cause you resentment. That certainly wasn't my intention. Large operations, which due to their size and large number of different device types, need to orchestrate the products of multiple SNMP vendors. SNMP does not make this easy if one is trying to do this securely. Rather, such environments are confronted by a lack of a coherent SNMP infrastructure to enable a viable multi-vendor deployment without having to do onerous investments (or onerous human management tasks) on their own in order to perform fundamentally tasks things like symmetric key distribution. This is an awfully lot of needless expense when we have already deployed authentication systems deployment wide such as PKI, Kerberos, or RADIUS. Such problems probably don't occur for single vendor implementations though such environments are outside of my experience. Unless one has total control of the SNMP system end-to-end today it is simply not possible to deploy a viably secure SNMP deployment (e.g., if one is controlling SNMP clients but not SNMP management systems). The current approach is therefore not modular nor scalable nor demonstrably secure. Rather, there is lots of evidence to question whether it is securable at all. =09 .... and far too many SNMPv3 products are prohibitively difficult to deploy securely today (i.e., a "hack me here" technology and far too often the weakest point in a deployment).=20 =20 Uri> And why is that?=20 Eric> The default privacy key durations are dangerously long. The establishment mechanism for distributing authentication keys is operationally difficult in some single vendor and most multi-vendor environments. SNMP MIBs by default often provide invaluable aids for hacking and cracking devices. These default MIBs need to be really tightened down if they are not actively undercut the security of that platform or environment. One must rely on non-SNMP mechanisms (e.g., IPTables, IPSec, SSH) to supplement the USM provisions in order to protect the devices' SNMP agents from a wide variety of cracking attempts. This is more troubling when one has fundamental doubts about the very viability of privacy and authentication keys due to the lack of PFS or the presence of password-derived keys. In shared business environments, how can we ensure that our business partner has kept their keys secure such that Joe cracker isn't spoofing them to us? I could go on and on but the point I am trying to make isn't that the USM security is technically flawed theoretically because such a point would probably be false. It is rather that the environment in which USM is deployed is such that it is really, really tough to deploy devices supporting USM in an operationally secure manner and, even if one has, one has no way to verify that one has. Also, the USM is very poorly designed for supporting many emerging modern business requirements, particularly those that are affiliated with increasingly porous corporate perimeter boundaries. We buy products and I am constrained by what vendors create. It is an expensive and time consuming game to do what Wes is suggesting on the list for us do (i.e., for us to demand that vendors change their products or else we won't buy them).=20 =20 Uri> You have your needs, other have theirs - that don't match yours. So convince vendors that it's your needs that should be addressed. There is no other acceptable way - to create a special standard just so that your needs (rather than theirs) are addressed, seems too gross.=20 Eric> Because I don't expect non-end users to sympathize or value the problems of end users (especially in the IETF where end users have such a tiny voice), I am uncertain how to respond to you on this point. I don't think it would be helpful to refer to the many other end users or certification authorities who have made similar conclusions as I about SNMPv3. You probably wouldn't agree with me that these issues are indirectly reflected by a diminishing SNMP mind-share worldwide. That is, if you concur at all that the SNMP mind share is diminishing, you probably believe that it is being caused by other factors (e.g., the desirability of using XML structures instead of MIBs/PIBs). I guess I can only say that a growing number of us end users are feeling like me, which is why I argued so often for the creation of the ISMS working group. That is, I wanted the IETF to create ISMS because I believe that the best way to make SNMP's security become operationally viable is to create a common multi-vendor security solution for SNMP that is operationally viable. Because a fundamental problem with SNMP security is in multi-vendor deployments, pounding on vendors individually is not a promising mechanism to fix problems which aren't caused by the vendors themselves. Rather, I believe that the solution is to create a viable alternative to -- or a supplement for -- the current USM within the IETF. I believe that vendors will be encouraged to deploy a more secure version of SNMP once such an alternative exists for their customers to request. =20 We've done that in the past and it is very costly to behave in that way -- and there are many more issues to consider in buying products than security.=20 =20 Uri> If only very few customers require what you need - obviously the "customized" solution will cost money. What else is news? =20 Therefore, to me, this WG will be successful if it results in interoperable SNMP products that leverage one or more of our current Authentication infrastructures in a manner that is operationally secure. =20 Uri> 1. This WG can result only in proposals later-to-become-standards, not products. 2. All of the submitted proposals leverage one or more of the current Authentication infrastructures. So this WG will be successful even if we just toss a coin to choose one.=20 Eric> Proposals that become standards is what I am after. Once a viable standard exists, then viable interoperable products may be devised. My goal is products but the path to that is first a proposal and then a standard. =20 I don't know if your second point is true or not. It may be. Certainly I concur with you that most -- perhaps even all of them, as you state, though I haven't concluded this yet myself -- of the alternatives materially improve SNMP security and thus are very positive steps forward. However, some alternatives seem to me to be more flexible than others. Flexibility is good. Also, some seem to have many provisions, and others have only a few. If "many" doesn't translate into "needless complexity", then "many" is good. If it does, then it isn't. I want the specification to compel default behaviors that are secure, rather than the current situation.=20 =20 Uri> "Secure" for you is "overboard" for most of other users. Why should the default favor you and not them? Eric> My use of the word "default" was concerning the defaults within the protocol itself. I am arguing for approaches that are inherently secure, rather than approaches which require convolutions on the part of the end user to make them become secure.=20 =20 --Eric ------_=_NextPart_001_01C4F844.87F1A8B4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
Well,=20 Uri, you certainly popped my balloon. Here I was thinking that perhaps = this is=20 among my best postings, and your email was certainly not the response I = was=20 expecting.
 
I will=20 try to answer your questions (or objections) by embedding my own text = below.=20 Should my explanations not resonate with you, then perhaps we can = discuss these=20 issues at the next IETF, assuming that I will be funded to attend=20 it?
-----Original Message-----
From: = Blumenthal, Uri=20 [mailto:uri.blumenthal@intel.com]
Sent: Tuesday, January = 11, 2005=20 11:47 AM
To: Fleischman, Eric
Cc:=20 isms@ietf.org
Subject: RE: [Isms] Evaluation status [and=20 more]

 <snip> <= SPAN=20 class=3D004381717-11012005>
So what will make this WG more successful? I believe that = clearly=20 articulating the goals, concerns and issues of the various communities = that=20 comprise us is a "path forward" to completing our task well since it = would=20 provide a clearly stated evaluation rationale for us all. 
 
Uri> We're in=20 agreement here.
 
My issues are the following: I have concluded that the SNMPv3 USM is = currently=20 operationally insecure 
 
Uri> I resent this comment and = find it=20 unfounded and unjustified.  
Eric> I am very=20 sorry to cause you resentment. That certainly wasn't my intention. Large = operations, which due to their size and large number of different device = types,=20 need to orchestrate the products of multiple SNMP vendors. SNMP does not = make=20 this easy if one is trying to do this securely. Rather, such = environments are=20 confronted by a lack of a coherent SNMP infrastructure to enable a=20 viable multi-vendor deployment without having to do onerous = investments (or=20 onerous human management tasks) on their own in order to perform=20 fundamentally tasks things like symmetric key distribution. This is = an=20 awfully lot of needless expense when we have already deployed = authentication=20 systems deployment wide such as PKI, Kerberos, or RADIUS. Such problems = probably=20 don't occur for single vendor implementations though such environments = are=20 outside of my experience. Unless one has total control of = the SNMP=20 system end-to-end today it is simply not possible to deploy a = viably=20 secure SNMP deployment (e.g., if one is controlling SNMP clients but not = SNMP=20 management systems). The current approach is therefore not modular nor = scalable=20 nor demonstrably secure. Rather, there is lots of evidence to question = whether=20 it is securable at all.
.... and far too many SNMPv3 = products are=20 prohibitively difficult to deploy securely today (i.e., a "hack me = here"=20 technology and far too often the weakest point in a deployment). 
 
Uri> And why is that? 
Eric> The=20 default privacy key durations are dangerously long. The = establishment=20 mechanism for distributing authentication keys is operationally = difficult=20 in some single vendor and most = multi-vendor=20 environments. SNMP MIBs by default often provide invaluable aids for = hacking and=20 cracking devices. These default MIBs need to be really tightened down if = they=20 are not actively undercut the security of that platform or = environment. One=20 must rely on non-SNMP mechanisms (e.g., IPTables, IPSec, SSH) to = supplement the=20 USM provisions in order to protect the devices' SNMP agents from a wide = variety=20 of cracking attempts. This is more troubling when one has fundamental = doubts=20 about the very viability of privacy and authentication keys due to the = lack of=20 PFS or the presence of password-derived keys. In shared business = environments,=20 how can we ensure that our business partner has kept their keys secure = such that=20 Joe cracker isn't spoofing them to us? I could go on and on but the = point I am=20 trying to make isn't that the USM security is technically flawed = theoretically=20 because such a point would probably be false. It is rather that the = environment=20 in which USM is deployed is such that it is really, really tough to = deploy=20 devices supporting USM in an operationally secure manner and, even if = one has,=20 one has no way to verify that one has. Also, the USM is very poorly = designed for=20 supporting many emerging modern business requirements, particularly = those that=20 are affiliated with increasingly porous corporate perimeter=20 boundaries.
We=20 buy products and I am constrained by what vendors create. It is an = expensive=20 and time consuming game to do what Wes is suggesting on the list for = us do=20 (i.e., for us to demand that vendors change their products or else we = won't=20 buy them). 
 
Uri> You have your needs, other = have=20 theirs - that don't match yours. So convince vendors that it's = your needs=20 that should be addressed. There is no other acceptable way - to = create a=20 special standard just so that your needs (rather than theirs) are = addressed,=20 seems too gross. 
Eric>  Because I don't = expect non-end=20 users to sympathize or value the problems of end users (especially in = the IETF=20 where end users have such a tiny voice), I am uncertain how to respond = to you=20 on this point. I=20 don't think it would be helpful to refer to the many other end users or=20 certification authorities who have made similar conclusions as I about = SNMPv3.=20 You probably wouldn't agree with me that these issues are = indirectly=20 reflected by a diminishing SNMP mind-share worldwide. That is, if = you=20 concur at all that the SNMP mind share is diminishing, you probably = believe that=20 it is being caused by other factors (e.g., the desirability of = using XML=20 structures instead of MIBs/PIBs). I guess I can only say that a = growing=20 number of us end users are feeling like me, which is why I argued so = often for=20 the creation of the ISMS working group. That is, I wanted the IETF to = create=20 ISMS because I believe that the best way to make SNMP's=20 security become operationally viable is to create a common = multi-vendor=20 security solution for SNMP that is operationally viable. Because a = fundamental=20 problem with SNMP security is in multi-vendor deployments, pounding on = vendors=20 individually is not a promising mechanism to fix problems which aren't = caused by=20 the vendors themselves. Rather, I believe that the solution is to create = a=20 viable alternative to -- or a supplement for -- the current USM within = the IETF.=20 I believe that vendors will be encouraged to deploy a more secure = version of=20 SNMP once such an alternative exists for their customers to=20 request.
 
 We've=20 done that in the past and it is very costly to behave in that way -- = and there=20 are many more issues to consider in buying products than = security. 
 
Uri> If only very few customers=20 require what you need - obviously the "customized" solution will = cost=20 money. What else is=20 news?
 
Therefore, = to=20 me,  this WG will be successful if it results in = interoperable SNMP=20 products that leverage one or more of our current Authentication=20 infrastructures in a manner that is operationally secure. 
 
Uri> 1. This WG can result = only in=20 proposals later-to-become-standards, not products. 2. All of the = submitted=20 proposals leverage one or more of the current Authentication = infrastructures.=20 So this WG will be successful even if we just toss a coin = to choose=20 one. 
Eric> Proposals=20 that become standards is what I am after. Once a viable standard exists, = then=20 viable interoperable products may be devised. My goal is products but = the path=20 to that is first a proposal and then a=20 standard.
&n= bsp;
I don't = know if your=20 second point is true or not. It may be. Certainly I concur with you that = most --=20 perhaps even all of them, as you state, though I haven't concluded this = yet=20 myself -- of the alternatives materially improve SNMP security = and=20 thus are very positive steps forward. However, some alternatives seem to = me to=20 be more flexible than others. Flexibility is good. Also, some seem to = have many=20 provisions, and others have only a few. If "many" doesn't translate into = "needless complexity", then "many" is good. If it does, then it=20 isn't.
  I want the = specification to=20 compel default behaviors that are secure, rather than the current=20 situation. 
 
Uri> "Secure"=20 for you is "overboard" for most of other users. Why should the default = favor=20 you and not = them?
Eric> = My use of=20 the word "default" was concerning the defaults within the protocol = itself. I am=20 arguing for approaches that are inherently secure, rather than = approaches which=20 require convolutions on the part of the end user to make them become = secure.=20
 
--Eric ------_=_NextPart_001_01C4F844.87F1A8B4-- --===============2001486359== 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 --===============2001486359==-- From isms-bounces@ietf.org Tue Jan 11 20:56:12 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 UAA26312; Tue, 11 Jan 2005 20:56:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXy1-0007UV-Bl; Tue, 11 Jan 2005 21:10:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXee-00039I-9r; Tue, 11 Jan 2005 20:50:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXUC-00018v-8n for isms@megatron.ietf.org; Tue, 11 Jan 2005 20:39: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 UAA24927 for ; Tue, 11 Jan 2005 20:39:45 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXi6-000730-0W for isms@ietf.org; Tue, 11 Jan 2005 20:54:11 -0500 Received: from h-68-165-170-21.snvacaid.dynamic.covad.net ([68.165.170.21] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CoXU8-0004TG-00 for isms@ietf.org; Tue, 11 Jan 2005 17:39:44 -0800 Message-ID: <002f01c4f847$ab0f7560$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] Network management authorization Date: Tue, 11 Jan 2005 17:40:16 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Hi - > From: "David T. Perkins" > To: "David B Harrington" > Cc: > Sent: Tuesday, January 11, 2005 4:20 PM > Subject: RE: [Isms] Network management authorization ... > 1) SBSM can use radius (and all other authentication > mechanisms that Wes and I have looked at). It would have helped if it had actually spelled out the details of how this would work for one of these mechanisms, rather than just asserting it. ... > 4) Authorization is out of scope of the ISMS WG. However, > there are several approaches that can be supported > by SBSM to make deployment and ongoing use of SNMP > easier. The most obvious is to not use table > vacmSecurityToGroupTable, and instead get the > group using the mechanism used for authentication > (such as from a Radius server). ... It may be out of scope, but I think failing to address this issue would be a big mistake. If no mechanism (like the one suggested) is provided, the the "integration" won't work until the security administrator uses SNMPv3 to configure the vacmSecurityToGroupTable, either manually or using something like the dead MIASMA proposal. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 11 21:02: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 VAA26831; Tue, 11 Jan 2005 21:02:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoY3s-0007dH-AG; Tue, 11 Jan 2005 21:16:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXhl-0003vs-V8; Tue, 11 Jan 2005 20:53:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoXb7-0002Y2-68 for isms@megatron.ietf.org; Tue, 11 Jan 2005 20:46:58 -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 UAA25516 for ; Tue, 11 Jan 2005 20:46:52 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoXp0-0007GW-6O for isms@ietf.org; Tue, 11 Jan 2005 21:01:18 -0500 Received: from h-68-165-170-21.snvacaid.dynamic.covad.net ([68.165.170.21] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CoXb2-0006kT-00 for isms@ietf.org; Tue, 11 Jan 2005 17:46:53 -0800 Message-ID: <003f01c4f848$aa41f6c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501112239.j0BMdDh7006391@nutshell.tislabs.com> Subject: Re: [Isms] Network management authorization Date: Tue, 11 Jan 2005 17:46:25 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi - > From: "Wes Hardaker" > To: > Cc: > Sent: Tuesday, January 11, 2005 2:57 PM > Subject: Re: [Isms] Network management authorization ... > In short, SBSM as is (without modification) can be tied to radius now. This wasn't clear to me from the i-d. Thanks for spelling it out. > The authentication systems in the back aren't complete for various > reasons, as the draft states and as I stated previously this week, but > the local authentication mechanism that is defined there today passes > the information needed to the agent for the agent to do a radius > exchange. This exchange could, but doesn't have to, lead to > bootstrapping of the VACM via similar mechanisms as the other drafts > discuss. It's not mentioned within the SBSM document directly because > it's out of scope of the working group, but maybe I should have put a > note in saying that it in no way impedes progress in any VACM > centralization scheme. ... I don't think it's necessary to go so far as a "VACM centralization scheme." This bit that *is* important to address in integrating with external authentication systems is the mapping of users to groups. Although that is modeled in VACM, it can also be considered part of user management. Failing to address it would be a grave mistake for the WG, IMO. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 10:11: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 KAA19739; Wed, 12 Jan 2005 10:11:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokOD-00080Z-44; Wed, 12 Jan 2005 10:26:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cojzt-0004b5-Rn; Wed, 12 Jan 2005 10:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoUyg-0002SV-EN for isms@megatron.ietf.org; Tue, 11 Jan 2005 17:59: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 RAA12778 for ; Tue, 11 Jan 2005 17:59:03 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVCa-0003fp-I7 for isms@ietf.org; Tue, 11 Jan 2005 18:13:28 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CoUya-000BQv-U5; Tue, 11 Jan 2005 17:59:01 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j0BMwtw30958; Tue, 11 Jan 2005 14:58:55 -0800 Date: Tue, 11 Jan 2005 14:58:55 -0800 (PST) From: Bernard Aboba To: ietfdbh@comcast.net Subject: RE: [Isms] RE: Network management authorization Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Wed, 12 Jan 2005 10:01:21 -0500 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.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 There a number of ways that EAP could be used to secure SNMP, and they have somewhat different implications: a. EAP packets could be encapsulated within SNMP itself. b. Keys derived from EAP could be used to secure SNMP. Approach a) would appear to run afoul of the RFC 3748 Section 1.3 applicability statement: " EAP was designed for use in network access authentication, where IP layer connectivity may not be available. Use of EAP for other purposes, such as bulk data transport, is NOT RECOMMENDED." However, the applicability statement only applies to authentication methods encapsulated within EAP; the same algorithms, if encapsulated within SNMP itself, would not run afoul of the applicability statement. It is also worth noting that the applicability statement does not apply to RADIUS, so that RADIUS/EAP could be used between a RADIUS client and server even if the protocol used to authenticate SNMP did not involve EAP. As an example, there are IETF protocols that support CHAP authentication (iSCSI is an example) and RADIUS is commonly used to centrally manage CHAP authentication. Approach b) is not in conflict with RFC 3748. However, it would introduce a link layer dependency into SNMP, since not all link layers support EAP. Typically link layer dependencies are to be discouraged, since one of the goals of the TCP/IP protocol suite is to shield applications from the link layer dependencies. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 10:12: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 KAA19858; Wed, 12 Jan 2005 10:12:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CokOj-00081H-1L; Wed, 12 Jan 2005 10:27:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cojzt-0004bE-Vk; Wed, 12 Jan 2005 10:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoV8K-0007qT-00 for isms@megatron.ietf.org; Tue, 11 Jan 2005 18:09: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 SAA14236 for ; Tue, 11 Jan 2005 18:09:01 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoVMD-0003wI-9g for isms@ietf.org; Tue, 11 Jan 2005 18:23:26 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CoV8I-000HuA-0W; Tue, 11 Jan 2005 18:09:02 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j0BN90Q31599; Tue, 11 Jan 2005 15:09:00 -0800 Date: Tue, 11 Jan 2005 15:09:00 -0800 (PST) From: Bernard Aboba To: ietfdbh@comcast.net Subject: RE: [Isms] RE: Network management authorization In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Wed, 12 Jan 2005 10:01:21 -0500 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.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 I should add that there are other variations, such as: c. An authentication algorithm could be encapsulated with SNMP, deriving keys to secure SNMP, with the key derivation mechanisms being borrowed from the EAP Key Management Framework. This particular variation does not involve EAP authentication on the wire at all, and so does not run afoul of RFC 3748. It also does not imply a link layer dependency, since the link layer is not required to support EAP. All that happens in this variation is reuse of EAP key derivation formulas, which presumably will be thoroughly reviewed. On Tue, 11 Jan 2005, Bernard Aboba wrote: > There a number of ways that EAP could be used to secure SNMP, and they > have somewhat different implications: > > a. EAP packets could be encapsulated within SNMP itself. > b. Keys derived from EAP could be used to secure SNMP. > > Approach a) would appear to run afoul of the RFC 3748 Section > 1.3 applicability statement: > > " EAP was designed for use in network access authentication, where IP > layer connectivity may not be available. Use of EAP for other > purposes, such as bulk data transport, is NOT RECOMMENDED." > > However, the applicability statement only applies to authentication > methods encapsulated within EAP; the same algorithms, if encapsulated > within SNMP itself, would not run afoul of the applicability statement. > > It is also worth noting that the applicability statement does not apply to > RADIUS, so that RADIUS/EAP could be used between a RADIUS client and > server even if the protocol used to authenticate SNMP did not involve EAP. > As an example, there are IETF protocols that support CHAP authentication > (iSCSI is an example) and RADIUS is commonly used to centrally manage CHAP > authentication. > > Approach b) is not in conflict with RFC 3748. However, it would > introduce a link layer dependency into SNMP, since not all link layers > support EAP. Typically link layer dependencies are to be discouraged, > since one of the goals of the TCP/IP protocol suite is to shield > applications from the link layer dependencies. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 11:40: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 LAA27328; Wed, 12 Jan 2005 11:40:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Colll-0001kt-QJ; Wed, 12 Jan 2005 11:54:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ColQE-0003M4-FV; Wed, 12 Jan 2005 11:32:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ColIq-0001Hm-QB for isms@megatron.ietf.org; Wed, 12 Jan 2005 11:25:01 -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 LAA26360 for ; Wed, 12 Jan 2005 11:24:58 -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 1ColWu-0001Po-2w for isms@ietf.org; Wed, 12 Jan 2005 11:39:32 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 9BE1911D825; Wed, 12 Jan 2005 08:24:56 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501112239.j0BMdDh7006391@nutshell.tislabs.com> <003f01c4f848$aa41f6c0$7f1afea9@oemcomputer> Date: Wed, 12 Jan 2005 08:24:56 -0800 In-Reply-To: <003f01c4f848$aa41f6c0$7f1afea9@oemcomputer> (Randy Presuhn's message of "Tue, 11 Jan 2005 17:46:25 -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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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: cab78e1e39c4b328567edb48482b6a69 >>>>> On Tue, 11 Jan 2005 17:46:25 -0800, "Randy Presuhn" said: >> In short, SBSM as is (without modification) can be tied to radius now. Randy> This wasn't clear to me from the i-d. Thanks for spelling it Randy> out. Well, I said "can" but it is not the most ideal way to do it IMHO. I was hoping to do a better radius supported authentication system in the future as well that wouldn't require the transfer of passwords to the agent. Granted, boxes that support remote terminal logins already require users to type in passwords which are then used to authenticate radius, I'd ideally like to see an SNMP system not require such as a scheme if a better system was available (cram-md5, the newer one I forget the name of suddenly (ug!), ...) Randy> I don't think it's necessary to go so far as a "VACM Randy> centralization scheme." This bit that *is* important to Randy> address in integrating with external authentication systems is Randy> the mapping of users to groups. Agreed... The depth of which information needs to flow within the VACM is likely to be closer to exactly what is described above (and in the EUSM draft). Randy> Although that is modeled in VACM, it can also be considered Randy> part of user management. Failing to address it would be a Randy> grave mistake for the WG, IMO. I think it should be a goal too. But, I don't think it should be tied to the authentication system since that would then require that the authentication system be tied to radius, which I don't think would make every operator out there happy. Not everyone uses radius (and in fact my survey showed this clearly). If we only supported a radius based extension we would not even be supporting a majority of the market, which seems very counter to exactly what we're trying to do. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 13:14: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 NAA02873; Wed, 12 Jan 2005 13:14:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ConEN-0003gx-AK; Wed, 12 Jan 2005 13:28:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ComnZ-00014n-N7; Wed, 12 Jan 2005 13:00:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CommT-0000eQ-P5 for isms@megatron.ietf.org; Wed, 12 Jan 2005 12:59: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 MAA02180 for ; Wed, 12 Jan 2005 12:59:39 -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 1Con0V-0003Qm-Ll for isms@ietf.org; Wed, 12 Jan 2005 13:14:14 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j0CHxbtL017280 for ; Wed, 12 Jan 2005 12:59:37 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 12 Jan 2005 12:59:38 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 12 Jan 2005 12:59:38 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Jan 2005 12:58:33 -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] Network management authorization Date: Wed, 12 Jan 2005 12:58:33 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19081@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT4xXEWDisSaKENR96yBPjBhnBPvAACeGPQ From: "Nelson, David" To: X-OriginalArrivalTime: 12 Jan 2005 17:58:33.0626 (UTC) FILETIME=[55016FA0:01C4F8D0] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.4106 P:95.9108 R:95.9108 S:94.0078 ) 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 Wes Hardaker writes... > Randy> Although that is modeled in VACM, it can also be considered > Randy> part of user management. Failing to address it would be a > Randy> grave mistake for the WG, IMO. >=20 > I think it should be a goal too. But, I don't think it should be tied > to the authentication system since that would then require that the > authentication system be tied to radius, which I don't think would > make every operator out there happy. Not everyone uses radius (and in > fact my survey showed this clearly). If we only supported a radius > based extension we would not even be supporting a majority of the > market, which seems very counter to exactly what we're trying to do. OK. Use the generic term AAA instead of a specific protocol name, e.g. RADIUS. It is very important, however, that the authorization (e.g. group name) be strictly tied to the authentication and be provided as part and parcel of the AAA service. Not doing so give rise to potential security weaknesses. -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 14:00: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 OAA05568; Wed, 12 Jan 2005 14:00:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ConxK-0004dR-80; Wed, 12 Jan 2005 14:14:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ConiO-0005b4-RJ; Wed, 12 Jan 2005 13:59:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CondE-0004FB-1E for isms@megatron.ietf.org; Wed, 12 Jan 2005 13:54: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 NAA05124 for ; Wed, 12 Jan 2005 13:54: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 1ConrG-0004Tj-8d for isms@ietf.org; Wed, 12 Jan 2005 14:08:45 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 410CE11D825; Wed, 12 Jan 2005 10:54:04 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] Network management authorization Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19081@MAANDMBX2.ets.enterasys.com> Date: Wed, 12 Jan 2005 10:54:03 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19081@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 12 Jan 2005 12:58:33 -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: 21c69d3cfc2dd19218717dbe1d974352 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: 50a516d93fd399dc60588708fd9a3002 >>>>> On Wed, 12 Jan 2005 12:58:33 -0500, "Nelson, David" said: David> OK. Use the generic term AAA instead of a specific protocol David> name, e.g. RADIUS. It is very important, however, that the David> authorization (e.g. group name) be strictly tied to the David> authentication and be provided as part and parcel of the AAA David> service. Not doing so give rise to potential security David> weaknesses. My point is, David, that not everyone wants to use a centralized service like AAA. In fact, the majority of the people out there *are not*. Thus, providing a solution via this working group that mandates the use of a AAA server is simply not going to make operators happy. What I want: Manager < -------------- > Agent < ---------------> AAA ISMS maybe VACM-ties Thus, *if* a agent is authenticating a manager through an AAA server on the back side, then it would be absolutely nice *if* the administrator ed wanted to distributing grouping or other authorization information within the AAA transaction used to authenticate the manager's ISMS request. However, there is no reason to force-tie the ISMS protocol security to the VACM-tie-in service. This should be done as policy/configuration on the agent, not by forcing it on users that don't want it. I very much agree that it would be useful for those operators that have AAA servers, and would love to see the work done. But I violently oppose it dictating that the only way the ISMS half of the solution can be done is by use of a AAA server. That simply does not meet the needs of the people out there and such results would be short sighted in the eyes of the operators. If, however, a nice marriage was possible (and it should be) then operators would have added incentive to switch to a AAA architecture to get the bonus benefits, which will make the AAA vendors happy (buy our product and suddenly your SNMP configuration burdens are eased). But please don't force that on the operators that already have an existing infrastructure that doesn't require an AAA server and may not want to maintain one. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 14:28:48 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 OAA06941; Wed, 12 Jan 2005 14:28:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CooOn-0005By-ML; Wed, 12 Jan 2005 14:43:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coo2M-0001h7-CI; Wed, 12 Jan 2005 14:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Conu3-00086r-Me for isms@megatron.ietf.org; Wed, 12 Jan 2005 14:11: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 OAA06166 for ; Wed, 12 Jan 2005 14:11:34 -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 1Coo87-0004rQ-Gh for isms@ietf.org; Wed, 12 Jan 2005 14:26:08 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA06406 for ; Wed, 12 Jan 2005 14:17:14 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma005912; Wed, 12 Jan 05 14:15:10 -0500 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 12 Jan 2005 14:09:24 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 12 Jan 2005 14:09:23 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Jan 2005 14:09:05 -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] Network management authorization Date: Wed, 12 Jan 2005 14:09:04 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19082@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT42BpWSmROClH3RqabSUSLttbphwAAEEew From: "Nelson, David" To: X-OriginalArrivalTime: 12 Jan 2005 19:09:05.0048 (UTC) FILETIME=[2F213180:01C4F8DA] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:78.1961 M:98.8113 P:95.9108 R:95.9108 S:68.6168 ) 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: 8abaac9e10c826e8252866cbe6766464 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable Wes Hardaker writes... =20 > My point is, David, that not everyone wants to use a centralized > service like AAA. In fact, the majority of the people out there *are > not*. Thus, providing a solution via this working group that mandates > the use of a AAA server is simply not going to make operators happy. A local username and password database is a degenerate instance of AAA. AAA does not imply "remote" or "centralized", although that is certainly the most common case. My point is that authentication provides evidence of identity. It does not, in the general case, provide evidence of "access rights" to management interfaces, *especially* in a centralized AAA (single sign-on) deployment. In the local database AAA deployment, it may be that the existence of a credential implies access rights. That's fine. While I never suggested mandating remote AAA as the only model, I do feel that *when* remote AAA is used it is important that at least the first two "A"s in Authentication, Authorization, and Accounting be considered. I also think that the kinds of "scaling" issues that folks complain of in static password or static key based SNMPv3 deployments will drive folks to want to use centralized AAA. The fact that surveys show little usage of centralized AAA for SNMP access control may be (at least partly) explained by the fact that there are not currently any standardized linkages, of the kind we are discussing. The non-availability of a feature in products often shows up as lack of fielded deployments of that particular feature. Right? :-) -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 14:36: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 OAA07508; Wed, 12 Jan 2005 14:36:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CooWH-0005LN-Ev; Wed, 12 Jan 2005 14:51:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooBM-0003PQ-1D; Wed, 12 Jan 2005 14:29:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coo3Z-00020f-Fk for isms@megatron.ietf.org; Wed, 12 Jan 2005 14:21:25 -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 OAA06657 for ; Wed, 12 Jan 2005 14:21:24 -0500 (EST) Message-Id: <200501121921.OAA06657@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CooHb-00053C-BV for isms@ietf.org; Wed, 12 Jan 2005 14:35:58 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011219205001400gpbcme>; Wed, 12 Jan 2005 19:20:50 +0000 From: "David B Harrington" To: "'Wes Hardaker'" , "'Nelson, David'" Subject: RE: [Isms] Network management authorization Date: Wed, 12 Jan 2005 14:20:46 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT42Pko8l7N2Wh5T+2fyEolJ6EfgAAAm9dg X-Spam-Score: 0.1 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi, I think Dave's point was, and I will reiterate it myself: "It is very important that the authorization be strictly tied to the authentication" This is a point that was discussed at length in the development of SMIv2/v3. Failure to strictly tie these together is a security problem. (Like I should have to tell you!) dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker > Sent: Wednesday, January 12, 2005 1:54 PM > To: Nelson, David > Cc: isms@ietf.org > Subject: Re: [Isms] Network management authorization > > >>>>> On Wed, 12 Jan 2005 12:58:33 -0500, "Nelson, David" > said: > > David> OK. Use the generic term AAA instead of a specific protocol > David> name, e.g. RADIUS. It is very important, however, that the > David> authorization (e.g. group name) be strictly tied to the > David> authentication and be provided as part and parcel of the AAA > David> service. Not doing so give rise to potential security > David> weaknesses. > > My point is, David, that not everyone wants to use a centralized > service like AAA. In fact, the majority of the people out there *are > not*. Thus, providing a solution via this working group that mandates > the use of a AAA server is simply not going to make operators happy. > > What I want: > > Manager < -------------- > Agent < ---------------> AAA > ISMS maybe > VACM-ties > > Thus, *if* a agent is authenticating a manager through an AAA server > on the back side, then it would be absolutely nice *if* the > administrator ed wanted to distributing grouping or other > authorization information within the AAA transaction used to > authenticate the manager's ISMS request. However, there is no reason > to force-tie the ISMS protocol security to the VACM-tie-in service. > This should be done as policy/configuration on the agent, not by > forcing it on users that don't want it. I very much agree that it > would be useful for those operators that have AAA servers, and would > love to see the work done. But I violently oppose it dictating that > the only way the ISMS half of the solution can be done is by use of a > AAA server. That simply does not meet the needs of the people out > there and such results would be short sighted in the eyes of the > operators. If, however, a nice marriage was possible (and it should > be) then operators would have added incentive to switch to a AAA > architecture to get the bonus benefits, which will make the AAA > vendors happy (buy our product and suddenly your SNMP configuration > burdens are eased). But please don't force that on the operators that > already have an existing infrastructure that doesn't require an AAA > server and may not want to maintain one. > > -- > 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 Jan 12 14:39: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 OAA07711; Wed, 12 Jan 2005 14:39:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CooZU-0005Ow-PO; Wed, 12 Jan 2005 14:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooJT-0005bH-5w; Wed, 12 Jan 2005 14:37:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CooHI-0004ew-7P for isms@megatron.ietf.org; Wed, 12 Jan 2005 14: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 OAA07378 for ; Wed, 12 Jan 2005 14:35:35 -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 1CooVM-0005J7-8D for isms@ietf.org; Wed, 12 Jan 2005 14:50:09 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id B3CF011D825; Wed, 12 Jan 2005 11:35:31 -0800 (PST) From: Wes Hardaker To: Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501121917.j0CJHTDx001978@nutshell.tislabs.com> Date: Wed, 12 Jan 2005 11:35:31 -0800 In-Reply-To: <200501121917.j0CJHTDx001978@nutshell.tislabs.com> (David B. Harrington's message of "Wed, 12 Jan 2005 14:20:46 -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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 >>>>> On Wed, 12 Jan 2005 14:20:46 -0500, "David B Harrington" said: David> Failure to strictly tie these together is a security problem. I don't disagree with that. I disagree with the mandatory tying. You MUST have authorization to do something. That authorization MUST be tied to an identity which has been authenticated. You don't necessarily need to, however, tie it via AAA. VACM already has a tie, albeit limited in functionality. It's the forced binding of two technologies that I object to. I'd imagine local policy directives that would tie authentication systems to a authorization system. "If coming in over SNMPv3/XXXX then look up grouping or other information in authorization system YYYY". It's the "the solution will use XXXX/YYYY" that I object to and think doesn't serve the community. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 15:07: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 PAA09525; Wed, 12 Jan 2005 15:07:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cop0j-0005wT-JX; Wed, 12 Jan 2005 15:22:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coohe-0003Z5-2W; Wed, 12 Jan 2005 15:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoogF-0002UW-Hk for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:01: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 PAA08783 for ; Wed, 12 Jan 2005 15:01:22 -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 1CoouI-0005mZ-Lu for isms@ietf.org; Wed, 12 Jan 2005 15:15:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 12 Jan 2005 13:13:06 +0000 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 j0CK0il2022636; Wed, 12 Jan 2005 12:00:44 -0800 (PST) Received: from jsaloweyw2k01 ([10.82.225.10]) by E2K-SEA-XCH2.sea-alpha.cisco.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Jan 2005 12:03:16 -0800 From: "Joseph Salowey" To: "'Bernard Aboba'" , Subject: RE: [Isms] RE: Network management authorization Date: Wed, 12 Jan 2005 12:00:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcT4uYqH6OqT4amARiydU+17/dQeCwAJRlew In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: X-OriginalArrivalTime: 12 Jan 2005 20:03:17.0204 (UTC) FILETIME=[C190D140:01C4F8E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: 7bit With EUSM we selected using EAP because of the integration possibilities with back end AAA authentication mechanisms. We had envisioned two modes of operation: 1. When the SNMP Manager/Client is aware of the location of the AAA server then it can establish keys with AAA server using RADIUS which then can cache them and localize them for each agent as needed. Here EAP is encapsulated in RADIUS. 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA server then the key negotiation would initiate between the SNMP Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if applicable. We did not encapsulate EAP in SNMP since this would be a big change to the SNMP protocol but instead choose to encapsulate it in an out of band protocol to leverage existing work. The protocols we had in mind were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or IKEv2, but other arrangements are possible. The second mode allows for operation without AAA. Joe isms-bounces@lists.ietf.org wrote: > I should add that there are other variations, such as: > > c. An authentication algorithm could be encapsulated with SNMP, > deriving keys to secure SNMP, with the key derivation mechanisms > being borrowed from the EAP Key Management Framework. > > This particular variation does not involve EAP authentication > on the wire at all, and so does not run afoul of RFC 3748. > It also does not imply a link layer dependency, since the > link layer is not required to support EAP. All that happens > in this variation is reuse of EAP key derivation formulas, > which presumably will be thoroughly reviewed. > > > On Tue, 11 Jan 2005, Bernard Aboba wrote: > >> There a number of ways that EAP could be used to secure SNMP, and >> they have somewhat different implications: >> >> a. EAP packets could be encapsulated within SNMP itself. >> b. Keys derived from EAP could be used to secure SNMP. >> >> Approach a) would appear to run afoul of the RFC 3748 Section >> 1.3 applicability statement: >> >> " EAP was designed for use in network access authentication, where >> IP layer connectivity may not be available. Use of EAP for other >> purposes, such as bulk data transport, is NOT RECOMMENDED." >> >> However, the applicability statement only applies to authentication >> methods encapsulated within EAP; the same algorithms, if encapsulated >> within SNMP itself, would not run afoul of the applicability >> statement. >> >> It is also worth noting that the applicability statement does not >> apply to RADIUS, so that RADIUS/EAP could be used between a RADIUS >> client and server even if the protocol used to authenticate SNMP did >> not involve EAP. As an example, there are IETF protocols that >> support CHAP authentication (iSCSI is an example) and RADIUS is >> commonly used to centrally manage CHAP authentication. >> >> Approach b) is not in conflict with RFC 3748. However, it would >> introduce a link layer dependency into SNMP, since not all link >> layers support EAP. Typically link layer dependencies are to be >> discouraged, since one of the goals of the TCP/IP protocol suite is >> to shield applications from the link layer dependencies. >> > > _______________________________________________ > 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 Jan 12 15:09: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 PAA09757; Wed, 12 Jan 2005 15:09:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cop1p-0005yz-0T; Wed, 12 Jan 2005 15:23:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coome-0007mh-D4; Wed, 12 Jan 2005 15:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoohJ-0003Fw-7W for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:02: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 PAA08892 for ; Wed, 12 Jan 2005 15:02:27 -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 1Coov8-0005p3-Ci for isms@ietf.org; Wed, 12 Jan 2005 15:17:02 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j0CK29tL023949 for ; Wed, 12 Jan 2005 15:02:09 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 12 Jan 2005 15:02:10 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 12 Jan 2005 15:02:10 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Jan 2005 15:02:01 -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] Network management authorization Date: Wed, 12 Jan 2005 15:02:01 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19083@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT43eNfqg1SVkIXS0C5H4uf4jU5vAAAFrfQ From: "Nelson, David" To: "Wes Hardaker" , X-OriginalArrivalTime: 12 Jan 2005 20:02:01.0736 (UTC) FILETIME=[94955080:01C4F8E1] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:96.3115 P:95.5390 R:95.9108 S:80.4590 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Wes Hardaker writes... > David> Failure to strictly tie these together is a security problem. >=20 > I don't disagree with that. I disagree with the mandatory tying. You > MUST have authorization to do something. That authorization MUST be > tied to an identity which has been authenticated. Cool. > You don't necessarily need to, however, tie it via AAA. I disagree. (But see my previous reply. I notice that replies sent only to the mail reflector are slower...) > VACM already has a tie, albeit limited in functionality. VACM can bind a username string "dave" to a view. The problem is that we need to be sure that the user "dave" who was authenticated is the same instance of "dave" that is used in the VACM binding. In simple, local database implementations of SNMP authentication and authorization, this might be easy to guarantee. In the cases of remote AAA, there is no strong binding of the local "dave" instance bound to the VACM and the "dave" instance whose credentials were validated by the remote AAA. You can issue an organizational fiat that all usernames will be unique in a single flat name space, but that is hard to guarantee, and, I postulate, impossible to guarantee to a level of certainty required for good security. Some form of cryptographic binding is generally required. > It's the forced binding of two > technologies that I object to. I'd imagine local policy directives > that would tie authentication systems to a authorization system.=20 I'm not suggesting that remote AAA be required. I'm suggesting that authentication be strictly tied to authorization, and that *when* remote AAA is used the authorization MUST be explicitly provided by the AAA service and not "guessed" by some local policy configuration. =20 > "If coming in over SNMPv3/XXXX then look up grouping or other=20 > information in authorization system YYYY". =20 I respectfully disagree and think that solution would have very poor security properties. -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 15:26:45 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 PAA11520; Wed, 12 Jan 2005 15:26:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CopIt-0006IK-Tw; Wed, 12 Jan 2005 15:41:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoorB-0003Cs-Jm; Wed, 12 Jan 2005 15:12:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coon8-0008H9-2J for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:08: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 PAA09585 for ; Wed, 12 Jan 2005 15:08:28 -0500 (EST) Message-Id: <200501122008.PAA09585@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cop1A-0005w1-DC for isms@ietf.org; Wed, 12 Jan 2005 15:23:03 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005011220075401500n4jtbe>; Wed, 12 Jan 2005 20:07:55 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Subject: RE: [Isms] Network management authorization Date: Wed, 12 Jan 2005 15:07: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.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT43egtpjw+U8+RSLWZIsooCQWDdQAAVWUA X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi Wes, I think you are reading too much into the term AAA. I consider AAA to be an abstract set of provided services, not specific protocols or particular types of implementation/deployments. The point Dave and I are making is that there needs to be a binding between the authentication and authorization. I will make the point that having such a binding is a matter of being compliant to the SNMpv3 architecture. That is not to say that both authentication and authorization need to be provided by the same service, as is the case with RADIUS, but that there needs to be a secure binding between the services that provide these two steps. USM provides the authentication service in SNMPv3, and VACM provides the authorization; they are securely bound by being in the same engine, and using the required securityname as the binding. If the authentication and authorization swervices are not in the same engine (SNMP engine or RADIUS server, etc.) then we need to explain HOW they will be appropriately bound in our proposals. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Wednesday, January 12, 2005 2:36 PM > To: ietfdbh@comcast.net > Cc: 'Nelson, David'; isms@ietf.org > Subject: Re: [Isms] Network management authorization > > >>>>> On Wed, 12 Jan 2005 14:20:46 -0500, "David B > Harrington" said: > > David> Failure to strictly tie these together is a security problem. > > I don't disagree with that. I disagree with the mandatory tying. You > MUST have authorization to do something. That authorization MUST be > tied to an identity which has been authenticated. You don't > necessarily need to, however, tie it via AAA. VACM already has a tie, > albeit limited in functionality. It's the forced binding of two > technologies that I object to. I'd imagine local policy directives > that would tie authentication systems to a authorization system. "If > coming in over SNMPv3/XXXX then look up grouping or other information > in authorization system YYYY". It's the "the solution will use > XXXX/YYYY" that I object to and think doesn't serve the community. > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 15:31: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 PAA11863; Wed, 12 Jan 2005 15:31:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CopNo-0006OR-CE; Wed, 12 Jan 2005 15:46:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cop5r-0004in-HL; Wed, 12 Jan 2005 15:27:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coowq-00077N-TC for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:18: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 PAA10847 for ; Wed, 12 Jan 2005 15:18:31 -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 1CopAv-0006AX-8P for isms@ietf.org; Wed, 12 Jan 2005 15:33:06 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id BEA6A11D825; Wed, 12 Jan 2005 12:18:28 -0800 (PST) From: Wes Hardaker To: Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501122004.j0CK4c2Z008685@nutshell.tislabs.com> Date: Wed, 12 Jan 2005 12:18:28 -0800 In-Reply-To: <200501122004.j0CK4c2Z008685@nutshell.tislabs.com> (David B. Harrington's message of "Wed, 12 Jan 2005 15:07:51 -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: 69a74e02bbee44ab4f8eafdbcedd94a1 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: 9ed51c9d1356100bce94f1ae4ec616a9 >>>>> On Wed, 12 Jan 2005 15:07:51 -0500, "David B Harrington" said: David> I think you are reading too much into the term AAA. I consider David> AAA to be an abstract set of provided services, not specific David> protocols or particular types of implementation/deployments. I'm quite possibly doing that, but I'd argue it's largely in part to how it's being used. If your definition of AAA also includes the USM/VACM pair, then I think we're likely much closer in agreement about what we think is necessary as far as a binding goes. David> The point Dave and I are making is that there needs to be a binding David> between the authentication and authorization. I don't think anyone has said otherwise actually. David> I will make the point that having such a binding is a matter of David> being compliant to the SNMpv3 architecture. Agreed. You can't be a compliant security model if you somehow trump the ability for VACM (or some other ACM) to work as an authorization mechanism. David> If the authentication and authorization swervices are not in David> the same engine (SNMP engine or RADIUS server, etc.) then we David> need to explain HOW they will be appropriately bound in our David> proposals. I agree with that completely. Which means we are probably on the same page and have been ranting about the same thing in different ways. Fortunately, I don't think any of the 3 proposals to date were planning on violating this. The only one that didn't discuss the issue at all was yours, actually, but that was merely due to time constraints not that it wasn't planned. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 15:59: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 PAA15059; Wed, 12 Jan 2005 15:59:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Copnf-0007fs-0G; Wed, 12 Jan 2005 16:13:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopBr-00083L-Df; Wed, 12 Jan 2005 15:34:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopAK-00072m-Tl for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:32: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 PAA11906 for ; Wed, 12 Jan 2005 15:32:27 -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 1CopOQ-0006Ov-8k for isms@ietf.org; Wed, 12 Jan 2005 15:47:02 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DD2DF11D825; Wed, 12 Jan 2005 12:32:23 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] Network management authorization Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19083@MAANDMBX2.ets.enterasys.com> Date: Wed, 12 Jan 2005 12:32:23 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19083@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 12 Jan 2005 15:02:01 -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: 00e94c813bef7832af255170dca19e36 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: d185fa790257f526fedfd5d01ed9c976 >>>>> On Wed, 12 Jan 2005 15:02:01 -0500, "Nelson, David" said: >> VACM already has a tie, albeit limited in functionality. David> VACM can bind a username string "dave" to a view. The problem David> is that we need to be sure that the user "dave" who was David> authenticated is the same instance of "dave" that is used in David> the VACM binding. In simple, local database implementations of David> SNMP authentication and authorization, this might be easy to David> guarantee. In the cases of remote AAA, there is no strong David> binding of the local "dave" instance bound to the VACM and the David> "dave" instance whose credentials were validated by the remote David> AAA. You can issue an organizational fiat that all usernames David> will be unique in a single flat name space, but that is hard to David> guarantee, and, I postulate, impossible to guarantee to a level David> of certainty required for good security. Some form of David> cryptographic binding is generally required. I agree completely. Almost. Your one failed statement is that the user "dave" must be unique by itself. That's not true at all. It must be unique in combination with the security model (see the indexes to the vacmSecurityToGroupTable). Thus, dave only needs to be unique for a given security model. SBSM takes this into account in its document and specifies that each authentication mechanism will be considered a different security model with respect to how the VACM should perform a look up. (and it's entirely possible, as I pointed out previously, that the contents of that lookup could very easily be propagated from a remote AAA server's exchange (trying to use the right terminology here new). But not required. It could have been locally pre-determined assigned as well.) David> I'm not suggesting that remote AAA be required. I'm finally seeing that in writing. I hadn't inferred that from the previous statements. And since that's the case, then I agree. David> I'm suggesting that authentication be strictly tied to David> authorization, and that *when* remote AAA is used the David> authorization MUST be explicitly provided by the AAA service David> and not "guessed" by some local policy configuration. That, however, I disagree with. I see no problems with accepting the authentication provided by a remote entity and certifying that a request is authentic to the person "david" using radius, but I may have a local notion of what I want the person I now know authoritatively as "david" to be able to do. There is still a binding here, but it is locally bound in the policy configured into the device. Or, I may want what you're describing which is to have the remote AAA server also hand who their authorization rights. Neither usage is insecure (although we haven't talked about how an agent can trust a remote AAA server for either of these decisions). Let me give an example from my past. I worked at a university with a centralized authentication system. This centralized system was capable of certifying (via kerberos or kerberos via radius or ...) who a user was. Each sub-department had its own services though. What it needed to know, in many cases, was could the user authenticate himself against his central account. If so and an identity was handed to the server requesting the authentication (its another story about how this is done), *then* the local policy would check to see if the person was in deed a member of the department and could view the information in question. The centralized service did not have the membership information, nor does it even today 5 years+ later. It's not its responsibility and if it was forced to do so, it would probably be unwilling to. Just because something else is doing the authentication doesn't mean that it's the only place you can securely retrieve authorization information from. Now, the one caveat is that you have to trust the larger authentication system to actually give you a user identity which you can verify is in a subset of interest only to you. It does get more complex if you want to deal with multiple remote AAA servers acting in different "domains". -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:03:48 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 QAA15771; Wed, 12 Jan 2005 16:03:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Copsi-0007vg-Uc; Wed, 12 Jan 2005 16:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopaY-0004W9-V7; Wed, 12 Jan 2005 15:59:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopDS-0000Sb-Uf for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:35:43 -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 PAA12128 for ; Wed, 12 Jan 2005 15:35:41 -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 1CopRV-0006RX-15 for isms@ietf.org; Wed, 12 Jan 2005 15:50:16 -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 j0CKZ6tP009573; Wed, 12 Jan 2005 20:35:06 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 j0CKYvlB011496; Wed, 12 Jan 2005 20:35:05 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs042.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011212350516574 ; Wed, 12 Jan 2005 12:35:05 -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); Wed, 12 Jan 2005 12:35:05 -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); Wed, 12 Jan 2005 12:35: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); Wed, 12 Jan 2005 15:35:04 -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] Network management authorization Date: Wed, 12 Jan 2005 15:35:03 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C59298A9543@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT43egtpjw+U8+RSLWZIsooCQWDdQAAVWUAAAGpSwA= From: "Blumenthal, Uri" To: , "Wes Hardaker" X-OriginalArrivalTime: 12 Jan 2005 20:35:04.0157 (UTC) FILETIME=[3232C0D0:01C4F8E6] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable AFAIC, USM provides *per-packet* authentication (and confidentiality), VACM provides authporization. This ISMS thing could provide credentials for the &session* within which the packets flow, and the tie to the VACM entry that should be applied for authorization for this session.=20 Uri -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Wednesday, January 12, 2005 3:08 PM To: 'Wes Hardaker' Cc: isms@ietf.org Subject: RE: [Isms] Network management authorization Hi Wes, I think you are reading too much into the term AAA. I consider AAA to be an abstract set of provided services, not specific protocols or particular types of implementation/deployments. The point Dave and I are making is that there needs to be a binding between the authentication and authorization. I will make the point that having such a binding is a matter of being compliant to the SNMpv3 architecture. That is not to say that both authentication and authorization need to be provided by the same service, as is the case with RADIUS, but that there needs to be a secure binding between the services that provide these two steps. USM provides the authentication service in SNMPv3, and VACM provides the authorization; they are securely bound by being in the same engine, and using the required securityname as the binding.=20 If the authentication and authorization swervices are not in the same engine (SNMP engine or RADIUS server, etc.) then we need to explain HOW they will be appropriately bound in our proposals. dbh > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 > Sent: Wednesday, January 12, 2005 2:36 PM > To: ietfdbh@comcast.net > Cc: 'Nelson, David'; isms@ietf.org > Subject: Re: [Isms] Network management authorization >=20 > >>>>> On Wed, 12 Jan 2005 14:20:46 -0500, "David B=20 > Harrington" said: >=20 > David> Failure to strictly tie these together is a security problem. >=20 > I don't disagree with that. I disagree with the mandatory tying. You > MUST have authorization to do something. That authorization MUST be > tied to an identity which has been authenticated. You don't > necessarily need to, however, tie it via AAA. VACM already has a tie, > albeit limited in functionality. It's the forced binding of two > technologies that I object to. I'd imagine local policy directives > that would tie authentication systems to a authorization system. "If > coming in over SNMPv3/XXXX then look up grouping or other information > in authorization system YYYY". It's the "the solution will use > XXXX/YYYY" that I object to and think doesn't serve the community. >=20 > --=20 > Wes Hardaker > Sparta >=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 Wed Jan 12 16:04:46 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 QAA15818; Wed, 12 Jan 2005 16:04:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coptf-0007wp-0N; Wed, 12 Jan 2005 16:19:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copaf-0004ZY-CM; Wed, 12 Jan 2005 15:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopFA-0001O3-98 for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:37: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 PAA12182 for ; Wed, 12 Jan 2005 15:37:26 -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 1CopTE-0006Tj-Sd for isms@ietf.org; Wed, 12 Jan 2005 15:52:02 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 7326311D825; Wed, 12 Jan 2005 12:37:23 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] Network management authorization Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19082@MAANDMBX2.ets.enterasys.com> Date: Wed, 12 Jan 2005 12:37:23 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19082@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 12 Jan 2005 14:09:04 -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: 97adf591118a232206bdb5a27b217034 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: 8b30eb7682a596edff707698f4a80f7d >>>>> On Wed, 12 Jan 2005 14:09:04 -0500, "Nelson, David" said: David> I also think that the kinds of "scaling" issues that folks complain of David> in static password or static key based SNMPv3 deployments will drive David> folks to want to use centralized AAA. FYI, I agree with this. It's highly likely that it would be a more optimal choice much of the time. It's certainly more efficient than rdisting local account/authorization information to a zillion machines. David> The fact that surveys show little usage of centralized AAA for David> SNMP access control may be (at least partly) explained by the David> fact that there are not currently any standardized linkages, of David> the kind we are discussing. There is no AAA service for SNMP. The survey was asking generically what they used for any authentication mechanism. IE, the reality was that local accounts were used for most remote logins via telnet or ssh. It had nothing to do with SNMP. And it's these existing credentials that they want to tie SNMP too if possible to make it more usable for them. A good Radius salesman may convince them of a better way to do things, but I'm not a salesman nor will I ever play one in life or on TV. David> The non-availability of a feature in products often shows up as David> lack of fielded deployments of that particular feature. Right? If your guess is right, the answer should have been 0 (since it doesn't exist, it couldn't be used). However, the question was about authentication in general. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:14:12 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 QAA16933; Wed, 12 Jan 2005 16:14:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coq2p-0008IB-3V; Wed, 12 Jan 2005 16:28:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copam-0004fh-1E; Wed, 12 Jan 2005 15:59:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopJs-0003tb-7M for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:42:20 -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 PAA12448 for ; Wed, 12 Jan 2005 15:42:18 -0500 (EST) Message-Id: <200501122042.PAA12448@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CopXv-0006Ym-Ow for isms@ietf.org; Wed, 12 Jan 2005 15:56:54 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005011220414501400ggi5pe>; Wed, 12 Jan 2005 20:41:45 +0000 From: "David B Harrington" To: "'Wes Hardaker'" Subject: RE: [Isms] Network management authorization Date: Wed, 12 Jan 2005 15:41:41 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT44+eYDEECcmruQeayDggsHFvREQAAXK7g X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Fortunately, I don't think any of the 3 proposals to date were > planning on violating this. The only one that didn't discuss the > issue at all was yours, actually, but that was merely due to time > constraints not that it wasn't planned. > Here's a good segue I'll take advantage of. In my view (and not neceesarily in Juergen's), I think it might be worthwhile to separate the message authentication from the user identity autentication. That is, allow TLS ir IPSec or other lower layer security mechanism to provide message sendser authentication, integrity checking, confidentiality, etc., to transport the SNMP request securely. In this way, the lower layer security might be host-to-host authentication, using existing protocols for that purpose; the lower layer might set up a secure association between message sender and message receiver. Then pass the payload to the SNMP engine, which authenticates the user identity in the payload, and that authenticated user identity will be used for authorization purposes. This could be application-session-based if desired, to minimize overhead, and could use centralized services, to reduce administration costs. This approach would eliminate the requirement of passing the securityname from the tranbsport layer into the application layer, maintaining a better layer separation. This separation of transport security from application security could simplify some aspects of SNMPv3. Such a proposal would require a good look at the necessary bindings between the different security systems. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:22: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 QAA17914; Wed, 12 Jan 2005 16:22:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqB0-0000CR-Nu; Wed, 12 Jan 2005 16:37:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copb5-0004tB-3p; Wed, 12 Jan 2005 16:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopOy-0006bc-7p for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:47: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 PAA12924 for ; Wed, 12 Jan 2005 15:47:34 -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 1Copcm-0006tL-MN for isms@ietf.org; Wed, 12 Jan 2005 16:02:10 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j0CKlFtL025481 for ; Wed, 12 Jan 2005 15:47:15 -0500 (EST) Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 12 Jan 2005 15:47:15 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 12 Jan 2005 15:47:14 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 12 Jan 2005 15:47:15 -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] Network management authorization Date: Wed, 12 Jan 2005 15:47:14 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19084@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Network management authorization Thread-Index: AcT45dkDbfMpSkuLS6OYOu0JOUL9WAAAHqCg From: "Nelson, David" To: "Wes Hardaker" X-OriginalArrivalTime: 12 Jan 2005 20:47:15.0204 (UTC) FILETIME=[E5EFAC40:01C4F8E7] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:85.5827 M:98.0659 P:95.9108 R:95.9108 S:99.9000 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable > That, however, I disagree with. I see no problems with accepting the > authentication provided by a remote entity and certifying that a > request is authentic to the person "david" using radius, but I may > have a local notion of what I want the person I now know > authoritatively as "david" to be able to do. I would have to see some details of how the binding of the authenticated identity to the local policy is to be accomplished before I could comment further. > The centralized service did not have the membership > information, nor does it even today 5 years+ later.=20 Yes, but Kerberos is not an AAA service. It is an Authenticated Key Management Service, and an Authentication Service. Last time I looked, Kerberos had no concept of Authorization (not to mention Accounting. I'm sure there are secure methods of binding the Kerberos identity with the local policy source's notion of identity. If one is using an AAA service, then one ought to use the Authorization component thereof for its intended purpose. If all one has is an authentication service, then extra work is required to "bolt-on" authorization, and I think we all agree that the method of doing so must provide a strong binding (most likely a cryptographic binding). -- Dave _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:23: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 QAA18042; Wed, 12 Jan 2005 16:23:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqBf-0000Fz-LQ; Wed, 12 Jan 2005 16:37:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copco-00067S-26; Wed, 12 Jan 2005 16:01:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopS5-0000CK-JK for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:50: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 PAA13596 for ; Wed, 12 Jan 2005 15:50:47 -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 1CopgA-000799-2F for isms@ietf.org; Wed, 12 Jan 2005 16:05:23 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id A76BC11D825; Wed, 12 Jan 2005 12:50:44 -0800 (PST) From: Wes Hardaker To: Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501122038.j0CKcPja011490@nutshell.tislabs.com> Date: Wed, 12 Jan 2005 12:50:44 -0800 In-Reply-To: <200501122038.j0CKcPja011490@nutshell.tislabs.com> (David B. Harrington's message of "Wed, 12 Jan 2005 15:41:41 -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: 08170828343bcf1325e4a0fb4584481c Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 >>>>> On Wed, 12 Jan 2005 15:41:41 -0500, "David B Harrington" said: David> In my view (and not neceesarily in Juergen's), I think it might David> be worthwhile to separate the message authentication from the David> user identity autentication. This is frequently done in situations like this. The only thing you have to make sure you do is cryptographically bind the message authentication key with the identity authentication mechanism. Without doing that, you end up with the MiM attacks that have been discussed so widely in the last 2 years or so. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:23: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 QAA18088; Wed, 12 Jan 2005 16:23:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqBr-0000Gb-Jf; Wed, 12 Jan 2005 16:38:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copct-0006CQ-8h; Wed, 12 Jan 2005 16:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopSj-0000YY-H9 for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:51: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 PAA13675 for ; Wed, 12 Jan 2005 15:51:27 -0500 (EST) Message-Id: <200501122051.PAA13675@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Copgp-00079o-8g for isms@ietf.org; Wed, 12 Jan 2005 16:06:03 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <2005011220505701500n2i6ke>; Wed, 12 Jan 2005 20:50:57 +0000 From: "David B Harrington" To: "'Blumenthal, Uri'" , "'Wes Hardaker'" Subject: RE: [Isms] Network management authorization Date: Wed, 12 Jan 2005 15:50:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <3DEC199BD7489643817ECA151F7C59298A9543@pysmsx401.amr.corp.intel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 thread-index: AcT43egtpjw+U8+RSLWZIsooCQWDdQAAVWUAAAGpSwAAAJs8kA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit I think everybody is in agreement on that point. dbh > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] > Sent: Wednesday, January 12, 2005 3:35 PM > To: ietfdbh@comcast.net; Wes Hardaker > Cc: isms@ietf.org > Subject: RE: [Isms] Network management authorization > > AFAIC, USM provides *per-packet* authentication (and > confidentiality), > VACM provides authporization. This ISMS thing could provide > credentials > for the &session* within which the packets flow, and the tie > to the VACM > entry that should be applied for authorization for this session. > > Uri > > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] > On Behalf Of David B Harrington > Sent: Wednesday, January 12, 2005 3:08 PM > To: 'Wes Hardaker' > Cc: isms@ietf.org > Subject: RE: [Isms] Network management authorization > > Hi Wes, > > I think you are reading too much into the term AAA. I consider AAA to > be an abstract set of provided services, not specific protocols or > particular types of implementation/deployments. > > The point Dave and I are making is that there needs to be a binding > between the authentication and authorization. I will make the point > that having such a binding is a matter of being compliant to the > SNMpv3 architecture. That is not to say that both authentication and > authorization need to be provided by the same service, as is the case > with RADIUS, but that there needs to be a secure binding between the > services that provide these two steps. USM provides the authentication > service in SNMPv3, and VACM provides the authorization; they are > securely bound by being in the same engine, and using the required > securityname as the binding. > > If the authentication and authorization swervices are not in the same > engine (SNMP engine or RADIUS server, etc.) then we need to explain > HOW they will be appropriately bound in our proposals. > > dbh > > > -----Original Message----- > > From: Wes Hardaker [mailto:hardaker@tislabs.com] > > Sent: Wednesday, January 12, 2005 2:36 PM > > To: ietfdbh@comcast.net > > Cc: 'Nelson, David'; isms@ietf.org > > Subject: Re: [Isms] Network management authorization > > > > >>>>> On Wed, 12 Jan 2005 14:20:46 -0500, "David B > > Harrington" said: > > > > David> Failure to strictly tie these together is a security problem. > > > > I don't disagree with that. I disagree with the mandatory tying. > You > > MUST have authorization to do something. That authorization MUST be > > tied to an identity which has been authenticated. You don't > > necessarily need to, however, tie it via AAA. VACM already has a > tie, > > albeit limited in functionality. It's the forced binding of two > > technologies that I object to. I'd imagine local policy directives > > that would tie authentication systems to a authorization system. > "If > > coming in over SNMPv3/XXXX then look up grouping or other > information > > in authorization system YYYY". It's the "the solution will use > > XXXX/YYYY" that I object to and think doesn't serve the community. > > > > -- > > 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 Jan 12 16:23:40 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 QAA18150; Wed, 12 Jan 2005 16:23:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqC0-0000HE-Hi; Wed, 12 Jan 2005 16:38:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copdl-0007Nu-Dw; Wed, 12 Jan 2005 16:02:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopTl-00011a-SI for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:52: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 PAA13834 for ; Wed, 12 Jan 2005 15:52: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 1Cophq-0007FB-MO for isms@ietf.org; Wed, 12 Jan 2005 16:07:07 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 22A2211D825; Wed, 12 Jan 2005 12:52:28 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] Network management authorization Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19084@MAANDMBX2.ets.enterasys.com> Date: Wed, 12 Jan 2005 12:52:26 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19084@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 12 Jan 2005 15:47:14 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 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: de4f315c9369b71d7dd5909b42224370 >>>>> On Wed, 12 Jan 2005 15:47:14 -0500, "Nelson, David" said: David> Last time I looked, Kerberos had no concept of Authorization David> (not to mention Accounting. Don't worry, it still doesn't. However, my example was about a scenario, not that it used kerberos (I should have made it generic; sorry). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:23:46 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 QAA18180; Wed, 12 Jan 2005 16:23:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqC5-0000HX-Uo; Wed, 12 Jan 2005 16:38:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Copdp-0007iJ-JD; Wed, 12 Jan 2005 16:02:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CopUY-0001VT-4Q for isms@megatron.ietf.org; Wed, 12 Jan 2005 15:53: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 PAA13943 for ; Wed, 12 Jan 2005 15:53: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 1Copid-0007Hb-Um for isms@ietf.org; Wed, 12 Jan 2005 16:07:56 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id E0DBE11D825; Wed, 12 Jan 2005 12:53:18 -0800 (PST) From: Wes Hardaker To: Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501122047.j0CKlaWi012220@nutshell.tislabs.com> Date: Wed, 12 Jan 2005 12:53:18 -0800 In-Reply-To: <200501122047.j0CKlaWi012220@nutshell.tislabs.com> (David B. Harrington's message of "Wed, 12 Jan 2005 15:50:53 -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: 30ac594df0e66ffa5a93eb4c48bcb014 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: 1ac7cc0a4cd376402b85bc1961a86ac2 >>>>> On Wed, 12 Jan 2005 15:50:53 -0500, "David B Harrington" said: David> I think everybody is in agreement on that point. I agree with your agreement on our agreement. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 16:53: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 QAA21265; Wed, 12 Jan 2005 16:53:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coqeq-0001JG-8M; Wed, 12 Jan 2005 17:08:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CoqGn-0002q1-UF; Wed, 12 Jan 2005 16:43:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Coq2G-00041c-V5 for isms@megatron.ietf.org; Wed, 12 Jan 2005 16:28: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 QAA19152 for ; Wed, 12 Jan 2005 16:28:11 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CoqGK-0000XE-Jg for isms@ietf.org; Wed, 12 Jan 2005 16:42:47 -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 j0CLRZZY022989; Wed, 12 Jan 2005 13:27:35 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0CLRbR9026374; Wed, 12 Jan 2005 13:27:37 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0CLRbB2026367; Wed, 12 Jan 2005 13:27:37 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 12 Jan 2005 13:27:37 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Randy Presuhn Subject: Re: [Isms] Network management authorization In-Reply-To: <002f01c4f847$ab0f7560$7f1afea9@oemcomputer> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 HI, We can talk about changes that make the SNMPv3 authorization system easier to deploy and keep operational. Wes and I have chatted much about this. However, it's out of scope, and it really seemed to us that it was a separable and mostly independent work with the SBSM approach. Maybe at the next IETF we could have a BOF to talk about authorization issues, and present some solutions. On Tue, 11 Jan 2005, Randy Presuhn wrote: > > 4) Authorization is out of scope of the ISMS WG. However, > > there are several approaches that can be supported > > by SBSM to make deployment and ongoing use of SNMP > > easier. The most obvious is to not use table > > vacmSecurityToGroupTable, and instead get the > > group using the mechanism used for authentication > > (such as from a Radius server). > ... > > It may be out of scope, but I think failing to address this issue > would be a big mistake. If no mechanism (like the one > suggested) is provided, the the "integration" won't work until > the security administrator uses SNMPv3 to configure the > vacmSecurityToGroupTable, either manually or using something > like the dead MIASMA proposal. > > Randy Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 19:05: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 TAA01554; Wed, 12 Jan 2005 19:05:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cosj1-0003yg-VU; Wed, 12 Jan 2005 19:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosIV-0002OV-BI; Wed, 12 Jan 2005 18:53:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cos50-0008Df-8H for isms@megatron.ietf.org; Wed, 12 Jan 2005 18:39: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 SAA29523 for ; Wed, 12 Jan 2005 18:39:07 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CosJ3-0003On-Rk for isms@ietf.org; Wed, 12 Jan 2005 18:53:45 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 32C7AD5EF; Thu, 13 Jan 2005 00:38:34 +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 03373-02; Thu, 13 Jan 2005 00:38:33 +0100 (CET) Received: from james (Ib8c7.i.pppool.de [85.73.184.199]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 1BF90B903; Thu, 13 Jan 2005 00:38:33 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cos4O-0000nI-6S; Thu, 13 Jan 2005 00:38:32 +0100 Date: Thu, 13 Jan 2005 00:38:32 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Network management authorization Message-ID: <20050112233832.GC2895@james> Mail-Followup-To: David B Harrington , 'Wes Hardaker' , isms@ietf.org References: <200501122042.PAA12448@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501122042.PAA12448@ietf.org> 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, Jan 12, 2005 at 03:41:41PM -0500, David B Harrington wrote: > That is, allow TLS ir IPSec or other lower layer security mechanism to > provide message sendser authentication, integrity checking, > confidentiality, etc., to transport the SNMP request securely. In > this way, the lower layer security might be host-to-host > authentication, using existing protocols for that purpose; the lower > layer might set up a secure association between message sender and > message receiver. > > Then pass the payload to the SNMP engine, which authenticates the user > identity in the payload, and that authenticated user identity will be > used for authorization purposes. This could be > application-session-based if desired, to minimize overhead, and could > use centralized services, to reduce administration costs. I have learned recently on this list that you have to cryptographically tie these things together to prevent man-in-the-middle attacks. > This separation of transport security from application security could > simplify some aspects of SNMPv3. Such a proposal would require a good > look at the necessary bindings between the different security systems. I guess passing the securityName up will be simpler than the binding but I am happy to be proven wrong. /js [BTW, nice discussions after ten years of work an SNMP security. ;-] -- 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 Jan 12 19:07:52 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 TAA01748; Wed, 12 Jan 2005 19:07:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Coskv-00041s-On; Wed, 12 Jan 2005 19:22:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosMw-0003Ef-1h; Wed, 12 Jan 2005 18:57:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CosBv-00014T-Q1 for isms@megatron.ietf.org; Wed, 12 Jan 2005 18:46: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 SAA00063 for ; Wed, 12 Jan 2005 18:46:17 -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 1CosQ2-0003YK-3M for isms@ietf.org; Wed, 12 Jan 2005 19:00:55 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DE65511D825; Wed, 12 Jan 2005 15:46:13 -0800 (PST) From: Wes Hardaker To: David B Harrington Subject: Re: [Isms] Network management authorization Organization: Sparta References: <200501122042.PAA12448@ietf.org> <20050112233832.GC2895@james> Date: Wed, 12 Jan 2005 15:46:13 -0800 In-Reply-To: <20050112233832.GC2895@james> (Juergen Schoenwaelder's message of "Thu, 13 Jan 2005 00:38: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: d17f825e43c9aed4fd65b7edddddec89 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: cf4fa59384e76e63313391b70cd0dd25 >>>>> On Thu, 13 Jan 2005 00:38:32 +0100, Juergen Schoenwaelder said: Juergen> [BTW, nice discussions after ten years of work an SNMP security. ;-] The question is: will it matter? We're having a huge discussion, the results of which may not matter if the evaluation team proclaims a totally different approach. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 21:50: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 VAA12221; Wed, 12 Jan 2005 21:50:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CovIk-0007HL-Cf; Wed, 12 Jan 2005 22:05:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cov3o-0004Vy-Dd; Wed, 12 Jan 2005 21:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cov1v-0003tY-Oz for isms@megatron.ietf.org; Wed, 12 Jan 2005 21:48: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 VAA12054 for ; Wed, 12 Jan 2005 21:48:10 -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 1CovG3-0007Ds-OX for isms@ietf.org; Wed, 12 Jan 2005 22:02:49 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065c32.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cov1t-0004ZN-00 for isms@ietf.org; Wed, 12 Jan 2005 18:48:09 -0800 Message-ID: <001b01c4f91a$72341ba0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501122042.PAA12448@ietf.org> <20050112233832.GC2895@james> Subject: Re: [Isms] Network management authorization Date: Wed, 12 Jan 2005 18:49:05 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 9182cfff02fae4f1b6e9349e01d62f32 Hi - > From: "Wes Hardaker" > To: "David B Harrington" > Cc: > Sent: Wednesday, January 12, 2005 3:46 PM > Subject: Re: [Isms] Network management authorization ... > The question is: will it matter? We're having a huge discussion, the > results of which may not matter if the evaluation team proclaims > a totally different approach. ... Huh? The WG is perfectly free to ignore the evaluation team's recommendations. RFC2418 (section 6.5) is abundantly clear on this point. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 22:03:45 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 WAA12796; Wed, 12 Jan 2005 22:03:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CovVA-0007Th-4T; Wed, 12 Jan 2005 22:18:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cov6u-00054X-47; Wed, 12 Jan 2005 21:53:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cov3z-0004dR-1b for isms@megatron.ietf.org; Wed, 12 Jan 2005 21:50: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 VAA12184 for ; Wed, 12 Jan 2005 21:50:17 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CovI5-0007GZ-1h for isms@ietf.org; Wed, 12 Jan 2005 22:04:56 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1Cov3u-0001dV-5H; Wed, 12 Jan 2005 21:50:14 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j0D2oC603101; Wed, 12 Jan 2005 18:50:12 -0800 Date: Wed, 12 Jan 2005 18:50:12 -0800 (PST) From: Bernard Aboba To: Joseph Salowey Subject: RE: [Isms] RE: Network management authorization In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 > With EUSM we selected using EAP because of the integration possibilities > with back end AAA authentication mechanisms. Integration with the AAA server is achievable regardless of whether the protocol on the wire between the Manager and Agent is EAP. For example, an authentication method could be embedded within SNMP without EAP encapsulation, and then the agent could encapsulate the authentication method within AAA/EAP in talking to the AAA server. Alternatively, rather than speaking EAP/AAA, the AAA client could use new AAA attributes could be defined to handle a particular authentication method (as is being done for SIP Digest). However, this approach is less general. > We had envisioned two modes of operation: > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > then it can establish keys with AAA server using RADIUS which then can cache > them and localize them for each agent as needed. Here EAP is encapsulated > in RADIUS. I guess you have decide whether the Manager/Client or Agent plays the role of the AAA client. Since there are typically only a few Managers and lots of Agents, it might make sense for the Manager to act in the role of the NAS, and the Agents to act as users requesting authentication. That way there are a lot fewer RADIUS shared secrets to distribute. I guess that in this particular case, the NAS/Manager/Client might be initiating a particular authentication method, rather than starting off with an Identity exchange, but that can be handled within RFC 3579. > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA > server then the key negotiation would initiate between the SNMP > Manager/Client and SNMP Agent and would be proxied to AAA over RADIUS if > applicable. We did not encapsulate EAP in SNMP since this would be a big > change to the SNMP protocol but instead choose to encapsulate it in an out > of band protocol to leverage existing work. The protocols we had in mind > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or > IKEv2, but other arrangements are possible. > > The second mode allows for operation without AAA. As you say, you could use IKEv2 w/EAP to derive keys to protect SNMP via IPsec. This would be somewhat unusual with Transport Mode (I think the EAP functionality in IKEv2 was created for largely for use with tunnel mode), but it would more or less work as you describe, with or without a AAA server. Since EAP functionality is officially part of the IKEv2 spec, this is like any other use of IKEv2/IPsec and doesn't run afoul of RFC 3748, 3579 or anything else, as far as I can tell. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 12 23:23: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 XAA17620; Wed, 12 Jan 2005 23:23:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cowkd-0000Wl-Pc; Wed, 12 Jan 2005 23:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CowVm-0006hM-Fw; Wed, 12 Jan 2005 23:23:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CowLo-0004QN-84 for isms@megatron.ietf.org; Wed, 12 Jan 2005 23:12: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 XAA17159 for ; Wed, 12 Jan 2005 23:12:43 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CowZu-0000L5-Vd for isms@ietf.org; Wed, 12 Jan 2005 23:27:23 -0500 Received: from h-66-167-207-234.snvacaid.dynamic.covad.net ([66.167.207.234] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CowLj-0005Wv-00 for isms@ietf.org; Wed, 12 Jan 2005 20:12:43 -0800 Message-ID: <000401c4f926$42b750c0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: Subject: Re: [Isms] RE: Network management authorization Date: Wed, 12 Jan 2005 20:13:39 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 52e1467c2184c31006318542db5614d5 Hi - > From: "Bernard Aboba" > To: "Joseph Salowey" > Cc: > Sent: Wednesday, January 12, 2005 6:50 PM > Subject: RE: [Isms] RE: Network management authorization ... > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > > then it can establish keys with AAA server using RADIUS which then can cache > > them and localize them for each agent as needed. Here EAP is encapsulated > > in RADIUS. > > I guess you have decide whether the Manager/Client or Agent plays the role > of the AAA client. Since there are typically only a few Managers and lots > of Agents, it might make sense for the Manager to act in the role of the > NAS, and the Agents to act as users requesting authentication. That way > there are a lot fewer RADIUS shared secrets to distribute. ... "Managers" and "agents" are just particular combinations of applications making use of an SNMP protocol engine. Furthermore, "managers" and "agents" frequently exist in many-to-very-many relationships, and "dual role" systems abound. Consequently, I suspect SNMP engines in general would need to play the role of AAA client. We went to a lot of effort to get rid of the manager/agent dichotomy in SNMPv3. Let's not bring back that not-too-helpful distinction. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 13 13:54: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 NAA03514; Thu, 13 Jan 2005 13:54:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAL8-00034m-DB; Thu, 13 Jan 2005 14:09:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9xW-0004IJ-JH; Thu, 13 Jan 2005 13:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9rB-0002Mp-LM for isms@megatron.ietf.org; Thu, 13 Jan 2005 13:38: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 NAA02404 for ; Thu, 13 Jan 2005 13:38:01 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpA5O-0002gL-Py for isms@ietf.org; Thu, 13 Jan 2005 13:52:51 -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 j0DIbenm014546; Thu, 13 Jan 2005 13:37:41 -0500 (EST) Message-Id: <200501131837.j0DIbenm014546@ginger.cmf.nrl.navy.mil> To: ietfdbh@comcast.net Subject: Re: [Isms] Evaluation process? In-Reply-To: <200501101741.j0AHfTri013656@ginger.cmf.nrl.navy.mil> 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, 13 Jan 2005 13:37:41 -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: 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 First off, let me offer my apologies to everyone for not being more responsive. The holidays combined with me getting sick really sucked up my available time. But enough excuses. >> I think we are still fine if we have a recommendation from >> the evaluation >> team before Christmas. > >Do you still think we are fine? "Yes" .... but actually, I think to be fine, I'd rather see a recommendation by the end of January rather than the I-D cutoff date. >[...] >Do you still feel we will have adequate time to agree or disagree on >the mailing list before the next meeting in March? >[...] >Do you still feel we will have adequate time to discuss a new charter >before the next meeting in March? Yes to both, if we make some serious progress on the evaluation. There was some talk of scheduling a phone conference between the evaluation team members; I will try to make that happen ASAP. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 13 13:56: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 NAA03753; Thu, 13 Jan 2005 13:56:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpAN6-00038C-2C; Thu, 13 Jan 2005 14:11:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9xp-0004Oi-S5; Thu, 13 Jan 2005 13:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cp9ux-0003Sh-LO for isms@megatron.ietf.org; Thu, 13 Jan 2005 13:41: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 NAA02775 for ; Thu, 13 Jan 2005 13:41:56 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpA9B-0002m8-VL for isms@ietf.org; Thu, 13 Jan 2005 13:56:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Jan 2005 10:47:05 -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 j0DIfGjw007691; Thu, 13 Jan 2005 10:41:22 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-71-254-244.cisco.com [171.71.254.244]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXG25871; Thu, 13 Jan 2005 10:41:14 -0800 (PST) Message-Id: <6.2.0.14.0.20050113100936.04d90ec0@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 13 Jan 2005 10:30:10 -0800 To: Bernard Aboba From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Hi Bernard, Please find my reply inline. At 06:50 PM 1/12/2005, Bernard Aboba wrote: > > With EUSM we selected using EAP because of the integration possibilities > > with back end AAA authentication mechanisms. > >Integration with the AAA server is achievable regardless of whether the >protocol on the wire between the Manager and Agent is EAP. For example, >an authentication method could be embedded within SNMP without EAP >encapsulation, and then the agent could encapsulate the authentication >method within AAA/EAP in talking to the AAA server. Alternatively, >rather than speaking EAP/AAA, the AAA client could use new >AAA attributes could be defined to handle a particular authentication >method (as is being done for SIP Digest). However, this approach is less >general. The primary motivation to use the existing model with EAP is since one of the goals of the proposal was to retain most of the existing SNMPv3 packet processing and not require additional attributes to be passed between the SNMPv3 engines part of the new SNMPv3 security model to reduce the churn to the thousands of agents. > > We had envisioned two modes of operation: > > > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > > then it can establish keys with AAA server using RADIUS which then can > cache > > them and localize them for each agent as needed. Here EAP is encapsulated > > in RADIUS. > >I guess you have decide whether the Manager/Client or Agent plays the role >of the AAA client. Since there are typically only a few Managers and lots >of Agents, it might make sense for the Manager to act in the role of the >NAS, and the Agents to act as users requesting authentication. That way >there are a lot fewer RADIUS shared secrets to distribute. > >I guess that in this particular case, the NAS/Manager/Client might be >initiating a particular authentication method, rather than starting off >with an Identity exchange, but that can be handled within RFC 3579. Actually the shared secret management for SNMPv3 agents should not be a problem that most of SNMPv3 agents would have shared secrets already setup for AAA for the CLI interface, since the proposal will primarily allow customers to use existing infrastructure that is used for CLI and other management protocols for SNMPv3 authentication. regards, kaushik! > > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA > > server then the key negotiation would initiate between the SNMP > > Manager/Client and SNMP Agent and would be proxied to AAA over RADIUS if > > applicable. We did not encapsulate EAP in SNMP since this would be a big > > change to the SNMP protocol but instead choose to encapsulate it in an out > > of band protocol to leverage existing work. The protocols we had in mind > > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or > > IKEv2, but other arrangements are possible. > > > > The second mode allows for operation without AAA. > >As you say, you could use IKEv2 w/EAP to derive keys to protect SNMP via >IPsec. >This would be somewhat unusual with Transport Mode (I think the EAP >functionality >in IKEv2 was created for largely for use with tunnel mode), but it would >more or less work as you describe, with or without a AAA server. > >Since EAP functionality is officially part of the IKEv2 spec, this >is like any other use of IKEv2/IPsec and doesn't run afoul of RFC 3748, >3579 or anything else, as far as I can tell. > >_______________________________________________ >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 Jan 13 17:07: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 RAA27880; Thu, 13 Jan 2005 17:07:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpDMa-0001sI-UT; Thu, 13 Jan 2005 17:22:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpCnd-0002jU-Jc; Thu, 13 Jan 2005 16:46:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpCAq-0007Ul-C5 for isms@megatron.ietf.org; Thu, 13 Jan 2005 16:06: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 QAA16428 for ; Thu, 13 Jan 2005 16:06:29 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpCP7-0006U5-Tj for isms@ietf.org; Thu, 13 Jan 2005 16:21:19 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CpCAn-000KHS-Nu; Thu, 13 Jan 2005 16:06:29 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j0DL6SS05108; Thu, 13 Jan 2005 13:06:28 -0800 Date: Thu, 13 Jan 2005 13:06:28 -0800 (PST) From: Bernard Aboba To: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <6.2.0.14.0.20050113100936.04d90ec0@mira-sjc5-a.cisco.com> Message-ID: References: <6.2.0.14.0.20050113100936.04d90ec0@mira-sjc5-a.cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 > The primary motivation to use the existing model with EAP is since one of the > goals of the proposal was to retain most of the existing SNMPv3 packet > processing and not require additional attributes to be passed between the > SNMPv3 engines part of the new SNMPv3 security model to reduce the > churn to the thousands of agents. AAA attributes are only passed from the AAA server to the AAA client, no? Since only the SNMP agent or manager would act as a AAA client, I'm not sure how AAA attributes end up on the wire between the agent and manager. Since RADIUS requires a shared secret to be established between the RADIUS client and server, if the agent and manager could speak RADIUS, then that implies they have a shared secret. I thought that was the provisioning problem we were trying to avoid here. > Actually the shared secret management for SNMPv3 agents should not > be a problem that most of SNMPv3 agents would have shared secrets > already setup for AAA for the CLI interface, since the proposal will > primarily allow customers to use existing infrastructure that is used > for CLI and other management protocols for SNMPv3 authentication. If you're not worried about this, then the agent could serve as a AAA client, and the Manager would act as a user. Of course then the agents would need to receive and interpret AAA attributes. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 13 20:43: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 UAA15053; Thu, 13 Jan 2005 20:43:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpGjM-0006Xv-Gz; Thu, 13 Jan 2005 20:58:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpGRP-0007NY-Li; Thu, 13 Jan 2005 20: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 1CpGQR-0006ld-FX for isms@megatron.ietf.org; Thu, 13 Jan 2005 20:38:55 -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 UAA14685 for ; Thu, 13 Jan 2005 20:38:53 -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 1CpGej-0006QP-Bk for isms@ietf.org; Thu, 13 Jan 2005 20:53:44 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 13 Jan 2005 17:41:49 -0800 Received: from mira-sjc5-a.cisco.com (IDENT:mirapoint@mira-sjc5-a.cisco.com [171.71.163.34]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0E1cIvl021882; Thu, 13 Jan 2005 17:38:19 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-71-254-244.cisco.com [171.71.254.244]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXG68990; Thu, 13 Jan 2005 17:38:16 -0800 (PST) Message-Id: <6.2.0.14.0.20050113172658.047c6280@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 13 Jan 2005 17:38:10 -0800 To: Bernard Aboba From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: References: <6.2.0.14.0.20050113100936.04d90ec0@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: 4b800b1eab964a31702fa68f1ff0e955 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: d8ae4fd88fcaf47c1a71c804d04f413d Hi Bernard, Please find my reply inline. At 01:06 PM 1/13/2005, Bernard Aboba wrote: > > The primary motivation to use the existing model with EAP is since one > of the > > goals of the proposal was to retain most of the existing SNMPv3 packet > > processing and not require additional attributes to be passed between the > > SNMPv3 engines part of the new SNMPv3 security model to reduce the > > churn to the thousands of agents. > >AAA attributes are only passed from the AAA server to the AAA client, no? >Since only the SNMP agent or manager would act as a AAA client, I'm not >sure how AAA attributes end up on the wire between the agent and >manager. Since RADIUS requires a shared secret to be established between >the RADIUS client and server, if the agent and manager could speak >RADIUS, then that implies they have a shared secret. I thought that was >the provisioning problem we were trying to avoid here. AAA attributes are never directly passed between the SNMP agent and manager. The SNMP agent is a AAA client will need a shared secret, it would already have a shared secret for CLI AAA. The SNMP manager will negotiate the key with the AAA server either directly in which case it would need a shared secret. In the other model, the key negotiation would use EAP between the SNMP manager and agent, the agent will proxy the request to AAA over RADIUS if applicable. In most cases we are not requiring any new credential provisioning since for thousands of agents, they already have a shared secret. The credential provisioning problem that ISMS is trying to solve is actually with provisioning of users and user credentials. The problem is that the current SNMPv3 USM specification requires that every agent has it's own user repository and there is no way to integrate it with existing user/AAA infrastructure. This is clearly not scale able and also does not integrate well in customer environments and has been a significant barrier to deployment for SNMPv3. > > Actually the shared secret management for SNMPv3 agents should not > > be a problem that most of SNMPv3 agents would have shared secrets > > already setup for AAA for the CLI interface, since the proposal will > > primarily allow customers to use existing infrastructure that is used > > for CLI and other management protocols for SNMPv3 authentication. > >If you're not worried about this, then the agent could serve >as a AAA client, and the Manager would act as a user. Of course then the >agents would need to receive and interpret AAA attributes. That's pretty close to our proposal and agents are already AAA clients since they process AAA attributes for CLIs. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 14 12:53:00 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 MAA01435; Fri, 14 Jan 2005 12:53:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpVrd-0008TN-BA; Fri, 14 Jan 2005 13:08:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpVT4-0000gP-M8; Fri, 14 Jan 2005 12:42:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpVOI-0007h1-TT for isms@megatron.ietf.org; Fri, 14 Jan 2005 12:37: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 MAA00577 for ; Fri, 14 Jan 2005 12:37:40 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpVcj-0008AU-RU for isms@ietf.org; Fri, 14 Jan 2005 12:52:39 -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 j0EHb7ZY022216; Fri, 14 Jan 2005 09:37:07 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0EHbAZ7010874; Fri, 14 Jan 2005 09:37:10 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0EHbAnN010871; Fri, 14 Jan 2005 09:37:10 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 14 Jan 2005 09:37:10 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <6.2.0.14.0.20050113172658.047c6280@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: 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 HI, On Thu, 13 Jan 2005, Kaushik Narayan wrote: ... > In the other model, the key negotiation > would use EAP between the SNMP manager and agent, the agent will proxy the > request to AAA over RADIUS if applicable. In the -00 draft, I didn't see the details for this approach. Did I miss them, or are they available in an update? Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 14 17:38: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 RAA02678; Fri, 14 Jan 2005 17:38:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpaJn-0000nz-I8; Fri, 14 Jan 2005 17:53:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpZqz-0007qA-0q; Fri, 14 Jan 2005 17: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 1CpZmJ-0005al-7W for isms@megatron.ietf.org; Fri, 14 Jan 2005 17:18: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 RAA01008 for ; Fri, 14 Jan 2005 17:18:45 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpa0p-0000Kp-97 for isms@ietf.org; Fri, 14 Jan 2005 17:33:47 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-4.cisco.com with ESMTP; 14 Jan 2005 14:18:36 -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 j0EMIDjw010791; Fri, 14 Jan 2005 14:18:13 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-69-126-196.cisco.com [171.69.126.196]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXH58641; Fri, 14 Jan 2005 14:18:12 -0800 (PST) Message-Id: <6.2.0.14.0.20050114135906.047dbd70@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 14 Jan 2005 14:18:11 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: References: <6.2.0.14.0.20050113172658.047c6280@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: 9182cfff02fae4f1b6e9349e01d62f32 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Hi David, This is described in the -00 draft. Section 2 provides the description and Figure 2 in the draft illustrates the flow. regards, kaushik! At 09:37 AM 1/14/2005, David T. Perkins wrote: >HI, > > >On Thu, 13 Jan 2005, Kaushik Narayan wrote: >... > > > In the other model, the key negotiation > > would use EAP between the SNMP manager and agent, the agent will proxy the > > request to AAA over RADIUS if applicable. > >In the -00 draft, I didn't see the details for this approach. >Did I miss them, or are they available in an update? > >Regards, >/david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 14 18:59: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 SAA08888; Fri, 14 Jan 2005 18:59:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cpban-0002Nv-L7; Fri, 14 Jan 2005 19:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpbJB-0008Eg-3c; Fri, 14 Jan 2005 18:56:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CpbEt-00079k-Ro for isms@megatron.ietf.org; Fri, 14 Jan 2005 18:52: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 SAA08463 for ; Fri, 14 Jan 2005 18:52:20 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CpbTO-0002EI-J4 for isms@ietf.org; Fri, 14 Jan 2005 19:07:24 -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 j0ENoiZY022344; Fri, 14 Jan 2005 15:50:44 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0ENolU1005987; Fri, 14 Jan 2005 15:50:47 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0ENokJa005977; Fri, 14 Jan 2005 15:50:47 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 14 Jan 2005 15:50:46 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <6.2.0.14.0.20050114135906.047dbd70@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: 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, Yes, I know the -00 draft contained a diagram. But did it include the DETAILS, that is, describe the contents of the SNMP messages between a "manager" and "agent". What info is in the messages, and what is the syntax of the messages. I didn't see that in section 2, or elsewhere in the document. On Fri, 14 Jan 2005, Kaushik Narayan wrote: > Hi David, > > This is described in the -00 draft. Section 2 provides the description > and Figure 2 in the draft illustrates the flow. > > > regards, > kaushik! > > At 09:37 AM 1/14/2005, David T. Perkins wrote: > >HI, > > > > > >On Thu, 13 Jan 2005, Kaushik Narayan wrote: > >... > > > > > In the other model, the key negotiation > > > would use EAP between the SNMP manager and agent, the agent will proxy the > > > request to AAA over RADIUS if applicable. > > > >In the -00 draft, I didn't see the details for this approach. > >Did I miss them, or are they available in an update? > > > >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 Sun Jan 16 12:16: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 MAA28584; Sun, 16 Jan 2005 12:16:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqEG9-0006BP-Ea; Sun, 16 Jan 2005 12:32:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqDz6-0002UU-QI; Sun, 16 Jan 2005 12:14:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqDoJ-0005Wh-GO for isms@megatron.ietf.org; Sun, 16 Jan 2005 12:03: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 MAA27099 for ; Sun, 16 Jan 2005 12:03:28 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqE3B-0005i9-6F for isms@ietf.org; Sun, 16 Jan 2005 12:18:54 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0GEQa003759; Sun, 16 Jan 2005 09:26:36 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 16 Jan 2005 09:26:35 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B708@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Bernard Aboba'" , Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization Date: Sun, 16 Jan 2005 09:26:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0098839244==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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. --===============0098839244== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FBD7.5F4754B0" 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_01C4FBD7.5F4754B0 Content-Type: text/plain > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Bernard Aboba > > The primary motivation to use the existing model with EAP is since one > of the > > goals of the proposal was to retain most of the existing SNMPv3 packet > > processing and not require additional attributes to be passed between > the > > SNMPv3 engines part of the new SNMPv3 security model to reduce the > > churn to the thousands of agents. > > AAA attributes are only passed from the AAA server to the AAA client, no? > Since only the SNMP agent or manager would act as a AAA client, I'm not > sure how AAA attributes end up on the wire between the agent and > manager. Since RADIUS requires a shared secret to be established between > the RADIUS client and server, if the agent and manager could speak > RADIUS, then that implies they have a shared secret. I thought that was > the provisioning problem we were trying to avoid here. I believe we are trying to solve the problem of provisioning attributes "per user". Solving the problem of provisioning connectivity of the client and server is a separate issue IMO (which needs to be solved, but not here). You raise a good point about the carrying of AAA attributes. Really, what makes sense to me is that both parts of the SNMP communication are AAA clients, and that the AAA exchanges provide information to each party that allow their authenticated communication through the existing USM mechanism. I think this is quite possible, but requires the definition of (possibly various) mechanisms of AAA servers providing key information to these parties. I also think it critical that the USM key authenticator not have access to any of the user AAA information (e.g. credentials) but only the SNMPv3 keys for a specific session. Martin. ------_=_NextPart_001_01C4FBD7.5F4754B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management authorization

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Bernard Aboba
> > The primary motivation to use the existing = model with EAP is since one
> of the
> > goals of the proposal was to retain most = of the existing SNMPv3 packet
> > processing and not require additional = attributes to be passed between
> the
> > SNMPv3 engines part of the new SNMPv3 = security model to reduce the
> > churn to the thousands of agents.
>
> AAA attributes are only passed from the AAA = server to the AAA client, no?
> Since only the SNMP agent or manager would act = as a AAA client, I'm not
> sure how AAA attributes end up on the wire = between the agent and
> manager.  Since RADIUS requires a shared = secret to be established between
> the RADIUS client and server, if the agent and = manager could speak
> RADIUS, then that implies they have a shared = secret.  I thought that was
> the provisioning problem we were trying to = avoid here.

I believe we are trying to solve the problem of = provisioning attributes "per user". Solving the problem of = provisioning connectivity of the client and server is a separate issue = IMO (which needs to be solved, but not here).

You raise a good point about the carrying of AAA = attributes. Really, what makes sense to me is that both parts of the = SNMP communication are AAA clients, and that the AAA exchanges provide = information to each party that allow their authenticated communication = through the existing USM mechanism. I think this is quite possible, but = requires the definition of (possibly various) mechanisms of AAA servers = providing key information to these parties. I also think it critical = that the USM key authenticator not have access to any of the user AAA = information (e.g. credentials) but only the SNMPv3 keys for a specific = session.

Martin.

------_=_NextPart_001_01C4FBD7.5F4754B0-- --===============0098839244== 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 --===============0098839244==-- From isms-bounces@ietf.org Mon Jan 17 01:32: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 BAA21783; Mon, 17 Jan 2005 01:32:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqQgb-0003nZ-W1; Mon, 17 Jan 2005 01:48:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqQQo-0002OY-CM; Mon, 17 Jan 2005 01:32:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqQOU-00021E-PK for isms@megatron.ietf.org; Mon, 17 Jan 2005 01:29: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 BAA21570 for ; Mon, 17 Jan 2005 01:29:41 -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 1CqQdT-0003j4-Td for isms@ietf.org; Mon, 17 Jan 2005 01:45:13 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2005 23:36:17 +0000 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 j0H6T8jw014050; Sun, 16 Jan 2005 22:29:08 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn7-93.cisco.com [10.21.144.93]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXI23593; Sun, 16 Jan 2005 22:29:07 -0800 (PST) Message-Id: <6.2.0.14.0.20050116222454.049846d0@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 16 Jan 2005 22:29:07 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: References: <6.2.0.14.0.20050114135906.047dbd70@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: 538aad3a3c4f01d8b6a6477ca4248793 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: f4c2cf0bccc868e4cc88dace71fb3f44 Hi David, As stated previously the EUSM proposal attempts to minimize the changes to SNMPv3. The only change to the SNMPv3 packet is the introduction of a new security mode. The key negotiation uses Key_Setup protocol that runs out-of-band to the SNMPv3 communication and keys derived from Key_Setup protocol are then used to secure SNMPv3 communication. regards, kaushik! At 03:50 PM 1/14/2005, David T. Perkins wrote: >HI, > >Yes, I know the -00 draft contained a diagram. But did >it include the DETAILS, that is, describe the contents of >the SNMP messages between a "manager" and "agent". >What info is in the messages, and what is the syntax >of the messages. I didn't see that in section 2, >or elsewhere in the document. > >On Fri, 14 Jan 2005, Kaushik Narayan wrote: > > Hi David, > > > > This is described in the -00 draft. Section 2 provides the description > > and Figure 2 in the draft illustrates the flow. > > > > > > regards, > > kaushik! > > > > At 09:37 AM 1/14/2005, David T. Perkins wrote: > > >HI, > > > > > > > > >On Thu, 13 Jan 2005, Kaushik Narayan wrote: > > >... > > > > > > > In the other model, the key negotiation > > > > would use EAP between the SNMP manager and agent, the agent will > proxy the > > > > request to AAA over RADIUS if applicable. > > > > > >In the -00 draft, I didn't see the details for this approach. > > >Did I miss them, or are they available in an update? > > > > > >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 Jan 17 11:52: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 LAA23182; Mon, 17 Jan 2005 11:52:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqaLr-0000r6-Vl; Mon, 17 Jan 2005 12:07:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZxl-0002nF-DM; Mon, 17 Jan 2005 11:42:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqZqi-0001VS-GW for isms@megatron.ietf.org; Mon, 17 Jan 2005 11:35: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 LAA21329 for ; Mon, 17 Jan 2005 11:35:24 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqa5m-0000Nz-1O for isms@ietf.org; Mon, 17 Jan 2005 11:51:03 -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 j0HGYoZY007389; Mon, 17 Jan 2005 08:34:50 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0HGYreb008605; Mon, 17 Jan 2005 08:34:53 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0HGYrQi008600; Mon, 17 Jan 2005 08:34:53 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Mon, 17 Jan 2005 08:34:53 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <6.2.0.14.0.20050116222454.049846d0@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: 6cca30437e2d04f45110f2ff8dc1b1d5 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: 31247fb3be228bb596db9127becad0bc HI, I'm confused by your answer. In section 2, there a is paragraph that starts with... "The second scheme described in the figure below is similar to EAP exchanges used in 802.1x environments." There is not enough detail present for me to understand how this second scheme works. Do you have plans for expanding this? Do you have any other info, such as packet traces? Also, how do you see the configuration setup in the manager so that it would know that it shoudl use the second form? How much additional code do you see in the manager and agent to support the second form? And to I correctly understand your description that a new, yet to be defined, protocol is used? On Sun, 16 Jan 2005, Kaushik Narayan wrote: > Hi David, > > As stated previously the EUSM proposal attempts to minimize the changes to > SNMPv3. The only change to the SNMPv3 packet is the introduction of a new > security mode. > > The key negotiation uses Key_Setup protocol that runs out-of-band to the > SNMPv3 communication and keys derived from Key_Setup protocol are then > used to secure SNMPv3 communication. > > regards, > kaushik! > > At 03:50 PM 1/14/2005, David T. Perkins wrote: > >HI, > > > >Yes, I know the -00 draft contained a diagram. But did > >it include the DETAILS, that is, describe the contents of > >the SNMP messages between a "manager" and "agent". > >What info is in the messages, and what is the syntax > >of the messages. I didn't see that in section 2, > >or elsewhere in the document. > > > >On Fri, 14 Jan 2005, Kaushik Narayan wrote: > > > Hi David, > > > > > > This is described in the -00 draft. Section 2 provides the description > > > and Figure 2 in the draft illustrates the flow. > > > > > > > > > regards, > > > kaushik! > > > > > > At 09:37 AM 1/14/2005, David T. Perkins wrote: > > > >HI, > > > > > > > > > > > >On Thu, 13 Jan 2005, Kaushik Narayan wrote: > > > >... > > > > > > > > > In the other model, the key negotiation > > > > > would use EAP between the SNMP manager and agent, the agent will > > proxy the > > > > > request to AAA over RADIUS if applicable. > > > > > > > >In the -00 draft, I didn't see the details for this approach. > > > >Did I miss them, or are they available in an update? > > > > > > > >Regards, > > > >/david t. perkins > > > > >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 Jan 17 15:52:50 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 PAA13722; Mon, 17 Jan 2005 15:52:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqe6w-0006vN-6D; Mon, 17 Jan 2005 16:08:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqdmy-0001YZ-MU; Mon, 17 Jan 2005 15:47:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqdiW-0007ML-HB for isms@megatron.ietf.org; Mon, 17 Jan 2005 15:43: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 PAA12983 for ; Mon, 17 Jan 2005 15:43:14 -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 1Cqdxe-0006YI-3F for isms@ietf.org; Mon, 17 Jan 2005 15:58:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 17 Jan 2005 13:49:58 +0000 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-1.cisco.com (8.12.10/8.12.6) with ESMTP id j0HKgfvl003096; Mon, 17 Jan 2005 12:42:42 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-69-71-250.cisco.com [171.69.71.250]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXI68625; Mon, 17 Jan 2005 12:42:40 -0800 (PST) Message-Id: <6.2.0.14.0.20050117122543.04a269a8@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 17 Jan 2005 12:42:39 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: References: <6.2.0.14.0.20050116222454.049846d0@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: 36c793b20164cfe75332aa66ddb21196 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: 1676547e4f33b5e63227e9c02bd359e3 Hi David, Please find my reply inline. At 08:34 AM 1/17/2005, David T. Perkins wrote: >HI, > >I'm confused by your answer. >In section 2, there a is paragraph that starts with... >"The second scheme described in the figure below is >similar to EAP exchanges used in 802.1x environments." >There is not enough detail present for me to understand >how this second scheme works. > >Do you have plans for expanding this? Do you have any >other info, such as packet traces? The reason this has not been expanded since EAP exchanges used by the Key_Setup_Protocol are captured in the RADIUS/EAP specification (RFC 3579) and we did not want to put redundant information. >Also, how do you see the configuration setup in the manager >so that it would know that it shoudl use the second form? >How much additional code do you see in the manager and >agent to support the second form? It would pretty straight-forward to drive the Key_Setup mode via a configuration variable. Part of the code required for the agent is already available (i.e. RADIUS/EAP code to talk a RADIUS server), we need plug the code in to terminate EAP transport protocol and there needs to code on the manager to initiate EAP messages over the EAP transport protocol. We pretty much leverage existing implementation of EAP message handling and the EAP methods. >And to I correctly understand your description that a new, >yet to be defined, protocol is used? We are not trying to define a new protocol but rather re-use an existing EAP transport protocol and there are several options such PANA, IKEv2 etc. Future work on the protocol in the Working Group will help us identify the optimal EAP transport protocol choice. regards, kaushik! >On Sun, 16 Jan 2005, Kaushik Narayan wrote: > > Hi David, > > > > As stated previously the EUSM proposal attempts to minimize the changes to > > SNMPv3. The only change to the SNMPv3 packet is the introduction of a new > > security mode. > > > > The key negotiation uses Key_Setup protocol that runs out-of-band to the > > SNMPv3 communication and keys derived from Key_Setup protocol are then > > used to secure SNMPv3 communication. > > > > regards, > > kaushik! > > > > At 03:50 PM 1/14/2005, David T. Perkins wrote: > > >HI, > > > > > >Yes, I know the -00 draft contained a diagram. But did > > >it include the DETAILS, that is, describe the contents of > > >the SNMP messages between a "manager" and "agent". > > >What info is in the messages, and what is the syntax > > >of the messages. I didn't see that in section 2, > > >or elsewhere in the document. > > > > > >On Fri, 14 Jan 2005, Kaushik Narayan wrote: > > > > Hi David, > > > > > > > > This is described in the -00 draft. Section 2 provides the description > > > > and Figure 2 in the draft illustrates the flow. > > > > > > > > > > > > regards, > > > > kaushik! > > > > > > > > At 09:37 AM 1/14/2005, David T. Perkins wrote: > > > > >HI, > > > > > > > > > > > > > > >On Thu, 13 Jan 2005, Kaushik Narayan wrote: > > > > >... > > > > > > > > > > > In the other model, the key negotiation > > > > > > would use EAP between the SNMP manager and agent, the agent will > > > proxy the > > > > > > request to AAA over RADIUS if applicable. > > > > > > > > > >In the -00 draft, I didn't see the details for this approach. > > > > >Did I miss them, or are they available in an update? > > > > > > > > > >Regards, > > > > >/david t. perkins > > > > > > >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 Tue Jan 18 09:39:12 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 JAA27063; Tue, 18 Jan 2005 09:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqul3-0001BB-Bk; Tue, 18 Jan 2005 09:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CquRh-0001iA-6U; Tue, 18 Jan 2005 09:35:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CquK4-0008UF-S2 for isms@megatron.ietf.org; Tue, 18 Jan 2005 09:27: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 JAA25895 for ; Tue, 18 Jan 2005 09:27:06 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CquZK-0000nW-Sb for isms@ietf.org; Tue, 18 Jan 2005 09:42:56 -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 j0IEPRr09489; Tue, 18 Jan 2005 09:25:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 18 Jan 2005 09:25:27 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B725@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Joseph Salowey'" , "'Bernard Aboba'" , ietfdbh@comcast.net Subject: RE: [Isms] RE: Network management authorization Date: Tue, 18 Jan 2005 09:25:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2109710862==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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. --===============2109710862== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FD64.94F57F90" 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_01C4FD64.94F57F90 Content-Type: text/plain > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Joseph Salowey > > With EUSM we selected using EAP because of the integration possibilities > with back end AAA authentication mechanisms. > > We had envisioned two modes of operation: > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > then it can establish keys with AAA server using RADIUS which then can > cache > them and localize them for each agent as needed. Here EAP is encapsulated > in RADIUS. > > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA > server then the key negotiation would initiate between the SNMP > Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if > applicable. We did not encapsulate EAP in SNMP since this would be a big > change to the SNMP protocol but instead choose to encapsulate it in an out > of band protocol to leverage existing work. The protocols we had in mind > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or > IKEv2, but other arrangements are possible. > > The second mode allows for operation without AAA. So then the Manager (separately from "SNMP") acts as the AAA server when an external/remote AAA server is unavailable or not configured? I think this is a nice solution. I like the idea of supporting USM as-is and providing something in addition to support AAA. Martin. ------_=_NextPart_001_01C4FD64.94F57F90 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management authorization

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Joseph Salowey
>
> With EUSM we selected using EAP because of the = integration possibilities
> with back end AAA authentication = mechanisms.
>
> We had envisioned two modes of = operation:
>
> 1. When the SNMP Manager/Client is aware of the = location of the AAA server
> then it can establish keys with AAA server = using RADIUS which then can
> cache
> them and localize them for each agent as = needed.  Here EAP is encapsulated
> in RADIUS.
>
> 2. When the SNMP Manager/Client is not aware of = the AAA or there is no AAA
> server then the key negotiation would initiate = between the SNMP
> Manage/Client and SNMP Agent and would be = proxied to AAA over RADIUS if
> applicable.  We did not encapsulate EAP in = SNMP since this would be a big
> change to the SNMP protocol but instead choose = to encapsulate it in an out
> of band protocol to leverage existing = work.  The protocols we had in mind
> were existing protocols that carry EAP such as = PANA/NACP(EAP over UDP) or
> IKEv2, but other arrangements are = possible.
>
> The second mode allows for operation without = AAA.

So then the Manager (separately from = "SNMP") acts as the AAA server when an external/remote AAA = server is unavailable or not configured? I think this is a nice = solution. I like the idea of supporting USM as-is and providing = something in addition to support AAA.

Martin.

------_=_NextPart_001_01C4FD64.94F57F90-- --===============2109710862== 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 --===============2109710862==-- From isms-bounces@ietf.org Tue Jan 18 09:50: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 JAA28087; Tue, 18 Jan 2005 09:50:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cquvb-0001Uo-FS; Tue, 18 Jan 2005 10:05:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqubV-0003fB-R4; Tue, 18 Jan 2005 09:45:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CquZT-0003C1-IF for isms@megatron.ietf.org; Tue, 18 Jan 2005 09:43: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 JAA27425 for ; Tue, 18 Jan 2005 09:43:01 -0500 (EST) Message-Id: <200501181443.JAA27425@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cquok-0001F6-Tc for isms@ietf.org; Tue, 18 Jan 2005 09:58:51 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <20050118144231016006vc2le>; Tue, 18 Jan 2005 14:42:32 +0000 From: "David B Harrington" To: "'Martin Soukup'" , "'Joseph Salowey'" , "'Bernard Aboba'" Subject: RE: [Isms] RE: Network management authorization Date: Tue, 18 Jan 2005 09:42:28 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2B725@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcT9acrb9jPheS5tTcuNn69f/bxKjgAAai7Q X-Spam-Score: 0.7 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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: , Content-Type: multipart/mixed; boundary="===============0896151432==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 This is a multi-part message in MIME format. --===============0896151432== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B8_01C4FD42.06550300" This is a multi-part message in MIME format. ------=_NextPart_000_01B8_01C4FD42.06550300 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit So, you're suggesting having the entity to-be-authenticated serve as the AAA-server when the regular AAA server is not accessible? Isn't that like asking the fox to authenticate/authorize itself to the henhouse when the farmer's not available? dbh _____ From: Martin Soukup [mailto:msoukup@nortelnetworks.com] Sent: Tuesday, January 18, 2005 9:25 AM To: 'Joseph Salowey'; 'Bernard Aboba'; ietfdbh@comcast.net Cc: isms@ietf.org Subject: RE: [Isms] RE: Network management authorization > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Joseph Salowey > > With EUSM we selected using EAP because of the integration possibilities > with back end AAA authentication mechanisms. > > We had envisioned two modes of operation: > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > then it can establish keys with AAA server using RADIUS which then can > cache > them and localize them for each agent as needed. Here EAP is encapsulated > in RADIUS. > > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA > server then the key negotiation would initiate between the SNMP > Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if > applicable. We did not encapsulate EAP in SNMP since this would be a big > change to the SNMP protocol but instead choose to encapsulate it in an out > of band protocol to leverage existing work. The protocols we had in mind > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or > IKEv2, but other arrangements are possible. > > The second mode allows for operation without AAA. So then the Manager (separately from "SNMP") acts as the AAA server when an external/remote AAA server is unavailable or not configured? I think this is a nice solution. I like the idea of supporting USM as-is and providing something in addition to support AAA. Martin. ------=_NextPart_000_01B8_01C4FD42.06550300 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management = authorization
So, you're suggesting having the entity = to-be-authenticated=20 serve as the AAA-server when the regular AAA server is not=20 accessible?
Isn't that like asking the fox to = authenticate/authorize=20 itself to the henhouse when the farmer's not = available?
 
dbh

From: Martin Soukup=20 [mailto:msoukup@nortelnetworks.com]
Sent: Tuesday, January = 18, 2005=20 9:25 AM
To: 'Joseph Salowey'; 'Bernard Aboba';=20 ietfdbh@comcast.net
Cc: isms@ietf.org
Subject: RE: = [Isms]=20 RE: Network management authorization



> -----Original Message-----
>=20 From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.iet= f.org]=20 On
> Behalf Of Joseph Salowey =
>
> With EUSM we selected = using EAP=20 because of the integration possibilities
> with=20 back end AAA authentication mechanisms.
> =
> We had envisioned two modes of = operation:=20
>
> 1. When the = SNMP=20 Manager/Client is aware of the location of the AAA server =
> then it can establish keys with AAA server using RADIUS = which then=20 can
> cache
> them and=20 localize them for each agent as needed.  Here EAP is = encapsulated=20
> in RADIUS.
> =
> 2. When the SNMP Manager/Client is not aware of the AAA = or there=20 is no AAA
> server then the key = negotiation would=20 initiate between the SNMP
> Manage/Client = and SNMP=20 Agent and would be proxied to AAA over RADIUS if
>=20 applicable.  We did not encapsulate EAP in SNMP since this would = be a=20 big
> change to the SNMP protocol but = instead=20 choose to encapsulate it in an out
> of = band=20 protocol to leverage existing work.  The protocols we had in = mind=20
> were existing protocols that carry EAP such as = PANA/NACP(EAP over UDP) or
> IKEv2, but = other=20 arrangements are possible.
> =
> The second mode allows for operation without AAA. =

So then the Manager (separately from "SNMP") acts as = the AAA=20 server when an external/remote AAA server is unavailable or not = configured? I=20 think this is a nice solution. I like the idea of supporting USM as-is = and=20 providing something in addition to support AAA.

Martin.

------=_NextPart_000_01B8_01C4FD42.06550300-- --===============0896151432== 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 --===============0896151432==-- From isms-bounces@ietf.org Tue Jan 18 10:04:52 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 KAA29202; Tue, 18 Jan 2005 10:04:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqv9t-0001vb-8p; Tue, 18 Jan 2005 10:20:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqut6-00079d-39; Tue, 18 Jan 2005 10:03:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqupB-0005tj-EF for isms@megatron.ietf.org; Tue, 18 Jan 2005 09:59: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 JAA28738 for ; Tue, 18 Jan 2005 09:59:14 -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 1Cqv4R-0001jZ-Q3 for isms@ietf.org; Tue, 18 Jan 2005 10:15:04 -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 j0IEuhEI003725; Tue, 18 Jan 2005 14:56:43 GMT Received: from fmsmsxvs043.fm.intel.com (fmsmsxvs043.fm.intel.com [132.233.42.129]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j0IEuf2X009845; Tue, 18 Jan 2005 14:56:41 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.2.35) with SMTP id M2005011806564030285 ; Tue, 18 Jan 2005 06:56:40 -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, 18 Jan 2005 06:56:40 -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); Tue, 18 Jan 2005 06:56:40 -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); Tue, 18 Jan 2005 09:56:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Isms] RE: Network management authorization Date: Tue, 18 Jan 2005 09:56:37 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C59298EBB48@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] RE: Network management authorization Thread-Index: AcT9acrb9jPheS5tTcuNn69f/bxKjgAAai7QAAB3kIA= From: "Blumenthal, Uri" To: , "Martin Soukup" , "Joseph Salowey" , "Bernard Aboba" X-OriginalArrivalTime: 18 Jan 2005 14:56:38.0975 (UTC) FILETIME=[E9D85CF0:01C4FD6D] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.6 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1935443157==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d This is a multi-part message in MIME format. --===============1935443157== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4FD6D.E9670AD4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C4FD6D.E9670AD4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nice analogy! :-) =20 It doesn't match the reality though. In reality when pre-shared keys are used, the "fox" is authenticated to the "henhouse" by its knowledge of the shared key. Now it shares something (another key, long-term - for even with AAA in the end you just share a key) from which a subsequent session key is generated. If the manager knows the AAA key, there's nothing wrong in its overtaking the AAA role and generating session keys + authorization. =20 To summarize: details need to be worked out, but in general the approach is OK. ________________________________ From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B Harrington Sent: Tuesday, January 18, 2005 9:42 AM To: 'Martin Soukup'; 'Joseph Salowey'; 'Bernard Aboba' Cc: isms@ietf.org Subject: RE: [Isms] RE: Network management authorization So, you're suggesting having the entity to-be-authenticated serve as the AAA-server when the regular AAA server is not accessible? Isn't that like asking the fox to authenticate/authorize itself to the henhouse when the farmer's not available? =20 dbh ________________________________ From: Martin Soukup [mailto:msoukup@nortelnetworks.com]=20 Sent: Tuesday, January 18, 2005 9:25 AM To: 'Joseph Salowey'; 'Bernard Aboba'; ietfdbh@comcast.net Cc: isms@ietf.org Subject: RE: [Isms] RE: Network management authorization =09 =09 > -----Original Message-----=20 > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On=20 > Behalf Of Joseph Salowey=20 >=20 > With EUSM we selected using EAP because of the integration possibilities=20 > with back end AAA authentication mechanisms.=20 >=20 > We had envisioned two modes of operation:=20 >=20 > 1. When the SNMP Manager/Client is aware of the location of the AAA server=20 > then it can establish keys with AAA server using RADIUS which then can=20 > cache=20 > them and localize them for each agent as needed. Here EAP is encapsulated=20 > in RADIUS.=20 >=20 > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA=20 > server then the key negotiation would initiate between the SNMP=20 > Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if=20 > applicable. We did not encapsulate EAP in SNMP since this would be a big=20 > change to the SNMP protocol but instead choose to encapsulate it in an out=20 > of band protocol to leverage existing work. The protocols we had in mind=20 > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or=20 > IKEv2, but other arrangements are possible.=20 >=20 > The second mode allows for operation without AAA.=20 So then the Manager (separately from "SNMP") acts as the AAA server when an external/remote AAA server is unavailable or not configured? I think this is a nice solution. I like the idea of supporting USM as-is and providing something in addition to support AAA. Martin.=20 ------_=_NextPart_001_01C4FD6D.E9670AD4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management = authorization
Nice=20 analogy!  :-)
 
It=20 doesn't match the reality though. In reality when pre-shared keys = are used,=20 the "fox" is authenticated to the "henhouse" by its knowledge of the = shared key.=20 Now it shares something (another key, long-term - for even with AAA = in the=20 end you just share a key) from which a subsequent session key is = generated.=20 If the manager knows the AAA key, there's nothing wrong in its = overtaking=20 the AAA role and generating session keys + = authorization.
 
To=20 summarize: details need to be worked out, but in general the approach is = OK.

From: isms-bounces@lists.ietf.org=20 [mailto:isms-bounces@lists.ietf.org] On Behalf Of David B=20 Harrington
Sent: Tuesday, January 18, 2005 9:42 = AM
To:=20 'Martin Soukup'; 'Joseph Salowey'; 'Bernard Aboba'
Cc:=20 isms@ietf.org
Subject: RE: [Isms] RE: Network management=20 authorization

So, you're suggesting having the entity = to-be-authenticated=20 serve as the AAA-server when the regular AAA server is not=20 accessible?
Isn't that like asking the fox to = authenticate/authorize=20 itself to the henhouse when the farmer's not = available?
 
dbh

From: Martin Soukup=20 [mailto:msoukup@nortelnetworks.com]
Sent: Tuesday, January = 18, 2005=20 9:25 AM
To: 'Joseph Salowey'; 'Bernard Aboba';=20 ietfdbh@comcast.net
Cc: isms@ietf.org
Subject: RE: = [Isms]=20 RE: Network management authorization



> -----Original Message-----
>=20 From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.iet= f.org]=20 On
> Behalf Of Joseph Salowey =
>
> With EUSM we selected = using EAP=20 because of the integration possibilities
> with=20 back end AAA authentication mechanisms.
> =
> We had envisioned two modes of = operation:=20
>
> 1. When the = SNMP=20 Manager/Client is aware of the location of the AAA server =
> then it can establish keys with AAA server using RADIUS = which then=20 can
> cache
> them and=20 localize them for each agent as needed.  Here EAP is = encapsulated=20
> in RADIUS.
> =
> 2. When the SNMP Manager/Client is not aware of the AAA = or there=20 is no AAA
> server then the key = negotiation would=20 initiate between the SNMP
> Manage/Client = and SNMP=20 Agent and would be proxied to AAA over RADIUS if
>=20 applicable.  We did not encapsulate EAP in SNMP since this would = be a=20 big
> change to the SNMP protocol but = instead=20 choose to encapsulate it in an out
> of = band=20 protocol to leverage existing work.  The protocols we had in = mind=20
> were existing protocols that carry EAP such as = PANA/NACP(EAP over UDP) or
> IKEv2, but = other=20 arrangements are possible.
> =
> The second mode allows for operation without AAA. =

So then the Manager (separately from "SNMP") acts as = the AAA=20 server when an external/remote AAA server is unavailable or not = configured? I=20 think this is a nice solution. I like the idea of supporting USM as-is = and=20 providing something in addition to support AAA.

Martin.

------_=_NextPart_001_01C4FD6D.E9670AD4-- --===============1935443157== 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 --===============1935443157==-- From isms-bounces@ietf.org Tue Jan 18 14:20: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 OAA21863; Tue, 18 Jan 2005 14:20:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cqz94-0000Yq-Cg; Tue, 18 Jan 2005 14:36:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cqyrc-0003n2-Ii; Tue, 18 Jan 2005 14:18:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqymN-0003E8-7h for isms@megatron.ietf.org; Tue, 18 Jan 2005 14:12: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 OAA21276 for ; Tue, 18 Jan 2005 14:12:37 -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 1Cqz1g-0000LN-Nu for isms@ietf.org; Tue, 18 Jan 2005 14:28:29 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 18 Jan 2005 12:19:32 +0000 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-2.cisco.com (8.12.10/8.12.6) with ESMTP id j0IJC4l2023101; Tue, 18 Jan 2005 11:12:05 -0800 (PST) Received: from kaushik-w2k03.cisco.com (dhcp-171-69-71-250.cisco.com [171.69.71.250]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AXJ47581; Tue, 18 Jan 2005 11:12:03 -0800 (PST) Message-Id: <6.2.0.14.0.20050118105617.04ae8a88@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 18 Jan 2005 11:11:59 -0800 To: "Martin Soukup" From: Kaushik Narayan Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2B725@zcarhxm2.corp.nor tel.com> References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B725@zcarhxm2.corp.nortel.com> Mime-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: isms@ietf.org, "'Bernard Aboba'" X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0819117127==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 --===============0819117127== Content-Type: multipart/alternative; boundary="=====================_179273111==.ALT" --=====================_179273111==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Martin, I would like to clarify that it would be the agent and not the manager that would act as a AAA server in cases there isn't an external AAA server present.This would typically used in cases of fallback wherein connectivity to a AAA server is lost and also in cases where the agent is capable of authentication via local credentials as in the case with X.509 certificates using EAP-TLS. regards, kaushik! At 06:25 AM 1/18/2005, Martin Soukup wrote: > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > > Behalf Of Joseph Salowey > > > > With EUSM we selected using EAP because of the integration possibilities > > with back end AAA authentication mechanisms. > > > > We had envisioned two modes of operation: > > > > 1. When the SNMP Manager/Client is aware of the location of the AAA server > > then it can establish keys with AAA server using RADIUS which then can > > cache > > them and localize them for each agent as needed. Here EAP is encapsulated > > in RADIUS. > > > > 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA > > server then the key negotiation would initiate between the SNMP > > Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if > > applicable. We did not encapsulate EAP in SNMP since this would be a big > > change to the SNMP protocol but instead choose to encapsulate it in an out > > of band protocol to leverage existing work. The protocols we had in mind > > were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or > > IKEv2, but other arrangements are possible. > > > > The second mode allows for operation without AAA. > >So then the Manager (separately from "SNMP") acts as the AAA server when >an external/remote AAA server is unavailable or not configured? I think >this is a nice solution. I like the idea of supporting USM as-is and >providing something in addition to support AAA. > >Martin. >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms --=====================_179273111==.ALT Content-Type: text/html; charset="us-ascii" Hi Martin,

I would like to clarify that it would be the agent and not the manager
that would act as a AAA server in cases there isn't an external AAA
server present.This would typically used in cases of fallback wherein
connectivity to a AAA server is lost and also in cases where the agent
is capable of authentication via local credentials as in the case with
X.509 certificates using EAP-TLS.

regards,
  kaushik!


At 06:25 AM 1/18/2005, Martin Soukup wrote:


> -----Original Message-----
> From: isms-bounces@lists.ietf.org [ mailto:isms-bounces@lists.ietf.org] On
> Behalf Of Joseph Salowey
>
> With EUSM we selected using EAP because of the integration possibilities
> with back end AAA authentication mechanisms.
>
> We had envisioned two modes of operation:
>
> 1. When the SNMP Manager/Client is aware of the location of the AAA server
> then it can establish keys with AAA server using RADIUS which then can
> cache
> them and localize them for each agent as needed.  Here EAP is encapsulated
> in RADIUS.
>
> 2. When the SNMP Manager/Client is not aware of the AAA or there is no AAA
> server then the key negotiation would initiate between the SNMP
> Manage/Client and SNMP Agent and would be proxied to AAA over RADIUS if
> applicable.  We did not encapsulate EAP in SNMP since this would be a big
> change to the SNMP protocol but instead choose to encapsulate it in an out
> of band protocol to leverage existing work.  The protocols we had in mind
> were existing protocols that carry EAP such as PANA/NACP(EAP over UDP) or
> IKEv2, but other arrangements are possible.
>
> The second mode allows for operation without AAA.

So then the Manager (separately from "SNMP") acts as the AAA server when an external/remote AAA server is unavailable or not configured? I think this is a nice solution. I like the idea of supporting USM as-is and providing something in addition to support AAA.

Martin.
_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms
--=====================_179273111==.ALT-- --===============0819117127== 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 --===============0819117127==-- From isms-bounces@ietf.org Tue Jan 18 14:46: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 OAA23986; Tue, 18 Jan 2005 14:46:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzYO-0001Fu-Rn; Tue, 18 Jan 2005 15:02:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzEj-0000IO-Vj; Tue, 18 Jan 2005 14:41:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CqzD1-0008VU-9q for isms@megatron.ietf.org; Tue, 18 Jan 2005 14:40: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 OAA23544 for ; Tue, 18 Jan 2005 14:40:09 -0500 (EST) Received: from outbound.mailhop.org ([63.208.196.171] ident=mailnull) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CqzSK-00015f-C0 for isms@ietf.org; Tue, 18 Jan 2005 14:56:01 -0500 Received: from c-67-182-139-247.client.comcast.net ([67.182.139.247] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.42) id 1CqzCp-0002VV-Qd; Tue, 18 Jan 2005 14:39:59 -0500 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id j0IJdv821959; Tue, 18 Jan 2005 11:39:58 -0800 Date: Tue, 18 Jan 2005 11:39:57 -0800 (PST) From: Bernard Aboba To: "Blumenthal, Uri" Subject: RE: [Isms] RE: Network management authorization In-Reply-To: <3DEC199BD7489643817ECA151F7C59298EBB48@pysmsx401.amr.corp.intel.com> Message-ID: References: <3DEC199BD7489643817ECA151F7C59298EBB48@pysmsx401.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mail-Handler: MailHop Outbound by DynDNS.org X-Originating-IP: 67.182.139.247 X-Report-Abuse-To: abuse@dyndns.org (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 > If the manager knows the AAA key, there's > nothing wrong in its overtaking the AAA role and generating session keys > + authorization. > > To summarize: details need to be worked out, but in general the approach > is OK. In general, RADIUS clients are specifically authorized to act in that role. A client cannot be configured to act as a RADIUS server merely because it has knowledge of a RADIUS shared secret. For example, the shared secret is supposed to be different for each client-server pair. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 20 11:59:13 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 LAA15172; Thu, 20 Jan 2005 11:59:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Crfu5-0003tg-7H; Thu, 20 Jan 2005 12:15:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrfYd-0000Hm-8N; Thu, 20 Jan 2005 11:53:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CrVzZ-0002Xv-7E for isms@megatron.ietf.org; Thu, 20 Jan 2005 01:40: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 BAA12235 for ; Thu, 20 Jan 2005 01:40:27 -0500 (EST) From: dannyv@bbn.com Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CrWFB-0004fL-HP for isms@ietf.org; Thu, 20 Jan 2005 01:56:37 -0500 Received: from po2.bbn.com (po2.bbn.com [128.33.0.56]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j0K6duje027369 for ; Thu, 20 Jan 2005 01:39:56 -0500 (EST) Received: from dhcp89-089-076.bbn.com (dhcp89-089-076.bbn.com [128.89.89.76]) by po2.bbn.com (8.11.6+Sun/8.10.2) with SMTP id j0K6duU11228 for ; Thu, 20 Jan 2005 01:39:56 -0500 (EST) Message-Id: <200501200639.j0K6duU11228@po2.bbn.com> Date: Wed, 19 Jan 2005 03:51:04 -0500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" To: isms@ietf.org Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 1.4 (+) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 20 Jan 2005 11:53:17 -0500 Subject: [Isms] 2005 NETWORK AND DISTRIBUTED SYSTEMS SECURITY SYMPOSIUM (NDSS '05) IS FAST APPROACHING X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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.7 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable ------------------------------------------------------------------------ ** My apologies if you receive multiple copies of this message. ** JUST A REMINDER THAT THE INTERNET SOCIETY'S 2005 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'05) IS FAST APPROACHING! February 2, 2005 - Pre Conference Workshop February 3-4, 2005 - Symposium Catamaran Resort Hotel, San Diego, California General Chair: Eric Harder, National Security Agency Program co-Chairs: Dan Simon, Microsoft Research Dan Boneh, Stanford University ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss05/ The 12th annual NDSS Symposium brings together innovative and forward thinking members of the Internet community including leading edge security researchers and implementers, globally recognized security technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. NDSS'05 provides a balanced mix of technical papers (with a strong emphasis on implementation) that cover new and practical approaches to security problems that are endemic to network and distributed systems. THIS YEAR'S TOPICS INCLUDE: * Cryptography in Network Security * Denial of Service Attacks * Peer to Peer Approaches * Internet Defense * Intrusion Detection * Platform Security. FEATURED GUEST SPEAKERS: * Amit Yoran, who was responsible for coordinating cyber-security activities for Homeland Security, will speak on "Security Challenges and Opportunities of the Future Enterprise" * Dr. Stefan Savage, Computer Science Dept., University of California, San Diego discusses "Internet Outbreaks: Epidemiology and Defenses PRE CONFERENCE WORKSHOP TOPICS INCLUDE: * Security in handling mobility on the internet * Security in wireless LANs * Security for telephony or voice over IP * Trust relations in ad hoc networks * Key management strategies to support mobility * Security in RFID. More information is available at: http://www.isoc.org/isoc/conferences/ndss/05/workshop.shtml =CA=CA REGISTER NOW Registration for NDSS'05 is now open. Student rates are available for both the workshop and symposium. See the web site for more information -- http://www.isoc.org/ndss05/ Registration fees: * After January 10, 2005 $695. Online registrations will be accepted until 20 January 2005. After that date, on-site registration will be available upon your arrival. HOTEL RESERVATIONS Remember to make your hotel reservations with the Catamaran Resort Hotel. https://shop.evanshotels.com/nds0130.html SPONSORSHIP OPPORTUNITIES AVAILABLE! If your organization would like to help support NDSS and gain visibility through sponsoring, please contact: sponsor-ndss@isoc.org. Information is also available at=20 http://www.isoc.org/ndss05/ Karen Seo NDSS'05 Publicity Chair _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Jan 25 19:23: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 TAA29732; Tue, 25 Jan 2005 19:23:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtbEw-0000Aq-Lm; Tue, 25 Jan 2005 19:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctarr-00047i-SE; Tue, 25 Jan 2005 19:17:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctang-00020l-Ce for isms@megatron.ietf.org; Tue, 25 Jan 2005 19:12: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 TAA28797 for ; Tue, 25 Jan 2005 19:12:44 -0500 (EST) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctb4T-0008Bk-6L for isms@ietf.org; Tue, 25 Jan 2005 19:30:10 -0500 Received: from conger.atcorp.com ([204.72.172.102] helo=STRIPER) by moby.atcorp.com with esmtp (Exim 3.35 #1 (Debian)) id 1Ctan9-0008Ci-00; Tue, 25 Jan 2005 18:12:15 -0600 From: "Wayne Kading" To: Subject: RE: [Isms] Evaluation status [and more] Date: Tue, 25 Jan 2005 18:09:51 -0600 Organization: ATC Message-ID: <004301c5033b$5bb1a610$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <200501112100.QAA28595@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: quoted-printable The following statement made by David on SNMP v1/v2c security prompted = this comment. Due to legacy security concerns where SNMP v1/v2c/v3 equipment coexists, it appears that SNMP v1/v2c security should be addressed in = the evaluation criteria and related proposals if it isn't already. I would = also be interested to see what importance is assigned to this criteria as it = is a concern in many large environments. Wayne -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of David B Harrington Sent: Tuesday, January 11, 2005 3:00 PM To: 'Nelson, David'; isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] . . If we adopt a secured-transport session, we might be able to transport the simpler SNMPv1 or SNMPv2c message formats securely. . . 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 Jan 25 23:00: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 XAA15498; Tue, 25 Jan 2005 23:00:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctech-0006p1-Pb; Tue, 25 Jan 2005 23:17:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CteJf-0003fc-Vm; Tue, 25 Jan 2005 22:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CteIm-0003Rs-4x for isms@megatron.ietf.org; Tue, 25 Jan 2005 22:57: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 WAA15252 for ; Tue, 25 Jan 2005 22:57:05 -0500 (EST) Received: from pop-a065b10.pas.sa.earthlink.net ([207.217.121.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CteZb-0006lb-1l for isms@ietf.org; Tue, 25 Jan 2005 23:14:32 -0500 Received: from h-66-167-206-174.snvacaid.dynamic.covad.net ([66.167.206.174] helo=oemcomputer) by pop-a065b10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CteIj-00029j-00 for isms@ietf.org; Tue, 25 Jan 2005 19:57:05 -0800 Message-ID: <00d301c5035b$245cdca0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <004301c5033b$5bb1a610$84aca8c0@STRIPER> Subject: Re: [Isms] Evaluation status [and more] Date: Tue, 25 Jan 2005 19:57:23 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: e5ba305d0e64821bf3d8bc5d3bb07228 Hi - > From: "Wayne Kading" > To: > Sent: Tuesday, January 25, 2005 4:09 PM > Subject: RE: [Isms] Evaluation status [and more] > > The following statement made by David on SNMP v1/v2c security prompted this > comment. Due to legacy security concerns where SNMP v1/v2c/v3 equipment > coexists, it appears that SNMP v1/v2c security should be addressed in the > evaluation criteria and related proposals if it isn't already. I would also > be interested to see what importance is assigned to this criteria as it is a > concern in many large environments. ... I'd say it's too late for this, since none of the proposals submitted to the WG try to do this. Furthermore, it's hard to see how any sort of encapsulation could help legacy equipment. If one needs to update the gear to support the encapsulation, one may as well do it right and go to SNMPv3 in order to get the benefits of access control. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 26 03:22:30 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 DAA00491; Wed, 26 Jan 2005 03:22:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtiiU-0005So-AR; Wed, 26 Jan 2005 03:39:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiQJ-0002FE-NY; Wed, 26 Jan 2005 03:21:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiGN-0000X1-IN for isms@megatron.ietf.org; Wed, 26 Jan 2005 03:10:55 -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 DAA29976 for ; Wed, 26 Jan 2005 03:10:53 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtiXE-0005Bo-Oc for isms@ietf.org; Wed, 26 Jan 2005 03:28:22 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 1AA73D645; Wed, 26 Jan 2005 09:10:17 +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 06937-01; Wed, 26 Jan 2005 09:10:16 +0100 (CET) Received: from james (I8ae2.i.pppool.de [85.73.138.226]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id A1BECB88A; Wed, 26 Jan 2005 09:10:15 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CtiFi-0000yJ-0t; Wed, 26 Jan 2005 09:10:14 +0100 Date: Wed, 26 Jan 2005 09:10:13 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050126081013.GA3715@james> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <004301c5033b$5bb1a610$84aca8c0@STRIPER> <00d301c5035b$245cdca0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d301c5035b$245cdca0$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: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 On Tue, Jan 25, 2005 at 07:57:23PM -0800, Randy Presuhn wrote: > I'd say it's too late for this, since none of the proposals submitted > to the WG try to do this. Some proposals may allow for this while other do not, even though this is not explicitely stated. I guess not all evaluation criteria have been addressed by the various proposals (which is no surprise since the criteria even today are not known). The key thing here is to try to identify what addresses the requirements of which segment of the overall SNMP market. (And I know that this is really difficult with the limited input we get.) > Furthermore, it's hard to see how any sort of encapsulation could > help legacy equipment. If one needs to update the gear to support > the encapsulation, one may as well do it right and go to SNMPv3 in > order to get the benefits of access control. I fail to understand the access control argument. You can do VACM access control with SNMPv1/SNMPv2c today as far as I understand things. Please correct me if I am wrong. /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 Jan 26 03:23: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 DAA00522; Wed, 26 Jan 2005 03:23:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtijS-0005TW-5k; Wed, 26 Jan 2005 03:40:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiQM-0002G7-S9; Wed, 26 Jan 2005 03:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtiHu-0000l0-RM for isms@megatron.ietf.org; Wed, 26 Jan 2005 03:12: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 DAA00029 for ; Wed, 26 Jan 2005 03:12:29 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtiYn-0005D0-AJ for isms@ietf.org; Wed, 26 Jan 2005 03:29:57 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id AF2D0D645; Wed, 26 Jan 2005 09:11:59 +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 06872-08; Wed, 26 Jan 2005 09:11:58 +0100 (CET) Received: from james (I8ae2.i.pppool.de [85.73.138.226]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 69DD4B88A; Wed, 26 Jan 2005 09:11:57 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CtiHL-0000yQ-QB; Wed, 26 Jan 2005 09:11:55 +0100 Date: Wed, 26 Jan 2005 09:11:55 +0100 From: Juergen Schoenwaelder To: Wayne Kading Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050126081155.GB3715@james> Mail-Followup-To: Wayne Kading , isms@ietf.org References: <200501112100.QAA28595@ietf.org> <004301c5033b$5bb1a610$84aca8c0@STRIPER> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004301c5033b$5bb1a610$84aca8c0@STRIPER> 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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: 7655788c23eb79e336f5f8ba8bce7906 On Tue, Jan 25, 2005 at 06:09:51PM -0600, Wayne Kading wrote: > Due to legacy security concerns where SNMP v1/v2c/v3 equipment > coexists, it appears that SNMP v1/v2c security should be addressed in the > evaluation criteria and related proposals if it isn't already. I would also > be interested to see what importance is assigned to this criteria as it is a > concern in many large environments. Can you explain what the potential market impact of being able to ship legacy SNMP over a secure transport actually is? I know this is hard to judge but actually the most critical question to ask when evaluating the proposals. /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 Jan 26 16:30: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 QAA22356; Wed, 26 Jan 2005 16:30:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctv0x-0005wJ-Sj; Wed, 26 Jan 2005 16:47:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuW5-0007hG-LG; Wed, 26 Jan 2005 16:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtuM2-0006yH-Vl for isms@megatron.ietf.org; Wed, 26 Jan 2005 16: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 QAA18263 for ; Wed, 26 Jan 2005 16:05:24 -0500 (EST) Received: from pop-a065d23.pas.sa.earthlink.net ([207.217.121.254]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctucq-0004cL-H2 for isms@ietf.org; Wed, 26 Jan 2005 16:22:59 -0500 Received: from h-66-167-206-248.snvacaid.dynamic.covad.net ([66.167.206.248] helo=oemcomputer) by pop-a065d23.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtuLp-0000Sx-00 for isms@ietf.org; Wed, 26 Jan 2005 13:05:21 -0800 Message-ID: <00d501c503ea$ca80dac0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <004301c5033b$5bb1a610$84aca8c0@STRIPER> <00d301c5035b$245cdca0$7f1afea9@oemcomputer> <20050126081013.GA3715@james> Subject: Re: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 13:05:29 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 26, 2005 12:10 AM > Subject: Re: [Isms] Evaluation status [and more] ... > > Furthermore, it's hard to see how any sort of encapsulation could > > help legacy equipment. If one needs to update the gear to support > > the encapsulation, one may as well do it right and go to SNMPv3 in > > order to get the benefits of access control. > > I fail to understand the access control argument. You can do VACM > access control with SNMPv1/SNMPv2c today as far as I understand > things. Please correct me if I am wrong. ... RFC 2576 section 5.2.1 requires requests coming in this way to be handled as NoAuthNoPriv. So yes, one can subject these to access control, but it's meaningful only in that anything other than "public" would still have to come in through SNMPv3. If one wanted these encapsulations to be handled differently, that is, recognizing them as authenticated, then one would need to define a new security model for the encapsulation, etc., which brings me back to my main point: it doesn't help legacy equipment, since one would need to install new software. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 26 18:02: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 SAA00707; Wed, 26 Jan 2005 18:02:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtwRp-0007zK-Ad; Wed, 26 Jan 2005 18:19:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctw9j-0003qP-9p; Wed, 26 Jan 2005 18: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 1Ctw7W-0002r2-B5 for isms@megatron.ietf.org; Wed, 26 Jan 2005 17:58: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 RAA00350 for ; Wed, 26 Jan 2005 17:58:39 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtwOV-0007tG-Bc for isms@ietf.org; Wed, 26 Jan 2005 18:16:16 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 76D4D9DE3; Wed, 26 Jan 2005 23:58:08 +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 23877-05; Wed, 26 Jan 2005 23:58:07 +0100 (CET) Received: from james (I94b3.i.pppool.de [85.73.148.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 66C569C32; Wed, 26 Jan 2005 23:58:07 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Ctw6v-0000nK-PA; Wed, 26 Jan 2005 23:58:05 +0100 Date: Wed, 26 Jan 2005 23:58:05 +0100 From: Juergen Schoenwaelder To: Randy Presuhn Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050126225805.GB2997@james> Mail-Followup-To: Randy Presuhn , isms@ietf.org References: <004301c5033b$5bb1a610$84aca8c0@STRIPER> <00d301c5035b$245cdca0$7f1afea9@oemcomputer> <20050126081013.GA3715@james> <00d501c503ea$ca80dac0$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d501c503ea$ca80dac0$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: 7d33c50f3756db14428398e2bdedd581 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Wed, Jan 26, 2005 at 01:05:29PM -0800, Randy Presuhn wrote: > RFC 2576 section 5.2.1 requires requests coming in this way to be > handled as NoAuthNoPriv. So yes, one can subject these to access > control, but it's meaningful only in that anything other than "public" > would still have to come in through SNMPv3. If one wanted these > encapsulations to be handled differently, that is, recognizing them > as authenticated, then one would need to define a new security model > for the encapsulation, etc., which brings me back to my main point: > it doesn't help legacy equipment, since one would need to install new > software. I think the argument was more that if you use a secure transport, you can probably get rid of some of the SNMPv3/USM header overhead. Needs some byte counting to see whether this is worth the effort. /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 Jan 26 18:38: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 SAA03891; Wed, 26 Jan 2005 18:38:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctx0d-0000D4-EJ; Wed, 26 Jan 2005 18:55:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctwfk-0001Zd-JA; Wed, 26 Jan 2005 18:34:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctwba-0000Nk-Ec for isms@megatron.ietf.org; Wed, 26 Jan 2005 18:29: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 SAA03350 for ; Wed, 26 Jan 2005 18:29:43 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtwsZ-0008U3-Pw for isms@ietf.org; Wed, 26 Jan 2005 18:47:21 -0500 Received: from h-66-167-206-248.snvacaid.dynamic.covad.net ([66.167.206.248] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CtwbW-0000IZ-00 for isms@ietf.org; Wed, 26 Jan 2005 15:29:42 -0800 Message-ID: <001801c503fe$f545dc60$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <004301c5033b$5bb1a610$84aca8c0@STRIPER> <00d301c5035b$245cdca0$7f1afea9@oemcomputer> <20050126081013.GA3715@james> <00d501c503ea$ca80dac0$7f1afea9@oemcomputer> <20050126225805.GB2997@james> Subject: Re: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 15:30:01 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) 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.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi - > From: "Juergen Schoenwaelder" > To: "Randy Presuhn" > Cc: > Sent: Wednesday, January 26, 2005 2:58 PM > Subject: Re: [Isms] Evaluation status [and more] ... > I think the argument was more that if you use a secure transport, you > can probably get rid of some of the SNMPv3/USM header overhead. Needs > some byte counting to see whether this is worth the effort. ... Yup. After all, bandwidth is so precious we wouldn't want to waste any bits. That's why we use BER rather than XML. ;-) Seriously, though, Wayne's point was about "legacy security concerns where SNMP v1/v2c/v3 equipment coexists". I understood "legacy" to refer to existing hardware/software that, for whatever reason, has not been upgraded to current standards. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 26 19:13: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 TAA06499; Wed, 26 Jan 2005 19:13:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxZG-0000vo-7s; Wed, 26 Jan 2005 19:31:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxAk-00027p-7G; Wed, 26 Jan 2005 19:06:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctx9u-0001p8-LY for isms@megatron.ietf.org; Wed, 26 Jan 2005 19:05: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 TAA05762 for ; Wed, 26 Jan 2005 19:05:11 -0500 (EST) Message-Id: <200501270005.TAA05762@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxQu-0000hf-N3 for isms@ietf.org; Wed, 26 Jan 2005 19:22:50 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20050127000440015009lt75e>; Thu, 27 Jan 2005 00:04:41 +0000 From: "David B Harrington" To: , "'Randy Presuhn'" Subject: RE: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 19:04:34 -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 In-Reply-To: <20050126225805.GB2997@james> Thread-Index: AcUD+w41FNcqsj5XRbeFuUElarx+ywAAu0LA X-Spam-Score: 0.1 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Hi, If the argument you refer to was the ue of SNMPv1 messages over a secure transport, my intent was not to say only that we could reduce header overhead in the SNMPv3 message. My comment was that SNMPv1/v2c format messages might be able to be used if a secure transport provided the message confidentiality and integrity checking. If transport-independent user authentication is desired, it might be able to be provided via a secure-community model, ala SNMPv2a. Using the SNMPv1/v2c message format would of course preclude some of the features of SNMPv3, like proxy. To dredge up history a bit, I think such usage might be akin to what SNMPv2u or SNMPv2a promised, and would lose some of the additional features from what snnmpv2* promised. For those who want the additional features, SNMPv3 format messages could be used over the secure transport ( and that the secured-transport security model might reduce the processing overhead compared to USM). 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: Wednesday, January 26, 2005 5:58 PM > To: Randy Presuhn > Cc: isms@ietf.org > Subject: Re: [Isms] Evaluation status [and more] > > On Wed, Jan 26, 2005 at 01:05:29PM -0800, Randy Presuhn wrote: > > > RFC 2576 section 5.2.1 requires requests coming in this way to be > > handled as NoAuthNoPriv. So yes, one can subject these to access > > control, but it's meaningful only in that anything other > than "public" > > would still have to come in through SNMPv3. If one wanted these > > encapsulations to be handled differently, that is, recognizing them > > as authenticated, then one would need to define a new security model > > for the encapsulation, etc., which brings me back to my main point: > > it doesn't help legacy equipment, since one would need to > install new > > software. > > I think the argument was more that if you use a secure transport, you > can probably get rid of some of the SNMPv3/USM header overhead. Needs > some byte counting to see whether this is worth the effort. > > /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 Wed Jan 26 19:24:05 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 TAA07270; Wed, 26 Jan 2005 19:24:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxjB-0001AG-Mb; Wed, 26 Jan 2005 19:41:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxNI-0005XR-20; Wed, 26 Jan 2005 19:19:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxKY-0004ri-Qs for isms@megatron.ietf.org; Wed, 26 Jan 2005 19:16: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 TAA06776 for ; Wed, 26 Jan 2005 19:16:11 -0500 (EST) Message-Id: <200501270016.TAA06776@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxbZ-0000y7-Md for isms@ietf.org; Wed, 26 Jan 2005 19:33:50 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005012700154201300kfnt3e>; Thu, 27 Jan 2005 00:15:42 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 19:15:39 -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 In-Reply-To: <00d501c503ea$ca80dac0$7f1afea9@oemcomputer> Thread-Index: AcUD7jsvF95doWMZRYCdjbU89ZKPjgAB936g X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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: 789c141a303c09204b537a4078e2a63f Content-Transfer-Encoding: 7bit Hi, Some comments: -- RFC2576 requirements Note that RFC2576 is obsolete; it has been replaced by RFC3584. The document has gone from standards-track to being simply a BCP. So the "requirement" that requests be handled as noAuthNoPriv doesn't carry the same weight as if it were a standard. That requireent is there because SNMPv1 messages have no confidentiality protection. We could certainly generate a new document, or an appendix to the proposed security model, that could override RFC3584 for coexistence between SNMPv1 and the new security model, if the new security model could provide adequate message secuirty to justify the continued use of the community-authentication model, or could utilize the community field of the SNMPv1/v2c message format to transport an authenticatable user identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that anything other than public would need to be handled through SNMPv3. -- the need to modify agents I agree that any new security model might require updating agent code. I think the real issue for operators is having to upgrade their whole systems, not just their legacy agents. As far as I have been able to determine, most equipment vendors already support SNMPv3-capable agents in new products; the real problem is that most management applications do not. Last I checked, HPOV, CA UniCenter, Tivoli, BMC Patrol, and Spectrum (the five leading multi-vendor platforms last time I checked) all did not support native SNMPv3; many offer a proxy via an SNMPv3-daemon, but no direct support for SNMPv3 in their main device-communications logic. So I think the problem is upgrading the operators' systems of interoperable managers and agents to support SNMPv3. If an SNMP security model (or security approach, if you will) could secure SNMPv1/v2c messages then it could be easier for operators to secure their SNMP systems, even without upgrading their managers to SNMPv3. If a new SNMP security approach utilized existing security infrastructure already co-resident with the legacy agents, such as SSH or SSL/TLS, to secure the messages, then living a while longer with the SNMPv1/v2c message format and a lack of SNMPv3/VACM access control might be acceptable. Of course, as Juergen pointed out, it might be possible to use VACM with an authenticated SNMPv1/v2c message. SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the surrounding security infrastructure. But leveraging an SSH or SSL approach, which could be applied not only to SNMP but also to CLI and/or web-based interfaces might justify the incremental costs to slightly modify the legacy SNMPv1 agents. -- demand for VACM I haven't found much demand for VACM-style access control from operators so far. I think this is because this access control is not consistent with the access control/authorization mechanisms used for other management interfaces, much as USM is not consistent with the authentication mechanisms for other management interfaces. I think we need to solve the authentication-consistency problem first, then we can try to solve the authorization-consistency issue. I believe the authorization-consistency issue will require that other management interfaces make their data objects addressable in a standard manner. The netconf data modeling may provide mechanisms for addressing data points hierarchically, and then a VACM-style access control could be applied to the data for netconf. Hopefully, netconf will lead the way for standardizing scripting, ala CLI scripting, and that might lead to some standardization of an addressing mechanism for CLI parameters. Web-based management data points might also become addressable via XML. If we can standardize addressability of CLI and web-based data points, then VACM-style access control could be applied to those management interfaces. But before we get there, we need to get user-authentication consistent across interfaces. I think it possible that operators will ask us to develop an authorization mechanism that is more consistent with existing CLI access control mechanisms, which may or may not be consistent with the VACM approach. VACM might be able to be deployed in a manner that would make it consistent with existing CLI access control, but so far we haven't told the operators how this can be done with VACM, probably because CLI access control hasn't been consistent across vendors (or even within vendors' product lines in many cases). My $.02 David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > Sent: Wednesday, January 26, 2005 4:05 PM > To: isms@ietf.org > Subject: Re: [Isms] Evaluation status [and more] > > Hi - > > > From: "Juergen Schoenwaelder" > > To: "Randy Presuhn" > > Cc: > > Sent: Wednesday, January 26, 2005 12:10 AM > > Subject: Re: [Isms] Evaluation status [and more] > ... > > > Furthermore, it's hard to see how any sort of encapsulation could > > > help legacy equipment. If one needs to update the gear to support > > > the encapsulation, one may as well do it right and go to SNMPv3 in > > > order to get the benefits of access control. > > > > I fail to understand the access control argument. You can do VACM > > access control with SNMPv1/SNMPv2c today as far as I understand > > things. Please correct me if I am wrong. > ... > > RFC 2576 section 5.2.1 requires requests coming in this way to be > handled as NoAuthNoPriv. So yes, one can subject these to access > control, but it's meaningful only in that anything other than "public" > would still have to come in through SNMPv3. If one wanted these > encapsulations to be handled differently, that is, recognizing them > as authenticated, then one would need to define a new security model > for the encapsulation, etc., which brings me back to my main point: > it doesn't help legacy equipment, since one would need to install new > software. > > 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 Wed Jan 26 19:38: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 TAA08431; Wed, 26 Jan 2005 19:38:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ctxwj-0001QX-Nq; Wed, 26 Jan 2005 19:55:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxer-0000vl-VX; Wed, 26 Jan 2005 19:37:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtxZW-00089a-Pe for isms@megatron.ietf.org; Wed, 26 Jan 2005 19:31: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 TAA07900 for ; Wed, 26 Jan 2005 19:31:39 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtxqX-0001IY-Re for isms@ietf.org; Wed, 26 Jan 2005 19:49:18 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 0E09ED47E; Thu, 27 Jan 2005 01:31:11 +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 27624-05; Thu, 27 Jan 2005 01:31:10 +0100 (CET) Received: from james (I94b3.i.pppool.de [85.73.148.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id F1F0CD45F; Thu, 27 Jan 2005 01:31:09 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CtxYy-0000r9-8d; Thu, 27 Jan 2005 01:31:08 +0100 Date: Thu, 27 Jan 2005 01:31:08 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050127003108.GA3286@james> Mail-Followup-To: David B Harrington , 'Randy Presuhn' , isms@ietf.org References: <20050126225805.GB2997@james> <20050127000943.E06CB9DE1@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050127000943.E06CB9DE1@hermes.iu-bremen.de> 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, Jan 26, 2005 at 07:04:34PM -0500, David B Harrington wrote: > Using the SNMPv1/v2c message format would of course preclude some of > the features of SNMPv3, like proxy. To dredge up history a bit, I > think such usage might be akin to what SNMPv2u or SNMPv2a promised, > and would lose some of the additional features from what snnmpv2* > promised. For those who want the additional features, SNMPv3 format > messages could be used over the secure transport ( and that the > secured-transport security model might reduce the processing overhead > compared to USM). The question is where you want to draw the line this time. There are a number of things in the SNMPv3 header that are in principle very good general enhancements of SNMPv1/SNMPv2c (msgMaxSize and scoped PDUs come to my mind). On the other hand, the many people still using SNMPv1/SNMPv2c seem to be happy enough without these features - I can't remember having ever talked to an operator who complained about message size problems or who have a real problem to use a public@something community string where needed. But I think we are slipping out of the charter here which I think says the SNMPv3 message header is something we are not expected to touch or discuss. So if my reading of the charter is right, the only thing to consider by this WG is the information carried in the USM header. /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 Jan 26 19:52:10 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 TAA09584; Wed, 26 Jan 2005 19:52:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyAP-0001jY-FK; Wed, 26 Jan 2005 20:09:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxt0-0003cq-SG; Wed, 26 Jan 2005 19:51:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxp6-0002kl-Rp for isms@megatron.ietf.org; Wed, 26 Jan 2005 19:47: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 TAA09200 for ; Wed, 26 Jan 2005 19:47:44 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cty67-0001ck-8S for isms@ietf.org; Wed, 26 Jan 2005 20:05:23 -0500 Received: from h-66-167-206-248.snvacaid.dynamic.covad.net ([66.167.206.248] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Ctxp1-0007If-00 for isms@ietf.org; Wed, 26 Jan 2005 16:47:43 -0800 Message-ID: <00dc01c50409$db300020$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501261915.1cTXk43Ex3Nl3pK0@gideon.mail.atl.earthlink.net> Subject: Re: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 16:48:02 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: f49c97ce49302a02285a2d36a99eef8c Hi - > From: "David B Harrington" > To: "'Randy Presuhn'" ; > Sent: Wednesday, January 26, 2005 4:15 PM > Subject: RE: [Isms] Evaluation status [and more] ... > Note that RFC2576 is obsolete; it has been replaced by RFC3584. The A stale cache error on my part, but it doesn't affect my point. > document has gone from standards-track to being simply a BCP. So the > "requirement" that requests be handled as noAuthNoPriv doesn't carry > the same weight as if it were a standard. That requireent is there > because SNMPv1 messages have no confidentiality protection. We could > certainly generate a new document, or an appendix to the proposed > security model, that could override RFC3584 for coexistence between > SNMPv1 and the new security model, if the new security model could > provide adequate message secuirty to justify the continued use of the > community-authentication model, or could utilize the community field > of the SNMPv1/v2c message format to transport an authenticatable user > identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that > anything other than public would need to be handled through SNMPv3. We're actually in agreement: if one wants to use SNMPv1 over a secure transport that provides real authentication services, one would need to define a new security model to make use of it, since authentication doesn't have much of a point until teamed up with an access control model of some kind. > -- the need to modify agents > > I agree that any new security model might require updating agent code. > > I think the real issue for operators is having to upgrade their whole > systems, not just their legacy agents. As far as I have been able to > determine, most equipment vendors already support SNMPv3-capable > agents in new products; the real problem is that most management > applications do not. Last I checked, HPOV, CA UniCenter, Tivoli, BMC > Patrol, and Spectrum (the five leading multi-vendor platforms last > time I checked) all did not support native SNMPv3; many offer a proxy > via an SNMPv3-daemon, but no direct support for SNMPv3 in their main > device-communications logic. Do we have any reason to believe that they would overcome their inertia and disregard for customers' security (or whatever else has motivated their inaction) and implement whatever comes out of this effort? > So I think the problem is upgrading the operators' systems of > interoperable managers and agents to support SNMPv3. If an SNMP > security model (or security approach, if you will) could secure > SNMPv1/v2c messages then it could be easier for operators to secure > their SNMP systems, even without upgrading their managers to SNMPv3. This is a part that I don't quite understand. A management application would need to provide some bits to the SNMP Engine & transport in order to get them to put the correct user authentication bits onto the wire. How is the reward/effort/risk going to be substantially different for them from what it would have been to put SNMPv3 in? > If a new SNMP security approach utilized existing security > infrastructure already co-resident with the legacy agents, such as SSH > or SSL/TLS, to secure the messages, then living a while longer with Even if an existing box has SSH code in it, if the SNMP code doesn't call it, getting it to do so means a few firmware/software version. > the SNMPv1/v2c message format and a lack of SNMPv3/VACM access control > might be acceptable. Of course, as Juergen pointed out, it might be > possible to use VACM with an authenticated SNMPv1/v2c message. With a new security model. > SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the But that point seems to be moot, since it's already out there for the agents. > surrounding security infrastructure. But leveraging an SSH or SSL > approach, which could be applied not only to SNMP but also to CLI > and/or web-based interfaces might justify the incremental costs to > slightly modify the legacy SNMPv1 agents. Could be. What worries me, though, is that I still haven't seen a convincing argument that the management platform vendors would be any more motivated to get their act together for this than for SNMPv3. > -- demand for VACM > > I haven't found much demand for VACM-style access control from > operators so far. > > I think this is because this access control is not consistent with the > access control/authorization mechanisms used for other management > interfaces, much as USM is not consistent with the authentication > mechanisms for other management interfaces. I think we need to solve > the authentication-consistency problem first, then we can try to solve > the authorization-consistency issue. The way this WG has been chartered leaves us little choice here. > I believe the authorization-consistency issue will require that other > management interfaces make their data objects addressable in a > standard manner. The netconf data modeling may provide mechanisms for > addressing data points hierarchically, and then a VACM-style access > control could be applied to the data for netconf. Hopefully, netconf > will lead the way for standardizing scripting, ala CLI scripting, and > that might lead to some standardization of an addressing mechanism for > CLI parameters. Web-based management data points might also become > addressable via XML. If we can standardize addressability of CLI and > web-based data points, then VACM-style access control could be applied > to those management interfaces. But before we get there, we need to > get user-authentication consistent across interfaces. This is an operational problem that we're addressing as a protocol problem. Let's hope it works. > I think it possible that operators will ask us to develop an > authorization mechanism that is more consistent with existing CLI > access control mechanisms, which may or may not be consistent with the The access control for the CLIs I've used (in the distant past) had very little in common with each other. Let's hope your optimism is justified. > VACM approach. VACM might be able to be deployed in a manner that > would make it consistent with existing CLI access control, but so far > we haven't told the operators how this can be done with VACM, probably > because CLI access control hasn't been consistent across vendors (or > even within vendors' product lines in many cases). ... Agreed. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Jan 26 20:09:08 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 UAA10975; Wed, 26 Jan 2005 20:09:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyQp-000261-9m; Wed, 26 Jan 2005 20:26:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cty1O-0004qx-6m; Wed, 26 Jan 2005 20:00:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctxvu-00042h-5Y for isms@megatron.ietf.org; Wed, 26 Jan 2005 19:54: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 TAA09826 for ; Wed, 26 Jan 2005 19:54:45 -0500 (EST) Received: from smtpout.mac.com ([17.250.248.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyCr-0001mp-5I for isms@ietf.org; Wed, 26 Jan 2005 20:12:24 -0500 Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/MantshX 4.0) with ESMTP id j0R0sf1k015057; Wed, 26 Jan 2005 16:54:41 -0800 (PST) Received: from [10.0.1.3] (c-24-131-57-12.mw.client2.attbi.com [24.131.57.12]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j0R0saLR028580; Wed, 26 Jan 2005 16:54:37 -0800 (PST) In-Reply-To: <200501270016.TAA06776@ietf.org> References: <200501270016.TAA06776@ietf.org> Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <036264C0-6FFE-11D9-9ED3-000A95A03E60@mac.com> From: pmrn Subject: Re: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 19:54:35 -0500 To: ietfdbh@comcast.net X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.1 (/) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1668917176==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 4bbdb236f788407ff689fcae8109fe34 --===============1668917176== Content-Type: multipart/alternative; boundary=Apple-Mail-19--368943490 --Apple-Mail-19--368943490 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Even though I don't work on the WG, I look at the discussion board. Dave is absolutely correct. Today, default password can be changed to any compatible password. As a matter of we urge users to do so for security reasons. I was under the impression that the Proxy module SNMPv3 is backward compatibility. VACM in combined with the Proxy Agent should be able to provide backward compatibility and allow SNMPv3 to interoperate with v1, v2, etc. Pall Ramanathan Amalan Networks On Jan 26, 2005, at 7:15 PM, David B Harrington wrote: > Hi, > > Some comments: > > -- RFC2576 requirements > > Note that RFC2576 is obsolete; it has been replaced by RFC3584. The > document has gone from standards-track to being simply a BCP. So the > "requirement" that requests be handled as noAuthNoPriv doesn't carry > the same weight as if it were a standard. That requireent is there > because SNMPv1 messages have no confidentiality protection. We could > certainly generate a new document, or an appendix to the proposed > security model, that could override RFC3584 for coexistence between > SNMPv1 and the new security model, if the new security model could > provide adequate message secuirty to justify the continued use of the > community-authentication model, or could utilize the community field > of the SNMPv1/v2c message format to transport an authenticatable user > identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that > anything other than public would need to be handled through SNMPv3. > > -- the need to modify agents > > I agree that any new security model might require updating agent code. > > I think the real issue for operators is having to upgrade their whole > systems, not just their legacy agents. As far as I have been able to > determine, most equipment vendors already support SNMPv3-capable > agents in new products; the real problem is that most management > applications do not. Last I checked, HPOV, CA UniCenter, Tivoli, BMC > Patrol, and Spectrum (the five leading multi-vendor platforms last > time I checked) all did not support native SNMPv3; many offer a proxy > via an SNMPv3-daemon, but no direct support for SNMPv3 in their main > device-communications logic. > > So I think the problem is upgrading the operators' systems of > interoperable managers and agents to support SNMPv3. If an SNMP > security model (or security approach, if you will) could secure > SNMPv1/v2c messages then it could be easier for operators to secure > their SNMP systems, even without upgrading their managers to SNMPv3. > If a new SNMP security approach utilized existing security > infrastructure already co-resident with the legacy agents, such as SSH > or SSL/TLS, to secure the messages, then living a while longer with > the SNMPv1/v2c message format and a lack of SNMPv3/VACM access control > might be acceptable. Of course, as Juergen pointed out, it might be > possible to use VACM with an authenticated SNMPv1/v2c message. > > SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the > surrounding security infrastructure. But leveraging an SSH or SSL > approach, which could be applied not only to SNMP but also to CLI > and/or web-based interfaces might justify the incremental costs to > slightly modify the legacy SNMPv1 agents. > > -- demand for VACM > > I haven't found much demand for VACM-style access control from > operators so far. > > I think this is because this access control is not consistent with the > access control/authorization mechanisms used for other management > interfaces, much as USM is not consistent with the authentication > mechanisms for other management interfaces. I think we need to solve > the authentication-consistency problem first, then we can try to solve > the authorization-consistency issue. > > I believe the authorization-consistency issue will require that other > management interfaces make their data objects addressable in a > standard manner. The netconf data modeling may provide mechanisms for > addressing data points hierarchically, and then a VACM-style access > control could be applied to the data for netconf. Hopefully, netconf > will lead the way for standardizing scripting, ala CLI scripting, and > that might lead to some standardization of an addressing mechanism for > CLI parameters. Web-based management data points might also become > addressable via XML. If we can standardize addressability of CLI and > web-based data points, then VACM-style access control could be applied > to those management interfaces. But before we get there, we need to > get user-authentication consistent across interfaces. > > I think it possible that operators will ask us to develop an > authorization mechanism that is more consistent with existing CLI > access control mechanisms, which may or may not be consistent with the > VACM approach. VACM might be able to be deployed in a manner that > would make it consistent with existing CLI access control, but so far > we haven't told the operators how this can be done with VACM, probably > because CLI access control hasn't been consistent across vendors (or > even within vendors' product lines in many cases). > > My $.02 > David Harrington > dbharrington@comcast.net > > >> -----Original Message----- >> From: isms-bounces@lists.ietf.org >> [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn >> Sent: Wednesday, January 26, 2005 4:05 PM >> To: isms@ietf.org >> Subject: Re: [Isms] Evaluation status [and more] >> >> Hi - >> >>> From: "Juergen Schoenwaelder" >>> To: "Randy Presuhn" >>> Cc: >>> Sent: Wednesday, January 26, 2005 12:10 AM >>> Subject: Re: [Isms] Evaluation status [and more] >> ... >>>> Furthermore, it's hard to see how any sort of encapsulation > could >>>> help legacy equipment. If one needs to update the gear to > support >>>> the encapsulation, one may as well do it right and go to SNMPv3 > in >>>> order to get the benefits of access control. >>> >>> I fail to understand the access control argument. You can do VACM >>> access control with SNMPv1/SNMPv2c today as far as I understand >>> things. Please correct me if I am wrong. >> ... >> >> RFC 2576 section 5.2.1 requires requests coming in this way to be >> handled as NoAuthNoPriv. So yes, one can subject these to access >> control, but it's meaningful only in that anything other than > "public" >> would still have to come in through SNMPv3. If one wanted these >> encapsulations to be handled differently, that is, recognizing them >> as authenticated, then one would need to define a new security model >> for the encapsulation, etc., which brings me back to my main point: >> it doesn't help legacy equipment, since one would need to install > new >> software. >> >> 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 > Pall Ramanathan Work: 678-9359670 Mobile: 678-576-7105 www.amalannetworks.com Learn like you will live for ever and Live like you will die tomorrow-Gandhi --Apple-Mail-19--368943490 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Even though I don't work on the WG, I look at the discussion board. Dave is absolutely correct. Today, default password can be changed to any compatible password. As a matter of we urge users to do so for security reasons. I was under the impression that the Proxy module SNMPv3 is backward compatibility. VACM in combined with the Proxy Agent should be able to provide backward compatibility and allow SNMPv3 to interoperate with v1, v2, etc. Pall Ramanathan Amalan Networks On Jan 26, 2005, at 7:15 PM, David B Harrington wrote: Hi, Some comments: -- RFC2576 requirements Note that RFC2576 is obsolete; it has been replaced by RFC3584. The document has gone from standards-track to being simply a BCP. So the "requirement" that requests be handled as noAuthNoPriv doesn't carry the same weight as if it were a standard. That requireent is there because SNMPv1 messages have no confidentiality protection. We could certainly generate a new document, or an appendix to the proposed security model, that could override RFC3584 for coexistence between SNMPv1 and the new security model, if the new security model could provide adequate message secuirty to justify the continued use of the community-authentication model, or could utilize the community field of the SNMPv1/v2c message format to transport an authenticatable user identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that anything other than public would need to be handled through SNMPv3. -- the need to modify agents I agree that any new security model might require updating agent code. I think the real issue for operators is having to upgrade their whole systems, not just their legacy agents. As far as I have been able to determine, most equipment vendors already support SNMPv3-capable agents in new products; the real problem is that most management applications do not. Last I checked, HPOV, CA UniCenter, Tivoli, BMC Patrol, and Spectrum (the five leading multi-vendor platforms last time I checked) all did not support native SNMPv3; many offer a proxy via an SNMPv3-daemon, but no direct support for SNMPv3 in their main device-communications logic. So I think the problem is upgrading the operators' systems of interoperable managers and agents to support SNMPv3. If an SNMP security model (or security approach, if you will) could secure SNMPv1/v2c messages then it could be easier for operators to secure their SNMP systems, even without upgrading their managers to SNMPv3. If a new SNMP security approach utilized existing security infrastructure already co-resident with the legacy agents, such as SSH or SSL/TLS, to secure the messages, then living a while longer with the SNMPv1/v2c message format and a lack of SNMPv3/VACM access control might be acceptable. Of course, as Juergen pointed out, it might be possible to use VACM with an authenticated SNMPv1/v2c message. SNMPv3 is a fairly expensive upgrade from SNMPv1 for an agent and the surrounding security infrastructure. But leveraging an SSH or SSL approach, which could be applied not only to SNMP but also to CLI and/or web-based interfaces might justify the incremental costs to slightly modify the legacy SNMPv1 agents. -- demand for VACM I haven't found much demand for VACM-style access control from operators so far. I think this is because this access control is not consistent with the access control/authorization mechanisms used for other management interfaces, much as USM is not consistent with the authentication mechanisms for other management interfaces. I think we need to solve the authentication-consistency problem first, then we can try to solve the authorization-consistency issue. I believe the authorization-consistency issue will require that other management interfaces make their data objects addressable in a standard manner. The netconf data modeling may provide mechanisms for addressing data points hierarchically, and then a VACM-style access control could be applied to the data for netconf. Hopefully, netconf will lead the way for standardizing scripting, ala CLI scripting, and that might lead to some standardization of an addressing mechanism for CLI parameters. Web-based management data points might also become addressable via XML. If we can standardize addressability of CLI and web-based data points, then VACM-style access control could be applied to those management interfaces. But before we get there, we need to get user-authentication consistent across interfaces. I think it possible that operators will ask us to develop an authorization mechanism that is more consistent with existing CLI access control mechanisms, which may or may not be consistent with the VACM approach. VACM might be able to be deployed in a manner that would make it consistent with existing CLI access control, but so far we haven't told the operators how this can be done with VACM, probably because CLI access control hasn't been consistent across vendors (or even within vendors' product lines in many cases). My $.02 David Harrington dbharrington@comcast.net -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn Sent: Wednesday, January 26, 2005 4:05 PM To: isms@ietf.org Subject: Re: [Isms] Evaluation status [and more] Hi - From: "Juergen Schoenwaelder" < To: "Randy Presuhn" < Cc: < Sent: Wednesday, January 26, 2005 12:10 AM Subject: Re: [Isms] Evaluation status [and more] ... Furthermore, it's hard to see how any sort of encapsulation could help legacy equipment. If one needs to update the gear to support the encapsulation, one may as well do it right and go to SNMPv3 in order to get the benefits of access control. I fail to understand the access control argument. You can do VACM access control with SNMPv1/SNMPv2c today as far as I understand things. Please correct me if I am wrong. ... RFC 2576 section 5.2.1 requires requests coming in this way to be handled as NoAuthNoPriv. So yes, one can subject these to access control, but it's meaningful only in that anything other than "public" would still have to come in through SNMPv3. If one wanted these encapsulations to be handled differently, that is, recognizing them as authenticated, then one would need to define a new security model for the encapsulation, etc., which brings me back to my main point: it doesn't help legacy equipment, since one would need to install new software. 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 Helvetica0000,6262,1B1BPall Ramanathan Work: 678-9359670 Mobile: 678-576-7105 www.amalannetworks.comHelvetica 1616,1D1D,E4E4Learn like you will live for ever and Live like you will die tomorrow-Gandhi --Apple-Mail-19--368943490-- --===============1668917176== 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 --===============1668917176==-- From isms-bounces@ietf.org Wed Jan 26 20:29: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 UAA14162; Wed, 26 Jan 2005 20:29:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtykP-0002aQ-Se; Wed, 26 Jan 2005 20:47:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtyO1-000136-DM; Wed, 26 Jan 2005 20:23:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CtyJB-00009q-6R for isms@megatron.ietf.org; Wed, 26 Jan 2005 20:18: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 UAA12028 for ; Wed, 26 Jan 2005 20:18:51 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtyaC-0002HP-B3 for isms@ietf.org; Wed, 26 Jan 2005 20:36:28 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id 922049DE1; Thu, 27 Jan 2005 02:18:21 +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 29358-01; Thu, 27 Jan 2005 02:18:20 +0100 (CET) Received: from james (I94b3.i.pppool.de [85.73.148.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id 8ED019C7E; Thu, 27 Jan 2005 02:18:20 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1CtyIc-0000sX-Rc; Thu, 27 Jan 2005 02:18:18 +0100 Date: Thu, 27 Jan 2005 02:18:18 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050127011818.GA3336@james> Mail-Followup-To: David B Harrington , 'Randy Presuhn' , isms@ietf.org References: <00d501c503ea$ca80dac0$7f1afea9@oemcomputer> <200501270016.TAA06776@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501270016.TAA06776@ietf.org> 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, Jan 26, 2005 at 07:15:39PM -0500, David B Harrington wrote: > I haven't found much demand for VACM-style access control from > operators so far. No surprise. I would not use an access control system on my hard disk which operates on the block address level while everything I am doing on my hard disk is expressed on the file abstraction level. Operators worry about logical entities such as interfaces not about OIDs. VACM simply does not help (except for defining generic read-only access to protect yourself against potentially nasty writable MIB objects ;-). To be fair, the real root of the problem is the naming system that forced the design of VACM. So in the light of this discussion, whatever netconf may come up with is hopefully incompatible with VACM. /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 Jan 26 21:07: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 VAA18902; Wed, 26 Jan 2005 21:07:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtzLK-0003fY-Uj; Wed, 26 Jan 2005 21:25:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ctz2z-0003BP-TT; Wed, 26 Jan 2005 21: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 1Ctz1Y-0002e0-E1 for isms@megatron.ietf.org; Wed, 26 Jan 2005 21:04: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 VAA18664 for ; Wed, 26 Jan 2005 21:04:42 -0500 (EST) Message-Id: <200501270204.VAA18664@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CtzIa-0003Zx-FB for isms@ietf.org; Wed, 26 Jan 2005 21:22:20 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <2005012702041101400hf75ie>; Thu, 27 Jan 2005 02:04:12 +0000 From: "David B Harrington" To: Subject: RE: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 21:04:07 -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 In-Reply-To: <20050127011818.GA3336@james> Thread-Index: AcUEDhd8JXDlfeLfRv+u4gEx8TY5ewAAuqAA X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Hi, I disagree with your pessimism, but I agree with the issue with the naming system, and the analogy of block-based versus file-based abstraction. That's why I mentioned a VACM-**style** access control system, rather than a VACM-compatible system. I think VACM, adapted to a different naming system (and different verb names), could be viable as an access control model for other management interfaces, if the addressing models for those other management interfaces are hierarchical in nature. If netconf defines an XML-based hierarchical data structure, and the VACM ASI is modified to work with a XML-based hierarchical addressing mechanism, and a verb system comparable to the VACM verb system (get-config, etc.), I think a VACM (hierarchical view-based) approach would be reasonable. I look at CLI interfaces that have "subsystems" of commands and verbs that are consistent across subsystems (e.g., set and show), that correspond roughly to SNMP verbs (set, get), and I think an adapted VACM approach very reasonable. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de] > Sent: Wednesday, January 26, 2005 8:18 PM > To: David B Harrington > Cc: 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] Evaluation status [and more] > > On Wed, Jan 26, 2005 at 07:15:39PM -0500, David B Harrington wrote: > > > I haven't found much demand for VACM-style access control from > > operators so far. > > No surprise. > > I would not use an access control system on my hard disk > which operates > on the block address level while everything I am doing on my hard disk > is expressed on the file abstraction level. > > Operators worry about logical entities such as interfaces not > about OIDs. > VACM simply does not help (except for defining generic > read-only access > to protect yourself against potentially nasty writable MIB > objects ;-). > > To be fair, the real root of the problem is the naming system that > forced the design of VACM. So in the light of this > discussion, whatever > netconf may come up with is hopefully incompatible with VACM. > > /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 Jan 26 22:22:10 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 WAA23020; Wed, 26 Jan 2005 22:22:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu0VZ-0004wm-Cq; Wed, 26 Jan 2005 22:39:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu0Do-0000pf-JE; Wed, 26 Jan 2005 22:21:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu0Ak-0008Sq-5f for isms@megatron.ietf.org; Wed, 26 Jan 2005 22:18: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 WAA22855 for ; Wed, 26 Jan 2005 22:18:15 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu0Rm-0004sQ-Ig for isms@ietf.org; Wed, 26 Jan 2005 22:35:54 -0500 Received: from h-66-167-206-248.snvacaid.dynamic.covad.net ([66.167.206.248] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1Cu0Ad-0004IS-00 for isms@ietf.org; Wed, 26 Jan 2005 19:18:11 -0800 Message-ID: <010f01c5041e$e0318980$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501270016.TAA06776@ietf.org> <036264C0-6FFE-11D9-9ED3-000A95A03E60@mac.com> Subject: Re: [Isms] Evaluation status [and more] Date: Wed, 26 Jan 2005 19:18:26 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: ea4ac80f790299f943f0a53be7e1a21a Hi - > From: "pmrn" > To: > Cc: "'Randy Presuhn'" ; > Sent: Wednesday, January 26, 2005 4:54 PM > Subject: Re: [Isms] Evaluation status [and more] ... > SNMPv3 is backward compatibility. VACM in combined with the Proxy Agent > should be able to provide backward compatibility and allow SNMPv3 to > interoperate with v1, v2, etc. ... That's not how SNMP proxy works. See http://www.ietf.org/rfc/rfc3584.txt for details. The VACM configuration at the proxy is not applied to forwarded requests and responses. One could argue about whether this is a bug or a feature, but this was the approach taken for reasons of compatibility with earlier approaches to SNMP proxy. One would need to define a new kind of proxy if one wanted to do the access control at the proxy as well as at the managed device. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 27 02:54: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 CAA28698; Thu, 27 Jan 2005 02:54:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu4kn-0002Wj-1i; Thu, 27 Jan 2005 03:11:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4KW-0002Zl-5C; Thu, 27 Jan 2005 02:44:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cu4Bk-0008Nt-Kx for isms@megatron.ietf.org; Thu, 27 Jan 2005 02: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 CAA26922 for ; Thu, 27 Jan 2005 02:35:34 -0500 (EST) Received: from hermes.iu-bremen.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cu4So-00021b-5n for isms@ietf.org; Thu, 27 Jan 2005 02:53:15 -0500 Received: from localhost (demetrius.iu-bremen.de [212.201.44.32]) by hermes.iu-bremen.de (Postfix) with ESMTP id C4DB1C96E; Thu, 27 Jan 2005 08:35:00 +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 08943-02; Thu, 27 Jan 2005 08:35:00 +0100 (CET) Received: from james (Iad3c.i.pppool.de [85.73.173.60]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by hermes.iu-bremen.de (Postfix) with ESMTP id D0FE19C32; Thu, 27 Jan 2005 08:34:59 +0100 (CET) Received: from schoenw by james with local (Exim 4.34) id 1Cu4B2-0000ph-Vy; Thu, 27 Jan 2005 08:34:54 +0100 Date: Thu, 27 Jan 2005 08:34:52 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] Evaluation status [and more] Message-ID: <20050127073452.GB2455@james> Mail-Followup-To: David B Harrington , 'Randy Presuhn' , isms@ietf.org References: <20050127011818.GA3336@james> <20050127020915.D3FEAC96E@hermes.iu-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050127020915.D3FEAC96E@hermes.iu-bremen.de> 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: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 On Wed, Jan 26, 2005 at 09:04:07PM -0500, David B Harrington wrote: > I disagree with your pessimism, but I agree with the issue with the > naming system, and the analogy of block-based versus file-based > abstraction. > > That's why I mentioned a VACM-**style** access control system, rather > than a VACM-compatible system. Sorry for misreading vacm-style as vacm-compatible. /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 Jan 27 13:03: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 NAA07342; Thu, 27 Jan 2005 13:03:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuEGY-0002By-Kl; Thu, 27 Jan 2005 13:21:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDty-000328-TQ; Thu, 27 Jan 2005 12:57:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuDr6-000288-Ad for isms@megatron.ietf.org; Thu, 27 Jan 2005 12:54: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 MAA06692 for ; Thu, 27 Jan 2005 12:54:52 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuE8F-0001zc-MC for isms@ietf.org; Thu, 27 Jan 2005 13:12:40 -0500 Received: from pc6 (1Cust43.tnt14.lnd4.gbr.da.uu.net [62.188.143.43]) by blaster.systems.pipex.net (Postfix) with SMTP id 4632FE000429; Thu, 27 Jan 2005 17:54:16 +0000 (GMT) Message-ID: <027c01c50490$9bfedca0$0601a8c0@pc6> From: "Tom Petch" To: "Randy Presuhn" , References: <200501261915.1cTXk43Ex3Nl3pK0@gideon.mail.atl.earthlink.net> <00dc01c50409$db300020$7f1afea9@oemcomputer> Subject: Re: [Isms] Evaluation status [and more] Date: Thu, 27 Jan 2005 17:49:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 1.3 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Thursday, January 27, 2005 1:48 AM Subject: Re: [Isms] Evaluation status [and more] > > > From: "David B Harrington" > > To: "'Randy Presuhn'" ; > > Sent: Wednesday, January 26, 2005 4:15 PM > > Subject: RE: [Isms] Evaluation status [and more] > ... > > Note that RFC2576 is obsolete; it has been replaced by RFC3584. The > > A stale cache error on my part, but it doesn't affect my point. > > > document has gone from standards-track to being simply a BCP. So the > > "requirement" that requests be handled as noAuthNoPriv doesn't carry > > the same weight as if it were a standard. That requireent is there > > because SNMPv1 messages have no confidentiality protection. We could > > certainly generate a new document, or an appendix to the proposed > > security model, that could override RFC3584 for coexistence between > > SNMPv1 and the new security model, if the new security model could > > provide adequate message secuirty to justify the continued use of the > > community-authentication model, or could utilize the community field > > of the SNMPv1/v2c message format to transport an authenticatable user > > identity (e.g. via SNMPv2a) for use by VACM. So I don't agree that > > anything other than public would need to be handled through SNMPv3. > > We're actually in agreement: if one wants to use SNMPv1 over a secure > transport that provides real authentication services, one would need to > define a new security model to make use of it, since authentication doesn't > have much of a point until teamed up with an access control model of some kind. > but that access control model can be much simpler. Outside of SNMP, the most complex I typically find is - no access - read access to everyday things - read access to almost everything and write access to most configuration details - read access to everything and write access to almost everything (eg software reload) Using SNMP (v1) then this often maps into a choice of community name perhaps coupled with a check on the source IP address which, if passed, gives me one of these levels of access. This is so simple that I would not normally dignify it with the name of an access control model, but it does the job; or would if the authentication - community name, source IP address - were strong enough to counter modern attackers. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 27 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 OAA13559; Thu, 27 Jan 2005 14:07:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuFG9-0003sf-Jr; Thu, 27 Jan 2005 14:24:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuEy5-0000Wu-9D; Thu, 27 Jan 2005 14: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 1CuEvA-0007i2-9a for isms@megatron.ietf.org; Thu, 27 Jan 2005 14:03: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 OAA13286 for ; Thu, 27 Jan 2005 14:03:10 -0500 (EST) Received: from pop-a065d14.pas.sa.earthlink.net ([207.217.121.252]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuFCL-0003mZ-4T for isms@ietf.org; Thu, 27 Jan 2005 14:20:57 -0500 Received: from h-69-3-26-11.snvacaid.dynamic.covad.net ([69.3.26.11] helo=oemcomputer) by pop-a065d14.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CuEv3-0001S1-00 for isms@ietf.org; Thu, 27 Jan 2005 11:03:06 -0800 Message-ID: <003701c504a2$e0abdda0$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501261915.1cTXk43Ex3Nl3pK0@gideon.mail.atl.earthlink.net> <00dc01c50409$db300020$7f1afea9@oemcomputer> <027c01c50490$9bfedca0$0601a8c0@pc6> Subject: Re: [Isms] Evaluation status [and more] Date: Thu, 27 Jan 2005 11:03:24 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: f4c2cf0bccc868e4cc88dace71fb3f44 Hi - > From: "Tom Petch" > To: "Randy Presuhn" ; > Sent: Thursday, January 27, 2005 8:49 AM > Subject: Re: [Isms] Evaluation status [and more] ... > > We're actually in agreement: if one wants to use SNMPv1 over a secure > > transport that provides real authentication services, one would need to > > define a new security model to make use of it, since authentication doesn't > > have much of a point until teamed up with an access control model of some > > kind. > > but that access control model can be much simpler. Outside of SNMP, the most > complex I typically find is > - no access > - read access to everyday things > - read access to almost everything and write access to most configuration > details > - read access to everything and write access to almost everything (eg software > reload) This begs the question of how one identifies which things are "everyday things", which things are "configuration details", and which bits are sensitive like "software reload". As other postings in this thread have indicated, SNMP's naming architecture quickly drives you to something like VACM. But the real point here is that you've just described an access control model. Without real authentication, the access control model is pretty useless, and with an access control model, the only value of authentication would be an audit trail, and we don't (currently) do that. > Using SNMP (v1) then this often maps into a choice of community name perhaps > coupled with a check on the source IP address which, if passed, gives me one of > these > levels of access. > > This is so simple that I would not normally dignify it with the name of an > access control model, but it does the job; or would if the authentication - > community name, source IP address - were strong enough to counter modern > attackers. And pigs could easily fly if they had wings and were lighter and were more aerodynamic. :-) Seriously, one could define a new protocol that contained SNMPv1 PDUs, and new security model to map its security levels and user identification mechanism into access control groups for VACM or some other security model, but I really don't see how that would bring us any closer to the WG's goal of integrating SNMPv3 with non-SNMP security infrastructure. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Jan 27 20:55: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 UAA22697; Thu, 27 Jan 2005 20:55:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuLdF-0006XC-8Y; Thu, 27 Jan 2005 21:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuLKv-0001QW-VA; Thu, 27 Jan 2005 20:54:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuLJ7-0000rp-AN for isms@megatron.ietf.org; Thu, 27 Jan 2005 20:52: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 UAA22419 for ; Thu, 27 Jan 2005 20:52:19 -0500 (EST) Message-Id: <200501280152.UAA22419@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuLaM-0006Sm-1M for isms@ietf.org; Thu, 27 Jan 2005 21:10:10 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <20050128015149014003da4ve>; Fri, 28 Jan 2005 01:51:49 +0000 From: "David B Harrington" To: Date: Thu, 27 Jan 2005 20:51:46 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0280_01C504B2.046D7820" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUEt2perowZMY60RS6FbLeKJBdyNwAJG+gA X-Spam-Score: 0.1 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Subject: [Isms] FW: I-D ACTION:draft-ietf-ips-auth-mib-06.txt 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: 21bf7a2f1643ae0bf20c1e010766eb78 This is a multi-part message in MIME format. ------=_NextPart_000_0280_01C504B2.046D7820 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit FYI. > -----Original Message----- > From: i-d-announce-bounces@ietf.org > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Thursday, January 27, 2005 3:54 PM > To: i-d-announce@ietf.org > Cc: ips@ietf.org > Subject: I-D ACTION:draft-ietf-ips-auth-mib-06.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > This draft is a work item of the IP Storage Working Group of the IETF. > > Title : Definitions of Managed Objects for > User Identity Authentication > Author(s) : M. Bakke, J. Muchow > Filename : draft-ietf-ips-auth-mib-06.txt > Pages : 33 > Date : 2005-1-27 > > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in TCP/IP based > internets. > In particular it defines objects for managing user > identities and the > names, addresses, and credentials required manage access > control, for > use with various protocols. This draft was motivated by > the need for > the configuration of authorized user identities for the iSCSI > protocol, but has been extended to be useful for other > protocols that > have similar requirements. It is important to note that this MIB > module provides only the set of identities to be used within access > lists; it is the responsibility of other MIB modules making use of > this one to tie them to their own access lists or other > authorization > control methods. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ips-auth-mib-06.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-ips-auth-mib-06.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-ips-auth-mib-06.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_000_0280_01C504B2.046D7820 Content-Type: Message/External-body; name="ATT00625.dat" Content-Disposition: attachment; filename="ATT00625.dat" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-1-27144008.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ips-auth-mib-06.txt ------=_NextPart_000_0280_01C504B2.046D7820 Content-Type: Message/External-body; name="draft-ietf-ips-auth-mib-06.txt" Content-Disposition: attachment; filename="draft-ietf-ips-auth-mib-06.txt" Content-Transfer-Encoding: 7bit Content-Type: text/plain Content-ID: <2005-1-27144008.I-D@ietf.org> ------=_NextPart_000_0280_01C504B2.046D7820 Content-Type: text/plain; name="ATT00628.txt" Content-Disposition: attachment; filename="ATT00628.txt" Content-Transfer-Encoding: 7bit _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------=_NextPart_000_0280_01C504B2.046D7820 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 ------=_NextPart_000_0280_01C504B2.046D7820-- From isms-bounces@ietf.org Fri Jan 28 07:29: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 HAA23534; Fri, 28 Jan 2005 07:29:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVWk-0003Gt-Nz; Fri, 28 Jan 2005 07:47:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuVEX-00061a-Ls; Fri, 28 Jan 2005 07:28:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuV9z-000501-8u for isms@megatron.ietf.org; Fri, 28 Jan 2005 07:23: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 HAA23111 for ; Fri, 28 Jan 2005 07:23:33 -0500 (EST) Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuVRI-00037z-ED for isms@ietf.org; Fri, 28 Jan 2005 07:41:28 -0500 Received: from pc6 (1Cust58.tnt30.lnd3.gbr.da.uu.net [62.188.122.58]) by ranger.systems.pipex.net (Postfix) with SMTP id CD087E00019B; Fri, 28 Jan 2005 12:22:55 +0000 (GMT) Message-ID: <003701c5052b$7bd1b240$0601a8c0@pc6> From: "Tom Petch" To: "Randy Presuhn" , References: <200501261915.1cTXk43Ex3Nl3pK0@gideon.mail.atl.earthlink.net><00dc01c50409$db300020$7f1afea9@oemcomputer><027c01c50490$9bfedca0$0601a8c0@pc6> <003701c504a2$e0abdda0$7f1afea9@oemcomputer> Subject: Re: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 12:19:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Content-Transfer-Encoding: 7bit I expect I am not making myself clear. I am agreeing with David that SNMPv1/v2c with better authentication is enough. I am disagreeing with the idea that because of VACM, reusing parts of SNMPv1/v2c does not save anything. Whether using SNMP or CLI, I have never had, and have never missed, what SNMPv3 VACM has to offer, all that putting objects into trees so that I can offer fine grained authorisation as part of network management. (System management is different). Rather, the manufacturer of the router or switch or hub has set up two or three or four proprietary categories of authorisation and has pre-assigned, immutably, all functions into a category for me; and that is adequate. All I then need is authentication that the sender of the SNMP message has low or medium or high security; this could be implicit in the authentication, eg determined by key length. Authentication matters, and needs to be strong, but authorisation can be a simple ternary or binay model for many needs. Tom Petch ----- Original Message ----- From: "Randy Presuhn" To: Sent: Thursday, January 27, 2005 8:03 PM Subject: Re: [Isms] Evaluation status [and more] > > From: "Tom Petch" > > To: "Randy Presuhn" ; > > Sent: Thursday, January 27, 2005 8:49 AM > > Subject: Re: [Isms] Evaluation status [and more] > ... > > > We're actually in agreement: if one wants to use SNMPv1 over a secure > > > transport that provides real authentication services, one would need to > > > define a new security model to make use of it, since authentication doesn't > > > have much of a point until teamed up with an access control model of some > > > kind. > > > > but that access control model can be much simpler. Outside of SNMP, the most > > complex I typically find is > > - no access > > - read access to everyday things > > - read access to almost everything and write access to most configuration > > details > > - read access to everything and write access to almost everything (eg software > > reload) > > This begs the question of how one identifies which things are "everyday things", > which things are "configuration details", and which bits are sensitive like > "software reload". As other postings in this thread have indicated, SNMP's > naming architecture quickly drives you to something like VACM. But the real > point here is that you've just described an access control model. Without > real authentication, the access control model is pretty useless, and with an > access control model, the only value of authentication would be an audit trail, > and we don't (currently) do that. > > > Using SNMP (v1) then this often maps into a choice of community name perhaps > > coupled with a check on the source IP address which, if passed, gives me one of > > these > > levels of access. > > > > This is so simple that I would not normally dignify it with the name of an > > access control model, but it does the job; or would if the authentication - > > community name, source IP address - were strong enough to counter modern > > attackers. > > And pigs could easily fly if they had wings and were lighter and were more > aerodynamic. :-) Seriously, one could define a new protocol that contained > SNMPv1 PDUs, and new security model to map its security levels and user > identification mechanism into access control groups for VACM or some other > security model, but I really don't see how that would bring us any closer to the > WG's goal of integrating SNMPv3 with non-SNMP security infrastructure. > > 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 Fri Jan 28 08:51: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 IAA01337; Fri, 28 Jan 2005 08:51:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuWnz-0005Kf-GJ; Fri, 28 Jan 2005 09:08:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuWTb-0004Dm-ML; Fri, 28 Jan 2005 08:47:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuWOf-00034V-QT for isms@megatron.ietf.org; Fri, 28 Jan 2005 08: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 IAA00585 for ; Fri, 28 Jan 2005 08:42:48 -0500 (EST) Message-Id: <200501281342.IAA00585@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuWg0-00057X-Gg for isms@ietf.org; Fri, 28 Jan 2005 09:00:44 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <200501281342170140039at5e>; Fri, 28 Jan 2005 13:42:17 +0000 From: "David B Harrington" To: "'Tom Petch'" , "'Randy Presuhn'" , Subject: RE: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 08:42:15 -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 In-Reply-To: <003701c5052b$7bd1b240$0601a8c0@pc6> Thread-Index: AcUFNPgsBtT6TJinSpWVy2qDpIH7fgACJ8wA X-Spam-Score: 0.1 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit Hi, SNMPv1/v2c with message integrity checking and confidentiality, yielding better authentication is enough in environments that don't require VACM; other environments may want the full-blown features of SNMPv3/VACM. Lower layers may be able to provide the integrity/confidentiality security features for SNMPv1/v2c messages, and also for SNMPv3 messages. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Tom Petch > Sent: Friday, January 28, 2005 6:19 AM > To: Randy Presuhn; isms@ietf.org > Subject: Re: [Isms] Evaluation status [and more] > > I expect I am not making myself clear. I am agreeing with > David that SNMPv1/v2c > with better authentication is enough. I am disagreeing with > the idea that > because of VACM, reusing parts of SNMPv1/v2c does not save anything. > > Whether using SNMP or CLI, I have never had, and have never > missed, what SNMPv3 > VACM has to offer, all that putting objects into trees so that I > can offer fine grained authorisation as part of network > management. (System > management is different). Rather, the manufacturer of the > router or switch or > hub has set up two or three or four proprietary categories of > authorisation and > has pre-assigned, immutably, all functions into a category > for me; and that is > adequate. > > All I then need is authentication that the sender of the SNMP > message has low > or medium or high security; this could be implicit in the > authentication, > eg determined by key length. Authentication matters, and > needs to be strong, > but authorisation can be a simple ternary or binay model for > many needs. > > Tom Petch > ----- Original Message ----- > From: "Randy Presuhn" > To: > Sent: Thursday, January 27, 2005 8:03 PM > Subject: Re: [Isms] Evaluation status [and more] > > > > > From: "Tom Petch" > > > To: "Randy Presuhn" ; > > > > Sent: Thursday, January 27, 2005 8:49 AM > > > Subject: Re: [Isms] Evaluation status [and more] > > ... > > > > We're actually in agreement: if one wants to use SNMPv1 > over a secure > > > > transport that provides real authentication services, > one would need to > > > > define a new security model to make use of it, since > authentication > doesn't > > > > have much of a point until teamed up with an access > control model of some > > > > kind. > > > > > > but that access control model can be much simpler. > Outside of SNMP, the > most > > > complex I typically find is > > > - no access > > > - read access to everyday things > > > - read access to almost everything and write access to > most configuration > > > details > > > - read access to everything and write access to almost > everything (eg > software > > > reload) > > > > This begs the question of how one identifies which things > are "everyday > things", > > which things are "configuration details", and which bits > are sensitive like > > "software reload". As other postings in this thread have > indicated, SNMP's > > naming architecture quickly drives you to something like > VACM. But the real > > point here is that you've just described an access control > model. Without > > real authentication, the access control model is pretty > useless, and with an > > access control model, the only value of authentication > would be an audit > trail, > > and we don't (currently) do that. > > > > > Using SNMP (v1) then this often maps into a choice of > community name perhaps > > > coupled with a check on the source IP address which, if > passed, gives me one > of > > > these > > > levels of access. > > > > > > This is so simple that I would not normally dignify it > with the name of an > > > access control model, but it does the job; or would if > the authentication - > > > community name, source IP address - were strong enough to > counter modern > > > attackers. > > > > And pigs could easily fly if they had wings and were > lighter and were more > > aerodynamic. :-) Seriously, one could define a new > protocol that contained > > SNMPv1 PDUs, and new security model to map its security > levels and user > > identification mechanism into access control groups for > VACM or some other > > security model, but I really don't see how that would bring > us any closer to > the > > WG's goal of integrating SNMPv3 with non-SNMP security > infrastructure. > > > > 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 Fri Jan 28 15:17:10 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 PAA09265; Fri, 28 Jan 2005 15:17:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cucpi-00070B-Sk; Fri, 28 Jan 2005 15:35:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CucSY-0004mF-6R; Fri, 28 Jan 2005 15:11:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CucO6-00039E-5c for isms@megatron.ietf.org; Fri, 28 Jan 2005 15:06:38 -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 PAA07994 for ; Fri, 28 Jan 2005 15:06:35 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CucfS-0006lu-RR for isms@ietf.org; Fri, 28 Jan 2005 15:24:36 -0500 Received: from h-69-3-25-221.snvacaid.dynamic.covad.net ([69.3.25.221] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CucNz-0004g2-00 for isms@ietf.org; Fri, 28 Jan 2005 12:06:31 -0800 Message-ID: <004601c50574$e8542120$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501261915.1cTXk43Ex3Nl3pK0@gideon.mail.atl.earthlink.net><00dc01c50409$db300020$7f1afea9@oemcomputer><027c01c50490$9bfedca0$0601a8c0@pc6> <003701c504a2$e0abdda0$7f1afea9@oemcomputer> <003701c5052b$7bd1b240$0601a8c0@pc6> Subject: Re: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 12:06:37 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: fb6060cb60c0cea16e3f7219e40a0a81 Hi - > From: "Tom Petch" > To: "Randy Presuhn" ; > Sent: Friday, January 28, 2005 3:19 AM > Subject: Re: [Isms] Evaluation status [and more] > > I expect I am not making myself clear. I am agreeing with David that SNMPv1/v2c > with better authentication is enough. I am disagreeing with the idea that > because of VACM, reusing parts of SNMPv1/v2c does not save anything. SNMPv2c and SNMPv3 have the same PDU format, and only differ in the "wrapper". The wrapper is where authentication information is carried in these two protocols. Fixing SNMPv2c authentication so that it actually provides some security results in a different protocol, modifying the fields where SNMPv2c and SNMPv3 differ. The issue is not VACM, it's *ANY* access control model. Without authentication, access control doesn't have what it needs to make a decision. Providing authentication without access control would make an audit trail possible, but would provide no protection. > Whether using SNMP or CLI, I have never had, and have never missed, what SNMPv3 > VACM has to offer, all that putting objects into trees so that I This is the only way we have of uniquely identifying information in SNMP. > can offer fine grained authorisation as part of network management. (System There's nothing that requires you to use the fine-grained capability if you don't need it. > management is different). Rather, the manufacturer of the router or switch or > hub has set up two or three or four proprietary categories of authorisation and > has pre-assigned, immutably, all functions into a category for me; and that is > adequate. And this could be done with VACM (StorageType=permanent) and pre-defined groups by manufacturers, if they thought customers would buy it. Consider RFC 3415 appendix A.1 as a case study. > All I then need is authentication that the sender of the SNMP message has low > or medium or high security; this could be implicit in the authentication, > eg determined by key length. Authentication matters, and needs to be strong, > but authorisation can be a simple ternary or binay model for many needs. ... If I understand you correctly, you're making a couple of claims: 1) the number of groups in most VACM configurations would be two or three. (For a lot of equipment, I believe this to be true.) 2) the decision about which bits of management information should be accessible to which of these groups does not need to be under control of the security administrator. 3) equipment manufacturers will decide which groups get which access, and it would be acceptible if this could be changed only by a firmware/software upgrade Did I get this much right? If so, do you think a standard policy for these could be formulated as an addendum to RFC 3415 appendix A.1? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 28 16:52:12 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 QAA23498; Fri, 28 Jan 2005 16:52:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CueJf-00030b-PG; Fri, 28 Jan 2005 17:10:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudpF-0006rI-RJ; Fri, 28 Jan 2005 16:38:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudNO-0006H2-N2 for isms@megatron.ietf.org; Fri, 28 Jan 2005 16:09:58 -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 QAA13521 for ; Fri, 28 Jan 2005 16:09:56 -0500 (EST) Message-Id: <200501282109.QAA13521@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cudem-0008BO-Ip for isms@ietf.org; Fri, 28 Jan 2005 16:27:57 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005012821092301300k5kbie>; Fri, 28 Jan 2005 21:09:23 +0000 From: "David B Harrington" To: "'Randy Presuhn'" , Subject: RE: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 16:09:21 -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 In-Reply-To: <004601c50574$e8542120$7f1afea9@oemcomputer> Thread-Index: AcUFdlknPII4FuVPQnylVBhvCuYBigAAHadw X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > If I understand you correctly, you're making a couple of claims: > > 1) the number of groups in most VACM configurations would be > two or three. (For a lot of equipment, I believe > this to be true.) > > 2) the decision about which bits of management information should > be accessible to which of these groups does not need to be > under control of the security administrator. > > 3) equipment manufacturers will decide which groups get > which access, > and it would be acceptible if this could be changed only by a > firmware/software upgrade > > Did I get this much right? > If so, do you think a standard policy for these could be > formulated as an > addendum to RFC 3415 appendix A.1? > > Randy > I believe this is fairly accurate as a representation of what exists. And I think we coul dhelp the SNMP community migrate from communities to VACM much more than we have by defining incremental migration paths. We could do a service to operators by defining some standard access control templates for VACM groups, comparable to public (r-o most), private (r-w-most), and super-user (r-w-all). This would help admins accustomed to the traditional SNMPv1 communities to migrate to VACM access control. Then admins could expand the group assignments from that point if desired. I would consider adding a new security-admin (r-w security mibs, such as VACM and USM and RADIUS) as well. I think it would help admins if we discussed how applications can serve as SNMPv3 USM users, for all their users. Some applications already provide user-level access control. I don't like this as much as agent-access-control, but it is easier to configure USM with a few applications than with larger number of users, while ISMS tries to improve ease-of-use. On a side note, Spectrum used to provide something like nine levels of user access control, and now only provide three because customers never used the extra six levels. In SNMPv1, the immutable assignments were made to communities, but I'm not sure whether contexts, views or groups are the right answer in SNMPv3. Contexts are the immutable entities, so I think contexts might be the right answer. I think we could help the vendors provide default assignment of mib modules to public/private/root contexts by providing a list of IETF mib modules, and recommend which context they should be associated with. David Harrington dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 28 16:57: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 QAA24123; Fri, 28 Jan 2005 16:57:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CueOi-0003Cn-KD; Fri, 28 Jan 2005 17:15:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cue0t-000748-D9; Fri, 28 Jan 2005 16:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CudgJ-0000BW-IZ for isms@megatron.ietf.org; Fri, 28 Jan 2005 16:29: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 QAA17380 for ; Fri, 28 Jan 2005 16:29:29 -0500 (EST) Received: from pop-a065d05.pas.sa.earthlink.net ([207.217.121.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cudxg-000164-N8 for isms@ietf.org; Fri, 28 Jan 2005 16:47:31 -0500 Received: from h-69-3-25-221.snvacaid.dynamic.covad.net ([69.3.25.221] helo=oemcomputer) by pop-a065d05.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1CudgF-0007UE-00 for isms@ietf.org; Fri, 28 Jan 2005 13:29:27 -0800 Message-ID: <002b01c50580$7ebb8b20$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200501281609.1cUDmQ7CG3Nl3oX0@new.mail.atl.earthlink.net> Subject: Re: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 13:29:48 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 8abaac9e10c826e8252866cbe6766464 Hi - > From: "David B Harrington" > To: "'Randy Presuhn'" ; > Sent: Friday, January 28, 2005 1:09 PM > Subject: RE: [Isms] Evaluation status [and more] ... (lots of agreement deleted) ... > In SNMPv1, the immutable assignments were made to communities, but I'm > not sure whether contexts, views or groups are the right answer in > SNMPv3. Contexts are the immutable entities, so I think contexts might > be the right answer. I think we could help the vendors provide default > assignment of mib modules to public/private/root contexts by providing > a list of IETF mib modules, and recommend which context they should be > associated with. ... I think using contexts to accomplish this would take us back to the semantic tangle we had with communities. I think groups are a better match, since the VACM defines a group as a set of users with identical permissions. Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 28 17:33: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 RAA27528; Fri, 28 Jan 2005 17:33:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuexJ-0004KC-6e; Fri, 28 Jan 2005 17:51:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuef6-0004bO-8l; Fri, 28 Jan 2005 17:32:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CueYI-0002lI-O2 for isms@megatron.ietf.org; Fri, 28 Jan 2005 17:25: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 RAA27088 for ; Fri, 28 Jan 2005 17:25:16 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuepi-000493-6f for isms@ietf.org; Fri, 28 Jan 2005 17:43:18 -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 j0SMOgaD003289; Fri, 28 Jan 2005 14:24:42 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j0SMOlFs030462; Fri, 28 Jan 2005 14:24:47 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j0SMOl7x030458; Fri, 28 Jan 2005 14:24:47 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 28 Jan 2005 14:24:46 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: David B Harrington Subject: RE: [Isms] Evaluation status [and more] In-Reply-To: <200501282109.QAA13521@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 HI, Interesting... Lets say there are three "roles" or "capabilities", which would correspond to VACM groups. Given these, the standards track documents containing MIB modules could indicate which objects and notifications should be available for access type for each role. Given this info in RFCs, it would be a mechanical process to create entries in the view, and access tables. That is, entries in table vacmViewTreeFamilyTable, and table vacmAccessTable. Entries would be created in tables usmUserTable and vacmSecurityToGroupTable when support for a new a user is added. And entries would be created in tables snmpCommunityTable and vacmSecurityToGroupTable when support for a new community string is added. On Fri, 28 Jan 2005, David B Harrington wrote: > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > If I understand you correctly, you're making a couple of claims: > > > > 1) the number of groups in most VACM configurations would be > > two or three. (For a lot of equipment, I believe > > this to be true.) > > > > 2) the decision about which bits of management information > should > > be accessible to which of these groups does not need to be > > under control of the security administrator. > > > > 3) equipment manufacturers will decide which groups get > > which access, > > and it would be acceptible if this could be changed only by > a > > firmware/software upgrade > > > > Did I get this much right? > > If so, do you think a standard policy for these could be > > formulated as an > > addendum to RFC 3415 appendix A.1? > > > > Randy > > > I believe this is fairly accurate as a representation of what exists. > And I think we coul dhelp the SNMP community migrate from communities > to VACM much more than we have by defining incremental migration > paths. > > We could do a service to operators by defining some standard access > control templates for VACM groups, comparable to public (r-o most), > private (r-w-most), and super-user (r-w-all). This would help admins > accustomed to the traditional SNMPv1 communities to migrate to VACM > access control. Then admins could expand the group assignments from > that point if desired. I would consider adding a new security-admin > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > I think it would help admins if we discussed how applications can > serve as SNMPv3 USM users, for all their users. Some applications > already provide user-level access control. I don't like this as much > as agent-access-control, but it is easier to configure USM with a few > applications than with larger number of users, while ISMS tries to > improve ease-of-use. On a side note, Spectrum used to provide > something like nine levels of user access control, and now only > provide three because customers never used the extra six levels. > > In SNMPv1, the immutable assignments were made to communities, but I'm > not sure whether contexts, views or groups are the right answer in > SNMPv3. Contexts are the immutable entities, so I think contexts might > be the right answer. I think we could help the vendors provide default > assignment of mib modules to public/private/root contexts by providing > a list of IETF mib modules, and recommend which context they should be > associated with. > > David Harrington > dbharrington@comcast.net Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Jan 28 19:17: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 TAA06711; Fri, 28 Jan 2005 19:17:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cuga8-0006RG-7E; Fri, 28 Jan 2005 19:35:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cug9d-0000Bw-Qu; Fri, 28 Jan 2005 19:07:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cug3C-0007PQ-5k for isms@megatron.ietf.org; Fri, 28 Jan 2005 19:01: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 TAA05200 for ; Fri, 28 Jan 2005 19:01:15 -0500 (EST) Message-Id: <200501290001.TAA05200@ietf.org> Received: from rwcrmhc11.comcast.net ([204.127.198.35]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CugKc-00061w-Nn for isms@ietf.org; Fri, 28 Jan 2005 19:19:19 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc11) with SMTP id <2005012900004601300k2v3be>; Sat, 29 Jan 2005 00:00:46 +0000 From: "David B Harrington" To: "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Fri, 28 Jan 2005 19:00:43 -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 In-Reply-To: Thread-Index: AcUFiCtL2ZXdFsWHRhCTyM2AkSU+MQADTQVQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: 7bit Yes, and if you can parse the security considerabtions boilerplate to find the objects in each category, that info may already be broken out to a degree. Not well, but to a degree. dbh > -----Original Message----- > From: David T. Perkins [mailto:dperkins@dsperkins.com] > Sent: Friday, January 28, 2005 5:25 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > HI, > > Interesting... > Lets say there are three "roles" or "capabilities", > which would correspond to VACM groups. Given > these, the standards track documents containing MIB modules > could indicate which objects and notifications should > be available for access type for each role. Given this > info in RFCs, it would be a mechanical process to > create entries in the view, and access tables. > That is, entries in table vacmViewTreeFamilyTable, > and table vacmAccessTable. > > Entries would be created in tables usmUserTable and > vacmSecurityToGroupTable when support for a new a user > is added. And entries would be created in tables > snmpCommunityTable and vacmSecurityToGroupTable > when support for a new community string is added. > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > 1) the number of groups in most VACM configurations would be > > > two or three. (For a lot of equipment, I believe > > > this to be true.) > > > > > > 2) the decision about which bits of management information > > should > > > be accessible to which of these groups does not need to be > > > under control of the security administrator. > > > > > > 3) equipment manufacturers will decide which groups get > > > which access, > > > and it would be acceptible if this could be > changed only by > > a > > > firmware/software upgrade > > > > > > Did I get this much right? > > > If so, do you think a standard policy for these could be > > > formulated as an > > > addendum to RFC 3415 appendix A.1? > > > > > > Randy > > > > > I believe this is fairly accurate as a representation of > what exists. > > And I think we coul dhelp the SNMP community migrate from > communities > > to VACM much more than we have by defining incremental migration > > paths. > > > > We could do a service to operators by defining some standard access > > control templates for VACM groups, comparable to public (r-o most), > > private (r-w-most), and super-user (r-w-all). This would > help admins > > accustomed to the traditional SNMPv1 communities to migrate to VACM > > access control. Then admins could expand the group assignments from > > that point if desired. I would consider adding a new security-admin > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > I think it would help admins if we discussed how applications can > > serve as SNMPv3 USM users, for all their users. Some applications > > already provide user-level access control. I don't like this as much > > as agent-access-control, but it is easier to configure USM > with a few > > applications than with larger number of users, while ISMS tries to > > improve ease-of-use. On a side note, Spectrum used to provide > > something like nine levels of user access control, and now only > > provide three because customers never used the extra six levels. > > > > In SNMPv1, the immutable assignments were made to > communities, but I'm > > not sure whether contexts, views or groups are the right answer in > > SNMPv3. Contexts are the immutable entities, so I think > contexts might > > be the right answer. I think we could help the vendors > provide default > > assignment of mib modules to public/private/root contexts > by providing > > a list of IETF mib modules, and recommend which context > they should be > > associated with. > > > > David Harrington > > dbharrington@comcast.net > > Regards, > /david t. perkins > > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Jan 29 12:23: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 MAA24825; Sat, 29 Jan 2005 12:23:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuwbG-0007xO-OE; Sat, 29 Jan 2005 12:41:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CuwF2-0003gC-So; Sat, 29 Jan 2005 12:18:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cuw9z-0001Jv-8u for isms@megatron.ietf.org; Sat, 29 Jan 2005 12:13: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 MAA24095 for ; Sat, 29 Jan 2005 12:13:20 -0500 (EST) Message-Id: <200501291713.MAA24095@ietf.org> Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CuwRY-0007jK-Lw for isms@ietf.org; Sat, 29 Jan 2005 12:31:33 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc13) with SMTP id <20050129171250015009mhe5e>; Sat, 29 Jan 2005 17:12:50 +0000 From: "David B Harrington" To: "'Martin Soukup'" , "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Sat, 29 Jan 2005 12:12:49 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcUGDdW5fbqK2kvsTCuPCKYw2XwiXQAFQHTQ In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2B7E9@zcarhxm2.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.7 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 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: , Content-Type: multipart/mixed; boundary="===============0144896593==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 1.4 (+) X-Scan-Signature: c375f2012a4f820b0c0fd6fb14a28357 This is a multi-part message in MIME format. --===============0144896593== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C505FB.DA5438D0" This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C505FB.DA5438D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Martin, I haven't seen anybody suggest that any proposal mentioned would solve everybody's problems. VACM is granular and complex so it can be configured to meet a wide range of needs. But having a highly granular, complex access control system also doesn't solve everybody's problems if many of the targeted users cannot figure out how to migrate to it, and the implementations provided by vendors make it hard to configure to meet operators' needs. We need to help users who don't need all the complexity to use it in a simple manner, and to standardize some vendor-neutral defaults to simplify the migration from the SNMPv1 approach to the SNMPv3 approach. dbh _____ From: Martin Soukup [mailto:msoukup@nortel.com] Sent: Saturday, January 29, 2005 9:21 AM To: 'David T. Perkins'; David B Harrington Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] I definitely support the specification of a base set of capabilities and their use on the device to provide simplicity and commonality to the administration of simple devices, but it would be a real shame to think that this would solve everyone's problems. I thought the point of VACM is to provide a significant range of possible access control models depending on the granularity and complexity required? Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of David T. Perkins > Sent: January 28, 2005 5:25 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > HI, > > Interesting... > Lets say there are three "roles" or "capabilities", > which would correspond to VACM groups. Given > these, the standards track documents containing MIB modules > could indicate which objects and notifications should > be available for access type for each role. Given this > info in RFCs, it would be a mechanical process to > create entries in the view, and access tables. > That is, entries in table vacmViewTreeFamilyTable, > and table vacmAccessTable. > > Entries would be created in tables usmUserTable and > vacmSecurityToGroupTable when support for a new a user > is added. And entries would be created in tables > snmpCommunityTable and vacmSecurityToGroupTable > when support for a new community string is added. > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > 1) the number of groups in most VACM configurations would be > > > two or three. (For a lot of equipment, I believe > > > this to be true.) > > > > > > 2) the decision about which bits of management information > > should > > > be accessible to which of these groups does not need to be > > > under control of the security administrator. > > > > > > 3) equipment manufacturers will decide which groups get > > > which access, > > > and it would be acceptible if this could be changed only by > > a > > > firmware/software upgrade > > > > > > Did I get this much right? > > > If so, do you think a standard policy for these could be > > > formulated as an > > > addendum to RFC 3415 appendix A.1? > > > > > > Randy > > > > > I believe this is fairly accurate as a representation of what exists. > > And I think we coul dhelp the SNMP community migrate from communities > > to VACM much more than we have by defining incremental migration > > paths. > > > > We could do a service to operators by defining some standard access > > control templates for VACM groups, comparable to public (r-o most), > > private (r-w-most), and super-user (r-w-all). This would help admins > > accustomed to the traditional SNMPv1 communities to migrate to VACM > > access control. Then admins could expand the group assignments from > > that point if desired. I would consider adding a new security-admin > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > I think it would help admins if we discussed how applications can > > serve as SNMPv3 USM users, for all their users. Some applications > > already provide user-level access control. I don't like this as much > > as agent-access-control, but it is easier to configure USM with a few > > applications than with larger number of users, while ISMS tries to > > improve ease-of-use. On a side note, Spectrum used to provide > > something like nine levels of user access control, and now only > > provide three because customers never used the extra six levels. > > > > In SNMPv1, the immutable assignments were made to communities, but I'm > > not sure whether contexts, views or groups are the right answer in > > SNMPv3. Contexts are the immutable entities, so I think contexts might > > be the right answer. I think we could help the vendors provide default > > assignment of mib modules to public/private/root contexts by providing > > a list of IETF mib modules, and recommend which context they should be > > associated with. > > > > David Harrington > > dbharrington@comcast.net > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------=_NextPart_000_0000_01C505FB.DA5438D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [Isms] Evaluation status [and more]
Hi Martin,
 
I haven't seen anybody suggest that any = proposal mentioned=20 would solve everybody's problems. VACM is granular and complex so it can = be=20 configured to meet a wide range of needs. But having a highly granular, = complex=20 access control system also doesn't solve everybody's problems if many of = the=20 targeted users cannot figure out how to migrate to it, and the = implementations=20 provided by vendors make it hard to configure to meet operators'=20 needs.
 
We need to help=20 users who don't need all the complexity to use it in a simple manner, = and to=20 standardize some vendor-neutral defaults to simplify the migration from = the=20 SNMPv1 approach to the SNMPv3 approach.
 
dbh

From: Martin Soukup=20 [mailto:msoukup@nortel.com]
Sent: Saturday, January 29, = 2005 9:21=20 AM
To: 'David T. Perkins'; David B Harrington
Cc:=20 isms@ietf.org
Subject: RE: [Isms] Evaluation status [and=20 more]

I definitely support the specification of a base set = of=20 capabilities and their use on the device to provide simplicity and = commonality=20 to the administration of simple devices, but it would be a real shame = to think=20 that this would solve everyone's problems. I thought the point of VACM = is to=20 provide a significant range of possible access control models = depending on the=20 granularity and complexity required?

Martin.

> -----Original Message-----
>=20 From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.iet= f.org]=20 On
> Behalf Of David T. Perkins =
> Sent: January 28, 2005 5:25 PM
> To:=20 David B Harrington
> Cc: = isms@ietf.org=20
> Subject: RE: [Isms] Evaluation status [and = more]=20
>
> HI, =
>
> Interesting... =
> Lets say there are three "roles" or = "capabilities",=20
> which would correspond to VACM groups. = Given=20
> these, the standards track documents = containing MIB=20 modules
> could indicate which objects = and=20 notifications should
> be available for = access type=20 for each role. Given this
> info in RFCs, = it would=20 be a mechanical process to
> create = entries in the=20 view, and access tables.
> That is, = entries in=20 table vacmViewTreeFamilyTable,
> and = table=20 vacmAccessTable.
>
>=20 Entries would be created in tables usmUserTable and
> vacmSecurityToGroupTable when support for a new a = user=20
> is added. And entries would be created in = tables=20
> snmpCommunityTable and = vacmSecurityToGroupTable=20
> when support for a new community string is = added.=20
>
> =
> On Fri, 28 Jan 2005, David B Harrington wrote: =
> > > -----Original Message-----
>=20 > > From: isms-bounces@lists.ietf.org
> >=20 > [mailto:isms-bounces@lists.iet= f.org]=20 On Behalf Of Randy Presuhn
> > = >=20
> > > If I understand you correctly, = you're making a=20 couple of claims:
> > > =
> > >     1) the number of = groups in most=20 VACM configurations would be
> >=20 >         two or = three.  (For=20 a lot of equipment, I believe
> > > = this to=20 be true.)
> > >
>=20 > >     2) the decision about which bits of=20 management information
> > = should=20
> >=20 >         be accessible to = which of=20 these groups does not need to be
> >=20 >         under control of = the=20 security administrator.
> > = >=20
> > >     3) equipment = manufacturers will decide which groups get
> >=20 > which access,
> >=20 >         and it would be=20 acceptible if this could be changed only by
> >=20 a
> >=20 >         firmware/software = upgrade
> > >
>=20 > > Did I get this much right?
> = > > If=20 so, do you think a standard policy for these could be
> > > formulated as an
> > >=20 addendum to RFC 3415 appendix A.1?
> > = >
> > > Randy
>=20 > >
> > I believe this is fairly = accurate=20 as a representation of what exists.
> = > And I=20 think we coul dhelp the SNMP community migrate from communities =
> > to VACM much more than we have by = defining=20 incremental migration
> > = paths.=20
> >
> > We = could do a=20 service to operators by defining some standard access
> > control templates for VACM groups, comparable to = public (r-o=20 most),
> > private (r-w-most), and = super-user=20 (r-w-all).  This would help admins
> = >=20 accustomed to the traditional SNMPv1 communities to migrate to = VACM=20
> > access control. Then admins could expand = the group=20 assignments from
> > that point if = desired. I=20 would consider adding a new security-admin
> >=20 (r-w security mibs, such as VACM and USM and RADIUS) as well. =
> >
> > I think it = would help=20 admins if we discussed how applications can
> >=20 serve as SNMPv3 USM users, for all their users. Some = applications=20
> > already provide user-level access = control. I don't=20 like this as much
> > as = agent-access-control,=20 but it is easier to configure USM with a few
> >=20 applications than with larger number of users, while ISMS tries = to=20
> > improve ease-of-use. On a side note, = Spectrum used=20 to provide
> > something like nine = levels of=20 user access control, and now only
> > = provide=20 three because customers never used the extra six levels. =
> >
> > In SNMPv1, the = immutable=20 assignments were made to communities, but I'm
>=20 > not sure whether contexts, views or groups are the right answer = in=20
> > SNMPv3. Contexts are the immutable = entities, so I=20 think contexts might
> > be the right = answer. I=20 think we could help the vendors provide default
>=20 > assignment of mib modules to public/private/root contexts by=20 providing
> > a list of IETF mib = modules, and=20 recommend which context they should be
> = >=20 associated with.
> >
> > David Harrington
> = >=20 dbharrington@comcast.net
> =
> Regards,
> /david t. = perkins=20
>
> =
> _______________________________________________ =
> Isms mailing list
>=20 Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms =

------=_NextPart_000_0000_01C505FB.DA5438D0-- --===============0144896593== 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 --===============0144896593==-- From isms-bounces@ietf.org Mon Jan 31 06:56:30 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 GAA18375; Mon, 31 Jan 2005 06:56:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvaSO-0000vc-0k; Mon, 31 Jan 2005 07:15:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cva26-0002Ky-Ot; Mon, 31 Jan 2005 06: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 1CvZv6-0001fF-Ar for isms@megatron.ietf.org; Mon, 31 Jan 2005 06:40: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 GAA17504 for ; Mon, 31 Jan 2005 06:40:37 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvaCz-0000fP-Gk for isms@ietf.org; Mon, 31 Jan 2005 06:59:12 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0VBeXWs026350 for ; Mon, 31 Jan 2005 05:40:34 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 12:40:32 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550649819E@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, "'Martin Soukup'" , "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 12:40:22 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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: d16ce744298aacf98517bc7c108bd198 I am really a bit appalled by the continued suggestions/discussions that VACM is too complex for those who want to keep things simple. If you look at appendix of RFC3415, there are suggested configs that are (in my view) VERY SIMPLE and VERY STRAIGHTFORWARD for those who do not need a fine grained access control. Is that just me? And it is also pretty straight forward to define a few users that have access with the simple access control setup. I agree that it is quite complicated if anyone wants to use all the capabilities of USM and VACM. I will also agree that we could specigfy some more default configs that may help operators even more than the initial configs in the current RFCs. But I do not buy the idea that doing a simple access control is all that difficult. Bert -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of David B Harrington Sent: Saturday, January 29, 2005 18:13 To: 'Martin Soukup'; 'David T. Perkins' Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] Hi Martin, I haven't seen anybody suggest that any proposal mentioned would solve everybody's problems. VACM is granular and complex so it can be configured to meet a wide range of needs. But having a highly granular, complex access control system also doesn't solve everybody's problems if many of the targeted users cannot figure out how to migrate to it, and the implementations provided by vendors make it hard to configure to meet operators' needs. We need to help users who don't need all the complexity to use it in a simple manner, and to standardize some vendor-neutral defaults to simplify the migration from the SNMPv1 approach to the SNMPv3 approach. dbh From: Martin Soukup [mailto:msoukup@nortel.com] Sent: Saturday, January 29, 2005 9:21 AM To: 'David T. Perkins'; David B Harrington Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] I definitely support the specification of a base set of capabilities and their use on the device to provide simplicity and commonality to the administration of simple devices, but it would be a real shame to think that this would solve everyone's problems. I thought the point of VACM is to provide a significant range of possible access control models depending on the granularity and complexity required? Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of David T. Perkins > Sent: January 28, 2005 5:25 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > HI, > > Interesting... > Lets say there are three "roles" or "capabilities", > which would correspond to VACM groups. Given > these, the standards track documents containing MIB modules > could indicate which objects and notifications should > be available for access type for each role. Given this > info in RFCs, it would be a mechanical process to > create entries in the view, and access tables. > That is, entries in table vacmViewTreeFamilyTable, > and table vacmAccessTable. > > Entries would be created in tables usmUserTable and > vacmSecurityToGroupTable when support for a new a user > is added. And entries would be created in tables > snmpCommunityTable and vacmSecurityToGroupTable > when support for a new community string is added. > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > 1) the number of groups in most VACM configurations would be > > > two or three. (For a lot of equipment, I believe > > > this to be true.) > > > > > > 2) the decision about which bits of management information > > should > > > be accessible to which of these groups does not need to be > > > under control of the security administrator. > > > > > > 3) equipment manufacturers will decide which groups get > > > which access, > > > and it would be acceptible if this could be changed only by > > a > > > firmware/software upgrade > > > > > > Did I get this much right? > > > If so, do you think a standard policy for these could be > > > formulated as an > > > addendum to RFC 3415 appendix A.1? > > > > > > Randy > > > > > I believe this is fairly accurate as a representation of what exists. > > And I think we coul dhelp the SNMP community migrate from communities > > to VACM much more than we have by defining incremental migration > > paths. > > > > We could do a service to operators by defining some standard access > > control templates for VACM groups, comparable to public (r-o most), > > private (r-w-most), and super-user (r-w-all). This would help admins > > accustomed to the traditional SNMPv1 communities to migrate to VACM > > access control. Then admins could expand the group assignments from > > that point if desired. I would consider adding a new security-admin > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > I think it would help admins if we discussed how applications can > > serve as SNMPv3 USM users, for all their users. Some applications > > already provide user-level access control. I don't like this as much > > as agent-access-control, but it is easier to configure USM with a few > > applications than with larger number of users, while ISMS tries to > > improve ease-of-use. On a side note, Spectrum used to provide > > something like nine levels of user access control, and now only > > provide three because customers never used the extra six levels. > > > > In SNMPv1, the immutable assignments were made to communities, but I'm > > not sure whether contexts, views or groups are the right answer in > > SNMPv3. Contexts are the immutable entities, so I think contexts might > > be the right answer. I think we could help the vendors provide default > > assignment of mib modules to public/private/root contexts by providing > > a list of IETF mib modules, and recommend which context they should be > > associated with. > > > > David Harrington > > dbharrington@comcast.net > > 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 Jan 31 08:21: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 IAA28281; Mon, 31 Jan 2005 08:21:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbmh-000395-IA; Mon, 31 Jan 2005 08:40:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbPq-0008A2-KK; Mon, 31 Jan 2005 08:16:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbKc-000742-5I for isms@megatron.ietf.org; Mon, 31 Jan 2005 08:11: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 IAA25734 for ; Mon, 31 Jan 2005 08:11:05 -0500 (EST) Message-Id: <200501311311.IAA25734@ietf.org> Received: from rwcrmhc12.comcast.net ([216.148.227.85]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvbcY-0002iz-SQ for isms@ietf.org; Mon, 31 Jan 2005 08:29:39 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (rwcrmhc12) with SMTP id <20050131131033014003evqse>; Mon, 31 Jan 2005 13:10:33 +0000 From: "David B Harrington" To: "'Wijnen, Bert \(Bert\)'" , "'Martin Soukup'" , "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 08:10:29 -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: AcUHia3vQJtlcCzSSwiU9OQXdOALSgABT7vg In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B1550649819E@nl0006exch001u.nl.lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070 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: bfe538a859d88717fa3c8a6377d62f90 Content-Transfer-Encoding: 7bit Hi bert, The problem isn't that VACM is too complex; it's that there is complexity and an associated learning curve, and we aren't helping peolle scale the learning curve. For somebody that already understands VACM, it may seem simple, but for people who have a different mind-set about how to do access control, changing to the mind-set required by VACM can be a deterrent to adoption. It is not a simple learning curve. 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? If I am used to thinking in terms of public, private and superuser communities to provide access control, and I suddenly need to configure SNMPv3 in my devices, show me where in Appendix A you tell me how to create public, private, and superuser "communities" in VACM. I see descriptions of a default context "" and an "initial" group, and "restricted" views, etc. But I'm used to getting my devices with preconfigured communities and MIB modules already assigned into different communities and so on. How do I transition from the way I typically think of the problem to this new way (and of course, I'm also at the same time trying to learn about MD5 authentication, and DES encryption, and trying to solve the problem of updating the keys across the whole system simultaneouly, and other aspects of SNMPv3 as well). Now a vendor needs to determine how to preconfigure its assignment of mib modules to ... What? To views? To contexts? To groups? We cannot even agree amongst ourselves whether vendors need to pre-assign the mib modules to contexts or views or groups in order to parallel the community approach, but somehow we expect that the vendors will just somehow get it right? And if different vendors do it different ways, then the operators have to sort out the mess, but we should be appalled that people suggest VACM is complex? We should help make the trasnition easier by defining VACM defaults that are consistent with the way users view the world already, and then they can extend it in more advanced ways as they're ready. Users do not currently think in terms of "", "initial", "initial-semi-secure-configuration", "minimum-secure", "semi-secure" and so on; they think in terms of public, private and superuser communities. Defining defaults that correspond to the traditional concepts could help overcome one of the thresholds that makes adoption of SNMPv3 harder. David Harrington dbharrington@comcast.net > -----Original Message----- > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > Sent: Monday, January 31, 2005 6:40 AM > To: ietfdbh@comcast.net; 'Martin Soukup'; 'David T. Perkins' > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > > I am really a bit appalled by the continued suggestions/discussions > that VACM is too complex for those who want to keep things simple. > > If you look at appendix of RFC3415, there are suggested configs that > are (in my view) VERY SIMPLE and VERY STRAIGHTFORWARD for those who > do not need a fine grained access control. > > Is that just me? > > And it is also pretty straight forward to define a few users that > have access with the simple access control setup. > > I agree that it is quite complicated if anyone wants to use all the > capabilities of USM and VACM. > > I will also agree that we could specigfy some more default configs > that may help operators even more than the initial configs > in the current RFCs. But I do not buy the idea that doing > a simple access control is all that difficult. > > Bert > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org]On Behalf Of David B Harrington > Sent: Saturday, January 29, 2005 18:13 > To: 'Martin Soukup'; 'David T. Perkins' > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > > Hi Martin, > > I haven't seen anybody suggest that any proposal mentioned > would solve everybody's problems. VACM is granular and > complex so it can be configured to meet a wide range of > needs. But having a highly granular, complex access control > system also doesn't solve everybody's problems if many of the > targeted users cannot figure out how to migrate to it, and > the implementations provided by vendors make it hard to > configure to meet operators' needs. > > We need to help users who don't need all the complexity to > use it in a simple manner, and to standardize some > vendor-neutral defaults to simplify the migration from the > SNMPv1 approach to the SNMPv3 approach. > > dbh > > > > > From: Martin Soukup [mailto:msoukup@nortel.com] > Sent: Saturday, January 29, 2005 9:21 AM > To: 'David T. Perkins'; David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > > I definitely support the specification of a base set of > capabilities and their use on the device to provide > simplicity and commonality to the administration of simple > devices, but it would be a real shame to think that this > would solve everyone's problems. I thought the point of VACM > is to provide a significant range of possible access control > models depending on the granularity and complexity required? > Martin. > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On > > Behalf Of David T. Perkins > > Sent: January 28, 2005 5:25 PM > > To: David B Harrington > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > HI, > > > > Interesting... > > Lets say there are three "roles" or "capabilities", > > which would correspond to VACM groups. Given > > these, the standards track documents containing MIB modules > > could indicate which objects and notifications should > > be available for access type for each role. Given this > > info in RFCs, it would be a mechanical process to > > create entries in the view, and access tables. > > That is, entries in table vacmViewTreeFamilyTable, > > and table vacmAccessTable. > > > > Entries would be created in tables usmUserTable and > > vacmSecurityToGroupTable when support for a new a user > > is added. And entries would be created in tables > > snmpCommunityTable and vacmSecurityToGroupTable > > when support for a new community string is added. > > > > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > > > If I understand you correctly, you're making a couple > of claims: > > > > > > > > 1) the number of groups in most VACM configurations > would be > > > > two or three. (For a lot of equipment, I believe > > > > this to be true.) > > > > > > > > 2) the decision about which bits of management information > > > should > > > > be accessible to which of these groups does not > need to be > > > > under control of the security administrator. > > > > > > > > 3) equipment manufacturers will decide which groups get > > > > which access, > > > > and it would be acceptible if this could be > changed only by > > > a > > > > firmware/software upgrade > > > > > > > > Did I get this much right? > > > > If so, do you think a standard policy for these could be > > > > formulated as an > > > > addendum to RFC 3415 appendix A.1? > > > > > > > > Randy > > > > > > > I believe this is fairly accurate as a representation of > what exists. > > > And I think we coul dhelp the SNMP community migrate from > communities > > > to VACM much more than we have by defining incremental migration > > > paths. > > > > > > We could do a service to operators by defining some > standard access > > > control templates for VACM groups, comparable to public > (r-o most), > > > private (r-w-most), and super-user (r-w-all). This would > help admins > > > accustomed to the traditional SNMPv1 communities to > migrate to VACM > > > access control. Then admins could expand the group > assignments from > > > that point if desired. I would consider adding a new > security-admin > > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > > > I think it would help admins if we discussed how applications can > > > serve as SNMPv3 USM users, for all their users. Some applications > > > already provide user-level access control. I don't like > this as much > > > as agent-access-control, but it is easier to configure > USM with a few > > > applications than with larger number of users, while ISMS > tries to > > > improve ease-of-use. On a side note, Spectrum used to provide > > > something like nine levels of user access control, and now only > > > provide three because customers never used the extra six levels. > > > > > > In SNMPv1, the immutable assignments were made to > communities, but I'm > > > not sure whether contexts, views or groups are the right > answer in > > > SNMPv3. Contexts are the immutable entities, so I think > contexts might > > > be the right answer. I think we could help the vendors > provide default > > > assignment of mib modules to public/private/root contexts > by providing > > > a list of IETF mib modules, and recommend which context > they should be > > > associated with. > > > > > > David Harrington > > > dbharrington@comcast.net > > > > 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 Jan 31 08:23: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 IAA28534; Mon, 31 Jan 2005 08:23:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbon-0003Bb-RU; Mon, 31 Jan 2005 08: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 1CvbSk-0000Sz-I6; Mon, 31 Jan 2005 08:19:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbM2-0007IU-PR for isms@megatron.ietf.org; Mon, 31 Jan 2005 08:12:34 -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 IAA25950 for ; Mon, 31 Jan 2005 08:12:32 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvbdy-0002oJ-6z for isms@ietf.org; Mon, 31 Jan 2005 08:31:06 -0500 Received: from pc6 (1Cust150.tnt9.lnd4.gbr.da.uu.net [62.188.138.150]) by blaster.systems.pipex.net (Postfix) with SMTP id 22B83E000271; Mon, 31 Jan 2005 13:11:56 +0000 (GMT) Message-ID: <037501c5078d$d1e5ab00$0601a8c0@pc6> From: "Tom Petch" To: , "'David T. Perkins'" References: <200501290001.TAA05200@ietf.org> Subject: Re: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 13:08:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 Content-Transfer-Encoding: 7bit Thank you to you all for fleshing out my half-formed ideas:-) Yes I am suggesting public/private/root and that manufacturers would supply a default assignment; I hadn't thought of it being built into firmware but I expect that would satisfy most needs . I shy away from VACM because I don't understand it; I know of the tables mentioned but unless and until I actually configure them, I doubt if I will remember which is what and so have to go away and look up their role. If David (Perkins) says this is the way to do it, I take that on trust. And I suspect that VACM is a lot more complexity to implement, in the general case, which may be a factor in the lack of implementations of SNMPv3. So part of me wants to dispense with VACM or make it so simple (eg with three groups and nothing more, MAX-ACCESS of read-only?) that the cost would be negligible. Despite this, I suspect that VACM groups are the better fit. I am hoping contexts will solve the multi-function box problem, of a chassis with multiple blades, routers, switches, hubs etc each wanting its own distinct 'MIB-II'. So loading the concept of context with security could compromise this (again, a half formed idea). And yes, I do see it as an addendum to RFC 3415, perhap RFC 3414. I think we need a(nother) starter subset. My last half-formed idea for the moment (which I realise has a lot of baggage around it). SNMPv1 took a time to catch on. For me, it was a capable set of building bricks that needed a lot of effort to be usable and it took off when a manufacturer produced something more like a ready to use structure (HP OpenView). I see in SNMPv3 a capable set of building bricks and have been waiting for a manufacturer to produce something more like a ready to use structure (eg a starter set of VACM and USM tables) - I am still waiting. Perhaps a move from the standards side - ie us - to something simpler (while not losing sight of our role to integrate security with existing systems) might get that response from a manufacturer. Tom Petch ----- Original Message ----- From: "David B Harrington" To: "'David T. Perkins'" Cc: Sent: Saturday, January 29, 2005 1:00 AM Subject: RE: [Isms] Evaluation status [and more] > Yes, and if you can parse the security considerabtions boilerplate to > find the objects in each category, that info may already be broken out > to a degree. Not well, but to a degree. > > dbh > > > -----Original Message----- > > From: David T. Perkins [mailto:dperkins@dsperkins.com] > > Sent: Friday, January 28, 2005 5:25 PM > > To: David B Harrington > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > HI, > > > > Interesting... > > Lets say there are three "roles" or "capabilities", > > which would correspond to VACM groups. Given > > these, the standards track documents containing MIB modules > > could indicate which objects and notifications should > > be available for access type for each role. Given this > > info in RFCs, it would be a mechanical process to > > create entries in the view, and access tables. > > That is, entries in table vacmViewTreeFamilyTable, > > and table vacmAccessTable. > > > > Entries would be created in tables usmUserTable and > > vacmSecurityToGroupTable when support for a new a user > > is added. And entries would be created in tables > > snmpCommunityTable and vacmSecurityToGroupTable > > when support for a new community string is added. > > > > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > > -----Original Message----- > > > > From: isms-bounces@lists.ietf.org > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > > > 1) the number of groups in most VACM configurations would be > > > > two or three. (For a lot of equipment, I believe > > > > this to be true.) > > > > > > > > 2) the decision about which bits of management information > > > should > > > > be accessible to which of these groups does not need to > be > > > > under control of the security administrator. > > > > > > > > 3) equipment manufacturers will decide which groups get > > > > which access, > > > > and it would be acceptible if this could be > > changed only by > > > a > > > > firmware/software upgrade > > > > > > > > Did I get this much right? > > > > If so, do you think a standard policy for these could be > > > > formulated as an > > > > addendum to RFC 3415 appendix A.1? > > > > > > > > Randy > > > > > > > I believe this is fairly accurate as a representation of > > what exists. > > > And I think we coul dhelp the SNMP community migrate from > > communities > > > to VACM much more than we have by defining incremental migration > > > paths. > > > > > > We could do a service to operators by defining some standard > access > > > control templates for VACM groups, comparable to public (r-o > most), > > > private (r-w-most), and super-user (r-w-all). This would > > help admins > > > accustomed to the traditional SNMPv1 communities to migrate to > VACM > > > access control. Then admins could expand the group assignments > from > > > that point if desired. I would consider adding a new > security-admin > > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > > > I think it would help admins if we discussed how applications can > > > serve as SNMPv3 USM users, for all their users. Some applications > > > already provide user-level access control. I don't like this as > much > > > as agent-access-control, but it is easier to configure USM > > with a few > > > applications than with larger number of users, while ISMS tries to > > > improve ease-of-use. On a side note, Spectrum used to provide > > > something like nine levels of user access control, and now only > > > provide three because customers never used the extra six levels. > > > > > > In SNMPv1, the immutable assignments were made to > > communities, but I'm > > > not sure whether contexts, views or groups are the right answer in > > > SNMPv3. Contexts are the immutable entities, so I think > > contexts might > > > be the right answer. I think we could help the vendors > > provide default > > > assignment of mib modules to public/private/root contexts > > by providing > > > a list of IETF mib modules, and recommend which context > > they should be > > > associated with. > > > > > > David Harrington > > > dbharrington@comcast.net > > > > 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 Jan 31 08:46: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 IAA01137; Mon, 31 Jan 2005 08:46:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvcAo-0003jn-5w; Mon, 31 Jan 2005 09:05:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvbrq-0004Od-TM; Mon, 31 Jan 2005 08:45:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvbpD-0003ua-F8 for isms@megatron.ietf.org; Mon, 31 Jan 2005 08:42: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 IAA00558 for ; Mon, 31 Jan 2005 08:42:42 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvc7A-0003bE-OH for isms@ietf.org; Mon, 31 Jan 2005 09:01:17 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j0VDg9Jf017990 for ; Mon, 31 Jan 2005 07:42:10 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id ; Mon, 31 Jan 2005 14:42:08 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550649824A@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: ietfdbh@comcast.net, "'Martin Soukup'" , "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 14:42:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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: f1405b5eaa25d745f8c52e3273d3af78 Inline > -----Original Message----- > From: David B Harrington [mailto:ietfdbh@comcast.net] > Sent: Monday, January 31, 2005 14:10 > To: 'Wijnen, Bert (Bert)'; 'Martin Soukup'; 'David T. Perkins' > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > > Hi bert, > > The problem isn't that VACM is too complex; it's that there is > complexity and an associated learning curve, and we aren't helping > peolle scale the learning curve. For somebody that already understands > VACM, it may seem simple, but for people who have a different mind-set > about how to do access control, changing to the mind-set required by > VACM can be a deterrent to adoption. It is not a simple learning > curve. > > 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. Darn simple, use the default included in appendix A and you are basically all set! Only if you want to do more than that, that is where it becomes a bit more complex! > 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? > YES! I am sure such is not more difficult than for me understainding how to add certificates for SSL and SFTP to my system. > If I am used to thinking in terms of public, private and superuser > communities to provide access control, and I suddenly need to > configure SNMPv3 in my devices, show me where in Appendix A you tell > me how to create public, private, and superuser "communities" in VACM. > I see descriptions of a default context "" and an "initial" group, and > "restricted" views, etc. But I'm used to getting my devices with > preconfigured communities and MIB modules already assigned into > different communities and so on. So you are telling me that the vendors give you a ahrd time! > How do I transition from the way I > typically think of the problem to this new way (and of course, I'm > also at the same time trying to learn about MD5 authentication, and > DES encryption, and trying to solve the problem of updating the keys > across the whole system simultaneouly, and other aspects of SNMPv3 as > well). > The KEYS updating and MD5 and DES issue has nothing to do with VACM. I know that USM is not easy. > Now a vendor needs to determine how to preconfigure its assignment of > mib modules to ... What? To views? To contexts? To groups? We cannot > even agree amongst ourselves whether vendors need to pre-assign the > mib modules to contexts or views or groups in order to parallel the > community approach, but somehow we expect that the vendors will just > somehow get it right? And if different vendors do it different ways, > then the operators have to sort out the mess, but we should be > appalled that people suggest VACM is complex? > And you think that that is gonna change withanything new that we develop in this WG ?? Vendors will keep doing things their own way. > We should help make the trasnition easier by defining VACM defaults > that are consistent with the way users view the world already, and > then they can extend it in more advanced ways as they're ready. Users > do not currently think in terms of "", "initial", > "initial-semi-secure-configuration", "minimum-secure", "semi-secure" > and so on; they think in terms of public, private and superuser > communities. > > Defining defaults that correspond to the traditional concepts could > help overcome one of the thresholds that makes adoption of SNMPv3 > harder. > So go ahead and write an I-D that defines that! Bert > David Harrington > dbharrington@comcast.net > > > > -----Original Message----- > > From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] > > Sent: Monday, January 31, 2005 6:40 AM > > To: ietfdbh@comcast.net; 'Martin Soukup'; 'David T. Perkins' > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > > > I am really a bit appalled by the continued suggestions/discussions > > that VACM is too complex for those who want to keep things simple. > > > > If you look at appendix of RFC3415, there are suggested configs that > > > are (in my view) VERY SIMPLE and VERY STRAIGHTFORWARD for those who > > do not need a fine grained access control. > > > > Is that just me? > > > > And it is also pretty straight forward to define a few users that > > have access with the simple access control setup. > > > > I agree that it is quite complicated if anyone wants to use all the > > capabilities of USM and VACM. > > > > I will also agree that we could specigfy some more default configs > > that may help operators even more than the initial configs > > in the current RFCs. But I do not buy the idea that doing > > a simple access control is all that difficult. > > > > Bert > > -----Original Message----- > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org]On Behalf Of David B Harrington > > Sent: Saturday, January 29, 2005 18:13 > > To: 'Martin Soukup'; 'David T. Perkins' > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > > > Hi Martin, > > > > I haven't seen anybody suggest that any proposal mentioned > > would solve everybody's problems. VACM is granular and > > complex so it can be configured to meet a wide range of > > needs. But having a highly granular, complex access control > > system also doesn't solve everybody's problems if many of the > > targeted users cannot figure out how to migrate to it, and > > the implementations provided by vendors make it hard to > > configure to meet operators' needs. > > > > We need to help users who don't need all the complexity to > > use it in a simple manner, and to standardize some > > vendor-neutral defaults to simplify the migration from the > > SNMPv1 approach to the SNMPv3 approach. > > > > dbh > > > > > > > > > > From: Martin Soukup [mailto:msoukup@nortel.com] > > Sent: Saturday, January 29, 2005 9:21 AM > > To: 'David T. Perkins'; David B Harrington > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > > > I definitely support the specification of a base set of > > capabilities and their use on the device to provide > > simplicity and commonality to the administration of simple > > devices, but it would be a real shame to think that this > > would solve everyone's problems. I thought the point of VACM > > is to provide a significant range of possible access control > > models depending on the granularity and complexity required? > > Martin. > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > [mailto:isms-bounces@lists.ietf.org] On > > > Behalf Of David T. Perkins > > > Sent: January 28, 2005 5:25 PM > > > To: David B Harrington > > > Cc: isms@ietf.org > > > Subject: RE: [Isms] Evaluation status [and more] > > > > > > HI, > > > > > > Interesting... > > > Lets say there are three "roles" or "capabilities", > > > which would correspond to VACM groups. Given > > > these, the standards track documents containing MIB modules > > > could indicate which objects and notifications should > > > be available for access type for each role. Given this > > > info in RFCs, it would be a mechanical process to > > > create entries in the view, and access tables. > > > That is, entries in table vacmViewTreeFamilyTable, > > > and table vacmAccessTable. > > > > > > Entries would be created in tables usmUserTable and > > > vacmSecurityToGroupTable when support for a new a user > > > is added. And entries would be created in tables > > > snmpCommunityTable and vacmSecurityToGroupTable > > > when support for a new community string is added. > > > > > > > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > > > -----Original Message----- > > > > > From: isms-bounces@lists.ietf.org > > > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy > Presuhn > > > > > > > > > > If I understand you correctly, you're making a couple > > of claims: > > > > > > > > > > 1) the number of groups in most VACM configurations > > would be > > > > > two or three. (For a lot of equipment, I believe > > > > > this to be true.) > > > > > > > > > > 2) the decision about which bits of management information > > > > > should > > > > > be accessible to which of these groups does not > > need to be > > > > > under control of the security administrator. > > > > > > > > > > 3) equipment manufacturers will decide which groups get > > > > > which access, > > > > > and it would be acceptible if this could be > > changed only by > > > > a > > > > > firmware/software upgrade > > > > > > > > > > Did I get this much right? > > > > > If so, do you think a standard policy for these could be > > > > > formulated as an > > > > > addendum to RFC 3415 appendix A.1? > > > > > > > > > > Randy > > > > > > > > > I believe this is fairly accurate as a representation of > > what exists. > > > > And I think we coul dhelp the SNMP community migrate from > > communities > > > > to VACM much more than we have by defining incremental migration > > > > > paths. > > > > > > > > We could do a service to operators by defining some > > standard access > > > > control templates for VACM groups, comparable to public > > (r-o most), > > > > private (r-w-most), and super-user (r-w-all). This would > > help admins > > > > accustomed to the traditional SNMPv1 communities to > > migrate to VACM > > > > access control. Then admins could expand the group > > assignments from > > > > that point if desired. I would consider adding a new > > security-admin > > > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > > > > > I think it would help admins if we discussed how applications > can > > > > serve as SNMPv3 USM users, for all their users. Some > applications > > > > already provide user-level access control. I don't like > > this as much > > > > as agent-access-control, but it is easier to configure > > USM with a few > > > > applications than with larger number of users, while ISMS > > tries to > > > > improve ease-of-use. On a side note, Spectrum used to provide > > > > something like nine levels of user access control, and now only > > > > provide three because customers never used the extra six levels. > > > > > > > > > In SNMPv1, the immutable assignments were made to > > communities, but I'm > > > > not sure whether contexts, views or groups are the right > > answer in > > > > SNMPv3. Contexts are the immutable entities, so I think > > contexts might > > > > be the right answer. I think we could help the vendors > > provide default > > > > assignment of mib modules to public/private/root contexts > > by providing > > > > a list of IETF mib modules, and recommend which context > > they should be > > > > associated with. > > > > > > > > David Harrington > > > > dbharrington@comcast.net > > > > > > 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 Jan 31 10:59:30 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 KAA15624; Mon, 31 Jan 2005 10:59:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveFG-0006nS-6z; Mon, 31 Jan 2005 11:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdr1-00034d-QI; Mon, 31 Jan 2005 10:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvdok-0002bh-Pm for isms@megatron.ietf.org; Mon, 31 Jan 2005 10:50: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 KAA14596 for ; Mon, 31 Jan 2005 10:50:20 -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 1Cve6d-0006cx-8d for isms@ietf.org; Mon, 31 Jan 2005 11:08:57 -0500 Received: from NHROCAVG2.ets.enterasys.com ([134.141.79.124]) by gtfw2.enterasys.com (0.25.1/8.12.6) with ESMTP id j0VFoDZC014413 for ; Mon, 31 Jan 2005 10:50:14 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 31 Jan 2005 10:50:13 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 31 Jan 2005 10:50:13 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jan 2005 10:50:13 -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] RE: Network management authorization Date: Mon, 31 Jan 2005 10:50:13 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190DC@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] RE: Network management authorization Thread-Index: AcUHFI+MM9FFWG1+SjCTTIqtbVzNxwAlpYlw From: "Nelson, David" To: X-OriginalArrivalTime: 31 Jan 2005 15:50:13.0782 (UTC) FILETIME=[8D63BB60:01C507AC] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:79.5348 M:98.0659 P:95.9108 R:95.9108 S:79.5749 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Martin Soukup writes... > Doesn't this just make sense? The big questions to me are:=20 > 1. Can we agree on RADIUS EAP and can the extensions needed=20 > be standardized=20 > 2. How can generation, caching and timeout of keys best be=20 > designed to provide PFS and minimize communication with a central=20 > AAA > (Host-specific access control is also interesting but out of=20 > scope) I understand that authorization considerations are currently out of scope. My opinion is that constraint was agreed upon because of the desire to have a narrow focus and short schedule, to see if consensus could really be achieved around authentication and key management. There have been suggestions that we could have a BOF on authorization issues. I suspect that the better thing to do is to make rapid progress on the existing charter issues, and then revise the charter to add authorization. IMHO, it would be a major mistake to standardize AAA-based authentication and key management and not standardize AAA-based authorization (access control). The level of recent list discussion indicates to me that there is a substantial community of interest. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 31 11:24: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 LAA19124; Mon, 31 Jan 2005 11:24:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvedN-0007aF-Ni; Mon, 31 Jan 2005 11:42:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cve2J-0005yS-Np; Mon, 31 Jan 2005 11:04:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cve1M-0005nM-3c for isms@megatron.ietf.org; Mon, 31 Jan 2005 11:03:25 -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 LAA16206 for ; Mon, 31 Jan 2005 11:03:21 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CveJJ-0006uC-IY for isms@ietf.org; Mon, 31 Jan 2005 11:21:58 -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 j0VG2ma19588; Mon, 31 Jan 2005 11:02:49 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Jan 2005 11:02:49 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B81C@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Nelson, David'" , isms@ietf.org Subject: RE: [Isms] RE: Network management authorization Date: Mon, 31 Jan 2005 11:02:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============1423449279==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 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. --===============1423449279== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C507AE.3ACCB173" 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_01C507AE.3ACCB173 Content-Type: text/plain I second that. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Nelson, David > Sent: January 31, 2005 10:50 AM > To: isms@ietf.org > Subject: RE: [Isms] RE: Network management authorization > > Martin Soukup writes... > > > Doesn't this just make sense? The big questions to me are: > > 1. Can we agree on RADIUS EAP and can the extensions needed > > be standardized > > 2. How can generation, caching and timeout of keys best be > > designed to provide PFS and minimize communication with a central > > AAA > > (Host-specific access control is also interesting but out of > > scope) > > I understand that authorization considerations are currently out of > scope. My opinion is that constraint was agreed upon because of the > desire to have a narrow focus and short schedule, to see if consensus > could really be achieved around authentication and key management. > > There have been suggestions that we could have a BOF on authorization > issues. I suspect that the better thing to do is to make rapid progress > on the existing charter issues, and then revise the charter to add > authorization. IMHO, it would be a major mistake to standardize > AAA-based authentication and key management and not standardize > AAA-based authorization (access control). The level of recent list > discussion indicates to me that there is a substantial community of > interest. > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C507AE.3ACCB173 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management authorization

I second that.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Nelson, David
> Sent: January 31, 2005 10:50 AM
> To: isms@ietf.org
> Subject: RE: [Isms] RE: Network management = authorization
>
> Martin Soukup writes...
>
> > Doesn't this just make sense? The big = questions to me are:
> > 1. Can we agree on RADIUS EAP and can the = extensions needed
> > be standardized
> > 2. How can generation, caching and timeout = of keys best be
> > designed to provide PFS and minimize = communication with a central
> > AAA
> > (Host-specific access control is also = interesting but out of
> > scope)
>
> I understand that authorization considerations = are currently out of
> scope.  My opinion is that constraint was = agreed upon because of the
> desire to have a narrow focus and short = schedule, to see if consensus
> could really be achieved around authentication = and key management.
>
> There have been suggestions that we could have = a BOF on authorization
> issues.  I suspect that the better thing = to do is to make rapid progress
> on the existing charter issues, and then revise = the charter to add
> authorization.  IMHO, it would be a major = mistake to standardize
> AAA-based authentication and key management and = not standardize
> AAA-based authorization (access control).  = The level of recent list
> discussion indicates to me that there is a = substantial community of
> interest.
>
>
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C507AE.3ACCB173-- --===============1423449279== 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 --===============1423449279==-- From isms-bounces@ietf.org Mon Jan 31 12:45: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 MAA28390; Mon, 31 Jan 2005 12:45:54 -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 1Cvftj-0001ME-Az; Mon, 31 Jan 2005 13:04:32 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Cvfbf-0006PI-CR; Mon, 31 Jan 2005 12:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfUA-0001r4-Ca; Mon, 31 Jan 2005 12:37:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvMpc-0003TV-Hp for isms@megatron.ietf.org; Sun, 30 Jan 2005 16:42: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 QAA06387 for ; Sun, 30 Jan 2005 16:42:04 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvN7O-00024Z-PW for isms@ietf.org; Sun, 30 Jan 2005 17:00:32 -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 j0ULfWn17260; Sun, 30 Jan 2005 16:41:32 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Jan 2005 16:41:33 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B7FF@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Nelson, David'" , isms@ietf.org Subject: RE: [Isms] RE: Network management authorization Date: Sun, 30 Jan 2005 16:41:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 X-Mailman-Approved-At: Mon, 31 Jan 2005 12:37:11 -0500 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============0584947253==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f 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. --===============0584947253== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50714.74E4CAFC" 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_01C50714.74E4CAFC Content-Type: text/plain Also note that EAP is used in 802.1x. The way that RADIUS is designed suggesting extensions to its methods doesn't break it - it's made to be customizable and extensible. The introduction of EAP and thus numerous originally unintended authentication mechanisms are already supported, why not another? Personally, I would argue that existing EAP mechanisms provide for the exchange of key information and thus no significant extensions are required. The only thing that doesn't fit within the existing protocols AFAICT is the ability of a trusted 3rd party to request key information on behalf of a client - this sounds more like the Liberty Federation standards, but it is definitely useful in RADIUS itself. Is it possible to define the EUSM concepts of layering key exchange within existing protocols out-of-band and then supporting USM as-is? Is it possible to agree on the approach and then debate which protocols can be reused for it? And then the details? It seems to me, to make sense to talk about the main architectural goals: 1. Use SNMPv3 and USM as-is (meaning provide key exchange through a different mechanism, without modifying SNMPv3 - this should also work for VACM but is outside of scope for this discussion) 2. The authenticator should provide key generation capabilities for the authenticatee in the case that a central AAA is not available (system should work a) without a central AAA b) with the central AAA unavailable) - otherwise the authenticator must request key information for a user upon session initiation 3. The generation of keys should be timed to provide for session time-outs and things like this Doesn't this just make sense? The big questions to me are: 1. Can we agree on RADIUS EAP and can the extensions needed be standardized 2. How can generation, caching and timeout of keys best be designed to provide PFS and minimize communication with a central AAA (Host-specific access control is also interesting but out of scope) Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Nelson, David > Sent: January 11, 2005 3:38 PM > To: isms@ietf.org > Subject: RE: [Isms] RE: Network management authorization > > > > (Of course, the fact > > that Bernard Aboba claimms EUSM does things with RADIUS that are > > forbidden by the RADIUS protocol doesn't help its case a lot.) > > I'm not sure I remember that posting. It may well have to do with the > fact that RADIUS is not an authenticated key management service. There > are IDs proposing to add that kind of service to RADIUS. They are > currently considered out-of-scope of the RADEXT WG, because that WG's > charter explicitly excludes new security methods for RADIUS. > > Having said that, RADIUS, using EAP methods, has been used as the AAA > system behind the authenticated key management system in IEEE 802.11i > wireless LANs. > > There has also been some discussion of changes to RADIUS to make it FIPS > compliant (whatever that turns out to mean), and the RADEXT charter > might be revised at some point when NIST has given definitive guidance > on this subject, and sufficient progress has been made on WG > deliverables and milestones, to warrant a charter revision. Too soon to > predict... > > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C50714.74E4CAFC Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management authorization

Also note that EAP is used in 802.1x. The way that = RADIUS is designed suggesting extensions to its methods doesn't break = it - it's made to be customizable and extensible. The introduction of = EAP and thus numerous originally unintended authentication mechanisms = are already supported, why not another? Personally, I would argue that = existing EAP mechanisms provide for the exchange of key information and = thus no significant extensions are required. The only thing that = doesn't fit within the existing protocols AFAICT is the ability of a = trusted 3rd party to request key information on behalf of a client - = this sounds more like the Liberty Federation standards, but it is = definitely useful in RADIUS itself.

Is it possible to define the EUSM concepts of = layering key exchange within existing protocols out-of-band and then = supporting USM as-is? Is it possible to agree on the approach and then = debate which protocols can be reused for it? And then the = details?

It seems to me, to make sense to talk about the main = architectural goals:
1. Use SNMPv3 and USM as-is (meaning provide key = exchange through a different mechanism, without modifying SNMPv3 - this = should also work for VACM but is outside of scope for this = discussion)

2. The authenticator should provide key generation = capabilities for the authenticatee in the case that a central AAA is = not available (system should work a) without a central AAA b) with the = central AAA unavailable) - otherwise the authenticator must request key = information for a user upon session initiation

3. The generation of keys should be timed to provide = for session time-outs and things like this

Doesn't this just make sense? The big questions to me = are:
1. Can we agree on RADIUS EAP and can the extensions = needed be standardized
2. How can generation, caching and timeout of keys = best be designed to provide PFS and minimize communication with a = central AAA

(Host-specific access control is also interesting but = out of scope)

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Nelson, David
> Sent: January 11, 2005 3:38 PM
> To: isms@ietf.org
> Subject: RE: [Isms] RE: Network management = authorization
>
>
> > (Of course, the fact
> > that Bernard Aboba claimms EUSM does = things with RADIUS that are
> > forbidden by the RADIUS protocol doesn't = help its case a lot.)
>
> I'm not sure I remember that posting.  It = may well have to do with the
> fact that RADIUS is not an authenticated key = management service.  There
> are IDs proposing to add that kind of service = to RADIUS.  They are
> currently considered out-of-scope of the RADEXT = WG, because that WG's
> charter explicitly excludes new security = methods for RADIUS.
>
> Having said that, RADIUS, using EAP methods, = has been used as the AAA
> system behind the authenticated key management = system in IEEE 802.11i
> wireless LANs.
>
> There has also been some discussion of changes = to RADIUS to make it FIPS
> compliant (whatever that turns out to mean), = and the RADEXT charter
> might be revised at some point when NIST has = given definitive guidance
> on this subject, and sufficient progress has = been made on WG
> deliverables and milestones, to warrant a = charter revision.  Too soon to
> predict...
>
>
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C50714.74E4CAFC-- --===============0584947253== 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 --===============0584947253==-- From isms-bounces@ietf.org Mon Jan 31 12:45: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 MAA28453; Mon, 31 Jan 2005 12:45:59 -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 1Cvfty-0001GV-Me; Mon, 31 Jan 2005 13:04:37 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CvfbV-0006On-MM; Mon, 31 Jan 2005 12:44:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfUA-0001r0-5d; Mon, 31 Jan 2005 12:37:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CutTi-0005Ro-VA for isms@megatron.ietf.org; Sat, 29 Jan 2005 09:21: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 JAA12288 for ; Sat, 29 Jan 2005 09:21:32 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CutlG-0004b2-9D for isms@ietf.org; Sat, 29 Jan 2005 09:39:42 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0TEKoW18646; Sat, 29 Jan 2005 09:20:50 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sat, 29 Jan 2005 09:20:50 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B7E9@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'David T. Perkins'" , David B Harrington Subject: RE: [Isms] Evaluation status [and more] Date: Sat, 29 Jan 2005 09:20:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 3f2cf88677bfbdeff30feb2c80e2257d X-Mailman-Approved-At: Mon, 31 Jan 2005 12:37:11 -0500 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0834134971==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec 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. --===============0834134971== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5060D.598D3231" 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_01C5060D.598D3231 Content-Type: text/plain I definitely support the specification of a base set of capabilities and their use on the device to provide simplicity and commonality to the administration of simple devices, but it would be a real shame to think that this would solve everyone's problems. I thought the point of VACM is to provide a significant range of possible access control models depending on the granularity and complexity required? Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of David T. Perkins > Sent: January 28, 2005 5:25 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > HI, > > Interesting... > Lets say there are three "roles" or "capabilities", > which would correspond to VACM groups. Given > these, the standards track documents containing MIB modules > could indicate which objects and notifications should > be available for access type for each role. Given this > info in RFCs, it would be a mechanical process to > create entries in the view, and access tables. > That is, entries in table vacmViewTreeFamilyTable, > and table vacmAccessTable. > > Entries would be created in tables usmUserTable and > vacmSecurityToGroupTable when support for a new a user > is added. And entries would be created in tables > snmpCommunityTable and vacmSecurityToGroupTable > when support for a new community string is added. > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > 1) the number of groups in most VACM configurations would be > > > two or three. (For a lot of equipment, I believe > > > this to be true.) > > > > > > 2) the decision about which bits of management information > > should > > > be accessible to which of these groups does not need to be > > > under control of the security administrator. > > > > > > 3) equipment manufacturers will decide which groups get > > > which access, > > > and it would be acceptible if this could be changed only by > > a > > > firmware/software upgrade > > > > > > Did I get this much right? > > > If so, do you think a standard policy for these could be > > > formulated as an > > > addendum to RFC 3415 appendix A.1? > > > > > > Randy > > > > > I believe this is fairly accurate as a representation of what exists. > > And I think we coul dhelp the SNMP community migrate from communities > > to VACM much more than we have by defining incremental migration > > paths. > > > > We could do a service to operators by defining some standard access > > control templates for VACM groups, comparable to public (r-o most), > > private (r-w-most), and super-user (r-w-all). This would help admins > > accustomed to the traditional SNMPv1 communities to migrate to VACM > > access control. Then admins could expand the group assignments from > > that point if desired. I would consider adding a new security-admin > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > I think it would help admins if we discussed how applications can > > serve as SNMPv3 USM users, for all their users. Some applications > > already provide user-level access control. I don't like this as much > > as agent-access-control, but it is easier to configure USM with a few > > applications than with larger number of users, while ISMS tries to > > improve ease-of-use. On a side note, Spectrum used to provide > > something like nine levels of user access control, and now only > > provide three because customers never used the extra six levels. > > > > In SNMPv1, the immutable assignments were made to communities, but I'm > > not sure whether contexts, views or groups are the right answer in > > SNMPv3. Contexts are the immutable entities, so I think contexts might > > be the right answer. I think we could help the vendors provide default > > assignment of mib modules to public/private/root contexts by providing > > a list of IETF mib modules, and recommend which context they should be > > associated with. > > > > David Harrington > > dbharrington@comcast.net > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C5060D.598D3231 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Evaluation status [and more]

I definitely support the specification of a base set = of capabilities and their use on the device to provide simplicity and = commonality to the administration of simple devices, but it would be a = real shame to think that this would solve everyone's problems. I = thought the point of VACM is to provide a significant range of possible = access control models depending on the granularity and complexity = required?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of David T. Perkins
> Sent: January 28, 2005 5:25 PM
> To: David B Harrington
> Cc: isms@ietf.org
> Subject: RE: [Isms] Evaluation status [and = more]
>
> HI,
>
> Interesting...
> Lets say there are three "roles" or = "capabilities",
> which would correspond to VACM groups. = Given
> these, the standards track documents containing = MIB modules
> could indicate which objects and notifications = should
> be available for access type for each role. = Given this
> info in RFCs, it would be a mechanical process = to
> create entries in the view, and access = tables.
> That is, entries in table = vacmViewTreeFamilyTable,
> and table vacmAccessTable.
>
> Entries would be created in tables usmUserTable = and
> vacmSecurityToGroupTable when support for a new = a user
> is added. And entries would be created in = tables
> snmpCommunityTable and = vacmSecurityToGroupTable
> when support for a new community string is = added.
>
>
> On Fri, 28 Jan 2005, David B Harrington = wrote:
> > > -----Original Message-----
> > > From: = isms-bounces@lists.ietf.org
> > > [mailto:isms-bounces@lists.ie= tf.org] On Behalf Of Randy Presuhn
> > >
> > > If I understand you correctly, you're = making a couple of claims:
> > >
> > >     1) the number = of groups in most VACM configurations would be
> > = >         two or = three.  (For a lot of equipment, I believe
> > > this to be true.)
> > >
> > >     2) the = decision about which bits of management information
> > should
> > = >         be accessible to = which of these groups does not need to be
> > = >         under control of = the security administrator.
> > >
> > >     3) equipment = manufacturers will decide which groups get
> > > which access,
> > = >         and it would be = acceptible if this could be changed only by
> > a
> > = >         firmware/software = upgrade
> > >
> > > Did I get this much right?
> > > If so, do you think a standard policy = for these could be
> > > formulated as an
> > > addendum to RFC 3415 appendix = A.1?
> > >
> > > Randy
> > >
> > I believe this is fairly accurate as a = representation of what exists.
> > And I think we coul dhelp the SNMP = community migrate from communities
> > to VACM much more than we have by defining = incremental migration
> > paths.
> >
> > We could do a service to operators by = defining some standard access
> > control templates for VACM groups, = comparable to public (r-o most),
> > private (r-w-most), and super-user = (r-w-all).  This would help admins
> > accustomed to the traditional SNMPv1 = communities to migrate to VACM
> > access control. Then admins could expand = the group assignments from
> > that point if desired. I would consider = adding a new security-admin
> > (r-w security mibs, such as VACM and USM = and RADIUS) as well.
> >
> > I think it would help admins if we = discussed how applications can
> > serve as SNMPv3 USM users, for all their = users. Some applications
> > already provide user-level access control. = I don't like this as much
> > as agent-access-control, but it is easier = to configure USM with a few
> > applications than with larger number of = users, while ISMS tries to
> > improve ease-of-use. On a side note, = Spectrum used to provide
> > something like nine levels of user access = control, and now only
> > provide three because customers never used = the extra six levels.
> >
> > In SNMPv1, the immutable assignments were = made to communities, but I'm
> > not sure whether contexts, views or groups = are the right answer in
> > SNMPv3. Contexts are the immutable = entities, so I think contexts might
> > be the right answer. I think we could help = the vendors provide default
> > assignment of mib modules to = public/private/root contexts by providing
> > a list of IETF mib modules, and recommend = which context they should be
> > associated with.
> >
> > David Harrington
> > dbharrington@comcast.net
>
> Regards,
> /david t. perkins
>
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C5060D.598D3231-- --===============0834134971== 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 --===============0834134971==-- From isms-bounces@ietf.org Mon Jan 31 12:46: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 MAA28528; Mon, 31 Jan 2005 12:46:07 -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 1CvfuS-0001Ol-Ky; Mon, 31 Jan 2005 13:04:45 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CvfcQ-0006Qc-1U; Mon, 31 Jan 2005 12:45:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfUA-0001r8-Jh; Mon, 31 Jan 2005 12:37:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQ8p-0002gh-ML for isms@megatron.ietf.org; Sun, 30 Jan 2005 20:14: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 UAA19221 for ; Sun, 30 Jan 2005 20:14:07 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQQf-0005Xc-IL for isms@ietf.org; Sun, 30 Jan 2005 20:32:37 -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 j0V1DDi09693; Sun, 30 Jan 2005 20:13:13 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Jan 2005 20:13:13 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B801@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Bernard Aboba'" , "Blumenthal, Uri" Subject: RE: [Isms] RE: Network management authorization Date: Sun, 30 Jan 2005 20:13:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 X-Mailman-Approved-At: Mon, 31 Jan 2005 12:37:11 -0500 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1170119098==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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. --===============1170119098== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50731.B5C99DFB" 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_01C50731.B5C99DFB Content-Type: text/plain I think it important to note that the same keys should not be used for communication, authentication, or key exchange. What I mean by this is that there should be three independent keys (assuming authPriv), meaning that if a centralized AAA is used there are separate shared keys for each client of the AAA. Martin. > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: January 18, 2005 2:40 PM > To: Blumenthal, Uri > Cc: ietfdbh@comcast.net; Soukup, Martin [CAR:5K50:EXCH]; Joseph Salowey; > isms@ietf.org > Subject: RE: [Isms] RE: Network management authorization > > > If the manager knows the AAA key, there's > > nothing wrong in its overtaking the AAA role and generating session keys > > + authorization. > > > > To summarize: details need to be worked out, but in general the approach > > is OK. > > In general, RADIUS clients are specifically authorized to act in that > role. A client cannot be configured to act as a RADIUS server merely > because it has knowledge of a RADIUS shared secret. For example, the > shared secret is supposed to be different for each client-server pair. ------_=_NextPart_001_01C50731.B5C99DFB Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] RE: Network management authorization

I think it important to note that the same keys = should not be used for communication, authentication, or key exchange. = What I mean by this is that there should be three independent keys = (assuming authPriv), meaning that if a centralized AAA is used there = are separate shared keys for each client of the AAA.

Martin.

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: January 18, 2005 2:40 PM
> To: Blumenthal, Uri
> Cc: ietfdbh@comcast.net; Soukup, Martin = [CAR:5K50:EXCH]; Joseph Salowey;
> isms@ietf.org
> Subject: RE: [Isms] RE: Network management = authorization
>
> > If the manager knows the AAA key, = there's
> > nothing wrong in its overtaking the AAA = role and generating session keys
> > + authorization.
> >
> > To summarize: details need to be worked = out, but in general the approach
> > is OK.
>
> In general, RADIUS clients are specifically = authorized to act in that
> role.  A client cannot be configured to = act as a RADIUS server merely
> because it has knowledge of a RADIUS shared = secret.  For example, the
> shared secret is supposed to be different for = each client-server pair.

------_=_NextPart_001_01C50731.B5C99DFB-- --===============1170119098== 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 --===============1170119098==-- From isms-bounces@ietf.org Mon Jan 31 12:46:10 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 MAA28562; Mon, 31 Jan 2005 12:46:10 -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 1Cvfua-0001QC-Dq; Mon, 31 Jan 2005 13:04:48 -0500 Received: from megatron.ietf.org ([132.151.6.71]) by mx2.foretec.com with esmtp (Exim 4.24) id 1CvfcY-0006Qo-Jl; Mon, 31 Jan 2005 12:45:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvfUA-0001rC-P5; Mon, 31 Jan 2005 12:37:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvQQt-0004Nu-16 for isms@megatron.ietf.org; Sun, 30 Jan 2005 20:32: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 UAA20307 for ; Sun, 30 Jan 2005 20:32:48 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvQii-0005oM-Ap for isms@ietf.org; Sun, 30 Jan 2005 20:51:17 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j0V1WCT11411; Sun, 30 Jan 2005 20:32:12 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 30 Jan 2005 20:32:12 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B802@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'ietfdbh@comcast.net'" , "'David T. Perkins'" Subject: RE: [Isms] Evaluation status [and more] Date: Sun, 30 Jan 2005 20:32:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616 X-Mailman-Approved-At: Mon, 31 Jan 2005 12:37:11 -0500 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0783001846==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 10e6cb90de4fe268e7150fb24857273b 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. --===============0783001846== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50734.503A79EA" 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_01C50734.503A79EA Content-Type: text/plain I think that's what I said. I think that the migration of SNMP users to secure communication and complex access control is once direction things are moving. The other is the movement of users with experience with secure communication and complex access control to SNMP. It just important, to me, to find a solution that solves both migrations if possible. Martin. -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net] Sent: January 29, 2005 12:13 PM To: Soukup, Martin [CAR:5K50:EXCH]; 'David T. Perkins' Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] Hi Martin, I haven't seen anybody suggest that any proposal mentioned would solve everybody's problems. VACM is granular and complex so it can be configured to meet a wide range of needs. But having a highly granular, complex access control system also doesn't solve everybody's problems if many of the targeted users cannot figure out how to migrate to it, and the implementations provided by vendors make it hard to configure to meet operators' needs. We need to help users who don't need all the complexity to use it in a simple manner, and to standardize some vendor-neutral defaults to simplify the migration from the SNMPv1 approach to the SNMPv3 approach. dbh _____ From: Martin Soukup [mailto:msoukup@nortel.com] Sent: Saturday, January 29, 2005 9:21 AM To: 'David T. Perkins'; David B Harrington Cc: isms@ietf.org Subject: RE: [Isms] Evaluation status [and more] I definitely support the specification of a base set of capabilities and their use on the device to provide simplicity and commonality to the administration of simple devices, but it would be a real shame to think that this would solve everyone's problems. I thought the point of VACM is to provide a significant range of possible access control models depending on the granularity and complexity required? Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org ] On > Behalf Of David T. Perkins > Sent: January 28, 2005 5:25 PM > To: David B Harrington > Cc: isms@ietf.org > Subject: RE: [Isms] Evaluation status [and more] > > HI, > > Interesting... > Lets say there are three "roles" or "capabilities", > which would correspond to VACM groups. Given > these, the standards track documents containing MIB modules > could indicate which objects and notifications should > be available for access type for each role. Given this > info in RFCs, it would be a mechanical process to > create entries in the view, and access tables. > That is, entries in table vacmViewTreeFamilyTable, > and table vacmAccessTable. > > Entries would be created in tables usmUserTable and > vacmSecurityToGroupTable when support for a new a user > is added. And entries would be created in tables > snmpCommunityTable and vacmSecurityToGroupTable > when support for a new community string is added. > > > On Fri, 28 Jan 2005, David B Harrington wrote: > > > -----Original Message----- > > > From: isms-bounces@lists.ietf.org > > > [mailto:isms-bounces@lists.ietf.org ] On Behalf Of Randy Presuhn > > > > > > If I understand you correctly, you're making a couple of claims: > > > > > > 1) the number of groups in most VACM configurations would be > > > two or three. (For a lot of equipment, I believe > > > this to be true.) > > > > > > 2) the decision about which bits of management information > > should > > > be accessible to which of these groups does not need to be > > > under control of the security administrator. > > > > > > 3) equipment manufacturers will decide which groups get > > > which access, > > > and it would be acceptible if this could be changed only by > > a > > > firmware/software upgrade > > > > > > Did I get this much right? > > > If so, do you think a standard policy for these could be > > > formulated as an > > > addendum to RFC 3415 appendix A.1? > > > > > > Randy > > > > > I believe this is fairly accurate as a representation of what exists. > > And I think we coul dhelp the SNMP community migrate from communities > > to VACM much more than we have by defining incremental migration > > paths. > > > > We could do a service to operators by defining some standard access > > control templates for VACM groups, comparable to public (r-o most), > > private (r-w-most), and super-user (r-w-all). This would help admins > > accustomed to the traditional SNMPv1 communities to migrate to VACM > > access control. Then admins could expand the group assignments from > > that point if desired. I would consider adding a new security-admin > > (r-w security mibs, such as VACM and USM and RADIUS) as well. > > > > I think it would help admins if we discussed how applications can > > serve as SNMPv3 USM users, for all their users. Some applications > > already provide user-level access control. I don't like this as much > > as agent-access-control, but it is easier to configure USM with a few > > applications than with larger number of users, while ISMS tries to > > improve ease-of-use. On a side note, Spectrum used to provide > > something like nine levels of user access control, and now only > > provide three because customers never used the extra six levels. > > > > In SNMPv1, the immutable assignments were made to communities, but I'm > > not sure whether contexts, views or groups are the right answer in > > SNMPv3. Contexts are the immutable entities, so I think contexts might > > be the right answer. I think we could help the vendors provide default > > assignment of mib modules to public/private/root contexts by providing > > a list of IETF mib modules, and recommend which context they should be > > associated with. > > > > David Harrington > > dbharrington@comcast.net > > Regards, > /david t. perkins > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C50734.503A79EA Content-Type: text/html RE: [Isms] Evaluation status [and more]

I think that’s what I said. I think that the migration of SNMP users to secure communication and complex access control is once direction things are moving. The other is the movement of users with experience with secure communication and complex access control to SNMP. It just important, to me, to find a solution that solves both migrations if possible.

 

Martin.

 

-----Original Message-----
From: David B Harrington [mailto:ietfdbh@comcast.net]
Sent: January 29, 2005 12:13 PM
To: Soukup, Martin [CAR:5K50:EXCH]; 'David T. Perkins'
Cc: isms@ietf.org
Subject: RE: [Isms] Evaluation status [and more]

 

Hi Martin,

 

I haven't seen anybody suggest that any proposal mentioned would solve everybody's problems. VACM is granular and complex so it can be configured to meet a wide range of needs. But having a highly granular, complex access control system also doesn't solve everybody's problems if many of the targeted users cannot figure out how to migrate to it, and the implementations provided by vendors make it hard to configure to meet operators' needs.

 

We need to help users who don't need all the complexity to use it in a simple manner, and to standardize some vendor-neutral defaults to simplify the migration from the SNMPv1 approach to the SNMPv3 approach.

 

dbh

 

From: Martin Soukup [mailto:msoukup@nortel.com]
Sent: Saturday, January 29, 2005 9:21 AM
To: 'David T. Perkins'; David B Harrington
Cc: isms@ietf.org
Subject: RE: [Isms] Evaluation status [and more]

I definitely support the specification of a base set of capabilities and their use on the device to provide simplicity and commonality to the administration of simple devices, but it would be a real shame to think that this would solve everyone's problems. I thought the point of VACM is to provide a significant range of possible access control models depending on the granularity and complexity required?

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On
> Behalf Of David T. Perkins
> Sent: January 28, 2005 5:25 PM
> To: David B Harrington
> Cc: isms@ietf.org
> Subject: RE: [Isms] Evaluation status [and more]
>
> HI,
>
> Interesting...
> Lets say there are three "roles" or "capabilities",
> which would correspond to VACM groups. Given
> these, the standards track documents containing MIB modules
> could indicate which objects and notifications should
> be available for access type for each role. Given this
> info in RFCs, it would be a mechanical process to
> create entries in the view, and access tables.
> That is, entries in table vacmViewTreeFamilyTable,
> and table vacmAccessTable.
>
> Entries would be created in tables usmUserTable and
> vacmSecurityToGroupTable when support for a new a user
> is added. And entries would be created in tables
> snmpCommunityTable and vacmSecurityToGroupTable
> when support for a new community string is added.
>
>
> On Fri, 28 Jan 2005, David B Harrington wrote:
> > > -----Original Message-----
> > > From: isms-bounces@lists.ietf.org
> > > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Randy Presuhn
> > >
> > > If I understand you correctly, you're making a couple of claims:
> > >
> > >     1) the number of groups in most VACM configurations would be
> > >         two or three.  (For a lot of equipment, I believe
> > > this to be true.)
> > >
> > >     2) the decision about which bits of management information
> > should
> > >         be accessible to which of these groups does not need to be
> > >         under control of the security administrator.
> > >
> > >     3) equipment manufacturers will decide which groups get
> > > which access,
> > >         and it would be acceptible if this could be changed only by
> > a
> > >         firmware/software upgrade
> > >
> > > Did I get this much right?
> > > If so, do you think a standard policy for these could be
> > > formulated as an
> > > addendum to RFC 3415 appendix A.1?
> > >
> > > Randy
> > >
> > I believe this is fairly accurate as a representation of what exists.
> > And I think we coul dhelp the SNMP community migrate from communities
> > to VACM much more than we have by defining incremental migration
> > paths.
> >
> > We could do a service to operators by defining some standard access
> > control templates for VACM groups, comparable to public (r-o most),
> > private (r-w-most), and super-user (r-w-all).  This would help admins
> > accustomed to the traditional SNMPv1 communities to migrate to VACM
> > access control. Then admins could expand the group assignments from
> > that point if desired. I would consider adding a new security-admin
> > (r-w security mibs, such as VACM and USM and RADIUS) as well.
> >
> > I think it would help admins if we discussed how applications can
> > serve as SNMPv3 USM users, for all their users. Some applications
> > already provide user-level access control. I don't like this as much
> > as agent-access-control, but it is easier to configure USM with a few
> > applications than with larger number of users, while ISMS tries to
> > improve ease-of-use. On a side note, Spectrum used to provide
> > something like nine levels of user access control, and now only
> > provide three because customers never used the extra six levels.
> >
> > In SNMPv1, the immutable assignments were made to communities, but I'm
> > not sure whether contexts, views or groups are the right answer in
> > SNMPv3. Contexts are the immutable entities, so I think contexts might
> > be the right answer. I think we could help the vendors provide default
> > assignment of mib modules to public/private/root contexts by providing
> > a list of IETF mib modules, and recommend which context they should be
> > associated with.
> >
> > David Harrington
> > dbharrington@comcast.net
>
> Regards,
> /david t. perkins
>
>
> _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms

------_=_NextPart_001_01C50734.503A79EA-- --===============0783001846== 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 --===============0783001846==-- From isms-bounces@ietf.org Mon Jan 31 13:40: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 NAA04870; Mon, 31 Jan 2005 13:40:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvglP-00030g-8p; Mon, 31 Jan 2005 13:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvgS6-0004QK-MW; Mon, 31 Jan 2005 13:39:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvgRN-0004BQ-3t for isms@megatron.ietf.org; Mon, 31 Jan 2005 13:38:25 -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 NAA04690 for ; Mon, 31 Jan 2005 13:38:20 -0500 (EST) Received: from blaster.systems.pipex.net ([62.241.163.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvgjJ-0002wt-H3 for isms@ietf.org; Mon, 31 Jan 2005 13:56:59 -0500 Received: from pc6 (1Cust163.tnt2.lnd4.gbr.da.uu.net [62.188.131.163]) by blaster.systems.pipex.net (Postfix) with SMTP id 96961E0002D8; Mon, 31 Jan 2005 18:37:40 +0000 (GMT) Message-ID: <047401c507bb$53d3dec0$0601a8c0@pc6> From: "Tom Petch" To: "Wijnen, Bert (Bert)" , References: <7D5D48D2CAA3D84C813F5B154F43B1550649824A@nl0006exch001u.nl.lucent.com> Subject: Re: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 18:33:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Yes I would be keen to see an ID along the lines given below, seeing it as an additional appendix to RFC3415, and would be willing to help in whatever way I can. But as my posts show, I lack the VACM skills to generate the technical details (or any software to test them with) of the ideas I have in mind.. Tom Petch ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: ; "'Martin Soukup'" ; "'David T. Perkins'" Cc: Sent: Monday, January 31, 2005 2:42 PM Subject: RE: [Isms] Evaluation status [and more] > Inline > > > -----Original Message----- > > From: David B Harrington [mailto:ietfdbh@comcast.net] > > Sent: Monday, January 31, 2005 14:10 > > To: 'Wijnen, Bert (Bert)'; 'Martin Soukup'; 'David T. Perkins' > > Cc: isms@ietf.org > > Subject: RE: [Isms] Evaluation status [and more] > > > > > > Hi bert, > > > > > We should help make the trasnition easier by defining VACM defaults > > that are consistent with the way users view the world already, and > > then they can extend it in more advanced ways as they're ready. Users > > do not currently think in terms of "", "initial", > > "initial-semi-secure-configuration", "minimum-secure", "semi-secure" > > and so on; they think in terms of public, private and superuser > > communities. > > > > Defining defaults that correspond to the traditional concepts could > > help overcome one of the thresholds that makes adoption of SNMPv3 > > harder. > > > So go ahead and write an I-D that defines that! > > Bert > > David Harrington > > dbharrington@comcast.net _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 31 14:02:10 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 OAA07721; Mon, 31 Jan 2005 14:02:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvh6N-0003Z7-Cy; Mon, 31 Jan 2005 14:20:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvggI-0006a1-Kl; Mon, 31 Jan 2005 13:53:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvgbu-0005lA-FG for isms@megatron.ietf.org; Mon, 31 Jan 2005 13:49: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 NAA06082 for ; Mon, 31 Jan 2005 13:49:15 -0500 (EST) Received: from moby.atcorp.com ([204.72.172.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvgtr-0003EK-ET for isms@ietf.org; Mon, 31 Jan 2005 14:07:54 -0500 Received: from conger.atcorp.com ([204.72.172.102] helo=STRIPER) by moby.atcorp.com with esmtp (Exim 3.35 #1 (Debian)) id 1CvgbL-00052G-00; Mon, 31 Jan 2005 12:48:43 -0600 From: "Wayne Kading" To: Subject: RE: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 12:46:08 -0600 Organization: ATC Message-ID: <010701c507c5$211197c0$84aca8c0@STRIPER> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20050126081155.GB3715@james> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable After reading the recent posts to this list and reviewing Wes' survey = dated 2004-08-11, the compatibility concern with legacy SNMP which I raised = below may not be as important as originally thought to be. Even though 62+% = of users are still on SMNPv1/SMNPv2 per Wes' survey, there may be more = interest in moving to SNMPv3 if a firmware upgrade of the client is required as = Randy suggested. I also noticed that Wes' survey indicates on p. 4 that 86% = of the users said they would use SNMPv3 if it would support one or more of their existing authentication methods. Wayne -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Wednesday, January 26, 2005 2:12 AM To: Wayne Kading Cc: isms@ietf.org Subject: Re: [Isms] Evaluation status [and more] On Tue, Jan 25, 2005 at 06:09:51PM -0600, Wayne Kading wrote: > Due to legacy security concerns where SNMP v1/v2c/v3 equipment > coexists, it appears that SNMP v1/v2c security should be addressed in = the > evaluation criteria and related proposals if it isn't already. I = would also > be interested to see what importance is assigned to this criteria as = it is a > concern in many large environments. Can you explain what the potential market impact of being able to ship=20 legacy SNMP over a secure transport actually is? I know this is hard to judge but actually the most critical question to ask when evaluating the proposals. /js --=20 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 Mon Jan 31 17:33: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 RAA14359; Mon, 31 Jan 2005 17:33:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkPA-0004yH-0Q; Mon, 31 Jan 2005 17:52:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjxN-0004NS-U3; Mon, 31 Jan 2005 17:23:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjHt-0001m8-5v for isms@megatron.ietf.org; Mon, 31 Jan 2005 16:40: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 QAA01121 for ; Mon, 31 Jan 2005 16:40:47 -0500 (EST) Received: from adsl-64-165-72-150.dsl.scrm01.pacbell.net ([64.165.72.150] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjZq-00015g-WE for isms@ietf.org; Mon, 31 Jan 2005 16:59:24 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 10EC911D9FE; Mon, 31 Jan 2005 13:40:42 -0800 (PST) From: Wes Hardaker To: "Wayne Kading" Subject: Re: [Isms] Evaluation status [and more] Organization: Sparta References: <010701c507c5$211197c0$84aca8c0@STRIPER> Date: Mon, 31 Jan 2005 13:40:41 -0800 In-Reply-To: <010701c507c5$211197c0$84aca8c0@STRIPER> (Wayne Kading's message of "Mon, 31 Jan 2005 12:46:08 -0600") 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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: d6b246023072368de71562c0ab503126 >>>>> On Mon, 31 Jan 2005 12:46:08 -0600, "Wayne Kading" said: Wayne> I also noticed that Wes' survey indicates on p. 4 that 86% of Wayne> the users said they would use SNMPv3 if it would support one or Wayne> more of their existing authentication methods. Some of the comments actually said similar things. IE, the reason they hadn't moved to V3 was it was going to be a pain. If ISMS results improve on this then they'll be more likely to switch. The survey results very clearly spelled that out, IMHO. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 31 17:34: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 RAA14488; Mon, 31 Jan 2005 17:34:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvkPp-0004zx-NW; Mon, 31 Jan 2005 17:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjyA-00056Y-PG; Mon, 31 Jan 2005 17:24:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvjMJ-0004cp-9s for isms@megatron.ietf.org; Mon, 31 Jan 2005 16:45: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 QAA02283 for ; Mon, 31 Jan 2005 16:45:21 -0500 (EST) Received: from adsl-64-165-72-150.dsl.scrm01.pacbell.net ([64.165.72.150] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvjeJ-0001TW-Nr for isms@ietf.org; Mon, 31 Jan 2005 17:04:01 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DBE6211D9FF; Mon, 31 Jan 2005 13:45:17 -0800 (PST) From: Wes Hardaker To: "Martin Soukup" Subject: Re: [Isms] Evaluation status [and more] Organization: Sparta References: <0BDFFF51DC89434FA33F8B37FCE363D501F2B802@zcarhxm2.corp.nortel.com> Date: Mon, 31 Jan 2005 13:45:17 -0800 In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2B802@zcarhxm2.corp.nortel.com> (Martin Soukup's message of "Sun, 30 Jan 2005 20:32:09 -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: 0bc60ec82efc80c84b8d02f4b0e4de22 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: b19722fc8d3865b147c75ae2495625f2 >>>>> On Sun, 30 Jan 2005 20:32:09 -0500, "Martin Soukup" said: Martin> I think that's what I said. I think that the migration of SNMP Martin> users to secure communication and complex access control is Martin> once direction things are moving. The other is the movement of Martin> users with experience with secure communication and complex Martin> access control to SNMP. It just important, to me, to find a Martin> solution that solves both migrations if possible. In order to achieve maximum deployment and usability, I agree that we need to solve all the deployment problems that people face. This includes both secure communication via authentication mechanisms operators already use (ISMS work) as well as work to help distribute authorization configuration to VACM or anything else (future work). I don't, however, see a technical to tie the results together. IE, I don't think the charter for ISMS should ever be expanded to say that both problems (or others) must be bound together in a single solution. They should, obviously, be usable together however. 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. We're now at the end of January and still have yet to hear from the evaluation team but yet the clock is still ticking away. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 31 18:50: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 SAA24448; Mon, 31 Jan 2005 18:50:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvlbb-0007Q7-LG; Mon, 31 Jan 2005 19:09:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvlEz-00085c-Iz; Mon, 31 Jan 2005 18:45:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvl4m-0005f5-NE for isms@megatron.ietf.org; Mon, 31 Jan 2005 18:35: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 SAA22818 for ; Mon, 31 Jan 2005 18:35:22 -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 1CvlMj-00070K-7M for isms@ietf.org; Mon, 31 Jan 2005 18:54: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 j0VNZFZC003329 for ; Mon, 31 Jan 2005 18:35:15 -0500 (EST) Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Mon, 31 Jan 2005 18:35:16 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Mon, 31 Jan 2005 18:35:16 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 31 Jan 2005 18:35:15 -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] Evaluation status [and more] Date: Mon, 31 Jan 2005 18:35:15 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E190E1@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] Evaluation status [and more] Thread-Index: AcUH5RF9QAKkdw2RRI+jq2cJRdNCvgABxjXA From: "Nelson, David" To: "Wes Hardaker" X-OriginalArrivalTime: 31 Jan 2005 23:35:15.0853 (UTC) FILETIME=[8451E3D0:01C507ED] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:87.1726 M:98.0684 P:95.9108 R:95.9108 S:93.7443 ) X-pstn-settings: 4 (0.2500:0.2500) p:13 m:13 c:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Wes Hardaker writes... > I don't think the charter for ISMS should ever be expanded to=20 > say that both problems (or others) must be bound together in=20 > a single solution. They should, obviously, be usable together=20 > however. Hmm... I'm confused by this. I believe that authorization *needs* to be strongly bound to authentication, to be robust and trustworthy. While there may be ways to accomplish that binding using disparate solutions, it seems that it would be much easier (straightforward) to achieve the binding using a single solution. That's not to say that we don't have the potential for using multiple AAA protocols, but rather to say we ought not to mix authentication from protocol "A" with authorization from protocol "B". > I would not mind, personally, if the charter were updated to=20 > include such future work as well but right now we haven't=20 > actually accomplished the immediate goals of determining an=20 > architectural direction to solve the current problem. Agreed. We need to keep the pressure on to complete current goals. That doesn't mean that authorization is unimportant, however. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Jan 31 21:52: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 VAA11173; Mon, 31 Jan 2005 21:52:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvoRN-0002zs-5w; Mon, 31 Jan 2005 22:10:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvo1l-0007u6-6V; Mon, 31 Jan 2005 21:44:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvnzo-0007fa-UR for isms@megatron.ietf.org; Mon, 31 Jan 2005 21:42: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 VAA10503 for ; Mon, 31 Jan 2005 21:42:23 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvoHp-0002nE-VC for isms@ietf.org; Mon, 31 Jan 2005 22:01:06 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j112ffU01194; Mon, 31 Jan 2005 21:41:41 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Jan 2005 21:41:41 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2B827@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Wes Hardaker'" Subject: RE: [Isms] Evaluation status [and more] Date: Mon, 31 Jan 2005 21:41:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1082075611==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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. --===============1082075611== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50807.361936C8" 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_01C50807.361936C8 Content-Type: text/plain > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: January 31, 2005 4:45 PM > To: Soukup, Martin [CAR:5K50:EXCH] > Cc: 'ietfdbh@comcast.net'; 'David T. Perkins'; isms@ietf.org > Subject: Re: [Isms] Evaluation status [and more] > > >>>>> On Sun, 30 Jan 2005 20:32:09 -0500, "Martin Soukup" > said: > > Martin> I think that's what I said. I think that the migration of SNMP > Martin> users to secure communication and complex access control is > Martin> once direction things are moving. The other is the movement of > Martin> users with experience with secure communication and complex > Martin> access control to SNMP. It just important, to me, to find a > Martin> solution that solves both migrations if possible. > > In order to achieve maximum deployment and usability, I agree that we > need to solve all the deployment problems that people face. This > includes both secure communication via authentication mechanisms > operators already use (ISMS work) as well as work to help distribute > authorization configuration to VACM or anything else (future work). I > don't, however, see a technical to tie the results together. IE, I > don't think the charter for ISMS should ever be expanded to say that > both problems (or others) must be bound together in a single > solution. They should, obviously, be usable together however. 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. We're now at the end of > January and still have yet to hear from the evaluation team but yet > the clock is still ticking away. I agree that this is out of scope and that it is best to focus on accomplishing something here. I agree that authN should be defined separately from authR, but not the reverse - something to be debated after ISMS creates something we all use I hope. Martin. ------_=_NextPart_001_01C50807.361936C8 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Evaluation status [and more]

> -----Original Message-----
> From: Wes Hardaker [mailto:hardaker@tislabs.com]
> Sent: January 31, 2005 4:45 PM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: 'ietfdbh@comcast.net'; 'David T. Perkins'; = isms@ietf.org
> Subject: Re: [Isms] Evaluation status [and = more]
>
> >>>>> On Sun, 30 Jan 2005 = 20:32:09 -0500, "Martin Soukup"
> <msoukup@nortel.com> said:
>
> Martin> I think that's what I said. I think = that the migration of SNMP
> Martin> users to secure communication and = complex access control is
> Martin> once direction things are moving. = The other is the movement of
> Martin> users with experience with secure = communication and complex
> Martin> access control to SNMP. It just = important, to me, to find a
> Martin> solution that solves both migrations = if possible.
>
> In order to achieve maximum deployment and = usability, I agree that we
> need to solve all the deployment problems that = people face.  This
> includes both secure communication via = authentication mechanisms
> operators already use (ISMS work) as well as = work to help distribute
> authorization configuration to VACM or anything = else (future work).  I
> don't, however, see a technical to tie the = results together.  IE, I
> don't think the charter for ISMS should ever be = expanded to say that
> both problems (or others) must be bound = together in a single
> solution.  They should, obviously, be = usable together however.  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.  = We're now at the end of
> January and still have yet to hear from the = evaluation team but yet
> the clock is still ticking away.

I agree that this is out of scope and that it is best = to focus on accomplishing something here. I agree that authN should be = defined separately from authR, but not the reverse - something to be = debated after ISMS creates something we all use I hope.

Martin.

------_=_NextPart_001_01C50807.361936C8-- --===============1082075611== 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 --===============1082075611==--