From isms-bounces@ietf.org Tue Mar 1 11:25: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 LAA12182; Tue, 1 Mar 2005 11:25:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ACY-0007YH-6F; Tue, 01 Mar 2005 11:26:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A4F-00030d-1a; Tue, 01 Mar 2005 11:17:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A4D-0002wm-Mz for isms@megatron.ietf.org; Tue, 01 Mar 2005 11:17: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 LAA11043 for ; Tue, 1 Mar 2005 11:17:47 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6A5B-0007GR-H1 for isms@ietf.org; Tue, 01 Mar 2005 11:18:50 -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 j21GHYcJ023309 for ; Tue, 1 Mar 2005 08:17:34 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j21GHetB001741 for ; Tue, 1 Mar 2005 08:17:40 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j21GHeOh001738 for ; Tue, 1 Mar 2005 08:17:40 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Tue, 1 Mar 2005 08:17:40 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Isms] Agenda item X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad HI, I would like to add a 10 minute presentation about the problems of the USM to the agenda. Thanks, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 11:57: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 LAA16425; Tue, 1 Mar 2005 11:57:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6AhV-0008T8-PW; Tue, 01 Mar 2005 11:58:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Aej-0003Vh-PW; Tue, 01 Mar 2005 11:55:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Aei-0003Uv-7V for isms@megatron.ietf.org; Tue, 01 Mar 2005 11:55: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 LAA16254 for ; Tue, 1 Mar 2005 11:55:29 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Afd-0008Qe-7e for isms@ietf.org; Tue, 01 Mar 2005 11:56:33 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA19991 for ; Tue, 1 Mar 2005 08:55:04 -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 j21GtFI06609 for ; Tue, 1 Mar 2005 08:55:15 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 08:55:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 08:55:10 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCCD@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlgAB7IiuA= From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Mar 2005 16:55:10.0611 (UTC) FILETIME=[6E0F6630:01C51E7F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Due to problems with the USM Authentication system, including significant weaknesses in SNMP key distribution in large multi-vendor environments, a very real possibility exists that Bad Guys can learn the identity of legitimate managers and spoof them. Good session protections are a helpful but inadequate defense against that. You are putting all of your eggs in the session security basket. However, what is needed is good defense in depth protections for the system as a whole. This is an elementary security precept, which is made all the more important for SNMPv3 due to widespread system blemishes/flaws with the USM security system as a whole when deployed within large, multi-vendor environments. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Monday, February 28, 2005 6:04 PM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 > I certainly agree with you about the need for "session" but I do not=20 > believe that "session" alone will meet all of our needs. Specifically, I > remain very concerned about weaknesses in the authentication system=20 > being exploited by crackers. What specific weaknesses in what part of authentication system? Rememeber that the traffic is protected by session-wide keys that are created when the session is established and are gone once the session is terminated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 12:16: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 MAA18939; Tue, 1 Mar 2005 12:16:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6B0N-0000fl-54; Tue, 01 Mar 2005 12:17:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Ayd-0007BK-6u; Tue, 01 Mar 2005 12:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Ayb-0007BF-CU for isms@megatron.ietf.org; Tue, 01 Mar 2005 12:16: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 MAA18785 for ; Tue, 1 Mar 2005 12:16:02 -0500 (EST) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Aza-0000dI-KC for isms@ietf.org; Tue, 01 Mar 2005 12:17:07 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j21HFsIX023038; Tue, 1 Mar 2005 17:15:54 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc,v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j21HFjox017223; Tue, 1 Mar 2005 17:15:54 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030109155426000 ; Tue, 01 Mar 2005 09:15:54 -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, 1 Mar 2005 09:15:46 -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, 1 Mar 2005 09:15:46 -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, 1 Mar 2005 12:15:45 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 12:15:35 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C21D4B@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlgAB7IiuAAAPAusA== From: "Blumenthal, Uri" To: "Fleischman, Eric" , X-OriginalArrivalTime: 01 Mar 2005 17:15:45.0161 (UTC) FILETIME=[4DE8C790:01C51E82] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: quoted-printable > Due to problems with the USM Authentication system, For the second time in this exchange I'm asking what specific problems you're talking about. > including significant weaknesses in SNMP key distribution in large > multi-vendor environments, Weaknesses such as...? Be specific please. And what does "multi-vendor" have to do with this?! > a very real possibility exists that Bad Guys can learn the identity > of legitimate managers and spoof them. Identities of the entities that establish the session must be revealed - unless you're willing to pay for anonymous Diffie-Hellman. Please explain how one can spoof a legitimate manager (as this implies that authentication mechanism is broken). > You are putting all of your eggs in the session security basket. > However, what is needed is good defense in depth protections for the > system as a whole. This is an elementary security precept, which is made > all the more important for SNMPv3 due to widespread system > blemishes/flaws with the USM security system as a whole when deployed > within large, multi-vendor environments. Please be specific. I'm getting tired watching all this hand-waving about some unspecified indescribable "widespread system blemishes/flaws". This is not a PR forum, after all. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Monday, February 28, 2005 6:04 PM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 > I certainly agree with you about the need for "session" but I do not=20 > believe that "session" alone will meet all of our needs. Specifically, I > remain very concerned about weaknesses in the authentication system=20 > being exploited by crackers. What specific weaknesses in what part of authentication system? Rememeber that the traffic is protected by session-wide keys that are created when the session is established and are gone once the session is terminated. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ 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 Mar 1 12:21: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 MAA19495; Tue, 1 Mar 2005 12:21:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6B53-0000pm-Gz; Tue, 01 Mar 2005 12:22:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B3W-0001XA-1r; Tue, 01 Mar 2005 12:21:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B3U-0001X0-29 for isms@megatron.ietf.org; Tue, 01 Mar 2005 12:21: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 MAA19464 for ; Tue, 1 Mar 2005 12:21:05 -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 1D6B4S-0000p8-G6 for isms@ietf.org; Tue, 01 Mar 2005 12:22:09 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id B8D0F11DBF6; Tue, 1 Mar 2005 09:21:02 -0800 (PST) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Organization: Sparta References: <200502281940.OAA27595@ietf.org> Date: Tue, 01 Mar 2005 09:21:02 -0800 In-Reply-To: <200502281940.OAA27595@ietf.org> (David B. Harrington's message of "Mon, 28 Feb 2005 14:40:17 -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 David> I have seen many complaints that SNMPv3 is hard to deploy; I David> have been trying to address the deployment issue, and I think David> the bulk of the WG are focusing on the deployment issue. In an David> IAB workshop for network management, with numerous operators David> present, there were complaints about the SNMP ease-of-use, but David> none about SNMPv3 not being secure enough. I think 90% of David> operators are satisifed that USM is secure, and the WG is David> trying to make it possible for that 90% to deploy SNMPv3 (with David> security comparable to USM) more easily. [I've been away or unavailable for the last two weeks and am trying to catch up...] The survey I conducted asked operators (reminder: almost entirely from NANOG advertising, but not a few others responded as well): When asked the question: Is the current SNMPv3 with USM sufficiently secure for your needs? The responses were: 38 Abstain 37 No 74 Yes Thus the data from my side resulted in 69% of one set of operators thought it was secure enough. This is certainly above half, but certainly a lot lower than a complete agreement. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 12:26: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 MAA19774; Tue, 1 Mar 2005 12:26:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6B9Z-0000ua-KP; Tue, 01 Mar 2005 12:27:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B6j-0002ai-C3; Tue, 01 Mar 2005 12:24:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B6h-0002aY-NQ for isms@megatron.ietf.org; Tue, 01 Mar 2005 12:24:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19608 for ; Tue, 1 Mar 2005 12:24:25 -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 1D6B7f-0000sN-UG for isms@ietf.org; Tue, 01 Mar 2005 12:25:29 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) 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 j21HOHjZ017505 for ; Tue, 1 Mar 2005 17:24:17 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j21HOGop025162 for ; Tue, 1 Mar 2005 17:24:17 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030109241627564 for ; Tue, 01 Mar 2005 09:24:16 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 09:24:16 -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, 1 Mar 2005 09:24:16 -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, 1 Mar 2005 12:24:14 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 12:24:05 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C21D60@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUegyyllZDJ2o3uQTiT5KLrIPfVLgAAC6yQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 01 Mar 2005 17:24:14.0734 (UTC) FILETIME=[7DA372E0:01C51E83] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable I expect this ratio to change favorably once EUSM is out. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Wes Hardaker Sent: Tuesday, March 01, 2005 12:21 PM To: ietfdbh@comcast.net Cc: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) David> I have seen many complaints that SNMPv3 is hard to deploy; I David> have been trying to address the deployment issue, and I think David> the bulk of the WG are focusing on the deployment issue. In an David> IAB workshop for network management, with numerous operators David> present, there were complaints about the SNMP ease-of-use, but David> none about SNMPv3 not being secure enough. I think 90% of David> operators are satisifed that USM is secure, and the WG is David> trying to make it possible for that 90% to deploy SNMPv3 (with David> security comparable to USM) more easily. [I've been away or unavailable for the last two weeks and am trying to catch up...] The survey I conducted asked operators (reminder: almost entirely from NANOG advertising, but not a few others responded as well): When asked the question: Is the current SNMPv3 with USM sufficiently secure for your needs? The responses were: 38 Abstain 37 No 74 Yes Thus the data from my side resulted in 69% of one set of operators thought it was secure enough. This is certainly above half, but certainly a lot lower than a complete agreement. --=20 Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 14:21: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 OAA00487; Tue, 1 Mar 2005 14:21:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Cwh-0003iT-SW; Tue, 01 Mar 2005 14:22:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Crz-0006vC-HP; Tue, 01 Mar 2005 14:17:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Cry-0006ux-H9 for isms@megatron.ietf.org; Tue, 01 Mar 2005 14:17: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 OAA00278 for ; Tue, 1 Mar 2005 14:17:19 -0500 (EST) Message-Id: <200503011917.OAA00278@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Csy-0003ej-VK for isms@ietf.org; Tue, 01 Mar 2005 14:18:25 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <2005030119171301100t4sj3e>; Tue, 1 Mar 2005 19:17:13 +0000 From: "David B Harrington" To: Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 14:17:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUegxV9oFk+FsGRTmeEJwRvxMTTIwACWLrg In-Reply-To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: 7bit Hi Wes, I recall that your survey had a caveat about the sum being greater than 100%. Can you quickly explain what the percentages mean, and how much overlap might exist between the categories. I have difficulty understanding how to interpret any answer overlaps in a binary yes/no question (assuming the abstains didn't actually vote). Do you have the raw data still? Is this overlap because some voted both yes and no? Is the overlap because those that abstained also voted? I didn't say that 100% of operators felt it was secure enough; I used the 90-10 rule to argue we should try to meet the needs of the majority. I would be happy to apply the same argument to a 74-36 or 69-31 split. If the WG can only focus on one security model, I suggest we address the need of the majority rather than the minority. Of course, if we can develop something that will address the needs of the majority and most of the needs of the minority at the same time, that would be ideal. While I recognize that certain segments of the community are most concerned with strong security, I have learned from history. The SNMPv2 Party Model focused on the needs of the security community, but was totally unusable by most operators because it prevented such things as autodiscovery of a network. I don't want to see us repeat that mistake here. I would hate to hold up progress in addressing the needs of the majority to meet the "requirements" of a vocal minority. As Uri points out, SNMPv3 was deliberately developed in a modular architecture so different segments of the industry could develop solutions to meet their specific needs, without requiring that the SNMP community find one and only one standard solution that meets everybody's needs. The SNMPv2 wars and subsequent WG meltdown demonstrated very effectively that such a one-size-fits-all approach is unlikely to ever reach resolution. Is it unfortunate that we might need to field multiple security models to meet all needs rather than just one standard? Yes. But the nice thing about the modular architecture and allowing multiple supplemental security models is that developers of specific security models will need to convince vendors and operators that they need the specific security model. If they cannot *sell* their solution, it will simply never be adopted by the industry; if the solution really is needed, then they should be able to sell it without much trouble. It's a let-the-market-select the approach to supplementing/replacing USM that best meets their needs. I think it is unfortunate that the area directors insisted the ISMS WG select only one direction to work on, when two supplemental models with much common infrastructure might better serve the industry, but that's their choice, and given the track record of SNMP-related WGs over the past five years, I understand their decision. I do expect that the WG will try their best to address as many "requirements" as possible. We need to pick one direction to focus on. It appears to me that the greater market demand is for improved ease-of-use. There are more operators complaining about the difficulty of deploying SNMPv3 than are complaining about the security being too weak, and Wes's survey results support that assertion. I think the first supplemental/alternate security model to USM should be focused primarily on improving the ease of deployment. Another security model can be developed independently to address the need for stronger security than USM offers. Then the operators can choose which they want to use for their environment. That's my $.02 David Harrington dbharrington@comcast.net co-chair IETF SNMPv3 WG, concluded > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: Tuesday, March 01, 2005 12:21 PM > To: ietfdbh@comcast.net > Cc: 'Fleischman, Eric'; 'Randy Presuhn'; isms@ietf.org > Subject: Re: [Isms] achieving market saturation with ISMS (fwd) > > > David> I have seen many complaints that SNMPv3 is hard to deploy; I > David> have been trying to address the deployment issue, and I think > David> the bulk of the WG are focusing on the deployment issue. In an > David> IAB workshop for network management, with numerous operators > David> present, there were complaints about the SNMP ease-of-use, but > David> none about SNMPv3 not being secure enough. I think 90% of > David> operators are satisifed that USM is secure, and the WG is > David> trying to make it possible for that 90% to deploy SNMPv3 (with > David> security comparable to USM) more easily. > > [I've been away or unavailable for the last two weeks and am trying to > catch up...] > > The survey I conducted asked operators (reminder: almost entirely from > NANOG advertising, but not a few others responded as well): > > When asked the question: > > Is the current SNMPv3 with USM sufficiently secure for your needs? > > The responses were: > > 38 Abstain > 37 No > 74 Yes > > Thus the data from my side resulted in 69% of one set of operators > thought it was secure enough. This is certainly above half, but > certainly a lot lower than a complete agreement. > > -- > Wes Hardaker > Sparta > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 15:34: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 PAA08525; Tue, 1 Mar 2005 15:34:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6E5g-0005KV-Gh; Tue, 01 Mar 2005 15:35:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6E4T-00048u-BY; Tue, 01 Mar 2005 15:34:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6E4R-00048p-PS for isms@megatron.ietf.org; Tue, 01 Mar 2005 15:34: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 PAA08517 for ; Tue, 1 Mar 2005 15:34:16 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6E5S-0005K9-FV for isms@ietf.org; Tue, 01 Mar 2005 15:35: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 MAA20755 for ; Tue, 1 Mar 2005 12:34:09 -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 j21KY9I08453 for ; Tue, 1 Mar 2005 12:34:09 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 12:34:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 12:34:05 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCCE@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlgAB7IiuAAAPAusAAATkKA From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Mar 2005 20:34:06.0083 (UTC) FILETIME=[03695D30:01C51E9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >> Due to problems with the USM Authentication system, >For the second time in this exchange I'm asking what=20 >specific problems you're talking about. The problems are due to loosely-defined concepts and ill-advised assumptions/oversights, when viewed from a system perspective, within the SNMPv3 USM itself coupled with the many optional elements in the specs (i.e., RFCs). These create uneven vendor implementations that cause inherent security gaps and flaws in multi-vendor deployments. These problems are exacerbated by the following security blemishes in the USM itself, which enable these gaps to be leveraged into ***significant*** security vulnerabilities: 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys 6) SNMPv3 USM keys are unrelated to any existing authentication system within a deployment (e.g., Kerberos, PKI, Radius, etc.) >> including significant weaknesses in SNMP key distribution in large=20 >> multi-vendor environments, >Weaknesses such as...? Be specific please. And what does "multi-vendor" have to do with this?! For example, some commendable SNMP products support RFC 2786 (see http://www.ietf.org/rfc/rfc2786.txt), which provides a Diffie-Hellman-like key exchange mechanism that is available for SNMPv3 systems to use. Most/many vendors have not implemented this. Some SNMPv3 products require that keys must be based on passwords due to their inherently weak key distribution capabilities. Some don't have any key distribution systems at all.=20 "Multi-vendor" is the key operative word in my communications because a function of extremely large deployments is that we have "at least one of everything." Thus, we don't have the luxury of choosing only the vendors with so-called "good" USM implementations but rather have to leverage whatever capabilities are supported in the products and try to make a coherent system out of it. This often devolves into the least common divisor -- a horrific result from the security perspective. This is characteristic for large deployments in general, which also have to address inherent scalability issues that do not exist in small deployments (e.g., less than 100,000 devices).=20 >> a very real possibility exists that Bad Guys can learn the identity of=20 >> legitimate managers and spoof them. >Identities of the entities that establish the session must be revealed -=20 >unless you're willing to pay for anonymous Diffie-Hellman. Please explain=20 >how one can spoof a legitimate manager (as this implies that authentication >mechanism is broken). No. You are still thinking that USM doing its own authentication system is viable. It isn't, not by a long shot. SNMP is only one application!!!! It is prohibitively expensive to create authentication systems deployment-wide. Large institutions usually have several generic authentication systems deployed within the Enterprise including PKI (e.g., primarily for application authentication), Kerberos (e.g., for MS Windows), and Radius (e.g., perimeter or security zone access control). Few companies can afford to create a separate authentication system for SNMP only. Please note that SNMP's security is distinct from other IETF protocols (I state this because I've studied the key management approaches used by ALL of the IETF protocols) and is also unlike any other system deployed in our infrastructure (that I've encountered, at least).=20 >>: You are putting all of your eggs in the session security basket.=20 >> However, what is needed is good defense in depth protections for the=20 >> system as a whole. This is an elementary security precept, which is made >> all the more important for SNMPv3 due to widespread system=20 >> blemishes/flaws with the USM security system as a whole when deployed >> within large, multi-vendor environments. >Please be specific. I'm getting tired watching all this hand-waving=20 >about some unspecified indescribable "widespread system=20 >blemishes/flaws". This is not a PR forum, after all. And I'm getting tired of providing elementary, Security 101 explanations as to why it is so very easy to crack SNMP systems!!! What do you want: a list of 30 different step-by-step ways to crack SNMP? Egads! That would demonstrate NOTHING because each instance is a function that the USM security *****SYSTEM***** itself is not viable. This is partially evidenced by the fact that the security capabilities of different vendors SNMP products do not adequately work together and partially evidenced by the flaws in the USM security system itself that I have been highlighting.=20 All security systems, including USM, are subject to a similar set of traditional threats. These traditional threats include: bypass (unauthorized leaking of info (e.g., between security zones/COIs)), compromise (unauthorized reading of data), tamper (unauthorized writing of data), cascade (failure in one partition/security subsystem causing failure in another), covert channel (malicious or erroneous code using authentication processes and side effects in order to leak information), subversion (trick an authorized person to install bad software into the system believing that it is good software or to reveal key authentication info; etc.), and virus (use of tamper to have malicious code replicate itself throughout the system). Of course, many of these are artifacts of USM being deployed within specific environments (e.g., operational security), but these vulnerabilities are greatly magnified by inherent weaknesses within the USM itself. For example, the fact that the USM implements a unique authentication system within the deployment makes it orders-of-magnitude more vulnerable to subversion, for example, than had it used a generic, infrastructure-wide authentication system (e.g., Kerberos, PKI, Radius, etc).=20 These are NOT difficult concepts to understand. Any CISSP should intuitively understand these elementary issues without my having to mention them. --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 15:51: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 PAA09777; Tue, 1 Mar 2005 15:51:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6EM3-0005dA-5u; Tue, 01 Mar 2005 15:52:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EJy-000758-LH; Tue, 01 Mar 2005 15:50:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EJw-000750-Ol for isms@megatron.ietf.org; Tue, 01 Mar 2005 15:50: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 PAA09737 for ; Tue, 1 Mar 2005 15:50:17 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6EKx-0005cC-5W for isms@ietf.org; Tue, 01 Mar 2005 15:51:24 -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 j21KoDfe007414 for ; Tue, 1 Mar 2005 15:50:13 -0500 (EST) Message-Id: <200503012050.j21KoDfe007414@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCCE@xch-nw-09.nw.nos.boeing.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 01 Mar 2005 15:50:14 -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: 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.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 >The problems are due to loosely-defined concepts and ill-advised >assumptions/oversights, when viewed from a system perspective, within >the SNMPv3 USM itself coupled with the many optional elements in the >specs (i.e., RFCs). These create uneven vendor implementations that >cause inherent security gaps and flaws in multi-vendor deployments. >These problems are exacerbated by the following security blemishes in >the USM itself, which enable these gaps to be leveraged into >***significant*** security vulnerabilities: >1) no provisions for two-factored authentication >2) SNMP symmetric keys may be assembled from passwords >3) Key updates do not provide for Perfect Forward Security >4) Inherent Symmetric Key distribution problems >5) Lack of viable session keys >6) SNMPv3 USM keys are unrelated to any existing authentication system >within a deployment (e.g., Kerberos, PKI, Radius, etc.) While I agree that the above things are not ideal, I don't think any of these points are what I would call "signficant" security vulnerabilities. >From a _protocol_ standpoint, USM has had signficant peer review. Considering it's goals, I think it's a reasonable protocol. The only downside I see in it is that the base spec only specifies DES and MD5 (but a later draft did specify AES). I don't even think DES was a huge problem in practice, because crackers aren't really doing DES brute-force attacks currently (they have so many other avenues). That's not to say we shouldn't be moving away from DES, but I don't think it's currently a fatal flaw. I think we all agree that from a _deployment_ perspective, USM's problem is Key Mangement (which is basically the root of most of your above points). That's why we're here. But strictly speaking, this is outside of the scope of the USM _protocol_ (the USM RFC also specifies some of the USM key management, so it's a bit confusing). Uri's talking about the protocol; you're talking about the deployment/key management. Can we all move on now? --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 16:03:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10594; Tue, 1 Mar 2005 16:03:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6EXh-0005yX-9x; Tue, 01 Mar 2005 16:04:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EUM-0000Um-0g; Tue, 01 Mar 2005 16:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6EUK-0000Uh-Qb for isms@megatron.ietf.org; Tue, 01 Mar 2005 16:01:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10471 for ; Tue, 1 Mar 2005 16:01:03 -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 1D6EVK-0005vg-M9 for isms@ietf.org; Tue, 01 Mar 2005 16:02:08 -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 j21L0rEe027218 for ; Tue, 1 Mar 2005 21:00:53 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 j21L0qot023609 for ; Tue, 1 Mar 2005 21:00:53 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030113005308893 for ; Tue, 01 Mar 2005 13:00:53 -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, 1 Mar 2005 13:00:35 -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, 1 Mar 2005 13:00:35 -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, 1 Mar 2005 16:00:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 16:00:24 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C21FD2@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlgAB7IiuAAAPAusAAATkKAAAewJ/A= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 01 Mar 2005 21:00:34.0481 (UTC) FILETIME=[B62BAA10:01C51EA1] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab 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: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Thank you, I think I've seen enough. I'm through with this discussion. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Tuesday, March 01, 2005 3:34 PM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >> Due to problems with the USM Authentication system, >For the second time in this exchange I'm asking what=20 >specific problems you're talking about. The problems are due to loosely-defined concepts and ill-advised assumptions/oversights, when viewed from a system perspective, within the SNMPv3 USM itself coupled with the many optional elements in the specs (i.e., RFCs). These create uneven vendor implementations that cause inherent security gaps and flaws in multi-vendor deployments. These problems are exacerbated by the following security blemishes in the USM itself, which enable these gaps to be leveraged into ***significant*** security vulnerabilities: 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys 6) SNMPv3 USM keys are unrelated to any existing authentication system within a deployment (e.g., Kerberos, PKI, Radius, etc.) >> including significant weaknesses in SNMP key distribution in large=20 >> multi-vendor environments, >Weaknesses such as...? Be specific please. And what does "multi-vendor" have to do with this?! For example, some commendable SNMP products support RFC 2786 (see http://www.ietf.org/rfc/rfc2786.txt), which provides a Diffie-Hellman-like key exchange mechanism that is available for SNMPv3 systems to use. Most/many vendors have not implemented this. Some SNMPv3 products require that keys must be based on passwords due to their inherently weak key distribution capabilities. Some don't have any key distribution systems at all.=20 "Multi-vendor" is the key operative word in my communications because a function of extremely large deployments is that we have "at least one of everything." Thus, we don't have the luxury of choosing only the vendors with so-called "good" USM implementations but rather have to leverage whatever capabilities are supported in the products and try to make a coherent system out of it. This often devolves into the least common divisor -- a horrific result from the security perspective. This is characteristic for large deployments in general, which also have to address inherent scalability issues that do not exist in small deployments (e.g., less than 100,000 devices).=20 >> a very real possibility exists that Bad Guys can learn the identity of=20 >> legitimate managers and spoof them. >Identities of the entities that establish the session must be revealed -=20 >unless you're willing to pay for anonymous Diffie-Hellman. Please explain=20 >how one can spoof a legitimate manager (as this implies that authentication >mechanism is broken). No. You are still thinking that USM doing its own authentication system is viable. It isn't, not by a long shot. SNMP is only one application!!!! It is prohibitively expensive to create authentication systems deployment-wide. Large institutions usually have several generic authentication systems deployed within the Enterprise including PKI (e.g., primarily for application authentication), Kerberos (e.g., for MS Windows), and Radius (e.g., perimeter or security zone access control). Few companies can afford to create a separate authentication system for SNMP only. Please note that SNMP's security is distinct from other IETF protocols (I state this because I've studied the key management approaches used by ALL of the IETF protocols) and is also unlike any other system deployed in our infrastructure (that I've encountered, at least).=20 >>: You are putting all of your eggs in the session security basket.=20 >> However, what is needed is good defense in depth protections for the=20 >> system as a whole. This is an elementary security precept, which is made >> all the more important for SNMPv3 due to widespread system=20 >> blemishes/flaws with the USM security system as a whole when deployed >> within large, multi-vendor environments. >Please be specific. I'm getting tired watching all this hand-waving=20 >about some unspecified indescribable "widespread system=20 >blemishes/flaws". This is not a PR forum, after all. And I'm getting tired of providing elementary, Security 101 explanations as to why it is so very easy to crack SNMP systems!!! What do you want: a list of 30 different step-by-step ways to crack SNMP? Egads! That would demonstrate NOTHING because each instance is a function that the USM security *****SYSTEM***** itself is not viable. This is partially evidenced by the fact that the security capabilities of different vendors SNMP products do not adequately work together and partially evidenced by the flaws in the USM security system itself that I have been highlighting.=20 All security systems, including USM, are subject to a similar set of traditional threats. These traditional threats include: bypass (unauthorized leaking of info (e.g., between security zones/COIs)), compromise (unauthorized reading of data), tamper (unauthorized writing of data), cascade (failure in one partition/security subsystem causing failure in another), covert channel (malicious or erroneous code using authentication processes and side effects in order to leak information), subversion (trick an authorized person to install bad software into the system believing that it is good software or to reveal key authentication info; etc.), and virus (use of tamper to have malicious code replicate itself throughout the system). Of course, many of these are artifacts of USM being deployed within specific environments (e.g., operational security), but these vulnerabilities are greatly magnified by inherent weaknesses within the USM itself. For example, the fact that the USM implements a unique authentication system within the deployment makes it orders-of-magnitude more vulnerable to subversion, for example, than had it used a generic, infrastructure-wide authentication system (e.g., Kerberos, PKI, Radius, etc).=20 These are NOT difficult concepts to understand. Any CISSP should intuitively understand these elementary issues without my having to mention them. --Eric _______________________________________________ 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 Mar 1 16:27: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 QAA12323; Tue, 1 Mar 2005 16:27:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Eur-0006Oo-Bt; Tue, 01 Mar 2005 16:28:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Er8-0004JX-OP; Tue, 01 Mar 2005 16: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 1D6Er7-0004JS-HL for isms@megatron.ietf.org; Tue, 01 Mar 2005 16:24:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12159 for ; Tue, 1 Mar 2005 16:24:35 -0500 (EST) Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Es5-0006Lx-3n for isms@ietf.org; Tue, 01 Mar 2005 16:25:40 -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 NAA21988 for ; Tue, 1 Mar 2005 13:24:10 -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 j21LOME06277 for ; Tue, 1 Mar 2005 15:24:23 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:24:20 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 13:24:20 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCD2@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUduehK9xPanVGRQXuMfWDwSmVPDgAAS9vQAAbX0SAAAF6gkAAKqOlgAB7IiuAAAPAusAAATkKAAAh3hCA= From: "Fleischman, Eric" To: X-OriginalArrivalTime: 01 Mar 2005 21:24:20.0718 (UTC) FILETIME=[084628E0:01C51EA5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: quoted-printable I apologize to the list for my have used evocative language and far-too-strong-statements in my posting below. This reflects my growing frustration with this dialog. Nevertheless, it was very wrong of me to have used such evocative expressions and statements, which is unworthy of this list. Please forgive me. -----Original Message----- From: Fleischman, Eric=20 Sent: Tuesday, March 01, 2005 12:34 PM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 >> Due to problems with the USM Authentication system, >For the second time in this exchange I'm asking what >specific problems you're talking about. The problems are due to loosely-defined concepts and ill-advised assumptions/oversights, when viewed from a system perspective, within the SNMPv3 USM itself coupled with the many optional elements in the specs (i.e., RFCs). These create uneven vendor implementations that cause inherent security gaps and flaws in multi-vendor deployments. These problems are exacerbated by the following security blemishes in the USM itself, which enable these gaps to be leveraged into ***significant*** security vulnerabilities: 1) no provisions for two-factored authentication 2) SNMP symmetric keys may be assembled from passwords 3) Key updates do not provide for Perfect Forward Security 4) Inherent Symmetric Key distribution problems 5) Lack of viable session keys 6) SNMPv3 USM keys are unrelated to any existing authentication system within a deployment (e.g., Kerberos, PKI, Radius, etc.) >> including significant weaknesses in SNMP key distribution in large >> multi-vendor environments, >Weaknesses such as...? Be specific please. And what does "multi-vendor" have to do with this?! For example, some commendable SNMP products support RFC 2786 (see http://www.ietf.org/rfc/rfc2786.txt), which provides a Diffie-Hellman-like key exchange mechanism that is available for SNMPv3 systems to use. Most/many vendors have not implemented this. Some SNMPv3 products require that keys must be based on passwords due to their inherently weak key distribution capabilities. Some don't have any key distribution systems at all.=20 "Multi-vendor" is the key operative word in my communications because a function of extremely large deployments is that we have "at least one of everything." Thus, we don't have the luxury of choosing only the vendors with so-called "good" USM implementations but rather have to leverage whatever capabilities are supported in the products and try to make a coherent system out of it. This often devolves into the least common divisor -- a horrific result from the security perspective. This is characteristic for large deployments in general, which also have to address inherent scalability issues that do not exist in small deployments (e.g., less than 100,000 devices).=20 >> a very real possibility exists that Bad Guys can learn the identity of=20 >> legitimate managers and spoof them. >Identities of the entities that establish the session must be revealed -=20 >unless you're willing to pay for anonymous Diffie-Hellman. Please explain=20 >how one can spoof a legitimate manager (as this implies that authentication >mechanism is broken). No. You are still thinking that USM doing its own authentication system is viable. It isn't, not by a long shot. SNMP is only one application!!!! It is prohibitively expensive to create authentication systems deployment-wide. Large institutions usually have several generic authentication systems deployed within the Enterprise including PKI (e.g., primarily for application authentication), Kerberos (e.g., for MS Windows), and Radius (e.g., perimeter or security zone access control). Few companies can afford to create a separate authentication system for SNMP only. Please note that SNMP's security is distinct from other IETF protocols (I state this because I've studied the key management approaches used by ALL of the IETF protocols) and is also unlike any other system deployed in our infrastructure (that I've encountered, at least).=20 >>: You are putting all of your eggs in the session security basket. >> However, what is needed is good defense in depth protections for the=20 >> system as a whole. This is an elementary security precept, which is made >> all the more important for SNMPv3 due to widespread system >> blemishes/flaws with the USM security system as a whole when deployed >> within large, multi-vendor environments. >Please be specific. I'm getting tired watching all this hand-waving >about some unspecified indescribable "widespread system=20 >blemishes/flaws". This is not a PR forum, after all. And I'm getting tired of providing elementary, Security 101 explanations as to why it is so very easy to crack SNMP systems!!! What do you want: a list of 30 different step-by-step ways to crack SNMP? Egads! That would demonstrate NOTHING because each instance is a function that the USM security *****SYSTEM***** itself is not viable. This is partially evidenced by the fact that the security capabilities of different vendors SNMP products do not adequately work together and partially evidenced by the flaws in the USM security system itself that I have been highlighting.=20 All security systems, including USM, are subject to a similar set of traditional threats. These traditional threats include: bypass (unauthorized leaking of info (e.g., between security zones/COIs)), compromise (unauthorized reading of data), tamper (unauthorized writing of data), cascade (failure in one partition/security subsystem causing failure in another), covert channel (malicious or erroneous code using authentication processes and side effects in order to leak information), subversion (trick an authorized person to install bad software into the system believing that it is good software or to reveal key authentication info; etc.), and virus (use of tamper to have malicious code replicate itself throughout the system). Of course, many of these are artifacts of USM being deployed within specific environments (e.g., operational security), but these vulnerabilities are greatly magnified by inherent weaknesses within the USM itself. For example, the fact that the USM implements a unique authentication system within the deployment makes it orders-of-magnitude more vulnerable to subversion, for example, than had it used a generic, infrastructure-wide authentication system (e.g., Kerberos, PKI, Radius, etc).=20 These are NOT difficult concepts to understand. Any CISSP should intuitively understand these elementary issues without my having to mention them. --Eric _______________________________________________ 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 Mar 1 16:47: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 QAA14392; Tue, 1 Mar 2005 16:47:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FEl-0006sC-Hv; Tue, 01 Mar 2005 16:49:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FCf-0000MB-S9; Tue, 01 Mar 2005 16:46:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FCd-0000Ls-Fw for isms@megatron.ietf.org; Tue, 01 Mar 2005 16:46: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 QAA14298 for ; Tue, 1 Mar 2005 16:46:49 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FDd-0006pe-C6 for isms@ietf.org; Tue, 01 Mar 2005 16:47:54 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA22198; Tue, 1 Mar 2005 15:46:27 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j21LkQI16978; Tue, 1 Mar 2005 13:46:26 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 13:46:26 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 13:46:25 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCD3@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUeoHFQ2+EN84P8SJuQasXNWUbb5gABNeEA From: "Fleischman, Eric" To: "Ken Hornstein" , X-OriginalArrivalTime: 01 Mar 2005 21:46:26.0412 (UTC) FILETIME=[1E7302C0:01C51EA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 >I think we all agree that from a _deployment_ perspective,=20 >USM's problem is Key Mangement (which is basically the root=20 >of most of your above points). That's why we're here. But=20 >strictly speaking, this is outside of the scope of the USM=20 >_protocol_ (the USM RFC also specifies some of the USM key=20 >management, so it's a bit confusing). Uri's talking about=20 >the protocol; you're talking about the deployment/key management. =20 >Can we all move on now? Ken,=20 Actually, Uri was stating that enhancing Session management alone would meet the ISMS goals. While I agree that session management is needed, I was arguing that we also need enhanced key management. I believe that my arguments are consistent with the ISMS charter, which says (in part): "The ISMS working group will focus on finding and identifying a solution for the first of the two above mentioned problems: creating a security model for SNMPv3 that will meet the security and operational needs of network administrators." If you concur, then we should move on. However, I don't see how we can move on profitably until we have defined a common set of requirements and common set of criteria in order to evaluate the three proposals. That is the view from my knothole. How do Juergen and you propose that the WG proceed from this point? That is, I don't see how the published agenda for the forthcoming IETF will enable us to reach our March 5th milestone. Would you mind sharing with the group how you expect that the WG to achieve that milestone?=20 --Eric _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 17:09:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15893; Tue, 1 Mar 2005 17:09:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FZQ-0007Fa-Og; Tue, 01 Mar 2005 17:10:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FUR-0003vM-Gi; Tue, 01 Mar 2005 17:05:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FUO-0003vD-JE for isms@megatron.ietf.org; Tue, 01 Mar 2005 17:05: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 RAA15669 for ; Tue, 1 Mar 2005 17:05:10 -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 1D6FVM-0007BJ-Mi for isms@ietf.org; Tue, 01 Mar 2005 17:06:17 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DBB3811DBF8; Tue, 1 Mar 2005 14:04:58 -0800 (PST) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Organization: Sparta References: <200503011917.OAA00278@ietf.org> Date: Tue, 01 Mar 2005 14:04:57 -0800 In-Reply-To: <200503011917.OAA00278@ietf.org> (David B. Harrington's message of "Tue, 1 Mar 2005 14:17: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: ff03b0075c3fc728d7d60a15b4ee1ad2 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: b2809b6f39decc6de467dcf252f42af1 >>>>> On Tue, 1 Mar 2005 14:17:09 -0500, "David B Harrington" said: David> I recall that your survey had a caveat about the sum being greater David> than 100% That was only true for the questions that involved multiple choices where they were deliberately allowed to select multiple choices. EG, I asked them to mention all the security infrastructures they used, and thus they could have picked both ssh and radius and local-accounts if they were using all 3. Thus, the percentages for which were in use by the various environments were specific to each protocol (local accounts was at the top with 99 of 149 responses saying they used local accounts. 73 of 149 responses said they used ssh authentication (which really meant they used ssh). Obviously, 73 + 99 > 149 since they were independent choices. (Think "multiple checkboxes") However, in the case of the question that I just reported the answers for (again; all of this was made available on the list a long time ago; I'm merely repeating the results at this point), it was a fixed choice between 1 and only 1 of 3 possibilities "yes", "no", and "didn't answer" (abstain). (Think "radio box") Thus those percentages added up to exactly 100: Is the current SNMPv3 with USM sufficiently secure for your needs?: % Raw 25.6 38 Abstain 24.8 37 No 49.6 74 Yes ---- --- 100.0 149 Total Now the real question you should be asking at this point is why is the yes percentage 50 when I said it was 60 earlier? Err... I don't know. I must have done the math wrong before. It's certainly right above. Of those that didn't abstain, 66.7% think it's secure which might have been what I did... David> Do you have the raw data still? Yes I have the raw data still. I can post everything again if you like and indicate which were multiple options (checkboxes) and which were single options (radios or menus) if you like? David> While I recognize that certain segments of the community are most David> concerned with strong security, I have learned from history. The David> SNMPv2 Party Model focused on the needs of the security community, but David> was totally unusable by most operators because it prevented such David> things as autodiscovery of a network. I don't want to see us repeat David> that mistake here. Agreed. I don't think we should force ourselves down a secure but unusable path. However, I don't see a problem with going down a "more secure" and "more usable" path if that is helpful. David> As Uri points out, SNMPv3 was deliberately developed in a David> modular architecture so different segments of the industry David> could develop solutions to meet their specific needs, without David> requiring that the SNMP community find one and only one David> standard solution that meets everybody's needs. Agreed. What's interesting is that many years later, people suddenly don't want to change away from that security protocol. Although it's modular people (some) don't want to exercise that option. We've supported SNMP/Kerberos for a good number of years now (3) as a vendor-add on and it is in use (4/149 people from the response, eg). The advantage of coming to a common ground is that we can help more people use what they want. Having a single vendor support a given authentication scheme isn't as useful as having multiple vendors support it. David> I think it is unfortunate that the area directors insisted the David> ISMS WG select only one direction to work on, when two David> supplemental models with much common infrastructure might David> better serve the industry It is sad, but I agree understandable. Though when you have this much interest I don't see the harm in trying. It's better for us to try and fail than not try at all. Surely if we don't try to converge at all then no commonality will result. Even if we stand around and argue for a very long time, it's likely we'll at least converge a little and reduce the possibilities down to a smaller set. David> We need to pick one direction to focus on. It appears to me David> that the greater market demand is for improved David> ease-of-use. There are more operators complaining about the David> difficulty of deploying SNMPv3 than are complaining about the David> security being too weak, and Wes's survey results support that David> assertion. I think the first supplemental/alternate security David> model to USM should be focused primarily on improving the ease David> of deployment. Another security model can be developed David> independently to address the need for stronger security than David> USM offers. Then the operators can choose which they want to David> use for their environment. This is where we start to disagree. I agree absolutely with your statement that "There are more operators complaining about the difficulty of deploying SNMPv3 than are complaining about the security being too weak, and Wes's survey results support that assertion". However, my fundamental point is that unless you tie the "something new" to existing architectures *in use* it will do no good. SNMP is and will always be a service turned on later rather than immediately. Operators are much more concerned about getting a router to route than getting it managed. They will always want to turn it on and start it routing and *then* set up management. They may seem backwards to the NM community, but it's a fundamental aspect that won't be changed. Thus, the operators will always be setting up some form of user database/system before hand. Thus the argument that "if you get them to set up USM and then they can manage all the rest of the users" simply doesn't fly with me. If there is any work toward deploying something beyond what they already have running, then it will result in a delay in them deploying it. If they're not running radius, then deploying radius will be a pain to them. If they're running radius but don't have a radius server that supports key delivery extensions or doesn't have configured shared secrets to protect the traffic, this will be a pain. The question is: what is the least amount of pain you can offer them. If the answer is not as close as possible to 0, you will loose deployment time and deployment saturation. There is no way around that IMHO. SNMP isn't the reason they bought the box, and it will never be. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 17:36: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 RAA17773; Tue, 1 Mar 2005 17:36:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6G00-0007hJ-Vm; Tue, 01 Mar 2005 17:37:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FwZ-0000Ex-5B; Tue, 01 Mar 2005 17:34:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6FwY-0000Er-1D for isms@megatron.ietf.org; Tue, 01 Mar 2005 17:34: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 RAA17668 for ; Tue, 1 Mar 2005 17:34:16 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6FxZ-0007f9-Vn for isms@ietf.org; Tue, 01 Mar 2005 17:35:23 -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 j21MY6N7011437 for ; Tue, 1 Mar 2005 17:34:07 -0500 (EST) Message-Id: <200503012234.j21MY6N7011437@ginger.cmf.nrl.navy.mil> From: "Ken Hornstein (Contractor)" To: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCD3@xch-nw-09.nw.nos.boeing.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 01 Mar 2005 17:34:07 -0500 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: 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.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 >Actually, Uri was stating that enhancing Session management alone would >meet the ISMS goals. While I agree that session management is needed, I >was arguing that we also need enhanced key management. I went back and read Uri's messages; my interpretation of his messages is that adding a session will facilitate many things ... including enhanced key management (sure, I suppose we could do a session _without_ enhanced key management, that would be theoretically possible, but there would be no point and I think that everyone agrees on this). >I believe that my >arguments are consistent with the ISMS charter, which says (in part): >"The ISMS working group will focus on finding and identifying a solution >for the first of the two above mentioned problems: creating a security >model for SNMPv3 that will meet the security and operational needs of >network administrators." If you concur, then we should move on. I think we _all_ concur on that one. >However, I don't see how we can move on profitably until we have defined >a common set of requirements and common set of criteria in order to >evaluate the three proposals. That is the view from my knothole. How do >Juergen and you propose that the WG proceed from this point? That is, I >don't see how the published agenda for the forthcoming IETF will enable >us to reach our March 5th milestone. Would you mind sharing with the >group how you expect that the WG to achieve that milestone? We are having a conference with our AD, hopefully this week. I am sure this will be a discussion item. So ... "we're working on it". --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 1 17:38: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 RAA17863; Tue, 1 Mar 2005 17:38:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6G1x-0007iz-LT; Tue, 01 Mar 2005 17:39:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6G0j-0000jh-CQ; Tue, 01 Mar 2005 17:38:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6G0i-0000jZ-3p for isms@megatron.ietf.org; Tue, 01 Mar 2005 17:38: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 RAA17845 for ; Tue, 1 Mar 2005 17:38:33 -0500 (EST) Message-Id: <200503012238.RAA17845@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6G1j-0007iB-12 for isms@ietf.org; Tue, 01 Mar 2005 17:39:40 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <2005030122380001600sp12fe>; Tue, 1 Mar 2005 22:38:01 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , "'Ken Hornstein'" , Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 17:37:57 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUeoHFQ2+EN84P8SJuQasXNWUbb5gABNeEAAAEP0KA= In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCD3@xch-nw-09.nw.nos.boeing.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Content-Transfer-Encoding: 7bit X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Hi Eric, I agree it would be helpful to have a more concrete set of goals. I have a question for you. It's a hard and detailed question. You and I disagree on the nature of the security requirements. I think RFC3411 documents the security requirements; you have a different list. I am not a security dweeb; I'm an NM dweeb ;-) Understand that your comments that the USM specs are "too loose" or "vendor implementations are too inconsistent" just doesn't give us enough to go on to understand the nature of the security threat enabled by the difference between USM and your requirements, that we could actually address as protocol developers. Can you explain (in reasonable detail to a non-security person) the nature of the threats that are enabled by the difference between the RFC3411/USM security requirements and your requirements, and how those threats will drive implementation compliance by vendors and deployment compliance by operators? Vendor implementations are inconsistent because economic forces work against our desire to have better compliance to our standards. There is nothing we as protocol designers can do to overcome that fact. What we can do is try to better understand your concerns and try to address them. But I for one do not "grok" the security benefits of each of your requirements over USM enough to be able to understand the engineering cost/benefit ratios involved. How often are you getting hit with attacks that would be thwarted by support of two-factored authentication? How critical are those attacks to your network? Are the attacks that are enabled by non-two-factored authentication well-documented as a serious problem with no other solution to mitigate their seriousness? Are these attacks something that are especially attractive to attackers for attacking a management protocol like SNMP, or are these attacks so easy to do and effective in other instances, like network access that most attackers wouldn't bother attacking SNMP? What are the implementation and operational costs and corresponding benefits? Vendors don't implement according to the IETF standards now; what economic drivers that are ineffective getting compliance now will kick in to motivate them to support two-factored authentication if we write a standard that specifies it? If you can't provide solid justification for increasing the requirements above the RFC3411/USM level, I have trouble justifying committing resources to do so. As the network management architect of a vendor, I would need to sell such solutions to engineering, product management, and marketing and I would need to justify the resources it would take to offer such solutions. Customers continue to buy products from vendors that do not comply with IETf standards. You said yourself you need to buy the equipment, and cannot choose to buy only a compliant product. How will having these features in their products increase a vendors' sales? How will lack of these features hurt a vendors sales? I would have tremendous difficulty justifying the engineering expense of migrating from USM to a model that offers the features you want because I don't know what concrete benefits this migration would yield, and I wouldn't know how to market to our customers the benefits of having such features in our product lines. We can't even convince customers they need the increased security provided by USM and VACM. Can you help me understand how to justify moving from RFC3411/USM requirements to your specific requirements? Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Tuesday, March 01, 2005 4:46 PM > To: Ken Hornstein; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS (fwd) > > > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > >I think we all agree that from a _deployment_ perspective, > >USM's problem is Key Mangement (which is basically the root > >of most of your above points). That's why we're here. But > >strictly speaking, this is outside of the scope of the USM > >_protocol_ (the USM RFC also specifies some of the USM key > >management, so it's a bit confusing). Uri's talking about > >the protocol; you're talking about the deployment/key management. > >Can we all move on now? > > Ken, > > Actually, Uri was stating that enhancing Session management > alone would > meet the ISMS goals. While I agree that session management is > needed, I > was arguing that we also need enhanced key management. I > believe that my > arguments are consistent with the ISMS charter, which says (in part): > "The ISMS working group will focus on finding and identifying > a solution > for the first of the two above mentioned problems: creating a security > model for SNMPv3 that will meet the security and operational needs of > network administrators." If you concur, then we should move on. > > However, I don't see how we can move on profitably until we > have defined > a common set of requirements and common set of criteria in order to > evaluate the three proposals. That is the view from my > knothole. How do > Juergen and you propose that the WG proceed from this point? > That is, I > don't see how the published agenda for the forthcoming IETF > will enable > us to reach our March 5th milestone. Would you mind sharing with the > group how you expect that the WG to achieve that milestone? > > --Eric > > _______________________________________________ > 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 Mar 1 20:33: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 UAA01842; Tue, 1 Mar 2005 20:33:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ikw-0002dc-83; Tue, 01 Mar 2005 20:34:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Ij4-0006sd-UQ; Tue, 01 Mar 2005 20:32:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Iiy-0006sV-0C for isms@megatron.ietf.org; Tue, 01 Mar 2005 20:32: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 UAA01775 for ; Tue, 1 Mar 2005 20:32:24 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ik1-0002cY-GV for isms@ietf.org; Tue, 01 Mar 2005 20:33:34 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id TAA08332; Tue, 1 Mar 2005 19:31:55 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j221VtI22955; Tue, 1 Mar 2005 17:31:55 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 17:31:54 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Tue, 1 Mar 2005 17:31:54 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCD7@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUeoHFQ2+EN84P8SJuQasXNWUbb5gABNeEAAAEP0KAABEzUMA== From: "Fleischman, Eric" To: , "Ken Hornstein" , X-OriginalArrivalTime: 02 Mar 2005 01:31:54.0742 (UTC) FILETIME=[9DF65960:01C51EC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: d9238570526f12788af3d33c67f37625 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: bacfc6c7290e34d410f9bc22b825ce96 Content-Transfer-Encoding: quoted-printable David, I believe your true issue, David, is whether the USM can simultaneously leverage public authentication systems and remain otherwise unchanged in a backward compatible manner or whether a more capable alternative to USM needs to be devised that is distinct from USM. If we do the latter, I urge you to please create an SNMPv3 security environment that can meet every deployments' security needs (i.e., the current ISMS charter). SNMP security is inherently difficult. If that were not so, then there would have been security within SNMPv2. Thus, my criticisms of SNMPv3 USM should not be interpreted as deprecating the important and difficult accomplishments of the SNMPv3 USM community. However, simultaneously, there were oversights and unfortunate assumptions which that community made, which are largely due (in my opinion) from not having a system or end user perspective -- but this is a characteristic weakness within IETF work in general because there are so few of us end users participating in the IETF. Less controversial is the observation that security aids (such as viable enterprise-wide authentication systems) now exist that the SNMP security community can leverage today that weren't similarly widely available in the past. Also, other relevant IETF protocols have matured (e.g., http://www.ietf.org/internet-drafts/draft-rescorla-dtls-03.txt) such that they offer attractive technology alternatives that previously could not be on the table. My list of security requirements are basically tools to enable SNMP to have normal defense in depth protections that are common on most other systems, including many other IETF-defined protocols. For example, two factor authentication is only needed if one is insecure about the viability of the SNMP authentication system due to possible compromises during key distribution, or having doubts about the controls that protect the integrity of the authentication system itself (e.g., the controls to defend against subversion, covert channel, or other well-known threats). In many multi-vendor environments, there is plenty of reason to be skeptical about the integrity of the USM authentication system, unless adequate controls have been explicitly introduced to mitigate those concerns, which isn't always possible and may be quite expensive. For example, SSH can implement two factor authentication capabilities that system administrators may want to implement if they are worried about the viability of the user's crypto-identity. It's not that that capability has to always be implemented, it is rather that it is a good tool to address certain classes of threats -- or perceived threats. If SNMP does not similarly implement this capability, then that type of control will not be available to the system administrator if needed. I am not comfortable about talking about specific exploits, other than to say that it is my perception that SNMP security is the weakest security system, with the fewest number of available controls, of the systems I deal with. =20 I assume that you are familiar with the practices and philosophy behind quantitative risk analysis and qualitative risk analysis. That is, security has costs and so each infrastructure needs to determine how to get the best protection for their critical systems within their available budget. This often results in trade-offs that can be partially mitigated by defense in depth protections. Thus, no two networks necessarily have identical strengths and weaknesses, and thus their susceptibility to specific types of exploits may vary. This is why some infrastructures will not implement SNMP security at all, trusting other systems (e.g., perimeter firewall) to protect them. Other systems are well served by USM security as it is currently defined, particularly the smaller or homogeneous deployments. However, other systems, the type I work with, need the type of defense in depth protections/provisions I have been arguing for. Why should you migrate from USM if USM fully meets your needs? However, if USM doesn't and can't meet the needs of many other communities, then why aren't you willing to permit a robust SNMPv3 security alternative to USM to be defined (i.e., fulfilling the ISMS WG charter that says "creating a security model for SNMPv3 that will meet the security and operational needs of network administrators")? From where I sit, both the "no security" and "USM security" options remain on the table. What I am urging is to have a third alternative that meets the more robust security needs of my type of deployment. --Eric -----Original Message----- From: David B Harrington [mailto:ietfdbh@comcast.net]=20 Sent: Tuesday, March 01, 2005 2:38 PM To: Fleischman, Eric; 'Ken Hornstein'; isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 Hi Eric, I agree it would be helpful to have a more concrete set of goals. I have a question for you. It's a hard and detailed question. You and I disagree on the nature of the security requirements. I think RFC3411 documents the security requirements; you have a different list.=20 I am not a security dweeb; I'm an NM dweeb ;-) Understand that your comments that the USM specs are "too loose" or "vendor implementations are too inconsistent" just doesn't give us enough to go on to understand the nature of the security threat enabled by the difference between USM and your requirements, that we could actually address as protocol developers. Can you explain (in reasonable detail to a non-security person) the nature of the threats that are enabled by the difference between the RFC3411/USM security requirements and your requirements, and how those threats will drive implementation compliance by vendors and deployment compliance by operators?=20 Vendor implementations are inconsistent because economic forces work against our desire to have better compliance to our standards. There is nothing we as protocol designers can do to overcome that fact. What we can do is try to better understand your concerns and try to address them. But I for one do not "grok" the security benefits of each of your requirements over USM enough to be able to understand the engineering cost/benefit ratios involved.=20 How often are you getting hit with attacks that would be thwarted by support of two-factored authentication? How critical are those attacks to your network? Are the attacks that are enabled by non-two-factored authentication well-documented as a serious problem with no other solution to mitigate their seriousness? Are these attacks something that are especially attractive to attackers for attacking a management protocol like SNMP, or are these attacks so easy to do and effective in other instances, like network access that most attackers wouldn't bother attacking SNMP? What are the implementation and operational costs and corresponding benefits? Vendors don't implement according to the IETF standards now; what economic drivers that are ineffective getting compliance now will kick in to motivate them to support two-factored authentication if we write a standard that specifies it? If you can't provide solid justification for increasing the requirements above the RFC3411/USM level, I have trouble justifying committing resources to do so. As the network management architect of a vendor, I would need to sell such solutions to engineering, product management, and marketing and I would need to justify the resources it would take to offer such solutions. Customers continue to buy products from vendors that do not comply with IETf standards. You said yourself you need to buy the equipment, and cannot choose to buy only a compliant product. How will having these features in their products increase a vendors' sales? How will lack of these features hurt a vendors sales? I would have tremendous difficulty justifying the engineering expense of migrating from USM to a model that offers the features you want because I don't know what concrete benefits this migration would yield, and I wouldn't know how to market to our customers the benefits of having such features in our product lines. We can't even convince customers they need the increased security provided by USM and VACM. Can you help me understand how to justify moving from RFC3411/USM requirements to your specific requirements?=20 Thanks, David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric > Sent: Tuesday, March 01, 2005 4:46 PM > To: Ken Hornstein; isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS (fwd)=20 >=20 >=20 > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil] > >I think we all agree that from a _deployment_ perspective, > >USM's problem is Key Mangement (which is basically the root=20 > >of most of your above points). That's why we're here. But=20 > >strictly speaking, this is outside of the scope of the USM=20 > >_protocol_ (the USM RFC also specifies some of the USM key=20 > >management, so it's a bit confusing). Uri's talking about=20 > >the protocol; you're talking about the deployment/key management. =20 > >Can we all move on now? >=20 > Ken, >=20 > Actually, Uri was stating that enhancing Session management > alone would > meet the ISMS goals. While I agree that session management is=20 > needed, I > was arguing that we also need enhanced key management. I=20 > believe that my > arguments are consistent with the ISMS charter, which says (in part): > "The ISMS working group will focus on finding and identifying > a solution > for the first of the two above mentioned problems: creating a security > model for SNMPv3 that will meet the security and operational needs of > network administrators." If you concur, then we should move on. >=20 > However, I don't see how we can move on profitably until we > have defined > a common set of requirements and common set of criteria in order to > evaluate the three proposals. That is the view from my=20 > knothole. How do > Juergen and you propose that the WG proceed from this point?=20 > That is, I > don't see how the published agenda for the forthcoming IETF=20 > will enable > us to reach our March 5th milestone. Would you mind sharing with the > group how you expect that the WG to achieve that milestone?=20 >=20 > --Eric >=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 Wed Mar 2 02:41: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 CAA07882; Wed, 2 Mar 2005 02:41:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6OVH-000165-9X; Wed, 02 Mar 2005 02:42:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6OSF-0004Fg-6g; Wed, 02 Mar 2005 02:39:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6OSC-0004Fb-EJ for isms@megatron.ietf.org; Wed, 02 Mar 2005 02:39: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 CAA06695 for ; Wed, 2 Mar 2005 02:39:30 -0500 (EST) Received: from i9833.i.pppool.de ([85.73.152.51] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6OTI-0000z8-Py for isms@ietf.org; Wed, 02 Mar 2005 02:40:41 -0500 Received: by boskop.local (Postfix, from userid 501) id A116D1965A1; Wed, 2 Mar 2005 08:39:20 +0100 (CET) Date: Wed, 2 Mar 2005 08:39:20 +0100 From: =?unknown-8bit?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= To: "Fleischman, Eric" Subject: Re: [Isms] achieving market saturation with ISMS (fwd) Message-ID: <20050302073920.GA6618@boskop.local> Mail-Followup-To: "Fleischman, Eric" , ietfdbh@comcast.net, Ken Hornstein , isms@ietf.org References: <5B58696DB20B9140AD20E0685C573A6404FDDCD7@xch-nw-09.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCD7@xch-nw-09.nw.nos.boeing.com> User-Agent: Mutt/1.4i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 [...] Having read all these messages, I still believe we have a very simple situation. We have the following proposals on the table: a) Leave the USM protocol largely unchanged and add sessions, session keys and AAA support to it. (EUSM) b) Replace the USM protocol with a new security protocol which is designed to leverage already deployed keying protocols and potentially also session based security protocols. (TLSM is trying to leverage existing security protocols while SBSM is a new security protocol trying to interface to keying protocols if I got that right.) The point here is that depending on your environment, you either prefer a) over b) or b) over a). While I know what the answer would be for the environments I am working in, I do understand that other environments are simply different. In case the above reading of the state of affairs is true, we should IMHO work towards agreement on these two fundamentally different approaches and we should have a constructive dialog with the powers how to handle this situation. Arguing against each other just creates unnecessary heat and does not help us to move forward. /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 Mar 2 08:35: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 IAA10489; Wed, 2 Mar 2005 08:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6U1U-0000Zm-SO; Wed, 02 Mar 2005 08:36:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Tym-0007yf-1S; Wed, 02 Mar 2005 08:33:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Tyk-0007wn-KV for isms@megatron.ietf.org; Wed, 02 Mar 2005 08:33: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 IAA10400 for ; Wed, 2 Mar 2005 08:33:28 -0500 (EST) Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251] helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Tzt-0000XH-Fx for isms@ietf.org; Wed, 02 Mar 2005 08:34:42 -0500 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO00B704; 2 Mar 05 08:41:26 -0500 Received: from spooler by Lamicro.com (Mercury/32 v3.32); 2 Mar 05 08:41:23 -0500 Received: from connotech.com (209.71.204.116) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG00B703; 2 Mar 05 08:41:22 -0500 Message-ID: <4225C6DD.6070406@connotech.com> Date: Wed, 02 Mar 2005 08:59:57 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Subject: [Isms] A proposal related to the isms main concern about SNMP X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 1.3 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Dear isms wg members: This message provides some information about the main problem identified by this working group: According to the ISMS Proposal Comparison, "Key management with manual keying is extremely difficult in any system." (section 2.1) but "None of the proposals address this problem." (section 3.5). So our SAKEM procedure and technology (Secret Authentication Key Establishment Method) might be of interest to this working group members. See http://www.connotech.com/sakem_white_paper_06.htm and http://www.connotech.com/sakem_index.htm Sincerely, -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 11:41: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 LAA00250; Wed, 2 Mar 2005 11:41:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6WvX-0004oV-Vb; Wed, 02 Mar 2005 11:42:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Wse-0005fJ-Cb; Wed, 02 Mar 2005 11:39:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Wsb-0005fA-NP for isms@megatron.ietf.org; Wed, 02 Mar 2005 11:39: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 LAA00043 for ; Wed, 2 Mar 2005 11:39:17 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Wtf-0004lX-Ck for isms@ietf.org; Wed, 02 Mar 2005 11:40:34 -0500 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA15093; Wed, 2 Mar 2005 10:38:49 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j22GcmI23514; Wed, 2 Mar 2005 08:38:48 -0800 (PST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 08:38:48 -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] achieving market saturation with ISMS (fwd) Date: Wed, 2 Mar 2005 08:38:47 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCD9@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUe+vVWZml+07LQRr6IxhKhBigDtwAScE9A From: "Fleischman, Eric" To: X-OriginalArrivalTime: 02 Mar 2005 16:38:48.0086 (UTC) FILETIME=[4ED7BB60:01C51F46] X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Good summary, Juergen. The only change that I would suggest to it is = that option A should also include PKI and Kerberos support, which the = EUSM people said that they could also support.=20 -----Original Message----- From: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder = [mailto:j.schoenwaelder@iu-bremen.de]=20 Sent: Tuesday, March 01, 2005 11:39 PM To: Fleischman, Eric Cc: ietfdbh@comcast.net; Ken Hornstein; isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) [...] Having read all these messages, I still believe we have a very simple = situation. We have the following proposals on the table: a) Leave the USM protocol largely unchanged and add sessions, session keys and AAA support to it. (EUSM) b) Replace the USM protocol with a new security protocol which is=20 designed to leverage already deployed keying protocols and=20 potentially also session based security protocols. (TLSM is trying=20 to leverage existing security protocols while SBSM is a new=20 security protocol trying to interface to keying protocols if I got that right.) The point here is that depending on your environment, you either=20 prefer a) over b) or b) over a). While I know what the answer=20 would be for the environments I am working in, I do understand=20 that other environments are simply different. In case the above reading of the state of affairs is true, we should = IMHO work towards agreement on these two fundamentally different=20 approaches and we should have a constructive dialog with the powers=20 how to handle this situation. Arguing against each other just creates=20 unnecessary heat and does not help us to move forward. /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 Wed Mar 2 13:47: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 NAA13272; Wed, 2 Mar 2005 13:47:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Ytk-0007qW-Tg; Wed, 02 Mar 2005 13:48:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Yrz-0003dO-Ho; Wed, 02 Mar 2005 13:46:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Yry-0003d6-9e for isms@megatron.ietf.org; Wed, 02 Mar 2005 13:46: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 NAA13231 for ; Wed, 2 Mar 2005 13:46:46 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Yt9-0007p0-Ja for isms@ietf.org; Wed, 02 Mar 2005 13:48:04 -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 j22IkSt02897 for ; Wed, 2 Mar 2005 13:46:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJL4V3N>; Wed, 2 Mar 2005 13:46:29 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B079D3@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Date: Wed, 2 Mar 2005 13:46:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Isms] WG Consensus: Move forward with eUSM? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 hi I'm just catching back up with this and based on the mailing list and previous hallway discussions, as well as the recommendations of the evaluation team, is it then rough working group consensus to move forward with eUSM? This of course means to enhance it as necessary to nicely address the two issues identified in the charter (although I observe some of the discussions here have been about problems outside of the scope of this working group). Sharon Chisholm Nortel Networks Ottawa, Ontario Canada _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 15:51: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 PAA25160; Wed, 2 Mar 2005 15:51:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6apa-0002L9-7H; Wed, 02 Mar 2005 15:52:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6alx-0008Ff-Q3; Wed, 02 Mar 2005 15:48:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6alw-0008E3-0R for isms@megatron.ietf.org; Wed, 02 Mar 2005 15:48: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 PAA25066 for ; Wed, 2 Mar 2005 15:48:42 -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 1D6anA-0002Ij-9O for isms@ietf.org; Wed, 02 Mar 2005 15:50:00 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 8C4F811DBF8; Wed, 2 Mar 2005 12:48:37 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] ISMS Operational Scenario/Goal Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914A@MAANDMBX2.ets.enterasys.com> Date: Wed, 02 Mar 2005 12:48:37 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914A@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Mon, 28 Feb 2005 17:05:48 -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: 2.0 (++) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: 2.0 (++) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe >>>>> On Mon, 28 Feb 2005 17:05:48 -0500, "Nelson, David" said: >> To use SNMPv3/ISMS, the information that is needed is >> ONLY the IP address of the system to be managed, a user >> identity, proof of the user identity, and verifier or >> the identity of the managed system. An examples of this >> last part include the SSH fingerprint, or the CA cert >> of the managed system's cert. There SHOULD NEVER be >> a requirement that there be an IP address and/or key >> for a Radius server. They are not needed now for management >> via SSH or via a WEB browser. David> I think this is an {unfortunate | undesirable | mistaken} David> requirement. I specifically object to the notion that "the SSH David> fingerprint, or the CA cert of the managed system's cert" are David> acceptable configuration prerequisites but "the IP address David> and/or key for a Radius server" are not acceptable. That David> distinction "cooks the books" in terms of eliminating potential David> solutions from consideration. If you want to use just about any David> commercially deployed AAA client-server system, then the AAA David> clients will need to share pre-configured credentials with the David> AAA server. You have a choice: 1) require the user to install and configure security infrastructure they're currently not using, such as an AAA server they weren't previously using, or an AAA server with new extensions that aren't needed for anything but SNMP. 2) don't. David's argument (one I agree with) is merely that if you do #1 you aren't achieving the original goals set forth in the charter. IE, to reuse existing infrastructures. If you require them to do something, that's simply not reusing. I suspect that a good number of people in this community, however, feel that #1 is acceptable as long as the cost of doing so is low. My argument is that nobody wants to do SNMP. They do it because they have to. Putting anything in the way of them being able to merely means they'll want to use it even less. SNMP is a side technology that is only useful because other technologies exist and need to be managed. This isn't a negativism toward SNMP at all, it's merely a fact. SNMP exists because other things need to be managed. It would be useless by itself. And as such, users would rather everything never need management but they know this is impossible. If #2 was doable above, then they'd have to do a lot less to make use of the protocol that might help them manage their other technologies and thus you'll get quicker and greater adoption. David never said, nor will he ever if I know him well at all, that an AAA shouldn't ever be used as a possible source of authentication information for SNMP. He said it shouldn't be required, and it shouldn't be required to _modify_ it in order to make SNMP authentication happen. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 17:00: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 RAA02726; Wed, 2 Mar 2005 17:00:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bv0-0004Rc-DW; Wed, 02 Mar 2005 17:02:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6btW-0006Ok-Kz; Wed, 02 Mar 2005 17:00:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6btV-0006Oa-HG for isms@megatron.ietf.org; Wed, 02 Mar 2005 17:00:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02648 for ; Wed, 2 Mar 2005 17:00: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 1D6buk-0004Qo-5u for isms@ietf.org; Wed, 02 Mar 2005 17:01:54 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA12635 for ; Wed, 2 Mar 2005 17:01:01 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma012596; Wed, 2 Mar 05 17:00:51 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 02 Mar 2005 17:00:23 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 02 Mar 2005 17:00:23 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Mar 2005 17:00:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] ISMS Operational Scenario/Goal Date: Wed, 2 Mar 2005 17:00:22 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1915B@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS Operational Scenario/Goal Thread-Index: AcUfaTmhU2x/I9XJRjSpy3ZL6u0TBgAB0EjA From: "Nelson, David" To: "Wes Hardaker" X-OriginalArrivalTime: 02 Mar 2005 22:00:22.0975 (UTC) FILETIME=[3B7E24F0:01C51F73] 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:97.7826 ) 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: 2.0 (++) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: 2.0 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable Wes Hardaker writes... > 1) require the user to install and configure security infrastructure > they're currently not using, such as an AAA server they weren't > previously using, or an AAA server with new extensions that aren't > needed for anything but SNMP. If, in fact, we expect that the target customer for the work product of ISMS doesn't already use some form of AAA infrastructure today, I would tend to agree. If, in fact, the AAA server extensions required to support the work product of ISMS would not also support any other industry or IETF efforts (are not needed for anything but SNMP), I would tend to agree. It is not clear to me, currently, that either of these are true. More work needs to be done to make that determination, I think. =20 > David's argument (one I agree with) is merely that if you do #1 you > aren't achieving the original goals set forth in the charter. IE, to > reuse existing infrastructures. If you assume that AAA is an existing infrastructure... it's reuse. > If you require them to do something, that's simply not reusing. Well, there two levels of reusing. The first is reusing protocols and products (potentially via version upgrades) that have a wide market penetration. The second is using the exact protocols and exact products (product versions) that a particular customer has deployed now. I guess I was advocating the first definition. Trying to get new features, functionality and scalability without "doing something" is akin to the children's fable of Stone Soup. The premise of stone soup is that you can feed an entire village using only a cauldron, boiling water and field stones. The moral of this fable is that it really takes a bunch of other ingredients, vegetables, potatoes, meat, and such that the villagers are enticed to supply on the premise that the nutrition is coming from the stones, and the rest of the vittles are inconsequential "flavorings". Something from nothing. :-) > SNMP exists because other things need to be > managed. It would be useless by itself. And as such, users would > rather everything never need management but they know this is > impossible. I've always wanted to write that universal clairvoyance module to read the user's minds. :-) > If #2 was doable above, then they'd have to do a lot less > to make use of the protocol that might help them manage their other > technologies and thus you'll get quicker and greater adoption. Stone Soup! :-) > David never said, nor will he ever if I know him well at all, that an > AAA shouldn't ever be used as a possible source of authentication > information for SNMP. He said it shouldn't be required, and it > shouldn't be required to _modify_ it in order to make SNMP > authentication happen. AAA should not be required to use SNMP, as we know it today. I find it hard to envision, however, how the WG goals can be met without using some form of KDC/AAA server. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 17:02: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 RAA03039; Wed, 2 Mar 2005 17:02:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bx2-0004W3-7d; Wed, 02 Mar 2005 17:04:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6btZ-0006Op-QU; Wed, 02 Mar 2005 17:00:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6btW-0006Of-2g for isms@megatron.ietf.org; Wed, 02 Mar 2005 17: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 RAA02651 for ; Wed, 2 Mar 2005 17:00: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 1D6buj-0004Qn-Os for isms@ietf.org; Wed, 02 Mar 2005 17:01:55 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id A70B211DBF8; Wed, 2 Mar 2005 14:00:32 -0800 (PST) From: Wes Hardaker To: "Blumenthal, Uri" Subject: Re: [Isms] Clarifications about EUSM Organization: Sparta References: <3DEC199BD7489643817ECA151F7C5929C218A7@pysmsx401.amr.corp.intel.com> Date: Wed, 02 Mar 2005 14:00:32 -0800 In-Reply-To: <3DEC199BD7489643817ECA151F7C5929C218A7@pysmsx401.amr.corp.intel.com> (Uri Blumenthal's message of "Mon, 28 Feb 2005 15:35: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: 2409bba43e9c8d580670fda8b695204a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 >>>>> On Mon, 28 Feb 2005 15:35:04 -0500, "Blumenthal, Uri" said: Uri> We are not modifying USM - we're providing a "wrapper" for a Uri> security model. "We" being the people that don't want to right? It sounds like you're stating a requirement that USM must be not be changed, which isn't a conclusion the WG has come to yet. Uri> Like David H. said - we don't hear complaints that USM isn't secure Uri> enough (except from you, and maybe Wes). Or the 37/149 people that responded to my survey. However, don't read into this that I think it's a requirement that we must improve on the situation. It would be a nice to have if we can and don't have to sacrifice other more important things. I suspect that we can without sacrificing the more important goal of external authentication integration. Whether we choose too or not has yet to be decided by the WG yet. But please don't state that a conclusion has been made yet by the WG, because it hasn't. It's hopefully really close, but I don't believe the chairs have declared consensus one way or another yet. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 17:13: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 RAA04046; Wed, 2 Mar 2005 17:13:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6c7X-0004od-Rc; Wed, 02 Mar 2005 17:15:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c63-0000cC-ST; Wed, 02 Mar 2005 17:13:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c63-0000c4-68 for isms@megatron.ietf.org; Wed, 02 Mar 2005 17:13: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 RAA04010 for ; Wed, 2 Mar 2005 17:13:32 -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 1D6c7E-0004ng-RA for isms@ietf.org; Wed, 02 Mar 2005 17:14:52 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 15:29:18 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107734400"; d="scan'208"; a="230866479:sNHT21109784" 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 j22MDKZV003161; Wed, 2 Mar 2005 14:13:20 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.63]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYQ74009; Wed, 2 Mar 2005 14:13:18 -0800 (PST) Message-Id: <6.2.0.14.0.20050302140944.03efa630@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 02 Mar 2005 14:13:18 -0800 To: Wes Hardaker From: Kaushik Narayan Subject: Re: [Isms] ISMS Operational Scenario/Goal In-Reply-To: References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1914A@MAANDMBX2.ets.enterasys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 2.0 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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: 2.0 (++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be We have tried to follow the advice of the Evaluation Team by adding to the EUSM spec further details of how to use PKI and Kerberos for EUSM. By doing so, it should become clear to all that EUSM doesn't require the use of AAA. In the case where operators desire integration with AAA, we believe it is better to have that SNMP piggy-back on changes already needed/being developed for AAA for other protocols (e.g., 802.11), rather than developing a new SNMP-specific security protocol. regards, kaushik! At 12:48 PM 3/2/2005, Wes Hardaker wrote: > >>>>> On Mon, 28 Feb 2005 17:05:48 -0500, "Nelson, David" > said: > > >> To use SNMPv3/ISMS, the information that is needed is > >> ONLY the IP address of the system to be managed, a user > >> identity, proof of the user identity, and verifier or > >> the identity of the managed system. An examples of this > >> last part include the SSH fingerprint, or the CA cert > >> of the managed system's cert. There SHOULD NEVER be > >> a requirement that there be an IP address and/or key > >> for a Radius server. They are not needed now for management > >> via SSH or via a WEB browser. > >David> I think this is an {unfortunate | undesirable | mistaken} >David> requirement. I specifically object to the notion that "the SSH >David> fingerprint, or the CA cert of the managed system's cert" are >David> acceptable configuration prerequisites but "the IP address >David> and/or key for a Radius server" are not acceptable. That >David> distinction "cooks the books" in terms of eliminating potential >David> solutions from consideration. If you want to use just about any >David> commercially deployed AAA client-server system, then the AAA >David> clients will need to share pre-configured credentials with the >David> AAA server. > >You have a choice: > >1) require the user to install and configure security infrastructure > they're currently not using, such as an AAA server they weren't > previously using, or an AAA server with new extensions that aren't > needed for anything but SNMP. > >2) don't. > >David's argument (one I agree with) is merely that if you do #1 you >aren't achieving the original goals set forth in the charter. IE, to >reuse existing infrastructures. If you require them to do something, >that's simply not reusing. I suspect that a good number of people in >this community, however, feel that #1 is acceptable as long as the >cost of doing so is low. My argument is that nobody wants to do SNMP. >They do it because they have to. Putting anything in the way of them >being able to merely means they'll want to use it even less. SNMP is >a side technology that is only useful because other technologies exist >and need to be managed. This isn't a negativism toward SNMP at all, >it's merely a fact. SNMP exists because other things need to be >managed. It would be useless by itself. And as such, users would >rather everything never need management but they know this is >impossible. If #2 was doable above, then they'd have to do a lot less >to make use of the protocol that might help them manage their other >technologies and thus you'll get quicker and greater adoption. > >David never said, nor will he ever if I know him well at all, that an >AAA shouldn't ever be used as a possible source of authentication >information for SNMP. He said it shouldn't be required, and it >shouldn't be required to _modify_ it in order to make SNMP >authentication happen. > >-- >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 Mar 2 17:39: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 RAA06339; Wed, 2 Mar 2005 17:39:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cW6-0005Nb-0J; Wed, 02 Mar 2005 17:40:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cTT-000628-2I; Wed, 02 Mar 2005 17:37:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cTR-000613-Jv for isms@megatron.ietf.org; Wed, 02 Mar 2005 17:37: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 RAA06270 for ; Wed, 2 Mar 2005 17:37:42 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cUe-0005Lf-Tw for isms@ietf.org; Wed, 02 Mar 2005 17:39:02 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j22MbRcJ018963; Wed, 2 Mar 2005 14:37:27 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j22MbXNR030477; Wed, 2 Mar 2005 14:37:33 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j22MbX1d030472; Wed, 2 Mar 2005 14:37:33 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 2 Mar 2005 14:37:32 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] ISMS Operational Scenario/Goal In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1915B@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 HI, Please stick with an argument based on facts instead of stories, especially when the stories do not match the situation. On Wed, 2 Mar 2005, Nelson, David wrote: > Stone Soup! :-) > It seems like your argument is that the cost to define, code, and deploy a new SNMP security model with no changes to any existing security infrastructure, is more expensive than defining a new SNMP security model (that is similar to USM), and defining, coding, and deploying updates to the existing security models. Is that what you are saying? Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 17:45: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 RAA06835; Wed, 2 Mar 2005 17:45:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ccV-0005VL-Ej; Wed, 02 Mar 2005 17: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 1D6cYo-0007Dx-5d; Wed, 02 Mar 2005 17:43:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cYm-0007Ds-FM for isms@megatron.ietf.org; Wed, 02 Mar 2005 17: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 RAA06625 for ; Wed, 2 Mar 2005 17:43:13 -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 1D6ca1-0005S3-H0 for isms@ietf.org; Wed, 02 Mar 2005 17:44:33 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id RAA14377 for ; Wed, 2 Mar 2005 17:43:40 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma014374; Wed, 2 Mar 05 17:43:34 -0500 Received: from psmtp.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 02 Mar 2005 17:43:05 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 02 Mar 2005 17:43:05 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Mar 2005 17:43: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] ISMS Operational Scenario/Goal Date: Wed, 2 Mar 2005 17:43:00 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19160@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] ISMS Operational Scenario/Goal Thread-Index: AcUfeG8Tbf1QttL5Q4amrxJGWJx08wAAEmtQ From: "Nelson, David" To: "David T. Perkins" X-OriginalArrivalTime: 02 Mar 2005 22:43:01.0085 (UTC) FILETIME=[303EC0D0:01C51F79] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:84.0661 M:98.9607 P:95.9108 R:95.9108 S:67.2552 ) 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: quoted-printable David Perkins writes... > Please stick with an argument based on facts instead of > stories, especially when the stories do not match the > situation. I though it both apt and instructive. I'm sorry that you disagree. > It seems like your argument is that the cost to define, code, > and deploy a new SNMP security model with no changes to > any existing security infrastructure, is more expensive > than defining a new SNMP security model (that is similar > to USM), and defining, coding, and deploying updates to > the existing security models. Is that what you are saying? I don't think so, but I'm having difficulty understanding your sentence. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 18:01: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 SAA08059; Wed, 2 Mar 2005 18:01:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6crL-0005pd-Mo; Wed, 02 Mar 2005 18:02:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6co5-0000vq-0q; Wed, 02 Mar 2005 17:59:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6co3-0000vY-6s for isms@megatron.ietf.org; Wed, 02 Mar 2005 17:59: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 RAA07791 for ; Wed, 2 Mar 2005 17:58:59 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cpH-0005jy-66 for isms@ietf.org; Wed, 02 Mar 2005 18:00:20 -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 j22MwkcJ024285; Wed, 2 Mar 2005 14:58:46 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j22MwqZX002454; Wed, 2 Mar 2005 14:58:52 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j22MwqE5002450; Wed, 2 Mar 2005 14:58:52 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 2 Mar 2005 14:58:52 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Nelson, David" Subject: RE: [Isms] ISMS Operational Scenario/Goal In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E19160@MAANDMBX2.ets.enterasys.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 2.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: 2.0 (++) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 HI, On Wed, 2 Mar 2005, Nelson, David wrote: > > It seems like your argument is that the cost to define, code, > > and deploy a new SNMP security model with no changes to > > any existing security infrastructure, is more expensive > > than defining a new SNMP security model (that is similar > > to USM), and defining, coding, and deploying updates to > > the existing security models. Is that what you are saying? > > I don't think so, but I'm having difficulty understanding your sentence. Let me break it down for you.... Cost 1 consists of costs to: 1) define new SNMP security model 2) code new security model 3) deploy SNMP with new secuirty model 4) NOTE: no changes to existing security infrastructure Cost 2 consists of costs to: 1) define a new SNMP secuirty model that is similar to USM 2) code new secuirty model 3) deploy new secuirty model 4) define extensions to existing security infrastructure to support the new security model 5) code new extensions 6) deploy new security structure extensions So, are you saying that cost 1 is greater than cost 2? Did I leave out any significant cost items? Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 18:01: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 SAA08092; Wed, 2 Mar 2005 18:01:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6crQ-0005po-WC; Wed, 02 Mar 2005 18:02:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6coQ-0000xv-Dd; Wed, 02 Mar 2005 17:59:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6coP-0000xq-Ik for isms@megatron.ietf.org; Wed, 02 Mar 2005 17:59: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 RAA07807 for ; Wed, 2 Mar 2005 17:59:22 -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 1D6cpe-0005kb-Ot for isms@ietf.org; Wed, 02 Mar 2005 18:00:43 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 3BCF711DBF8; Wed, 2 Mar 2005 14:59:21 -0800 (PST) From: Wes Hardaker To: "Nelson, David" Subject: Re: [Isms] ISMS Operational Scenario/Goal Organization: Sparta References: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1915B@MAANDMBX2.ets.enterasys.com> Date: Wed, 02 Mar 2005 14:59:20 -0800 In-Reply-To: <2A5E4540D4D5934D9A1E7E0B0FDB2D69E1915B@MAANDMBX2.ets.enterasys.com> (David Nelson's message of "Wed, 2 Mar 2005 17:00:22 -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: e1e48a527f609d1be2bc8d8a70eb76cb 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: 4adaf050708fb13be3316a9eee889caa >>>>> On Wed, 2 Mar 2005 17:00:22 -0500, "Nelson, David" said: David> If you assume that AAA is an existing infrastructure... it's David> reuse. Right. I don't. That's my point! 60/149 people from my survey used radius. 43/149 people from my survey used tacacs+. Thus, I couldn't draw from those numbers that AAA was existing for all people. (note that there could be overlap in those figures, but why anyone would run both radius and tacas+ at the same time I'm not sure. I actually could check for overlaps if need be; (I looked at the first of my response files just to see how easy the grep would be to count. Interestingly enough the first file that I looked at contained both in use [and ssh and local-accounts]). David> Well, there two levels of reusing. The first is reusing David> protocols and products (potentially via version upgrades) that David> have a wide market penetration. The second is using the exact David> protocols and exact products (product versions) that a David> particular customer has deployed now. I guess I was advocating David> the first definition. There are definitely multiple levels, I agree. The more the better, though, is what I was arguing. If you could reuse something else without augmentation or modification that'd be better than reusing something else that may or may not be available everywhere. David> Stone Soup! :-) I don't buy your analogy I'm afraid. It doesn't fit in many ways. I'm not going to dive into it though, as I don't think it would be productive. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 19:50: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 TAA19098; Wed, 2 Mar 2005 19:50:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6eYm-0008Fk-UQ; Wed, 02 Mar 2005 19:51:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eX8-0008So-12; Wed, 02 Mar 2005 19:49:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eX7-0008Sg-43 for isms@megatron.ietf.org; Wed, 02 Mar 2005 19:49: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 TAA19069 for ; Wed, 2 Mar 2005 19:49:37 -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 1D6eYN-0008F7-7B for isms@ietf.org; Wed, 02 Mar 2005 19:50:59 -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 j230nV0l006000 for ; Thu, 3 Mar 2005 00:49:31 GMT Received: from fmsmsxvs040.fm.intel.com (fmsmsxvs040.fm.intel.com [132.233.42.124]) by fmsfmr101.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j230nJal021708 for ; Thu, 3 Mar 2005 00:49:31 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030216493028277 for ; Wed, 02 Mar 2005 16:49:30 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 16:49:30 -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); Wed, 2 Mar 2005 16:49:30 -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); Wed, 2 Mar 2005 19:49:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Wed, 2 Mar 2005 19:49:19 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C5E1A7@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUe+0cE/9KzWajFRsi0gl7ZjpRJ8AAjusvQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 03 Mar 2005 00:49:29.0628 (UTC) FILETIME=[DB5E85C0:01C51F8A] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable IMHO, while what you're saying is correct - it doesn't address the cause = of the problem. Thus it is difficult to properly address it. The issue is not whether USM is good or bad. The issue is what = capabilities are needed, that are currently missing, and what's a good = way to add them. I suggest that session establishment and teardown is = what's lacking now. Once that is in place - we can check what other = services (per-packet authentication, encryption, timeliness = verification) are present or missing, and act accordingly. Desire of modularity suggests that (like in all the other = security-related protocols) session establishment mechanisms are = separated from those actually protecting the traffic. It allows = interchanging on either level. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] = On Behalf Of J=C3=BCrgen Sch=C3=B6nw=C3=A4lder Sent: Wednesday, March 02, 2005 2:39 AM To: Fleischman, Eric Cc: isms@ietf.org Subject: Re: [Isms] achieving market saturation with ISMS (fwd) [...] Having read all these messages, I still believe we have a very simple situation. We have the following proposals on the table: a) Leave the USM protocol largely unchanged and add sessions, session keys and AAA support to it. (EUSM) b) Replace the USM protocol with a new security protocol which is=20 designed to leverage already deployed keying protocols and=20 potentially also session based security protocols. (TLSM is trying=20 to leverage existing security protocols while SBSM is a new=20 security protocol trying to interface to keying protocols if I got that right.) The point here is that depending on your environment, you either=20 prefer a) over b) or b) over a). While I know what the answer=20 would be for the environments I am working in, I do understand=20 that other environments are simply different. In case the above reading of the state of affairs is true, we should IMHO work towards agreement on these two fundamentally different=20 approaches and we should have a constructive dialog with the powers=20 how to handle this situation. Arguing against each other just creates=20 unnecessary heat and does not help us to move forward. /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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 21:09: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 VAA26578; Wed, 2 Mar 2005 21:09:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6fnl-0001Td-9R; Wed, 02 Mar 2005 21: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 1D6flz-00061G-Sw; Wed, 02 Mar 2005 21:09:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6flh-0005sd-N3 for isms@megatron.ietf.org; Wed, 02 Mar 2005 21:08: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 VAA26420 for ; Wed, 2 Mar 2005 21:08:47 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6fmw-0001OR-92 for isms@ietf.org; Wed, 02 Mar 2005 21:10:08 -0500 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id UAA15081; Wed, 2 Mar 2005 20:08:30 -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 j2328UE15635; Wed, 2 Mar 2005 20:08:30 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 18:08:29 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] achieving market saturation with ISMS (fwd) Date: Wed, 2 Mar 2005 18:08:29 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCE6@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] achieving market saturation with ISMS (fwd) Thread-Index: AcUe+0cE/9KzWajFRsi0gl7ZjpRJ8AAjusvQAAJqF8A= From: "Fleischman, Eric" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 03 Mar 2005 02:08:29.0747 (UTC) FILETIME=[E4B34830:01C51F95] 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 Good points, Uri.=20 I think we additionally need to, at a minimum, introduce the configuration option of explicitly obtaining/distributing SNMPv3 authentication keys by one or more widely deployed authentication infrastructures. I propose that the following authentication infrastructures shall (at a minimum) be required configuration alternatives for ISMS to support: Radius, Kerberos, PKI. Support for other authentication systems, in addition to these three, is desirable. I do not think that there is disagreement in the WG on any of the above. If there is, please let us know... :-) I would also like to propose that my other frequently enumerated requirements also be formally put on the table as being optional requirements, that should also be required if and only if the inclusion of each item on my list is not difficult to do for whatever proposal the ISMS WG ultimately decides to advance. -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 Sent: Wednesday, March 02, 2005 4:49 PM To: isms@ietf.org Subject: RE: [Isms] achieving market saturation with ISMS (fwd) IMHO, while what you're saying is correct - it doesn't address the cause of the problem. Thus it is difficult to properly address it. The issue is not whether USM is good or bad. The issue is what capabilities are needed, that are currently missing, and what's a good way to add them. I suggest that session establishment and teardown is what's lacking now. Once that is in place - we can check what other services (per-packet authentication, encryption, timeliness verification) are present or missing, and act accordingly. Desire of modularity suggests that (like in all the other security-related protocols) session establishment mechanisms are separated from those actually protecting the traffic. It allows interchanging on either level. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 2 23: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 XAA05596; Wed, 2 Mar 2005 23:09:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6hgE-0003is-Q8; Wed, 02 Mar 2005 23:11:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6hdh-00085I-94; Wed, 02 Mar 2005 23:08:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6hdJ-00082c-5U for isms@megatron.ietf.org; Wed, 02 Mar 2005 23:08: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 XAA05392 for ; Wed, 2 Mar 2005 23:08:13 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6heZ-0003gB-Lw for isms@ietf.org; Wed, 02 Mar 2005 23:09:37 -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 j23485cJ016003; Wed, 2 Mar 2005 20:08:05 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2348B93003045; Wed, 2 Mar 2005 20:08:11 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2348BnH003040; Wed, 2 Mar 2005 20:08:11 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Wed, 2 Mar 2005 20:08:10 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Fleischman, Eric" Subject: RE: [Isms] achieving market saturation with ISMS (fwd) In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDCE6@xch-nw-09.nw.nos.boeing.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: 082a9cbf4d599f360ac7f815372a6a15 HI, You left out local accounts and SSH key pairs, and TACACS+. Regards, /david t. perkins On Wed, 2 Mar 2005, Fleischman, Eric wrote: > Good points, Uri. > > I think we additionally need to, at a minimum, introduce the > configuration option of explicitly obtaining/distributing SNMPv3 > authentication keys by one or more widely deployed authentication > infrastructures. I propose that the following authentication > infrastructures shall (at a minimum) be required configuration > alternatives for ISMS to support: Radius, Kerberos, PKI. Support for > other authentication systems, in addition to these three, is desirable. > > I do not think that there is disagreement in the WG on any of the above. > If there is, please let us know... :-) > > I would also like to propose that my other frequently enumerated > requirements also be formally put on the table as being optional > requirements, that should also be required if and only if the inclusion > of each item on my list is not difficult to do for whatever proposal the > ISMS WG ultimately decides to advance. > > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] > Sent: Wednesday, March 02, 2005 4:49 PM > To: isms@ietf.org > Subject: RE: [Isms] achieving market saturation with ISMS (fwd) > > > IMHO, while what you're saying is correct - it doesn't address the cause > of the problem. Thus it is difficult to properly address it. > > The issue is not whether USM is good or bad. The issue is what > capabilities are needed, that are currently missing, and what's a good > way to add them. I suggest that session establishment and teardown is > what's lacking now. Once that is in place - we can check what other > services (per-packet authentication, encryption, timeliness > verification) are present or missing, and act accordingly. > > Desire of modularity suggests that (like in all the other > security-related protocols) session establishment mechanisms are > separated from those actually protecting the traffic. It allows > interchanging on either level. > > > _______________________________________________ > 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 Mar 3 01:22: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 BAA16978; Thu, 3 Mar 2005 01:22:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jkz-0006gE-CJ; Thu, 03 Mar 2005 01: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 1D6jjK-0004h5-1F; Thu, 03 Mar 2005 01:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jjF-0004gk-Tq for isms@megatron.ietf.org; Thu, 03 Mar 2005 01:22: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 BAA16906 for ; Thu, 3 Mar 2005 01:22:33 -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 1D6jkY-0006fd-AT for isms@ietf.org; Thu, 03 Mar 2005 01:23:55 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 9019D11DBF8; Wed, 2 Mar 2005 22:22:23 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Organization: Sparta Date: Wed, 02 Mar 2005 22:22:23 -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: 343d06d914165ffd9d590a64755216ca Subject: [Isms] design decisions in SBSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: c0aa019322dfce838bd8604f5a841b57 I thought I'd write down a quick history of how SBSM came about and the trade offs that were made when designing it. Many of the issues that are being discussed today were long ago thought about when putting together SBSM and although the working group may very well chose a different path at various decision points, I thought it would be helpful to at least outline how and why the SBSM draft came about. Additionally there has been a lot of discussion on the mailing list lately (yay) but since I was away in Japan at Apricot for a week I'm trying to catch up and I hope this message will summarize my views on a lot of the topics that have been discussed lately. The first realization, and the primary focus of the working group, was simply that a fair number of people weren't using SNMPv3 because it required them to use a different security infrastructure (USM accounts) than they had in their current deployed systems. This is long known, and is why ISMS was created in the first place. A much more subtle second point is that I believed (and I think I can safely say David believed) that if SNMP ever required another system they didn't have or required modifications to existing systems that it would result in less use of SNMP. As I've mentioned recently multiple times, SNMP is always a "secondary service" to the rest of the services on the box. SNMP is a service that you turn on out of necessity in order to help manage the other services. This isn't a bad thing, it's simply why SNMP exists. It exists to help support other services. But that means that if there is any barrier to being able to use SNMP, it'll make it harder for operators to turn on since they've already declared themselves "too busy" to manage anything else. Thus the 99% case transformation path, IMHO, from a box out of the box: A B C D E Open package Set up deploy Set up Turn on Get the box -> Features it -> on -> management -> SNMP was bought for network (SNMP) Certainly sometimes multiple parts of these steps may be combined. Especially when deploying new boxes into an existing network, it's likely that an existing configuration set that may combine steps B and D will be done at once. However, for new boxes with new features or new networks, I (we) believed that B would always be done first. What does B above entail? It requires a number of things. B.1 Creation of login accounts and/or changing of default administrator passwords. B.2 Creating other security services so that operators can log in remotely via telnet/ssh/whatever. This may require creating a host key, installing user public keys, creating local accounts, setting up radius, etc... B.3 Setting up configuration for the services they bought the box for. This could be router configuration, firewall rules, QoS handling, ... IE, the purpose of the box. This could be done either at a console or over the network using the security services set in B.2. If done over the console, B.2 may not be needed as what was done in B.1 was likely enough. Regardless, I believe that these steps would always result in a box with pre-existing security infrastructure. Requiring later than in step D above that SNMPv3 required additional security setup would mean a delay in the user's desire to do so. Fine-tuning firewall rules would be much more important than setting up a new security infrastructure. With SNMPv3/USM as is, D was required to be: D.1 set up USM names and keys/pass-phrases D.2 set up VACM access rights So, what needed to be done to remove either of these steps to increase the speed at which a user could get to point E would mean simply not doing them. To remove D.1 it would require relying completely on the services that had been set up in B.1 and B.2 above. Requiring any other infrastructure aside from what was already available meant that you couldn't completely remove D.1. You could potentially reduce the impact, but the step would always be there unless you were totally reliant on other services. My (our) goal was to eliminate D.1 entirely, which meant not just making USM deployment easier but eliminating it entirely from scope. I'll come back to this again in a minute as this was a major point behind many of the decisions that were later made. Another side note about removing the D.1 requirement: It means that you must at all times be able to fallback to whatever existing fallback mechanism was available. IE, if you offered radius but yet had to fall back to USM in times of trouble that means you haven't eliminated the D.1 step in setting up a network. Even if you were falling back to a single root-equivalent USM user, it means that user had to be set up and maintained. It is much more important, IMHO, to fall back to other security mechanisms that operators are already planning on relying on when network troubles are encountered. EG, if they're using radius generally but plan on falling back to local accounts or SSH in times of trouble, then to entirely eliminate D.1 the resulting solution to the problem must be able to handle this. D.2 (VACM setup) is impossible to remove entirely, as you don't want to grant access rights out of the box of course. David and I discussed this at length for a long time. He argued that we should do something to provision VACM records directly in the resulting solution. But I argued that we shouldn't tie them together both because a coupling was not needed, was not potentially wanted for all environments and would, worse,would delay the authentication half of the solution (the removal of D.1) from deployment since it would increase the work to be done. We both agreed, however, that something should be done in the future. (By the way, I think what was done in EUSM is a wonderful solution to the D.2 reduction problem. My only caveat is that it requires a central authorization infrastructure to do that distribution. Many will see this as a plus, however.). So given those requirements being the most important, the next step was to decide what authentication mechanisms were important. Dave and I had many discussions about that and never did come to a great agreement on which ones should be worked on first, etc. The WG discussions seem to be proceeding on similar lines. The ones that we considered fairly critical: local accounts ssh (the survey results weren't around at the time; this was mostly because we knew it was fairly popular and because netconf was going to mandate it as a transport so it seemed very wise to use it). radius x.509 ... Pretty much the list mirrored the list that we saw in the survey results. The fill-in-the-blanks from the survey showed a few others we forgot about, like LDAP. The problem with the list, of course, is that if you really want to accomplish D.1 from above (the complete reliance on other authentication infrastructures) it is very difficult to accommodate the entire list. The differences in operation between the two 3 alone are hugely different (local-accounts, ssh-keys, radius). [aside: another requirement not discussed much to date is that there was a desire to have the result to be transport independent. It should be usable over UDP, TCP, AAL5, ... Our clients make use of multiple transport types and limiting the security options they could pick from to a single or small set of transports seemed counter to their desires] So, when thinking about the best way to accommodate everything a number of things were considered. Some of the extensible mechanisms were considered (eg, EAP, SASL) but the issue with these were that none of them supported all of the above mechanisms. At the time, EAP mechanisms existed for doing local accounts, eg, but were not documented as such and people were told in the hallway that you could use OTP or GTC to accomplish that (I've now heard both from different people; I thought OTP was the only one that would work but I'd have to go re-read to trust either at this point. It's been too long). However, EAP looked like the best solution to accommodate as many as possible using an existing protocol. However, I never wanted to run it in parallel with SNMPv3. IE, when I was considering EAP I was only thinking about it potentially tunneled through the security parameters within the SNMPv3 packet. But at that point, you still need to deal with message protection for it since EAP itself doesn't provide for that (PEAP and EAP-TLS do and would have to be used). It would also require only key-generating mechanisms, of which few were in existence at the time. I never wanted to run it along side SNMPv3 simply because the architectural ramifications of dealing with that within an OS get to be very complex when trying to deal with portability, interaction with multiple software components, etc. I'll explain this in a separate message though as it's an entire topic in itself. However, EAP would likely never accommodate SSH authentication which was a large problem since both other NM schemes (netconf) were going to require it and it was very popular with operators. Thus in order to achieve complete reliance on existing deployed infrastructures, SSH support capability became a must. The other decision that occurred at this time and is related to the last paragraph is that of if nothing else was available that could make use of as much of the existing infrastructures as possible, the choice was to go with something like EAP and hope that in the future other EAP authentication mechanisms would begin to support the other popular security mechanisms. It was more important, in my mind at least, that we achieve deployment sooner rather than later and knowing the speed at which multiple IETF working groups have been known to manage to co-produce interacting frameworks to achieve a common good was, um, slow I decided it would be best to roll-our-own. This, I think, is the largest of the decisions that is different between my thinking and the other proposals. The reason behind it was solely to accommodate as many existing infrastructures (without change) as soon as possible. It offered the greatest flexibility but at a significant cost: that the protocol was going to have to be new. In order to mitigate that as much as possible, an existing known secure exchange protocol was selected to base the work off of. A number were considered, but SIGMA looked to be the best for multiple reasons: 1) It had been well analyzed 2) It had been proven secure (at least no one has countered the proof yet). 3) It offered identity protection, which wasn't a requirement but was a nice-to-have in my customers eyes. (and the survey results confirmed this saying with 86/149 saying it would be useful, 31/149 saying it wouldn't be, and 32/149 abstaining from answering). 4) It had been used in other protocols, although often in the alternate mode. 5) the number of packet exchanges to bring up a session was small However, even if that protocol was followed it doesn't prove that the specification following it would be clear of all potential mistakes. Certainly you can follow something known to be secure but make a mistake in applying it to your particular problem. Additionally, the order in which things happened in the new SBSM protocol (IE, the elements of procedure ordering) that were unrelated to the usage of the SIGMA exchange protocol would need to be analyzed. These problems were documented in the ID as problems with this particular solution direction. It is, by far, the biggest of the problems facing it. We've always admitted to that. To some, it may be an unacceptable path based on this downside. That is certainly a fair opinion, though I don't agree with it because I think the benefits in this case far exceed the problem space. The payoff for this route is nice. It is fairly easy to support multiple authentication systems and thus the achievable deployment would be potentially very large. It also required no interactions with other WGs, thus speeding the process along, and required no modifications to existing security infrastructure and their related protocols or software. That was the gain we wanted most. In order to reduce the potential problems with negotiation issues of unsupported features, the options being negotiated were limited to the bare minimum with no room for future feature creep (I expected complaints about this actually, but never got any). I was hoping to keep the list shorter than it is, but SNMP requires a number of things that aren't easily avoided (engineID exchange, for example, so the default contextEngineID can be discovered). The list functionally boiled down to engineID, replay windowing, message authentication type (SHA, MD5), message encryption type (DES, AES), key-exchange parameters, identity type, identity and proof of identity. There are not a bizzilion options to pick from, but some negotiation had to be done. Compression was added later. We did try and reuse existing mechanisms wherever possible. EG, the current USM HMAC forms (MD5 and SHA1) were reused as well as the current encryption types and modes. This was done to help limit the footprint of the new system as much as possible. (and anyone who had implemented the DH experimental mib likely already had DH around as well). The SBSM result is really divided into two parts. The first part, is described above, which is the creation of a session. The second part is how the real SNMP commands get sent over the session. Once the setup of a session had been accomplished and was done internally to the packet, the actual runtime information is very limited. It was reduced to the bare minimum as well and is quite short: the session identifier, the message sequence number, the authentication, encryption and compression parameters. The message authentication and encryption were treated as identically as possible to how USM does things. The USM format itself was not reused for various reasons. 1) real replay support was desired since SNMP is being used more and more in complex manners (see midcom) and since operators never write scripts [at least that I've seen] that make use of the test and increment counters. [I'm convinced that replay of things like TRAPs and INFORMs is a problem that merely hasn't reared its head yet. Even GETs I think shouldn't be replayed, but that's another argument]. 2) The session identifier needed to uniquely identify a session, not a user like the USM packet had in it. The session identifier was needed to uniquely identify the session properties (keys, for example). My point is writing most of the above is multi-fold: 1) Much of this is not well spelled out in the SBSM draft, and it should have been as it would have helped understanding. 2) If we're going to go forward with one solution, I wanted to make sure that the motivations behind why the choices that resulted in SBSM were made. The primary and strongest goal was to enable end-users to deploy SNMP with security without modifying and by completely reusing their existing authentication infrastructure. This is the most paramount goal of ISMS. Unfortunately, I think I might be in the minority in thinking that absolutely no changes to existing authentication infrastructures should be needed or that reusing existing security infrastructures is an absolute. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 03:55: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 DAA22101; Thu, 3 Mar 2005 03:55:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6m8u-0001SV-KQ; Thu, 03 Mar 2005 03:57:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6m6m-00058u-H8; Thu, 03 Mar 2005 03:55:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6m6V-000578-04 for isms@megatron.ietf.org; Thu, 03 Mar 2005 03:54: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 DAA21860 for ; Thu, 3 Mar 2005 03:54:41 -0500 (EST) Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6m7m-0001PP-F7 for isms@ietf.org; Thu, 03 Mar 2005 03:56:05 -0500 Received: from europa.office (europa.office [10.1.1.2]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 0341410B3B; Thu, 3 Mar 2005 09:56:09 +0100 (CET) Received: from [10.1.1.171] ([10.1.1.171]) by europa.office over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:54:29 +0100 Date: Thu, 03 Mar 2005 09:54:53 +0100 From: Juergen Quittek To: "David T. Perkins" , isms@ietf.org Subject: Re: [Isms] Agenda item Message-ID: In-Reply-To: References: X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-OriginalArrivalTime: 03 Mar 2005 08:54:29.0687 (UTC) FILETIME=[9C5B2470:01C51FCE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit The agenda has already been posted, but it is not a tight one. It should be no problem fitting in a 10 minutes presentation. I take this as first issue for agenda bashing. Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 01.03.2005 17:17 Uhr +0100 David T. Perkins wrote: > HI, > > I would like to add a 10 minute presentation about the > problems of the USM to the agenda. > > Thanks, > /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 Thu Mar 3 07:09: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 HAA14880; Thu, 3 Mar 2005 07:09:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6pAj-0006zA-9c; Thu, 03 Mar 2005 07:11:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6p9B-0000R1-Ls; Thu, 03 Mar 2005 07:09:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6p9A-0000Qr-Bo for isms@megatron.ietf.org; Thu, 03 Mar 2005 07:09: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 HAA14865 for ; Thu, 3 Mar 2005 07:09:37 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6pAV-0006yj-D6 for isms@ietf.org; Thu, 03 Mar 2005 07:11:04 -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 j23C9IJ02373 for ; Thu, 3 Mar 2005 07:09:18 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLVBJP>; Thu, 3 Mar 2005 07:09:19 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B07DE3@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] Agenda item Date: Thu, 3 Mar 2005 07:09:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) 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.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 hi Might I propose that it goes at the very end if there is time? It sounds like a request to add new work to the charter, unless Dave meant he was looking to raise some issues with eUSM (not USM) which he thought people should be aware of before we take consensus to move forward with a selected starting point to solve the two problems identified in the charter. Perhaps he could clarify. Sharon -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek Sent: Thursday, March 03, 2005 3:55 AM To: David T. Perkins; isms@ietf.org Subject: Re: [Isms] Agenda item The agenda has already been posted, but it is not a tight one. It should be no problem fitting in a 10 minutes presentation. I take this as first issue for agenda bashing. Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de --On 01.03.2005 17:17 Uhr +0100 David T. Perkins wrote: > HI, > > I would like to add a 10 minute presentation about the problems of the > USM to the agenda. > > Thanks, > /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 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 08:33:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22941; Thu, 3 Mar 2005 08:33:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qTn-0000Q0-Po; Thu, 03 Mar 2005 08:35:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOw-0003rF-GI; Thu, 03 Mar 2005 08:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOu-0003qh-FW for isms@megatron.ietf.org; Thu, 03 Mar 2005 08:30:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22667 for ; Thu, 3 Mar 2005 08:29:58 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qQG-0000LI-5o for isms@ietf.org; Thu, 03 Mar 2005 08:31:25 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D6qOi-0006LR-CI; Thu, 03 Mar 2005 08:29:48 -0500 Date: Thu, 3 Mar 2005 08:30:21 -0500 From: Robert Story To: "Sharon Chisholm" Subject: Re: [Isms] Agenda item Message-ID: <20050303083021.35723ea2@aud> In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402B07DE3@zcarhxm2.corp.nortel.com> References: <713043CE8B8E1348AF3C546DBE02C1B402B07DE3@zcarhxm2.corp.nortel.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit On Thu, 3 Mar 2005 07:09:09 -0500 Sharon wrote: SC> Might I propose that it goes at the very end if there is time? It sounds SC> like a request to add new work to the charter, unless Dave meant he was SC> looking to raise some issues with eUSM (not USM) If we are trying to provide something better than USM, then it would make sense to talk about the problems with USM, to make sure the new model doesn't suffer from any of the same problems... -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 09:09: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 JAA26270; Thu, 3 Mar 2005 09:09:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6r2O-0001IH-GT; Thu, 03 Mar 2005 09:10:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qz4-0001Ri-0l; Thu, 03 Mar 2005 09:07:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qz2-0001Rd-LD for isms@megatron.ietf.org; Thu, 03 Mar 2005 09:07: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 JAA25994 for ; Thu, 3 Mar 2005 09:07:18 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6r0O-0001Ep-OW for isms@ietf.org; Thu, 03 Mar 2005 09:08:46 -0500 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id 9F664284B2; Thu, 3 Mar 2005 06:31:27 -0800 (PST) To: Wes Hardaker Subject: Re: [Isms] design decisions in SBSM In-reply-to: Your message of "Wed, 02 Mar 2005 22:22:23 PST." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 03 Mar 2005 06:11:16 -0800 From: Eric Rescorla Message-Id: <20050303143127.9F664284B2@sierra.rtfm.com> 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 Wes Hardaker wrote: > The other decision that occurred at this time and is related to the > last paragraph is that of if nothing else was available that could > make use of as much of the existing infrastructures as possible, the > choice was to go with something like EAP and hope that in the future > other EAP authentication mechanisms would begin to support the other > popular security mechanisms. It was more important, in my mind at > least, that we achieve deployment sooner rather than later and knowing > the speed at which multiple IETF working groups have been known to > manage to co-produce interacting frameworks to achieve a common good > was, um, slow I decided it would be best to roll-our-own. This, I > think, is the largest of the decisions that is different between my > thinking and the other proposals. The reason behind it was solely to > accommodate as many existing infrastructures (without change) as soon > as possible. It offered the greatest flexibility but at a significant > cost: that the protocol was going to have to be new. This is really a striking argument because basically it comes down to "working with others is too much trouble". Yes, it certainly is easier to design something when you don't have people looking over your shoulder, but at least in the security area, it seems to take quite some time to get a new protocol right. We're *still* finding problems in IKEv2 and TLS, after 10 years. Is there any reason to believe that the same situation won't obtain with SBSM? > In order to > mitigate that as much as possible, an existing known secure exchange > protocol was selected to base the work off of. A number were > considered, but SIGMA looked to be the best for multiple reasons: > > 1) It had been well analyzed > 2) It had been proven secure (at least no one has countered the > proof yet). Wes, every time you've mentioned SIGMA you've mentioned that it's been proven secure. While this is certainly a nice to have, it really buys you a lot less than one would imagine. In particular, I strongly suspect that the proofs of security only hold when you're NOT composing it with a whole bunch of arbitrary authentication schemes with strengths that don't match the public key authentication schemes that SIGMA is based on. > However, even if that protocol was followed it doesn't prove that the > specification following it would be clear of all potential mistakes. > Certainly you can follow something known to be secure but make a > mistake in applying it to your particular problem. Additionally, the > order in which things happened in the new SBSM protocol (IE, the > elements of procedure ordering) that were unrelated to the usage of > the SIGMA exchange protocol would need to be analyzed. These problems > were documented in the ID as problems with this particular solution > direction. It is, by far, the biggest of the problems facing it. > We've always admitted to that. To some, it may be an unacceptable > path based on this downside. That is certainly a fair opinion, though > I don't agree with it because I think the benefits in this case far > exceed the problem space. > > The payoff for this route is nice. It is fairly easy to support > multiple authentication systems and thus the achievable deployment > would be potentially very large. I'm extremely skeptical of this claim. I hear you saying that it's easy to support multiple authentication systems but the current SBSM just has stub markers for where these authentication systems would in principle go if you were going to put them in. Both IKE and TLS have exactly the same kind of cutouts and yet every time we go to add a new form of authentication (by this I don't mean some new public key algorithm but rather something fundamentally new, like passwords) it takes years because the security properties of the composed protocol are not necessarily the same as the security properties of the individual protocols. I would also note that it's a little surprising that you claim that supporting multiple authentication mechanisms is a feature of designing a new protocol and yet your solution for supporting a number of them seems to be to punt the problem off to EAP: Although not defined yet, the EAP identification mechanism will support a number of important identification concepts missing from the previous mechanisms, such as Generic Token Card, One Time Password, and two factor authentication support. Doesn't this argue for just using EAP? The major argument you're making for designing a new protocol is time to market. I think you're dramatically underestimating the difficulty of getting a security protocol from -03 stage to finished stage. In my opinion, at this stage in the game it would be far easier to simply use IKE and add whatever authentication mechanisms it lacks that you think you need. This would have the advantage of giving you a protocol that actually does something and is standardized today and would let you leverage work that is *already* going on to add additional authentication mechanisms to IKE (see, for instance, draft-eronen-ipsec-ikev2-eap-auth). -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 09:21: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 JAA27561; Thu, 3 Mar 2005 09:21:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rDe-0001ZI-Of; Thu, 03 Mar 2005 09:22:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rB6-0004XZ-Is; Thu, 03 Mar 2005 09:19:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rB4-0004XU-Oh for isms@megatron.ietf.org; Thu, 03 Mar 2005 09:19: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 JAA27512 for ; Thu, 3 Mar 2005 09:19:45 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rCS-0001YE-8X for isms@ietf.org; Thu, 03 Mar 2005 09:21:12 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D6rB2-0006V6-RX; Thu, 03 Mar 2005 09:19:44 -0500 Date: Thu, 3 Mar 2005 09:20:18 -0500 From: Robert Story To: Eric Rescorla Subject: Re: [Isms] design decisions in SBSM Message-ID: <20050303092018.1379e434@aud> In-Reply-To: <20050303143127.9F664284B2@sierra.rtfm.com> References: <20050303143127.9F664284B2@sierra.rtfm.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit On Thu, 03 Mar 2005 06:11:16 -0800 Eric wrote: ER> Wes Hardaker wrote: ER> > It was more important, in my mind at ER> > least, that we achieve deployment sooner rather than later and knowing ER> > the speed at which multiple IETF working groups have been known to ER> > manage to co-produce interacting frameworks to achieve a common good ER> > was, um, slow I decided it would be best to roll-our-own. ER> ER> This is really a striking argument because basically it comes down to ER> "working with others is too much trouble". But I think it is a well-known problem within the IETF. If you tie your work to the output of another WG, and that WG gets bogged down in issues unrelated to what you need (or worse, the WG gets shut down), where does that leave you? ER> it seems to take quite some time to get a new protocol right. We're ER> *still* finding problems in IKEv2 and TLS, after 10 years. [...] ER> The major argument you're making for designing a new protocol is ER> time to market. I think you're dramatically underestimating the ER> difficulty of getting a security protocol from -03 stage to ER> finished stage. In my opinion, at this stage in the game it ER> would be far easier to simply use IKE and add whatever ER> authentication mechanisms it lacks that you think you need. I've had this same thought. The nice thing about IKE is that it is already defined. i.e. we don't have to worry about the WG getting shut down. And since IPv6 requires it, it's likely to already be available on lots of boxes... -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 09:22: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 JAA27767; Thu, 3 Mar 2005 09:22:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rFQ-0001bx-46; Thu, 03 Mar 2005 09:24:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rDe-00052C-Ur; Thu, 03 Mar 2005 09:22:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rDd-00051v-MN for isms@megatron.ietf.org; Thu, 03 Mar 2005 09:22: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 JAA27715 for ; Thu, 3 Mar 2005 09:22:24 -0500 (EST) Received: from sierra.rtfm.com ([198.144.203.251]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rEz-0001bC-Rt for isms@ietf.org; Thu, 03 Mar 2005 09:23:51 -0500 Received: from rtfm.com (romeo.rtfm.com [198.144.203.242]) by sierra.rtfm.com (Postfix) with ESMTP id D3F7E2857E; Thu, 3 Mar 2005 06:46:36 -0800 (PST) To: Robert Story Subject: Re: [Isms] design decisions in SBSM In-reply-to: Your message of "Thu, 03 Mar 2005 09:20:18 EST." <20050303092018.1379e434@aud> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 15) Date: Thu, 03 Mar 2005 06:26:25 -0800 From: Eric Rescorla Message-Id: <20050303144636.D3F7E2857E@sierra.rtfm.com> 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 Robert Story wrote: > On Thu, 03 Mar 2005 06:11:16 -0800 Eric wrote: > ER> Wes Hardaker wrote: > ER> > It was more important, in my mind at > ER> > least, that we achieve deployment sooner rather than later and knowing > ER> > the speed at which multiple IETF working groups have been known to > ER> > manage to co-produce interacting frameworks to achieve a common good > ER> > was, um, slow I decided it would be best to roll-our-own. > ER> > ER> This is really a striking argument because basically it comes down to > ER> "working with others is too much trouble". > > But I think it is a well-known problem within the IETF. If you tie your work to > the output of another WG, and that WG gets bogged down in issues unrelated to > what you need (or worse, the WG gets shut down), where does that leave you? Yes, but we also have plenty of cautionary tales about how we were just going to whip out this alternative protocol in no time and then years later... The good news in this case, however, is that both IKE and EAP are already in existence and do *something*, even if they don't have every single feature that you want. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 09:31: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 JAA29265; Thu, 3 Mar 2005 09:31:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rO9-0001u3-90; Thu, 03 Mar 2005 09:33:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rKW-0006Xw-04; Thu, 03 Mar 2005 09:29:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rKU-0006XC-Uv for isms@megatron.ietf.org; Thu, 03 Mar 2005 09:29: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 JAA28581 for ; Thu, 3 Mar 2005 09:29:29 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rLs-0001nb-5S for isms@ietf.org; Thu, 03 Mar 2005 09:30:56 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j23ETEj25337; Thu, 3 Mar 2005 09:29:14 -0500 (EST) Received: from [47.135.175.135] (47.135.175.135 [47.135.175.135]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FKG7HD4S; Thu, 3 Mar 2005 09:29:14 -0500 Mime-Version: 1.0 X-Mailer: SnapperMail 2.1.1.01 Site Licence by Snapperfish, www.snappermail.com Site licence: nortel networks To: "Robert Story" , "Sharon Chisholm" Subject: Re: [Isms] Agenda item Message-ID: <212-SnapperMsgDCDECA60BE4CCFB9@47.135.175.135> In-Reply-To: <20050303083021.35723ea2@aud> References: <713043CE8B8E1348AF3C546DBE02C1B402B07DE3@zcarhxm2.corp.nortel.com> <20050303083021.35723ea2@aud> From: Sharon Chisholm Date: Thu, 03 Mar 2005 9:29 -0500 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit The name of the working group is integrated security model - not improved. According to the charter, we are not trying to provide something better than USM. There are two really important problems outlined in the charter which we were suppose to have made a lot more progress on by now. I'd like to see us get back on track to solve those in a timely manner. Any other problem discussion should be framed in the context of a charter discussion Sharon ___ Sent with SnapperMail www.snappermail.com ...... Original Message ....... On Thu, 3 Mar 2005 08:30:21 -0500 "Robert Story" wrote: >On Thu, 3 Mar 2005 07:09:09 -0500 Sharon wrote: >SC> Might I propose that it goes at the very end if there is time? It sounds >SC> like a request to add new work to the charter, unless Dave meant he was >SC> looking to raise some issues with eUSM (not USM) > >If we are trying to provide something better than USM, then it would make sense >to talk about the problems with USM, to make sure the new model doesn't suffer >from any of the same problems... > >-- >Robert Story; NET-SNMP Junkie >Support: > >You are lost in a twisty maze of little standards, all different. > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:12: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 KAA03395; Thu, 3 Mar 2005 10:12:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s1B-0002kB-Nf; Thu, 03 Mar 2005 10:13:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rxG-0005Ey-ES; Thu, 03 Mar 2005 10:09:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rxE-0005Ef-Gg for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:09: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 KAA02989 for ; Thu, 3 Mar 2005 10:09:30 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ryb-0002gB-Do for isms@ietf.org; Thu, 03 Mar 2005 10:10:58 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D6rxB-0006er-3M; Thu, 03 Mar 2005 10:09:29 -0500 Date: Thu, 3 Mar 2005 10:10:02 -0500 From: Robert Story To: Sharon Chisholm Subject: Re: [Isms] Agenda item Message-ID: <20050303101002.7fbeee38@aud> In-Reply-To: <212-SnapperMsgDCDECA60BE4CCFB9@47.135.175.135> References: <713043CE8B8E1348AF3C546DBE02C1B402B07DE3@zcarhxm2.corp.nortel.com> <20050303083021.35723ea2@aud> <212-SnapperMsgDCDECA60BE4CCFB9@47.135.175.135> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Thu, 03 Mar 2005 9:29 -0500 Sharon wrote: SC> According to the charter, we are not trying to provide something better SC> than USM. There are two really important problems outlined in the charter SC> [...] The charter says we are "creating a security model for SNMPv3 that will meet the security and operational needs of network administrators." If USM doesn't meet those needs, and ISMS does, then I think that qualifies as 'better'. I think understanding why the existing security model does not meet these needs would be informative. 'Those who do not learn from the past are doomed to repeat it'. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:13: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 KAA03690; Thu, 3 Mar 2005 10:13:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s2G-0002n8-FN; Thu, 03 Mar 2005 10:14:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s0m-0006D8-S3; Thu, 03 Mar 2005 10:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s0l-0006D2-AG for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:13: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 KAA03635 for ; Thu, 3 Mar 2005 10:13:09 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s28-0002mj-6u for isms@ietf.org; Thu, 03 Mar 2005 10:14:37 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D6s0i-0006ft-FU; Thu, 03 Mar 2005 10:13:08 -0500 Date: Thu, 3 Mar 2005 10:13:42 -0500 From: Robert Story To: Eric Rescorla Subject: Re: [Isms] design decisions in SBSM Message-ID: <20050303101342.0794e7b1@aud> In-Reply-To: <20050303144636.D3F7E2857E@sierra.rtfm.com> References: <20050303092018.1379e434@aud> <20050303144636.D3F7E2857E@sierra.rtfm.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On Thu, 03 Mar 2005 06:26:25 -0800 Eric wrote: ER> > But I think it is a well-known problem within the IETF. If you tie your ER> > work to the output of another WG, and that WG gets bogged down in issues ER> > unrelated to what you need (or worse, the WG gets shut down), where does ER> > that leave you? ER> ER> Yes, but we also have plenty of cautionary tales about how we were just ER> going to whip out this alternative protocol in no time and then years ER> later... Heh. Also very true. ER> The good news in this case, however, is that both IKE and EAP are ER> already in existence and do *something*, even if they don't ER> have every single feature that you want. Right, though I'd lean more towards IKE, for the reasons I stated before. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:17: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 KAA04429; Thu, 3 Mar 2005 10:17:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s64-0002sy-NM; Thu, 03 Mar 2005 10:18:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s4A-0007aW-FS; Thu, 03 Mar 2005 10:16:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s49-0007aR-9m for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:16: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 KAA04342 for ; Thu, 3 Mar 2005 10:16:39 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s5V-0002rx-UE for isms@ietf.org; Thu, 03 Mar 2005 10:18:07 -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 j23FGS202863 for ; Thu, 3 Mar 2005 10:16:28 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLVGS8>; Thu, 3 Mar 2005 10:16:28 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B578C4@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] Agenda item Date: Thu, 3 Mar 2005 10:16:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: c1c65599517f9ac32519d043c37c5336 hi I think you (and others) are reading too much into this one sentence. The sentence is too ambiguous and should probably have been caught when the charter was drafted. I don't think it was intended as a blank check to solve whatever problems people thought would be interesting to solve. Integrating SNMPv3 security into existing infrastructure (and improving operational complexity) is the primary goal of this working group. I say solve that first and then look at 'me too' problems. Sharon -----Original Message----- From: Robert Story [mailto:rstory@freesnmp.com] Sent: Thursday, March 03, 2005 10:10 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: isms@ietf.org; Chisholm, Sharon [CAR:5K50:EXCH] Subject: Re: [Isms] Agenda item On Thu, 03 Mar 2005 9:29 -0500 Sharon wrote: SC> According to the charter, we are not trying to provide something SC> better SC> than USM. There are two really important problems outlined in the charter SC> [...] The charter says we are "creating a security model for SNMPv3 that will meet the security and operational needs of network administrators." If USM doesn't meet those needs, and ISMS does, then I think that qualifies as 'better'. I think understanding why the existing security model does not meet these needs would be informative. 'Those who do not learn from the past are doomed to repeat it'. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:24: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 KAA05376; Thu, 3 Mar 2005 10:24:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6sDA-00034J-9J; Thu, 03 Mar 2005 10:26:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s7m-0008PF-WA; Thu, 03 Mar 2005 10:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s7H-0008GN-Ty for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:19: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 KAA04831 for ; Thu, 3 Mar 2005 10:19:53 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s8e-0002wM-Pd for isms@ietf.org; Thu, 03 Mar 2005 10:21:22 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1D6s7E-0006hO-GG; Thu, 03 Mar 2005 10:19:52 -0500 Date: Thu, 3 Mar 2005 10:20:26 -0500 From: Robert Story To: Wes Hardaker Subject: Re: [Isms] design decisions in SBSM Message-ID: <20050303102026.61adbe0c@aud> In-Reply-To: References: X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit On Wed, 02 Mar 2005 22:22:23 -0800 Wes wrote: WH> A much more subtle second point is that I believed (and I think I can WH> safely say David believed) that if SNMP ever required another system WH> they didn't have or required modifications to existing systems that it WH> would result in less use of SNMP. I agree. WH> What does B [device setup] above entail? It requires a number of things. WH> WH> B.1 Creation of login accounts and/or changing of default WH> administrator passwords. I think this is the biggest single argument for making local accounts the 'must implement' system. It's universal, and doesn't require any external services. Not knowing much about RADIUS, can someone explain how it is different from local accounts, from the originators perspective? Doesn't the originator pass the same information to the device (userid/password)? -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:25: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 KAA05455; Thu, 3 Mar 2005 10:25:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6sE0-00035F-KU; Thu, 03 Mar 2005 10:26:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6sAU-0000TS-IP; Thu, 03 Mar 2005 10:23:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6sAT-0000TK-N6 for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:23: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 KAA05256 for ; Thu, 3 Mar 2005 10:23: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 1D6sBq-000324-Am for isms@ietf.org; Thu, 03 Mar 2005 10:24:39 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 6073A11DBF7; Thu, 3 Mar 2005 07:23:08 -0800 (PST) From: Wes Hardaker To: "Sharon Chisholm" Subject: Re: [Isms] Agenda item Organization: Sparta References: <713043CE8B8E1348AF3C546DBE02C1B402B578C4@zcarhxm2.corp.nortel.com> Date: Thu, 03 Mar 2005 07:23:08 -0800 In-Reply-To: <713043CE8B8E1348AF3C546DBE02C1B402B578C4@zcarhxm2.corp.nortel.com> (Sharon Chisholm's message of "Thu, 3 Mar 2005 10:16:22 -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: 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 >>>>> On Thu, 3 Mar 2005 10:16:22 -0500 , "Sharon Chisholm" said: Sharon> I think you (and others) are reading too much into this one Sharon> sentence. The sentence is too ambiguous and should probably Sharon> have been caught when the charter was drafted. I don't think Sharon> it was intended as a blank check to solve whatever problems Sharon> people thought would be interesting to solve. Integrating Sharon> SNMPv3 security into existing infrastructure (and improving Sharon> operational complexity) is the primary goal of this working Sharon> group. I say solve that first and then look at 'me too' Sharon> problems. Having helped write much of the charter, all the wording was fairly carefully written and reviewed both by the WG and the IESG members. The intent of the creation of the working group was to fix problems, and that included integration (most importantly) and other security issues (secondary). However, it is not a blank check as the wording says "meet the security and operational needs of network administrators". IE, you can't throw anything at it if it's not needed. That "needs" word in there is rather important. I don't think the WG has come to consensus on what is "needed" exactly however. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 10:46: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 KAA07784; Thu, 3 Mar 2005 10:46:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6sYR-0003X4-FM; Thu, 03 Mar 2005 10:47:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6sWm-0004qi-8Q; Thu, 03 Mar 2005 10:46:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6sWk-0004qS-Sm for isms@megatron.ietf.org; Thu, 03 Mar 2005 10:46: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 KAA07740 for ; Thu, 3 Mar 2005 10:46:12 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6sY6-0003WG-Pp for isms@ietf.org; Thu, 03 Mar 2005 10:47:41 -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 j23FjvM21664 for ; Thu, 3 Mar 2005 10:45:58 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1JJLVHXL>; Thu, 3 Mar 2005 10:45:57 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402B5793B@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] Agenda item Date: Thu, 3 Mar 2005 10:45:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 hi It still sounds like a loophole left in the charter to me. But, even by your accounts these additional 'improvements' are only a secondary priority but are what seem to be preventing the working group from moving forward. I would propose the following 1) Confirm that wg consensus and its charter is to address additional 'needs' as a secondary consideration in the solution 2) Very quickly determine what this minimal set of 'needs' is 3) Move forward with eUSM since it seems to be the best choice to meet the primary needs of the working group and see what changes are needed to address these secondary 'needs'. Sharon -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com] Sent: Thursday, March 03, 2005 10:23 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: isms@ietf.org Subject: Re: [Isms] Agenda item >>>>> On Thu, 3 Mar 2005 10:16:22 -0500 , "Sharon Chisholm" >>>>> said: Sharon> I think you (and others) are reading too much into this one Sharon> sentence. The sentence is too ambiguous and should probably have Sharon> been caught when the charter was drafted. I don't think it was Sharon> intended as a blank check to solve whatever problems people Sharon> thought would be interesting to solve. Integrating SNMPv3 Sharon> security into existing infrastructure (and improving operational Sharon> complexity) is the primary goal of this working group. I say Sharon> solve that first and then look at 'me too' problems. Having helped write much of the charter, all the wording was fairly carefully written and reviewed both by the WG and the IESG members. The intent of the creation of the working group was to fix problems, and that included integration (most importantly) and other security issues (secondary). However, it is not a blank check as the wording says "meet the security and operational needs of network administrators". IE, you can't throw anything at it if it's not needed. That "needs" word in there is rather important. I don't think the WG has come to consensus on what is "needed" exactly however. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 12:54: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 MAA24212; Thu, 3 Mar 2005 12:54:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uY0-0007HB-Ix; Thu, 03 Mar 2005 12:55:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uTA-0001PX-Hr; Thu, 03 Mar 2005 12:50:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uT9-0001PN-8N for isms@megatron.ietf.org; Thu, 03 Mar 2005 12:50: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 MAA23878 for ; Thu, 3 Mar 2005 12:50:36 -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 1D6uUY-0007BI-3T for isms@ietf.org; Thu, 03 Mar 2005 12:52:06 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j23HoTpn019756 for ; Thu, 3 Mar 2005 17:50:29 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 j23Ho6rs023393 for ; Thu, 3 Mar 2005 17:50:29 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030309502803609 for ; Thu, 03 Mar 2005 09:50:28 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:50: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); Thu, 3 Mar 2005 09:50: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); Thu, 3 Mar 2005 12:50:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Agenda item Date: Thu, 3 Mar 2005 12:50:15 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C5E51D@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Agenda item Thread-Index: AcUgCDc1JggoAGcHQt2eYytIQzCv3gABHA8A From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 03 Mar 2005 17:50:26.0875 (UTC) FILETIME=[7B88A0B0:01C52019] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 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: ff03b0075c3fc728d7d60a15b4ee1ad2 Content-Transfer-Encoding: quoted-printable IMHO, we need to: 1. Realize that most of "good" security protocols have two=20 [almost-]independent parts:=20 - establishment part that offers strong end-point authentication,=20 policy application, deciding upon the crypto algorithms to use, creation of dynamic Security Association, keys, etc. - traffic protection part, that simply takes one packet at a time and applies authentication, confidentiality and (optionally) freshness algorithms to it, with the keys provided by=20 establshment part. 2. Realize that current SNMPv3 USM security is essentially only the=20 2nd - i.e. traffic protection part. It is analogous to IPsec=20 with manually keyed SA (*not* IKE with manual keying!). 3. Realize that the "establishment part" can provide keys etc. to any traffic protection part, including USM. 4. Realize that USM can take keys from any "establishment part", including IKE and EAP. 5. Realize that if we pick a good existing protocol for the "establishment part" and design a nice interface to it (call it "Session Manager Model" :-), we may use any old or new "Security Model" with it.=20 My preference is IKEv2. I certainly can live with EAP. I want it cleanly separated from the actual traffic protection, so they are interchangeable. If that design is accepted - session establishment is clean, as packets requesting new session will carry Security Model tag that points at the "establishment" model (which in turn will invoke=20 IKE, or just run EAP encapsulated within). While the protected=20 SNMP traffic would carry the tag of "traffic" Security Model,=20 such as USM. IMHO, EUSM seems to head in this direction.=20 -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sharon Chisholm Sent: Thursday, March 03, 2005 10:46 AM To: isms@ietf.org Subject: RE: [Isms] Agenda item hi It still sounds like a loophole left in the charter to me. But, even by your accounts these additional 'improvements' are only a secondary priority but are what seem to be preventing the working group from moving forward.=20 I would propose the following 1) Confirm that wg consensus and its charter is to address additional 'needs' as a secondary consideration in the solution 2) Very quickly determine what this minimal set of 'needs' is 3) Move forward with eUSM since it seems to be the best choice to meet the primary needs of the working group and see what changes are needed to address these secondary 'needs'. Sharon -----Original Message----- From: Wes Hardaker [mailto:hardaker@tislabs.com]=20 Sent: Thursday, March 03, 2005 10:23 AM To: Chisholm, Sharon [CAR:5K50:EXCH] Cc: isms@ietf.org Subject: Re: [Isms] Agenda item >>>>> On Thu, 3 Mar 2005 10:16:22 -0500 , "Sharon Chisholm"=20 >>>>> said: Sharon> I think you (and others) are reading too much into this one=20 Sharon> sentence. The sentence is too ambiguous and should probably have Sharon> been caught when the charter was drafted. I don't think it was=20 Sharon> intended as a blank check to solve whatever problems people=20 Sharon> thought would be interesting to solve. Integrating SNMPv3=20 Sharon> security into existing infrastructure (and improving operational Sharon> complexity) is the primary goal of this working group. I say=20 Sharon> solve that first and then look at 'me too' problems. Having helped write much of the charter, all the wording was fairly carefully written and reviewed both by the WG and the IESG members. The intent of the creation of the working group was to fix problems, and that included integration (most importantly) and other security issues (secondary). However, it is not a blank check as the wording says "meet the security and operational needs of network administrators". IE, you can't throw anything at it if it's not needed. That "needs" word in there is rather important. I don't think the WG has come to consensus on what is "needed" exactly however. --=20 Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 14:12:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02865; Thu, 3 Mar 2005 14:12:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vlw-0000qM-86; Thu, 03 Mar 2005 14:14:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vhl-000056-7Z; Thu, 03 Mar 2005 14:09:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vhj-000050-Qh for isms@megatron.ietf.org; Thu, 03 Mar 2005 14:09: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 OAA02666 for ; Thu, 3 Mar 2005 14:09:46 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vj9-0000nC-3Q for isms@ietf.org; Thu, 03 Mar 2005 14:11:15 -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 j23J9b9s030023; Thu, 3 Mar 2005 11:09:37 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j23J9gxC001105; Thu, 3 Mar 2005 11:09:42 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j23J9fJ3001097; Thu, 3 Mar 2005 11:09:42 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 3 Mar 2005 11:09:41 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: "Blumenthal, Uri" Subject: RE: [Isms] Agenda item In-Reply-To: <3DEC199BD7489643817ECA151F7C5929C5E51D@pysmsx401.amr.corp.intel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 HI, URI, your summary outlines the approach that we have taken with the SBSM proposal. It seems like you believe that only EUSM "seems to head in this direction". Or maybe you were just giving an example. What is your view on whether or not the SBSM follows this approach? Note that if you have tried to deploy and use SNMPv3/USM, then you would really be troubled with the "freshness" (replay protection) that is used. It really causes problems with configuration for sending secured informs, and results in excesive network traffic. I'm not sure people realize these operational problems caused by USM's design. Since USM doesn't use sessions (or maybe you can say it has a really long session that is started with a user rekeying), that what was done was a somewhat reasonable approach. But with sessions, other approaches can be taken for replay protection that have much lower operational costs. Let me repeat the high level architecture that, I believe, describes the ideal solution: System A -------- System where management apps are run. User (or management daemon) has knowledge about the system(s) to be managed. Information to manage the system is a) an identifier for the managed system b) a transport address to use to send management traffic. (This may not be the address of the managed system because a proxy may be used.) c) a supported mechanism to prove the identity of the managed system. (Note, in USM, when proxy is used, the security relation is with the proxy and not the managed system.) d) an identity for the user or daeman and proof System B -------- The managed system. Has an identity, and proof. Has rules on how managers are authenticated. These may be based on manager identity, manager transport address, manager ingress interface, time of day, day of week, etc. The rules specify how to verify identity, such as use local accounts, use a Radius server, use a TACACS+ server, etc. For each external authenication server, there must be configuration set up. For example for each Radius server, it's IP address and shared secret must be configured. System C -------- A system that runs an authentication service. The service can be Radius, TACACS+, Kerberos, etc. The above is the classic diagram in the EAP specificatio, with system A being the "peer", system being the authenticator, and system C being the "backend authentication server". So, is this the architecture that you want, do do you want another? On Thu, 3 Mar 2005, Blumenthal, Uri wrote: > IMHO, we need to: > > 1. Realize that most of "good" security protocols have two > [almost-]independent parts: > > - establishment part that offers strong end-point authentication, > policy application, deciding upon the crypto algorithms to use, > creation of dynamic Security Association, keys, etc. > > - traffic protection part, that simply takes one packet at a time > and applies authentication, confidentiality and (optionally) > freshness algorithms to it, with the keys provided by > establshment part. > > 2. Realize that current SNMPv3 USM security is essentially only the > 2nd - i.e. traffic protection part. It is analogous to IPsec > with manually keyed SA (*not* IKE with manual keying!). > > 3. Realize that the "establishment part" can provide keys etc. to > any traffic protection part, including USM. > > 4. Realize that USM can take keys from any "establishment part", > including IKE and EAP. > > 5. Realize that if we pick a good existing protocol for the > "establishment part" and design a nice interface to it > (call it "Session Manager Model" :-), we may > use any old or new "Security Model" with it. > > My preference is IKEv2. I certainly can live with EAP. I want it > cleanly separated from the actual traffic protection, so they > are interchangeable. > > > If that design is accepted - session establishment is clean, as > packets requesting new session will carry Security Model tag that > points at the "establishment" model (which in turn will invoke > IKE, or just run EAP encapsulated within). While the protected > SNMP traffic would carry the tag of "traffic" Security Model, > such as USM. > > > IMHO, EUSM seems to head in this direction. > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 3 15:37:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13009; Thu, 3 Mar 2005 15:37:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6x6D-0002r5-Bh; Thu, 03 Mar 2005 15: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 1D6x3P-00073Q-Gj; Thu, 03 Mar 2005 15:36:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x3N-00072T-DM for isms@megatron.ietf.org; Thu, 03 Mar 2005 15:36: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 PAA12891 for ; Thu, 3 Mar 2005 15:36:11 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6x4m-0002pM-Sn for isms@ietf.org; Thu, 03 Mar 2005 15:37:42 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j23Ka29s016358 for ; Thu, 3 Mar 2005 12:36:02 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j23Ka8Nf022076 for ; Thu, 3 Mar 2005 12:36:08 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j23Ka8Gr022072 for ; Thu, 3 Mar 2005 12:36:08 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 3 Mar 2005 12:36:08 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: isms@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Isms] Managed system identity X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 HI, One of the details that we haven't gotten into is the identity that is used for the managed system. With SNMPv3/USM, this is an engineID. However, SNMP engineIDs are not used by existing security infrastructures. Which existing identifies should be used so that a management app can verify that it is communicating with the actual system and not a fake one? Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 05:17: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 FAA24372; Fri, 4 Mar 2005 05:17:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D79th-000670-Oy; Fri, 04 Mar 2005 05:19:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D79q3-0006d2-OH; Fri, 04 Mar 2005 05:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D79q1-0006cs-Ex for isms@megatron.ietf.org; Fri, 04 Mar 2005 05:15:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24155 for ; Fri, 4 Mar 2005 05:15:14 -0500 (EST) Received: from astro.systems.pipex.net ([62.241.163.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D79rZ-00063k-0X for isms@ietf.org; Fri, 04 Mar 2005 05:16:53 -0500 Received: from pc6 (1Cust33.tnt24.lnd4.gbr.da.uu.net [62.188.151.33]) by astro.systems.pipex.net (Postfix) with SMTP id D2B3EE0002F3; Fri, 4 Mar 2005 10:14:59 +0000 (GMT) Message-ID: <002e01c5209a$4bdaa580$0601a8c0@pc6> From: "Tom Petch" To: "David T. Perkins" References: Subject: Re: [Isms] ISMS Operational Scenario/Goal Date: Fri, 4 Mar 2005 10:09:54 +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: 2.1 (++) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.1 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Ah but cost to whom? Defining or amending a security model is a cost to us on this list. Coding a new security model is a cost to manufacturers of SNMP engines, 'managers' and 'agents' (who may be lurking on this list). Deploying is a cost to all those in the world who will use it from now until the end of its life. And has been pointed out, this community is not strongly represented on this list. When I was designing software, I was sadly ignorant of this last cost, which in any widely deployed system vastly outweighs the previous two costs (orders of magnitude was once suggested to me). So when I look at isms, I first think will it reuse all the effort that has been put into setting up roles, groups, users, secret info, management and logging of violations, etc etc perhaps at great cost over a long time in an existing, maybe not very network-oriented, security system? My reading of Wes' survey is that it is that that needs to be reused, not just a particular flavour of a particular existing protocol. So no, it is not a question of leaving out, rather of the different magnitude of items to different people. And I do see these considerations as part of the requirements of isms even though they do not appear in RFC3411. Tom Petch ----- Original Message ----- From: "David T. Perkins" To: "Nelson, David" Cc: Sent: Wednesday, March 02, 2005 11:58 PM Subject: RE: [Isms] ISMS Operational Scenario/Goal > On Wed, 2 Mar 2005, Nelson, David wrote: > > > > It seems like your argument is that the cost to define, code, > > > and deploy a new SNMP security model with no changes to > > > any existing security infrastructure, is more expensive > > > than defining a new SNMP security model (that is similar > > > to USM), and defining, coding, and deploying updates to > > > the existing security models. Is that what you are saying? > > > > I don't think so, but I'm having difficulty understanding your sentence. > > Let me break it down for you.... > > Cost 1 consists of costs to: > 1) define new SNMP security model > 2) code new security model > 3) deploy SNMP with new secuirty model > 4) NOTE: no changes to existing security infrastructure > > Cost 2 consists of costs to: > 1) define a new SNMP secuirty model that is similar to USM > 2) code new secuirty model > 3) deploy new secuirty model > 4) define extensions to existing security infrastructure to > support the new security model > 5) code new extensions > 6) deploy new security structure extensions > > So, are you saying that cost 1 is greater than cost 2? > > Did I leave out any significant cost items? > > Regards, > /david t. perkins > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 09:46: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 JAA24124; Fri, 4 Mar 2005 09:46:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7E6B-0004Ox-Rg; Fri, 04 Mar 2005 09:48:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7E2r-00030a-Jr; Fri, 04 Mar 2005 09:44:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7E2p-00030A-OS for isms@megatron.ietf.org; Fri, 04 Mar 2005 09:44: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 JAA23901 for ; Fri, 4 Mar 2005 09:44:45 -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 1D7E4P-0004L3-4r for isms@ietf.org; Fri, 04 Mar 2005 09:46:26 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 5BC1C11D7EB; Fri, 4 Mar 2005 06:44:37 -0800 (PST) From: Wes Hardaker To: Tom Petch Subject: Re: [Isms] ISMS Operational Scenario/Goal Organization: Sparta References: <002e01c5209a$4bdaa580$0601a8c0@pc6> Date: Fri, 04 Mar 2005 06:44:36 -0800 In-Reply-To: <002e01c5209a$4bdaa580$0601a8c0@pc6> (Tom Petch's message of "Fri, 4 Mar 2005 10:09:54 +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: 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 Fri, 4 Mar 2005 10:09:54 +0100, "Tom Petch" said: Tom> So no, it is not a question of leaving out, rather of the Tom> different magnitude of items to different people. You've defined 3 groups of people that would be affected by cost. Maybe analyzing each cost David P. proposed, and any that people feel he left out, by each group of people would show something? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 14:26: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 OAA23070; Fri, 4 Mar 2005 14:26:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ISl-0003e5-Mk; Fri, 04 Mar 2005 14:27:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7IPQ-0000T6-44; Fri, 04 Mar 2005 14:24:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7IPO-0000T1-0o for isms@megatron.ietf.org; Fri, 04 Mar 2005 14:24: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 OAA22845 for ; Fri, 4 Mar 2005 14:24:21 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7IR1-0003bl-Ex for isms@ietf.org; Fri, 04 Mar 2005 14:26:03 -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 j24JOE5F009291 for ; Fri, 4 Mar 2005 14:24:14 -0500 (EST) Message-Id: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> To: isms@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <22570.1109964241.0@cmf.nrl.navy.mil> Date: Fri, 04 Mar 2005 14:24:14 -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: 789c141a303c09204b537a4078e2a63f Subject: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 225414c974e0d6437992164e91287a51 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <22570.1109964241.1@cmf.nrl.navy.mil> Greetings all. Eric Fleischman had asked earlier on the mailing list how we (the WG chairs) expected to achieve our milestones since we weren't close to consensus on the proposals. I said that we were having a teleconference with our sheperding AD soon, and I wanted to wait until we had that teleconference until I said more. We had that teleconference today, and the results were surprising. Sam drafted the following note after the conference and has given me permission to forward his note to the mailing list. You can read his note below, but I'll summarize now: - EAP is not an appropriate protocol to use to authenticate SNMP, based on the EAP applicability statement (see sec 1.3 of RFC 3748). - His recommendation is to re-consider the evaluation of the propsals based on this new information. - The most productive route in his opinion is to consider solutions not based on EAP. - The delay caused by this won't be held against the working group. So .... where does that leave us? I'd like to hear from WG members, but to me this means we might want to restart the evaluation team process again. This would mean that the proposal authors would have another chance to change their proposals significantly to address objections raised by the evaluation team. But we don't necessarily have to do the evaluation team process again (I personally think it would be worthwhile to do the eval team process again). Anyway, I suspect it's going to be an interesting meeting in Minneapolis. I apologize to all WG participants, but due to work committments I won't be able to make it (I hope to participate via Jabber). --Ken ------- =_aaaaaaaaaa0 Content-Type: message/rfc822 Content-ID: <22570.1109964241.2@cmf.nrl.navy.mil> Content-Description: forwarded message Return-Path: Received: from luminous.mit.edu (LUMINOUS.MIT.EDU [18.101.1.61]) by ginger.cmf.nrl.navy.mil (8.12.11/8.12.11) with ESMTP id j24J196N008719 for ; Fri, 4 Mar 2005 14:01:10 -0500 (EST) Received: by luminous.mit.edu (Postfix, from userid 1000) id CA70B76E90; Fri, 4 Mar 2005 14:01:07 -0500 (EST) To: kenh@cmf.nrl.navy.mil, quittek@netlab.nec.de Cc: housley@vigilsec.com, david.kessens@nokia.com, bwijnen@lucent.com, hartmans-ietf@mit.edu Subject: Late Surprise: EAP is not appropriate for ISMS From: Sam Hartman Date: Fri, 04 Mar 2005 14:01:07 -0500 Message-ID: <87d5ufme18.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: (*) hits=1 X-Virus-Scanned: NAI Completed X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-UIDL: O79!!Ii6!!'8C"!:a_"! [Feel free to forward the following as appropriate.] Hi, Ken and Juergen. As we discussed on the phone today, I have run across what I believe is a stumbling block for the current ISMS work. I'm sorry that I did not notice this sooner; there has been a lot of information to assimilate as I've joined the IESG. It is my understanding that the ISMS review team recommended an approach based on the EUSM proposal. Part of this proposal depends on being able to use EAP for authontication. I'd like to draw your attention to the first part of the EAP applicability statement in section 1.3 of RFC 3748: 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. ISMS is not a network access application. the SNMP engines are not authenticating in order to gain access to the network. Instead ISMS is authenticating network management traffic. As such, it falls outside the scope of the EAP applicability statement. Multiple members of the IESG including myself would not like the see the scope of EAP expanded beyond its intended applicability. I have also received concerns from the EAP community about desires to use EAP beyond its intended scope. One question probably running through your mind is why don't we want EAP used as a general communications security/key exchange protocol. I don't know that we have a consensus answer on that question but I'm happy to share my personal answer. First, EAP is kind of complex. It has a feature set that is necessary for its current use cases, but it has a lot of complexity associated with the fact that it does not run over IP and that it is intended to support proxying through AAA servers. That complexity is not generally necessary for communications security. Also, EAP did not start off providing many security services; it started more as a message format for multi-round-trip exchanges. When appropriate, other protocols tend to provide communications security without some of the costs of EAP. In addition, the IETF has a large number of communications security protocols. When protocols like EAP are developed for specific purposes it is desirable to keep those protocols used for those specific purposes. What are these other protocols? Well, general application security is often accomplished with one or more of TLS, SASL, GSSAPI, or soon DTLS. In some cases, IPsec is an appropriate solution; I do not believe ISMS is such a case. It is my understanding that the netconf working group, which is in a similar space to ISMS supports the ssh protocol. Ssh does provide a good framework for this sort of thing. Kerberos is used by some people, although the Kerberos community would generally prefer that you use their protocol via GSSAPI or SASL rather than directly. I think the next step is to re-consider your evaluation of proposals in terms of this new information. Is EUSM still the best approach if you give up the dependence on EAP? What communications security protocols should be used instead? Considering solutions that do not depend on EAP is going to be more productive than arguing that the EAP applicability statement should be changed or that ISMS should be allowed to use EAP even though it falls outside the applicability statement. When you are done considering solutions, noting what attributes you lose by not using EAP would be useful. Also, if any important attributes are lost by not depending on EAP, please discuss those with me. Finally, I'd like to apologize for the delay that this news may cause. I realize that you were well on track to meet your March deadline. I also realize that any delay introduced by this message will be my fault and will not be held against the working group. Again, I'm sorry that I did not realize this situation sooner. ------- =_aaaaaaaaaa0 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 ------- =_aaaaaaaaaa0-- From isms-bounces@ietf.org Fri Mar 4 20:24:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28066; Fri, 4 Mar 2005 20:24:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7O3V-0003mt-3o; Fri, 04 Mar 2005 20:26:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7NzZ-0005Kt-B5; Fri, 04 Mar 2005 20:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7NzY-0005Ko-Cz for isms@megatron.ietf.org; Fri, 04 Mar 2005 20:22: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 UAA27915 for ; Fri, 4 Mar 2005 20:22:02 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7O1D-0003kT-77 for isms@ietf.org; Fri, 04 Mar 2005 20:23:48 -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 TAA11193; Fri, 4 Mar 2005 19:21:38 -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 j251LcE06709; Fri, 4 Mar 2005 19:21:38 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 17:21:36 -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] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Fri, 4 Mar 2005 17:21:36 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDCFA@xch-nw-09.nw.nos.boeing.com> Thread-Topic: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Thread-Index: AcUg7/RglDuXiuyiSjuQ+gnihmC9cwAMZp7A From: "Fleischman, Eric" To: "Ken Hornstein" , X-OriginalArrivalTime: 05 Mar 2005 01:21:36.0421 (UTC) FILETIME=[ACA74D50:01C52121] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: quoted-printable Would it be appropriate for the WG as a whole to officially articulate our requirements and evaluation criteria before the evaluation committee is formed? -----Original Message----- From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 Sent: Friday, March 04, 2005 11:24 AM To: isms@ietf.org Subject: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Greetings all. Eric Fleischman had asked earlier on the mailing list how we (the WG chairs) expected to achieve our milestones since we weren't close to consensus on the proposals. I said that we were having a teleconference with our sheperding AD soon, and I wanted to wait until we had that teleconference until I said more. We had that teleconference today, and the results were surprising. Sam drafted the following note after the conference and has given me permission to forward his note to the mailing list. You can read his note below, but I'll summarize now: - EAP is not an appropriate protocol to use to authenticate SNMP, based on the EAP applicability statement (see sec 1.3 of RFC 3748). - His recommendation is to re-consider the evaluation of the propsals based on this new information. - The most productive route in his opinion is to consider solutions not based on EAP. - The delay caused by this won't be held against the working group. So .... where does that leave us? I'd like to hear from WG members, but to me this means we might want to restart the evaluation team process again. This would mean that the proposal authors would have another chance to change their proposals significantly to address objections raised by the evaluation team. But we don't necessarily have to do the evaluation team process again (I personally think it would be worthwhile to do the eval team process again). Anyway, I suspect it's going to be an interesting meeting in Minneapolis. I apologize to all WG participants, but due to work committments I won't be able to make it (I hope to participate via Jabber). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 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 VAA05867; Fri, 4 Mar 2005 21:52:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7PQX-0005aY-5E; Fri, 04 Mar 2005 21:54:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7PNr-0001Tv-Ql; Fri, 04 Mar 2005 21:51:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7PNq-0001Tq-F5 for isms@megatron.ietf.org; Fri, 04 Mar 2005 21:51: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 VAA05753 for ; Fri, 4 Mar 2005 21:51:11 -0500 (EST) Received: from pop-a065c10.pas.sa.earthlink.net ([207.217.121.184]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7PPV-0005ZR-1J for isms@ietf.org; Fri, 04 Mar 2005 21:52:58 -0500 Received: from h-68-166-38-229.snvacaid.dynamic.covad.net ([68.166.38.229] helo=oemcomputer) by pop-a065c10.pas.sa.earthlink.net with smtp (Exim 3.33 #1) id 1D7PNj-0005wv-00 for isms@ietf.org; Fri, 04 Mar 2005 18:51:07 -0800 Message-ID: <002601c5212e$2e81d500$7f1afea9@oemcomputer> From: "Randy Presuhn" To: References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Fri, 4 Mar 2005 18:51:07 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Score: 2.9 (++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 2.9 (++) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Hi - > From: "Ken Hornstein" > To: > Sent: Friday, March 04, 2005 11:24 AM > Subject: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) ... I find it ironic that some of the reasons the AD gives for not wanting to use EAP (complexity resulting from operating over non-reliable transport, independence from IP, support for proxying, multi-step exchanges, etc.) all contribute to the most complex aspects of the SBSM proposal. If we can't use EAP, are we doomed to re-invent it? Randy _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 23:28: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 XAA12929; Fri, 4 Mar 2005 23:28:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Qvf-0007LS-Bv; Fri, 04 Mar 2005 23:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Qt5-00052i-0L; Fri, 04 Mar 2005 23:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Qrt-0004uZ-RG for isms@megatron.ietf.org; Fri, 04 Mar 2005 23:26: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 XAA12787 for ; Fri, 4 Mar 2005 23:26:19 -0500 (EST) Received: from dcn236-43.dcn.davis.ca.us ([168.150.236.43] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Qta-0007Ji-4O for isms@ietf.org; Fri, 04 Mar 2005 23:28:07 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 94A9D11D731; Fri, 4 Mar 2005 20:26:15 -0800 (PST) From: Wes Hardaker To: "Randy Presuhn" Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Organization: Sparta References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> Date: Fri, 04 Mar 2005 20:26:13 -0800 In-Reply-To: <002601c5212e$2e81d500$7f1afea9@oemcomputer> (Randy Presuhn's message of "Fri, 4 Mar 2005 18:51:07 -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: d185fa790257f526fedfd5d01ed9c976 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: c3a18ef96977fc9bcc21a621cbf1174b >>>>> On Fri, 4 Mar 2005 18:51:07 -0800, "Randy Presuhn" said: Randy> I find it ironic that some of the reasons the AD gives for not Randy> wanting to use EAP (complexity resulting from operating over Randy> non-reliable transport, independence from IP, support for Randy> proxying, multi-step exchanges, etc.) all contribute to the Randy> most complex aspects of the SBSM proposal. If we can't use Randy> EAP, are we doomed to re-invent it? I don't think you read the entire message. He suggested multiple alternatives. SASL is another complex but already existing exchange mechanism that has not been heavily discussed, but has in a few brief messages before (see my design considerations message from 2 days ago or so, or Ken Horstein's overview of SASL near the start of this mailing list). SASL is actually designed for application level authentication agreement transactions, unlike EAP. Choices going forward include: SBSM: + the most flexible from a authentication acceptance, because it could be made to do anything we wanted. o We'd have to be careful about not throwing everything possible in and to limit feature creep (see my previous message on design considerations) + Offered the most security from a feature perspective. - It'd be a new security protocol. + Offers transfer of SNMP specific information (default contextEngineID) Auth mechanisms include: As desired. Could include any of local accounts, ssh [for auth not protocol], X.509, AAA/radius, ... SASL: + Uses an extensible authentication mechanism... - ...though some popular operator choices would likely never be usable (eg, ssh). + Could probably be shoe-horned into USM. (Could also be made to use other SM formats, such as SBSMRunning) - Though the one problem that EUSM had which was likely going to cause problems was the key selection criteria (was a combination of user name and IP addr). This could likely be done by manipulating the user name field to select a key rather than a user. I've been meaning to write about this for some time and hopefully I'll get to it soon. - Would require a fair amount of new study to make session keying work like it would need to. o would require new packets to transfer SASL messages within SNMPv3 messages. [this is neither positive nor negative. Doing something in parallel like EAP did means a lot more inner-box complexity. Something else I've been meaning to write about...] - Could result in many round trips to bring up a session (but other proposals already suffered from this as well). o It's unknown if the default contextEngineID could be "discovered". Auth mechanisms include: Many. I'd have to look up the list again it's been too long since I read it. not ssh though. TLSM: + uses pre-existing secure transports. - Transports would have to bubble up a user name and a fair amount of study would be required to make that happen in all needed cases. - only a few mechanisms exist, namely TLS and SSH which are both TCP based. DTLS is "on the horizon" for UDP, but it likely eliminates any other transport types (ATM, ...) + SSH and TLS are popular with operators + Existing transports offer a lot of security (including anti-replay; the evaluation team left out discussion of the others that were previously discussed on the list and in the BOFs). - It's known that the default contextEngineID could not be "discovered". Auth mechanisms include: SSH, X.509, Accounts (and thus AAA/radius) We could certainly cook up more, but those are likely the most likely candidates. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 23:37:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13833; Fri, 4 Mar 2005 23:37:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R4Z-0007Wu-EJ; Fri, 04 Mar 2005 23:39:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R11-0005ov-0W; Fri, 04 Mar 2005 23:35:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R0z-0005oq-Co for isms@megatron.ietf.org; Fri, 04 Mar 2005 23:35: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 XAA13619 for ; Fri, 4 Mar 2005 23:35:42 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R2f-0007Sv-Nz for isms@ietf.org; Fri, 04 Mar 2005 23:37:31 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 36E0B17045; Fri, 4 Mar 2005 20:39:44 -0800 (PST) To: Wes Hardaker Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> From: Eric Rescorla Date: Fri, 04 Mar 2005 20:39:44 -0800 In-Reply-To: (Wes Hardaker's message of "Fri, 04 Mar 2005 20:26:13 -0800") Message-ID: <86acpi1zan.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Wes Hardaker writes: >>>>>> On Fri, 4 Mar 2005 18:51:07 -0800, "Randy Presuhn" said: > Choices going forward include: > > SBSM: ... > SASL: ... > TLSM: ... > We could certainly cook up more, but those are likely the most likely > candidates. IKE is conspicuously absent from this list. It strikes me as the most obvious candidate if you want to have a separate authentication/data transport strategy... -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 23:42: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 XAA14420; Fri, 4 Mar 2005 23:42:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R8v-0007gr-7i; Fri, 04 Mar 2005 23:43:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R6B-00075o-VR; Fri, 04 Mar 2005 23:41:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R69-00072o-PF for isms@megatron.ietf.org; Fri, 04 Mar 2005 23:41: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 XAA14301 for ; Fri, 4 Mar 2005 23:41:02 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R7q-0007e8-Bq for isms@ietf.org; Fri, 04 Mar 2005 23:42:50 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 2DC0517045; Fri, 4 Mar 2005 20:45:06 -0800 (PST) To: Wes Hardaker Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> From: Eric Rescorla Date: Fri, 04 Mar 2005 20:45:06 -0800 In-Reply-To: (Wes Hardaker's message of "Fri, 04 Mar 2005 20:26:13 -0800") Message-ID: <8665061z1p.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 I don't think I agree with all of your assessments below. Wes Hardaker writes: > SBSM: > + the most flexible from a authentication acceptance, because it > could be made to do anything we wanted. As can SASL, IKEv2, and TLS/DTLS. It's simply a matter of adding new mechanisms. Indeed, given that IKEv2, TLS, and SBSM all use more or less the same DH-style framework, I don't think that there's really any important difference here. > + Offered the most security from a feature perspective. I don't see that this is the case. What security features do you believe that SBSM offers that IKEv2 and TLS don't offer. > SASL: > + Uses an extensible authentication mechanism... > - ...though some popular operator choices would likely never be > usable (eg, ssh). Why? > TLSM: ... > - only a few mechanisms exist, namely TLS and SSH which are both TCP > based. DTLS is "on the horizon" for UDP, but it likely eliminates > any other transport types (ATM, ...) DTLS works fine over any datagram transport. It's not bound to UDP. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 23:51: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 XAA15255; Fri, 4 Mar 2005 23:51:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RI0-0007sg-16; Fri, 04 Mar 2005 23:53:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RFd-0000Uh-Mg; Fri, 04 Mar 2005 23:50:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RFK-0000UC-Ll for isms@megatron.ietf.org; Fri, 04 Mar 2005 23:50: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 XAA15213 for ; Fri, 4 Mar 2005 23:50: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 1D7RH2-0007re-1Z for isms@ietf.org; Fri, 04 Mar 2005 23:52:20 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 6ED8911D731; Fri, 4 Mar 2005 20:50:31 -0800 (PST) From: Wes Hardaker To: EKR Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Organization: Sparta References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <86acpi1zan.fsf@romeo.rtfm.com> Date: Fri, 04 Mar 2005 20:50:31 -0800 In-Reply-To: <86acpi1zan.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Fri, 04 Mar 2005 20:39:44 -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: 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 Fri, 04 Mar 2005 20:39:44 -0800, Eric Rescorla said: Eric> IKE is conspicuously absent from this list. It strikes me as Eric> the most obvious candidate if you want to have a separate Eric> authentication/data transport strategy... I don't, so color me biased. I'll explain that in a later message though. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 4 23:52: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 XAA15502; Fri, 4 Mar 2005 23:52:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RJP-0007vl-Ah; Fri, 04 Mar 2005 23:54:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RFa-0000UO-0n; Fri, 04 Mar 2005 23:50:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7REj-0000MI-3G for isms@megatron.ietf.org; Fri, 04 Mar 2005 23:49:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15192 for ; Fri, 4 Mar 2005 23:49:54 -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 1D7RGQ-0007rK-OA for isms@ietf.org; Fri, 04 Mar 2005 23:51:43 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id DA9E711D731; Fri, 4 Mar 2005 20:49:53 -0800 (PST) From: Wes Hardaker To: EKR Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Organization: Sparta References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <8665061z1p.fsf@romeo.rtfm.com> Date: Fri, 04 Mar 2005 20:49:53 -0800 In-Reply-To: <8665061z1p.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Fri, 04 Mar 2005 20:45:06 -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: a7d6aff76b15f3f56fcb94490e1052e4 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 >>>>> On Fri, 04 Mar 2005 20:45:06 -0800, Eric Rescorla said: >> + the most flexible from a authentication acceptance, because it >> could be made to do anything we wanted. Eric> As can SASL, IKEv2, and TLS/DTLS. It's simply a matter of adding Eric> new mechanisms. Indeed, given that IKEv2, TLS, and SBSM all Eric> use more or less the same DH-style framework, I don't think that Eric> there's really any important difference here. Agreed to some extent. Both SASL and EAP are extensible. But to add things to them means relying on a document likely to be produced in another WG. But you're right that we might be able to force that to happen. >> + Offered the most security from a feature perspective. Eric> I don't see that this is the case. What security features Eric> do you believe that SBSM offers that IKEv2 and TLS don't offer. I was assuming that the prevailing goal of many members of the WG would be to force whatever the outcome of the authentication would be into USM. IE, whatever SASL was made to do would be to generate keys for use via USM, where some of the other security features are then lost (such as anti-replay). >> SASL: >> + Uses an extensible authentication mechanism... >> - ...though some popular operator choices would likely never be >> usable (eg, ssh). Eric> Why? I'm betting that there wouldn't be a strong desire to make that happen. Color me wrong if it happens. I'd bet, however, that the drive will be lost by that point. I'd be very happy to be proven wrong however. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 00: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 AAA16336; Sat, 5 Mar 2005 00:03:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RTX-0008Js-3W; Sat, 05 Mar 2005 00:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RPA-0001s3-VV; Sat, 05 Mar 2005 00:00:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RP9-0001ry-KH for isms@megatron.ietf.org; Sat, 05 Mar 2005 00:00: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 AAA16130 for ; Sat, 5 Mar 2005 00:00:40 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RQq-0008FX-1q for isms@ietf.org; Sat, 05 Mar 2005 00:02:29 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id CE7001704D; Fri, 4 Mar 2005 21:04:43 -0800 (PST) To: Wes Hardaker Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <86acpi1zan.fsf@romeo.rtfm.com> From: Eric Rescorla Date: Fri, 04 Mar 2005 21:04:43 -0800 In-Reply-To: (Wes Hardaker's message of "Fri, 04 Mar 2005 20:50:31 -0800") Message-ID: <86y8d2znro.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Wes Hardaker writes: >>>>>> On Fri, 04 Mar 2005 20:39:44 -0800, Eric Rescorla said: > > Eric> IKE is conspicuously absent from this list. It strikes me as > Eric> the most obvious candidate if you want to have a separate > Eric> authentication/data transport strategy... > > I don't, so color me biased. I'll explain that in a later message though. Well, you may not think it's an obvious candidate, but I'd be interested to hear an argument that puts it totally out of the running... -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 00:06: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 AAA16730; Sat, 5 Mar 2005 00:06:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RWv-0008QI-Gy; Sat, 05 Mar 2005 00:08:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RTt-0002sF-IE; Sat, 05 Mar 2005 00:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RTq-0002qS-G1 for isms@megatron.ietf.org; Sat, 05 Mar 2005 00:05: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 AAA16613 for ; Sat, 5 Mar 2005 00:05:30 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RVW-0008Ng-6S for isms@ietf.org; Sat, 05 Mar 2005 00:07:19 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 1616517045; Fri, 4 Mar 2005 21:09:34 -0800 (PST) To: Wes Hardaker Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <8665061z1p.fsf@romeo.rtfm.com> From: Eric Rescorla Date: Fri, 04 Mar 2005 21:09:34 -0800 In-Reply-To: (Wes Hardaker's message of "Fri, 04 Mar 2005 20:49:53 -0800") Message-ID: <86u0nqznjl.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Wes Hardaker writes: >>>>>> On Fri, 04 Mar 2005 20:45:06 -0800, Eric Rescorla said: > >>> + the most flexible from a authentication acceptance, because it >>> could be made to do anything we wanted. > > Eric> As can SASL, IKEv2, and TLS/DTLS. It's simply a matter of adding > Eric> new mechanisms. Indeed, given that IKEv2, TLS, and SBSM all > Eric> use more or less the same DH-style framework, I don't think that > Eric> there's really any important difference here. > > Agreed to some extent. Both SASL and EAP are extensible. But to add > things to them means relying on a document likely to be produced in > another WG. But you're right that we might be able to force that to > happen. The reason why there's resistance to adding this sort of functionality is that it's technically tricky. It will be equally technically tricky with SBSM. >>> + Offered the most security from a feature perspective. > > Eric> I don't see that this is the case. What security features > Eric> do you believe that SBSM offers that IKEv2 and TLS don't offer. > > I was assuming that the prevailing goal of many members of the WG > would be to force whatever the outcome of the authentication would be > into USM. IE, whatever SASL was made to do would be to generate keys > for use via USM, where some of the other security features are then > lost (such as anti-replay). But this isn't an argument for SBSM over e.g. TLSM, because TLSM replaces USM and therefore *does* offer anti-replay. >>> SASL: >>> + Uses an extensible authentication mechanism... >>> - ...though some popular operator choices would likely never be >>> usable (eg, ssh). > > Eric> Why? > > I'm betting that there wouldn't be a strong desire to make that > happen. Color me wrong if it happens. I'd bet, however, that the > drive will be lost by that point. I'd be very happy to be proven > wrong however. I'm very uncomfortable with the argument that we're in so much of a hurry to avoid review by the WGs who are really tasked to design this kind of flexible security protocol that we should instead design something wholly new. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 00:19: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 AAA17522; Sat, 5 Mar 2005 00:19:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Rin-0000DL-7E; Sat, 05 Mar 2005 00:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Rfk-0004sR-C7; Sat, 05 Mar 2005 00:17:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Rfi-0004sM-Gf for isms@megatron.ietf.org; Sat, 05 Mar 2005 00:17: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 AAA17403 for ; Sat, 5 Mar 2005 00:17:47 -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 1D7RhP-0000BM-2h for isms@ietf.org; Sat, 05 Mar 2005 00:19:36 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j255HcvL022990 for ; Sat, 5 Mar 2005 05:17:38 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 j255HXS6008568 for ; Sat, 5 Mar 2005 05:17:38 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs040.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030421173804999 for ; Fri, 04 Mar 2005 21:17:38 -0800 Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 21:17:38 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Mar 2005 21:17:38 -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); Sat, 5 Mar 2005 00:17:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Sat, 5 Mar 2005 00:17:26 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C5EE88@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Thread-Index: AcUhPQDn+43g0TxwSBy0fO78XmGnqAAAen7w From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 05 Mar 2005 05:17:37.0219 (UTC) FILETIME=[A5259930:01C52142] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable >> Choices going forward include: >> >> SBSM: >>... >> SASL: >>... >> TLSM: >>... >> >> We could certainly cook up more, but those are likely the most likely >> candidates. > > IKE is conspicuously absent from this list. It strikes me as > the most obvious candidate if you want to have a separate > authentication/data transport strategy... IMHO, separation of authentication and data traffic protection is a-must. IKE is a well-analyzed Key Exchange protocol, whose entire job is to just authenticate end-points, agree on SA parameters and generate keys (not encumbered by other functionality). I would strongly object to re-inventing key exchange protocol. I'd strongly support a minimal explicit interface to something like IKE. I want to emphasize, that even INTEGRATING an EXISTING GOOD Key=20 Exchange protocol is non-trivial and tricky enough. > I was assuming that the prevailing goal of many members of the WG > would be to force whatever the outcome of the authentication would be > into USM.=20 I'd say it's the most convenient way. USM does well traffic integrity=20 and confidentiality. Replay protection is weaker - but it was a conscious decision based on inability to find reliable clocks and desire to avoid complicated and expensive re-synchronization, coupled with the nature of SNMP traffic (not a true "session" with good data flow, etc). I question, whether the reasons that prevented us from incorporating a better anti-replay into USM, still stand and will bug other models. > IE, whatever SASL was made to do would be to generate keys > for use via USM, where some of the other security features are then > lost (such as anti-replay). I'd be more interested to see an IKE-based mechanism to establish dynamic session=20 and feed it to USM, than to create an entirely new security model and spend=20 unpredictable time analyzing it. But again, SNMP architecture allows=20 for many security models - there's room for whatever you may need,=20 just design it and pay the vendors to code and offer it. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 01:22:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21758; Sat, 5 Mar 2005 01:22:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Shq-0001TQ-Uu; Sat, 05 Mar 2005 01:24:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Sed-00056e-Sa; Sat, 05 Mar 2005 01:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Sea-00056T-OI for isms@megatron.ietf.org; Sat, 05 Mar 2005 01:20: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 BAA21702 for ; Sat, 5 Mar 2005 01:20:43 -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 1D7SgI-0001S2-EJ for isms@ietf.org; Sat, 05 Mar 2005 01:22:31 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 7401B11D731; Fri, 4 Mar 2005 22:20:39 -0800 (PST) From: Wes Hardaker To: EKR Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Organization: Sparta References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <8665061z1p.fsf@romeo.rtfm.com> <86u0nqznjl.fsf@romeo.rtfm.com> Date: Fri, 04 Mar 2005 22:20:38 -0800 In-Reply-To: <86u0nqznjl.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Fri, 04 Mar 2005 21:09: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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f >>>>> On Fri, 04 Mar 2005 21:09:34 -0800, Eric Rescorla said: Eric> But this isn't an argument for SBSM over e.g. TLSM, because TLSM Eric> replaces USM and therefore *does* offer anti-replay. Never said otherwise. Or didn't mean to. Of the solutions, TLSM would be fine with me. I've stated that many times before. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 01:23:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21808; Sat, 5 Mar 2005 01:23:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Sj7-0001Ui-VD; Sat, 05 Mar 2005 01:25:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7SgL-0005GB-FB; Sat, 05 Mar 2005 01:22:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7SgG-0005ET-1b for isms@megatron.ietf.org; Sat, 05 Mar 2005 01:22: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 BAA21777 for ; Sat, 5 Mar 2005 01:22: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 1D7Shx-0001TU-Pz for isms@ietf.org; Sat, 05 Mar 2005 01:24:14 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 6A8E611D731; Fri, 4 Mar 2005 22:22:24 -0800 (PST) From: Wes Hardaker To: EKR Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Organization: Sparta References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> <86acpi1zan.fsf@romeo.rtfm.com> <86y8d2znro.fsf@romeo.rtfm.com> Date: Fri, 04 Mar 2005 22:22:24 -0800 In-Reply-To: <86y8d2znro.fsf@romeo.rtfm.com> (Eric Rescorla's message of "Fri, 04 Mar 2005 21:04:43 -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: cf4fa59384e76e63313391b70cd0dd25 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 >>>>> On Fri, 04 Mar 2005 21:04:43 -0800, Eric Rescorla said: Eric> Well, you may not think it's an obvious candidate, but I'd be Eric> interested to hear an argument that puts it totally out of the Eric> running... I don't think anything is out of the running at this point. That includes IKE. It wouldn't be my choice, but again I'll explain that later. I'll probably type it up Sunday on the plane... One nice advantage that IKE has over the rest of the other options is that it supports EAP! [joke] -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sat Mar 5 02:58: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 CAA19258; Sat, 5 Mar 2005 02:58:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7UCc-0003LJ-CB; Sat, 05 Mar 2005 02:59:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7U9u-0002SL-D9; Sat, 05 Mar 2005 02:57:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7U9r-0002SG-8x for isms@megatron.ietf.org; Sat, 05 Mar 2005 02: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 CAA19171 for ; Sat, 5 Mar 2005 02:57:05 -0500 (EST) Received: from i9f24.i.pppool.de ([85.73.159.36] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7UBZ-0003KY-E9 for isms@ietf.org; Sat, 05 Mar 2005 02:58:54 -0500 Received: by boskop.local (Postfix, from userid 501) id 1F8DE1DB4D7; Sat, 5 Mar 2005 08:56:51 +0100 (CET) Date: Sat, 5 Mar 2005 08:56:51 +0100 From: Juergen Schoenwaelder To: Wes Hardaker Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Message-ID: <20050305075651.GA15139@boskop.local> Mail-Followup-To: Wes Hardaker , Randy Presuhn , isms@ietf.org References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 On Fri, Mar 04, 2005 at 08:26:13PM -0800, Wes Hardaker wrote: > Choices going forward include: > > SBSM: > > SASL: > > TLSM: IKE ... The protocols that we actually use in production are TLS and SSH. We use a fair amount of SASL as well, but typically layered on top of TLS (even if that is seen to be broken). I am living in a world where people never have deployed USM and where people are likely to ignore any solution which requires anything they are not familiar with. This was the main reason to write TLSM - simply interface with what is out there rather doing something new. I do understand that other environments are different. I am just saying that for us, only a solution reusing TLS or SSH is likely to be ever considered and deployed. /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 Sun Mar 6 09:24: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 JAA11770; Sun, 6 Mar 2005 09:24:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7wiK-0003f0-FE; Sun, 06 Mar 2005 09:26:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7wfW-0000jE-Ha; Sun, 06 Mar 2005 09:23:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7wfV-0000j1-4x for isms@megatron.ietf.org; Sun, 06 Mar 2005 09:23: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 JAA11741 for ; Sun, 6 Mar 2005 09:23:38 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7whU-0003eJ-14 for isms@ietf.org; Sun, 06 Mar 2005 09:25:44 -0500 Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j26EN3Z23480; Sun, 6 Mar 2005 09:23:04 -0500 (EST) Received: from [47.102.176.66] (archt01z.us.nortel.com [47.102.176.66]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GFJ81TZN; Sun, 6 Mar 2005 09:23:03 -0500 Message-ID: <422B1244.1020907@nortel.com> Date: Sun, 06 Mar 2005 09:23:00 -0500 From: "Dondeti, Lakshminath" Organization: Nortel Networks User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Hornstein Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> In-Reply-To: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb 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: a8041eca2a724d631b098c15e9048ce9 Content-Transfer-Encoding: 7bit Hi Ken, I am sorry I could not respond to this earlier, but I think this was discussed earlier, in January; Bernard Aboba wrote a number of options to this list on how to use EAP with due nod to the RFC 3748 applicability statement. regards, Lakshminath I can't find his emails in the ISMS archive: ++++++++++++= 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. ++++++++++++ Ken Hornstein wrote: >Greetings all. > >Eric Fleischman had asked earlier on the mailing list how we (the WG >chairs) expected to achieve our milestones since we weren't close to >consensus on the proposals. I said that we were having a teleconference >with our sheperding AD soon, and I wanted to wait until we had that >teleconference until I said more. > >We had that teleconference today, and the results were surprising. Sam >drafted the following note after the conference and has given me permission >to forward his note to the mailing list. You can read his note below, >but I'll summarize now: > >- EAP is not an appropriate protocol to use to authenticate SNMP, based > on the EAP applicability statement (see sec 1.3 of RFC 3748). >- His recommendation is to re-consider the evaluation of the propsals > based on this new information. >- The most productive route in his opinion is to consider solutions not > based on EAP. >- The delay caused by this won't be held against the working group. > >So .... where does that leave us? > >I'd like to hear from WG members, but to me this means we might want to >restart the evaluation team process again. This would mean that the >proposal authors would have another chance to change their proposals >significantly to address objections raised by the evaluation team. But >we don't necessarily have to do the evaluation team process again (I >personally think it would be worthwhile to do the eval team process >again). > >Anyway, I suspect it's going to be an interesting meeting in Minneapolis. >I apologize to all WG participants, but due to work committments I won't >be able to make it (I hope to participate via Jabber). > >--Ken > > > > > ------------------------------------------------------------------------ > > Subject: > Late Surprise: EAP is not appropriate for ISMS > From: > Sam Hartman > Date: > Fri, 04 Mar 2005 14:01:07 -0500 > To: > kenh@cmf.nrl.navy.mil, quittek@netlab.nec.de > > To: > kenh@cmf.nrl.navy.mil, quittek@netlab.nec.de > CC: > housley@vigilsec.com, david.kessens@nokia.com, bwijnen@lucent.com, > hartmans-ietf@mit.edu > > >[Feel free to forward the following as appropriate.] > > > >Hi, Ken and Juergen. As we discussed on the phone today, I have run >across what I believe is a stumbling block for the current ISMS work. >I'm sorry that I did not notice this sooner; there has been a lot of >information to assimilate as I've joined the IESG. > >It is my understanding that the ISMS review team recommended an >approach based on the EUSM proposal. Part of this proposal depends on >being able to use EAP for authontication. > >I'd like to draw your attention to the first part of the EAP >applicability statement in section 1.3 of RFC 3748: > > 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. > >ISMS is not a network access application. the SNMP engines are not >authenticating in order to gain access to the network. Instead ISMS >is authenticating network management traffic. As such, it falls >outside the scope of the EAP applicability statement. > >Multiple members of the IESG including myself would not like the see >the scope of EAP expanded beyond its intended applicability. I have >also received concerns from the EAP community about desires to use EAP >beyond its intended scope. > >One question probably running through your mind is why don't we want >EAP used as a general communications security/key exchange protocol. >I don't know that we have a consensus answer on that question but I'm >happy to share my personal answer. First, EAP is kind of complex. It >has a feature set that is necessary for its current use cases, but it >has a lot of complexity associated with the fact that it does not run >over IP and that it is intended to support proxying through AAA >servers. That complexity is not generally necessary for >communications security. Also, EAP did not start off providing many >security services; it started more as a message format for >multi-round-trip exchanges. When appropriate, other protocols tend to >provide communications security without some of the costs of EAP. In >addition, the IETF has a large number of communications security >protocols. When protocols like EAP are developed for specific >purposes it is desirable to keep those protocols used for those >specific purposes. > >What are these other protocols? Well, general application security is >often accomplished with one or more of TLS, SASL, GSSAPI, or >soon DTLS. In some cases, IPsec is an appropriate solution; I do not >believe ISMS is such a case. It is my understanding that the netconf >working group, which is in a similar space to ISMS supports the ssh >protocol. Ssh does provide a good framework for this sort of thing. >Kerberos is used by some people, although the Kerberos community would >generally prefer that you use their protocol via GSSAPI or SASL rather >than directly. > >I think the next step is to re-consider your evaluation of proposals >in terms of this new information. Is EUSM still the best approach if >you give up the dependence on EAP? What communications security >protocols should be used instead? > >Considering solutions that do not depend on EAP is going to be more >productive than arguing that the EAP applicability statement should be >changed or that ISMS should be allowed to use EAP even though it falls >outside the applicability statement. When you are done considering >solutions, noting what attributes you lose by not using EAP would be >useful. Also, if any important attributes are lost by not depending >on EAP, please discuss those with me. > > >Finally, I'd like to apologize for the delay that this news may cause. >I realize that you were well on track to meet your March deadline. I >also realize that any delay introduced by this message will be my >fault and will not be held against the working group. Again, I'm >sorry that I did not realize this situation sooner. > > > > > >------------------------------------------------------------------------ > >_______________________________________________ >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 Sun Mar 6 21:13: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 VAA24325; Sun, 6 Mar 2005 21:13:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D87mY-0004fl-0W; Sun, 06 Mar 2005 21:15:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87k8-0001oL-6W; Sun, 06 Mar 2005 21:13:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D87k6-0001oD-Mn for isms@megatron.ietf.org; Sun, 06 Mar 2005 21:13: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 VAA24268 for ; Sun, 6 Mar 2005 21:13:07 -0500 (EST) Received: from wireless-130-129-133-143.ietf62.ietf.org ([130.129.133.143] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D87mB-0004eq-LD for isms@ietf.org; Sun, 06 Mar 2005 21:15:20 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 8123E11D724; Sun, 6 Mar 2005 18:13:08 -0800 (PST) From: Wes Hardaker To: isms@ietf.org Date: Sun, 06 Mar 2005 13:32:23 -0800 Organization: Sparta 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.7 (/) X-Scan-Signature: a743e34ab8eb08259de9a7307caed594 Subject: [Isms] Parallel vs in-band session setup. X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: ff0adf256e4dd459cc25215cfa732ac1 As David P. has pointed out, every solution to date has talked about the establishment of a session so I'm going to use that terminology within, even though I'm not referring just to the SBSM protocol. There are a number of ways to begin a session and establish the necessary runtime parameters to make use of the session establishment results. The fundamental task ISMS is targeted with is the establishment of at least keying information, regardless if that keying information is to be used by USM or another security model. For this discussion, I'm only going to talk about the session setup aspect regardless of what information will be set up there. We will assume at least keying, however, though likely things like a session ID or some other key material identify identifier and potentially other properties might be needed in a full scenario. The comparison document did a good job discussing the architectures produced by the various solutions, but didn't discuss much of the system ramifications of each of these architectures. Here's a recap of the architectures that will be useful for this message: 2.4.1 USM and 2.4.3 SBSM [Figure 1/4] [These are functionally very similar diagrams, so I'm only including one. The fundamental point behind them is that they are direct and integrated within the protocol itself] +----------------------+ +----------------------+ | Manager | | Managed | | Computer | | Device | | +------------------+ | | +------------------+ | | | SNMP Engine | | | | SNMP Engine | | | | | | | | | | | | | | <------> | | | | | | +-----+ +------+ | | | | +------+ +-----+ | | | | | USM | | SBSM | | | | | | SBSM | | USM | | | | | +-----+ +------+ | | | | +------+ +-----+ | | | +------------------+ | | +------------------+ | +----------------------+ +----------------------+ 2.4.4 Transport-Layer Security Model [TLSM; Figure 5] +------------------------+ +------------------------+ | Manager | | Managed | | Computer | | Device | | +--------------------+ | | +--------------------+ | | | SNMP Engine | | | | SNMP Engine | | | | | | | | | | | | | | <- - - - - -> | | | | | | +------+ +-------+ | | | | +-------+ +------+ | | | | | TLSM | | USM | | | | | | USM | | TLSM | | | | | +------+ +-------+ | | | | +-------+ +------+ | | | +----^---------------+ | | +-----^--------------+ | | | | | | | | +----v---------------+ | | +-----v--------------+ | | | Security layer | | <-----------> | | Security layer | | | +--------------------+ | | +--------------------+ | +------------------------+ +------------------------+ 2.4.2 External User Security Model [EUSM, figure 2] +------------------------+ +----------------------+ | Manager | | Managed | | Computer | | Device | | | | | | +---------+ | | +--------+ | | | Session | | Session establish | | Session| | | | Mgmt | |<----------------->| | Mgmt | | | +---------+ | | +--------+ | | ^ | | ^ | | +---------------|----+ | | +---|--------------+ | | | SNMP Engine | | | | | | SNMP Engine | | | | | | | Message traffic | | | | | | | v | | <---------------> | | v | | | | +-------+ | | | | +-------+ | | | | | USM | | | | | | USM | | | | | +-------+ | | | | +-------+ | | | +--------------------+ | | +------------------+ | +------------------------+ +----------------------+ [Editorial note: I changed "key establish" to "session establish" in the above diagram, as we have not yet decided that only keying information is needed. IE, I'm using "session establishment" in a way that includes "key establishment" but is not limited to just key negotiation.] One key difference in all of these diagrams is important to understand. Specifically, whether keying and session setup is passed directly within the communication "path". In USM and SBSM everything is done by the security model. In TLSM, it is done by a lower layer within the stack, but none the less is done over the same transport domain/address that will be used to fundamentally communicate over after the session has been set up. However, in EUSM and any replacements that involve parallel establishment of session and keying information, this establishment is manipulated over a separate transport domain/address which means that internally to the box the information needs to be conveyed from one service (the key establishment service) to another (the SNMP engine that needs it). For some devices, these services maybe implemented as a single entity (EG, a "process" under many common operating systems; if you want a SNMP reference see HOST-RESOURCES-MIB::hrSWRunIndex). If these services are to be implemented independently, this means that session information needs to be passed from the session establishment service to the SNMP engine responsible for handling the request. IE, in EUSM from the EAP and AAA/Radius services to the SNMP Engine in the device. What does this mean internally in today's modern operating systems? It means that the processes need a decent form of inter-process communication which is also protected from disclosure and modification from the other processes as well. This can be implemented in many ways, and is frequently done so using anything from shared memory on simple devices to internal signaling mechanisms to ... Thus vendors of session establishment services will need to work closely with vendors of SNMP stacks in order to make this possible. For highly portable packages, it may be extremely difficult to handle every possible internal communication path that may be found on the systems it wants to support. It means that commercial companies may be able to force users to buy not only their SNMP stack but their session establishment system as well. What makes this even harder is the number of ways in which SNMP is in use today. For SNMP, it is important to remember that there are really 2 services that need to be thought about. Specifically, many systems contain both a command receiver as well as a notification receiver and frequently a proxy as well. Many systems have these services each running as separate "processes" within the operating system. I've worked with many users that also run the same service in parallel on two different network ports. EG, they'll run one snmp command responder on the default port 161 and another on port 9161 because they offer different features and both are needed for some reason or another. The end result is that figure 2 above from section 2.4.2 is somewhat misleading about the internal complexity of what will need to be implemented. A potentially better diagram would depict multiple data paths and multiple engines: +------------------------+ +----------------------+ | Managed | | Manager | | Device | | Computer | | | | | | +---------+ | | +--------+ | | | Session | | Session establish | | Session| | | | Mgmt | |<----------------->| | Mgmt | | | +---------+ | | +--------+ | | ^ ^ | | ^ | | +-------------|----+ | | | +---|--------------+ | | | SNMP Engine | | | | | | | SNMP Engine | | | | #1 | | | | Message traffic | | | | | | | v | | | <---------------> | | v | | | | +-------+ | | | | | +-------+ | | | | | USM | | | | | | | USM | | | | | +-------+ | | | | | +-------+ | | | +------------------+ | | | | | | | | | | | | | | ______/ | | | | | | | | | | | | | +-------------|----+ | | | | | | | SNMP Engine | | | | | | | | | #2 | | | Message traffic | | | | | | v | | <---------------> | | | | | | +-------+ | | | | | | | | | USM | | | | | | | | | +-------+ | | | | | | | +------------------+ | | +------------------+ | +------------------------+ +----------------------+ [I put the managed device on the left this time because I started editing that box first and should have done the other; really either side could contain any number of engines and it doesn't matter] This means that as a given device needs to send SNMP messages to another device, it needs to kick the session establishment service to say "hey, go make this connection for me" and the receiving end must be properly told which internal engine to pass the information too. I've had clients with 4 engines running on one system before, with at least 3 of them being from different vendors. At a minimum, 2 must be supported by the resulting architecture since most packages I'm aware of implement the notification receiver in a separate process from the command generator. In order to make a parallel establishment setup work, such as EUSM or an IKE replacement or..., we would have to: 1) Declare the above an implementation problem and not worry about it. Note that implementing such internal message passing is subject to potential security and implementation problems resulting from the complexity and sensitivity of the information being passed around. [Plus the interoperability and portability problem mentioned above] 2) Standardize an internal session information passing mechanism along with the protocol we're going to use. 3) Not choose an architecture that requires parallel session establishment. Both TLSM and SBSM don't require this. An internally passed SASL implementation wouldn't require this either. I'm strong against #1, but I think #2 is at least usable but I really think #3 is the right way to go and that we should stick to an architecture that does not require such complex internal message passing. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Mar 6 21:33: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 VAA25401; Sun, 6 Mar 2005 21:33:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D885p-00051K-2L; Sun, 06 Mar 2005 21:35:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D881c-00038L-Cy; Sun, 06 Mar 2005 21:31:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D881a-00038G-TJ for isms@megatron.ietf.org; Sun, 06 Mar 2005 21:31: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 VAA25210 for ; Sun, 6 Mar 2005 21:31:11 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D883f-0004yS-9a for isms@ietf.org; Sun, 06 Mar 2005 21:33:24 -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 j272V0H15489; Sun, 6 Mar 2005 21:31:01 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 6 Mar 2005 21:31:01 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2BA65@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Wes Hardaker'" , isms@ietf.org Subject: RE: [Isms] Parallel vs in-band session setup. Date: Sun, 6 Mar 2005 21:30:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.6 (/) X-Scan-Signature: c5360d8dc5896b7620777c236feb980a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============1001644481==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 0f44ec47f6ebd2aaf0f97ba9529b3ca5 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. --===============1001644481== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C522BD.51FC15A9" 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_01C522BD.51FC15A9 Content-Type: text/plain Wes, Just wondering, but wouldn't it make more sense for the session/key establishment mechanism to be implemented as a library-type-thing (i.e. shlib) and thus execute within whatever SNMP Engine process is requesting a session? I think this is an implementation issue, which is easily overcome. Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Wes Hardaker > Sent: March 6, 2005 4:32 PM > To: isms@ietf.org > Subject: [Isms] Parallel vs in-band session setup. > > > As David P. has pointed out, every solution to date has talked about > the establishment of a session so I'm going to use that terminology > within, even though I'm not referring just to the SBSM protocol. > > There are a number of ways to begin a session and establish the > necessary runtime parameters to make use of the session establishment > results. The fundamental task ISMS is targeted with is the > establishment of at least keying information, regardless if that > keying information is to be used by USM or another security model. > For this discussion, I'm only going to talk about the session setup > aspect regardless of what information will be set up there. We will > assume at least keying, however, though likely things like a session > ID or some other key material identify identifier and potentially > other properties might be needed in a full scenario. > > > > The comparison document did a good job discussing the architectures > produced by the various solutions, but didn't discuss much of the > system ramifications of each of these architectures. Here's a recap > of the architectures that will be useful for this message: > > 2.4.1 USM and 2.4.3 SBSM [Figure 1/4] > > [These are functionally very similar diagrams, so I'm only including > one. The fundamental point behind them is that they are direct and > integrated within the protocol itself] > > +----------------------+ +----------------------+ > | Manager | | Managed | > | Computer | | Device | > | +------------------+ | | +------------------+ | > | | SNMP Engine | | | | SNMP Engine | | > | | | | | | | | > | | | | <------> | | | | > | | +-----+ +------+ | | | | +------+ +-----+ | | > | | | USM | | SBSM | | | | | | SBSM | | USM | | | > | | +-----+ +------+ | | | | +------+ +-----+ | | > | +------------------+ | | +------------------+ | > +----------------------+ +----------------------+ > > 2.4.4 Transport-Layer Security Model [TLSM; Figure 5] > > +------------------------+ +------------------------+ > | Manager | | Managed | > | Computer | | Device | > | +--------------------+ | | +--------------------+ | > | | SNMP Engine | | | | SNMP Engine | | > | | | | | | | | > | | | | <- - - - - -> | | | | > | | +------+ +-------+ | | | | +-------+ +------+ | | > | | | TLSM | | USM | | | | | | USM | | TLSM | | | > | | +------+ +-------+ | | | | +-------+ +------+ | | > | +----^---------------+ | | +-----^--------------+ | > | | | | | | > | +----v---------------+ | | +-----v--------------+ | > | | Security layer | | <-----------> | | Security layer | | > | +--------------------+ | | +--------------------+ | > +------------------------+ +------------------------+ > > 2.4.2 External User Security Model [EUSM, figure 2] > > +------------------------+ +----------------------+ > | Manager | | Managed | > | Computer | | Device | > | | | | > | +---------+ | | +--------+ | > | | Session | | Session establish | | Session| | > | | Mgmt | |<----------------->| | Mgmt | | > | +---------+ | | +--------+ | > | ^ | | ^ | > | +---------------|----+ | | +---|--------------+ | > | | SNMP Engine | | | | | | SNMP Engine | | > | | | | | Message traffic | | | | | > | | v | | <---------------> | | v | | > | | +-------+ | | | | +-------+ | | > | | | USM | | | | | | USM | | | > | | +-------+ | | | | +-------+ | | > | +--------------------+ | | +------------------+ | > +------------------------+ +----------------------+ > > [Editorial note: I changed "key establish" to "session establish" > in the above diagram, as we have not yet decided that only keying > information is needed. IE, I'm using "session establishment" in a > way that includes "key establishment" but is not limited to just > key negotiation.] > > One key difference in all of these diagrams is important to > understand. Specifically, whether keying and session setup is passed > directly within the communication "path". In USM and SBSM everything > is done by the security model. In TLSM, it is done by a lower layer > within the stack, but none the less is done over the same transport > domain/address that will be used to fundamentally communicate over > after the session has been set up. > > However, in EUSM and any replacements that involve parallel > establishment of session and keying information, this establishment is > manipulated over a separate transport domain/address which means that > internally to the box the information needs to be conveyed from one > service (the key establishment service) to another (the SNMP engine > that needs it). For some devices, these services maybe implemented as > a single entity (EG, a "process" under many common operating systems; > if you want a SNMP reference see HOST-RESOURCES-MIB::hrSWRunIndex). > > If these services are to be implemented independently, this means that > session information needs to be passed from the session establishment > service to the SNMP engine responsible for handling the request. IE, > in EUSM from the EAP and AAA/Radius services to the SNMP Engine in the > device. > > What does this mean internally in today's modern operating systems? > It means that the processes need a decent form of inter-process > communication which is also protected from disclosure and modification > from the other processes as well. This can be implemented in many > ways, and is frequently done so using anything from shared memory on > simple devices to internal signaling mechanisms to ... Thus vendors > of session establishment services will need to work closely with > vendors of SNMP stacks in order to make this possible. For highly > portable packages, it may be extremely difficult to handle every > possible internal communication path that may be found on the systems > it wants to support. It means that commercial companies may be able > to force users to buy not only their SNMP stack but their > session establishment system as well. > > > > What makes this even harder is the number of ways in which SNMP is in > use today. For SNMP, it is important to remember that there are > really 2 services that need to be thought about. Specifically, many > systems contain both a command receiver as well as a notification > receiver and frequently a proxy as well. Many systems have these > services each running as separate "processes" within the operating > system. I've worked with many users that also run the same service in > parallel on two different network ports. EG, they'll run one snmp > command responder on the default port 161 and another on port 9161 > because they offer different features and both are needed for some > reason or another. The end result is that figure 2 above from section > 2.4.2 is somewhat misleading about the internal complexity of what > will need to be implemented. A potentially better diagram would > depict multiple data paths and multiple engines: > > +------------------------+ +----------------------+ > | Managed | | Manager | > | Device | | Computer | > | | | | > | +---------+ | | +--------+ | > | | Session | | Session establish | | Session| | > | | Mgmt | |<----------------->| | Mgmt | | > | +---------+ | | +--------+ | > | ^ ^ | | ^ | > | +-------------|----+ | | | +---|--------------+ | > | | SNMP Engine | | | | | | | SNMP Engine | | > | | #1 | | | | Message traffic | | | | | > | | v | | | <---------------> | | v | | > | | +-------+ | | | | | +-------+ | | > | | | USM | | | | | | | USM | | | > | | +-------+ | | | | | +-------+ | | > | +------------------+ | | | | | | > | | | | | | | > | ______/ | | | | | > | | | | | | | > | +-------------|----+ | | | | | > | | SNMP Engine | | | | | | | > | | #2 | | | Message traffic | | | | > | | v | | <---------------> | | | | > | | +-------+ | | | | | | > | | | USM | | | | | | | > | | +-------+ | | | | | | > | +------------------+ | | +------------------+ | > +------------------------+ +----------------------+ > > [I put the managed device on the left this time because I started > editing that box first and should have done the other; really > either side could contain any number of engines and it doesn't > matter] > > This means that as a given device needs to send SNMP messages to > another device, it needs to kick the session establishment service to > say "hey, go make this connection for me" and the receiving end must > be properly told which internal engine to pass the information too. > I've had clients with 4 engines running on one system before, with at > least 3 of them being from different vendors. At a minimum, 2 must be > supported by the resulting architecture since most packages I'm aware > of implement the notification receiver in a separate process from the > command generator. > > In order to make a parallel establishment setup work, such as EUSM or > an IKE replacement or..., we would have to: > > 1) Declare the above an implementation problem and not worry about > it. Note that implementing such internal message passing is > subject to potential security and implementation problems resulting > from the complexity and sensitivity of the information being passed > around. [Plus the interoperability and portability problem > mentioned above] > > 2) Standardize an internal session information passing mechanism along > with the protocol we're going to use. > > 3) Not choose an architecture that requires parallel session > establishment. Both TLSM and SBSM don't require this. An > internally passed SASL implementation wouldn't require this > either. > > I'm strong against #1, but I think #2 is at least usable but I really > think #3 is the right way to go and that we should stick to an > architecture that does not require such complex internal message > passing. > > -- > Wes Hardaker > Sparta > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C522BD.51FC15A9 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Parallel vs in-band session setup.

Wes,

Just wondering, but wouldn't it make more sense for = the session/key establishment mechanism to be implemented as a = library-type-thing (i.e. shlib) and thus execute within whatever SNMP = Engine process is requesting a session?

I think this is an implementation issue, which is = easily overcome.

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Wes Hardaker
> Sent: March 6, 2005 4:32 PM
> To: isms@ietf.org
> Subject: [Isms] Parallel vs in-band session = setup.
>
>
> As David P. has pointed out, every solution to = date has talked about
> the establishment of a session so I'm going to = use that terminology
> within, even though I'm not referring just to = the SBSM protocol.
>
> There are a number of ways to begin a session = and establish the
> necessary runtime parameters to make use of the = session establishment
> results.  The fundamental task ISMS is = targeted with is the
> establishment of at least keying information, = regardless if that
> keying information is to be used by USM or = another security model.
> For this discussion, I'm only going to talk = about the session setup
> aspect regardless of what information will be = set up there.  We will
> assume at least keying, however, though likely = things like a session
> ID or some other key material identify = identifier and potentially
> other properties might be needed in a full = scenario.
>
>
>
> The comparison document did a good job = discussing the architectures
> produced by the various solutions, but didn't = discuss much of the
> system ramifications of each of these = architectures.  Here's a recap
> of the architectures that will be useful for = this message:
>
>   2.4.1  USM and 2.4.3 = SBSM  [Figure 1/4]
>
>   [These are functionally very = similar diagrams, so I'm only including
>   one.  The fundamental point = behind them is that they are direct and
>   integrated within the protocol = itself]
>
>    = +----------------------+        =   +----------------------+
>    = |       = Manager        = |          = |       = Managed        |
>    = |       = Computer       = |          = |       = Device         |
>    | +------------------+ = |          | = +------------------+ |
>    | |   SNMP = Engine    | = |          | = |    SNMP Engine   | |
>    | = |            = ;      | = |          | = |            = ;      | |
>    | = |            = ;      | | <------> | = |            = ;      | |
>    | | +-----+ +------+ | = |          | | +------+ = +-----+ | |
>    | | | USM | | SBSM | | = |          | | | SBSM | | = USM | | |
>    | | +-----+ +------+ | = |          | | +------+ = +-----+ | |
>    | +------------------+ = |          | = +------------------+ |
>    = +----------------------+        =   +----------------------+
>
>   2.4.4  Transport-Layer = Security Model [TLSM; Figure 5]
>
>    = +------------------------+       &nbs= p;       = +------------------------+
>    = |        = Manager         = |            = ;   |        = Managed         |
>    = |        = Computer        = |            = ;   |        = Device          |
>    | +--------------------+ = |            = ;   | +--------------------+ |
>    | |    SNMP = Engine     | = |            = ;   | |     SNMP Engine    = | |
>    | = |            = ;        | = |            = ;   | = |            = ;        | |
>    | = |            = ;        | | <- - - - - -> | = |            = ;        | |
>    | | +------+ +-------+ | = |            = ;   | | +-------+ +------+ | |
>    | | | TLSM | |  = USM  | | = |            = ;   | | |  USM  | | TLSM | | |
>    | | +------+ +-------+ | = |            = ;   | | +-------+ +------+ | |
>    | +----^---------------+ = |            = ;   | +-----^--------------+ |
>    = |      = |            = ;     = |            = ;   |       = |            = ;    |
>    | +----v---------------+ = |            = ;   | +-----v--------------+ |
>    | |  Security = layer    | | <-----------> | |   = Security layer   | |
>    | +--------------------+ = |            = ;   | +--------------------+ |
>    = +------------------------+       &nbs= p;       = +------------------------+
>
>   2.4.2  External User Security = Model [EUSM, figure 2]
>
>    = +------------------------+       &nbs= p;           = +----------------------+
>    = |        = Manager         = |            = ;       = |        = Managed       |
>    = |        = Computer        = |            = ;       = |        = Device        |
>    = |            = ;            = |            = ;       = |            = ;          |
>    = |            = +---------+ = |            = ;       | = +--------+           = |
>    = |            | = Session | | Session establish | | = Session|           = |
>    = |            | = Mgmt    | |<----------------->| | Mgmt   = |           |
>    = |            = +---------+ = |            = ;       | = +--------+           = |
>    = |            = ;     ^      = |            = ;       |     = ^            = ;    |
>    | +---------------|----+ = |            = ;       | +---|--------------+ |
>    | |   SNMP Engine = |    | = |            = ;       | |   | SNMP = Engine  | |
>    | = |            = ;   |    | |  Message traffic  | = |   = |            = ;  | |
>    | = |            = ;   v    | | <---------------> | = |   = v            = ;  | |
>    | = |          +-------+ | = |            = ;       | | = +-------+        | |
>    | = |          |  = USM  | | = |            = ;       | | |  USM  = |        | |
>    | = |          +-------+ | = |            = ;       | | = +-------+        | |
>    | +--------------------+ = |            = ;       | +------------------+ |
>    = +------------------------+       &nbs= p;           = +----------------------+
>
>    [Editorial note: I changed = "key establish" to "session establish"
>    in the above diagram, as we = have not yet decided that only keying
>    information is needed.  = IE, I'm using "session establishment" in a
>    way that includes "key = establishment" but is not limited to just
>    key negotiation.]
>
> One key difference in all of these diagrams is = important to
> understand.  Specifically, whether keying = and session setup is passed
> directly within the communication = "path".  In USM and SBSM everything
> is done by the security model.  In TLSM, = it is done by a lower layer
> within the stack, but none the less is done = over the same transport
> domain/address that will be used to = fundamentally communicate over
> after the session has been set up.
>
> However, in EUSM and any replacements that = involve parallel
> establishment of session and keying = information, this establishment is
> manipulated over a separate transport = domain/address which means that
> internally to the box the information needs to = be conveyed from one
> service (the key establishment service) to = another (the SNMP engine
> that needs it).  For some devices, these = services maybe implemented as
> a single entity (EG, a "process" = under many common operating systems;
> if you want a SNMP reference see = HOST-RESOURCES-MIB::hrSWRunIndex).
>
> If these services are to be implemented = independently, this means that
> session information needs to be passed from the = session establishment
> service to the SNMP engine responsible for = handling the request.  IE,
> in EUSM from the EAP and AAA/Radius services to = the SNMP Engine in the
> device.
>
> What does this mean internally in today's = modern operating systems?
> It means that the processes need a decent form = of inter-process
> communication which is also protected from = disclosure and modification
> from the other processes as well.  This = can be implemented in many
> ways, and is frequently done so using anything = from shared memory on
> simple devices to internal signaling mechanisms = to ...  Thus vendors
> of session establishment services will need to = work closely with
> vendors of SNMP stacks in order to make this = possible.  For highly
> portable packages, it may be extremely = difficult to handle every
> possible internal communication path that may = be found on the systems
> it wants to support.  It means that = commercial companies may be able
> to force users to buy not only their SNMP stack = but their
> session establishment system as well.
>
>
>
> What makes this even harder is the number of = ways in which SNMP is in
> use today.  For SNMP, it is important to = remember that there are
> really 2 services that need to be thought = about.  Specifically, many
> systems contain both a command receiver as well = as a notification
> receiver and frequently a proxy as well.  = Many systems have these
> services each running as separate = "processes" within the operating
> system.  I've worked with many users that = also run the same service in
> parallel on two different network ports.  = EG, they'll run one snmp
> command responder on the default port 161 and = another on port 9161
> because they offer different features and both = are needed for some
> reason or another.  The end result is that = figure 2 above from section
> 2.4.2 is somewhat misleading about the internal = complexity of what
> will need to be implemented.  A = potentially better diagram would
> depict multiple data paths and multiple = engines:
>
>    = +------------------------+       &nbs= p;           = +----------------------+
>    = |        = Managed         = |            = ;       = |        = Manager       |
>    = |        = Device          = |            = ;       = |        = Computer      |
>    = |            = ;            = |            = ;       = |            = ;          |
>    = |            = +---------+ = |            = ;       | = +--------+           = |
>    = |            | = Session | | Session establish | | = Session|           = |
>    = |            | = Mgmt    | |<----------------->| | Mgmt   = |           |
>    = |            = +---------+ = |            = ;       | = +--------+           = |
>    = |            = ;   ^      ^ = |            = ;       |     = ^            = ;    |
>    | +-------------|----+ | = |            = ;       | +---|--------------+ |
>    | | SNMP Engine = |    | | = |            = ;       | |   | SNMP = Engine  | |
>    | | = #1          = |    | | |  Message traffic  | |   = |            = ;  | |
>    | = |            = ; v    | | | <---------------> | |   = v            = ;  | |
>    | = |        +-------+ | | = |            = ;       | | = +-------+        | |
>    | = |        |  USM  | | | = |            = ;       | | |  USM  = |        | |
>    | = |        +-------+ | | = |            = ;       | | = +-------+        | |
>    | +------------------+ | = |            = ;       | = |            = ;      | |
>    = |            = ;          | = |            = ;       | = |            = ;      | |
>    = |            = ;   ______/  = |            = ;       | = |            = ;      | |
>    = |            = ;   |        = |            = ;       | = |            = ;      | |
>    | = +-------------|----+   = |            = ;       | = |            = ;      | |
>    | | SNMP Engine = |    |   = |            = ;       | = |            = ;      | |
>    | | = #2          = |    |   |  Message traffic  | = |            = ;      | |
>    | = |            = ; v    |   | <---------------> | = |            = ;      | |
>    | = |        +-------+ |   = |            = ;       | = |            = ;      | |
>    | = |        |  USM  | = |   = |            = ;       | = |            = ;      | |
>    | = |        +-------+ |   = |            = ;       | = |            = ;      | |
>    | = +------------------+   = |            = ;       | +------------------+ |
>    = +------------------------+       &nbs= p;           = +----------------------+
>
>    [I put the managed device on = the left this time because I started
>    editing that box first and = should have done the other; really
>    either side could contain any = number of engines and it doesn't
>    matter]
>
> This means that as a given device needs to send = SNMP messages to
> another device, it needs to kick the session = establishment service to
> say "hey, go make this connection for = me" and the receiving end must
> be properly told which internal engine to pass = the information too.
> I've had clients with 4 engines running on one = system before, with at
> least 3 of them being from different = vendors.  At a minimum, 2 must be
> supported by the resulting architecture since = most packages I'm aware
> of implement the notification receiver in a = separate process from the
> command generator.
>
> In order to make a parallel establishment setup = work, such as EUSM or
> an IKE replacement or..., we would have = to:
>
> 1) Declare the above an implementation problem = and not worry about
>    it.  Note that = implementing such internal message passing is
>    subject to potential security = and implementation problems resulting
>    from the complexity and = sensitivity of the information being passed
>    around.  [Plus the = interoperability and portability problem
>    mentioned above]
>
> 2) Standardize an internal session information = passing mechanism along
>    with the protocol we're going = to use.
>
> 3) Not choose an architecture that requires = parallel session
>    establishment.  Both = TLSM and SBSM don't require this.  An
>    internally passed SASL = implementation wouldn't require this
>    either.
>
> I'm strong against #1, but I think #2 is at = least usable but I really
> think #3 is the right way to go and that we = should stick to an
> architecture that does not require such complex = internal message
> passing.
>
> --
> Wes Hardaker
> Sparta
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C522BD.51FC15A9-- --===============1001644481== 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 --===============1001644481==-- From isms-bounces@ietf.org Sun Mar 6 21:46: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 VAA26343; Sun, 6 Mar 2005 21:46:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88Is-0005Ia-Mp; Sun, 06 Mar 2005 21:49:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88GA-0004Ol-1y; Sun, 06 Mar 2005 21:46:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88G8-0004Mh-Aa for isms@megatron.ietf.org; Sun, 06 Mar 2005 21:46: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 VAA26221 for ; Sun, 6 Mar 2005 21:46:13 -0500 (EST) Received: from wireless-130-129-133-143.ietf62.ietf.org ([130.129.133.143] helo=wes.hardakers.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88IE-0005H1-Kj for isms@ietf.org; Sun, 06 Mar 2005 21:48:26 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 52D3A11D727; Sun, 6 Mar 2005 18:46:15 -0800 (PST) From: Wes Hardaker To: "Martin Soukup" Subject: Re: [Isms] Parallel vs in-band session setup. Organization: Sparta References: <0BDFFF51DC89434FA33F8B37FCE363D501F2BA65@zcarhxm2.corp.nortel.com> Date: Sun, 06 Mar 2005 18:46:14 -0800 In-Reply-To: <0BDFFF51DC89434FA33F8B37FCE363D501F2BA65@zcarhxm2.corp.nortel.com> (Martin Soukup's message of "Sun, 6 Mar 2005 21:30:57 -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: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Martin> Just wondering, but wouldn't it make more sense for the Martin> session/key establishment mechanism to be implemented as a Martin> library-type-thing (i.e. shlib) and thus execute within Martin> whatever SNMP Engine process is requesting a session? It's the receiving side of the connection establishment which is more problematic. How does a XXX keying demon on a machine know which of multiple SNMP processes to send the keys too? -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 00:06: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 AAA09450; Mon, 7 Mar 2005 00:06:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ATk-0000Hf-P4; Mon, 07 Mar 2005 00:08:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AQT-0000ld-5v; Mon, 07 Mar 2005 00:05:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8AQS-0000l4-1e for isms@megatron.ietf.org; Mon, 07 Mar 2005 00:05:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09196 for ; Mon, 7 Mar 2005 00:05:00 -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 1D8ASY-0000Ft-Mf for isms@ietf.org; Mon, 07 Mar 2005 00:07:15 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j2754rl4004070 for ; Mon, 7 Mar 2005 05:04:53 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j2754lk2029392 for ; Mon, 7 Mar 2005 05:04:53 GMT Received: from fmsmsx331.amr.corp.intel.com ([132.233.42.156]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030621045306080 for ; Sun, 06 Mar 2005 21:04:53 -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); Sun, 6 Mar 2005 21:04:53 -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); Sun, 6 Mar 2005 21:04:52 -0800 Received: from pysmsx401.amr.corp.intel.com ([146.152.3.156]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 7 Mar 2005 00:04:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Parallel vs in-band session setup. Date: Mon, 7 Mar 2005 00:04:41 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929C5EF0D@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Parallel vs in-band session setup. Thread-Index: AcUivhdFHjtk8roiQ/SUj2PXtF+U1gAC2e8w From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 07 Mar 2005 05:04:51.0854 (UTC) FILETIME=[31C7AAE0:01C522D3] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 563af5038a5e1dade28c8affc0fff375 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: 562cdc9baa87554b29d950396a30cf75 Content-Transfer-Encoding: quoted-printable >> Just wondering, but wouldn't it make more sense for the session/key establishment mechanism >> to be implemented as a library-type-thing (i.e. shlib) and thus execute within whatever SNMP >> Engine process is requesting a session? > > It's the receiving side of the connection establishment which is more > problematic. How does a XXX keying demon on a machine know which > of multiple SNMP processes to send the keys too? =20 [Uri>] First question: do you want the "keying entity" to live within the SNMP engine, or outside of it (like IKE in IPsec)? My answer is - it should be inside, as a part of SNMP engine. I propose making "keying subsystem" a new security model, whose sole=20 responsibilities are: 1. authenticating the parties; 2. authorizing them (possibly via back-end such as RADIUS); 3. determining session lifetime and creating (or assigning) identity; 4. obtaining VACM group entry and mapping that identity onto it; 5. generating session keys and installing them into USM (for those who just can't stand this model - to xSM :-). In that case all the session establishment traffic can be cleanly encapsulated in SNMPv3, be parsed by SNMPv3 protocol engine and handled to the right Security Model (which in turn will configure the other Security Models for upcoming SNMP traffic). [started sounding similar to SBSM] Another advantage of following the above - SNMP engine can preserve its=20 multi-version multi-lingual capabilities. And no intreaction with=20 Regarding use of EAP - we cannot use EAP encapsulation. But we'll probably have to re-use the algorithms (like ARCHIE EAP method), because there are just so many ways to do key exchange... In the below analysis, I believe that Wes is correct. Except that IMHO it is not enough to do just the keying - xACM mapping is also necessary. > -----Original Message-----=20 > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On=20 > Behalf Of Wes Hardaker=20 > Sent: March 6, 2005 4:32 PM=20 > To: isms@ietf.org=20 > Subject: [Isms] Parallel vs in-band session setup.=20 >=20 >=20 > As David P. has pointed out, every solution to date has talked about=20 > the establishment of a session so I'm going to use that terminology=20 > within, even though I'm not referring just to the SBSM protocol.=20 >=20 > There are a number of ways to begin a session and establish the=20 > necessary runtime parameters to make use of the session establishment=20 > results. The fundamental task ISMS is targeted with is the=20 > establishment of at least keying information, regardless if that=20 > keying information is to be used by USM or another security model.=20 > For this discussion, I'm only going to talk about the session setup=20 > aspect regardless of what information will be set up there. We will=20 > assume at least keying, however, though likely things like a session=20 > ID or some other key material identify identifier and potentially=20 > other properties might be needed in a full scenario.=20 >=20 >=20 >=20 > The comparison document did a good job discussing the architectures=20 > produced by the various solutions, but didn't discuss much of the=20 > system ramifications of each of these architectures. Here's a recap=20 > of the architectures that will be useful for this message:=20 >=20 > 2.4.1 USM and 2.4.3 SBSM [Figure 1/4]=20 >=20 > [These are functionally very similar diagrams, so I'm only including=20 > one. The fundamental point behind them is that they are direct and=20 > integrated within the protocol itself]=20 >=20 > +----------------------+ +----------------------+=20 > | Manager | | Managed |=20 > | Computer | | Device |=20 > | +------------------+ | | +------------------+ |=20 > | | SNMP Engine | | | | SNMP Engine | |=20 > | | | | | | | |=20 > | | | | <------> | | | |=20 > | | +-----+ +------+ | | | | +------+ +-----+ | |=20 > | | | USM | | SBSM | | | | | | SBSM | | USM | | |=20 > | | +-----+ +------+ | | | | +------+ +-----+ | |=20 > | +------------------+ | | +------------------+ |=20 > +----------------------+ +----------------------+=20 >=20 > 2.4.4 Transport-Layer Security Model [TLSM; Figure 5]=20 >=20 > +------------------------+ +------------------------+=20 > | Manager | | Managed |=20 > | Computer | | Device |=20 > | +--------------------+ | | +--------------------+ |=20 > | | SNMP Engine | | | | SNMP Engine | |=20 > | | | | | | | |=20 > | | | | <- - - - - -> | | | |=20 > | | +------+ +-------+ | | | | +-------+ +------+ | |=20 > | | | TLSM | | USM | | | | | | USM | | TLSM | | |=20 > | | +------+ +-------+ | | | | +-------+ +------+ | |=20 > | +----^---------------+ | | +-----^--------------+ |=20 > | | | | | |=20 > | +----v---------------+ | | +-----v--------------+ |=20 > | | Security layer | | <-----------> | | Security layer | |=20 > | +--------------------+ | | +--------------------+ |=20 > +------------------------+ +------------------------+=20 >=20 > 2.4.2 External User Security Model [EUSM, figure 2]=20 >=20 > +------------------------+ +----------------------+=20 > | Manager | | Managed |=20 > | Computer | | Device |=20 > | | | |=20 > | +---------+ | | +--------+ |=20 > | | Session | | Session establish | | Session| |=20 > | | Mgmt | |<----------------->| | Mgmt | |=20 > | +---------+ | | +--------+ |=20 > | ^ | | ^ |=20 > | +---------------|----+ | | +---|--------------+ |=20 > | | SNMP Engine | | | | | | SNMP Engine | |=20 > | | | | | Message traffic | | | | |=20 > | | v | | <---------------> | | v | |=20 > | | +-------+ | | | | +-------+ | |=20 > | | | USM | | | | | | USM | | |=20 > | | +-------+ | | | | +-------+ | |=20 > | +--------------------+ | | +------------------+ |=20 > +------------------------+ +----------------------+=20 >=20 > [Editorial note: I changed "key establish" to "session establish"=20 > in the above diagram, as we have not yet decided that only keying=20 > information is needed. IE, I'm using "session establishment" in a=20 > way that includes "key establishment" but is not limited to just=20 > key negotiation.]=20 >=20 > One key difference in all of these diagrams is important to=20 > understand. Specifically, whether keying and session setup is passed=20 > directly within the communication "path". In USM and SBSM everything=20 > is done by the security model. In TLSM, it is done by a lower layer=20 > within the stack, but none the less is done over the same transport=20 > domain/address that will be used to fundamentally communicate over=20 > after the session has been set up.=20 >=20 > However, in EUSM and any replacements that involve parallel=20 > establishment of session and keying information, this establishment is=20 > manipulated over a separate transport domain/address which means that=20 > internally to the box the information needs to be conveyed from one=20 > service (the key establishment service) to another (the SNMP engine=20 > that needs it). For some devices, these services maybe implemented as=20 > a single entity (EG, a "process" under many common operating systems;=20 > if you want a SNMP reference see HOST-RESOURCES-MIB::hrSWRunIndex).=20 >=20 > If these services are to be implemented independently, this means that=20 > session information needs to be passed from the session establishment=20 > service to the SNMP engine responsible for handling the request. IE,=20 > in EUSM from the EAP and AAA/Radius services to the SNMP Engine in the=20 > device.=20 >=20 > What does this mean internally in today's modern operating systems?=20 > It means that the processes need a decent form of inter-process=20 > communication which is also protected from disclosure and modification=20 > from the other processes as well. This can be implemented in many=20 > ways, and is frequently done so using anything from shared memory on=20 > simple devices to internal signaling mechanisms to ... Thus vendors=20 > of session establishment services will need to work closely with=20 > vendors of SNMP stacks in order to make this possible. For highly=20 > portable packages, it may be extremely difficult to handle every=20 > possible internal communication path that may be found on the systems=20 > it wants to support. It means that commercial companies may be able=20 > to force users to buy not only their SNMP stack but their=20 > session establishment system as well.=20 >=20 >=20 >=20 > What makes this even harder is the number of ways in which SNMP is in=20 > use today. For SNMP, it is important to remember that there are=20 > really 2 services that need to be thought about. Specifically, many=20 > systems contain both a command receiver as well as a notification=20 > receiver and frequently a proxy as well. Many systems have these=20 > services each running as separate "processes" within the operating=20 > system. I've worked with many users that also run the same service in=20 > parallel on two different network ports. EG, they'll run one snmp=20 > command responder on the default port 161 and another on port 9161=20 > because they offer different features and both are needed for some=20 > reason or another. The end result is that figure 2 above from section=20 > 2.4.2 is somewhat misleading about the internal complexity of what=20 > will need to be implemented. A potentially better diagram would=20 > depict multiple data paths and multiple engines:=20 >=20 > +------------------------+ +----------------------+=20 > | Managed | | Manager |=20 > | Device | | Computer |=20 > | | | |=20 > | +---------+ | | +--------+ |=20 > | | Session | | Session establish | | Session| |=20 > | | Mgmt | |<----------------->| | Mgmt | |=20 > | +---------+ | | +--------+ |=20 > | ^ ^ | | ^ |=20 > | +-------------|----+ | | | +---|--------------+ |=20 > | | SNMP Engine | | | | | | | SNMP Engine | |=20 > | | #1 | | | | Message traffic | | | | |=20 > | | v | | | <---------------> | | v | |=20 > | | +-------+ | | | | | +-------+ | |=20 > | | | USM | | | | | | | USM | | |=20 > | | +-------+ | | | | | +-------+ | |=20 > | +------------------+ | | | | | |=20 > | | | | | | |=20 > | ______/ | | | | |=20 > | | | | | | |=20 > | +-------------|----+ | | | | |=20 > | | SNMP Engine | | | | | | |=20 > | | #2 | | | Message traffic | | | |=20 > | | v | | <---------------> | | | |=20 > | | +-------+ | | | | | |=20 > | | | USM | | | | | | |=20 > | | +-------+ | | | | | |=20 > | +------------------+ | | +------------------+ |=20 > +------------------------+ +----------------------+=20 >=20 > [I put the managed device on the left this time because I started=20 > editing that box first and should have done the other; really=20 > either side could contain any number of engines and it doesn't=20 > matter]=20 >=20 > This means that as a given device needs to send SNMP messages to=20 > another device, it needs to kick the session establishment service to=20 > say "hey, go make this connection for me" and the receiving end must=20 > be properly told which internal engine to pass the information too.=20 > I've had clients with 4 engines running on one system before, with at=20 > least 3 of them being from different vendors. At a minimum, 2 must be=20 > supported by the resulting architecture since most packages I'm aware=20 > of implement the notification receiver in a separate process from the=20 > command generator.=20 >=20 > In order to make a parallel establishment setup work, such as EUSM or=20 > an IKE replacement or..., we would have to:=20 >=20 > 1) Declare the above an implementation problem and not worry about=20 > it. Note that implementing such internal message passing is=20 > subject to potential security and implementation problems resulting=20 > from the complexity and sensitivity of the information being passed=20 > around. [Plus the interoperability and portability problem > mentioned above]=20 >=20 > 2) Standardize an internal session information passing mechanism along=20 > with the protocol we're going to use.=20 >=20 > 3) Not choose an architecture that requires parallel session=20 > establishment. Both TLSM and SBSM don't require this. An=20 > internally passed SASL implementation wouldn't require this > either.=20 >=20 > I'm strong against #1, but I think #2 is at least usable but I really=20 > think #3 is the right way to go and that we should stick to an > architecture that does not require such complex internal message=20 > passing.=20 >=20 > --=20 > Wes Hardaker=20 > Sparta=20 >=20 > _______________________________________________=20 > Isms mailing list=20 > Isms@lists.ietf.org=20 > https://www1.ietf.org/mailman/listinfo/isms=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 10:59: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 KAA01538; Mon, 7 Mar 2005 10:59:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Kfw-00071x-1K; Mon, 07 Mar 2005 11:01:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8KdJ-000307-CZ; Mon, 07 Mar 2005 10:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8KdH-000301-V4 for isms@megatron.ietf.org; Mon, 07 Mar 2005 10:58: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 KAA01500 for ; Mon, 7 Mar 2005 10:58:57 -0500 (EST) Message-Id: <200503071558.KAA01500@ietf.org> Received: from sccrmhc14.comcast.net ([204.127.202.59] helo=sccrmhc11.comcast.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8KfU-00071N-Bz for isms@ietf.org; Mon, 07 Mar 2005 11:01:17 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc14) with SMTP id <2005030715584901400pprpde>; Mon, 7 Mar 2005 15:58:49 +0000 From: "David B Harrington" To: Date: Mon, 7 Mar 2005 10:58:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUjLoSPq+LxIbU4RaGT5ujpIUWNJw== X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Isms] slides X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dbharrington@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Hi, If slides will be used during this evening's meeting, are those slides available on the Internet for viewing by remote participants? The MP3 sessions seem to be working fine this morning. The Jabber isn't working well apparently because of the wireless issues. 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 Mar 7 12:23:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11133; Mon, 7 Mar 2005 12:23:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8LzT-0000u2-Ey; Mon, 07 Mar 2005 12:25:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LuG-0006f1-Bs; Mon, 07 Mar 2005 12:20:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LuE-0006ew-WE for isms@megatron.ietf.org; Mon, 07 Mar 2005 12:20: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 MAA10588 for ; Mon, 7 Mar 2005 12:20:32 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8LwS-0000mG-1L for isms@ietf.org; Mon, 07 Mar 2005 12:22:53 -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 j27HKRgI014250 for ; Mon, 7 Mar 2005 12:20:28 -0500 (EST) Message-Id: <200503071720.j27HKRgI014250@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <422B1244.1020907@nortel.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 07 Mar 2005 12:20:27 -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: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 >I am sorry I could not respond to this earlier, but I think this was >discussed earlier, in January; Bernard Aboba wrote a number of options >to this list on how to use EAP with due nod to the RFC 3748 >applicability statement. I don't recall this email, but nevertheless ... There seems to be a lot of concern at the IESG about using EAP for things it wasn't intended to be used for (and I don't think that EAP was ever intended to secure SNMP). If the WG decides that it wants to select EUSM and use EAP (EUSM may be an option if you don't use EAP), I think we will be facing an uphill battle in the IESG. I know what Bernard said in the email you provided, but I got a very different impression from Sam during our teleconference. Additionally ... it seems in the new draft that the way you support Kerberos is via EAP-TLS and "Kerberos cipher suites". If by that you are referring to RFC 2712 (this isn't in the references section), then I think that is an issue, as that protocol is not well supported by TLS implementations, is not really used in that many production environments, and I personally don't think that it is reasonable to use it as a way to specify Kerberos support for EUSM. This is completely seperate from exactly HOW you would use it, because even if it was widely used and supported you're missing some pieces on how they hook together. Specifically ... if you're using TLS with Kerberos cipher suites, exactly why do you need to use EAP at all? Would EAP implementations even know about the Kerberos cipher suite that was negotiated by TLS? Really, what you want is the Kerberos negotiation to take place _within_ EAP, but AFAIK no such mechanism exists. The same holds true for X.509 certificates; if you're expecting to take certificates exchanged as part of TLS and use those to make authorization decisions, I'm missing how EAP fits into that. One other thought occurs to me. I don't see how you negotiate between doing EAP/TLS and PEAPv2/RADIUS (if I'm a manager that can do either, how do I choose between the two when I talk to an agent?). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 14:34: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 OAA24275; Mon, 7 Mar 2005 14:34:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8O27-0004Nj-Cy; Mon, 07 Mar 2005 14:36:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NyC-0005CA-Dr; Mon, 07 Mar 2005 14:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NyB-0005C5-HD for isms@megatron.ietf.org; Mon, 07 Mar 2005 14:32: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 OAA23949 for ; Mon, 7 Mar 2005 14:32:45 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8O0P-0004JQ-PS for isms@ietf.org; Mon, 07 Mar 2005 14:35:07 -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 j27JWTUX017472 for ; Mon, 7 Mar 2005 14:32:29 -0500 (EST) Message-Id: <200503071932.j27JWTUX017472@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <3DEC199BD7489643817ECA151F7C5929C5EE88@pysmsx401.amr.corp.intel.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Mon, 07 Mar 2005 14:32:29 -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: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 >IKE is a well-analyzed Key Exchange protocol, whose entire job is to >just authenticate end-points, agree on SA parameters and generate keys >(not encumbered by other functionality). > >I would strongly object to re-inventing key exchange protocol. I'd >strongly support a minimal explicit interface to something like IKE. >I want to emphasize, that even INTEGRATING an EXISTING GOOD Key >Exchange protocol is non-trivial and tricky enough. I definately agree that IKE is well-analyzed (maybe not universally well-understood, though :-) ). I have one question, though. Of course IKE is used by IPsec, but is it used by other application-level protocols for key exchange? The reason I ask is that if it's not, then I think that would definately increase the implementation burden if the WG decided to use it. The reason is that while a particular box may ship with IPsec, it won't necessarily make an API available to where applications can use IKE directly, thus forcing implementors to re-implement all of IKE. Now of course you'd need to implement all of SBSM yourself, for example, but with something like TLSM you'd be able to make use of existing TLS libraries that are used by plenty of applications today. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 20:14: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 UAA03187; Mon, 7 Mar 2005 20:14:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TLE-0005cb-Dr; Mon, 07 Mar 2005 20:16:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8TIZ-0002OO-Fh; Mon, 07 Mar 2005 20:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7XFy-0001h5-HV for isms@megatron.ietf.org; Sat, 05 Mar 2005 06:15: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 GAA04172 for ; Sat, 5 Mar 2005 06:15:35 -0500 (EST) Received: from luminous.mit.edu ([18.101.1.61]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7XHi-0007mq-PM for isms@ietf.org; Sat, 05 Mar 2005 06:17:28 -0500 Received: by luminous.mit.edu (Postfix, from userid 1000) id AE9C276E99; Sat, 5 Mar 2005 06:15:33 -0500 (EST) To: "Randy Presuhn" Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503041924.j24JOE5F009291@ginger.cmf.nrl.navy.mil> <002601c5212e$2e81d500$7f1afea9@oemcomputer> From: Sam Hartman Date: Sat, 05 Mar 2005 06:15:33 -0500 In-Reply-To: <002601c5212e$2e81d500$7f1afea9@oemcomputer> (Randy Presuhn's message of "Fri, 4 Mar 2005 18:51:07 -0800") Message-ID: <87y8d2ibsa.fsf@luminous.mit.edu> User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Mon, 07 Mar 2005 20:14:10 -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.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a >>>>> "Randy" == Randy Presuhn writes: Randy> I find it ironic that some of the reasons the AD gives for Randy> not wanting to use EAP (complexity resulting from operating Randy> over non-reliable transport, independence from IP, support Randy> for proxying, multi-step exchanges, etc.) all contribute Randy> to the most complex aspects of the SBSM proposal. If we Randy> can't use EAP, are we doomed to re-invent it? The irony is not lost on me. I'd rather you not end up inventing your own security protocol. If you do end up rejecting all the security protocols that it would be appropriate to use, I'd certainly appreciate feedback to take to those protocol designers on why they did not meet your needs. Ending up with SBSM is not inherently wrong though. IT may well be that having two application-specific protocols (EAP for network access, SBSM for network management) is better than trying to make one protocol fit both applications. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 20:15: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 UAA03298; Mon, 7 Mar 2005 20:15:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TMA-0005dg-5e; Mon, 07 Mar 2005 20:17:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8TIa-0002Og-Ce; Mon, 07 Mar 2005 20:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8QRL-0004sa-1c for isms@megatron.ietf.org; Mon, 07 Mar 2005 17:11: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 RAA09625 for ; Mon, 7 Mar 2005 17:11:00 -0500 (EST) Received: from wireless-130-129-135-90.ietf62.ietf.org ([130.129.135.90] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8QTa-00085e-Di for isms@ietf.org; Mon, 07 Mar 2005 17:13:23 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 394C7E0063; Mon, 7 Mar 2005 17:10:57 -0500 (EST) To: Ken Hornstein Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503071720.j27HKRgI014250@ginger.cmf.nrl.navy.mil> From: Sam Hartman Date: Mon, 07 Mar 2005 17:10:57 -0500 In-Reply-To: <200503071720.j27HKRgI014250@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Mon, 07 Mar 2005 12:20:27 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Mon, 07 Mar 2005 20:14:10 -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.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d >>>>> "Ken" == Ken Hornstein writes: >> I am sorry I could not respond to this earlier, but I think >> this was discussed earlier, in January; Bernard Aboba wrote a >> number of options to this list on how to use EAP with due nod >> to the RFC 3748 applicability statement. Ken> I don't recall this email, but nevertheless ... Ken> There seems to be a lot of concern at the IESG about using Ken> EAP for things it wasn't intended to be used for (and I don't Ken> think that EAP was ever intended to secure SNMP). If the WG Ken> decides that it wants to select EUSM and use EAP (EUSM may be Ken> an option if you don't use EAP), I think we will be facing an Ken> uphill battle in the IESG. I know what Bernard said in the Ken> email you provided, but I got a very different impression Ken> from Sam during our teleconference. Hmm, I actually think what I'm saying is consistent with what Bernard is saying. When I pointed out to Bernard that using EAP tunneled within SNMP was the goal, he agreed that fell outside the applicability statement. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 20:16: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 UAA03414; Mon, 7 Mar 2005 20:16:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TN3-0005fK-4y; Mon, 07 Mar 2005 20:18:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8TIZ-0002OW-Rw; Mon, 07 Mar 2005 20:14:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7xPQ-00064q-76 for isms@megatron.ietf.org; Sun, 06 Mar 2005 10:11: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 KAA16294 for ; Sun, 6 Mar 2005 10:11:05 -0500 (EST) Received: from wireless-130-129-135-158.ietf62.ietf.org ([130.129.135.158] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7xRP-0004k9-CV for isms@ietf.org; Sun, 06 Mar 2005 10:13:12 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 99C5FE0063; Sun, 6 Mar 2005 10:09:22 -0500 (EST) To: isms@ietf.org From: Sam Hartman Date: Sun, 06 Mar 2005 10:09:22 -0500 Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Mon, 07 Mar 2005 20:14:10 -0500 Subject: [Isms] What are people's objections to TLSM X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 Hi. Reading the comparison document, I notice that TLSM seems to not be considered very seriously. In addition, the presentation for TLSM at IETF 61 said that even the presenters didn't consider it seriously. Asking as an individual, not as an AD, why is that the case? Could someone help me understand what the disadvantages of TLSM are? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 20:16: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 UAA03465; Mon, 7 Mar 2005 20:16:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TNa-0005g7-0o; Mon, 07 Mar 2005 20: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 1D8TIa-0002Oc-4k; Mon, 07 Mar 2005 20:14:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8QPA-0004cC-1x for isms@megatron.ietf.org; Mon, 07 Mar 2005 17:08: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 RAA09461 for ; Mon, 7 Mar 2005 17:08:45 -0500 (EST) Received: from wireless-130-129-135-90.ietf62.ietf.org ([130.129.135.90] helo=cz.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8QRP-00083O-Mn for isms@ietf.org; Mon, 07 Mar 2005 17:11:08 -0500 Received: by cz.mit.edu (Postfix, from userid 8042) id 42F9AE0063; Mon, 7 Mar 2005 17:08:42 -0500 (EST) To: Ken Hornstein Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) References: <200503071932.j27JWTUX017472@ginger.cmf.nrl.navy.mil> From: Sam Hartman Date: Mon, 07 Mar 2005 17:08:42 -0500 In-Reply-To: <200503071932.j27JWTUX017472@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Mon, 07 Mar 2005 14:32:29 -0500") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 07 Mar 2005 20:14:10 -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.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 >>>>> "Ken" == Ken Hornstein writes: >> IKE is a well-analyzed Key Exchange protocol, whose entire job >> is to just authenticate end-points, agree on SA parameters and >> generate keys (not encumbered by other functionality). >> >> I would strongly object to re-inventing key exchange >> protocol. I'd strongly support a minimal explicit interface to >> something like IKE. I want to emphasize, that even INTEGRATING >> an EXISTING GOOD Key Exchange protocol is non-trivial and >> tricky enough. Ken> I definately agree that IKE is well-analyzed (maybe not Ken> universally well-understood, though :-) ). I have one Ken> question, though. Of course IKE is used by IPsec, but is it Ken> used by other application-level protocols for key exchange? IKE also has an applicability statement. IKE, particularly IKEv2 is only for IPsec. So, if you use IKE, expect to use IPsec. I suggest that IPsec is a bad fit for your application. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 7 20: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 UAA04819; Mon, 7 Mar 2005 20:32:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TcD-00060n-Vd; Mon, 07 Mar 2005 20:34:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8TYl-0004DG-6S; Mon, 07 Mar 2005 20:30:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8TYk-0004DB-3g for isms@megatron.ietf.org; Mon, 07 Mar 2005 20:30: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 UAA04755 for ; Mon, 7 Mar 2005 20:30:51 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Tb1-0005zA-Iy for isms@ietf.org; Mon, 07 Mar 2005 20:33:15 -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 j281UfH27819 for ; Mon, 7 Mar 2005 20:30:41 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Mar 2005 20:30:41 -0500 Message-ID: <713043CE8B8E1348AF3C546DBE02C1B402BBC37B@zcarhxm2.corp.nortel.com> From: "Sharon Chisholm" To: isms@ietf.org Subject: RE: [Isms] What are people's objections to TLSM Date: Mon, 7 Mar 2005 20:30:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============2015816829==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede 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. --===============2015816829== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5237E.6C85F5CA" 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_01C5237E.6C85F5CA Content-Type: text/plain hi >From my perspective, it does not seem to provide much value over just running SNMP over TLS or IPsec, but does require creation of a new, albeit thin, security model. Sharon -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman Sent: Sunday, March 06, 2005 10:09 AM To: isms@ietf.org Subject: [Isms] What are people's objections to TLSM Hi. Reading the comparison document, I notice that TLSM seems to not be considered very seriously. In addition, the presentation for TLSM at IETF 61 said that even the presenters didn't consider it seriously. Asking as an individual, not as an AD, why is that the case? Could someone help me understand what the disadvantages of TLSM are? _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C5237E.6C85F5CA Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] What are people's objections to TLSM

hi

From my perspective, it does not seem to provide much = value over just running SNMP over TLS or IPsec, but does require = creation of a new, albeit thin, security model.

Sharon

-----Original Message-----
From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On Behalf Of Sam Hartman
Sent: Sunday, March 06, 2005 10:09 AM
To: isms@ietf.org
Subject: [Isms] What are people's objections to = TLSM




Hi.  Reading the comparison document, I notice = that TLSM seems to not be considered very seriously.  In addition, = the presentation for TLSM at IETF 61 said that even the presenters = didn't consider it seriously.

Asking as an individual, not as an AD, why is that = the case?  Could someone help me understand what the disadvantages = of TLSM are?


_______________________________________________
Isms mailing list
Isms@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C5237E.6C85F5CA-- --===============2015816829== 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 --===============2015816829==-- From isms-bounces@ietf.org Mon Mar 7 20:53: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 UAA06833; Mon, 7 Mar 2005 20:53:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Tws-0006UO-Dt; Mon, 07 Mar 2005 20:55:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Trt-00065H-TN; Mon, 07 Mar 2005 20:50:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Trt-00065C-Di for isms@megatron.ietf.org; Mon, 07 Mar 2005 20:50: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 UAA06385 for ; Mon, 7 Mar 2005 20:50:39 -0500 (EST) Message-Id: <200503080150.UAA06385@ietf.org> Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TuA-0006P6-JZ for isms@ietf.org; Mon, 07 Mar 2005 20:53:04 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc11) with SMTP id <20050308015028011005q9fre>; Tue, 8 Mar 2005 01:50:28 +0000 From: "David B Harrington" To: "'Sam Hartman'" , Subject: RE: [Isms] What are people's objections to TLSM Date: Mon, 7 Mar 2005 20:50:23 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcUjfHN2BhnFcDegRNy/zPd98eMZGQAAxHRg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Hi, TLSM only solves some of the problems that need to be solved, and may be difficult to solve the ones it does solve. Transport level security (TLS or other protocols) is useful for securing the message, but many transport layer security protocols authenticate against a host, not a user. It is important to use security models that will provide user-authentication for use with SNMP authorization (e.g. VACM). Second, the user identity need sto be mapped to an authorization policy, e.g. VACM groups. Transport layer security protocols generally don't provide any mechanism for identifying an authorization policy associated with the authenticated user. So even if the message was secured by TLSM, you might still need to have a RADIUS or other approach to provide the mapping between authetication and authorization. Part of my reasons for not strongly pushing TLSM at the last meeting was simply that all three approaches appeared viable, and I suggested dropping TLSM to winnow the field. That said, I have given more thought to TLSM and like the leveraging of existing infrastructure to secure messages that TLS, SASL, or SSH provide. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Sam Hartman > Sent: Sunday, March 06, 2005 10:09 AM > To: isms@ietf.org > Subject: [Isms] What are people's objections to TLSM > > > > Hi. Reading the comparison document, I notice that TLSM seems to not > be considered very seriously. In addition, the presentation for TLSM > at IETF 61 said that even the presenters didn't consider it seriously. > > Asking as an individual, not as an AD, why is that the case? Could > someone help me understand what the disadvantages of TLSM are? > > > _______________________________________________ > 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 Mar 8 01:52: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 BAA29553; Tue, 8 Mar 2005 01:52:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8YcP-0004Sa-8s; Tue, 08 Mar 2005 01: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 1D8YWN-0002iq-UM; Tue, 08 Mar 2005 01:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8YWM-0002hT-5A for isms@megatron.ietf.org; Tue, 08 Mar 2005 01:48: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 BAA29287 for ; Tue, 8 Mar 2005 01:48:44 -0500 (EST) Received: from ia981.i.pppool.de ([85.73.169.129] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8YYg-0004Mw-I3 for isms@ietf.org; Tue, 08 Mar 2005 01:51:11 -0500 Received: by boskop.local (Postfix, from userid 501) id 234E11DECE6; Tue, 8 Mar 2005 07:48:31 +0100 (CET) Date: Tue, 8 Mar 2005 07:48:30 +0100 From: Juergen Schoenwaelder To: Sam Hartman Subject: Re: [Isms] What are people's objections to TLSM Message-ID: <20050308064830.GA19892@boskop.local> Mail-Followup-To: Sam Hartman , isms@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Sun, Mar 06, 2005 at 10:09:22AM -0500, Sam Hartman wrote: > Hi. Reading the comparison document, I notice that TLSM seems to not > be considered very seriously. In addition, the presentation for TLSM > at IETF 61 said that even the presenters didn't consider it seriously. > > Asking as an individual, not as an AD, why is that the case? Could > someone help me understand what the disadvantages of TLSM are? TLSM breaks with one of the many holy myths of SNMP, namely that SNMP must not rely on other services to be functional when the network burns. I personally do not believe in this myths as I have never met someone who really uses SNMP to bring a network back into operational state when the network burns. (But perhaps I am just talking to the wrong people. ;-) My fear is basically that pushing for TLSM may yield another instance of this "you are not allowed to break SNMP myths" discussions which I have experienced before and I prefer to stay away from. [For those not familiar with the SNMP history, you may want to read the "Towards Useful Management" published almost nine(!) years ago in the July 1996 issue of the Simple Times: http://www.simple-times.org/pub/simple-times/issues/4-3.html] In practical terms, the only security mechanism having a chance to be deployed in environments I am familiar with is one that uses a security protocol and authentication mechanism that is already well understood and deployed. /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 Tue Mar 8 01:57: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 BAA00009; Tue, 8 Mar 2005 01:57:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8YhT-0004bA-3H; Tue, 08 Mar 2005 02:00:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Yds-0003VG-Dl; Tue, 08 Mar 2005 01:56:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Ydq-0003UW-Gw for isms@megatron.ietf.org; Tue, 08 Mar 2005 01:56: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 BAA29853 for ; Tue, 8 Mar 2005 01:56:29 -0500 (EST) Received: from ia981.i.pppool.de ([85.73.169.129] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8YgB-0004YG-JY for isms@ietf.org; Tue, 08 Mar 2005 01:58:56 -0500 Received: by boskop.local (Postfix, from userid 501) id 1D9AD1DED05; Tue, 8 Mar 2005 07:56:20 +0100 (CET) Date: Tue, 8 Mar 2005 07:56:20 +0100 From: Juergen Schoenwaelder To: David B Harrington Subject: Re: [Isms] What are people's objections to TLSM Message-ID: <20050308065620.GB19892@boskop.local> Mail-Followup-To: David B Harrington , 'Sam Hartman' , isms@ietf.org References: <200503080150.UAA06385@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503080150.UAA06385@ietf.org> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "'Sam Hartman'" , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 On Mon, Mar 07, 2005 at 08:50:23PM -0500, David B Harrington wrote: > Transport level security (TLS or other protocols) is useful for > securing the message, but many transport layer security protocols > authenticate against a host, not a user. I am not sure this statement is generally true. I do authenticate as a user using ssh. I do authenticate as a user using TLS, typically in combination with SASL (which is considered to be broken but I guess fixing this will happen anyways). The more important point with all these alternatives is hat they are all stream based and assume TCP as a transport. Running SNMP over TCP touches another myths. I am not sure DTLS is such an appealing alternative - someone needs to carefully analyze the number of round trips needed and the amount of state information needed for the DTLS session in an SNMP context. My fuzzy reading of the specs made me believe that things might become close to running SNMP over TCP, but I can't claim that I do understand the details. As a code writer, I love to have a solution which allows me to pick an already available and debugged library which I can simply link against to get a viable solution. /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 Tue Mar 8 08:28: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 IAA22321; Tue, 8 Mar 2005 08:28:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8end-0004LB-3j; Tue, 08 Mar 2005 08:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8el0-0000tx-6u; Tue, 08 Mar 2005 08:28:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ekz-0000ts-I8 for isms@megatron.ietf.org; Tue, 08 Mar 2005 08:28: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 IAA22297 for ; Tue, 8 Mar 2005 08:28:15 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8enM-0004Kq-Pb for isms@ietf.org; Tue, 08 Mar 2005 08:30:46 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id F0F3C17045; Tue, 8 Mar 2005 05:32:04 -0800 (PST) To: David B Harrington Subject: Re: [Isms] What are people's objections to TLSM References: <200503080150.UAA06385@ietf.org> <20050308065620.GB19892@boskop.local> From: Eric Rescorla Date: Tue, 08 Mar 2005 05:32:04 -0800 In-Reply-To: <20050308065620.GB19892@boskop.local> (Juergen Schoenwaelder's message of "Tue, 8 Mar 2005 07:56:20 +0100") Message-ID: <86mztefeln.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: "'Sam Hartman'" , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Juergen Schoenwaelder writes: > The more important point with all these alternatives is hat they are > all stream based and assume TCP as a transport. Running SNMP over > TCP touches another myths. I am not sure DTLS is such an appealing > alternative - someone needs to carefully analyze the number of round > trips needed Two (or three if you want the anti-DoS protection). This is pretty much the standard number for this kind of protocol. > and the amount of state information needed for the DTLS > session in an SNMP context. 4 session keys and whatever identity information you hang off them, pretty much the same as with any protocol of this kind. > As a code writer, I love to have a solution which allows me to pick > an already available and debugged library which I can simply link > against to get a viable solution. We're working on this, but there's already a working version checked into reSIProcate: http://list.sipfoundry.org/archive/resiprocate-devel/msg01674.html -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 08:33: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 IAA22598; Tue, 8 Mar 2005 08:33:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8esT-0004PD-4J; Tue, 08 Mar 2005 08:36:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8epV-00017s-Lb; Tue, 08 Mar 2005 08:32:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8epU-00017n-H0 for isms@megatron.ietf.org; Tue, 08 Mar 2005 08:32: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 IAA22571 for ; Tue, 8 Mar 2005 08:32:54 -0500 (EST) Received: from zrtps0kn.nortelnetworks.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ert-0004Oh-0T for isms@ietf.org; Tue, 08 Mar 2005 08:35:25 -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 j28DWW217591; Tue, 8 Mar 2005 08:32:32 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 8 Mar 2005 08:32:33 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2BA87@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Sam Hartman'" , Ken Hornstein Subject: RE: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Tue, 8 Mar 2005 08:32:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 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="===============0791124780==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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. --===============0791124780== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C523E3.3F3A8CE4" 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_01C523E3.3F3A8CE4 Content-Type: text/plain I didn't think EAP tunnelled within SNMP was the goal, did you read a different I-D than I did? The EAP traffic is out-of-band from the SNMP traffic in eUSM. I also don't understand your IKE applicability statement. My understanding is that IKE is limited to "authenticated exchange of keying material and associated policy information between the end-points of a security association". This is specifically the scope being discussed in ISMS. Martin. > -----Original Message----- > From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On > Behalf Of Sam Hartman > Sent: March 7, 2005 5:11 PM > To: Ken Hornstein > Cc: isms@ietf.org > Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) > > >>>>> "Ken" == Ken Hornstein writes: > > >> I am sorry I could not respond to this earlier, but I think > >> this was discussed earlier, in January; Bernard Aboba wrote a > >> number of options to this list on how to use EAP with due nod > >> to the RFC 3748 applicability statement. > > Ken> I don't recall this email, but nevertheless ... > > Ken> There seems to be a lot of concern at the IESG about using > Ken> EAP for things it wasn't intended to be used for (and I don't > Ken> think that EAP was ever intended to secure SNMP). If the WG > Ken> decides that it wants to select EUSM and use EAP (EUSM may be > Ken> an option if you don't use EAP), I think we will be facing an > Ken> uphill battle in the IESG. I know what Bernard said in the > Ken> email you provided, but I got a very different impression > Ken> from Sam during our teleconference. > > Hmm, I actually think what I'm saying is consistent with what Bernard > is saying. > > When I pointed out to Bernard that using EAP tunneled within SNMP was > the goal, he agreed that fell outside the applicability statement. > > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms ------_=_NextPart_001_01C523E3.3F3A8CE4 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Late Surprise: EAP is not appropriate for ISMS = (fwd)

I didn't think EAP tunnelled within SNMP was the = goal, did you read a different I-D than I did? The EAP traffic is = out-of-band from the SNMP traffic in eUSM.

I also don't understand your IKE applicability = statement. My understanding is that IKE is limited to = "authenticated exchange of keying material and associated policy = information between the end-points of a security association". = This is specifically the scope being discussed in ISMS.

Martin.

> -----Original Message-----
> From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ie= tf.org] On
> Behalf Of Sam Hartman
> Sent: March 7, 2005 5:11 PM
> To: Ken Hornstein
> Cc: isms@ietf.org
> Subject: Re: [Isms] Late Surprise: EAP is not = appropriate for ISMS (fwd)
>
> >>>>> "Ken" =3D=3D Ken = Hornstein <kenh@cmf.nrl.navy.mil> writes:
>
>     >> I am sorry I = could not respond to this earlier, but I think
>     >> this was = discussed earlier, in January; Bernard Aboba wrote a
>     >> number of = options to this list on how to use EAP with due nod
>     >> to the RFC = 3748 applicability statement.
>
>     Ken> I don't recall = this email, but nevertheless ...
>
>     Ken> There seems to = be a lot of concern at the IESG about using
>     Ken> EAP for things = it wasn't intended to be used for (and I don't
>     Ken> think that EAP = was ever intended to secure SNMP).  If the WG
>     Ken> decides that it = wants to select EUSM and use EAP (EUSM may be
>     Ken> an option if = you don't use EAP), I think we will be facing an
>     Ken> uphill battle = in the IESG.  I know what Bernard said in the
>     Ken> email you = provided, but I got a very different impression
>     Ken> from Sam during = our teleconference.
>
> Hmm, I actually think what I'm saying is = consistent with what Bernard
> is saying.
>
> When I pointed out to Bernard that using EAP = tunneled within SNMP was
> the goal, he agreed that fell outside the = applicability statement.
>
>
> = _______________________________________________
> Isms mailing list
> Isms@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/isms=

------_=_NextPart_001_01C523E3.3F3A8CE4-- --===============0791124780== 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 --===============0791124780==-- From isms-bounces@ietf.org Tue Mar 8 09:32: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 JAA27123; Tue, 8 Mar 2005 09:32:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fnY-0005bh-ID; Tue, 08 Mar 2005 09:35:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8fko-0005Iu-CL; Tue, 08 Mar 2005 09:32:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8fkn-0005Id-EF for isms@megatron.ietf.org; Tue, 08 Mar 2005 09:32: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 JAA27064 for ; Tue, 8 Mar 2005 09:32:07 -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 1D8fnB-0005aM-HH for isms@ietf.org; Tue, 08 Mar 2005 09:34:38 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 Mar 2005 07:49:00 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107734400"; d="scan'208"; a="232599141:sNHT19021088" 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 j28EVsq8018619; Tue, 8 Mar 2005 06:31:54 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn1-324.cisco.com [10.21.97.68]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYV69341; Tue, 8 Mar 2005 06:31:52 -0800 (PST) Message-Id: <6.2.0.14.0.20050308082808.03fa4100@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 08:31:52 -0600 To: Sam Hartman From: Kaushik Narayan Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: References: <200503071720.j27HKRgI014250@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Hi Sam, Please find my reply inline. >Hmm, I actually think what I'm saying is consistent with what Bernard >is saying. > >When I pointed out to Bernard that using EAP tunneled within SNMP was >the goal, he agreed that fell outside the applicability statement. EUSM does not tunnel EAP within SNMP. EAP is used as defined over UDP or Layer 2 (as and when SNMP is used in a non-IP environment). EAP is used to setup Keys between two hosts running SNMP engines based on authentication via credentials such as X.509 certs, Kerberos, shared secrets or passwords stored on a RADIUS server. The SNMP engines running on these hosts then acquire these keys to be used for securing SNMP via mechanisms as defined today in SNMPv3. EUSM trying to fix the integration problem with least amount change to both to SNMP and to existing security protocols, this is important since churning the SNMP protocol by introducing extensive new packet processing is going further increase the barrier for use of SNMPv3. I was want to point out the EUSM can work with EAP and RADIUS without any change to either RADIUS or EAP. regards, kaushik! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 09:42: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 JAA28133; Tue, 8 Mar 2005 09:42:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fwn-0005r3-5z; Tue, 08 Mar 2005 09:44:33 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8fqS-0005g3-Co; Tue, 08 Mar 2005 09:38:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8fqR-0005fy-6B for isms@megatron.ietf.org; Tue, 08 Mar 2005 09:37: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 JAA27513 for ; Tue, 8 Mar 2005 09:37:57 -0500 (EST) Received: from fmr15.intel.com ([192.55.52.69] helo=fmsfmr005.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8fsq-0005hd-9U for isms@ietf.org; Tue, 08 Mar 2005 09:40:28 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr005.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc,v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j28EbYVQ007115; Tue, 8 Mar 2005 14:37:34 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 j28Eb9xg028206; Tue, 8 Mar 2005 14:37:33 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs043.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005030806373320526 ; Tue, 08 Mar 2005 06:37:33 -0800 Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 06:37:33 -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, 8 Mar 2005 06:37:33 -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, 8 Mar 2005 09:37:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Tue, 8 Mar 2005 09:37:20 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929CA19E0@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Thread-Index: AcUjTL3ZKJyP2dqXQ3WwpGG/B+suTgAnxWdQ From: "Blumenthal, Uri" To: "Ken Hornstein" , X-OriginalArrivalTime: 08 Mar 2005 14:37:31.0875 (UTC) FILETIME=[5C5C8B30:01C523EC] X-Scanned-By: MIMEDefang 2.44 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 You wouldn't be able to use existing TLS libraries any more than you'd be able to use existing IKE implementation. You'd need to hack either one to make it working with SNMP, doing what you need in addition to (or instead of) what it's doing out-of-box. -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Ken Hornstein Sent: Monday, March 07, 2005 2:32 PM To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) >IKE is a well-analyzed Key Exchange protocol, whose entire job is to >just authenticate end-points, agree on SA parameters and generate keys >(not encumbered by other functionality). > >I would strongly object to re-inventing key exchange protocol. I'd >strongly support a minimal explicit interface to something like IKE. >I want to emphasize, that even INTEGRATING an EXISTING GOOD Key=20 >Exchange protocol is non-trivial and tricky enough. I definately agree that IKE is well-analyzed (maybe not universally well-understood, though :-) ). I have one question, though. Of course IKE is used by IPsec, but is it used by other application-level protocols for key exchange? The reason I ask is that if it's not, then I think that would definately increase the implementation burden if the WG decided to use it. The reason is that while a particular box may ship with IPsec, it won't necessarily make an API available to where applications can use IKE directly, thus forcing implementors to re-implement all of IKE. Now of course you'd need to implement all of SBSM yourself, for example, but with something like TLSM you'd be able to make use of existing TLS libraries that are used by plenty of applications today. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 10:28: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 KAA05848; Tue, 8 Mar 2005 10:28:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gfm-0007Is-5d; Tue, 08 Mar 2005 10:31:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8gd4-00040k-O5; Tue, 08 Mar 2005 10:28:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8gd2-00040a-M3 for isms@megatron.ietf.org; Tue, 08 Mar 2005 10: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 KAA05817 for ; Tue, 8 Mar 2005 10:28:10 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gfR-0007IR-GU for isms@ietf.org; Tue, 08 Mar 2005 10:30:42 -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 j28FS5fH002498 for ; Tue, 8 Mar 2005 10:28:05 -0500 (EST) Message-Id: <200503081528.j28FS5fH002498@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <6.2.0.14.0.20050308082808.03fa4100@mira-sjc5-a.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 08 Mar 2005 10:28:05 -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: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 >EUSM does not tunnel EAP within SNMP. EAP is used as defined over > UDP or Layer 2 (as and when SNMP is used in a non-IP environment). >EAP is used to setup Keys between two hosts running SNMP engines >based on authentication via credentials such as X.509 certs, Kerberos, >shared secrets or passwords stored on a RADIUS server. Did you see my previous email on this subject? Specifically, you seem to be relying on using Kerberos cipher suites for TLS for the Kerberos authentication. It's unclear to me how these keys relate to EAP (in fact, I'm not even sure what the purpose is of EAP in this mode). The same is true for X.509. This is completely distinct from the fact that Kerberos cipher suites for TLS is notoriously under-supported. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 10:29: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 KAA05995; Tue, 8 Mar 2005 10:29:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ggm-0007KE-TA; Tue, 08 Mar 2005 10:32:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8geG-0004Fr-J8; Tue, 08 Mar 2005 10: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 1D8geG-0004Fg-0g for isms@megatron.ietf.org; Tue, 08 Mar 2005 10:29: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 KAA05985 for ; Tue, 8 Mar 2005 10:29:25 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gge-0007K5-Js for isms@ietf.org; Tue, 08 Mar 2005 10:31:58 -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 j28FTKGZ002526 for ; Tue, 8 Mar 2005 10:29:21 -0500 (EST) Message-Id: <200503081529.j28FTKGZ002526@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <3DEC199BD7489643817ECA151F7C5929CA19E0@pysmsx401.amr.corp.intel.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 08 Mar 2005 10:29:20 -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: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 >You wouldn't be able to use existing TLS libraries any more than you'd >be able to use existing IKE implementation. You'd need to hack either >one to make it working with SNMP, doing what you need in addition to (or >instead of) what it's doing out-of-box. I'm not sure I agree. Assuming we _weren't_ using DTLS, and we were doing SNMP-over-TCP, I can't honestly see why you couldn't use a "stock" TLS library (based on the little TLS programming I have done). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 10:34: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 KAA07010; Tue, 8 Mar 2005 10:34:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8glw-0007U1-8h; Tue, 08 Mar 2005 10:37:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8giD-0004w0-8O; Tue, 08 Mar 2005 10:33:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8giC-0004vt-2e for isms@megatron.ietf.org; Tue, 08 Mar 2005 10:33: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 KAA06818 for ; Tue, 8 Mar 2005 10:33:29 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gkb-0007RS-T1 for isms@ietf.org; Tue, 08 Mar 2005 10:36:02 -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 j28FXQLM002614 for ; Tue, 8 Mar 2005 10:33:26 -0500 (EST) Message-Id: <200503081533.j28FXQLM002614@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] What are people's objections to TLSM In-Reply-To: <20050308065620.GB19892@boskop.local> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 08 Mar 2005 10:33:26 -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: 68c8cc8a64a9d0402e43b8eee9fc4199 X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 >I am not sure this statement is generally true. I do authenticate as a >user using ssh. I do authenticate as a user using TLS, typically in >combination with SASL (which is considered to be broken but I guess >fixing this will happen anyways). I think what is really happening is that you're encrypting with TLS, but you're authenticating with SASL. While this isn't as perfect as crypto weenies like me would like, it has the advantage of supporting a bunch of mechanisms (enough that I think it would meet the needs of most everbody) and it's well understood. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 12:46: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 MAA24973; Tue, 8 Mar 2005 12:46:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ipX-000318-Mw; Tue, 08 Mar 2005 12:49:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8imk-0000r8-33; Tue, 08 Mar 2005 12:46:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8imi-0000qz-TV for isms@megatron.ietf.org; Tue, 08 Mar 2005 12:46: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 MAA24946 for ; Tue, 8 Mar 2005 12:46:17 -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 1D8ip8-00030W-Oi for isms@ietf.org; Tue, 08 Mar 2005 12:48:52 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 08 Mar 2005 10:00:11 -0800 Received: from E2K-SEA-XCH2.sea-alpha.cisco.com (e2k-sea-xch2.cisco.com [10.93.132.68]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j28Hk5q8024565; Tue, 8 Mar 2005 09:46:05 -0800 (PST) content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Date: Tue, 8 Mar 2005 09:49:13 -0800 Message-ID: <7210B31550AC934A8637D6619739CE6904CE86D0@e2k-sea-xch2.sea-alpha.cisco.com> Thread-Topic: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) Thread-Index: AcUj9Bww1DCemVeeT7exL2kZeXjGMwAEKHKQ From: "Salowey, Joe" To: "Ken Hornstein" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable =20 > -----Original Message----- > From: Ken Hornstein [mailto:kenh@cmf.nrl.navy.mil]=20 > Sent: Tuesday, March 08, 2005 7:28 AM > To: isms@ietf.org > Subject: Re: [Isms] Late Surprise: EAP is not appropriate for=20 > ISMS (fwd)=20 >=20 > >EUSM does not tunnel EAP within SNMP. EAP is used as defined over > > UDP or Layer 2 (as and when SNMP is used in a non-IP environment). > >EAP is used to setup Keys between two hosts running SNMP=20 > engines based=20 > >on authentication via credentials such as X.509 certs,=20 > Kerberos, shared=20 > >secrets or passwords stored on a RADIUS server. >=20 > Did you see my previous email on this subject? >=20 > Specifically, you seem to be relying on using Kerberos cipher=20 > suites for TLS for the Kerberos authentication. It's unclear=20 > to me how these keys relate to EAP (in fact, I'm not even=20 > sure what the purpose is of EAP in this mode).=20 > The same is=20 > true for X.509. =20 [Joe] I'm not quite sure what your question is, but I think you're asking what EAP-TLS does in addition to TLS. EAP-TLS defines a way to derive keys from the TLS master secret that can be exported from the TLS layer for use elsewhere and it also provides fragmentation support (which might not be too useful in this case). EAP also provides a way to negotiate other authentication mechanism besides EAP-TLS. If EAP were not used in this mode some other way of exchanging keys would have to be defined (perhaps by exchanging keys in the TLS session itself). =20 > This is completely distinct from the fact=20 > that Kerberos cipher suites for TLS is notoriously under-supported. >=20 > --Ken >=20 > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms >=20 _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 13:10: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 NAA27262; Tue, 8 Mar 2005 13:10:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jCg-0003VL-P3; Tue, 08 Mar 2005 13:13:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8j8R-0002rN-2x; Tue, 08 Mar 2005 13:08:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8j8P-0002rF-9N for isms@megatron.ietf.org; Tue, 08 Mar 2005 13:08: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 NAA27099 for ; Tue, 8 Mar 2005 13:08:42 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8jAp-0003Tr-Al for isms@ietf.org; Tue, 08 Mar 2005 13:11:16 -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 j28I8aWS005762 for ; Tue, 8 Mar 2005 13:08:36 -0500 (EST) Message-Id: <200503081808.j28I8aWS005762@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <7210B31550AC934A8637D6619739CE6904CE86D0@e2k-sea-xch2.sea-alpha.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 08 Mar 2005 13:08:36 -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: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 856eb5f76e7a34990d1d457d8e8e5b7f >[Joe] I'm not quite sure what your question is, but I think you're >asking what EAP-TLS does in addition to TLS. EAP-TLS defines a way to >derive keys from the TLS master secret that can be exported from the TLS >layer for use elsewhere and it also provides fragmentation support >(which might not be too useful in this case). EAP also provides a way to >negotiate other authentication mechanism besides EAP-TLS. If EAP were >not used in this mode some other way of exchanging keys would have to be >defined (perhaps by exchanging keys in the TLS session itself). I'm asking what EAP-TLS gets me if I'm using Kerberos (since presumably I can simply derive keys directly from Kerberos). --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 14:30: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 OAA04764; Tue, 8 Mar 2005 14:30:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kSN-0005MW-8z; Tue, 08 Mar 2005 14:33:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kO9-0001N6-Bg; Tue, 08 Mar 2005 14:29:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kO8-0001N1-AY for isms@megatron.ietf.org; Tue, 08 Mar 2005 14:29: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 OAA04533 for ; Tue, 8 Mar 2005 14:29:01 -0500 (EST) Received: from i935f.i.pppool.de ([85.73.147.95] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kQY-0005Ji-8c for isms@ietf.org; Tue, 08 Mar 2005 14:31:35 -0500 Received: by boskop.local (Postfix, from userid 501) id 799751DF2C2; Tue, 8 Mar 2005 16:30:06 +0100 (CET) Date: Tue, 8 Mar 2005 16:30:06 +0100 From: Juergen Schoenwaelder To: Eric Rescorla Subject: Re: [Isms] What are people's objections to TLSM Message-ID: <20050308153006.GA20789@boskop.local> Mail-Followup-To: Eric Rescorla , David B Harrington , 'Sam Hartman' , isms@ietf.org References: <200503080150.UAA06385@ietf.org> <20050308065620.GB19892@boskop.local> <86mztefeln.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86mztefeln.fsf@romeo.rtfm.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.7 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "'Sam Hartman'" , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.7 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 On Tue, Mar 08, 2005 at 05:32:04AM -0800, Eric Rescorla wrote: > > I am not sure DTLS is such an appealing > > alternative - someone needs to carefully analyze the number of round > > trips needed > Two (or three if you want the anti-DoS protection). This is pretty > much the standard number for this kind of protocol. > > > and the amount of state information needed for the DTLS > > session in an SNMP context. > 4 session keys and whatever identity information you hang off them, > pretty much the same as with any protocol of this kind. Another question: How much overhead will DTLS consume in terms of number of bytes in a UDP packet? How much space will be left for SNMP payload? /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 Tue Mar 8 14:37: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 OAA05532; Tue, 8 Mar 2005 14:37:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kYi-0005WX-5d; Tue, 08 Mar 2005 14:40:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kUY-0001n4-UH; Tue, 08 Mar 2005 14:35:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kUX-0001mv-Lv for isms@megatron.ietf.org; Tue, 08 Mar 2005 14:35: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 OAA05234 for ; Tue, 8 Mar 2005 14:35:40 -0500 (EST) Received: from romeo.rtfm.com ([198.144.203.242]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kWy-0005SW-Bj for isms@ietf.org; Tue, 08 Mar 2005 14:38:13 -0500 Received: by romeo.rtfm.com (Postfix, from userid 1001) id 664BF1704D; Tue, 8 Mar 2005 11:39:39 -0800 (PST) To: David B Harrington Subject: Re: [Isms] What are people's objections to TLSM References: <200503080150.UAA06385@ietf.org> <20050308065620.GB19892@boskop.local> <86mztefeln.fsf@romeo.rtfm.com> <20050308153006.GA20789@boskop.local> From: Eric Rescorla Date: Tue, 08 Mar 2005 11:39:39 -0800 In-Reply-To: <20050308153006.GA20789@boskop.local> (Juergen Schoenwaelder's message of "Tue, 8 Mar 2005 16:30:06 +0100") Message-ID: <86u0nmdj0k.fsf@romeo.rtfm.com> User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Security Through Obscurity, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "'Sam Hartman'" , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Juergen Schoenwaelder writes: > On Tue, Mar 08, 2005 at 05:32:04AM -0800, Eric Rescorla wrote: >> > I am not sure DTLS is such an appealing >> > alternative - someone needs to carefully analyze the number of round >> > trips needed >> Two (or three if you want the anti-DoS protection). This is pretty >> much the standard number for this kind of protocol. >> >> > and the amount of state information needed for the DTLS >> > session in an SNMP context. >> 4 session keys and whatever identity information you hang off them, >> pretty much the same as with any protocol of this kind. > > Another question: How much overhead will DTLS consume in terms of number > of bytes in a UDP packet? How much space will be left for SNMP payload? With AES, order 50 bytes. This really isn't an issue of DTLS vs. ISMS vs. USM. Basically, if you want to provide security for datagram packets, there's kind of a minimum amount of overhead for any given set of algorithms. All of these protocols are about equally efficient. -Ekr _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 14:45: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 OAA06532; Tue, 8 Mar 2005 14:45:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kgo-0005qB-5F; Tue, 08 Mar 2005 14:48:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kdI-0003Ot-TX; Tue, 08 Mar 2005 14:44:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8kdH-0003Ns-9c for isms@megatron.ietf.org; Tue, 08 Mar 2005 14:44: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 OAA06394 for ; Tue, 8 Mar 2005 14:44:41 -0500 (EST) Received: from i935f.i.pppool.de ([85.73.147.95] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kfj-0005ma-2X for isms@ietf.org; Tue, 08 Mar 2005 14:47:15 -0500 Received: by boskop.local (Postfix, from userid 501) id 3FA4A1DF45A; Tue, 8 Mar 2005 20:44:33 +0100 (CET) Date: Tue, 8 Mar 2005 20:44:33 +0100 From: Juergen Schoenwaelder To: Eric Rescorla Subject: Re: [Isms] What are people's objections to TLSM Message-ID: <20050308194433.GC21208@boskop.local> Mail-Followup-To: Eric Rescorla , David B Harrington , 'Sam Hartman' , isms@ietf.org References: <200503080150.UAA06385@ietf.org> <20050308065620.GB19892@boskop.local> <86mztefeln.fsf@romeo.rtfm.com> <20050308153006.GA20789@boskop.local> <86u0nmdj0k.fsf@romeo.rtfm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86u0nmdj0k.fsf@romeo.rtfm.com> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: "'Sam Hartman'" , isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@iu-bremen.de List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a On Tue, Mar 08, 2005 at 11:39:39AM -0800, Eric Rescorla wrote: > > Another question: How much overhead will DTLS consume in terms of number > > of bytes in a UDP packet? How much space will be left for SNMP payload? > > With AES, order 50 bytes. > > This really isn't an issue of DTLS vs. ISMS vs. USM. > > Basically, if you want to provide security for datagram packets, > there's kind of a minimum amount of overhead for any given set > of algorithms. All of these protocols are about equally > efficient. Well, I know what USM does and I just want to understand what DTLS would do (or any other protocol running over UDP). I am really just trying to learn (and I apologize that it is about three months ago that I last looked into the DTLS draft and that my memory is rather short term). /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 Tue Mar 8 15:28: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 PAA14662; Tue, 8 Mar 2005 15:28:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lMK-0007wd-KZ; Tue, 08 Mar 2005 15:31:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lGL-0005P1-Ko; Tue, 08 Mar 2005 15:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lGK-0005Ol-4G for isms@megatron.ietf.org; Tue, 08 Mar 2005 15:25: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 PAA14066 for ; Tue, 8 Mar 2005 15:25:02 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lIl-0007n9-Dy for isms@ietf.org; Tue, 08 Mar 2005 15:27:36 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 08 Mar 2005 12:25:17 -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-4.cisco.com (8.12.10/8.12.6) with ESMTP id j28KOnYO017521; Tue, 8 Mar 2005 12:24:49 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn6-91.cisco.com [10.21.120.91]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYW11796; Tue, 8 Mar 2005 12:24:48 -0800 (PST) Message-Id: <6.2.0.14.0.20050308142216.03836548@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 14:24:46 -0600 To: Ken Hornstein From: Kaushik Narayan Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <200503081808.j28I8aWS005762@ginger.cmf.nrl.navy.mil> References: <7210B31550AC934A8637D6619739CE6904CE86D0@e2k-sea-xch2.sea-alpha.cisco.com> <200503081808.j28I8aWS005762@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Ken, At 12:08 PM 3/8/2005, Ken Hornstein wrote: > >[Joe] I'm not quite sure what your question is, but I think you're > >asking what EAP-TLS does in addition to TLS. EAP-TLS defines a way to > >derive keys from the TLS master secret that can be exported from the TLS > >layer for use elsewhere and it also provides fragmentation support > >(which might not be too useful in this case). EAP also provides a way to > >negotiate other authentication mechanism besides EAP-TLS. If EAP were > >not used in this mode some other way of exchanging keys would have to be > >defined (perhaps by exchanging keys in the TLS session itself). > >I'm asking what EAP-TLS gets me if I'm using Kerberos (since presumably >I can simply derive keys directly from Kerberos). EAP provides an authentication framework to support multiple authentication mechanisms. We can use Kerberos directly to derive keys but using EAP provides us the ability to support other authentication mechanisms as well. Now specifically with regards to use of EAP-TLS, TLS is being used for Kerberos authentication using Kerberos cipher suites. There are other EAP methods such as a EAP-GSS method that might be used for Kerberos but EAP-GSS does not exist right now. regards, kaushik! >--Ken > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 15:37: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 PAA17024; Tue, 8 Mar 2005 15:37:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lV0-00008Q-Gx; Tue, 08 Mar 2005 15:40:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lPc-0008Fc-NY; Tue, 08 Mar 2005 15:34:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8lPb-0008FK-R2 for isms@megatron.ietf.org; Tue, 08 Mar 2005 15:34: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 PAA16359 for ; Tue, 8 Mar 2005 15:34:37 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8lS2-0008P7-Tu for isms@ietf.org; Tue, 08 Mar 2005 15:37:12 -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 j28KYUIP009514 for ; Tue, 8 Mar 2005 15:34:30 -0500 (EST) Message-Id: <200503082034.j28KYUIP009514@ginger.cmf.nrl.navy.mil> To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <6.2.0.14.0.20050308142216.03836548@mira-sjc5-a.cisco.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Tue, 08 Mar 2005 15:34:30 -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: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 2409bba43e9c8d580670fda8b695204a >EAP provides an authentication framework to support multiple >authentication mechanisms. We can use Kerberos directly to >derive keys but using EAP provides us the ability to support >other authentication mechanisms as well. Here's my problem with that. Let's say that I'm using Kerberos cipher suites for TLS. All of the authentication takes place using Kerberos inside of TLS, before any EAP messages are exchanged. What, exactly, is EAP supposed to do over this TLS channel? All of the authentication is complete before EAP has sent a single message. >Now specifically >with regards to use of EAP-TLS, TLS is being used for >Kerberos authentication using Kerberos cipher suites. I think I've raised my objection to this already. My opinion is that the support for Kerberos cipher suites for TLS is essentially non-existant (I find that unfortunate, but it's the reality). To me this is not a practical way of providing support for Kerberos authentication in EUSM. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 8 16: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 QAA22714; Tue, 8 Mar 2005 16:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mSZ-0001pP-30; Tue, 08 Mar 2005 16:41:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mPq-0001iw-He; Tue, 08 Mar 2005 16:38:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8mPo-0001io-U7 for isms@megatron.ietf.org; Tue, 08 Mar 2005 16:38:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22708 for ; Tue, 8 Mar 2005 16:38:53 -0500 (EST) Received: from wireless-130-129-132-129.ietf62.ietf.org ([130.129.132.129] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8mSF-0001pD-HO for isms@ietf.org; Tue, 08 Mar 2005 16:41:28 -0500 Received: from localhost.localdomain (unknown [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 832BFD015; Tue, 8 Mar 2005 13:40:20 -0800 (PST) Received: (from baerm@localhost) by localhost.localdomain (8.12.8/8.12.8/Submit) id j28LeETB024139; Tue, 8 Mar 2005 13:40:14 -0800 X-Authentication-Warning: localhost.localdomain: baerm set sender to sbsm@mikesoffice.com using -f To: isms@ietf.org Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) From: Michael Baer X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.: ("Martin Soukup"'s message of "Tue, 8 Mar 2005 08:32:17 -0500") Message-ID: User-Agent: Gnus/5.090015 (Oort Gnus v0.15) XEmacs/21.4 (Rational FORTRAN, powerpc-unknown-linux) References: <0BDFFF51DC89434FA33F8B37FCE363D501F2BA87@zcarhxm2.corp.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: "'Sam Hartman'" X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 8abaac9e10c826e8252866cbe6766464 (I'm resending this mail to the isms list as it was inadvertently dropped by the list server): From: Sam Hartman Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) To: "Martin Soukup" Cc: Ken Hornstein , isms@ietf.org Date: Tue, 08 Mar 2005 11:33:40 -0500 >>>>> "Martin" == Martin Soukup writes: Martin> I also don't understand your IKE applicability Martin> statement. My understanding is that IKE is limited to Martin> "authenticated exchange of keying material and associated Martin> policy information between the end-points of a security Martin> association". This is specifically the scope being Martin> discussed in ISMS. Particularly for IKE v2, the applicability has been limited to IPsec. I believe people have mostly decided IKE v1 should also not be used for IPsec. --Sam _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 9 02:58: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 CAB21401; Wed, 9 Mar 2005 02:58:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8w7w-00075m-P2; Wed, 09 Mar 2005 03: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 1D8w45-000463-4k; Wed, 09 Mar 2005 02:57:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8w43-00045y-Fv for isms@megatron.ietf.org; Wed, 09 Mar 2005 02:57: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 CAA21059 for ; Wed, 9 Mar 2005 02:57:05 -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 1D8w6b-00071W-TD for isms@ietf.org; Wed, 09 Mar 2005 02:59:46 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2005 01:14:09 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,149,1107734400"; d="scan'208"; a="232963355:sNHT19453884" 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 j297urq8027269; Tue, 8 Mar 2005 23:56:53 -0800 (PST) Received: from kaushik-w2k03.cisco.com (sjc-vpn4-415.cisco.com [10.21.81.159]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AYW68435; Tue, 8 Mar 2005 23:56:55 -0800 (PST) Message-Id: <6.2.0.14.0.20050308145651.03845b38@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 08 Mar 2005 15:11:04 -0600 To: Ken Hornstein From: Kaushik Narayan Subject: Re: [Isms] Late Surprise: EAP is not appropriate for ISMS (fwd) In-Reply-To: <200503082034.j28KYUIP009514@ginger.cmf.nrl.navy.mil> References: <6.2.0.14.0.20050308142216.03836548@mira-sjc5-a.cisco.com> <200503082034.j28KYUIP009514@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.7 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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.7 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi Ken, Please find my reply inline. At 02:34 PM 3/8/2005, Ken Hornstein wrote: > >EAP provides an authentication framework to support multiple > >authentication mechanisms. We can use Kerberos directly to > >derive keys but using EAP provides us the ability to support > >other authentication mechanisms as well. > >Here's my problem with that. Let's say that I'm using Kerberos cipher >suites for TLS. All of the authentication takes place using Kerberos >inside of TLS, before any EAP messages are exchanged. What, exactly, >is EAP supposed to do over this TLS channel? All of the authentication >is complete before EAP has sent a single message. [Kaushik] All TLS messages will be encapsulated within EAP messages when EAP-TLS is used. > >Now specifically > >with regards to use of EAP-TLS, TLS is being used for > >Kerberos authentication using Kerberos cipher suites. > >I think I've raised my objection to this already. My opinion is that >the support for Kerberos cipher suites for TLS is essentially >non-existant (I find that unfortunate, but it's the reality). To >me this is not a practical way of providing support for Kerberos >authentication in EUSM. [Kaushik] A better way to support Kerboros might be an EAP-GSS method. There was an EAP-GSS specification that was written to support Kerberos but that has long expired. I think once the KITTEN folks have defined a GSSAPIv3, we could define an EAP-GSS based on GSSAPIv3. regards, kaushik! >--Ken > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 16 21:51: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 VAA29819; Wed, 16 Mar 2005 21:51:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBlB4-0004ko-0l; Wed, 16 Mar 2005 21:56:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBl5g-0005Kk-Gd; Wed, 16 Mar 2005 21:50:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBl5f-0005Kc-8u for isms@megatron.ietf.org; Wed, 16 Mar 2005 21:50:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29725 for ; Wed, 16 Mar 2005 21:50:24 -0500 (EST) Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBl9k-0004iE-PN for isms@ietf.org; Wed, 16 Mar 2005 21:54:44 -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 j2H2oAi11169; Wed, 16 Mar 2005 21:50:10 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 16 Mar 2005 21:50:11 -0500 Message-ID: <0BDFFF51DC89434FA33F8B37FCE363D501F2BB4A@zcarhxm2.corp.nortel.com> From: "Martin Soukup" To: "'Wes Hardaker'" Subject: RE: [Isms] Parallel vs in-band session setup. Date: Wed, 16 Mar 2005 21:50:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) 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: , Content-Type: multipart/mixed; boundary="===============0103140671==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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. --===============0103140671== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52A9C.07252EE6" 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_01C52A9C.07252EE6 Content-Type: text/plain You do, potentially, need a shared data store on the Managed Device. All keying information requests could come from the SNMP Engines (i.e. requesting a session of the SNMP Engine will have it request keys from its local session "controller"). Maybe I've misunderstood something, but I don't see any hard need to do IPC in the implementations, although you may need a shared store the heap or the file system tend to be adequate. Furthermore, in the integrated version no local information storage is required since the key negotiation in eUSM happens outside the SNMP IPC. Martin. > -----Original Message----- > From: Wes Hardaker [mailto:hardaker@tislabs.com] > Sent: March 6, 2005 9:46 PM > To: Soukup, Martin [CAR:5K50:EXCH] > Cc: isms@ietf.org > Subject: Re: [Isms] Parallel vs in-band session setup. > > > Martin> Just wondering, but wouldn't it make more sense for the > Martin> session/key establishment mechanism to be implemented as a > Martin> library-type-thing (i.e. shlib) and thus execute within > Martin> whatever SNMP Engine process is requesting a session? > > It's the receiving side of the connection establishment which is more > problematic. How does a XXX keying demon on a machine know which > of multiple SNMP processes to send the keys too? > > -- > Wes Hardaker > Sparta ------_=_NextPart_001_01C52A9C.07252EE6 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Isms] Parallel vs in-band session setup.

You do, potentially, need a shared data store on the = Managed Device. All keying information requests could come from the = SNMP Engines (i.e. requesting a session of the SNMP Engine will have it = request keys from its local session "controller"). Maybe I've = misunderstood something, but I don't see any hard need to do IPC in the = implementations, although you may need a shared store the heap or the = file system tend to be adequate. Furthermore, in the integrated version = no local information storage is required since the key negotiation in = eUSM happens outside the SNMP IPC.

Martin.

> -----Original Message-----
> From: Wes Hardaker [mailto:hardaker@tislabs.com]
> Sent: March 6, 2005 9:46 PM
> To: Soukup, Martin [CAR:5K50:EXCH]
> Cc: isms@ietf.org
> Subject: Re: [Isms] Parallel vs in-band session = setup.
>
>
> Martin> Just wondering, but wouldn't it make = more sense for the
> Martin> session/key establishment mechanism = to be implemented as a
> Martin> library-type-thing (i.e.  = shlib) and thus execute within
> Martin> whatever SNMP Engine process is = requesting a session?
>
> It's the receiving side of the connection = establishment which is more
> problematic.  How does a XXX keying demon = on a machine know which
> of multiple SNMP processes to send the keys = too?
>
> --
> Wes Hardaker
> Sparta

------_=_NextPart_001_01C52A9C.07252EE6-- --===============0103140671== 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 --===============0103140671==-- From isms-bounces@ietf.org Thu Mar 17 19:15: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 TAA06716; Thu, 17 Mar 2005 19:15:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC5Dq-0002Wu-Gp; Thu, 17 Mar 2005 19:20:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC579-0003CP-D3; Thu, 17 Mar 2005 19:13:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC577-0003CK-UD for isms@megatron.ietf.org; Thu, 17 Mar 2005 19:13: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 TAA06598 for ; Thu, 17 Mar 2005 19:13:13 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC5BR-0002TW-Cx for isms@ietf.org; Thu, 17 Mar 2005 19:17:46 -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 SAA18994 for ; Thu, 17 Mar 2005 18:13:02 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j2I0D2711741 for ; Thu, 17 Mar 2005 18:13:02 -0600 (CST) Received: from XCH-NW-09.nw.nos.boeing.com ([192.42.226.84]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Mar 2005 16:12:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 17 Mar 2005 16:12:59 -0800 Message-ID: <5B58696DB20B9140AD20E0685C573A6404FDDD46@xch-nw-09.nw.nos.boeing.com> Thread-Topic: What happened during the ISMS WG meeting Thread-Index: AcUqnEZFhpZvV1bOQ+2i9d5MFGZxWgAssZeA From: "Fleischman, Eric" To: X-OriginalArrivalTime: 18 Mar 2005 00:12:59.0541 (UTC) FILETIME=[3E2C0450:01C52B4F] X-Spam-Score: 0.6 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Isms] What happened during the ISMS WG meeting X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 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="===============1545024044==" Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 This is a multi-part message in MIME format. --===============1545024044== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52B4F.3DE74C04" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52B4F.3DE74C04 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few of us were not able to attend the last IETF and are curious what progress was made in the ISMS WG during that meeting. Could somebody please give us a report so that we could know the current status of the WG? Thanks! =20 ------_=_NextPart_001_01C52B4F.3DE74C04 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
A few=20 of us were not able to attend the last IETF and are curious what = progress was=20 made in the ISMS WG during that meeting. Could somebody please give us a = report=20 so that we could know the current status of the WG? = Thanks!
 
------_=_NextPart_001_01C52B4F.3DE74C04-- --===============1545024044== 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 --===============1545024044==-- From isms-bounces@ietf.org Thu Mar 17 19:33: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 TAA08523; Thu, 17 Mar 2005 19:33:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC5VX-0002zS-Gz; Thu, 17 Mar 2005 19:38:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC5QS-0007Z6-TL; Thu, 17 Mar 2005 19:33:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC5QR-0007Yy-9j for isms@megatron.ietf.org; Thu, 17 Mar 2005 19:33:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08496 for ; Thu, 17 Mar 2005 19:33:10 -0500 (EST) Received: from kyoto.netlab.nec.de ([195.37.70.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC5Ul-0002yQ-0E for isms@ietf.org; Thu, 17 Mar 2005 19:37:43 -0500 Received: from dialin-145-254-225-075.arcor-ip.net (dialin-145-254-225-075.arcor-ip.net [145.254.225.75]) by kyoto.netlab.nec.de (Postfix) with ESMTP id 8E3141BAC4D; Fri, 18 Mar 2005 01:33:01 +0100 (CET) Date: Fri, 18 Mar 2005 01:32:56 +0100 From: Juergen Quittek To: "Fleischman, Eric" , isms@ietf.org Subject: Re: [Isms] What happened during the ISMS WG meeting Message-ID: <12C365ADB9568DD60B8F0A32@[192.168.2.1]> In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDD46@xch-nw-09.nw.nos.boeing.com> References: <5B58696DB20B9140AD20E0685C573A6404FDDD46@xch-nw-09.nw.nos.boeing.com> X-Mailer: Mulberry/3.1.6 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 3.0 (+++) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: 3.0 (+++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Eric, --On 17.03.2005 16:12 -0800 Fleischman, Eric wrote: > > A few of us were not able to attend the last IETF and are curious what progress was made in the ISMS WG during that meeting. Could somebody please give us a report so that we could know the current status of the WG? Thanks! > Here is a brief summary: IETF #61 ISMS WG Session Summary, Monday, March 7, 2004, Minneapolis The ISMS evaluation team had produced an I-D comparing the proposed solutions TLSM, EUSM, and SBSM. The team gave the recommendation to choose EUSM as starting point for standardization work in ISMS. However, EUSM uses EAP and few days before the meeting, the ADs discovered that this conflicts with the EAP applicability statement in RFC 3748. The WG discussed this constraint extensively without reaching consensus on how to react. In order to still progress further, the WG decided to make a decision on the target ISMS architecture first, before closing the protocol issue. The chairs and the evaluation team will post a description of the alternative architectures that have been discussed and will try to achieve consensus on a single ISMS architecture until end of April. Then discussion on a new ISMS charter will start, that must be completed at IETF63. Otherwise the WG will be closed. Elaborated minutes will be written soon. You can find an audio recording of the session at Can somebody please provide a pointer to the Jabber log? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 17 20: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 UAA11605; Thu, 17 Mar 2005 20:12:21 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC66h-0003vG-Eu; Thu, 17 Mar 2005 20:16:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC61q-0006QE-II; Thu, 17 Mar 2005 20:11:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC61o-0006Q3-Kd for isms@megatron.ietf.org; Thu, 17 Mar 2005 20:11: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 UAA11534 for ; Thu, 17 Mar 2005 20:11:47 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC667-0003u4-Vt for isms@ietf.org; Thu, 17 Mar 2005 20:16:21 -0500 Received: from shell4.bayarea.net (shell4.bayarea.net [209.128.82.1]) by smtpout1.bayarea.net (8.12.10/8.12.10) with ESMTP id j2I1Ba9s010072; Thu, 17 Mar 2005 17:11:36 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2I1BiDv012791; Thu, 17 Mar 2005 17:11:44 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2I1BiCM012788; Thu, 17 Mar 2005 17:11:44 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Thu, 17 Mar 2005 17:11:43 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Juergen Quittek Subject: Re: [Isms] What happened during the ISMS WG meeting In-Reply-To: <12C365ADB9568DD60B8F0A32@[192.168.2.1]> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 HI, There was much talk about security during the IETF. I believe the most important session was the ICOS BOF. (http://www.ietf.org/ietf/05mar/icos.txt) The session was mostly presentations about what going with security in the IETF. Grab the presentations. They were quite informative. I'm hoping that the EUSM guys can get together with Wes and me and work out a combined proposal. In the end, to me, there are three parts of the solution, and I believe we are close. The three parts are: 1) mutual authentication, creation of "master session key" and session identifier, negotiation of auth and priv protocols, and possible group determination. Plus determination of session attributes. 2) how replay protection is to be provided (reuse "shared clock" from USM, or use message cache in SBSM) 3) notification receiver identity determination Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 17 23:06: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 XAA26196; Thu, 17 Mar 2005 23:06:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8pQ-0007Wq-AE; Thu, 17 Mar 2005 23:11:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8iU-0002AU-Mf; Thu, 17 Mar 2005 23:04:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8iT-0002AP-H4 for isms@megatron.ietf.org; Thu, 17 Mar 2005 23:04: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 XAA26064 for ; Thu, 17 Mar 2005 23:04:02 -0500 (EST) Message-Id: <200503180404.XAA26064@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8mp-0007Tm-Js for isms@ietf.org; Thu, 17 Mar 2005 23:08:36 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005031804035001200e7ff8e>; Fri, 18 Mar 2005 04:03:50 +0000 From: "David B Harrington" To: "'Fleischman, Eric'" , Subject: RE: [Isms] What happened during the ISMS WG meeting Date: Thu, 17 Mar 2005 23:03: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 In-Reply-To: <5B58696DB20B9140AD20E0685C573A6404FDDD46@xch-nw-09.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUqnEZFhpZvV1bOQ+2i9d5MFGZxWgAssZeAAAgJlKA= X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Hi, You can listen to the whole meeting if you'd like. All meetings were recorded (and broadcast) in MP3 format. See to see which channel was used for each room. ISMS=channel 5, Monday evening. See for the MP3 Bert and I (among others) listened to the meetings as they took place, and could participate using jabber in a few of the meetings. David Harrington dbharrington@comcast.net ________________________________ From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Fleischman, Eric Sent: Thursday, March 17, 2005 7:13 PM To: isms@ietf.org Subject: [Isms] What happened during the ISMS WG meeting A few of us were not able to attend the last IETF and are curious what progress was made in the ISMS WG during that meeting. Could somebody please give us a report so that we could know the current status of the WG? Thanks! _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Thu Mar 17 23:12: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 XAA26557; Thu, 17 Mar 2005 23:12:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8um-0007dR-D7; Thu, 17 Mar 2005 23:16:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8po-0003Ed-P2; Thu, 17 Mar 2005 23:11:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC8pm-0003EW-5m for isms@megatron.ietf.org; Thu, 17 Mar 2005 23:11: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 XAA26523 for ; Thu, 17 Mar 2005 23:11:34 -0500 (EST) Message-Id: <200503180411.XAA26523@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC8u8-0007cW-BR for isms@ietf.org; Thu, 17 Mar 2005 23:16:08 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005031804112701200e6l9be>; Fri, 18 Mar 2005 04:11:27 +0000 From: "David B Harrington" To: "'Juergen Quittek'" , "'Fleischman, Eric'" , Subject: RE: [Isms] What happened during the ISMS WG meeting Date: Thu, 17 Mar 2005 23:11:22 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <12C365ADB9568DD60B8F0A32@[192.168.2.1]> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUrUi4PacijYehJRfeudKqt1jU0zAAHlQmg X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit The jabber log can be found at http://www.xmpp.org/ietf-logs/isms@ietf.xmpp.org/2005-03-07.html dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Juergen Quittek > Sent: Thursday, March 17, 2005 7:33 PM > To: Fleischman, Eric; isms@ietf.org > Subject: Re: [Isms] What happened during the ISMS WG meeting > > Eric, > > --On 17.03.2005 16:12 -0800 Fleischman, Eric wrote: > > > > > A few of us were not able to attend the last IETF and are > curious what progress was made in the ISMS WG during that > meeting. Could somebody please give us a report so that we > could know the current status of the WG? Thanks! > > > Here is a brief summary: > > IETF #61 ISMS WG Session Summary, Monday, March 7, 2004, Minneapolis > > The ISMS evaluation team had produced an I-D comparing the proposed > solutions TLSM, EUSM, and SBSM. The team gave the recommendation > to choose EUSM as starting point for standardization work in ISMS. > However, EUSM uses EAP and few days before the meeting, the ADs > discovered that this conflicts with the EAP applicability statement > in RFC 3748. > > The WG discussed this constraint extensively without reaching > consensus on how to react. In order to still progress further, > the WG decided to make a decision on the target ISMS architecture > first, before closing the protocol issue. The chairs and the > evaluation team will post a description of the alternative > architectures that have been discussed and will try to achieve > consensus on a single ISMS architecture until end of April. > Then discussion on a new ISMS charter will start, that must > be completed at IETF63. Otherwise the WG will be closed. > > > Elaborated minutes will be written soon. > > You can find an audio recording of the session at > > > Can somebody please provide a pointer to the Jabber log? > > Thanks, > > Juergen > -- > Juergen Quittek quittek@netlab.nec.de Tel: +49 > 6221 90511-15 > NEC Europe Ltd., Network Laboratories Fax: +49 > 6221 90511-55 > Kurfuersten-Anlage 36, 69115 Heidelberg, Germany > http://www.netlab.nec.de > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 18 14:01: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 OAA11189; Fri, 18 Mar 2005 14:01:58 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMnv-0002Bz-AK; Fri, 18 Mar 2005 14:06:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMjI-0008BG-ON; Fri, 18 Mar 2005 14:01:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMjH-0008BB-11 for isms@megatron.ietf.org; Fri, 18 Mar 2005 14:01: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 OAA11171 for ; Fri, 18 Mar 2005 14:01:49 -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 1DCMnl-0002BN-0G for isms@ietf.org; Fri, 18 Mar 2005 14:06:30 -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 j2IJ1YTd022694; Fri, 18 Mar 2005 11:01:34 -0800 (PST) Received: by admsrvnt02.enet.sharplabs.com with Internet Mail Service (5.5.2657.72) id <1B77DRL9>; Fri, 18 Mar 2005 11:01:34 -0800 Message-ID: From: "McDonald, Ira" To: "'Juergen Quittek'" , "Fleischman, Eric" , isms@ietf.org Subject: RE: [Isms] What happened during the ISMS WG meeting Date: Fri, 18 Mar 2005 11:01:25 -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: 25620135586de10c627e3628c432b04a X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: cd26b070c2577ac175cd3a6d878c6248 ISMS WG chairs, Is there a note from the IESG that could be copied to this list that allows this extension of the charter by three or more months? Right now, this working group ceases to exist in two weeks. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald@sharplabs.com -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org]On Behalf Of Juergen Quittek Sent: Thursday, March 17, 2005 7:33 PM To: Fleischman, Eric; isms@ietf.org Subject: Re: [Isms] What happened during the ISMS WG meeting Eric, --On 17.03.2005 16:12 -0800 Fleischman, Eric wrote: > > A few of us were not able to attend the last IETF and are curious what progress was made in the ISMS WG during that meeting. Could somebody please give us a report so that we could know the current status of the WG? Thanks! > Here is a brief summary: IETF #61 ISMS WG Session Summary, Monday, March 7, 2004, Minneapolis The ISMS evaluation team had produced an I-D comparing the proposed solutions TLSM, EUSM, and SBSM. The team gave the recommendation to choose EUSM as starting point for standardization work in ISMS. However, EUSM uses EAP and few days before the meeting, the ADs discovered that this conflicts with the EAP applicability statement in RFC 3748. The WG discussed this constraint extensively without reaching consensus on how to react. In order to still progress further, the WG decided to make a decision on the target ISMS architecture first, before closing the protocol issue. The chairs and the evaluation team will post a description of the alternative architectures that have been discussed and will try to achieve consensus on a single ISMS architecture until end of April. Then discussion on a new ISMS charter will start, that must be completed at IETF63. Otherwise the WG will be closed. Elaborated minutes will be written soon. You can find an audio recording of the session at Can somebody please provide a pointer to the Jabber log? Thanks, Juergen -- Juergen Quittek quittek@netlab.nec.de Tel: +49 6221 90511-15 NEC Europe Ltd., Network Laboratories Fax: +49 6221 90511-55 Kurfuersten-Anlage 36, 69115 Heidelberg, Germany http://www.netlab.nec.de _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 18 14:06: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 OAA11827; Fri, 18 Mar 2005 14:06:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMsi-0002Sd-3b; Fri, 18 Mar 2005 14:11:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMno-000141-AP; Fri, 18 Mar 2005 14:06:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCMnm-00013l-Sp for isms@megatron.ietf.org; Fri, 18 Mar 2005 14:06: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 OAA11771 for ; Fri, 18 Mar 2005 14:06:29 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCMsG-0002RC-Ux for isms@ietf.org; Fri, 18 Mar 2005 14:11:10 -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 j2IJ6KFw019109; Fri, 18 Mar 2005 14:06:21 -0500 (EST) Message-Id: <200503181906.j2IJ6KFw019109@ginger.cmf.nrl.navy.mil> To: "McDonald, Ira" Subject: Re: [Isms] What happened during the ISMS WG meeting In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` Date: Fri, 18 Mar 2005 14:06:21 -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: 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 >Is there a note from the IESG that could be copied to this list >that allows this extension of the charter by three or more months? > >Right now, this working group ceases to exist in two weeks. Juergen sent in a request to the IESG to change the Milestones and it was approved by our AD. So I guess the only thing to say is ... "check the ISMS web page", it should appear there soon. --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 18 18:42: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 SAA23566; Fri, 18 Mar 2005 18:42:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCRBe-00015I-EN; Fri, 18 Mar 2005 18:47:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCR4m-0002Ah-Ia; Fri, 18 Mar 2005 18:40:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCR4l-00029h-Jy for isms@megatron.ietf.org; Fri, 18 Mar 2005 18:40: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 SAA23477 for ; Fri, 18 Mar 2005 18:40:16 -0500 (EST) Received: from ginger.cmf.nrl.navy.mil ([134.207.10.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCR9J-0000zu-4j for isms@ietf.org; Fri, 18 Mar 2005 18:45:01 -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 j2INeDCX028230 for ; Fri, 18 Mar 2005 18:40:14 -0500 (EST) Message-Id: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> To: isms@ietf.org 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: Fri, 18 Mar 2005 18:40:14 -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: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Isms] Discussion: Architecture direction for ISMS X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Greetings all, As you all know, the outcome from the ISMS working group meeting was that due to a number of events, we are now tasked with deciding on the architecture to use for ISMS. As discussed in the meeting, there are three obvious choices, which neatly correspond to the three proposed ISMS protocols. Note that choosing a security architecture doesn't necessarily mean we have to choose the particular proposed protocol; my expectation is that once we pick a particular architecture, we'll develop a new protocol based on that architecture. As I see it, we have the following architectures to choose from. Note that when I say "features", I'm not making a decision on whether or not a feature is good or bad; it's just some of the more important points to consider. I have no doubt others will have other features to bring up about each architecture. - "Out of Band Keying" This is the approach chosen by EUSM. Essentially, a seperate protocol exchange is conducted between the manager and agent (or a third party) and a key is then established/derived for use with standard USM. Features: - Can make use of existing USM (already-analyzed protocol). - Likely wide variety of IETF protocols to use as out-of-band keying protocol - Encryption/checksum modes limited to ones supported by USM - Extra care would be required to assure keying material derived from out-of-band exchange is matched with a particular USM session. - "In Band Keying" This is the approach taken by SBSM. The security protocol is contained within SNMP payloads and likely whatever protocol is chosen will have a way to secure the PDU contents. Features: - Requires new SNMP security model. - Is more in line with the traditional way security is applied to application protocols. - Exact privacy/integrity details will need to be specified by this or other protocol (depending on which framework is chosen). - "Encapsulation keying" This is the approach taken by TLSM. An encapsulation protocol (such as TLS) is used to "wrap" SNMP payloads. A traditional USM could be run underneath this protocol. - Likely requires no changes to SNMP protocol. - Is used by a number of other protocols with a great deal of success. - _May_ require the use of TCP. - Traditional TLS only performs authentication for some mechanisms, may require additional work to support other authentication schemes. I am sure that others will have additional features to add to the ones I've listed above. Anyway, please, anyone that has any thoughts, please lets get them out there! --Ken _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 18 20:27: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 UAA00820; Fri, 18 Mar 2005 20:27:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCSou-0004qV-9a; Fri, 18 Mar 2005 20:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCSjh-0002mK-Am; Fri, 18 Mar 2005 20:26:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCSjf-0002mC-KN for isms@megatron.ietf.org; Fri, 18 Mar 2005 20:26: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 UAA00785 for ; Fri, 18 Mar 2005 20:26:37 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCSoD-0004pS-Jo for isms@ietf.org; Fri, 18 Mar 2005 20:31:22 -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 j2J1QH9s003447; Fri, 18 Mar 2005 17:26:17 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2J1QO7u010178; Fri, 18 Mar 2005 17:26:24 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2J1QMK3010165; Fri, 18 Mar 2005 17:26:24 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 18 Mar 2005 17:26:22 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Ken Hornstein Subject: Re: [Isms] Discussion: Architecture direction for ISMS In-Reply-To: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) 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: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c HI, The Keying architecture is only one part of the problem to be solved. On "Out of Band" vs "In Band", both EUSM and SBSM can be modified to use either. The result of keying is: 1) a session Identity 2) a master session key from which the MIC and encryption keys are derived 3) mutual authentication 4) the "auth protocol" and "priv protocol" (SNMP terminology) to be used for MIC and encryption during normal message exchange 5) other session parameters (such as activity timeout, or rekeying) 6) if possible, the group to be used Note that 3rd party keying as described in EUSM will not work with Radius, since Radius servers cannot remember state. If a single one was modified to do so, this would create a problem for supporting Radius server groups (the state would have to be made available to all Radius servers in the group). During the IETF meeting, there were some investigation into what other protocol could be used. The ICOS BOF covered security background and presented some possible approaches. As was pointed out on the ISMS mailing list, and at the WG meeting, that technology based on EAP is outside the realm of applicabillity. See http://www.drizzle.com/~aboba/IETF62/icos/ietf62_eap_applicability.ppt In the ICOS BOF, another contender IKEv2 (and IKEv1) were discussed. It turns out that IKEv1 could possibly be used, but its replacement, IKEv2 is strictly for IPSEC and not for other uses. Another choice was SASL. However, SASL doesn't do the job by itself, and other work would need to be done. Other candidates include GSSAPI and PANA. The EUSM specification identifies PANA. However, no analysis has been done so far to understand the issue with using GSSAPI and PANA. Uri & Eric (and other security people) please chime in if I missed something. The other parts of the architecture are 1) when running, what will be done for session identification, and what will be done for replay protection. EUSM proposes the use what was done for USM. However, the user name and IP address is ambiguous, since in many cases on SNMP managers, there are concurrent SNMP manager applications that are running that do not use the same "SNMP engine" and are unaware of the existance of each other. Also, the USM replay protection requires use of a loosely synchronized clock and choosing an authoritative SNMP engine. This is much more complicated than needed, once a session based approach is used. SBSM uses a different and simplier approach for session identification and replay protection. 2) Setting up sessions for delivering notifications. This is tricky, since the notification sender has a security name (a security model independent identity) that it want to deliver a notification to. However, a notification receiver may support multiple identites. How to do mutual authentication, can be a little tricky in this case. That's it so far. On Fri, 18 Mar 2005, Ken Hornstein wrote: > Greetings all, > > As you all know, the outcome from the ISMS working group meeting was that > due to a number of events, we are now tasked with deciding on the architecture > to use for ISMS. As discussed in the meeting, there are three obvious choices, > which neatly correspond to the three proposed ISMS protocols. Note that > choosing a security architecture doesn't necessarily mean we have to choose > the particular proposed protocol; my expectation is that once we pick a > particular architecture, we'll develop a new protocol based on that > architecture. > > As I see it, we have the following architectures to choose from. Note that > when I say "features", I'm not making a decision on whether or not a feature > is good or bad; it's just some of the more important points to consider. > I have no doubt others will have other features to bring up about each > architecture. > > - "Out of Band Keying" > > This is the approach chosen by EUSM. Essentially, a seperate protocol > exchange is conducted between the manager and agent (or a third party) > and a key is then established/derived for use with standard USM. > > Features: > > - Can make use of existing USM (already-analyzed protocol). > - Likely wide variety of IETF protocols to use as out-of-band keying protocol > - Encryption/checksum modes limited to ones supported by USM > - Extra care would be required to assure keying material derived from > out-of-band exchange is matched with a particular USM session. > > - "In Band Keying" > > This is the approach taken by SBSM. The security protocol is > contained within SNMP payloads and likely whatever protocol is chosen > will have a way to secure the PDU contents. > > Features: > > - Requires new SNMP security model. > - Is more in line with the traditional way security is applied to > application protocols. > - Exact privacy/integrity details will need to be specified by this or > other protocol (depending on which framework is chosen). > > - "Encapsulation keying" > > This is the approach taken by TLSM. An encapsulation protocol (such > as TLS) is used to "wrap" SNMP payloads. A traditional USM could be > run underneath this protocol. > > - Likely requires no changes to SNMP protocol. > - Is used by a number of other protocols with a great deal of success. > - _May_ require the use of TCP. > - Traditional TLS only performs authentication for some mechanisms, may > require additional work to support other authentication schemes. > > I am sure that others will have additional features to add to the ones > I've listed above. Anyway, please, anyone that has any thoughts, please > lets get them out there! > > --Ken Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 21 17:01: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 RAA01263; Mon, 21 Mar 2005 17:01:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDV3B-0004VH-A8; Mon, 21 Mar 2005 17:07:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUx1-0003Kp-7Q; Mon, 21 Mar 2005 17:00:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDUx0-0003Kk-Bu for isms@megatron.ietf.org; Mon, 21 Mar 2005 17:00: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 RAA01113 for ; Mon, 21 Mar 2005 17:00:39 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDV27-0004QS-T5 for isms@ietf.org; Mon, 21 Mar 2005 17:06:01 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1DDUwv-0004Lc-CT for isms@ietf.org; Mon, 21 Mar 2005 17:00:37 -0500 Date: Mon, 21 Mar 2005 17:00:43 -0500 From: Robert Story To: isms@ietf.org Subject: Re: [Isms] Discussion: Architecture direction for ISMS Message-ID: <20050321170043.39f3e05f@aud> In-Reply-To: References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote: DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote: DTP> > - "Encapsulation keying" DTP> > DTP> > This is the approach taken by TLSM. An encapsulation protocol (such DTP> > as TLS) is used to "wrap" SNMP payloads. DTP> 2) Setting up sessions for delivering notifications. Speaking of notifications, isn't there an issue with the transport approach and notifications? Doesn't net-conf suffer from this issue? Specifically, sending a notification when the notification destination doesn't have an existing open session with the notification generator. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 21 18:07: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 SAA09093; Mon, 21 Mar 2005 18:07:44 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDW54-0006zL-Bt; Mon, 21 Mar 2005 18:13:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDVy7-00028g-8U; Mon, 21 Mar 2005 18:05:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDVy5-00028b-T5 for isms@megatron.ietf.org; Mon, 21 Mar 2005 18:05: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 SAA08852 for ; Mon, 21 Mar 2005 18:05:51 -0500 (EST) Message-Id: <200503212305.SAA08852@ietf.org> Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDW3F-0006xF-Ae for isms@ietf.org; Mon, 21 Mar 2005 18:11:13 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc13) with SMTP id <20050321230544016007rq5fe>; Mon, 21 Mar 2005 23:05:44 +0000 From: "David B Harrington" To: "'Robert Story'" , Subject: RE: [Isms] Discussion: Architecture direction for ISMS Date: Mon, 21 Mar 2005 18:05:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050321170043.39f3e05f@aud> thread-index: AcUuYZI7KvZkWWkySGqBZRgqk1FwCAAAOyug X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Hi, The TLSM document mentions in section 4.6 the possible need to create a new session to send a notification, if no session is currently open. The ability to send asynchronous notifications is not subject to the same issues as netconf. To get netconf 1.0 published faster, the netconf WG punted on the notification issue. Part of the issue for netconf is that processing must be done sequentially - there is only one channel, and XML messages must be handled in line-by-line order, and each message must be parsed completely to ensure well-formed, valid XML, and Netconf messages can be very large because they are just streaming text, and may need to contain all the configuration commands for a complex device. There is no reasonable way to send asynchronous notifications in the middle of a netconf stream. I think the single global lock issue may also impact netconf's ability to send notifications while an incoming message is being processed, but further research may show that it doesn't. I don't think it would be wise for a TLSM design to punt on addressing the notification issue. TLSM is still underspecified, but I don't expect it to necessarily be constrained to only one channel in a session or to only one session between entities. SNMP explicitly does not guarantee the ordering of the processing of varbinds, does not require that all varbinds are validated before processing begins, and does not impose a message ordering requirement. While using a secured-TCP-based transport might permit multiple SNMP messages to be sent in the same session, I expect that for backwards compatibility, the size of a single message will still be constrained by the currently implemented SNMP buffer sizes in managers and agents, so current SNMP rules and guidelines about message size will probably still apply, at least for a while. SNMP messages are frequently parallel-processed and SNMP tends to use table locks rather than a global lock, so sending a notification to another entity while processing a varbind list from that same entity should not really be a problem from the SNMP side of the equation. David Harrington dbharrington@comcast.net > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story > Sent: Monday, March 21, 2005 5:01 PM > To: isms@ietf.org > Subject: Re: [Isms] Discussion: Architecture direction for ISMS > > On Fri, 18 Mar 2005 17:26:22 -0800 (PST) David wrote: > DTP> On Fri, 18 Mar 2005, Ken Hornstein wrote: > DTP> > - "Encapsulation keying" > DTP> > > DTP> > This is the approach taken by TLSM. An > encapsulation protocol (such > DTP> > as TLS) is used to "wrap" SNMP payloads. > > DTP> 2) Setting up sessions for delivering notifications. > > Speaking of notifications, isn't there an issue with the > transport approach > and notifications? Doesn't net-conf suffer from this issue? > Specifically, > sending a notification when the notification destination > doesn't have an > existing open session with the notification generator. > > -- > Robert Story; NET-SNMP Junkie > Support: > > You are lost in a twisty maze of little standards, all different. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 21 18:48: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 SAA14460; Mon, 21 Mar 2005 18:48:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWiZ-0008VO-LS; Mon, 21 Mar 2005 18:53:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWbU-0002sB-6f; Mon, 21 Mar 2005 18:46:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWbS-0002s3-Nt for isms@megatron.ietf.org; Mon, 21 Mar 2005 18:46: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 SAA13890 for ; Mon, 21 Mar 2005 18:46:31 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWgb-0008NZ-Bg for isms@ietf.org; Mon, 21 Mar 2005 18:51:54 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1DDWbO-0004cR-HN; Mon, 21 Mar 2005 18:46:30 -0500 Date: Mon, 21 Mar 2005 18:47:16 -0500 From: Robert Story To: Subject: Re: [Isms] Discussion: Architecture direction for ISMS Message-ID: <20050321184716.62aef39f@aud> In-Reply-To: References: <20050321170043.39f3e05f@aud> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit On Mon, 21 Mar 2005 18:05:36 -0500 David wrote: DBH> The TLSM document mentions in section 4.6 the possible need to create DBH> a new session to send a notification, if no session is currently open. Right. My question is, is this scenario something that happens in the existing infra-structure? I'm not familiar with TLS, but I do use SSH as a transport, and I'm guessing TLS is similar. It's a one way thing. So using it to receive unsolicited notifications when there is no existing session requires setup on the notification receiver's side that does not exist in the current infra-structure. And it's very unlikely that a management station will have a session established with every device it manages (especially if there are 100k+ nodes, like the networks Eric is always talking about). DBH> I don't think it would be wise for a TLSM design to punt on addressing DBH> the notification issue. I agree. A new security model that can't do everything the previous one would would be DOA. On the other hand, in the absence of a session, notifications could be sent using existing USM. If informs were used, an intelligent manager could drop the first inform and establish a session with the notification originator, hopefully in time for the retry to come over the newly established session. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 21 19:07: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 TAA16189; Mon, 21 Mar 2005 19:07:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDX1G-0000ob-3b; Mon, 21 Mar 2005 19:13:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWuV-00078l-1L; Mon, 21 Mar 2005 19:06:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDWuU-00078f-3K for isms@megatron.ietf.org; Mon, 21 Mar 2005 19:06: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 TAA16114 for ; Mon, 21 Mar 2005 19:06:10 -0500 (EST) Received: from i8ffd.i.pppool.de ([85.73.143.253] helo=boskop.local) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDWzc-0000md-D1 for isms@ietf.org; Mon, 21 Mar 2005 19:11:33 -0500 Received: by boskop.local (Postfix, from userid 501) id A755F1F91E9; Tue, 22 Mar 2005 01:05:57 +0100 (CET) Date: Tue, 22 Mar 2005 01:05:56 +0100 From: Juergen Schoenwaelder To: Robert Story Subject: Re: [Isms] Discussion: Architecture direction for ISMS Message-ID: <20050322000556.GA5059@boskop.local> Mail-Followup-To: Robert Story , ietfdbh@comcast.net, isms@ietf.org References: <20050321170043.39f3e05f@aud> <20050321184716.62aef39f@aud> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050321184716.62aef39f@aud> User-Agent: Mutt/1.4.2.1i 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 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: ea4ac80f790299f943f0a53be7e1a21a On Mon, Mar 21, 2005 at 06:47:16PM -0500, Robert Story wrote: > DBH> The TLSM document mentions in section 4.6 the possible need to create > DBH> a new session to send a notification, if no session is currently open. > > Right. My question is, is this scenario something that happens in the existing > infra-structure? I'm not familiar with TLS, but I do use SSH as a transport, > and I'm guessing TLS is similar. It's a one way thing. So using it to receive > unsolicited notifications when there is no existing session requires setup on > the notification receiver's side that does not exist in the current > infra-structure. And it's very unlikely that a management station will have a > session established with every device it manages (especially if there are 100k+ > nodes, like the networks Eric is always talking about). RFC 3430 might be useful reading material here. The text in section 2.3 says that the notification originator is responsible to establish any TCP sessions needed to deliver a notification to the interested targets. A summary of several options discussed while RFC 3430 was produced is contained in Appendix A. /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 Mar 21 20:48: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 UAA24815; Mon, 21 Mar 2005 20:48:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDYai-0004CT-37; Mon, 21 Mar 2005 20:53:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDYV0-0001Nn-Qe; Mon, 21 Mar 2005 20:48:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDYUy-0001Ne-LM for isms@megatron.ietf.org; Mon, 21 Mar 2005 20:48:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24605 for ; Mon, 21 Mar 2005 20:47:58 -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 1DDYa9-00049N-0W for isms@ietf.org; Mon, 21 Mar 2005 20:53:21 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 21 Mar 2005 17:47:51 -0800 X-IronPort-AV: i="3.91,108,1110182400"; d="scan'208"; a="621615617:sNHT221007660" 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 j2M1lmZV005245; Mon, 21 Mar 2005 17:47:48 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZG85275; Mon, 21 Mar 2005 17:47:46 -0800 (PST) Message-Id: <6.2.0.14.0.20050321174030.03e68ae8@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 21 Mar 2005 17:47:45 -0800 To: Ken Hornstein From: Kaushik Narayan Subject: Re: [Isms] Discussion: Architecture direction for ISMS In-Reply-To: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: 057ebe9b96adec30a7efb2aeda4c26a4 Hi Ken, We believe that use of in-band and out-of-band keying is not the most important difference between EUSM and SBSM. EUSM could use an in-band Key Setup via using SNMPv3 noAuthnoPriv Notification messages (similar to SNMPv3 engine ID discovery). We believe the most important differences are 1. EUSM attempts to ONLY solve the problem of "integration of USM with existing authentication systems". We retain the USM and it's processing entirely and only add capability to provision keys used by USM. 2. EUSM completely relies on existing authenticated key exchange mechanisms that have been well defined, implemented and analyzed, we had proposed the use of EAP for Key Setup and we plan to suggest the use of TLS or GSSAPI for Key Setup. We do plan to put an EUSM -03 draft with changes based on the recommendation on EAP usage. We have got feedback that the use of the RADIUS server to distribute keys is not desirable. We plan to remove the parts that describe the use of RADIUS for Key Request and the use of the RADIUS server to distribute keys to multiple agents in the EUSM -03 draft. regards, kaushik! At 03:40 PM 3/18/2005, Ken Hornstein wrote: >Greetings all, > >As you all know, the outcome from the ISMS working group meeting was that >due to a number of events, we are now tasked with deciding on the architecture >to use for ISMS. As discussed in the meeting, there are three obvious >choices, >which neatly correspond to the three proposed ISMS protocols. Note that >choosing a security architecture doesn't necessarily mean we have to choose >the particular proposed protocol; my expectation is that once we pick a >particular architecture, we'll develop a new protocol based on that >architecture. > >As I see it, we have the following architectures to choose from. Note that >when I say "features", I'm not making a decision on whether or not a feature >is good or bad; it's just some of the more important points to consider. >I have no doubt others will have other features to bring up about each >architecture. > >- "Out of Band Keying" > > This is the approach chosen by EUSM. Essentially, a seperate protocol > exchange is conducted between the manager and agent (or a third party) > and a key is then established/derived for use with standard USM. > > Features: > > - Can make use of existing USM (already-analyzed protocol). > - Likely wide variety of IETF protocols to use as out-of-band keying > protocol > - Encryption/checksum modes limited to ones supported by USM > - Extra care would be required to assure keying material derived from > out-of-band exchange is matched with a particular USM session. > >- "In Band Keying" > > This is the approach taken by SBSM. The security protocol is > contained within SNMP payloads and likely whatever protocol is chosen > will have a way to secure the PDU contents. > > Features: > > - Requires new SNMP security model. > - Is more in line with the traditional way security is applied to > application protocols. > - Exact privacy/integrity details will need to be specified by this or > other protocol (depending on which framework is chosen). > >- "Encapsulation keying" > > This is the approach taken by TLSM. An encapsulation protocol (such > as TLS) is used to "wrap" SNMP payloads. A traditional USM could be > run underneath this protocol. > > - Likely requires no changes to SNMP protocol. > - Is used by a number of other protocols with a great deal of success. > - _May_ require the use of TCP. > - Traditional TLS only performs authentication for some mechanisms, may > require additional work to support other authentication schemes. > >I am sure that others will have additional features to add to the ones >I've listed above. Anyway, please, anyone that has any thoughts, please >lets get them out there! > >--Ken > >_______________________________________________ >Isms mailing list >Isms@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 22 00: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 AAA09470; Tue, 22 Mar 2005 00:07:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDbhK-0002dm-6g; Tue, 22 Mar 2005 00:12:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbb9-0002Sx-Qm; Tue, 22 Mar 2005 00:06:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbb4-0002OX-Um for isms@megatron.ietf.org; Tue, 22 Mar 2005 00:06: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 AAA09275 for ; Tue, 22 Mar 2005 00:06:28 -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 1DDbgH-0002ZM-5Y for isms@ietf.org; Tue, 22 Mar 2005 00:11:53 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id C9F9411D89C; Mon, 21 Mar 2005 21:06:20 -0800 (PST) From: Wes Hardaker To: Ken Hornstein Subject: Re: [Isms] Discussion: Architecture direction for ISMS Organization: Sparta References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> Date: Mon, 21 Mar 2005 21:06:18 -0800 In-Reply-To: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> (Ken Hornstein's message of "Fri, 18 Mar 2005 18:40:14 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 >>>>> On Fri, 18 Mar 2005 18:40:14 -0500, Ken Hornstein said: Ken> - "Out of Band Keying" Ken> This is the approach chosen by EUSM. Essentially, a seperate protocol Ken> exchange is conducted between the manager and agent (or a third party) Ken> and a key is then established/derived for use with standard USM. That's a EUSM specific solution. Any of the given architectures could support shoving keys into USM and I think that is a separate issue (the use of USM or something else) and should be treaded separately. All three of the architectures (or deviations to the existing protocols) could feed keys to USM or to something different. Let's forget about USM for the time being and concentrate just on keys. Yes, they're highly interrelated but I suspect if we don't separate the issues we'll never come to an agreement. Ken> Features: Ken> - Can make use of existing USM (already-analyzed protocol). They can all do this somehow or another. Ken> - Likely wide variety of IETF protocols to use as out-of-band Ken> keying protocol Yes, but the architectures of those other systems are often very different. As I explained in a previous note (which I'm not going to repeat here), SNMP has potentially many components running on a device. The choices for how to deal with this problem result in either: 1) interoperability between all SNMP *and* key-distribution-protocol stack vendors on a given device. [4 SNMP stack vendors and 4 key dist. vendors = 16 possibilities] 2) run one independent keying service per SNMP service on the device. [the result being N-2*N ports open, where N is the number of SNMP related ports open with one new one per service.]. One of the goals of this working group is to reuse existing mechanisms. I do not think that existing keying exchanges are used today in many cases that we can reuse here. EAP and IKEv2 have been shown to be not-very-good fits (to say the least) and that doesn't leave anything else but kerberos. Kerberos is actually a nice solution to the above problem, as it is ticket based and the tickets have service names/keys attached to them. However, kerberos isn't in wide use (unfortunately) and it would still require modification to the SNMP protocol to get the key from the ticket put into the service. Ken> - Encryption/checksum modes limited to ones supported by USM Again, this is not a fact of the architecture but of EUSM's implementation. We agreed in MSP to talk about the architecture features more than the solution features. Ken> - Extra care would be required to assure keying material derived from Ken> out-of-band exchange is matched with a particular USM session. External keying protocols really need a key identifier and a destination identifier. In summary, I'm not a fan of an external keying protocols for this situation [it's the only one I'm not a fan of actually]. I've used them many times in other situations where they have worked well, but I don't think it's a good fit for SNMP at all. The complexity discussed in a previous message above and above cause too many problems when I considered trying to implement it in a number of the stacks I work with (the open source ones being Net-SNMP, OpenSNMP & Net-Policy). It simply couldn't be done without breaking the high level of portability of some of those projects in the process of adding external keying. Additionally, I don't see an existing deployment of this technique that makes me want to marry it to SNMP. Many of the external keying protocols are definitely being used, but they're not being used heavily. IKE doesn't exist in most devices. EAP doesn't exist in many devices (I'd argue "most" but I don't have numbers to back that up). Kerberos doesn't exist in most devices and doesn't have wide deployment. If half of our point is to reuse what is available and deployed today, I don't think it's wise to go down this road as we'd be breaking from our goals. I do not believe that operators today are using seperate keying mechanisms for 99% of what they do. It has great penetration into only parts of small, not-complete markets (such as VPN and WAP environments) but not for the rest of the deployed enterprises. At least based on the discussions I've had with users. ---------------------------------------------------------------------- Ken> - "In Band Keying" Ken> This is the approach taken by SBSM. The security protocol is Ken> contained within SNMP payloads and likely whatever protocol is chosen Ken> will have a way to secure the PDU contents. Ken> Features: Ken> - Requires new SNMP security model. They all do. Well, TLSM hasn't actually stated that. EUSM is a new security model with a low new footprint as it reuses the message payload and protocol steps (a big reuse) but requires a new security number on the wire (and thus at least a small change to existing stacks, though it's the smallest of them all). SBSM requires a new security model for use in negotiating keys, which requires new code for doing so within the SNMP stacks. It could reuse USM for running-session traffic, but again I'll save that argument for a later date when we get to that point. Ken> - Is more in line with the traditional way security is applied to Ken> application protocols. Interesting phrasing ;-) It is more traditional, but it's also the tradition that is often hated by many to be fair. That being said, as I explained in a previous message there was a reason I went with this approach after considering the others. I won't repeat that here. Ken> - Exact privacy/integrity details will need to be specified by this or Ken> other protocol (depending on which framework is chosen). *** More features: - transport independent (UDP, TCP, AAL5, ...). I can't predict the future use of the protocol, and thus this is a nice-to-have in my opinion (besides the fact that I have a fair number of users using it over non UDP/TCP transports; a lot more than I'd expect actually) ---------------------------------------------------------------------- Ken> - "Encapsulation keying" Ken> This is the approach taken by TLSM. An encapsulation protocol (such Ken> as TLS) is used to "wrap" SNMP payloads. A traditional USM could be Ken> run underneath this protocol. [there may be issues with running USM underneath but it is possible] Ken> - Likely requires no changes to SNMP protocol. I disagree. I think it would be unwise to at least not assign a new security model number. USM and any TLSM based session should have different identifiers, IMHO. (I'd actually assign one per each TLSM base transport personally). It has only been discussed a little bit Ken> - Is used by a number of other protocols with a great deal of success. Ken> - _May_ require the use of TCP. Existing commonly in-use versions certainly well. There is no current widely-deployed underlying transport that doesn't use TCP. I'm not convinced we should dump UDP and move to TCP, but I think DTLS will hopefully cover this ground for this spot if it goes forward. I think a "Encapsulation keying" provides a nice warm feeling because it's able to use commonly deployed and in use mechanisms (namely TLS and SSH), but it does suffer problems as well namely that the number of transports to choose from are fairly limited and are restricted to UDP and TCP based transports, but then again that does cover 99% of the cases. The other nice thing about the encapsulation is that it provides protection better than what USM itself provides and since you get that for free (assuming we pick reasonable transports) then the whole USM/new-model argument is pretty much moot. It's also been implemented before by a number of people. In summary, I'd be happy with an Encapsulation Keying mechanism though I don't think we'd get quite the deployment level that we might achieve with an "In Band Keying" mechanism it'd still be fairly high (certainly significantly higher than current SNMPv3). -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Tue Mar 22 23:25:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20483; Tue, 22 Mar 2005 23:25:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDxWM-0005GP-6P; Tue, 22 Mar 2005 23:31:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDxPT-0000tU-5v; Tue, 22 Mar 2005 23:23:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDxPI-0000mE-SR for isms@megatron.ietf.org; Tue, 22 Mar 2005 23:23:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20271 for ; Tue, 22 Mar 2005 23:23:46 -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 1DDxUg-0005C1-HO for isms@ietf.org; Tue, 22 Mar 2005 23:29:23 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id BFEFE11D89B; Tue, 22 Mar 2005 20:23:40 -0800 (PST) From: Wes Hardaker To: Kaushik Narayan Subject: Re: [Isms] Discussion: Architecture direction for ISMS Organization: Sparta References: <200503182340.j2INeDCX028230@ginger.cmf.nrl.navy.mil> <6.2.0.14.0.20050321174030.03e68ae8@mira-sjc5-a.cisco.com> Date: Tue, 22 Mar 2005 20:23:39 -0800 In-Reply-To: <6.2.0.14.0.20050321174030.03e68ae8@mira-sjc5-a.cisco.com> (Kaushik Narayan's message of "Mon, 21 Mar 2005 17:47:45 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 >>>>> On Mon, 21 Mar 2005 17:47:45 -0800, Kaushik Narayan said: Kaushik> We believe that use of in-band and out-of-band keying is not Kaushik> the most important difference between EUSM and SBSM. This is a different argument than you've been previously making. One of the whole purposes of this discussion was to come to agreement on something, namely an architecture first. In your response you didn't seem to state clearly if you had preferences for one or two of the architectures. It appears that you're no longer solely considering an out-of-band mechanism which is a very good thing because if we can all agree to move a "little bit" we'll likely end up somewhere that we can at least agree upon even if it's not the ideal place for each of us. Kaushik> We believe the most important differences are So, given that can we concentrate on a preferred architecture first and then battle the USM issue. This is what we agreed upon in MSP but yet everyone seems to want to argue the USM case instead. Kaushik> ... we had proposed the use of EAP for Key Setup and we plan Kaushik> to suggest the use of TLS or GSSAPI for Key Setup. Given the above statement, I originally thought you had meant either out of band or in-band-underneath would be fine (GSSAPI is out-of-band sort of... GSSAPI is really an API not an architecture but the current common mechanism (kerberos) is out-of-band). But having re-read what you've said I could see someone proposing TLS on the side to do out-of-band negotiation over TLS. I assume this is not what you're going to propose since it would be somewhat unusual but thought I should double check. So, if you had to pick two (or one) of the architectures (*not* solutions for those architectures) it sounds like you're at least willing to consider "encapsulation" (TLS like) or "out of band" (EAP like) architectures? It sounds like we're (the group as a whole) actually converging on an architecture which is acceptable to everyone, which is a really really good thing. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 09:27: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 JAA18606; Wed, 23 Mar 2005 09:27:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6vR-0007Yh-Nb; Wed, 23 Mar 2005 09:33:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6mi-0004bW-Cl; Wed, 23 Mar 2005 09:24:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6mh-0004bR-Iq for isms@megatron.ietf.org; Wed, 23 Mar 2005 09:24:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18255 for ; Wed, 23 Mar 2005 09:24:33 -0500 (EST) Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251] helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6sA-0007TC-GF for isms@ietf.org; Wed, 23 Mar 2005 09:30:15 -0500 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO0068D0; 23 Mar 05 09:33:18 -0500 Received: from spooler by Lamicro.com (Mercury/32 v3.32); 23 Mar 05 09:33:08 -0500 Received: from connotech.com (209.71.204.110) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG0068CE; 23 Mar 05 09:32:51 -0500 Message-ID: <4241825E.4050709@connotech.com> Date: Wed, 23 Mar 2005 09:51:10 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: isms@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 7d38eb86565b1a4d8c3dba35af39014d Content-Transfer-Encoding: 7bit Subject: [Isms] A session-less fix to SNMP security issues? X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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: 1.3 (+) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Content-Transfer-Encoding: 7bit Subject: A session-less fix to SNMP security issues? Dear isms wg members, The current isms activity is an architectural review. This message is intended as a contribution towards the isms advancement, however not based on either architectural proposals currently under review. I am taking the isms pursuit from a security perspective. I recently became aware and interested in the proposal comparison document ([COMPAR]) during a search of security scheme documents addressing the provisioning of pre-shared secrets. Table of contents 1. Situation analysis 2. Proposal 2.1. Desirable Properties 2.2. Proposal Strategy 3. Solution 3.1. Solution Context 3.2. A Sample Protocol Suite 3.2.1. SSH 3.2.2. RADIUS 3.2.3. SNMPv3 3.3. SAKEM Use Pattern 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure 3.4.2. SNMPv3 Installation-Related Operation 3.4.3. The SNMPv3 Agent User Management Operations 3.5. Server-Side Arrangements 4. Conclusion 5. Intellectual Property Notice 6. References 1. Situation analysis The following situation analysis uses some external sources of understanding: o the isms meeting audio recording ([AUDIO]) -- somehow usable despite low recording level and missing recording from some seats in the meeting room, o the reference [MSG445] o the author's organization promoted solution element, SAKEM (Secret Authentication Key Establishment Method) ([SAKEM_WP] and [SAKEM_IND]), o an inference from a mailing list message ([MSG319]) () that a workable SNMP agent configuration strategy can rest on a single "initial user" account, even with the initial-no-access-configuration option (defined in [RFC3415]). The main situation analysis elements are: o The major discomfort with the SNMPv3 security scheme is that "Key management with manual keying is extremely difficult in any system." From [COMPAR]. o There are very few proposals that directly address the above difficulty. From [SAKEM_WP]. o The SNMPv3 security scheme is application-level security, implementing datagram security (connectionless security protocol) with symmetric-key cryptography. o The SNMPv3 key management is a simple symmetric key derivation scheme, i.e. key derived from user passwords. Accordingly, the derived symmetric keys need to be (securely) configured in each SNMP agent, but the user passwords need not be stored on the SNMP manager side (it is a local implementation decision to store a user passwords on the SNMP manager side). o The current SNMPv3 security solution comprises no notion of a session to which a security association can be plugged. The three isms proposals appear to change this architectural trait in order to benefit from various security protocols which derive session master keys from long-term authentication secrets. From [COMPAR]. o According to [MSG319], the out-of-box security configuration for SNMPv3 would be a single pre-shared secret key derived from an "initial user" password. o Operational stability is best ensured if the "initial user" password is stored or backed up in a secure server for the administrative domain (hereafter "USM secure store"). o VACM is not broken. From [AUDIO], circa 58 minutes from start of recording. (Without further supporting data, not even having understood VACM, I assume that VACM need not be fixed.) 2. Proposal 2.1. Desirable Properties The desirable properties of a solution path, mainly motivated by the network operator's operational needs: o As little change as possible to the SNMPv3 implementations. From [AUDIO]. o The typical out-of-box procedure for a new network element comprises the installation of a number of security protocols, each with its manual cryptographic key configuration requirement (pre-shared secret passwords are analogue to cryptographic keys in this context): . SSH (host public key to be certified, see[SSH_ARCH]) . Radius NAS-to-server (symmetric secret key for mutual authentication, see [RFC2865]) . VPN enrolment (...) . SNMPv3 (pre-shared secret key derived from the "initial user" password) From [MSG445], [MSG319], and [AUDIO]. See also [OPSEC], section 2.3.2. o Perhaps a fallback mode of operation (or backwards compatibility) to the original SNMPv3 USM is an inescapable requirement. From [MSG445]. A secondary goal is ignored herein to keep focused on the main issues: o In SNMPv3, authentication and privacy keys are derived with a single mechanism. This looks like an original SNMPv3 design flaw (i.e. it would have been easy to specify differentiated derivations for authentication and privacy). In any case, a fix would be to use the recently standardized CCM mode of operation [CCM]. From [RFC3414] section 11.2. 2.2. Proposal Strategy The main strategy for this proposal is 1. stick to connectionless security as specified in SNMPv3, 2. specify additional symmetric key management operations, 3. allow protocol elements to remain unspecified at this stage (because symmetric-key cryptography is simpler, e.g. fewer rounds of session key derivation protocol, than public-key cryptography, at the expense of more limited set of threat prevention, e.g. lack of perfect forward secrecy), 4. address the manual pre-shared secret distribution problem in a systematic way (SAKEM), and 5. attempt to apply this systematic approach to other security protocols configured in a typical out-of-box installation (a network device authentication consolidation approach, not unlike the single-sign-on paradigm for user authentication). Stepping back in the isms activities, this proposal re- focuses on the SNMPv3 operational hindrance and shows (?) that the three isms proposals carry a major architectural change (moving away from the SNMPv3 connectionless protocol and simple symmetric-key security model) that is not clearly related to the major operational issue. 3. Solution 3.1. Solution Context Within an administrative domain, the solution assumes three execution environments: 1) field network devices, which may run SNMP agents, 2) secure servers premises, and 3) administrative systems, which may run SNMP manager applications. The secure server premises is the proper place for secure databases (e.g. Radius server databases) and security certificate issuing systems/applications in support of public key cryptography (e.g. to certify a network device public key for the SSH protocol). Note that public key cryptography is introduced in the present proposal because protocols alongside SNMPv3 use it, and the consolidation approach supports it (in some configurations at least). 3.2. A Sample Protocol Suite Since we are contemplating a consolidated solution to the device authentication needs of a number of security protocols, we may list some candidate protocols with some explanation about how the individual solutions can converge towards a common method for the very initial authentication of keys and secrets. 3.2.1. SSH In SSH, the network device needs to set up a private/public key pair for routine device authentication afterwards. Within the secure server premises, SSH deployment needs either a trusted database of public keys or a security certificate issuance function (see section 4.1 of [SSH_ARCH]). In either case, a proof-of-possession should be delivered to the secure server premises, providing confidence that the network device is able to sign some authenticated shared secret with the private counterpart of the alleged public key. Thus, the SAKEM procedure and technology may be used to authenticate a shared secret between a new SSH host protocol entity in a network device and a central organization's secure server premises. The SSH host implementation need to digitally sign this shared secret (specifically, a conventional string containing the shared secret or a string conventionally derived from the shared secret, as a necessary countermeasure against chosen ciphertext attacks, as is well understood among public key cryptography experts). The SSH host implementation already performs digital signature operations. The additional requirement shouldn't be overly difficult. 3.2.2. RADIUS If RADIUS is used to control access to a network device e.g. for command line system management interface, the network device acts as a NAS (Network Access Server) in the RADIUS terminology. The RADIUS protocol links the NAS to the RADIUS server (in the secure server premises). Upon device installation, the NAS and RADIUS server must be provisioned with a pre-shared secret. This is a straightforward application for the SAKEM procedure and technology. 3.2.3. SNMPv3 In the secure server premises, the SNMPv3 "USM secure store" (where SNMPv3 passwords are stored for an administrative domain) holds the "initial user" password from which the initial SNMPv3 pre-shared secret must be derived for any new network device. In this case, the SAKEM procedure and technology can pre-share an unpredictable binary secret key, which is neither a password nor a value derived from a password. Some key management provisions must be made to turn this network device pre-shared secret into a secret derived (localized) from a password for every SNPMv3 agent implementations on this device. First, there is a many-to-one relationship between SNMPv3 agents (identified by snmpEngineID) and network devices. This needs to be reflected in the procedural aspect of SAKEM, i.e. the identity that is verified in this context is the list of snmpEngineID-s installed (or to be installed) on this device. The key management provision addressing this many-to-one relationship is a secret key derivation (details to be specified) based on the snmpEngineID value. Then, the derived secret key for an SNMPv3 engine can be used to protect (e.g. for confidentiality and data authentication using the CCM mode of operation [CCM]) a message from the "USM secure store" to the SNMPv3 engine with the data triplet "initial user" name, privacy key, authentication key. We later refer to such message as the *protected message*. 3.3. SAKEM Use Pattern Although the three protocols SSH / RADIUS / SNMPv3 are introduced as a representative set of protocols for out-of-box installation, we also get representatives of three different SAKEM integration patterns: Protocol Authenticated pre-shared secret use pattern ======== =========================================== RADIUS Direct use of authenticated pre-shared secret SSH Authenticated pre-shared secret used in a proof- of-possession for public key certificate issuance SNMPv3 Authenticated pre-shared secret protecting a password (or value derived from password) configuration message 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure The SNMPv3 agent must securely store (same kind of secure storage applicable to shared secrets) an authenticated pre-shared secret received from the SAKEM client-side software. 3.4.2. SNMPv3 Installation-Related Operation The SNMPv3 agent must receive the *protected message* holding the "initial user" account data (user name, authentication key, privacy key). The triggering of this message transmission from the "USM secure store" to the local SNMPv3 agent is left unspecified at this point. Once so installed, the SNMPv3 agent is configured with a fallback "initial user" account. 3.4.3. The SNMPv3 Agent User Management Operations Synchronization between SNMP user management and authentication protocols (e.g. RADIUS) is a goal of the isms working group charter. The present proposal implements this with 1) a small change to SNMPv3 agent implementation, and 2) use of some RADIUS protocol implementation-specific attributes for the purpose of SNMPv3 user management integration (IANA considerations set aside). The main change in the SNMPv3 agent implementation is the support for the receipt of a *protected message* holding user account data for a given user (user name, authentication key, privacy key). Implementation-wise, this looks like the re-use of the "initial user" setup as described above. Security-wise, there a important difference: the SNMPv3 agent implementation must be protected from replay attacks (e.g. local mitigation by implementation integration of the SNMPv3 security code and the RADIUS NAS code). The RADIUS protocol support of SNMPv3 user management is an implementation-specific attribute in the Access-Request packet to indicate to the RADIUS server that some "Authenticate Only" service type request is a request to a) authenticate the end- user, b) validate that the end-user is allowed SNMPv3 agent registration, and c) convey the above *protected message* to the NAS in the network device, in an implementation-specific attribute to the RADIUS Access-Accept packet. The daily network management operations work as follows: o Upon hiring a new employee in the network management function, a user name and password is created in the "USM secure store." o The first time an employee wishes to perform an SNMP operation targeted at an SNMP agent, he/she must first authenticate with the RADIUS NAS server residing on the same network device, requesting the implementation- specific service arrangement described above. This is when the "USM secure store" application prepares the *protected message* for users other than the initial one. o When the employee leaves or when a password change is required, every SNMP agents which was within his/her reach must be notified (i.e. the employee user name must be removed or disabled). Most SNMP management systems should be flexible enough to have this task automated. 3.5. Server-Side Arrangements The server-side arrangement details are numerous but "straightforward" (for the present author to formulate, and maybe for some readers). A SAKEM implementation document uses the term "Functional Area" for the required secure application in the secure server premises ("FA systems"). The SAKEM FA system required for the current proposal integrates the support of SSH out-of-box deployment, RADIUS NAS out-of-box deployment, and the proposed RADIUS-SNMPv3 integration. 4. Conclusion The above proposal is a two-sided solution to the SNMPv3 operational difficulties: A) the "initial user" manual configuration is recognized as a familiar difficulty with other protocols in an out-of-box procedures for new network devices (we propose the IP- restricted SAKEM procedure and technology), and B) the SNMPv3 user management function is facilitated with a simple integration scheme that do not change the original SNMPv3 security model. Obviously, the present proposal reliance on RADIUS is mostly for convenience of feasability demonstration. This proposal author does not claim that a session-oriented security protocol is inappropriate for SNMPv3 (e.g. we do nothing about the 150 seconds anti-replay protection timeout). However, we suggest that SNMPv3 difficulties can also be addressed differently. 5. Intellectual Property Notice The SAKEM procedure and technology is covered by the United States patent number 6,061,791. Generally speaking, if proprietary elements of the SAKEM procedure and technology becomes part of a publicly available standard established by an open standardization body, CONNOTECH is willing to negotiate licenses for these intellectual property rights on reasonable and nondiscriminatory terms and conditions. Please contact CONNOTECH Experts-conseils inc. for further details. 6. References [COMPAR] R. Presuhn, Ed., U. Blumenthal, L. Dondeti, E. Rescorla, "Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol)", Internet-Draft, draft-ietf-isms-proposal-comparison-00.txt, February 13, 2005 [AUDIO] audio recording file ietf62-ch5-mon-eve.mp3 retrieved from the IETF web site [MSG445] a mailing list message from Wes Hardaker about "design decisions in SBSM", http://www1.ietf.org/mail-archive/web/isms/current/msg00445. html [SAKEM_WP] http://www.connotech.com/sakem_white_paper_06.htm [SAKEM_IND] http://www.connotech.com/sakem_index.htm [MSG319] http://www1.ietf.org/mail-archive/web/isms/current/msg00379. html [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC3415, December 2002 [SSH_ARCH] draft-ietf-secsh-architecture-21.txt [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS).", RFC-2865, June 2000 [OPSEC] draft-ietf-opsec-current-practices-00.txt [CCM] Morris Dworkin, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, May 2004 [RFC3414] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC-3414, December 2002 -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 09:49: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 JAA21025; Wed, 23 Mar 2005 09:49:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7GQ-0008Bb-Vr; Wed, 23 Mar 2005 09:55:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE79F-0008WB-5V; Wed, 23 Mar 2005 09:47:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE79D-0008W3-GC for isms@megatron.ietf.org; Wed, 23 Mar 2005 09:47:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20653 for ; Wed, 23 Mar 2005 09:47:49 -0500 (EST) Received: from sls-ce10p21.dca2.superb.net ([66.36.242.103] helo=hosting.revelstone.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7Eh-00087Q-3H for isms@ietf.org; Wed, 23 Mar 2005 09:53:32 -0500 Received: from localhost ([127.0.0.1] helo=aud) by hosting.revelstone.com with smtp (Exim 4.44) id 1DE796-0003ZT-UJ; Wed, 23 Mar 2005 09:47:45 -0500 Date: Wed, 23 Mar 2005 09:48:29 -0500 From: Robert Story To: Thierry Moreau Subject: Re: [Isms] A session-less fix to SNMP security issues? Message-ID: <20050323094829.4ac5010f@aud> In-Reply-To: <4241825E.4050709@connotech.com> References: <4241825E.4050709@connotech.com> X-Mailer: Sylpheed-Claws 0.9.12b (GTK+ 1.2.10; powerpc-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - hosting.revelstone.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - freesnmp.com X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit On Wed, 23 Mar 2005 09:51:10 -0500 Thierry wrote: TM> The SAKEM procedure and technology is covered by the United TM> States patent number 6,061,791. Generally speaking, if TM> proprietary elements of the SAKEM procedure and technology TM> becomes part of a publicly available standard established by an TM> open standardization body, CONNOTECH is willing to negotiate TM> licenses for these intellectual property rights on reasonable and TM> nondiscriminatory terms and conditions. I would very strongly oppose adopting any solution encumbered with IPR. -- Robert Story; NET-SNMP Junkie Support: You are lost in a twisty maze of little standards, all different. _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 10:12: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 KAA23456; Wed, 23 Mar 2005 10:12:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7cF-0000OX-61; Wed, 23 Mar 2005 10:17:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7V7-0004Pm-JL; Wed, 23 Mar 2005 10:10:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7V5-0004Ph-AB for isms@megatron.ietf.org; Wed, 23 Mar 2005 10:10:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23282 for ; Wed, 23 Mar 2005 10:10:24 -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 1DE7aV-0000N4-Tf for isms@ietf.org; Wed, 23 Mar 2005 10:16:06 -0500 Received: from fmsfmr100.fm.intel.com (fmsfmr100.fm.intel.com [10.1.192.58]) by fmsfmr002.fm.intel.com (8.12.10/8.12.10/d: major-outer.mc, v 1.1 2004/09/17 17:50:56 root Exp $) with ESMTP id j2NFA9G6031001 for ; Wed, 23 Mar 2005 15:10:09 GMT Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by fmsfmr100.fm.intel.com (8.12.10/8.12.10/d: major-inner.mc, v 1.2 2004/09/17 18:05:01 root Exp $) with SMTP id j2NFA1cI007564 for ; Wed, 23 Mar 2005 15:10:09 GMT Received: from fmsmsx332.amr.corp.intel.com ([132.233.42.148]) by fmsmsxvs041.fm.intel.com (SAVSMTP 3.1.7.47) with SMTP id M2005032307100911846 for ; Wed, 23 Mar 2005 07:10:09 -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); Wed, 23 Mar 2005 07:10:09 -0800 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 23 Mar 2005 07:10:08 -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, 23 Mar 2005 10:10:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Isms] A session-less fix to SNMP security issues? Date: Wed, 23 Mar 2005 10:09:51 -0500 Message-ID: <3DEC199BD7489643817ECA151F7C5929DE09BD@pysmsx401.amr.corp.intel.com> Thread-Topic: [Isms] A session-less fix to SNMP security issues? Thread-Index: AcUvtFHNsdJ3zrUQQ0y735RhCSeHRQABODlA From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 23 Mar 2005 15:10:07.0642 (UTC) FILETIME=[664927A0:01C52FBA] X-Scanned-By: MIMEDefang 2.44 X-Spam-Score: 0.0 (/) X-Scan-Signature: 54f716cba2c98b25bc07e094cc18394c 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: e52c6009a9b39871b75233310d7f3490 Content-Transfer-Encoding: quoted-printable I think the authors of this proposal fail to understand one fundamental issue. Authentication is necessary for each and every packet. Desired means for=20 authentication are way too expensive to be carried out on per-packet basis. Thus it is necessary to split the work - authenticate something (i.e. session keys) and define the (relatively short) lifetime of that authenticated . It enables cost-efficient per-session mechanisms to co-exist with desirable but expensive session-establishment mechanisms. This THEORETICALLY does not allow for conceptual connection-less. Please explain - as briefly as possible - how you propose to circumvent this issue. I.e. how to provide online authentication with RADIUS, and yet stay session-less? [From what I read below - it looks like an attempt to find a problem for the solution.] -----Original Message----- From: isms-bounces@lists.ietf.org [mailto:isms-bounces@lists.ietf.org] On Behalf Of Thierry Moreau Sent: Wednesday, March 23, 2005 9:51 AM To: isms@ietf.org Subject: [Isms] A session-less fix to SNMP security issues? Subject: A session-less fix to SNMP security issues? Dear isms wg members, The current isms activity is an architectural review. This message is intended as a contribution towards the isms advancement, however not based on either architectural proposals currently under review. I am taking the isms pursuit from a security perspective. I recently became aware and interested in the proposal comparison document ([COMPAR]) during a search of security scheme documents addressing the provisioning of pre-shared secrets. Table of contents 1. Situation analysis 2. Proposal 2.1. Desirable Properties 2.2. Proposal Strategy 3. Solution 3.1. Solution Context 3.2. A Sample Protocol Suite 3.2.1. SSH 3.2.2. RADIUS 3.2.3. SNMPv3 3.3. SAKEM Use Pattern 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure 3.4.2. SNMPv3 Installation-Related Operation 3.4.3. The SNMPv3 Agent User Management Operations 3.5. Server-Side Arrangements 4. Conclusion 5. Intellectual Property Notice 6. References 1. Situation analysis The following situation analysis uses some external sources of understanding: o the isms meeting audio recording ([AUDIO]) -- somehow usable despite low recording level and missing recording from some seats in the meeting room, o the reference [MSG445] o the author's organization promoted solution element, SAKEM (Secret Authentication Key Establishment Method) ([SAKEM_WP] and [SAKEM_IND]), o an inference from a mailing list message ([MSG319]) () that a workable SNMP agent configuration strategy can rest on a single "initial user" account, even with the initial-no-access-configuration option (defined in [RFC3415]). The main situation analysis elements are: o The major discomfort with the SNMPv3 security scheme is that "Key management with manual keying is extremely difficult in any system." From [COMPAR]. o There are very few proposals that directly address the above difficulty. From [SAKEM_WP]. o The SNMPv3 security scheme is application-level security, implementing datagram security (connectionless security protocol) with symmetric-key cryptography. o The SNMPv3 key management is a simple symmetric key derivation scheme, i.e. key derived from user passwords. Accordingly, the derived symmetric keys need to be (securely) configured in each SNMP agent, but the user passwords need not be stored on the SNMP manager side (it is a local implementation decision to store a user passwords on the SNMP manager side). o The current SNMPv3 security solution comprises no notion of a session to which a security association can be plugged. The three isms proposals appear to change this architectural trait in order to benefit from various security protocols which derive session master keys from long-term authentication secrets. From [COMPAR]. o According to [MSG319], the out-of-box security configuration for SNMPv3 would be a single pre-shared secret key derived from an "initial user" password. o Operational stability is best ensured if the "initial user" password is stored or backed up in a secure server for the administrative domain (hereafter "USM secure store"). o VACM is not broken. From [AUDIO], circa 58 minutes from start of recording. (Without further supporting data, not even having understood VACM, I assume that VACM need not be fixed.) 2. Proposal 2.1. Desirable Properties The desirable properties of a solution path, mainly motivated by the network operator's operational needs: o As little change as possible to the SNMPv3 implementations. From [AUDIO]. o The typical out-of-box procedure for a new network element comprises the installation of a number of security protocols, each with its manual cryptographic key configuration requirement (pre-shared secret passwords are analogue to cryptographic keys in this context): . SSH (host public key to be certified, see[SSH_ARCH]) . Radius NAS-to-server (symmetric secret key for mutual authentication, see [RFC2865]) . VPN enrolment (...) . SNMPv3 (pre-shared secret key derived from the "initial user" password) From [MSG445], [MSG319], and [AUDIO]. See also [OPSEC], section 2.3.2. o Perhaps a fallback mode of operation (or backwards compatibility) to the original SNMPv3 USM is an inescapable requirement. From [MSG445]. A secondary goal is ignored herein to keep focused on the main issues: o In SNMPv3, authentication and privacy keys are derived with a single mechanism. This looks like an original SNMPv3 design flaw (i.e. it would have been easy to specify differentiated derivations for authentication and privacy). In any case, a fix would be to use the recently standardized CCM mode of operation [CCM]. From [RFC3414] section 11.2. 2.2. Proposal Strategy The main strategy for this proposal is 1. stick to connectionless security as specified in SNMPv3, 2. specify additional symmetric key management operations, 3. allow protocol elements to remain unspecified at this stage (because symmetric-key cryptography is simpler, e.g. fewer rounds of session key derivation protocol, than public-key cryptography, at the expense of more limited set of threat prevention, e.g. lack of perfect forward secrecy), 4. address the manual pre-shared secret distribution problem in a systematic way (SAKEM), and 5. attempt to apply this systematic approach to other security protocols configured in a typical out-of-box installation (a network device authentication consolidation approach, not unlike the single-sign-on paradigm for user authentication). Stepping back in the isms activities, this proposal re- focuses on the SNMPv3 operational hindrance and shows (?) that the three isms proposals carry a major architectural change (moving away from the SNMPv3 connectionless protocol and simple symmetric-key security model) that is not clearly related to the major operational issue. 3. Solution 3.1. Solution Context Within an administrative domain, the solution assumes three execution environments: 1) field network devices, which may run SNMP agents, 2) secure servers premises, and 3) administrative systems, which may run SNMP manager applications. The secure server premises is the proper place for secure databases (e.g. Radius server databases) and security certificate issuing systems/applications in support of public key cryptography (e.g. to certify a network device public key for the SSH protocol). Note that public key cryptography is introduced in the present proposal because protocols alongside SNMPv3 use it, and the consolidation approach supports it (in some configurations at least). 3.2. A Sample Protocol Suite Since we are contemplating a consolidated solution to the device authentication needs of a number of security protocols, we may list some candidate protocols with some explanation about how the individual solutions can converge towards a common method for the very initial authentication of keys and secrets. 3.2.1. SSH In SSH, the network device needs to set up a private/public key pair for routine device authentication afterwards. Within the secure server premises, SSH deployment needs either a trusted database of public keys or a security certificate issuance function (see section 4.1 of [SSH_ARCH]). In either case, a proof-of-possession should be delivered to the secure server premises, providing confidence that the network device is able to sign some authenticated shared secret with the private counterpart of the alleged public key. Thus, the SAKEM procedure and technology may be used to authenticate a shared secret between a new SSH host protocol entity in a network device and a central organization's secure server premises. The SSH host implementation need to digitally sign this shared secret (specifically, a conventional string containing the shared secret or a string conventionally derived from the shared secret, as a necessary countermeasure against chosen ciphertext attacks, as is well understood among public key cryptography experts). The SSH host implementation already performs digital signature operations. The additional requirement shouldn't be overly difficult. 3.2.2. RADIUS If RADIUS is used to control access to a network device e.g. for command line system management interface, the network device acts as a NAS (Network Access Server) in the RADIUS terminology. The RADIUS protocol links the NAS to the RADIUS server (in the secure server premises). Upon device installation, the NAS and RADIUS server must be provisioned with a pre-shared secret. This is a straightforward application for the SAKEM procedure and technology. 3.2.3. SNMPv3 In the secure server premises, the SNMPv3 "USM secure store" (where SNMPv3 passwords are stored for an administrative domain) holds the "initial user" password from which the initial SNMPv3 pre-shared secret must be derived for any new network device. In this case, the SAKEM procedure and technology can pre-share an unpredictable binary secret key, which is neither a password nor a value derived from a password. Some key management provisions must be made to turn this network device pre-shared secret into a secret derived (localized) from a password for every SNPMv3 agent implementations on this device. First, there is a many-to-one relationship between SNMPv3 agents (identified by snmpEngineID) and network devices. This needs to be reflected in the procedural aspect of SAKEM, i.e. the identity that is verified in this context is the list of snmpEngineID-s installed (or to be installed) on this device. The key management provision addressing this many-to-one relationship is a secret key derivation (details to be specified) based on the snmpEngineID value. Then, the derived secret key for an SNMPv3 engine can be used to protect (e.g. for confidentiality and data authentication using the CCM mode of operation [CCM]) a message from the "USM secure store" to the SNMPv3 engine with the data triplet "initial user" name, privacy key, authentication key. We later refer to such message as the *protected message*. 3.3. SAKEM Use Pattern Although the three protocols SSH / RADIUS / SNMPv3 are introduced as a representative set of protocols for out-of-box installation, we also get representatives of three different SAKEM integration patterns: Protocol Authenticated pre-shared secret use pattern =3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RADIUS Direct use of authenticated pre-shared secret SSH Authenticated pre-shared secret used in a proof- of-possession for public key certificate issuance SNMPv3 Authenticated pre-shared secret protecting a password (or value derived from password) configuration message 3.4. Elements of Operations Applicable to SNMPv3 Agents 3.4.1. Initial Out-of-box Procedure The SNMPv3 agent must securely store (same kind of secure storage applicable to shared secrets) an authenticated pre-shared secret received from the SAKEM client-side software. 3.4.2. SNMPv3 Installation-Related Operation The SNMPv3 agent must receive the *protected message* holding the "initial user" account data (user name, authentication key, privacy key). The triggering of this message transmission from the "USM secure store" to the local SNMPv3 agent is left unspecified at this point. Once so installed, the SNMPv3 agent is configured with a fallback "initial user" account. 3.4.3. The SNMPv3 Agent User Management Operations Synchronization between SNMP user management and authentication protocols (e.g. RADIUS) is a goal of the isms working group charter. The present proposal implements this with 1) a small change to SNMPv3 agent implementation, and 2) use of some RADIUS protocol implementation-specific attributes for the purpose of SNMPv3 user management integration (IANA considerations set aside). The main change in the SNMPv3 agent implementation is the support for the receipt of a *protected message* holding user account data for a given user (user name, authentication key, privacy key). Implementation-wise, this looks like the re-use of the "initial user" setup as described above. Security-wise, there a important difference: the SNMPv3 agent implementation must be protected from replay attacks (e.g. local mitigation by implementation integration of the SNMPv3 security code and the RADIUS NAS code). The RADIUS protocol support of SNMPv3 user management is an implementation-specific attribute in the Access-Request packet to indicate to the RADIUS server that some "Authenticate Only" service type request is a request to a) authenticate the end- user, b) validate that the end-user is allowed SNMPv3 agent registration, and c) convey the above *protected message* to the NAS in the network device, in an implementation-specific attribute to the RADIUS Access-Accept packet. The daily network management operations work as follows: o Upon hiring a new employee in the network management function, a user name and password is created in the "USM secure store." o The first time an employee wishes to perform an SNMP operation targeted at an SNMP agent, he/she must first authenticate with the RADIUS NAS server residing on the same network device, requesting the implementation- specific service arrangement described above. This is when the "USM secure store" application prepares the *protected message* for users other than the initial one. o When the employee leaves or when a password change is required, every SNMP agents which was within his/her reach must be notified (i.e. the employee user name must be removed or disabled). Most SNMP management systems should be flexible enough to have this task automated. 3.5. Server-Side Arrangements The server-side arrangement details are numerous but "straightforward" (for the present author to formulate, and maybe for some readers). A SAKEM implementation document uses the term "Functional Area" for the required secure application in the secure server premises ("FA systems"). The SAKEM FA system required for the current proposal integrates the support of SSH out-of-box deployment, RADIUS NAS out-of-box deployment, and the proposed RADIUS-SNMPv3 integration. 4. Conclusion The above proposal is a two-sided solution to the SNMPv3 operational difficulties: A) the "initial user" manual configuration is recognized as a familiar difficulty with other protocols in an out-of-box procedures for new network devices (we propose the IP- restricted SAKEM procedure and technology), and B) the SNMPv3 user management function is facilitated with a simple integration scheme that do not change the original SNMPv3 security model. Obviously, the present proposal reliance on RADIUS is mostly for convenience of feasability demonstration. This proposal author does not claim that a session-oriented security protocol is inappropriate for SNMPv3 (e.g. we do nothing about the 150 seconds anti-replay protection timeout). However, we suggest that SNMPv3 difficulties can also be addressed differently. 5. Intellectual Property Notice The SAKEM procedure and technology is covered by the United States patent number 6,061,791. Generally speaking, if proprietary elements of the SAKEM procedure and technology becomes part of a publicly available standard established by an open standardization body, CONNOTECH is willing to negotiate licenses for these intellectual property rights on reasonable and nondiscriminatory terms and conditions. Please contact CONNOTECH Experts-conseils inc. for further details. 6. References [COMPAR] R. Presuhn, Ed., U. Blumenthal, L. Dondeti, E. Rescorla, "Comparison of Proposals for Integrated Security Models for SNMP (Simple Network Management Protocol)", Internet-Draft, draft-ietf-isms-proposal-comparison-00.txt, February 13, 2005 [AUDIO] audio recording file ietf62-ch5-mon-eve.mp3 retrieved from the IETF web site [MSG445] a mailing list message from Wes Hardaker about "design decisions in SBSM", http://www1.ietf.org/mail-archive/web/isms/current/msg00445. html [SAKEM_WP] http://www.connotech.com/sakem_white_paper_06.htm [SAKEM_IND] http://www.connotech.com/sakem_index.htm [MSG319] http://www1.ietf.org/mail-archive/web/isms/current/msg00379. html [RFC3415] B. Wijnen, R. Presuhn, K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC3415, December 2002 [SSH_ARCH] draft-ietf-secsh-architecture-21.txt [RFC2865] C. Rigney, S. Willens, A. Rubens, W. Simpson, "Remote Authentication Dial In User Service (RADIUS).", RFC-2865, June 2000 [OPSEC] draft-ietf-opsec-current-practices-00.txt [CCM] Morris Dworkin, "Recommendation for Block Cipher Modes of Operation: The CCM Mode for Authentication and Confidentiality", NIST Special Publication 800-38C, May 2004 [RFC3414] U. Blumenthal, B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC-3414, December 2002 --=20 - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 12:37: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 MAA10949; Wed, 23 Mar 2005 12:37:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9tG-0004ow-FQ; Wed, 23 Mar 2005 12:43:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9nA-0003NJ-Mk; Wed, 23 Mar 2005 12:37:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE9n8-0003Lz-H6 for isms@megatron.ietf.org; Wed, 23 Mar 2005 12:37: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 MAA10900 for ; Wed, 23 Mar 2005 12:37:11 -0500 (EST) Message-Id: <200503231737.MAA10900@ietf.org> Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE9sd-0004nt-Kh for isms@ietf.org; Wed, 23 Mar 2005 12:42:56 -0500 Received: from djyxpy41 (h00104b8ce2a3.ne.client2.attbi.com[24.128.104.220]) by comcast.net (sccrmhc12) with SMTP id <2005032317370301200ebcjee>; Wed, 23 Mar 2005 17:37:04 +0000 From: "David B Harrington" To: "'Robert Story'" , "'Thierry Moreau'" Subject: RE: [Isms] A session-less fix to SNMP security issues? Date: Wed, 23 Mar 2005 12:36: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.6353 In-Reply-To: <20050323094829.4ac5010f@aud> thread-index: AcUvt4lcLlR8bJs3ToK8DtivteYDbAAFzGsg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ietfdbh@comcast.net List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit I concur that we should not base a new IETF standard security model on an approach that is encumbered by IPR. dbh > -----Original Message----- > From: isms-bounces@lists.ietf.org > [mailto:isms-bounces@lists.ietf.org] On Behalf Of Robert Story > Sent: Wednesday, March 23, 2005 9:48 AM > To: Thierry Moreau > Cc: isms@ietf.org > Subject: Re: [Isms] A session-less fix to SNMP security issues? > > On Wed, 23 Mar 2005 09:51:10 -0500 Thierry wrote: > TM> The SAKEM procedure and technology is covered by the United > TM> States patent number 6,061,791. Generally speaking, if > TM> proprietary elements of the SAKEM procedure and technology > TM> becomes part of a publicly available standard established by an > TM> open standardization body, CONNOTECH is willing to negotiate > TM> licenses for these intellectual property rights on reasonable and > TM> nondiscriminatory terms and conditions. > > I would very strongly oppose adopting any solution encumbered > with IPR. > > -- > Robert Story; NET-SNMP Junkie > Support: > > You are lost in a twisty maze of little standards, all different. > > _______________________________________________ > Isms mailing list > Isms@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/isms > _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 13:11: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 NAA14893; Wed, 23 Mar 2005 13:11:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEAQD-0005n6-Af; Wed, 23 Mar 2005 13:17:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAJo-0000VI-GJ; Wed, 23 Mar 2005 13:11:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEAJm-0000UH-Mf for isms@megatron.ietf.org; Wed, 23 Mar 2005 13:10: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 NAA14777 for ; Wed, 23 Mar 2005 13:10:55 -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 1DEAPH-0005lc-VC for isms@ietf.org; Wed, 23 Mar 2005 13:16:41 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id EFB1211D724; Wed, 23 Mar 2005 10:10:51 -0800 (PST) From: Wes Hardaker To: ietfdbh@comcast.net Subject: Re: [Isms] A session-less fix to SNMP security issues? Organization: Sparta References: <200503231737.MAA10900@ietf.org> Date: Wed, 23 Mar 2005 10:10:51 -0800 In-Reply-To: <200503231737.MAA10900@ietf.org> (David B. Harrington's message of "Wed, 23 Mar 2005 12:36:54 -0500") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Wed, 23 Mar 2005 12:36:54 -0500, "David B Harrington" said: David> I concur that we should not base a new IETF standard security model on David> an approach that is encumbered by IPR. Thirded. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 14: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 OAA20246; Wed, 23 Mar 2005 14:04:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBFU-0007M9-R8; Wed, 23 Mar 2005 14: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 1DEB8H-0008NJ-6T; Wed, 23 Mar 2005 14:03:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEB8G-0008NE-6n for isms@megatron.ietf.org; Wed, 23 Mar 2005 14:03: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 OAA20030 for ; Wed, 23 Mar 2005 14:03:06 -0500 (EST) Received: from 66-163-8-251.ip.tor.radiant.net ([66.163.8.251] helo=SMTP.Lamicro.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBDl-0007HY-AS for isms@ietf.org; Wed, 23 Mar 2005 14:08:50 -0500 Received: from Spooler by SMTP.Lamicro.com (Mercury/32 v3.32) ID MO006AE1; 23 Mar 05 14:11:50 -0500 Received: from spooler by Lamicro.com (Mercury/32 v3.32); 23 Mar 05 14:11:40 -0500 Received: from connotech.com (209.71.204.111) by SMTP.Lamicro.com (Mercury/32 v3.32) with ESMTP ID MG006AE0; 23 Mar 05 14:11:28 -0500 Message-ID: <4241C3AF.5000905@connotech.com> Date: Wed, 23 Mar 2005 14:29:51 -0500 From: Thierry Moreau User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [Isms] A session-less fix to SNMP security issues? References: <3DEC199BD7489643817ECA151F7C5929DE09BD@pysmsx401.amr.corp.intel.com> In-Reply-To: <3DEC199BD7489643817ECA151F7C5929DE09BD@pysmsx401.amr.corp.intel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.3 (+) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: 1.3 (+) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Blumenthal, Uri wrote: > I think the authors of this proposal fail to understand one fundamental > issue. > > Authentication is necessary for each and every packet. Desired means > for authentication are way too expensive to be carried out on per-packet > basis. Do you mean that the SNMPv3 current auhentication scheme is no good? Per-packet authentication is implemented by a data integrity crypto-mechanism based on a key (or a key derived from a key) that one party *believes* to be under the control of the remote party. In the current SNMPv3 scheme, the secret derived (localized) from the user password is that key. In most secure protocols, a session key used for integrity is usually derived from a longer-term key that is the very basis for *authentication*. > Thus it is necessary to split the work - authenticate something (i.e. > session > keys) and define the (relatively short) lifetime of that > authenticated . > It enables cost-efficient per-session mechanisms to co-exist with > desirable > but expensive session-establishment mechanisms. Indeed, cost-efficient===symmetric key crypto and expensive===public key cryptography. It is necessary to "split the work" (i.e. an hybrid crypto-system) whenever a public key-based protocol is used. > > This THEORETICALLY does not allow for conceptual connection-less. > > Please explain - as briefly as possible - how you propose to circumvent > this > issue. I.e. how to provide online authentication with RADIUS, and yet > stay > session-less? The proposed use of RADIUS for SNMPv3 user password registration in the SNMP agent is not *online authentication* on every packet. It is an occasional reliance on RADIUS (see original post, section 3.4.3), when a user accesses the SNMP agent for the first time, or when a password change has been forced. Not necessarily an elegant solution, but a solution based on minimal changes to existing protocols. (Incidentally, this specific part of the proposal is outside of CONNOTECH IPR.) There are definitional issues when applying the term *authentication* to per-packet data integrity using a key derived from a long-term authenticated key. I see the SNMPv3 deployment difficulties as the operational hindrance related to authenticating the long-term secret derived (localized) from the user password. > > [From what I read below - it looks like an attempt to find a problem for > the > solution.] > Indeed, CONNOTECH is on the watch for applications of its SAKEM procedure and technology. However, the problem statement comes from the isms comparison document. Thanks for your comments. -- - Thierry Moreau CONNOTECH Experts-conseils inc. 9130 Place de Montgolfier Montreal, Qc Canada H2M 2A1 Tel.: (514)385-5691 Fax: (514)385-5900 web site: http://www.connotech.com e-mail: thierry.moreau@connotech.com _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Wed Mar 23 14:07: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 OAA20661; Wed, 23 Mar 2005 14:07:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEBHu-0007RT-3x; Wed, 23 Mar 2005 14:13:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBCD-0000WA-UI; Wed, 23 Mar 2005 14:07:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEBCC-0000W4-GL for isms@megatron.ietf.org; Wed, 23 Mar 2005 14:07: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 OAA20628 for ; Wed, 23 Mar 2005 14:07:11 -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 1DEBHi-0007RG-BK for isms@ietf.org; Wed, 23 Mar 2005 14:12:55 -0500 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id OAA09779 for ; Wed, 23 Mar 2005 14:07:49 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma009767; Wed, 23 Mar 05 14:06:57 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Wed, 23 Mar 2005 14:06:17 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Wed, 23 Mar 2005 14:06:16 -0500 Received: from maandmbx2 ([134.141.93.31]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 23 Mar 2005 14:06:16 -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] A session-less fix to SNMP security issues? Date: Wed, 23 Mar 2005 14:06:15 -0500 Message-ID: <2A5E4540D4D5934D9A1E7E0B0FDB2D6901032256@MAANDMBX2.ets.enterasys.com> Thread-Topic: [Isms] A session-less fix to SNMP security issues? Thread-Index: AcUvt4lcLlR8bJs3ToK8DtivteYDbAAFzGsgAAMPa3A= From: "Nelson, David" To: X-OriginalArrivalTime: 23 Mar 2005 19:06:16.0837 (UTC) FILETIME=[63C8BB50:01C52FDB] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.8 X-pstn-levels: (C:65.2823 M:98.8113 P:95.9108 R:95.9108 S:43.2907 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: quoted-printable X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 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 Content-Transfer-Encoding: quoted-printable Dave Harrington writes... > I concur that we should not base a new IETF standard security model on > an approach that is encumbered by IPR. Unless, of course, the IPR holder grants an unlimited, world-wide, irrevocable, royalty-free license to use the IPR, to anyone implementing the protocol. :-) _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Fri Mar 25 14:57: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 OAA04622; Fri, 25 Mar 2005 14:57:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEv1t-0003Da-6R; Fri, 25 Mar 2005 15:03:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuuv-0001OJ-BM; Fri, 25 Mar 2005 14:56:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuuu-0001O5-GB for isms@megatron.ietf.org; Fri, 25 Mar 2005 14:56:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04513 for ; Fri, 25 Mar 2005 14:56: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 1DEv0o-0003Av-VA for isms@ietf.org; Fri, 25 Mar 2005 15:02:33 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 11:56:12 -0800 X-IronPort-AV: i="3.91,123,1110182400"; d="scan'208"; a="240917895:sNHT1319527444" 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 j2PJuADr026434; Fri, 25 Mar 2005 11:56:10 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZK76283; Fri, 25 Mar 2005 11:56:09 -0800 (PST) Message-Id: <6.2.0.14.0.20050325114402.03982dc0@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Mar 2005 11:56:08 -0800 To: hardaker@tislabs.com From: Kaushik Narayan Subject: Re: Re: [Isms] Discussion: Architecture direction for ISMS In-Reply-To: <20050324022811.33895.qmail@web31005.mail.mud.yahoo.com> References: <20050324022811.33895.qmail@web31005.mail.mud.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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: 7fa173a723009a6ca8ce575a65a5d813 Hi Wes, We are looking at using SNMP transport for the Key Setup Protocol however we still believe the most important design consideration for EUSM is to re-use existing security protocols the includes taking advantage of as much of the existing USM works as possible and to use existing security frameworks such as the GSSAPI. Here is our summary of the three proposals. ------------------------------------------------------------------------------ || Security Protocol || Key Setup Transport || || Existing | New || SNMP | TLS || ------------++-----------+-----------++-------------+----------------++ SBSM || | x || x | || ------------++-----------+-----------++-------------+----------------++ TLSM || x | || | x || ------------++-----------+-----------++-------------+----------------++ EUSM || x | || x | || ------------++-----------+-----------++-------------+----------------++ regards, kaushik! > > > > >>>>> On Mon, 21 Mar 2005 17:47:45 -0800, Kaushik > > Narayan said: > > > > Kaushik> We believe that use of in-band and > > out-of-band keying is not > > Kaushik> the most important difference between EUSM > > and SBSM. > > > > This is a different argument than you've been > > previously making. One > > of the whole purposes of this discussion was to come > > to agreement on > > something, namely an architecture first. > > > > In your response you didn't seem to state clearly if > > you had > > preferences for one or two of the architectures. It > > appears that > > you're no longer solely considering an out-of-band > > mechanism which is > > a very good thing because if we can all agree to > > move a "little bit" > > we'll likely end up somewhere that we can at least > > agree upon even if > > it's not the ideal place for each of us. > > > > Kaushik> We believe the most important differences > > are > > > > So, given that can we concentrate on a preferred > > architecture first > > and then battle the USM issue. This is what we > > agreed upon in MSP but > > yet everyone seems to want to argue the USM case > > instead. > > > > Kaushik> ... we had proposed the use of EAP for Key > > Setup and we plan > > Kaushik> to suggest the use of TLS or GSSAPI for Key > > Setup. > > > > Given the above statement, I originally thought you > > had meant either > > out of band or in-band-underneath would be fine > > (GSSAPI is out-of-band > > sort of... GSSAPI is really an API not an > > architecture but the > > current common mechanism (kerberos) is out-of-band). > > > > But having re-read what you've said I could see > > someone proposing TLS > > on the side to do out-of-band negotiation over TLS. > > I assume this is > > not what you're going to propose since it would be > > somewhat unusual > > but thought I should double check. > > > > So, if you had to pick two (or one) of the > > architectures (*not* > > solutions for those architectures) it sounds like > > you're at least > > willing to consider "encapsulation" (TLS like) or > > "out of band" (EAP > > like) architectures? > > > > It sounds like we're (the group as a whole) actually > > converging on an > > architecture which is acceptable to everyone, which > > is a really really > > good thing. > > > > -- > > 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 Fri Mar 25 16:33: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 QAA19106; Fri, 25 Mar 2005 16:33:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwWO-00073e-2u; Fri, 25 Mar 2005 16:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwQC-0007rk-0W; Fri, 25 Mar 2005 16:32:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEwOp-0007fl-49 for isms@megatron.ietf.org; Fri, 25 Mar 2005 16:31: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 QAA18681 for ; Fri, 25 Mar 2005 16:31:19 -0500 (EST) Received: from smtpout1.bayarea.net ([209.128.95.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEwPY-0006g9-7o for isms@ietf.org; Fri, 25 Mar 2005 16:32:08 -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 j2PLPh9s014687; Fri, 25 Mar 2005 13:25:43 -0800 Received: from shell4.bayarea.net (localhost [127.0.0.1]) by shell4.bayarea.net (8.12.11/8.12.11) with ESMTP id j2PLPEgu023774; Fri, 25 Mar 2005 13:25:14 -0800 Received: from localhost (dperkins@localhost) by shell4.bayarea.net (8.12.11/8.12.11/Submit) with ESMTP id j2PLPEmx023767; Fri, 25 Mar 2005 13:25:14 -0800 X-Authentication-Warning: shell4.bayarea.net: dperkins owned process doing -bs Date: Fri, 25 Mar 2005 13:25:13 -0800 (PST) From: "David T. Perkins" X-Sender: dperkins@shell4.bayarea.net To: Kaushik Narayan Subject: Re: Re: [Isms] Discussion: Architecture direction for ISMS In-Reply-To: <6.2.0.14.0.20050325114402.03982dc0@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: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: isms@ietf.org X-BeenThere: isms@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mailing list for the ISMS working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: isms-bounces@ietf.org Errors-To: isms-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 HI, I don't understand your classification below, since SBSM uses the existing auth and priv protocols defined for USM. That is, it uses the same procedure as specified in RFC 3414, sections 6.2.4 and 6.3 when the HMAC-MD5-96 authentication protocol is being used. Likewise, it uses the same procedure as specified in RFC 3414, sections 8.2.4 and 8.3 for the DES protocol. In general, going through RFC 3414 sections 6, 7, and 8, one simply subsitutes "session key" for "user key" (and "session identifier" for "userName", and you get what SBSM does. On Fri, 25 Mar 2005, Kaushik Narayan wrote: > Hi Wes, > > We are looking at using SNMP transport for the Key Setup Protocol > however we still believe the most important design consideration for > EUSM is to re-use existing security protocols the includes taking > advantage of as much of the existing USM works as possible and to > use existing security frameworks such as the GSSAPI. > > Here is our summary of the three proposals. > > ------------------------------------------------------------------------------ > || Security Protocol || Key Setup Transport || > || Existing | New || SNMP | TLS || > ------------++-----------+-----------++-------------+----------------++ > SBSM || | x || x | || > ------------++-----------+-----------++-------------+----------------++ > TLSM || x | || | x || > ------------++-----------+-----------++-------------+----------------++ > EUSM || x | || x | || > ------------++-----------+-----------++-------------+----------------++ > > regards, > kaushik! > Regards, /david t. perkins _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Sun Mar 27 01:39: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 BAA10155; Sun, 27 Mar 2005 01:39:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DFRWz-0005LA-Pl; Sun, 27 Mar 2005 01: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 1DFROT-0006nb-CN; Sun, 27 Mar 2005 01:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DFROR-0006nR-C4 for isms@megatron.ietf.org; Sun, 27 Mar 2005 01:37: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 BAA09969 for ; Sun, 27 Mar 2005 01:36:52 -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 1DFRUT-0005Fu-HH for isms@ietf.org; Sun, 27 Mar 2005 01:43:17 -0500 Received: by wes.hardakers.net (Postfix, from userid 274) id 965A711D89B; Sat, 26 Mar 2005 22:36:45 -0800 (PST) From: Wes Hardaker To: Kaushik Narayan Subject: Re: [Isms] Discussion: Architecture direction for ISMS Organization: Sparta References: <20050324022811.33895.qmail@web31005.mail.mud.yahoo.com> <6.2.0.14.0.20050325114402.03982dc0@mira-sjc5-a.cisco.com> Date: Sat, 26 Mar 2005 22:36:44 -0800 In-Reply-To: <6.2.0.14.0.20050325114402.03982dc0@mira-sjc5-a.cisco.com> (Kaushik Narayan's message of "Fri, 25 Mar 2005 11:56:08 -0800") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Fri, 25 Mar 2005 11:56:08 -0800, Kaushik Narayan said: Kaushik> We are looking at using SNMP transport for the Key Setup Kaushik> Protocol Ok, this is a big improvement because I think it means that the WG is actually much closer to consensus because we may have the ability to eliminate the external keying scenario. Does anyone still feel attached to this, or can we now concentrate on either underneath (TLS/SSH-ish) or internal (SBSM or internal SASL or ...)? Eliminating one would be a decent step forward. (Please correct me if I'm misreading you) Kaushik> however we still believe the most important design Kaushik> consideration for EUSM is to re-use existing security Kaushik> protocols the includes taking advantage of as much of the Kaushik> existing USM works as possible and to use existing security Kaushik> frameworks such as the GSSAPI. Yes, you've made that clear. Though the WG decided in MSP to discuss architecture first before discussing *how* to do it. Reusing as many existing things vs not is certainly a discussion that we'll have. I agree it's a very important one. But as I've stated before, all the architectures could reuse USM security and could reuse existing frameworks. The consensus in MSP was to select an architecture before jumping to a solution. The good news is that we may be closer to doing that, at which point we can discuss your above points without getting sidetracked. We have until the end of April to decide on an architecture and if we get sidetracked into solution details then we will be out of luck entirely. -- Wes Hardaker Sparta _______________________________________________ Isms mailing list Isms@lists.ietf.org https://www1.ietf.org/mailman/listinfo/isms From isms-bounces@ietf.org Mon Mar 28 21:28: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 VAA08980; Mon, 28 Mar 2005 21:28:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DG6ZC-0000Xi-Ue; Mon, 28 Mar 2005 21:34:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG6RQ-00014D-0c; Mon, 28 Mar 2005 21:26:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DG6RO-000148-2Z for isms@megatron.ietf.org; Mon, 28 Mar 2005 21:26: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 VAA08899 for ; Mon, 28 Mar 2005 21:26:48 -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 1DG6Xy-0000Vc-7O for isms@ietf.org; Mon, 28 Mar 2005 21:33:40 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 28 Mar 2005 18:26:38 -0800 X-IronPort-AV: i="3.91,129,1110182400"; d="txt'?scan'208"; a="242071933:sNHT72900766" 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 j2T2QZZV016049; Mon, 28 Mar 2005 18:26:35 -0800 (PST) Received: from kaushik-w2k03.cisco.com ([171.69.75.179]) by mira-sjc5-a.cisco.com (MOS 3.4.5-GR) with ESMTP id AZM48912; Mon, 28 Mar 2005 18:26:35 -0800 (PST) Message-Id: <6.2.0.14.0.20050328181859.04829d70@mira-sjc5-a.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Mar 2005 18:26:34 -0800 To: "David T. Perkins" From: Kaushik Narayan Subject: Re: Re: [Isms] Discussion: Architecture direction for ISMS In-Reply-To: References: <6.2.0.14.0.20050325114402.03982dc0@mira-sjc5-a.cisco.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_31578387==_" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 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: b1c41982e167b872076d0018e4e1dc3c --=====================_31578387==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi David, We classified the definition and usage of SBSMInit1, SBSMInit2, SBSMInit2Encr, SBSMInit3 and SBSMRunning as new. In contrast, both EUSM and TLSM are based on combining already-defined pieces (both SNMP and non-SNMP) together in new ways. We actually expanded the table with an additional column and added some explanation for the columns. Please find the table in attached text file. The first column in this table refers the re-use of existing USM protocol for message protection (confidentiality, integrity and replay) more in terms putting together existing parts of USM in different ways rather than defining new pieces. The first column also refers to the use of existing security protocols for key negotiation. Both TLSM and EUSM use existing security protocols for key negotiation. The second column of the table refers to the transport protocol used to transmit regular SNMP Get/Set/Notify messages. With SBSM and EUSM regular SNMP messages are transmitted as either UDP or TCP messages just as they are at the moment, i.e., no change whereas for TLSM, they are transmitted in a TLS session. The third column of the table refers to the transport protocol used for the key negotiation. This is the current focus of the WG discussion. The current EUSM proposal uses an external Key Setup mechanism which defines the transport but we are seriously considering the option of performing the Key Setup using SNMP encapsulation especially if that would help the WG to make progress. We believe that the choice of the transport for key negotiation is really based on the transport protocol for the SNMP messages and we believe that the focus of the WG should be really based on the first making a decision of the second column, i.e. whether we believe that we need to use transport based security or security built into SNMP. Once that decision is made, the next decision will have to be made on the first column, i.e. whether we need to modify USM and on the need to use existing security protocols already defined within the IETF. regards, kaushik! At 01:25 PM 3/25/2005, David T. Perkins wrote: >HI, > >I don't understand your classification below, since SBSM >uses the existing auth and priv protocols defined for >USM. That is, it uses the same procedure as specified >in RFC 3414, sections 6.2.4 and 6.3 when the HMAC-MD5-96 >authentication protocol is being used. Likewise, it uses the >same procedure as specified in RFC 3414, sections 8.2.4 and >8.3 for the DES protocol. In general, going through RFC 3414 >sections 6, 7, and 8, one simply subsitutes "session key" >for "user key" (and "session identifier" for "userName", >and you get what SBSM does. > > >On Fri, 25 Mar 2005, Kaushik Narayan wrote: > > > Hi Wes, > > > > We are looking at using SNMP transport for the Key Setup Protocol > > however we still believe the most important design consideration for > > EUSM is to re-use existing security protocols the includes taking > > advantage of as much of the existing USM works as possible and to > > use existing security frameworks such as the GSSAPI. > > > > Here is our summary of the three proposals. > > > > > ------------------------------------------------------------------------------ > > || Security Protocol || Key Setup Transport || > > || Existing | New || SNMP | TLS || > > ------------++-----------+-----------++-------------+----------------++ > > SBSM || | x || x | || > > ------------++-----------+-----------++-------------+----------------++ > > TLSM || x | || | x || > > ------------++-----------+-----------++-------------+----------------++ > > EUSM || x | || x | || > > ------------++-----------+-----------++-------------+----------------++ > > > > regards, > > kaushik! > > >Regards, >/david t. perkins --=====================_31578387==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="isms-eval-matrix.txt" -------------------------------------------------------------------------------- || Security Protocol || Message Encap. || Key Setup Transport || || Existing | New || SNMP | TLS || SNMP | TLS |External|| -------------++----------+--------++--------+--------++-------+------+--------++ SBSM || | x || x | || x | | || -------------++----------+--------++--------+--------++-------+------+--------++ TLSM || x | || | x || | x | || -------------++----------+--------++ -------+--------++-------+------+--------++ EUSM || x | ** || x | || ** | | x || -------------++----------+--------++--------+--------++-------+------+--------++ Message Encap. - SNMP Message Encapsulation ** - In case EUSM uses SNMP as the transport protocol for Key Setup, then the Key Setup procedure will constitute a "New" Security protocol. ** - Current EUSM proposal relies on an external key setup protocol, use of SNMP transport for key setup under consideration. --=====================_31578387==_ 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 --=====================_31578387==_--